https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #12 from Richard Biener ---
> (In reply to Eric Botcazou from comment #11)
>> > So I am testing the patch right now and should be able to send it tomorro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #21 from Thomas Preud'homme ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #19)
>>
>> I've now regtested that patch on sparc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #24 from Thomas Preud'homme ---
[...]
>> Please remember to add proposed patches to the URL field of the PR,
>> otherwise they are easily overlooke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #29 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #28 from Thomas Preud'homme ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #22)
>> > --- Comment #21 from Thomas Preud'homme >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #31 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #30 from Thomas Preud'homme ---
> Can you run the test manually under gdb and tell me what is the value for the
> "out" variable in hex format?
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #33 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #32 from Thomas Preud'homme ---
[...]
> Are you sure the patch was applied to this test? Line 78 I have "bfin.inval =
> (struct ok) { 0x83, 0x85, 0x8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #36 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #35 from thopre01 at gcc dot gnu.org ---
> Now that PR61306 and the bswap-2 test issue are fixed in trunk, could you try
> again a bootstrap without any of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #37 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #36 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #35 from thopre01 at gcc dot gnu.org ---
>> Now that PR61306 and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #39 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #38 from thopre01 at gcc dot gnu.org ---
> I've just wrote a patch that solve a bug that can lead to the kind of issue
> you
> are running into. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61533
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Uroš Bizjak ---
> (In reply to Rainer Orth from comment #1)
>> Created attachment 32950 [details]
>> assembler output
>
> The test assum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61498
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Ian Lance Taylor ---
> Should be fixed now, I hope.
Indeed, SPARC results look good again (expect for PR ipa/61495 when
using gas).
Thanks.
Rainer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61268
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from rsandifo at gcc dot gnu.org
> ---
[...]
> The patch passed bootstrap on x86_64-linux-gnu but could you test it for
> sparc too?
Sure: sparc-sun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #41 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #40 from thopre01 at gcc dot gnu.org ---
> Alright, change commited (r211778). Can you try another bootstrap with trunk
> to
> see if your Bus error was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61268
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #5 from rsandifo at gcc dot gnu.org > gnu.org> ---
> [...]
>> Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #42 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #41 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #40 from thopre01 at gcc dot gnu.org ---
>> Alright, change commited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #44 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #43 from thopre01 at gcc dot gnu.org ---
> Thanks. In the stage before the one that fails, could you add
> -fdump-tree-all-details -fdump-rtl-all-details to th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65602
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Ilya Enkovich ---
> (In reply to Rainer Orth from comment #0)
>> All link tests will fail on all non-Linux targets since only those provide
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65644
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Jakub Jelinek ---
> (%edi) etc. in 64-bit mode should be assembled as addr32 (0x67) prefix on the
> instruction. If Solaris assembler doesn't ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65644
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Daniel Richard G. ---
> Reopening due to lack of resolution.
>
> If system patches should resolve the issue, then I am open to trying any that
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65644
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Daniel Richard G. ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #8)
>>
>> Looking closer, you are *not* using the Solaris assem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65931
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Dominique d'Humieres ---
> I have already filed Bug ID# 20510039 and I am using dsymutil from Xcode 6.2.
Good, that helped quite a lot.
Thanks f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456
--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #24 from Bill Schmidt ---
> No, I don't think so. The same change was made in GCC 4.9, and it didn't
> cause
> it to XPASS there (looking at gcc-t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456
--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
[...]
> Not yet: those sparc boxes are slow, and it will take ages. I'll check
> if I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59664
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Jakub Jelinek ---
> I guess it is problematic to include in the test, because then you
> rely on whatever the vendor math.h does.
>
> Does it st
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59430
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Ian Lance Taylor ---
> This should be fixed now.
Indeed, works fine everywhere.
Thanks.
Rainer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59433
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Ian Lance Taylor ---
> Should be fixed now.
I'm seeing a massive improvement, but now some 32-bit tests that used to
work before are failing:
Running
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59433
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
It seems this is a 32-bit issue: the failure is very fragile to
reproduce: I easily get it if running manually or under gdb, but it
vanishes if run under truss. Adding assertions in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59431
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
I thought so myself when I saw the patch and fired off an
i386-pc-solaris2.10 bootstrap. Unfortunately, the failures remain.
Rainer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58111
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
Between 20130906 (r202327) and 20130913 (r202562), the problem vanished.
Rainer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Iain Sandoe ---
> (In reply to Rainer Orth from comment #9)
>> I see the same issue on some Solaris 10/SPARC systems on UltraSPARC T2:
>
> do y
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60076
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Richard Biener ---
> Mine. Some dg-requires of vect_XXX missing probably.
>
> note: not vectorized: no vectype for stmt: _8 = *_7;
> scalar_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #12 from Iain Sandoe ---
[...]
> Do you repeat the findings we see on Darwin, where a heavily loaded system
> does
> not exhibit the slow-down?
no, I se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60076
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Richard Biener ---
> note: extract even/odd not supported by target
>
> aha... next try:
This works: scan-tree-dump isn't even attempted.
Thanks.
Rainer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305
--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #14 from Iain Sandoe ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #13)
[...]
> so the open question is whether there's a fault in the fall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60080
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
I just tried the patch on i386-pc-solaris2.10 and the SEGVs are gone.
Thanks for the quick fix.
Rainer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60107
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Jakub Jelinek ---
> Well, this isn't about main alignment (and, after all, main realigns the stack
> anyway), but about stack alignment upon entering
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
--- Comment #23 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #22 from Jakub Jelinek ---
> (In reply to Rainer Orth from comment #21)
>> The new test FAILs on Solaris 11 (both SPARC and x86), which, unlike Solaris
&
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #24 from Richard Biener ---
> As the standard doesn't specify that the value is undefined upon error and it
> only specifies its contents upon successfull
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55637
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #13 from Dominique d'Humieres ---
>> What should we do about this test? Having it fail everywhere a current
>> binutils
>> version is us
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60290
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Jakub Jelinek ---
> Even with the r207623 fix?
Yes, this is from the latest r207783 bootstraps.
Rainer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59431
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Ian Lance Taylor ---
> Yeah, I didn't think that would fix this problem, I was just hoping for more
> consistent error messages--e.g., "out of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #15 from Dominique d'Humieres ---
> What is the output of
>
> write(*,"(en15.1)") 9.4905
> end
>
> ? If it is 9.4, it means t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from Dominique d'Humieres ---
> Could your repeat the test for
>
> write(*,"(en15.1)") 9.4905_8
> end
9.5E+00
> write(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67421
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Jiong Wang ---
> (In reply to Rainer Orth from comment #0)
>> Created attachment 36275 [details]
>> wide-shift-64.c.219r.combine
>>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67481
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from ktkachov at gcc dot gnu.org ---
> I'm testing a fix for PR 67456.
> Hopefully they have the same root cause and the patch will fix them all
Great:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67622
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
The reghunt revealed (not completely unexpected) the following patch as
the culprit:
The first bad revision is:
changeset: 25098:fa3edfa6a9a7
user:davem@138bc75d-0d04-0410
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67747
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Jonathan Wakely ---
> Could you modify the test to print the values of iter->path() and p/"d1" to
> stdout before the asserti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67912
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Dominique d'Humieres ---
> I think this bug affects all platforms, see the thread
> https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01013.html.
Rig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773
--- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #20 from Dominique d'Humieres ---
> Is this still a problem?
I'm bootstrapping gcc mainline on Mac OS X 10.11.2 Beta just fine. The
only problem I'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773
--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #23 from Iain Sandoe ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #22)
>> > --- Comment #20 from Dominique d'Humieres ---
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773
--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> Ok, I'll dig up the details later today. It may well be related to a
> command line tools upgraded corresponding to Xcode 7.x.
Here's what I found: in stage2, linkin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773
--- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #26 from mrs at gcc dot gnu.org ---
> Are there any symbols in .text? If so, this is wrong. All symbols have to
> have 1 or more bytes after them. This is jus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773
--- Comment #29 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
I've done some more digging and found that the switch from a gas-derived
as in Xcode 6.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773
--- Comment #30 from ro at CeBiTec dot Uni-Bielefeld.DE ---
With Xcode 6.4 as, 32-bit bootstrap is now well into running the testsuite.
I've filed bug
23669324 Xcode 7 as creates relocation ld cannot handle
Rainer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64341
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Jakub Jelinek ---
> Can't reproduce this with a cross to sparc64-linux with -m32, can you still
> reproduce it?
No, they went away between 2014121
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64612
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #13 from Jakub Jelinek ---
> g++.dg/abi/comdat1.C is guarded with { target *-*-*gnu* }, perhaps this test
> should be too.
While that would work, it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64612
--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #15 from Jakub Jelinek ---
> If you are willing to cook up an effective-target for that in
> lib/target-supports.exp, sure, go ahead.
Given the complexi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63439
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Richard Biener ---
[...]
> For SPARC we use v8qi and peel for alignment. That should be handled
> but it looks like SPARC is not vect64 for whatev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63439
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Richard Biener ---
[...]
> which means it is unconditionally vect64 (I assume word_mode is DImode).
Unless I'm completely mistaken, word_mode is SI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63439
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #12 from Richard Biener ---
[...]
>> I'm attaching the 32-bit slp? dumps for reference.
>
> So 64-bit works fine?
Unfortunately not. I'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from rguenther at suse dot de ---
[...]
> Does malloc return 8-byte aligned memory? Is __alignof__
It does, according to libc sources exactly for the case a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64612
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #18 from Jakub Jelinek ---
> Created attachment 34573
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34573&action=edit
> gcc5-pr64612.patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Richard Biener ---
> Created attachment 34591
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34591&action=edit
> patch
>
> Ok,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64799
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Richard Henderson ---
> Created attachment 34583
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34583&action=edit
> proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64368
--- Comment #30 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #25 from Jonathan Wakely ---
> Great, thanks for confirming it. As you say, let's leave this open for now in
> case HP or Rainer still sees some of these f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64799
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
[...]
> Looks good so far: I've applied the patch, rebuilt libffi and run the
> libff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61225
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #18 from Jeffrey A. Law ---
> Rainer,
>
> Zhenqiang has left GCC development.
I didn't know that: now wonder the issue isn't getting his attent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64900
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Ian Lance Taylor ---
> Normally libgo.so will get the symbol _Unwind_GetLanguageSpecificData from
> libgcc_s.so. The first step here is to find out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61535
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
This also affects the new gcc.dg/pr63594-1.c and gcc.dg/pr63594-2.c
testcases.
Rainer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #40 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #39 from Stupachenko Evgeny ---
> (In reply to Rainer Orth from comment #38)
[...]
> You should apply patch from comment 15 as well.
> It is still under rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #42 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #41 from Stupachenko Evgeny ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #40)
[...]
> That should be not "EBX enablig" issue as poi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #45 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #44 from Iain Sandoe ---
> (In reply to Stupachenko Evgeny from comment #43)
[...]
> there were at one point this week 4 concurrent bootstrap breaks on dariwn.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #47 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #45 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
[...]
> I'm now testing the rev before Evgeny's patch to check if that
> bootst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63765
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from David Edelsohn ---
> If _XOPEN_SOURCE is removed from thr.c completely, the testsuite results
> revert
> to 1 failure.
Did this failure already exi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63765
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from David Edelsohn ---
> Yes, the single objc failure existed before the patch. But I don't know if
> *other* targets need _XOPEN_SOURCE=500.
True, b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63765
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from David Edelsohn ---
> I would have expected _XOPEN_SOURCE=500 to be defined in a host-specific
> configure file (like libstdc++-v3/config/os/.../os_defi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63765
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Andrew Pinski ---
> Let's go with the one defining _XOPEN_SOURCE only for Solaris until someone
> programs David's suggestion of the host-spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62289
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Richard Biener ---
> Thus "moved" (ISL bug).
Shouldn't we keep this as a placeholder until GCC is made to work with a
fixed version of I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63966
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Uroš Bizjak ---
> What happens if you remove check for __PIC__ from the #if guard?
Which guard do you mean? There's no such guard in either libc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63966
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Uroš Bizjak ---
> Can you please test this patch:
i386-apple-darwin14.0.0 bootstrap into stage2 now, so seems ok.
Thanks.
Rainer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64054
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Jonathan Wakely ---
> Doh, so it is, I misread the test code.
>
> Rainer, what does this print (when compiled with -std=c++11)?
>
> #include
&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64055
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Dominique d'Humieres ---
> Revision r217101 is OK.
Not in my case: at r217915, the test FAILs for the 32-bit multilib of
both the i386-apple-darwi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64054
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Jonathan Wakely ---
> Thanks - so it looks as though the problem is in std::stod which is pretty
> simple, and can be reduced to:
[...]
> Maybe Sol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64054
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Jonathan Wakely ---
> Aha, of course.
>
> Maybe we should just add this to the test for now?
>
> // https://gcc.gnu.org/bugzilla/show_bug.cgi?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64056
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Jakub Jelinek ---
> So fixed?
Not completely: unlike Solaris 11, Solaris 10 lacks stpcpy in libc, thus
FAIL: gcc.target/i386/chkp-strlen-2.c (test for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56203
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
"dominiq at lps dot ens.fr" writes:
> --- Comment #3 from Dominique d'Humieres ---
> Without feedback I'll close this PR as WONTFIX.
This has become more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56203
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Joost VandeVondele ethz.ch> ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #4)
>> This has become more pronounced with increased g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61283
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Jan Hubicka ---
> The i386 testcase works for me now. It has static ctor that becomes pure so it
> ought to be duplicate of PR61324
Right: the testcase s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64054
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #13 from Jonathan Wakely ---
> Rainer, should we close this now?
I'd rather keep it open or mark it suspended as a reminder.
Rainer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61748
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Dominique d'Humieres ---
> I have silenced the failure with the following patch
>
> --- ../_clean/gcc/testsuite/g++.dg/ipa/imm-devirt-2.C2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61822
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Yuri Rumyantsev ---
> Hi Rainer,
>
> Could you try attached patch to check if it helps (test should not be
> run for sparc).
Indeed, the test is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #62 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #60 from Richard Biener ---
[...]
> Fix:
>
> Index: gcc/tree-ssa-loop-ivopts.c
> ===
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #63 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #62 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
[...]
> With the patch, SPARC bootstrap concluded on mainline. I'm seeing two
> diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Richard Biener ---
> it's odd that stage2 is not affected... can you provide preprocessed source
I lied: if you generate the .gch file with the stage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61950
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Richard Biener ---
[...]
> So I wonder whether it rather is libgfortran that is miscompiled? Can you
> check running the testcases against an olde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61950
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
With the patch, the previously failing gfortran.dg/allocate_class_3.f90
testcase works fine on 64-bit SPARC.
Thanks.
Rainer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Richard Biener ---
[...]
> Patch attached, it may still help SPARC passing the testcase.
The patch doesn't make a difference, unfortunately.
Rainer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #65 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #61 from Eric Botcazou ---
[...]
>> can you test and apply that patch?
>
> I think that it needs to be applied on both mainline and 4.9 branch then.
Tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61535
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
I'm seeing the same on the 4.7, 4.8, and 4.9 branches. Also
reproducible in i386-pc-solaris2.11 x sparc-solaris2.11 and
x86_64-unknown-linux-gnu crosses.
Rainer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62304
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Dave Malcolm ---
> The crash in find_dead_or_set_registers is the one discussed in:
> https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02619.html
> and
701 - 800 of 1428 matches
Mail list logo
