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/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
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
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
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
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 > >
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
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
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
>>
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
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
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=edit
> Tentative fix
>
> Please give it a try when you
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=edit
> proposed patch
>
> I'm testing this patch, does
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
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
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
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=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=edit
> Tentative fix
>
> Hopefully the final version of
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=edit
> Tentative fix
>
> The complete version of it.
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
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
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
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:
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
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
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=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
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/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.
>
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
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
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
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
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
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
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
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
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
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
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
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
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://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
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
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
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,
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?
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 from
>> far
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
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
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,
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
>
> So far very lightly
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:
>>
>> #define
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 comment #1)
>>> I
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, but would
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?
>
> This actually
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 to comment.
>
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 checked the
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 use
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.0.
> Can
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 of the
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
Great, thanks for
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 all.
What I
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 ("aE", a, 2) != NULL;
> }
>
> as
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 to xfail it
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
>> failures
>> to find
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
>
> works on x86_64 sonoma, with
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
>
> Correction the cast should be
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: I tested
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 substitution and we also
1 - 100 of 356 matches
Mail list logo
