https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #12 from Eric Botcazou ---
> Rainer, what's your take on this? Should we proceed and change the ABI on
> Solaris for GCC 14?
I think so, yes:
* Binary comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114454
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Ian Lance Taylor ---
> I'm not sure what is going on here. The test as such does not require a UTF-8
> LANG. That is, I can run the compiler and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112652
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Jakub Jelinek ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #8)
>> FWIW, the iconv conversion tables in /usr/lib/iconv can be regener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
I've now also found p. 3P-10:
%f0 through %f7 Floating-point fields from structure return
(%d0 through %d6) values with a total size of 32 bytes or less
(%q0 and %q4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96147
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
It seems the xfail can go completely now: the test PASSes on both
sparc-sun-solaris2.11 and i386-pc-solaris2.11 (32 and 64-bit) with
diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-32.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113431
--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #23 from Jakub Jelinek ---
> Assuming fixed even on sparc*.
It is. I've missed this one when collecting instances of missing
vect_hw_misalign like PR tree-optimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114155
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Iain Buclaw ---
> Fix to format hexstrings as big endian has been committed from upstream merge.
>
> r14-9505
>
> This should be resolved no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Andrew Pinski ---
> Let me look into that for GCC 15. Note libobjc is not used by many folks even
> the GNUStep folks don't use it any more ...
Thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114154
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #2 from Richard Biener ---
>> possibly "fallout" of r14-9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114154
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Richard Biener ---
> possibly "fallout" of r14-9193-ga0b1798042d033
It's not: I've reverted that patch locally, rebuilt cc1 and re-tested:
the XPASSes remain.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Iain Sandoe ---
> now that boehm-gc is no longer in tree
>
> what should we do with this?
>
> I suppose there could be some more sophi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112652
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Jakub Jelinek ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #6)
>> > --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112652
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #4 from Jakub Jelinek ---
>> Given that C++ says e.g. in https://eel.is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112652
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Jakub Jelinek ---
> Given that C++ says e.g. in https://eel.is/c++draft/lex.ccon#3.1
> that program is ill-formed if some character lacks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110483
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> * out-of-bounds-diagram-3.c gets skipped on that machine due to
> { dg-require-effective-target lp64 }
> "check_cached_effective_target lp64: return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102344
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Gaius Mulley ---
> I'm optimistically changing the version of the bug from 12 to 14 and closing
> it.
Right, that was my intent ;-)
> Feel fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102344
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
Looks good: I've just tested both testcases on i386-pc-solaris2.11 and
sparc-sun-solaris2.11 (both 32 and 64-bit). Everything PASSes just
fine. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107855
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Xi Ruoyao ---
> Hmm, the test contains
>
> "/* { dg-additional-options "-Ofast -mavx" { target avx_runtime } } */"
>
> So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE ---
I'm talking with Oracle Solaris Engineering and they're amenable to
making the int8_t change from char to signed char.
To assess the possible impact, the plan is to compare the public
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Iain Sandoe ---
> so .. if i follow your discussion correctly - neither clang nor gcc finds it
> because it's incorrectly quoted (is that an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Sandoe ---
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers
> should be a symlink to
&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #24 from Jakub Jelinek ---
> (In reply to fxcoud...@gmail.com from comment #19)
>> I haven’t yet tested Xcode 13.3 myself, and have only followed the PRs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #23 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #22 from Iain Sandoe ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #21)
>> > --- Comment #19 from fxcoudert at gmail dot com > com>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #19 from fxcoudert at gmail dot com
> ---
> Hi Rainer,
>
>> Thanks a lot for the patch. I've now re-bootstrapped trunk on macOS 14
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from Joseph S. Myers ---
> The tests that GCC's internal notion of the types agrees with the headers are
> in gcc.dg/c99-stdint-5.c and gcc.dg/c99-stdint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from Jakub Jelinek ---
> Created attachment 57483
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57483=edit
> gcc14-pr114007.patch
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450
--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #15 from Jonathan Wakely ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #14)
>> * When checking clang, there were more surprises:
&g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #7 from Jonathan Wakely ---
>> (In reply to Jonathan Wakely from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Jakub Jelinek ---
> Or convince Oracle to change it (again, an ABI break).
I can try, but don't hold your breath.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Jonathan Wakely ---
> It's technically an ABI break, since void f(int8_t) would mangle differently.
> It probably wouldn't affect much in practice,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Jonathan Wakely ---
> (In reply to Jonathan Wakely from comment #1)
>> I assume that int8_t is char on Solaris, rather than signed char?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Sandoe ---
> Is this a clang extension (handling clang::x with -std= < c23)?
I can't tell: I was waiting for the preprocessor maintainers t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60045
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Richard Biener ---
> There was some recent fixes (in GCC 14) addressing scheduling related issues.
> Do these testcases still pose problems?
I've check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910
--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #14 from Richard Biener ---
> The regression should be fixed, can you check we're now no longer slower on
> trunk? (either use a release checking build or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Andrew Pinski ---
>>Configure with --enable-checking=release to disable checks.
I'm seeing the same slowdown with release builds of GCC 12.3.0 and
13.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113785
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
Upstream pull request posted: https://github.com/llvm/llvm-project/pull/81588
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113785
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE ---
I've found what's going on: as described in Solaris makecontext(3C), the
function changed starting with Solaris 10:
NOTES
The semantics of the uc_stack member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104739
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Iain Buclaw ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #5)
> Can give it a go.
>
> https://github.com/dlang/dmd/pull/16136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104739
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Rainer Orth ---
> I wonder how to handle this: while DejaGnu has an ucn effective-target
> keyword,
> the gdc.test testsuite doesn't use those at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
When looking at the 64-bit libgcc_s.so.1 on both Solaris/x86 and
Linux/i686, I noticed that all the new GCC_14.0.0 symbols from
libgcc-glibc.ver (and now libgcc-sol2.ver) have been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113706
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from H.J. Lu ---
> On Solaris, when compiling this
>
> #include
>
> __attribute__ ((weak))
> int
> f (int a)
> {
>return memchr (&qu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Lewis Hyatt ---
> Oh interesting. So the purpose of this test was just to record that GCC
> outputs
> incorrect locations for this case, I wan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Iain Sandoe ---
> (In reply to Rainer Orth from comment #8)
>> Again tested on macOS 11 (unchanged) and 14. On the latter, the previous
>> f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112861
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Sandoe ---
> Created attachment 57201
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57201=edit
> patch under test
>
> w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113559
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Gaius Mulley ---
> Created attachment 57205
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57205=edit
> Proposed fix v2
>
> Corre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113558
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Robin Dapp ---
> Would you mind giving the attached patch a try? I ran it on riscv and power10
> so far, x86 and aarch64 are still in progress.
Sure:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Iain Sandoe ---
>> > Now I have a concern that we have instances of -Bpath/to/libsomething/.libs
>> > that are present to allow for specs sub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Jonathan Wakely ---
> I pushed a slightly different change, but it should be equivalent. Please
> reopen if I messed it up :-)
The variant worked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
David, can you provide some help or suggestions here? I'm completely
lost in the analyzer code. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Iain Sandoe ---
> OK. So I realise the reason you see this and I wasn't: I have the habit of
> installing before running the testsuite. When I test un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Jonathan Wakely ---
> I assume that int8_t is char on Solaris, rather than signed char?
Indeed. AFAIK char being signed goes back to SysVr4 at least (a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Sandoe ---
> which Xcode version produces this?
15.1. Btw., I only see those failures on macOS 14, not earlier versions.
> on Darwin23 with XC1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Sandoe ---
> this appears to be fixed; I get clean fortran testsuite results on (x86_64)
> Darwin21 and Darwin23. Please could you check and eit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112958
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Eric Botcazou ---
> Someone motivated enough should add a specific libgnat/s-dorepr__freebsd.adb
> unit where Rep64 is an array of two Interfaces.Un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112958
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Eric Botcazou ---
> The code is the same on the 13 branch though, does it compile there?
So far, I had only tried gcc 11.4.0 (where the code compiles) and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113140
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Rainer Orth ---
> It's also helpful to include the cc1plus invocation from g++ -v; that includes
> all you need to reproduce.
The full one is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #38 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #37 from Ian Lance Taylor ---
> Search for this comment in the top-level configure.ac file.
>
> # Disable libgo for some systems where it is known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112917
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Alexandre Oliva ---
> Nevermind, I've managed to log into the cfarm machines running solaris/sparc.
Good: while the Solaris 11.3/SPARC system (cfarm211)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112728
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Jorn Wolfgang Rennecke ---
> (In reply to Rainer Orth from comment #0)
>> The gcc.dg/scantest-lto.c FAILs on quite a number of targets:
> ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112729
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Hongyu Wang ---
[...]
> Hi Rainer, can you help verify if the change make these test pass on
> solaris/FreeBSD?
They do on Solaris/x86. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112729
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Hongyu Wang ---
> The cfi scan fails was caused by -fno-omit-frame-pointer which force push the
> frame pointer first and the cfi info become
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112563
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #10 from Jakub Jelinek ---
>> (In reply to r...@cebitec.uni-bielefe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112562
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> Should be fixed now I believe.
It is indeed: thanks for the quick fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112652
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Jakub Jelinek ---
> Strange. On cfarm211 which is
> SunOS gcc-solaris11 5.11 11.3 sun4u sparc SUNW,SPARC-Enterprise
> the test passes.
Can you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112671
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Arsen Arsenović ---
> hm, actually, I think I confused reports - sorry.
>
> do you know if this worked a short while ago? and if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112671
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Arsen Arsenović ---
[...]
> I will restore the modifications in the shared tree with the few other patches
> I mentioned on the GCC ML recently soon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112563
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Jakub Jelinek ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #9)
[...]
>> I've now come up with an alternative. It's a bit ugly,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112563
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from Jakub Jelinek ---
> So, shall we go with
> --- libsanitizer/sanitizer_common/sanitizer_redefine_builtins.h.jj
> 2023-11-15 12:45:17.359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106120
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Hans-Peter Nilsson ---
> (In reply to Rainer Orth from comment #10)
>> Since 20230106, this test produces an XPASS, according to gcc-testresults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112563
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Jakub Jelinek ---
> Note, following patch
[...]
> passed bootstrap/regtest for me on x86_64-linux and i686-linux and didn't
> create any new memset/me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112562
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Jakub Jelinek ---
> find -type f | xargs grep %function
> ./interception/interception.h: ".type "
> SANITIZER_STRINGIFY(TRAMPOLINE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112523
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Jakub Jelinek ---
> Trying now
> 2023-11-14 Jakub Jelinek
>
> * config/i386/i386.md (3_doubleword_lowpart): Move
> operan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112523
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Andrew Pinski ---
> (In reply to Rainer Orth from comment #0)
>> Between 20231110 and 20231123, Solaris/x86 bootstrap got broken: both the 32
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from ibuclaw at gcc dot gnu.org ---
> Upstream PR https://github.com/dlang/dmd/pull/15778
Excellent, thanks a lot for the blindingly fast fix.
I'll file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from ibuclaw at gcc dot gnu.org ---
> Based on what I see here, this patch to core.cpuid should be sufficient to fix
> loop and not introduce any change in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from ibuclaw at gcc dot gnu.org ---
> (In reply to Rainer Orth from comment #0)
>> This affects all DMD-based versions of GDC, while the previous C++-based
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111010
--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #15 from Uroš Bizjak ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #13)
>> > --- Comment #11 from Uroš Bizjak ---
>> > Created a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111010
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #12 from Uroš Bizjak ---
> gcc-13 version:
[...]
Same here: successfully regtested on i386-pc-solaris2.11; reduced and
full testcase compile without issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111010
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Uroš Bizjak ---
> Created attachment 55772
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55772=edit
> The correct proposed patc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111010
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Richard Biener ---
>
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index f3a3305ac4f..d38b9d764d8 100644
> --- a/gcc/conf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111010
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
I've just completed a reghunt which identified
commit 4e0b504f26f78ff02e80ad98ebbf8ded3aa6ffa1
Author: Richard Biener
Date: Tue Jan 10 13:48:51 2023 +0100
tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110955
--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #7 from Rainer Orth ---
>> (In reply to Petr Sumbera from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110955
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #12 from Petr Sumbera ---
>> (In reply to Petr Sumbera from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110955
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #12 from Petr Sumbera ---
> (In reply to Petr Sumbera from comment #9)
>> (In reply to r...@cebitec.uni-bielefeld.de from comment #8)
>> > > wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110955
--- 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 Petr Sumbera ---
>> (In reply to r...@cebitec.uni-bielefeld.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110955
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Petr Sumbera ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #8)
>> > I'm not sure if we taked about this before: have you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
[...]
> I'm currently running a full i386-pc-solaris2.11 bootstrap.
... which just complete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110955
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Rainer Orth ---
> (In reply to Petr Sumbera from comment #3)
>> (In reply to Andrew Pinski from comment #1)
>> > Are you sure this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from Thomas Neumann ---
> Created attachment 55715
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55715=edit
> patch to use the corre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110779
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from Gaius Mulley ---
> Created attachment 55703
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55703=edit
> Proposed fix (addendum)
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869
--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #16 from Stefan Schulze Frielinghaus ibm.com> ---
> Turns out that my dejagnu foo is weak ;-) I came up with a wrong target
> selector. Should be fixe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #12 from Stefan Schulze Frielinghaus ibm.com> ---
> I have done a test with a cross-compiler and it looks to me as if we need -O2
> instead of -O1 on Sp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #1 from Andrew Pinski ---
>> Can you test the patch in bug 110867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Andrew Pinski ---
> Can you test the patch in bug 110867 comment #1 to see if fixes the issue here
> too?
Sure: sparc-sun-solaris2.11 bootstrap in progress...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110787
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Roger Sayle ---
> I'm bootstrapping with --enable-languages=all to investigate what's going on.
> I'll revert the patch once I (or anyone) ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110651
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #1 from Iain Sandoe ---
>> (In reply to Rainer Orth from co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from Jonathan Wakely ---
> I hope this is fixed now.
It is indeed. Thanks a lot.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110651
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Sandoe ---
> (In reply to Rainer Orth from comment #0)
>> When bootstrapping current trunk on macOS 14.0 beta 3 with Xcode 15 beta 4,
>> ev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110624
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Iain Sandoe ---
> Here, I will test on some earlier Darwin versions - but would welcome
> confirmation that it fixes the XC15 issue.
I've done that now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110624
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Iain Sandoe ---
> actually, we already have a config test for -platform_version, which is what
> clang passes to ld. First, I'll take a look at
1 - 100 of 1308 matches
Mail list logo
