https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from H.J. Lu ---
> The stack isn't properly realigned. Please find out which commit caused this.
Sure: a reghunt identified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #12 from Aldy Hernandez ---
> (In reply to Aldy Hernandez from comment #11)
>> This looks mighty suspicious ;-)
>>
>> diff --git a/gcc/tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Aldy Hernandez ---
> (In reply to David Edelsohn from comment #1)
>> Confirmed.
>
> I don't have access to an i386-solaris box.
... and there's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102426
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Andrew Pinski ---
> It seems like only this feature which libtool gets wrong.
>
> There are other places where lt_cv_prog_gnu_ld/with_gnu_ld is c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101772
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from H.J. Lu ---
> A patch is posted at:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576697.html
I gave it a quick try by restarting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100787
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Aldy Hernandez ---
> Note, this is still broken so I am leaving the PR open. I will address this
> next week.
FWIW, I can bootstrap both i386-pc-so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #35 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #34 from Tobias Burnus ---
> What's actually the status of the PR – I mean on both powerpc64*-linux-gnu,
> sparc*-*-*.
>
> The summary states that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100559
--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #14 from Petr Sumbera ---
[...]
> It has following comment:
>
> # We want sparc/i386 to match locations for their 32 bit support when
> buildin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100452
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Richard Biener ---
> Hmm, I'm not sure if it works, but at least the FE accepts it. Does
[...]
> fix it on sparc? At least on x86 the A arguments in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100467
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Bernd Edlinger ---
> should be fixed now.
It is: tested on i386-pc-solaris2.11 (and, for good measure, on
sparc-sun-solaris2.11).
Thanks for the quick fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90834
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from Iain Sandoe ---
> ping for closing this - or new information otherwise.
I haven't reread the whole thread, but AFAICS one still needs to
con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
--- Comment #23 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #22 from Vladimir Makarov ---
> Could you check the patch on the failed bootstraps. I have no access to
Unfortunately, it didn't help. I continue to revert the p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98920
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #18 from Jakub Jelinek ---
> Indeed.
> But perhaps instead of adding new effective target tests, in this case it
> could
> be resolved by:
[... wrapping t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #12 from Rainer Orth ---
> Unfortunately, I'm still seeing the ICE reported in PR target/99432 on
> i386-pc-solaris2.11.
While I could build yesterday's tree wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from David Malcolm ---
> Re comment #10: I just tested unknown-fns-4.c and malloc-vs-local-1b.c 500
> times each on a --target=i386-pc-solaris2.11 bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99385
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Martin Liška ---
> Thanks for the report and the analysis.
> The code should not segfault as we do:
>
> if (pt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98528
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Nathan Sidwell ---
> do you have preprocessed source for those other failing platforms? my guess
> is
> they have different system headers, particu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98528
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Richard Biener ---
> Any update?
At least on Solaris, the failures are gone since 20210113.
However, gcc-testresults still shows similar failures fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #13 from Patrick Palka ---
[...]
> So:
>
> 1. The hex-form conversion specifier doesn't trim trailing zeroes.
Which according to ISO C 2017, p.228, is allowe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Patrick Palka ---
> I posted a patch at
> https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565726.html that does
> this, but a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98910
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Iain Buclaw ---
> (In reply to Rainer Orth from comment #2)
>> Unfortunately, even with your patch Solaris bootstrap is still broken:
>>
>
&g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98910
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
On top of the missing locale_t definition, the other issue I'd reported
is also still present:
/vol/gcc/src/hg/master/local/libphobos/libdruntime/core/thread/osthread.d:1468:12:
error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98531
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
Nathan,
last night I've tried the patch you posted on both i386-pc-solaris2.11
and sparc-sun-solaris2.11, with mixed results:
* The new g++.dg/modules/pr98531_* testcases PASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Mark Wielaard ---
> (In reply to Rainer Orth from comment #0)
>> However, when I switched to
>> the freshly released GNU as 2.36 today,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98771
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Jakub Jelinek ---
> Created attachment 50028
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50028=edit
> gcc11-pr98771.patch
>
> Un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98773
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
[...]
> Sure: I'll first try another i686-pc-linux-gnu bootstrap. Solaris will
The i686-pc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98773
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Richard Biener ---
> Patch I am testing (note I couldn't reproduce the issue so it would be nice if
> you can verify the fix).
Sure: I'll first try ano
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98773
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Richard Biener ---
> So I wasn't able to reproduce on a x86_64 host bootstrapping a 32bit
> compiler configured as
>
> --enable-languages=c+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98771
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Martin Sebor ---
> I can't reproduce these failures with my solaris2.11 cross. The dump and the
Please note that the failure only occurs for i386-pc-solar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97299
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Richard Biener ---
> Created attachment 50017
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50017=edit
> patch
[...]
> Rainer, can you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98676
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from H.J. Lu ---
> Created attachment 49966
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49966=edit
> A patch
>
> STV is disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98680
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
I've just ran arrive_and_wait.exe a 1000 times, and (at least so far)
one instance not only didn't complete within the testsuite's 5 minute
timeout, but hang for an hour, so probably
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95021
--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #14 from Richard Biener ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #13)
>> The failures reported in Comment 11 still exist on master, thou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95021
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
The failures reported in Comment 11 still exist on master, though.
Maybe it's too early to remove 11 from the regression list?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95549
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Richard Biener ---
> Is this still a problem?
It was when I last tried in December (cf. PR ada/98171, last two lines).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Patrick Palka ---
[...]
> Thanks for testing! Hmm, that execute failure is surprising. I wonder just
> how much we're diverging from the output of pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #13 from Bernd Edlinger ---
> could someone try this for me?
This worked fine for me, both with -j2 and without. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Bernd Edlinger ---
> I tried to bootstrap with
> GNU ld (GNU Binutils for Ubuntu) 2.24
>
> but still cannot reproduce the reported
> failure l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> The arguments are in a response-file: @outputs.ld1_args
>> maybe that looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Bernd Edlinger ---
> when you leave just one of those tests, you can
> get somewhat more verbose output by using something like that:
>
> m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Bernd Edlinger ---
> It is interesting that some tests are reported failing
> on the x86_64-pc-linux-gnu platform that I also use.
Right: it's not the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Bernd Edlinger ---
> Unfortunately I cannot reproduce.
>
> I configured like this:
> ../gcc-trunk/configure --prefix=/home/ed/gnu/install --enabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98531
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Nathan Sidwell ---
> +FAIL: g++.dg/modules/xtreme-header-2_a.H module-cmi
> (gcm.cache/vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/modules/xtre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98530
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Nathan Sidwell ---
> thanks, this smells like a broken solaris header. unnamed structs and unions
> without typedef-names for linkage purposes are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98315
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Nathan Sidwell ---
> sorry for not getting this right sooner:
>
> b7b6879f0b5: c++: Another solaris header use [PR 98315]
No worries: I've now compl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98315
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Nathan Sidwell ---
[...]
>> Unfortunately not: there are still two instances of the problem:
>
> There is another path to get to a poisoned bcopy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98315
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Nathan Sidwell ---
> I think this is fixed by
> 6ff747f023c 2020-12-16 | c++: Fix (some) solaris breakage
>
> please let me know
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98316
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE ---
Besides, currently libcody.a (and, once this PR is fixed, libsocket and
libnsl) are linked into every backend instead of just into cc1plus. I
believe this should change, just like f951
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96147
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Richard Biener ---
[...]
> For now can you confirm the FAILs persist? I'll have to dig in with a
> cross...
The FAILs (and XPASSes) are stil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98139
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from David Edelsohn ---
> It has nothing to do with the proper way to install GCC on AIX.
Why not? Consider some developer trying to build trunk on his own AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98139
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from David Edelsohn ---
> I bootstrap GCC on AIX with, and the instructions in the CompileFarm wiki
> recommend, --disable-werror.
Ah, I missed that. It's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96129
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Richard Biener ---
> Quite some revs, two vectorizer changes. Do the FAILs still occur?
Both still do.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70358
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Jonathan Wakely ---
> Rainer, what's the status of this one? Are those tests still UNSUPPORTED, or
> now PASSing?
Looking back at old testresults, the t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Jonathan Wakely ---
> Looks like this is still failing for solaris 11:
> https://gcc.gnu.org/pipermail/gcc-testresults/2020-October/610818.html
True.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #27 from Dominique d'Humieres ---
> Is thie PR fixed?
Not at all: I'm still seeing it on sparc*-sun-solaris2.11, and there are
tons of reports for other targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97119
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Ali Bahrami ---
> I added -flive-patching=inline-only-static as suggested by Martin. It didn't
> alter the results I'm seeing. There is still a lot of .l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #19 from anlauf at gcc dot gnu.org ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #14)
>> > --- Comment #13 from anlauf at gcc dot gnu.org --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #13 from anlauf at gcc dot gnu.org ---
> This may lead to a total mess, and I am unable to test it, but can you try:
I just ran bootstraps on both sparc-sun-solar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from anlauf at gcc dot gnu.org ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #9)
>> >> 0x67606b build_round_expr
>> >>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from anlauf at gcc dot gnu.org ---
> (In reply to Rainer Orth from comment #6)
>> The test also FAIL on 64-bit SPARC with an ICE/SEGV:
>>
>> 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94324
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Dominique d'Humieres ---
> Is it a fortran bug or a bug in a Solaris lib?
The latter, I suspect (or rather: the Studio compiler used to build
them). Howeve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96180
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Richard Biener ---
> Hmm, yeah - the testcase assumes the target upps alignment of 'a' a bit from
> its requirement of 'int' ... guess changing a to requi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492
--- Comment #32 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #31 from H.J. Lu ---
>> If this is a Linux-only feature, shouldn't the tests rather be
>> restricted to Linux instead? It certainly also fails on fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492
--- Comment #30 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #29 from H.J. Lu ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #28)
>> > --- Comment #27 from H.J. Lu ---
>> > (In reply to r...@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492
--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #27 from H.J. Lu ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #26)
>> > --- Comment #25 from H.J. Lu ---
>> > -fpatchable-fun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492
--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #25 from H.J. Lu ---
> -fpatchable-function-entry and -mfentry generate special instruction
> sequence at function entry. Does Solaris support such special
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492
--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #23 from H.J. Lu ---
> Do -fpatchable-function-entry and -mfentry work on Solaris?
I don't have the slightest idea what that would mean, and the
descri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95706
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from David Edelsohn ---
> I added Solaris to the list of targets that see the error on line 5. Add it
> wherever your target sees it.
This has almost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96028
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Richard Biener ---
> Do I need some special flags?
The -m64 is crucial: the test PASSes for me for the default -m32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95575
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Buclaw ---
> Ah, for some reason I thought that moving the dejagnu .exp scripts from
> top-level gdc.test to one per each subdirectory would remove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95494
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Martin Liška ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #4)
>> > --- Comment #3 from Martin Liška ---
>> > Is there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95494
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Martin Liška ---
> Is there a compile farm machine I can test it on?
Sure: gcc211 should do the trick.
> Btw. can you please make a brief analysis why
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95494
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Martin Liška ---
> Can you please test the current master?
> This patch could fix it: a04b7410d305800b747963ab940d2b1a602b5ddf
Unfortunately, it doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95413
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from H.J. Lu ---
> I am testing this:
[...]
Seems to work fine: at least configuring and building the 32 and 64-bit
libgomp multilibs now succeeds.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95413
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> How did CET changes add -march=i486 -mtune=i686? Can you bisect to the commit?
Done: the reghunt identified
commit 4c1a5d8b71e29b71e0bc1004480c12c5fc427cb7
Author: H.J. Lu
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94703
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Richard Biener ---
[...]
> Hmm, OK looks like memcpy is not folded, likely because the source is
> not known to be appropriately aligned.
[...]
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92177
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Richard Biener ---
[...]
> which means we are actually vectorizing a multiplication. Like with
> the following. Rainer - can you test this?
[...]
Wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90719
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from ibuclaw at gcc dot gnu.org ---
> (In reply to Rainer Orth from comment #8)
[...]
> Oops, I must have both misunderstood your original bug report (you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91027
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from Iain Buclaw ---
> The commit for it is here.
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98eb7b2ed249537d12004f2c58583140ac25d666
I just noticed t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
[...]
> Fine, thanks. Just FYI, I built binutils master to check if the issue
> also exists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #25 from Iain Sandoe ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #24)
>> > --- Comment #23 from Iain Sandoe ---
>> > unpatched
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Martin Liška ---
>> Can you provide some pointers where to look? I'm totally unfamiliar
>> with this code. Maybe it's easier for you to try th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #23 from Iain Sandoe ---
> unpatched GCC master, gcc-9.x, gcc-8.x and gcc-7.5 work for me with any SDK >=
> Xcode commandline tools 11.3b.
I've recentl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94239
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Jakub Jelinek ---
> Yes, see https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542459.html
> Sorry for that.
I've just applied your patch (the pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Martin Liška ---
> Ah, ok. Can you please do some basic debugging what's hapenning?
Can you provide some pointers where to look? I'm totally unfa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Martin Liška ---
> It will be definitely caused by my g:c8429c2aba80f845939ffa6b2cfe8a0be1b50078.
[...]
> So is the reason usage of ld.gold? Is the defau
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91028
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Jan Hubicka ---
> I believe this was fixed a while ago by adding the loop. It no longer fails
> with -fno-use-linker-plugin. Is it OK on Solaris?
It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93731
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #1 from Jakub Jelinek ---
[...
>> Of course, trying to workaround ke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93961
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Eric Botcazou ---
> Please check that it is really compiled at -O1.
It is: no optimization option beside -O is used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93731
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Iain Sandoe ---
> These systems are EOL so we can't expect any fixes to the systems themselves.
>
> The question is "is the latest imported a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93731
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Jakub Jelinek ---
> So you could just disable asan and keep ubsan (set ASAN_SUPPORTED=no in
> libsanitizer/configure.tgt for a particular darwin O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92002
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Jakub Jelinek ---
> -Wno-error=uninitialized might be more appropriate for the workaround.
In fact one needs both -Wno-error=uninitialized and
-Wno-error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93316
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from David Malcolm ---
> Sorry about the failing tests.
>
> As noted in comment #4, r10-6152-gda7cf663b75513e4d2baf5a579ffcb4f8a61193b
> hope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92303
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Richard Biener ---
> There's no RA commits in that range, further bisection is needed.
Done now. I've found r272742 to be the culprit:
2019-06-27 R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92002
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from Richard Biener ---
> Did this somehow get fixed (the bootstrap?) or require some nonstandard
> configuration?
Not at all. I still cannot make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92391
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Joel Hutton ---
> Weird, I tested on gcc202.
[...]
> # of unsupported tests 2
I see the same when testing this single test individually.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92527
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from rsandifo at gcc dot gnu.org
> ---
> I have a patch for the bb-slp-21.c failure. Are you still seeing the
> bb-slp-div-2.c failure? I can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92391
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Joel Hutton ---
> Hi Rainer
>
> I set up an account with cfarm, and tested on gcc202, the test fails because
> on
> SPARC, no constr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92391
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Joel Hutton ---
> As this fails when it was introduced, and I don't have a SPARC machine to test
> on, I suggest making this XFAIL on sparc.
I'd rat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91027
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Jan Hubicka ---
> Hi,
> this patch triggers another confusion in ipa-devirt.
> It tries to build type inheritnace graph but since D frotnend pro
301 - 400 of 1361 matches
Mail list logo
