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 thos
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 wanted
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&action=edit
> patch under test
>
&g
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&action=edit
> Proposed fix v2
>
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 te
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.Unsign
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 o
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 to not w
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 (cfarm21
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.
Fr
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 diff
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 so, ho
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 (I
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
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 mems
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
> operands[
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.
Th
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&action=edit
> The correct proposed
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-optimiz
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 #3
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: hav
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 com
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&action=edit
> patch to use the c
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&action=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 Sparc
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 co
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 anyon
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
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 ena
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110624
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Sandoe ---
> OK. (I do not have enough hardware to install 14 or xc15 at present).
You don't depend on macOS 14 here, fortunately: xc 15 sti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Jonathan Wakely ---
> (In reply to Jonathan Wakely from comment #9)
>> One solution would be to just add the declaration to the header, and a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110483
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from David Malcolm ---
> Thanks for filing this; sorry about the failures.
>
> What's the endianness of the hosts that this is happening on?
Solaris/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #14 from Thomas Schwinge ---
> (In reply to Eric Gallager from comment #12)
>> Note that there's a gnulib module for flock:
>> https://www.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Thomas Schwinge ---
> Resolved for GCC 14. Not planning on backporting to release branches (but
> could, if desired).
Unfortunately not: flock is c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #36 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #35 from Jakub Jelinek ---
> Sorry for wasting your time.
No worries: it's mostly the SPARC box doing the compiles ;-)
> --- a/gcc/tree-inline.cc
&g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #34 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #33 from Jakub Jelinek ---
> Oops, sorry.
> gen_raw_REG (TYPE_MODE (DECL_RESULT (new_fndecl)), 8);
While this compiles, I run into
during IPA pass: inline
In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #32 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #31 from Jakub Jelinek ---
> If the important side-effect is allocation of some GC memory, then perhaps
> (assuming you also see just 5 initialize_cfun calls w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #25 from Jakub Jelinek ---
> Anyway, as I said for the second version, it would be nice to also try
> subvariants:
> // relayout_decl (DECL_RESULT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #25 from Jakub Jelinek ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #24)
>> > --- Comment #23 from Jakub Jelinek ---
>> [...]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #23 from Jakub Jelinek ---
[...]
> Perhaps try to undo my patch in a different way, like
> --- gcc/tree-inline.cc 2023-03-17 18:59:50.226199917 +0100
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #20 from Jakub Jelinek ---
>> Tried valgrind on the cross d21 on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #20 from Jakub Jelinek ---
> Tried valgrind on the cross d21 on x86_64 and didn't see anything.
> Perhaps modify the makefiles such that it uses -fdum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #16 from Jakub Jelinek ---
> Used
> PATH=/export/home/jakub/gcc-11-inst/bin:$PATH
> LD_LIBRARY_PATH=/export/home/jakub/gcc-11-inst/lib/ CC='gcc
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #15 from Jakub Jelinek ---
> So, after installing gcc 11 I've tried
[...]
> Undefined first referenced
> symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #12 from Jakub Jelinek ---
> BTW, I have also backported the r13-6739 commit to 12 branch in r12-9293, does
> that branch fail to bootstrap too?
I usually tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #13 from Jakub Jelinek ---
> I found I could perhaps use gcc211 on CompilerFarm to try to reproduce it,
> currently building GCC 11 for working GDC ther
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #7 from Jakub Jelinek ---
>> No luck reproducing this using a cros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Jakub Jelinek ---
> No luck reproducing this using a cross.
Ok, so I'll continue with the reghunt.
> So, could you please attach -fdump-tree-optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
"jakub at gcc dot gnu.org" writes:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
>
> --- Comment #3 from Jakub Jelinek ---
> Can you find out the gdc an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Jakub Jelinek ---
> Is that with -g vs. non--g?
> Could be NEXT_INSN vs. next_nondebug_insn in combine_reload_insn.
No, it's just -fno-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109125
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from CVS Commits ---
> The master branch has been updated by Gaius Mulley :
>
> https://gcc.gnu.org/g:f231bca93ca92f6fd55de6fbe4bf8935f9ec558a
>
&g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109125
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Gaius Mulley ---
> Created attachment 54675
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54675&action=edit
> Proposed fix v3
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109125
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Gaius Mulley ---
> readreal.mod requires the input file testnumber to be in the same directory as
> the executable invocation.
>
> Or manually cre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109125
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Gaius Mulley ---
[...]
> Version 2 of the patch catches some more cases found in the iso libraries.
I've tried that one last night and most of the f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108956
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Gaius Mulley ---
> Do the above fixes resolve this PR ?
The revised version did indeed. I'd included it in last night's
bootstraps and everythi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108956
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Gaius Mulley ---
> The hand built modules were not changed to include the libname. (UnixArgs,
> ldtoa, dtoa for the tool pge). The patch corrects the h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Andrew Pinski ---
> (In reply to Andrew Pinski from comment #2)
>> Confirmed.
>> The following builtins are missing from the go front-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108344
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE ---
To gather more information, I've tried a -g3 -O0 build. The failures
still occur, but the failure mode is slightly different: all the 64-bit
tests in gm2/iso/pass now SEGV in c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106072
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #18 from ktkachov at gcc dot gnu.org ---
> (In reply to Richard Biener from comment #17)
>> Fixed(?)
>
> Yes on aarch64, thanks!
Same on sparc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107807
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Rainer Orth ---
> It did in last night's Solaris bootstraps (sparc and x86). macOS bootstraps
> are
> super-slow, so I'll wait for t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Jakub Jelinek ---
> Created attachment 53953
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53953&action=edit
> gcc13-pr107815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107817
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Jonathan Wakely ---
> Native configuration is sparc-sun-solaris2.11
[...]
> PASS: std/format/functions/format.cc (test for excess errors)
> PASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Jakub Jelinek ---
> The 1e+202L * __DBL_MAX__ num
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107233
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Gaius Mulley ---
> ok, thanks for the suggestion. I've changed gcc/configure.ac to use
> AM_PATH_PYTHON and AM_CONDITIONAL:
>
> # Pytho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Jakub Jelinek ---
>> The line before the assertion failure is
>>
>> 1.18973e+4932 1e+4932
>> /vol/gcc/src/hg/master/local/libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107814
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Jonathan Wakely ---
> I'm unable to access the Solaris/x86 host in the compile farm (gcc210) so I
> can't test if this fixes it. It pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107814
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Jonathan Wakely ---
> I think I'll push the patch in comment 2 and we can see if it helps :-)
I've just tried it on sparc and x86, 32 and 64-bit:
101 - 200 of 1370 matches
Mail list logo
