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=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. However,
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 tests were
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 .localalias
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 on
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 ltrans0.ltrans_args
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=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 still exactly as
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 the only
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 completed Solaris
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
Unfortunately not: there are
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. Fixed thusly.
>
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 different
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
>
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 --enable-languages=all
>
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 platform
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:
>
> make check-gcc-c
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 different for you?
>
> It
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 printf here.
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 test the attached
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=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 by
[...]
> Please try this.
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, though.
>> Maybe
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=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=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-solaris2.11
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++,ada
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 another
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-linux-gnu
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
>
> Untested fix.
I've now
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=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=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=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 test now
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
> building
> # multilib. For
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 there is an ICE – is
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-solaris2.11
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=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:
>>
>
> Sorry, I've just been
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, the error vanished
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
configure with
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 the bulk of main
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 patches
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 allowed: "trailing
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 also salvages the
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 for
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, particularly around
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 (ptr != MAP_FAILED)
> {
>
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 build using the
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 with the PR
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 a previously
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 checked.
> So it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102838
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from Jakub Jelinek ---
> Ok, so, first question, is GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC defined in your
> case?
It is since all of HAVE_ALIGNED_ALLOC,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102838
--- 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 Jakub Jelinek ---
>> Does the committed patch fix the issue on Solaris?
>
> I'll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102874
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from H.J. Lu ---
> Does libffi 3.4.2 work on Solaris? If yes, why doesn't it work in gcc?
It does when gcc is configured with gas, but doesn't when configured
with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102344
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Gaius Mulley ---
> apologies if this is the wrong way to mention a status change. (Is this
> done on bugzilla? I've looked and cannot see how to change its
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102838
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Jakub Jelinek ---
> Does the committed patch fix the issue on Solaris?
I'll see after tonight's bootstrap. The original one attached to the PR
fixed only a few
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
commit
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 none in the cfarm
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/tree-vrp.c b/gcc/tree-vrp.c
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102944
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Martin Sebor ---
> I don't see any of the FAILs or XFAILs listed in comment #0 with cross
> compilers for any of the Targets. Can this report be resolved?
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98076
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Francois-Xavier Coudert
> ---
> Hi Rainer,
>
> Apologies for that, apparently I got confused between the keyword and the
> macro
> form. Can you confirm that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102838
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #13 from Jakub Jelinek ---
> Created attachment 51807
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51807=edit
> gcc12-pr102838-2.patch
>
> Does this patch fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102838
--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #15 from Jakub Jelinek ---
> Ah, bet Solaris aligned_alloc relies on:
> "the value of size shall be an integral multiple of alignment"
> (glibc aligned_alloc doesn't).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103042
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Tamar Christina ---
>> gcc/testsuite/gcc.dg/vect/complex/fast-math-bb-slp-complex-add-pattern-double.c
>
> This one running is odd, it's guarded by vect_double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103042
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from CVS Commits ---
[...]
> testsuite: change vect_long to vect_long_long in complex tests.
>
> These tests are still failing on SPARC and it looks like this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103041
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from luoxhu at gcc dot gnu.org ---
> Could you please verify whether it is caused by r12-4818 instead of r12-4819?
> r12-4819 is a NFC patch which seems more unlikely,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102949
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Richard Biener ---
> Hm, I tried --target=sparcv8-sun-solaris2.11 but that seems to fail to
> reproduce any vectorization with -O2 -ftree-vectorize. If I add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102837
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Andrew Pinski ---
> (In reply to Andrew Pinski from comment #1)
>> It is one of the following:
>> g:8088a33df5f62fd6416fb8cb158b791e639aa707
>
> Most likely this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102946
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Richard Biener ---
> Very likely might be fixed with properly aligning the data like with adding
>
> a = __builtin_assume_aligned (a, __BIGGEST_ALIGNMENT__);
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102954
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Richard Biener ---
> It was likely the vect_worthwhile_without_simd_p changes where we might now
> vectorize this loop using (unaligned) 'int'.
>
> Can you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102944
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from CVS Commits ---
> The master branch has been updated by hongtao Liu :
>
> https://gcc.gnu.org/g:2e560abff4294639a0fcf666994c30fb2f00a324
>
> commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102831
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Thomas Schwinge ---
> Are you guys able to reliably reproduce the problem? Asking because for me,
> it
> was very flaky: some (seemingly random) change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102949
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Richard Biener ---
> Fixed (by inspecting assembly).
Indeed: the execution tests PASS again. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103577
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Iain Buclaw ---
> FYI, with darwin, I've only been using the most recent commit in
> releases/gcc-11 for testing as there have been a number of issues exposed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103577
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> I recently tried to build master on Darwin 11 with gcc 11.0.1. That's the
> first
> release to build gdc, and while libphobos isn't marked as supported in
> libphobos/configure.tgt,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103577
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Iain Buclaw ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #1)
>> I cannot yet tell if this is just an issue with GCC 11.1.0 gdc or
>> libphobos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103528
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Iain Buclaw ---
> (In reply to Rainer Orth from comment #0)
>> * toplevel configure needs to make certain that the bootstrap gdc can compile
>> *and link* some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090
--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE ---
The last time I saw the failure on Solaris was on 20210106.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103577
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #3 from Iain Buclaw ---
>> FYI, with darwin, I've only been using the most recent commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Jakub Jelinek ---
> That is weird.
> We have:
> ieee_arithmetic.lo: ieee/ieee_arithmetic.F90 ieee_exceptions.lo
> dependency and ieee_exceptions.mod is created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Jakub Jelinek ---
> Created attachment 52176
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52176=edit
> gcc12-pr104006.patch
The patch lists gcc as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Jakub Jelinek ---
> Created attachment 52177
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52177=edit
> gcc12-pr104006.patch
>
> Updated patch.
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Jakub Jelinek ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #3)
>> Really strange. If kinds.h were missing completely at that point, I'd
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Jakub Jelinek ---
> Created attachment 52180
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52180=edit
> gcc12-pr104006.patch
>
> So yet another version.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006
--- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #21 from Jakub Jelinek ---
> That is make -j48 from where?
> Toplevel, or the libgfortran build dir, or toplevel make -j48
> all-target-libgfortran or make -j48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #18 from Jakub Jelinek ---
> Some of the patches before #c13 were just buggy and could cause such errors.
> Do you see the above on vanilla trunk?
I do.
> Can you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006
--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #24 from Jakub Jelinek ---
> Created attachment 52184
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52184=edit
> gcc12-pr104006.patch
>
> Fix. I've added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006
--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #16 from Jakub Jelinek ---
> The version file is now fixed.
Thanks.
> Can you perhaps rm -rf the libgfortran build directories and retry, if it
> wasn't some weird
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006
--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> A quick parallel make configure-target-libgfortran all-target-libfortran
> completed without issues. I've just fired off full bootstraps with that
> patch before going to bed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104781
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from H.J. Lu ---
> Created attachment 52563
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52563=edit
> A patch
>
> Try this.
That patch certainly did fix the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104781
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from H.J. Lu ---
> Created attachment 52567
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52567=edit
> The v2 patch
>
> Please test this patch.
This version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104732
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Roger Sayle ---
> This should now be fixed on mainline. Rainer please let me know if you notice
> any remaining issues on solaris/x86.
I've now run bootstraps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104198
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from Jakub Jelinek ---
> Is this fixed now?
It is: SPARCv9 bootstrap is back to normal.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102841
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Thomas Schwinge ---
> Can't (easily) test due to corresponding Solaris/Darwin system
> non-availability, but I think I understand the issue, and it should now be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from Jakub Jelinek ---
> Does libgomp.fortran/pointer2.f90 still FAIL?
It does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Iain Buclaw ---
> That's interesting. I've just done a build of
> 54ef95cc4d1f3f2cde7c1f13250f889ffb81ca75 (20220301) and I get the same
> comparison failure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102831
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Richard Biener ---
> Assuming fixed.
I can't tell for certain because I had a local patch in my tree
selectively disabling the warnings to avoid random
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104781
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Jakub Jelinek ---
> I believe this should now be fixed, Rainer, can you please confirm?
It is: last night's i386-pc-solaris2.11 bootstraps were fine without
1 - 100 of 356 matches
Mail list logo
