http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54283
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-11-16 09:11:36 UTC ---
> --- Comment #3 from Andrew Pinski 2012-11-16
> 01:06:20 UTC ---
> Does this still happen?
It does. I've a local patch in my
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402
--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-12-06 16:56:35 UTC ---
> --- Comment #15 from Richard Biener 2012-12-06
> 16:41:45 UTC ---
> Improvements so that the regression part is fixed?
Not on Sola
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-12-12 11:07:21 UTC ---
> --- Comment #18 from Jakub Jelinek 2012-12-10
> 10:56:51 UTC ---
> (In reply to comment #16)
>> Not on Solaris/SPARC, unfortunately:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54718
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-12-12 15:53:49 UTC ---
The extreme sparcv9 libgo compile times without
-fno-var-tracking-assignments are handled in PR debug/54402, it seems.
I haven't seen the ICE cover
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44495
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-12-12 16:04:21 UTC ---
> --- Comment #5 from Eric Botcazou 2012-12-11
> 08:32:07 UTC ---
> Does this still occur?
I had done some further investigate at that time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402
--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-12-13 13:12:00 UTC ---
> --- Comment #22 from Jakub Jelinek 2012-12-12
> 22:21:57 UTC ---
> Created attachment 28942
> --> http://gcc.gnu.org/bugzilla/attachme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54283
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-12-18 12:06:21 UTC ---
> --- Comment #9 from Jakub Jelinek 2012-12-18
> 10:30:12 UTC ---
> So not a bug then?
I don't think so: even on x86_64-unknown-l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54283
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-12-18 12:12:32 UTC ---
> --- Comment #11 from Jakub Jelinek 2012-12-18
> 12:09:52 UTC ---
> If you don't add that /vol/gcc-4.4/lib/ to ld.so.conf (or ld.so.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54283
--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-12-19 14:33:55 UTC ---
> --- Comment #14 from Jakub Jelinek 2012-12-19
> 12:04:19 UTC ---
> Given that -static-libstdc++ has been added to trunk in 2009-06-25, and g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55594
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE 2013-01-06 15:42:03 UTC ---
> --- Comment #4 from Jakub Jelinek 2013-01-06
> 15:10:01 UTC ---
> So, can we restrict the -Wa,-nH check to *-*-solaris*, or do also say -Wa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54283
--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE 2013-01-07 12:08:27 UTC ---
I can now confirm that using g++ 4.7 as bootstrap compiler works out of
the box. Even with the problems I've observed with g++ 4.4, this seems
a sui
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54283
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE 2013-01-07 13:06:16 UTC ---
> --- Comment #17 from Jakub Jelinek 2013-01-07
> 12:55:39 UTC ---
> But that is not a requirement. The requirement is using a C++ compiler that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402
--- Comment #29 from ro at CeBiTec dot Uni-Bielefeld.DE 2013-01-21 10:07:02 UTC ---
> --- Comment #28 from Alexandre Oliva 2013-01-18
> 11:08:06 UTC ---
> Is the mem-clobbering compile-time regression still noticeable after the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54507
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE 2013-01-21 10:09:18 UTC ---
> --- Comment #3 from Alexandre Oliva 2013-01-18
> 11:08:43 UTC ---
> FYI, var-tracking just got a patch that could make this better.
As repor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402
--- Comment #31 from ro at CeBiTec dot Uni-Bielefeld.DE 2013-01-24 12:45:44 UTC ---
> --- Comment #30 from Richard Biener 2013-01-23
> 16:49:05 UTC ---
> Is it still a regression from 4.7.x?
Not anymore, judging from my
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56076
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE 2013-01-29 15:05:14 UTC ---
> --- Comment #5 from Ian Lance Taylor 2013-01-25
> 23:43:57 UTC ---
> May be fixed now. Not sure.
It is, thanks.
Rainer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56173
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE 2013-02-02 21:05:42 UTC ---
> --- Comment #1 from Ian Lance Taylor 2013-02-02
> 16:12:35 UTC ---
> Can you verify that the files in libgo/go/archive/tar/testdata are identi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56172
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE 2013-02-04 13:00:59 UTC ---
Thanks for the analysis.
> Since you can recreate the bug, I guess the next step is to check the
> mp->waitsema field in the runtime_semawakeup f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69917
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Dominique d'Humieres ---
> Confirmed on x86_64-apple-darwin15.
I don't think so: in my x86_64-apple-darwin15.4.0 builds, the test fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Jakub Jelinek ---
> Can you please bisect it to the exact change that reintroduced it?
Sure: the reghunt found this patch:
2016-02-08 Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #12 from Richard Biener ---
> Can you please answer comment #5 now?
The testcase there compiles and executes just fine, both before and with
your patch.
Rainer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949
--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE ---
They do, and for the same reason:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x08f5ecc1 in md5_read_ctx (resbuf=0x8046fd8, ctx=0x8046e90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> So this is with bootstrap-O3?
No, just a regular (i.e. -O2) bootstrap.
I've just checked again: the SEGV doesn't happen with the stage1
compiler, but with both the stag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949
--- Comment #20 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from Richard Biener ---
> ./configure --target=i386-pc-solaris2.10
>
> is not enough, with -O3 -msse2 and the preprocessed file I get
>
&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949
--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #22 from Richard Biener ---
> Btw, don't see how this can be in any way related to the cited rev.
This reghunt was straightforward, but last time I'd fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949
--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #21 from Richard Biener ---
> Ok, can reproduce but I need -msse2 in addition to -O2 (but executing ./cc1 so
> your diver may add that).
It does: config.gcc has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949
--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #23 from Richard Biener ---
> Well, looks like same analysis as the last time ;) Sth is broken on solaris -
> please check with gdb how the stack is aligned on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949
--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #27 from rguenther at suse dot de ---
[...]
>> Maybe we'll need the Solaris 9-only fix from PR libgomp/60107 on Solaris
>> 10+, too.
>
> Or do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68915
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from vries at gcc dot gnu.org ---
[...]
> Can you try out this patch?
It's a bit too much:
XPASS: gcc.dg/vect/pr46032.c scan-tree-dump-not vect "vers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70224
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Jakub Jelinek ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #10)
[...]
>> I just did, but it ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70224
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Jeffrey A. Law ---
> So I realized that given the nature of this bug a simple bootstrap on sparc
> wasn't going to be particularly interesting -- bo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69917
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Ilya Enkovich ---
[...]
> test.chkp printed in assembler means we either miss transparent alias chain
> for
> an alias or ignore it when output.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69917
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Ilya Enkovich ---
> I got an access to x86_64-apple-darwin12.5.0. Will try to reproduce there.
There's no point: as I mentioned in comment 2, the fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69917
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Ilya Enkovich ---
> Looking through Solaris configs I see two places where transparent aliases are
> not followed. This patch should fix this. Any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69917
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #9 from Ilya Enkovich ---
>> Looking through Solaris configs I se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70356
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Jakub Jelinek ---
[...]
> But, avx-vextractf128-256-5.c has:
> dg-require-effective-target avx512f, so wonder what is the problem.
> Does the order of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70356
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Jakub Jelinek ---
> Seems this test is the only one in gcc.target/i386 that has
> dg-require-effective-target above dg-do.
> Can you please tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70581
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Jakub Jelinek ---
> Created attachment 38215
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38215&action=edit
> gcc6-pr70581.patch
&g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68945
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Stefan Teleman ---
>> Since Stefan hasn't followed up and I'm currently looking at other
>> libcilkrts issues anyway, I'm taking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650
--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from Jason Merrill ---
[...]
> This fixes the reduced testcase for me on sparc, does it fix bootstrap on the
> various targets?
Just for the record, with you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
[...]
> Just for the record, with your patch a sparc-sun-solaris2.12 bootstrap
> is well int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70839
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Richard Biener ---
> But the actual 6.1.0 release works, right?
No, unfortunately not: that's where I first noticed the problem when
building 6.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70803
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from amker at gcc dot gnu.org ---
> Thanks for reporting this, I will check it. Maybe a simple "vect_int_mult" to
> skip on some targets.
Right, r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70360
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Rainer Orth ---
> I'm seeing the abi_check failure with
--enable-vtable-verify on x86_64-pc-linux-gnu and i386-pc-solaris2.12:
7 incompatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68945
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Eric Botcazou ---
[...]
>> * One thing I wonder about is runtime/config/sparc/os-fence.h: when using
>> __sync_synchronize, gcc emits membar #S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71080
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE ---
The obvious patch (returning false for exp == NULL_TREE in
ix86_in_large_data_p) fixes the testcase above and survived
x86_64-pc-linux-gnu bootstrap. A second make check with -mcmodel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71097
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Uroš Bizjak ---
> Many of these are testsuite issues, -mcmodel=medium is incompatible with
> -mx32.
This doesn't apply to the cases I listed: this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71097
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
You're right, of course: should have kept my mouth shut ;-(
This leaves us with
gcc.target/i386/387-12.c
gcc.target/i386/avxfp-1.c
gcc.target/i386/avxfp-2.c
gcc.target/i386/ssef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71264
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Richard Biener ---
> Does adding
>
> ptr = __builtin_assume_alinged (alignof (footype), ptr);
> mask = __builtin_assume_aligned (alignof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70923
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Marc Glisse ---
> (In reply to Richard Biener from comment #1)
>> We have vect_recog_mult_pattern that should have triggered here but that
&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70923
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Marc Glisse ---
[...]
> Does it help?
It does: I just completed a sparc-sun-solaris2.12 bootstrap and the
failures are gone. Unfortunately, the patch intr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81514
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from David Malcolm ---
> Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01858.html
I've included the patch in this weekend's Solaris bo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #27 from H.J. Lu ---
> What are error messages?
None, the warnings are simply missing.
Rainer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from rguenther at suse dot de ---
[...]
> They are created that way to make my life easier. They are supposed to be
> valid
> ELF objects and they are acco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from rguenther at suse dot de ---
[...]
>>collect2: fatal error: ld terminated with signal 11 [Segmentation
>>Fault]
>>compilation terminated.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from rguenther at suse dot de ---
> On August 25, 2017 4:14:05 PM GMT+02:00, "ro at CeBiTec dot Uni-Bielefeld.DE"
[...]
>>My reading is differen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Eric Botcazou ---
[...]
> Rainer, do you test Go in this configuration (system as + ld)?
Sorry for the long delay: I've been mostly away for 6 week
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #12 from Dennis Clarke ---
> I don't mean to ask what may seem obvious but does it make sense to
> add a not required "dummy .text" section? I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82011
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Richard Biener ---
> Ok, so a simple checking patch like the following unfortunately fires
> right and left, restricting it to DW_AT_inline doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from rguenther at suse dot de ---
> On Mon, 28 Aug 2017, ro at CeBiTec dot Uni-Bielefeld.DE wrote:
[...]
> Thanks. Can you check whether the above patch res
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #16 from Dennis Clarke ---
> This is excellent follow up and it looks like GNU binutils must be around
> somewhere on the system for "Go" to build.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82045
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from rsandifo at gcc dot gnu.org gnu.org> ---
> Could you attach the .i file? Using a cross compiler, I was able to build the
Sure, done.
> parts of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82045
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from rsandifo at gcc dot gnu.org gnu.org> ---
[...]
>> Natively, I can easily reproduce the ICE with
>>
>> $ cc1 -fpreprocessed libgcc2.i -qui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82045
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
>> --- Comment #4 from rsandifo at gcc dot gnu.org > gnu.org> ---
> [...]
>>> Natively, I can easily reproduce the ICE with
>>>
>>> $ cc1 -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82045
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #6)
[...]
> Ah! Thanks for debugging it. I guess the problem is that we're
> passing the new machine_mode c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82045
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from rsandifo at gcc dot gnu.org gnu.org> ---
[...]
> Here's the patch I'm testing. Only sanity-checked on aarch64-linux-gnu and
> cross sparc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82045
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
Unfortunately, the patch breaks x86 bootstrap (e.g. for the 32-bit
_multc3.o), both in i386-pc-solaris2.* and x86_64-pc-linux-gnu compilers:
$ cc1 -fpreprocessed libgcc2.i -quiet -o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Richard Biener ---
[...]
>> Why does Solaris ld output warnings by default? Does it have an
>> option to suppress them? It doesn't seem th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #14 from Richard Biener ---
> Thanks for the detailed analysis. Indeed
>
> /* Mark sections as preserved that are required by to be preserved
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81733
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Sandoe ---
> Is this still current?
It is: just tried with a vanilla tree at r252892.
> The ld64 assert is most likely triggered by a 0-length F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from rguenther at suse dot de ---
[...]
>>That worked just fine, thanks.
>>
>>While there are still ld warnings
>>
>>ld: warning: f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
--- Comment #56 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #55 from simon at pushface dot org ---
> (In reply to Iain Sandoe from comment #54)
>
>> I bootstrapped r252936 on x86-64 Darwin15.6 (10.11.6), it w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
--- Comment #58 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #57 from Iain Sandoe ---
[...]
>> Now running an i386-apple-darwin11.4.2 bootstrap, which will take
>> another day.
> Dominique reported OK on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80459
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Jakub Jelinek ---
> Created attachment 41226
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41226&action=edit
> gcc7-pr80459.patch
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80645
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Martin Sebor ---
> I'm not able to reproduce the warning mentioned in comment #1 either with a
> native x86_64 compiler (-m32 or -m64), or with the c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881
--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #27 from Jerry DeLisle ---
> (In reply to Rainer Orth from comment #15)
>> The new testcase FAILs on 64-bit Solaris/SPARC:
>>
>> +FAIL: gfort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Daniel Santos ---
> (In reply to Rainer Orth from comment #0)
>> It seems to me that ms-sysv.exp is seriously misguided in trying to do all
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Daniel Santos ---
> Actually, I just realized that it won't help to move do_test.S into ms-sysv.c
> as inline asm because each test still needs a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
Daniel,
> Would you be so kind as to test this on Solaris for me please? I don't have
> access to a Solaris machine and I've never set it up before, so I wouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Daniel Santos ---
[...]
> Anyway, if you can test it again for me and let me know what you think I would
> appreciate it. I've got some other c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Daniel Santos ---
[...]
>> sure, though there's no need at all (except for the .struct part) to do
>> the testing on Solaris. I believe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80913
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Nathan Sidwell ---
[...]
> But x86_64-linux is not being affected in the way you describe. The backtrace
> is something borking in the spelling correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80913
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Nathan Sidwell ---
> yes, must be something with a 32-bit target. I can reproduce it on x86_64
> linux host targeting either i386-linux or i386-solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80913
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Nathan Sidwell ---
> It doesn't appear to be the stathack patch at fault here. I still get the
> infinite loop with my reduced testcase when I reve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #18 from Daniel Santos ---
> I intended to respond to your comments from 6 days ago sooner, but better late
> than never! Again, sorry for the delay
No worri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759
--- Comment #20 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from Daniel Santos ---
> (In reply to Rainer Orth from comment #15)
>> Created attachment 41404 [details]
>> Switch ms-sysv to more regular dg fun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
--- Comment #31 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #29 from Dominique d'Humieres ---
>> Did you try what I suggested in comment #16 as a stopgap measure?
>> No GNAT developer builds the mainlin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
--- Comment #32 from ro at CeBiTec dot Uni-Bielefeld.DE ---
Oh, I forgot: does anyone have an explanation why
i386-apple-darwin16.7.0 and i386-apple-darwin11.4.2 bootstraps *with*
Ada still work fine while their x86_64 counterparts fail?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80928
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
... and also on sparc-sun-solaris2.12:
+FAIL: gcc.dg/vect/slp-13-big-array.c -flto -ffat-lto-objects
scan-tree-dump-ti
mes vect "vectorizing stmts using SLP" 3
+FAIL: gcc.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80928
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
>> --- Comment #5 from Rainer Orth ---
>> The patch also caused a couple of regressions on i386-pc-solaris2.12:
>>
>> +FAIL: gcc.dg/vect/slp-perm-8.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
I've digged a bit further now.
Running the testcase under gdb, I find that p at the failing assertion
is 0x806fda8, i.e. not aligned to 16 bytes but to 8 bytes instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759
--- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #22 from Daniel Santos ---
[...]
> I thought I would post this here before posting to the list since I still
> don't
> have a useable i686 build to t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759
--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
[...]
> Besides, can you *pretty please* concentrate on the issue at hand in
> this PR, i.e.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Maxim Ostapenko ---
[...]
> For ODR violation bug we have a local patch in libsanitizer. Could you check
> whether you applied all local patches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759
--- Comment #30 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #29 from Daniel Santos ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #28)
>> As I've said before, the parallelization of ms-sysv.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
--- Comment #40 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #39 from simon at pushface dot org ---
[...]
> Updated patch posted here; working on gcc-patches@ submission.
Thanks for the analysis and the patch. I'll give
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
--- Comment #42 from ro at CeBiTec dot Uni-Bielefeld.DE ---
Just for the record: at r249012 (i.e. before the patches causing PR
bootstrap/81033), I managed to successfully bootstrap
x86_64-apple-darwin16.6.0, x86_64-apple-darwin11.4.2, and
i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759
--- Comment #33 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #32 from Daniel Santos ---
> Created attachment 41533
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41533&action=edit
> 41532: proposed fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759
--- Comment #34 from ro at CeBiTec dot Uni-Bielefeld.DE ---
One more data point: I tried to run the ms-sysv.exp tests on
x86_64-apple-darwin and failed initially:
FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -O2 "-DGEN_ARGS=-p0"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759
--- Comment #35 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> In all cases, I get link errors:
>
> Excess errors:
> Undefined first referenced
> symbol in file
501 - 600 of 1428 matches
Mail list logo
