https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Rainer Orth ---
> I see similar errors (100 libstdc++ tests FAILing with excess errors) on
> Solaris, both sparc and x86.
The Solaris testsuite fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Iain Sandoe ---
> unfortunately, (or ...) I Have not succeeded in reproducing this - so will
> need
> some help to identify what's being done
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from Iain Sandoe ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #7)
[...]
>> I guess so: cfarm216 is current Solaris 11.4/SPARC, the sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Iain Sandoe ---
> (In reply to Rainer Orth from comment #5)
>> The new test causes a SIGBUS on 32-bit Solaris/SPARC (sparc-sun-solaris2.11):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116653
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Thomas Koenig ---
> Is there an effective target for the test suite that only runs
> the tests on little-endian targets?
Sure: there's le. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116500
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from Andrew Pinski ---
> (In reply to andi from comment #7)
>> Thanks. Updated patch. This one seems obvious so I'll commit soon.
>>
>&g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116500
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Andi Kleen ---
> Do you have the dump file from tree-vect?
Already attached.
> I guess it just doesn't vectorize something here.
>
> The r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116470
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Bernd Edlinger ---
> Created attachment 58991
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58991&action=edit
> proposed patch
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116427
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Pierre-Emmanuel Patry dot com> ---
> (In reply to Rainer Orth from comment #0)
>
>> I wonder what the way forward is here: just wait for g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87589
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #12 from Ian Lance Taylor ---
> Sure, we can do that patch for now. Thanks. unsupported is fine too.
I've posted the patch now
https://gcc.gnu.org/pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98678
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Jonathan Wakely ---
> This test is a bit tricky. The whole point is to check that performance of one
> operation is acceptable compared to a baseline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87589
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Ian Lance Taylor ---
> It does work for me on x86_64 GNU/Linux. The big stack allocation is handled
> by the split-stack support.
I think I see what&#x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112593
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Jonathan Wakely ---
> (In reply to Rainer Orth from comment #1)
>> The test also FAILs on Solaris 11.4, both sparc and x86, 32 and 64-bit.
>&g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641
--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #14 from dave.anglin at bell dot net ---
> On 2024-05-29 8:17 a.m., ro at CeBiTec dot Uni-Bielefeld.DE wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #12 from Hans-Peter Nilsson ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #11)
[...]
>> * sparc64-unknown-linux-gnu (again, c and c++ only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115304
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Richard Biener ---
> It should only need vect32 - basically I assumed the target can compose the
> 64bit vector from two 32bit elements. But it might be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114434
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Iain Buclaw ---
> I see the test is pointer + 64-bit int. Is this UB on 32bit pointer
> platforms?
You're right: I only see the failure when d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Hans-Peter Nilsson ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #9)
>> > --- Comment #8 from ro at CeBiTec dot Uni-Biele
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115294
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE ---
I've identified the problem and tested a patch. Will commit shortly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #6 from Hans-Peter Nilsson ---
[...]
>> versions.) BTW, it'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Hans-Peter Nilsson ---
> BTW, I see the target list says sparc*-sun-solaris2.11 which seems a cutnpasto
> from some ancient template: that particular v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Hans-Peter Nilsson ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #2)
>
>> You should use cfarm216 instead: it's way faster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
[...]
> Aldy, when investigating PR ipa/114985, got along with just
>
> configure &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Hans-Peter Nilsson ---
> Sorry. I bet something in reorg actually uses a barrier insn as a reference.
> I'll revert those three patches unless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #12 from dave.anglin at bell dot net ---
> It will be a few days before I can test. I've had three hard drives fail on
> my
> main hppa
> system i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115270
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Eric Botcazou ---
> Created attachment 58304
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58304&action=edit
> Tentative fix
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115031
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
I've done some digging now, comparing mmap calls on Solaris/i386 and
Solaris/SPARC (counts and sizes each):
i386:
2 4096
7 8192
5 16384
7 32768
4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115208
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Andrew Macleod ---
> Created attachment 58287
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58287&action=edit
> proposed patch
>
&g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115211
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Richard Biener ---
> This was done on purpose, you can use -help=optimizers now I think.
The thread I cited rather suggested is was removed because Martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114148
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Hongtao Liu ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #3)
[...]
> uoops, does below patch fix the testcase on Solaris/x86?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114148
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
To investigate further, I've added comparison functions to a reduced
version of pr106010-7b.c, with
void
cmp_epi8 (_Complex unsigned char* a, _Complex unsigned char* b)
{
for (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641
--- 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 Jonathan Wakely ---
>
>> It's possible that all the lam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57025
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Alan Coopersmith ---
> While Solaris 11.3 support has been dropped from gcc now, Jonathan Perkins
> from pkgsrc found that just removing the defi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Jonathan Wakely ---
> It's possible that all the lambda frames are inlined, or skip+2 in
> stacktrace.cc causes us to skip real frames that we s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114072
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from rguenther at suse dot de ---
[...]
>> I think the best we can do then is
>>
>> /* { dg-skip-if "PR tree-optimization/114072&qu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114072
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Richard Biener ---
> Hmm, is solaris-sparc big-endian? It seems so. That makes the bitfield
It is indeed.
> access require a VnQImode logical right s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115168
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Eric Botcazou ---
> Created attachment 58255
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58255&action=edit
> Tentative fix
Both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115106
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Eric Botcazou ---
>> as of r15-644, Ada bootstrap succeeded on i686-darwin9 and 17.
>
> Great!
Same on i386-pc-solaris2.11.
>> I do not kno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115133
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Eric Botcazou ---
> Created attachment 58230
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58230&action=edit
> Tentative fix
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115133
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Eric Botcazou ---
> Created attachment 58229
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58229&action=edit
> Tentative fix
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115133
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> until one runs into
>
> s-oslock.ads:83:03: (style) bad indentation [-gnaty0]
> make[6]: *** [../gcc-interface/Makefile:306: a-undesu.o] Error 1
>
> No idea what&#x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #31 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #29 from Aldy Hernandez ---
[...]
> Ok, what's the minimum configuration I need to build here?
>
> srcdir/configure --build=sparc-sun-solaris2.11
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #27 from Aldy Hernandez ---
> This is in cfarm216.cfarm.et:
>
> aldyh@s11-sparc:~/bld/clean$ hostname
> s11-sparc.cfarm
> aldyh@s11-sparc:~/bld/clean
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #25 from Aldy Hernandez ---
> prange has been enabled again, after testing on x86-64 and ppc64le linux.
> Aarch has no space to run tests on the compile farm,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115066
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Tom de Vries ---
> (In reply to Rainer Orth from comment #10)
[...]
>> I wonder how best to handle this: just skip the test on sparc*-sun-solaris2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113719
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Hongyu Wang ---
[...]
> Could you try the attachment and see if the error was solved? I tested with
I just bootstrapped with the patch included on i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107750
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
When I hack locally to avoid the indirection in the
definitions of the SOCK_* constants, only two gcc.dg/analyzer/fd-*.c
tests FAIL on Solaris:
FAIL: gcc.dg/analyzer/fd-access-mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107750
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
I think I've found what's going on: really has
#if !defined(_XPG4_2) || defined(__EXTENSIONS__)
#ifndef NC_TPI_CLTS
#define NC_TPI_CLTS 1 /* must
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112959
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Gerald Pfeifer ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #6)
>> What's there looks good to me.
>
> Cool, thank y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #12 from Aldy Hernandez ---
> Created attachment 58168
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58168&action=edit
> proposed patch in te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #16 from Aldy Hernandez ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #14)
>> > --- Comment #13 from Aldy Hernandez ---
>> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #13 from Aldy Hernandez ---
> BTW, I'm waiting for a review, or at least a nod from a C++ savvy person here:
>
> https://gcc.gnu.org/pipermail/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112959
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Gerald Pfeifer ---
> Rainer, do you think the three changes I made - and hence the current
> state of install.texi on trunk - address all the issues you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Andrew Pinski ---
> If Aldy does not fix it by Saturday, I will give the union a try then. I will
Great, thanks. Your alignas patch also worked fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113706
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #13 from Jason Merrill ---
> Should be fixed now.
It is indeed. Thanks a lot.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112958
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Gerald Pfeifer ---
> FreeBSD i386 is on it's way out: FreeBSD 14 is the last series supporting
> it; FreeBSD 15 is dropping support for it.
Ah, I w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
"dmalcolm at gcc dot gnu.org" writes:
> --- Comment #11 from David Malcolm ---
> Thanks. I've been working on this on cfarm216; I have a messy set of patches
&g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from David Malcolm ---
> Sorry about this.
>
> Is there a machine in the compile farm I can test this on?
Sure, both cfarm215 (Solaris/x86) and cfarm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #17 from Eric Botcazou ---
[...]
>>> The sparc64-unknown-linux-gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from Eric Botcazou ---
>> The sparc-sun-solaris2.11 bootstrap (both multilibs) has just completed
>> successfully without regressions.
>>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #14 from Eric Botcazou ---
>> Do you happen to have some spare c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #14 from Eric Botcazou ---
> OK, thanks, let's go ahead for Solaris then, but I agree that we'd better do
> nothing for other platforms at this poin
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
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 an
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-o
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 now.
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 ...
T
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-9193-
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 encodi
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: returning 0 fo
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 f
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
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 SD
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
>> w
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-s
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&action=edit
> gcc14-pr114007.pa
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
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 maintain
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
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 bui
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
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 mem
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
Gr
1 - 100 of 1180 matches
Mail list logo
