gcc: vx-common.h: fix test for VxWorks7

  The macro TARGET_VXWORKS7 is always defined (see vxworks-dummy.h).
Thus we need to test its value, not its definedness.

Fixes aca124df (define NO_DOT_IN_LABEL only in vxworks6).

gcc/ChangeLog:

	* config/vx-common.h: Test value of TARGET_VXWORKS7 rather
	than definedness.
---
 gcc/config/vx-common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

Hi Rasmus,

> On 3 Nov 2021, at 14:18, Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:
> 
> The macro TARGET_VXWORKS7 is always defined (see vxworks-dummy.h).
> Thus we need to test its value, not its definedness.
> 
> Fixes aca124df (define NO_DOT_IN_LABEL only in vxworks6).
> 
> gcc/ChangeLog:
> 
> 	* config/vx-common.h: Test value of TARGET_VXWORKS7 rather
> 	than definedness.

Indeed. Ok, thanks!
  

On 05/11/2021 09.08, Olivier Hainque wrote:
> Hi Rasmus,
> 
>> On 3 Nov 2021, at 14:18, Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:
>>
>> The macro TARGET_VXWORKS7 is always defined (see vxworks-dummy.h).
>> Thus we need to test its value, not its definedness.
>>
>> Fixes aca124df (define NO_DOT_IN_LABEL only in vxworks6).
>>
>> gcc/ChangeLog:
>>
>> 	* config/vx-common.h: Test value of TARGET_VXWORKS7 rather
>> 	than definedness.
> 
> Indeed. Ok, thanks!

Applied to master and pushed - hope I've done it right.

How about the gcc-11 branch, can it be applied there as well, and if so,
should I do a "git cherry-pick -x" and push it to that branch? From
looking at the git history it seems to be the way things are done.

Thanks,
Rasmus
  

> On 5 Nov 2021, at 09:48, Rasmus Villemoes <rasmus.villemoes@prevas.dk> wrote:
> Applied to master and pushed - hope I've done it right.

AFAICS, yes.

> How about the gcc-11 branch, can it be applied there as well,

Yes, I think so. The builds you do used to work before
the change that introduced the ifdef, IIUC, and the adjustment
you propose is close to being in the "obvious" category.

Very small, clearly vxworks only and in line with
every other use of that macro.

> and if so,
> should I do a "git cherry-pick -x" and push it to that branch?

> From
> looking at the git history it seems to be the way things are done.

That's my understanding as well.

Thanks,

Olivier
  

On 05/11/2021 15.08, Olivier Hainque wrote:
> 
> 
>> On 5 Nov 2021, at 09:48, Rasmus Villemoes <rasmus.villemoes@prevas.dk> wrote:
>> Applied to master and pushed - hope I've done it right.
> 
> AFAICS, yes.
> 
>> How about the gcc-11 branch, can it be applied there as well,
> 
> Yes, I think so. The builds you do used to work before
> the change that introduced the ifdef, 

Well, apart from all the other fixups, some of which are not
upstreamable, that I also need to apply :)

IIUC, and the adjustment
> you propose is close to being in the "obvious" category.

Indeed. I'll cherry-pick it into releases/gcc-11.

Have you had a chance to look at the other four patches I've sent
recently? They are also vxworks-only, and shouldn't be very controversial.

Rasmus
  

> On 5 Nov 2021, at 15:12, Rasmus Villemoes <rasmus.villemoes@prevas.dk> wrote:
> 
>> Yes, I think so. The builds you do used to work before
>> the change that introduced the ifdef, 
> 
> Well, apart from all the other fixups, some of which are not
> upstreamable, that I also need to apply :)

Sure. My comment was only meant as positioning wrt
the branch commit policy.

The issue you address can be seen as triggering a regression on
its own, regardless of other changes possibly causing issues as well,
so a safe fix for it is eligible to the branch.

> IIUC, and the adjustment
>> you propose is close to being in the "obvious" category.
> 
> Indeed. I'll cherry-pick it into releases/gcc-11.
> 
> Have you had a chance to look at the other four patches I've sent
> recently? They are also vxworks-only, and shouldn't be very controversial.

Not yet, but I'm planning to get there RSN.

I have been in delivery preparation mode on another project this week
and we had to finalize a move to gcc-11 for non vxworks ports we have
in-house first.

VxWorks ports are next in line, starting next week. We have quite a
few changes to push (wrt shared libs in particular), and I'll take the
opportunity to incorporate your changes in my local testing cycles
(pretty heavy for vx7, and some for vx6).

We happen to also have a few fixincludes hunks around. Some of
them have been there for years now and I thought would be nice to
propagate at some point.

Do you use it?
  

On 05/11/2021 16.12, Olivier Hainque wrote:
> 
> 
>> On 5 Nov 2021, at 15:12, Rasmus Villemoes <rasmus.villemoes@prevas.dk> wrote:

> We happen to also have a few fixincludes hunks around. Some of
> them have been there for years now and I thought would be nice to
> propagate at some point.
> 
> Do you use it?

Sort of, kind of. I have previously sent fixups for some of the vxworks
fixincludes, and I think I have a few more I could submit, but since I'm
able to modify our target headers directly that's often much easier.

For example, there's the mkdir fixup that adds

    #define mkdir(dir, ...) ((void)0, ##__VA_ARGS__, (mkdir)(dir))

But that macro doesn't play well with code in libstdc++ that says

    if (posix::mkdir(p.c_str(), mode))

because that expands to utter nonsense and breaks the build. A better
macro, also using the comma operator to have the mode argument evaluated
then ignored, would be something like

  #define mkdir(dir, mode) mkdir(((void)(mode), (dir)))

(or the variadic version to continue allowing a one-argument
invocation). But it was easier to just change the target header, making
that fixinclude pattern no longer apply - knowing that if we ever
compile the mkdir implementation [we have parts of the kernel sources,
but not all], we'll have to fixup the definition.

The one fixinclude-related problem I have is the stdint.h one I've
mentioned previously.

Rasmus