Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?
Hi Alex, I do regular bootstraps of mainline all languages on FC3 i686-pc-linuux-gnu and haven't seen any problemss upto Friday. I'm using --enable-checking=tree,misc,rtl,rtlflag which might make a difference. Cheers Graham
Re: ada build failure?
Richard, No but I haven't been able to bootstrap with Ada since Friday I'm currently getting stage1/xgcc -Bstage1/ -B/usr/local/NETGCC/i686-pc-linux-gnu/bin/ -c -O2 -g -fomit-frame-pointer -gnatpg -gnata -I- -I. -Iada -I/src/gcc4.0/gcc/gcc/ada /src/gcc4.0/gcc/gcc/ada/ada.ads -o ada/ada.o raised STORAGE_ERROR : stack overflow (or erroneous memory access) Richard Henderson wrote: Is anyone else seeing this? I see the same with either 3.3 or 3.4 as the build compiler. gcc -c -g -gnatpg -gnata -I- -I. -Iada -I../../src-gcc/gcc/ada \ ../../src-gcc/gcc/ada/exp_ch11.adb -o ada/exp_ch11.o exp_ch11.adb:926:34: expected type "Char_Code_Base" defined at types.ads:531 exp_ch11.adb:926:34: found private type "Uint" defined at uintp.ads:50 r~
Re: Stage2 Miscompilaton of Ada?
Andreas, I've had the same problem since updating on Wednesday evening :-( It did bootstrap overnight Tuesday. Cheers Graham
Re: Ada Status in mainline
Jeff, The last time I bootstrapped with Ada successfully on i686-pc-linux-gnu was around 9/10th May after that it hangs in stage3 so I've had it disabled since then. Maybe it's time once it back bootstraping to enable Ada by default during bootstraps. Graham
Re: Visual C++ style inline asms
--- Richard Henderson <[EMAIL PROTECTED]> wrote: > On Tue, Jun 14, 2005 at 09:26:11PM -0400, Andrew Pinski wrote: > > On Jun 14, 2005, at 9:25 PM, Mike Stump wrote: > > >Any objections to adding Visual C++ style inline asms? > > > > Didn't RTH objected the last time? > > One has to do a less gross job of it than Red Hat did. I suppose > I could be prodded into pulling out the code so that you can see > where the bar is. It was a nightmare to get the large test apps working, they had inline asms that spaned several pages of A4 with emmbeded labels, control flow, and other cruff which was why it ended up being so gross. Also when combined with C++ Templates even the upfront parsing of the asm gets hairy very quickly. Graham
Re: Where is TARGET_EXPLICIT_RELOCS defined for MIPS?
It's done during configury Cheers Graham
Re: Somebody broke bootstrap on trunk for x86_64
It looks kike that patch contains a typo
The entry for nonmemory_operand has an extra bogus false
The following patch more than likely fixes the fallout I've just kicked of
a x86_64 bootstrap to find out
Index: gensupport.c
===
--- gensupport.c(revision 107251)
+++ gensupport.c(working copy)
@@ -1242,7 +1242,7 @@
{"const_double_operand", false, {CONST_INT, CONST_DOUBLE}},
{"nonimmediate_operand", false, {SUBREG, REG, MEM}},
{"nonmemory_operand", false, {CONST_INT, CONST_DOUBLE, CONST, SYMBOL_REF,
-false, LABEL_REF, SUBREG, REG}},
+ LABEL_REF, SUBREG, REG}},
{"push_operand", false, {MEM}},
{"pop_operand", false, {MEM}},
{"memory_operand", false, {SUBREG, MEM}},
Cheers
Graham
Re: -static-pie and -static -pie
Original message
From: Rich Felker
Date: 02/02/2018 18:32 (GMT+00:00)
To: Szabolcs Nagy
Cc: li...@coryfields.com, "H.J. Lu" , n...@arm.com, GCC
Development
Subject: Re: -static-pie and -static -pie
On Fri, Feb 02, 2018 at 11:33:22AM +, Szabolcs Nagy wrote:
> On 31/01/18 15:44, Cory Fields wrote:
> >After looking at this for quite a while, I'm afraid I'm unsure how to
> >proceed.
> >
> >As of now, static and static-pie are mutually exclusive. So given the
> >GNU_USER_TARGET_STARTFILE_SPEC you pasted
> >earlier, "static" matches before "static-pie", causing the wrong start files.
> >
> >It seems to me that the static-pie target complicates things more than
> >matching against static+pie individually.
> >
> >If I convert -static + -pie to -static-pie, then "static" won't be
> >matched in specs, where maybe it otherwise should. Same for -pie.
> >
>
> you can change PIE_SPEC to pie|static-pie
> and occurrences of static to static|static-pie
> (and !static: to !static:%{!static-pie: etc.),
> except where it is used to mean "no-pie static",
> those should be changed to PIE_SPEC:;static:
> (and i think --no-dynamic-linker should always
> be passed to ld in LD_PIE_SPEC for static pie,
> not just on linux systems and selected targets.)
>
> then there should be no difference between -static -pie
> and -static-pie. (and the new -static-pie flag would
> be redundant.)
>
> this would e.g. break static linking with default pie
> toolchain on systems where the static libc is not pie
> or missing the rcrt startup file after upgrading to gcc-8.
> i'm not sure if this is a good enough reason to introduce
> the -static-pie mess, however if we don't want to break
> any previously working configuration then -static-pie has
> to be different from -static -pie.
Ideally, ld would have an "opportunistic pie" option to link as pie
whenever the input files are all pic, and fallback to non-pie if any
pic-incompatible (would-be-textrels) objects are present. However this
is architecturally complex to support because ld would have to know
about switching between versions of crt1.
In practice, I think users on musl-based systems like Alpine with
default-pie will want -static to continue to produce static pie by
default; this is what Alpine is doing now with their gcc package. I
think the idea is that, since the toolchain produces pie by default,
all static libraries will end up being pie anyway.
If you have an ecosystem of old and new static libraries from
different toolchains, though, that might not be a safe assumption.
Also note that libtool and various other software may interpret
-static and may not expect to be static linking when only -static-pie
but not -static appears in LDFLAGS.
I think reasonable course of action is:
1. -static-pie can always request linking as static pie. It should be
compatible with having -static on the command line too so as not to
break build systems that are aware of and look for -static (in
which case the user building might need to add both options).
2. Behavior of -static with -pie (including default pie) should be
configurable via something like --enable-default-static-pie. This
way distros that have been using -static -pie to get static pie can
keep doing so without patching their GCCs, and distros that need a
more conservative behavior can have that.
Thoughts? Even if you don't want to do #2 as-is, I think an effort
should be made not to break things so that it's hard for distros to
preserve the ability of -static to work (successfully build static
pie) on default-pie toolchains.
Rich
Re: CSE bug when narrowing constants
All, One thing that may or may not be related is that the current main fails to bootstrap on x86_64 with fold checking enabled. It aborts due to a fold-checking failure (i.e fold has modified it's inputs) using the stage1 compiler. I don't recall exactly which file it triggers on (I think it was one of the host-ieee*.c files in libdecnumber library). The last bootstrap I did was about 8 weeks ago and that passed with all checking enabled so its a *recent* regression. I'll look into the cause this evening. Cheers Graham --- On Mon, 1/12/08, Eric Botcazou <[EMAIL PROTECTED]> wrote: > From: Eric Botcazou <[EMAIL PROTECTED]> > Subject: Re: CSE bug when narrowing constants > To: "Gary Funck" <[EMAIL PROTECTED]> > Cc: gcc@gcc.gnu.org > Date: Monday, 1 December, 2008, 10:50 AM > > cse_insn() calls lookup_as_function() ultimately > through fold_rtx(), IIRC, > > and is the routine that writes the REG_EQUAL note. > > OK, thanks. But I'm a little at a loss as to why this > problem arises only > now: the problematic code in lookup_as_function is one > decade old. Do you > happen to have older compilers around (say GCC 4.1.x based) > that correctly > compile the testcase? If so, what happens differently with > them? > > -- > Eric Botcazou
Re: Bootstrap failure on Linux/x86-64
Andreas, FWIW I've had successful bootstrap with these checking flags on x86_64-unknown-lunux-gnu Graham
Re: Should we remove java from the default bootstrap languages?
All, --- Andrew Haley <[EMAIL PROTECTED]> wrote: > Mark Mitchell wrote: > > Andrew Haley wrote: > > > >>> I agree. I also agree that if someone breaks Java, they should be > >>> required to fix the problem. In fact, we could have the rule that the > >>> Java maintainers get to revert a patch summarily based merely on the > >>> fact that there exists a Java post-patch failure that does not occur > >>> pre-patch. > >> > >> OK. I'm hoping that the java mainatiners won't have _all_ the burden, > >> though. > >> > >> We should have a trial phase where java build breakage on the > >> autobuilders > >> is mailed to the maintainers who checked in patches and to the java > >> maintainers, and we'll see how it goes. > >> > >> I'm open-minded about this, but if it doesn't work we should be > >> prepared to > >> revert the policy. > > > > I think that's reasonable. Perhaps a 30-day trial period, after the > > autobuilder is set up? Then if we're seeing that the Java maintainers > > have had to beat people up a lot -- and particularly if that isn't > > yielding results -- then we revert? > > OK, but perhaps with a slightly longer trial period. I'm not hung up on > that though. > > > To be clear, I have no special decision-making power here. I'm hoping > > we can build a consensus to move in this direction, but it has to be a > > consensus decision. > > Understood. > > Andrew. > Maybe we could have the default depend on which stage of development the tree is currently in. For example during stages 1 and 2 the default could be disabled and during stage 3 it could be enabled. Cheers Graham
