https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118314
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Iain Buclaw ---
> I suspect one of them might be this issue
>
> https://github.com/dlang/dmd/issues/20688
Resp. its Solaris equivalent. The other is the gcc/d de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118314
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Iain Buclaw ---
> Changes made to the module itself.
>
> https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=libphobos/src/std/bitmanip.d;h=15211a3a98adab5ab2952bf801a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358
--- Comment #29 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #22 from prathamesh3492 at gcc dot gnu.org ---
> @all: Could you please test it on your machines, and let me know if it causes
> any further issues ? I plan to commit it i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358
--- Comment #20 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #19 from Tobias Burnus ---
> (In reply to Rainer Orth from comment #18)
>> This patch broke Solaris bootstrap when linking libgdruntime.la (both sparc
>> and x86, most lik
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117895
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Jeffrey A. Law ---
> Ugh. libgo + sparc + solaris 2. Hopefully I can find a way to reproduce
> this.
Shouldn't be too hard these days: the cfarm has a Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117697
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
>> Even more strangely, I'd tried an i686-pc-linux-gnu build with
>> --enable-frame-pointer (the Solaris default), which showed the testsuite
>> failures before your patch, but still -f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117697
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Haochen Jiang ---
> Testcase fixed on trunk.
Great, thanks.
> Since I do not have a Solaris machine, I could not to solve the problem on
> Solaris/x86 for:
>
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117698
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Richard Biener ---
> Might be due to PR114189. Alternatively can you check whether --param
> vect-force-slp=0 makes the FAILs go away.
It does indeed for all aff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102296
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
Please Cc me on Solaris bugs from the beginning, otherwise I'm almost
guaranteed to miss them.
That said, where do you see this? (The PR refers to GCC 12.0). As far
as I could find, b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98171
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from dje.gcc at gmail dot com ---
> IBM AIX has changed libintl and older versions are not in the default
> path. There may be other versions installed on the system in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98171
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from David Edelsohn ---
> gcc119 now is AIX 7.3. If this doesn't work it won't be fixed.
How do you mean? What won't be fixed? Ada on AIX 7.2? Ada on AIX 7.3?
Ada o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117170
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Sam James ---
> I think if it's working fine for you, I'm not going to worry about it until I
> have cause to log in again and figure out what I did wrong (which i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117170
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Sam James ---
> Bisecting has been pretty painful so I gave up for now. I ended up hitting
> other comparison failures for a lot of commits in the range.
>
> I als
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 failures boil down
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 differently from y
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 same I use for
>> my
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):
>
> Is this reproducib
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's even documented i
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.
>>
>> diff --git a/gcc/testsuite/gcc.
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 right fix is probably to
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
>
> I would appreciate wh
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 gccrs to be
>> self-contai
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/pipermail/gcc-patche
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. But the defi
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's happening
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.
>> However,
>> the fail
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.cgi?id=111641
>>
>>
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): there are tes
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 that for
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 d21 is a 32-bit bin
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-Bielefeld.DE > > Uni-Bielefel
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'd be nice to know it it reprod
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 version is in
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 than the others and
>> r
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 && make -j128 && make ch
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 I can fix the probl
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 in the past few weeks.
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
>
> Please give it a try when
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 65536
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
>
> I'm testing this patch,
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 argued
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?
>
>memcpy (pd_sr
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 (int i =
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 lambda frames are inlined, or
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 definition of __STDC_
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 should keep, or may
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" { be && { ! vect_shift_char }
>> } }
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 shift (but
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 i386-pc-solaris2.11 and
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 known whether that means
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
>
> Hopefully the final versi
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
>
> The complete version of i
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's wrong here, though.
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
>
> srcdir/configure --b
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$ uname -a
> SunOS s1
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, and sparc
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*
>> && !gas?
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 i386-pc-solaris
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-tar
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 agree with netconfig
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 you. I cherry picked the chang
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 testing
I just tried
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 ---
>> > BTW, I'm waiting for a revie
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-patches/2024-May/650634
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 reported
>
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 fine btw.
> al
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 wasn't aware of
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
> with this improvement
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 cfarm216 (Solaris/SPAR
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-gnu one will be running f
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.
>>
>> However, sparc/sol2.h ne
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 cycles to conduct a testi
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 point.
Right, I forgot th
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 compatibility wi
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 the test with LA
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 regenerated
>> from
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
b
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-optimization/
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.
It is. Thanks for
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. I only in
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-ga0b1798042d033
>
> It's not:
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 sophisticated top-level configurati
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 > > 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/c++draft/lex.ccon#
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 encoding in the execution
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 for unix"
>
> Is th
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 free to re-open if t
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 it passes on AVX capable native builds, b
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 SDK issue?).. or?
The
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
> /Library/Develo
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 from
>> far away
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> ---
>
>
>> The only is
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
>> with it applied instead of the loc
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-6.c.
Ah, no
1 - 100 of 378 matches
Mail list logo
