Message ID | 20211103131847.116762-1-rasmus.villemoes@prevas.dk |
---|---|
State | New |
Headers | show |
Series | gcc: vx-common.h: fix test for VxWorks7 | expand |
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
diff --git a/gcc/config/vx-common.h b/gcc/config/vx-common.h index 7dd4dee536e..a436bf14074 100644 --- a/gcc/config/vx-common.h +++ b/gcc/config/vx-common.h @@ -97,7 +97,7 @@ along with GCC; see the file COPYING3. If not see /* ------------------------ Misc configuration bits ---------------------- */ -#ifndef TARGET_VXWORKS7 +#if !TARGET_VXWORKS7 /* VxWorks, prior to version 7, could not have dots in constructor labels, because it used a mutant variation of collect2 that generates C code instead of assembly. Thus each constructor label