[Bug go/87589] [11/12/13/14/15 regression] index0-out.go FAILs

2024-06-06 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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-patches/2024-June/653813.html

but decided to leave the untested -> unsupported change separate to
avoid obscuring the other change.

> Let's not close the bug, though.  The real fix is to not put very large 
> objects
> on the stack--we don't want to do that for split-stack either.  There should 
> be
> some size cut off where we push objects onto the heap.  But we don't have to 
> do
> that today.

Fine, will do.

[Bug libstdc++/98678] 30_threads/future/members/poll.cc execution test FAILs

2024-06-05 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 definition of
> "acceptable" and the relative difference between the speed of the different
> operations varies with arch. We could just increase the tolerances, but then 
> we
> allow worse performance on the targets that don't need it. Maybe we want to
> change the 30 and 100 magic numbers to depend on the target.

I've made some more checks on Solaris now.  The test consistently PASSes
on Solaris/SPARC, both 32 and 64-bit.  However, on Solaris/x86 the
failure is just as reliable, e.g.

/vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/30_threads/future/members/poll.cc:132:
int main(): Assertion 'wait_until_sys_min < (ready * 100)' failed.
wait_for(0s): 3674ns for 200 calls, avg 18.37ns per call
wait_until(system_clock minimum): 419918ns for 200 calls, avg 2099.59ns per
call
wait_until(steady_clock minimum): 459775ns for 200 calls, avg 2298.88ns per
call
wait_until(system_clock epoch): 1117280ns for 200 calls, avg 5586.4ns per call
wait_until(steady_clock epoch: 956073ns for 200 calls, avg 4780.36ns per call
wait_for when ready: 3194ns for 200 calls, avg 15.97ns per call

It also makes no difference if the system is under full load or
completely idle.  I've also checked a wider range of systems/CPUs:

  host  32-bit  64-bit  

  nahe  1.311.402.60 GHz Xeon Gold 6132
  lokon 1.431.663.10 GHz Core i5-2400
  itzacchiuatl  0.691.533.20 GHz Core i7-8700
  manam 0.892.223.50 GHz Xeon E3-1245
  lucy  0.540.592.00 GHz Xeon E7-4850

The attached patch uses a scale factor of 2.5 to accomodate this.

[Bug go/87589] [11/12/13/14/15 regression] index0-out.go FAILs

2024-06-04 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 now: my Linux/x86_64 build is configured
with --with-ld=/gld-2.42, but there's no matching gld-2.42.gold
around, so auto-host.h has

/* #undef HAVE_GOLD_NON_DEFAULT_SPLIT_STACK */

Thus no split-stack support and the SEGV observed.

[Bug libstdc++/112593] FAIL: 26_numerics/headers/cmath/equivalent_functions.cc on Solaris

2024-06-04 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 failure mode is different:
>> 
>> /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/26_numerics/headers/
>> cmath/equivalent_functions.cc:120: void test_float_overload(): Assertion
>> 'std::asin(x) == std::asinf(x)' failed.
>
> That looks like a similar problem though. std::asin(float) probably calls
> std::__asinf, which apparently gives a different result to ::asinf.

the strange thing is: running

$ dis -F _Z19test_float_overloadv equivalent_functions.exe

I find only a call to __asinf, nothing else.

> If you comment out the call to test_float_overload() in main, it might fail at
> the same place in test_long_double_overload (or maybe somewhere else!)

Right, it's the same

/vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/26_numerics/headers/cmath/equivalent_functions.cc:199:
void test_long_double_overload(): Assertion 'std::cosh(x) == std::coshl(x)'
failed.

that you saw on S11.3.

Again, only __coshl called in there.

[Bug libstdc++/111641] FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test

2024-06-03 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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
>>
>> --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE > 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.
>> I guess it's best to postpone committing to the gcc-14 branch until you
>> can report hppa results then.  Btw., when you're ready, could you also
>> check the libbacktrace test results (no .sum file, unfortunately, just
>> buried deeply in make check output) for comparison?  Thanks.
> Change fixes the following libstdc++ tests on hppa-linux:
> FAIL: 19_diagnostics/stacktrace/current.cc  -std=gnu++23 execution test
> FAIL: 19_diagnostics/stacktrace/current.cc  -std=gnu++26 execution test
> FAIL: 19_diagnostics/stacktrace/entry.cc  -std=gnu++23 execution test
> FAIL: 19_diagnostics/stacktrace/entry.cc  -std=gnu++26 execution test
> FAIL: 19_diagnostics/stacktrace/output.cc  -std=gnu++23 execution test
> FAIL: 19_diagnostics/stacktrace/output.cc  -std=gnu++26 execution test
> FAIL: 19_diagnostics/stacktrace/stacktrace.cc  -std=gnu++23 execution test
> FAIL: 19_diagnostics/stacktrace/stacktrace.cc  -std=gnu++26 execution test
>
> The libbacktrace tests all pass on hppa-linux.

Hi Dave,

thanks for checking.  I guess it's reasonably safe to backport the patch
to the gcc-14 branch then.

[Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC

2024-06-03 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 testsuite
>>   failures all over the place, but I'd have to perform another bootstrap
>>   with your patches removed to make an exact comparison.
>
> Hm, the part where you compare results against a baseline is pretty central.
>
> One the one hand, when it doesn't manifest for sparc64-solaris just through 
> the
> testsuite, the odds are against it manifesting that simple for sparc64-linux. 
> On the other hand, an existing reproducer is so much easier to handle.  Thank
> you and thanks in advance for the last step!

I've completed the sparc64-linux comparison now: no regressions with a
non-bootstrap build and your patches either, thus the same situation as
on Solaris.

[Bug tree-optimization/115304] gcc.dg/vect/slp-gap-1.c FAILs

2024-06-03 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 this to work
> the loads would need to be aligned.
>
> What is needed is char-to-short unpacking and vector composition.  Either
> composing V2SImode or V8QImode from two V4QImode vectors.
>
> Does the following help?

Unfortunately not: makes no difference AFAICS.

[Bug d/114434] gdc.test/runnable/test23514.d FAILs

2024-06-03 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 binary; 64-bit
d21 is ok.  However, both are supposed to work the same in multilibbed
configurations.

[Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC

2024-05-31 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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-Bielefeld.DE> ---
>> >> --- Comment #6 from Hans-Peter Nilsson  ---
>> [...]
>> >> versions.)  BTW, it'd be nice to know it it reproduces for sparc-linux
>> >> as well.
>> >
>> > I happen to have a Linux/sparc64 LDom around: I'll give it a whirl.
>> 
>> The failure is even earlier here: in a sparc64-unknown-linux-gnu
>> bootstrap, building a libstdc++ .gch file in stage 2 breaks:
>
> Great, thanks!  That means that tricking my pc into believing it's a sparc by
> means of using the binfmt machinery that Jeff mentioned in the thread where I
> mentioned the revert on gcc-patches, would work.  (I don't have the details 
> and
> don't remember if I'd actually tried it, certainly not recently; I just know
> about the concept.)

I can't help but wonder if this wouldn't be a total waste of your time:
considering what the qemu wiki docments for SPARC support

https://wiki.qemu.org/Documentation/Platforms/SPARC

seems not too encouraging for 64-bit systems.  When I think about what
it took myself to get recent macOS working on qemu-kvm (although the
procedure is resonably well documented, with firmware and all
available), I'd consider such an attempt a positive nightmare.

When all it takes for you to either get your ssh client working to
access a ready-made and not too slow SPARC system (or in the worst case,
build OpenSSH from source), I know which route I'd take ;-)

> What's not so great is that the described reproducer is a bootstrap, so the
> debug situation is unpleasant.  The first step I'd do, would be to just do a
> cross-build (or native --disable-bootstrap) and just run the testsuite
> before/after the patch-set (or just 933ab59c59bdc1) and see if the problem
> manifests there.
>
> It's also not great (from the view of gcc targeting architectures with
> delay-slots) that this isn't at the top of my queue anymore, since the
> immediate situation was resolved; as mentioned I committed the revert.  I'll
> get to it eventually, but if someone is intrigued enough by the prospect of a
> 0.36%-ish performance improvement (see commit log for the culprit commit) to 
> do
> such a --disable-bootstrap regtest, that'd help. :)

I've tried that now on both

* sparc-sun-solaris2.11 (c and c++ only): no additional testsuite
  failures are apparent there, which is not too astonishing given that
  the bootstrap failure occurs in stage 3, suggesting a mis-compiled
  stage 2 cc1plus, and

* sparc64-unknown-linux-gnu (again, c and c++ only): there are testsuite
  failures all over the place, but I'd have to perform another bootstrap
  with your patches removed to make an exact comparison.

[Bug testsuite/115294] [15 regression] dg-additional-files-options change broke several testsuites

2024-05-31 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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.

[Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC

2024-05-30 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 reproduces for sparc-linux as 
>> well.
>
> I happen to have a Linux/sparc64 LDom around: I'll give it a whirl.

The failure is even earlier here: in a sparc64-unknown-linux-gnu
bootstrap, building a libstdc++ .gch file in stage 2 breaks:

n file included from
/var/gcc/regression/master/6.8.9-gcc-gas-gld/build/sparc64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_pair.h:60,
 from
/var/gcc/regression/master/6.8.9-gcc-gas-gld/build/sparc64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:64,
 from
/var/gcc/regression/master/6.8.9-gcc-gas-gld/build/sparc64-unknown-linux-gnu/libstdc++-v3/include/algorithm:60,
 from
/vol/gcc/src/hg/master/solaris/libstdc++-v3/include/precompiled/stdc++.h:51:
/var/gcc/regression/master/6.8.9-gcc-gas-gld/build/sparc64-unknown-linux-gnu/libstdc++-v3/include/type_traits:
In instantiation of 'struct std::integral_constant':
/var/gcc/regression/master/6.8.9-gcc-gas-gld/build/sparc64-unknown-linux-gnu/libstdc++-v3/include/type_traits:296:72:
  required from here
  296 |constexpr true_type __is_complete_or_unbounded(__type_identity<_Tp>)
  |   ^
/var/gcc/regression/master/6.8.9-gcc-gas-gld/build/sparc64-unknown-linux-gnu/libstdc++-v3/include/type_traits:92:17:
internal compiler error: tree check: expected tree that contains 'decl common'
structure, have 'function_decl' in tsubst_arg_types, at cp/pt.cc:15782
   92 |   constexpr operator value_type() const noexcept { return value; }
  | ^~~~
0xfff8000100a2f087 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0xfff8000100a2f1a3 __libc_start_main_impl
./csu/libc-start.c:360

[Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC

2024-05-30 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 installed on cfarm211

It's not: I've tried bootstraps on sparc-sun-solaris2.11 and
sparcv9-sun-solaris2.11 to check if it's just a 32-bit issue.

> and a build log for a recent gcc checkout says "Configuration
> sparc-sun-solaris2.11 not supported" for the gcc dir.  (Please correct the

While the configure triples have no way to distinguish between Solaris
11.3 and 11.4, gcc/config.gcc explicitly checks for hosts running 11.4.

But I see what you mean: that's an error of mine moving 11.3 from
obsolete to unsupported.  The message should say

sparc-sun-solaris2.11.3 not supported

instead.  Will fix.

> versions.)  BTW, it'd be nice to know it it reproduces for sparc-linux as 
> well.

I happen to have a Linux/sparc64 LDom around: I'll give it a whirl.

[Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC

2024-05-30 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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
>> runs Solaris 11.4, which is the only OS release supported on trunk.
> I can't reach cfarm216, something with my ssh setup is too old. :(

Strange: you're the first to report such an issue, and there are quite a
number of users of the system.

> Also, I just realized it can't be a plain NULL basic_block, because that'd 
> have
> shown a SEGV in resource.c.  All the more interest in a way to reproduce on
> cfarm210 or cfarm211.

There's no point in trying: trunk isn't supported on either Solaris 10
(cfarm210) or Solaris 11.3 (cfarm211).

>> Ok.  For this night's bootstrap, I'm using the tree at the revision
>> before the culprit patch.  I tried to revert just that one, but failed
>> (conflicts and manual resolution failed compiling stage 1 libgcc).
> There's two other commits after the culprit, that depends on it functionally
> and contextually, so you have to revert those too.

I suspected that much, but was in a bit of hurry to get the bootstraps
going before I went to bed.

> Either way, if you prefer to revert (the failing one and the two after that 
> one
> obviously in opposite order, I'd be thankful.  I'll likely land there myself 
> as
> I currently have no way to reproduce the problem.

I've no problem with just reverting locally for a day or two.

[Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC

2024-05-29 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 check -j128 -k
>
> While that has its downsides, for the purposes of this investigation it
> should do the trick.

Oh, I forgot: you can speed up the build quite a bit by disabling
unnecessary languages, multilibs, and runtime libs.  Here's what I used
for the reghunt:

configure --enable-languages=c,c++ --disable-lto --disable-libatomic
--disable-libcc1 --disable-libquadmath --disable-libssp --disable-libitm
--disable-libvtv --disable-libsanitizer --disable-libgomp --disable-multilib

[Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC

2024-05-29 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 problem within 24 hours
> (not counting regtest-time).

Ok.  For this night's bootstrap, I'm using the tree at the revision
before the culprit patch.  I tried to revert just that one, but failed
(conflicts and manual resolution failed compiling stage 1 libgcc).

> Incidentally, can you please post a configure line for cfarm210 or cfarm211
> that works?  (A no-options line failed to find some library during bootstrap 
> so
> I originally bailed on sparc testing.)

You should use cfarm216 instead: it's way faster than the others and
runs Solaris 11.4, which is the only OS release supported on trunk.

Aldy, when investigating PR ipa/114985, got along with just

configure && make -j128 && make check -j128 -k

While that has its downsides, for the purposes of this investigation it
should do the trick.

[Bug libstdc++/111641] FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test

2024-05-29 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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.

I guess it's best to postpone committing to the gcc-14 branch until you
can report hppa results then.  Btw., when you're ready, could you also
check the libbacktrace test results (no .sum file, unfortunately, just
buried deeply in make check output) for comparison?  Thanks.

[Bug ada/115270] gnat doesn't link on 32-bit Linux/sparc

2024-05-29 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 have a chance.

As it happens, I still had the failed build tree around, so I just
dropped in the patch and restarted the build.  It completed successfully
and the following make check-ada only found the expected failures.

Thanks for the quick fix.

[Bug c++/115031] g++.dg/modules/pr99023_b.X FAILs

2024-05-27 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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
  3 131072
  2 262144
  3 524288
  2 1048576
  1 1662976
892 2097152
  2 3313664
  1 4194304

  total ca. 1784 MB
  getconf PAGE_SIZE -> 4096

sparc:

491 8192
  6 16384
  4 32768
  3 65536
  2 131072
  1 262144
  2 524288
  1 1048576
  1 2097152
986 4194304

  total ca. 3947 MB
  getconf PAGE_SIZE -> 8192

In a next step, I disabled MAPPED_{READING, WRITING} in
gcc/cp/module.cc, but that made almost no different on i386 and didn't
cure the allocation failure on sparc.

Looking closer at the mmap64 call chains, they are primarily from
ggc_internal_alloc.  So I undef'ed USING_MMAP there, with astonishing
results for runtimes:

* i386 with mmap in module.cc and ggc-page.cc:

real  30.12
user  29.62
sys0.14

* i386 with fileio in module.cc and mmap in ggc-page:

real  29.93
user  29.50
sys0.21

* i386 with fileio in module.cc and USING_MMAP undef'ed in ggc-page.cc:

real  28.53
user  28.19
sys0.16

* sparc with the same combination allows the test to run to complition
  for the first time:

real  37.81
user  37.46
sys0.14

I wonder what to make of that beyond the failing sparc testcase.

[Bug tree-optimization/115208] [15 Regression] Memory consumption get extremely high after r15-807-gfae5e6a4dfcf92

2024-05-26 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 it resolve your problem?

It did: i386-pc-solaris2.11 and sparc-sun-solaris2.11 bootstraps
completed without issues.  Thanks.

[Bug other/115211] [11/12/13/14/15 regression] -frecord-gcc-switches refactoring lost list of enabled options

2024-05-24 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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
the info wasn't fully complete.  However, I don't see how something that
is only 95% complete is worse than having nothing.

--help=optimizers just documents optimization options, with no
indication which are enabled for a given compilation.  Don't see how
this helps.

[Bug target/114148] gcc.target/i386/pr106010-7b.c FAILs

2024-05-24 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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_src, p_init, 2 * N * sizeof (double));
> -  memcpy (ps_dst, p_init, 2 * N * sizeof (float));
> -  memcpy (epi64_dst, p_init, 2 * N * sizeof (long long));
> -  memcpy (epi32_dst, p_init, 2 * N * sizeof (int));
> -  memcpy (epi16_dst, p_init, 2 * N * sizeof (short));
> -  memcpy (epi8_dst, p_init, 2 * N * sizeof (char));
> +  memcpy (ps_src, p_init, 2 * N * sizeof (float));
> +  memcpy (epi64_src, p_init, 2 * N * sizeof (long long));
> +  memcpy (epi32_src, p_init, 2 * N * sizeof (int));
> +  memcpy (epi16_src, p_init, 2 * N * sizeof (short));
> +  memcpy (epi8_src, p_init, 2 * N * sizeof (char));

It does indeed: tested 32 and 64-bit, and, for good measure, with all
allocators I tried before, too.

Thanks.

[Bug target/114148] gcc.target/i386/pr106010-7b.c FAILs

2024-05-23 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 = 0; i != N; i++)
if (a[i] != b[i])
  {
printf ("cmp_epi8: i = %d: a[i].r = %x a[i].i = %x b[i].r = %x b[i].i =
%x\n",
i, __real__ a[i], __imag__ a[i], __real__ b[i], __imag__ b[i]);
  }
}

This shows (when using _Complex unsigned char since on Solaris, char is
signed by default)

cmp_epi8: i = 76: a[i].r = 0 a[i].i = 0 b[i].r = 88 b[i].i = 33
cmp_epi8: i = 77: a[i].r = 0 a[i].i = 0 b[i].r = 6 b[i].i = 8
cmp_epi8: i = 80: a[i].r = 0 a[i].i = 0 b[i].r = 3 b[i].i = 0

I've also noticed that the test result depends on the implementation of
malloc used:

* With Solaris libc malloc, libmalloc, and watchmalloc, the test aborts.

* However, when using one of libbsdmalloc, libmapmalloc, libmtmalloc, or
  libumem, the test works.

However, ISTM that the test is simply bogus: in avx_test

* epi8_src, epi8_dst are allocated with malloc, buffer contents undefined

* epi8_dst is cleared

* epi8_dst is initialized from p_init

* in foo_epi8, epi8_src[0] (an undefined value) is copied into first N
  elements of epi8_dst

* epi8_dst is compared to epi8_src (with the remaining members of epi8_src
  still undefined)

Why on earth would the rest of epi8_dst and epi8_src be identical if
epi8_src was never initialized?

[Bug libstdc++/111641] FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test

2024-05-23 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 skip+2 in
>> stacktrace.cc causes us to skip real frames that we should keep, or maybe
>> libbacktrace just doesn't work on this target.
[...]
> The stacktrace failures only happen on 32-bit x86; 64-bit x86 is fine.
>
> I'm now trying a debug build and plan to compare i386 and amd64 side by
> side to find differences.

While that didn't produce anything useful, I noticed that both
libbacktrace and its testcases are built with -funwind-tables.

Checking what gcc does for that option, here's what I found:

* 64-bit x86 defaults to -fasynchronous-unwind-tables, thus implicitly
  -funwind-tables, too.  For that reason, the stacktrace tests PASS on
  both Linux/x86_64 and Solaris/amd64.

* 32-bit x86 defaults to -fasynchronous-unwind-tables *if*
  -fomit-frame-pointer is enabled.  This is the case on Linux/i686, thus
  the PASSes, while Solaris/i386 defaults to -fno-omit-frame-pointer,
  thus the FAILs observed.

* Solaris never enables -funwind-tables by default, thus the FAILs on
  both Solaris/SPARC and Linux/SPARC.

When I manually rebuild libstdc++-v3/src/libbacktrace with -g3 -O0
-funwind-tables and a testcase, too, it PASSes.

The question is how to proceed, though: while one could enable
-funwind-tables unconditionally in src/libbacktrace/Makefile.am (it's
done this way in other runtimes libs) and add -funwind-tables to the
affected testcases using dg-additional-options, I wonder if that
produces a satisfying user experience in the end.  Maybe it's better to
just default to -funwind-tables in g++ instead?

[Bug c++/57025] Solaris g++ defines __STDC_VERSION__=199901L

2024-05-22 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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_VERSION__
> didn't work with some of the illumos headers:
> https://github.com/jperkin/notes/blob/main/gcc-cpp-stdc/README.md

Unfortunately, the Illumos guys have refused to cooperate with upstream
GCC and LLVM for years, never tried to upstream patches, perform
testing, report results or anything.  Unless they suddenly start
testing, analysis, and provide patches, I'm not willing to do their work
for them.  I simply don't have the time.

[Bug libstdc++/111641] FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test

2024-05-22 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 maybe
> libbacktrace just doesn't work on this target.

In the Solaris case, the libbacktrace tests all PASS on all of 32 and
64-bit SPARC and x86.

The stacktrace failures only happen on 32-bit x86; 64-bit x86 is fine.

I'm now trying a debug build and plan to compare i386 and amd64 side by
side to find differences.

[Bug tree-optimization/114072] gcc.dg/vect/vect-pr111779.c FAILs

2024-05-22 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 } 
>> } }
>> */
>> 
>> Lets the test become UNSUPPORTED on 32 and 64-bit SPARC, but still PASS
>> as before on 32 and 64-bit x86.
>
> Can we instead guard the scan-tree-dump?  This way the correctness
> execute part still is exercised?

Sure, even if the result is somewhat hard to read with all those levels
of braces:

/* { dg-final { scan-tree-dump "LOOP VECTORIZED" "vect" { target { vect_int &&
{ le || { be && vect_shift_char } } } } } } */

This way, all of compile, execute, and scan are run on x86, while on
sparc it's only compile, execute.

[Bug tree-optimization/114072] gcc.dg/vect/vect-pr111779.c FAILs

2024-05-22 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 little-endian doesn't
> require it - it's actually bitfield endianess that matters).
>
> There is vect_shift_char you could use and somehow conditionalize that
> on big-endianess.

I think the best we can do then is

/* { dg-skip-if "PR tree-optimization/114072" { be && { ! vect_shift_char } } }
*/

Lets the test become UNSUPPORTED on 32 and 64-bit SPARC, but still PASS
as before on 32 and 64-bit x86.

[Bug ada/115168] [15 regression] Several libada compile errors on Solaris

2024-05-21 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 sparc-sun-solaris2.11 bootstraps are well
into make check now.  Thanks.

[Bug ada/115106] [15 regression] SEGV in sem_elab.internal_representation.nts_map.mutate_and_rehash

2024-05-21 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 the issue is actually fixed by recent Ada
>> commits, or that it's now just become latent.
>
> Ada commits have nothing to do with it though, the breakage and the probable
> fix both came from recent optimization changes.

I'm practically certain that this is due to Richard's recent fix for PR
middle-end/115110, so it's not latent.

[Bug ada/115133] [15 regression] s-oslock__solaris.ads doesn't compile

2024-05-17 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 it.

Yes, make all-target-libada completed just fine with this.  Thanks!

[Bug ada/115133] [15 regression] s-oslock__solaris.ads doesn't compile

2024-05-17 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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.

Thanks.  There's one issue left:

s-tasini.adb:248:11: warning: default initialization of "Lock" may modify
overlaid storage [-gnatwo]
s-tasini.adb:248:11: warning: use pragma Import for "Lock" to suppress
initialization (RM B.1(24)) [-gnatwo]
s-tasini.adb:260:11: warning: default initialization of "Lock" may modify
overlaid storage [-gnatwo]
s-tasini.adb:260:11: warning: use pragma Import for "Lock" to suppress
initialization (RM B.1(24)) [-gnatwo]
s-tasini.adb:272:11: warning: default initialization of "Lock" may modify
overlaid storage [-gnatwo]
s-tasini.adb:272:11: warning: use pragma Import for "Lock" to suppress
initialization (RM B.1(24)) [-gnatwo]
s-tasini.adb:284:11: warning: default initialization of "Lock" may modify
overlaid storage [-gnatwo]
s-tasini.adb:284:11: warning: use pragma Import for "Lock" to suppress
initialization (RM B.1(24)) [-gnatwo]

[Bug ada/115133] [15 regression] s-oslock__solaris.ads doesn't compile

2024-05-17 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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.

There's a 2-space indentation instead of the expected 3 spaces.  I had
to look several times to see it, though.  Maybe the error could be
clearer?

After that, I run into

s-taprop.adb:1402:20: error: expected type "System.Os_Locks.RTS_Lock_Ptr"
s-taprop.adb:1402:20: error: found type "System.Task_Primitives.Lock_Ptr"
s-taprop.adb:1443:57: error: expected type "System.Task_Primitives.Lock_Ptr"
s-taprop.adb:1443:57: error: found type "System.Os_Locks.RTS_Lock_Ptr"
s-taprop.adb:1471:20: error: expected type "System.Os_Locks.RTS_Lock_Ptr"
s-taprop.adb:1471:20: error: found type "System.Task_Primitives.Lock_Ptr"
s-taprop.adb:1552:57: error: expected type "System.Task_Primitives.Lock_Ptr"
s-taprop.adb:1552:57: error: found type "System.Os_Locks.RTS_Lock_Ptr"
make[6]: *** [../gcc-interface/Makefile:306: s-taprop.o] Error 1

but am stuck.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

2024-05-16 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 --build=sparc-sun-solaris2.11 --without-gnu-as
> --without-gnu-ld
>
> ??

  srcdir/configure --build=sparcv9-sun-solaris2.11 --without-gnu-as
  --with-as=/usr/bin/as --without-gnu-ld --with-ld=/usr/bin/ld

should do the trick.

Preferably prepend /usr/gnu/bin to PATH.

> I really don't care how it builds, I just want the bare minimum so I can
> bootstrap and run tests.
>
> A minor rant, but why can't all this be set up automatically in the compile
> farm machines?  Keeping track of minor nuances of each architecture is
> distracting.  They should all be set up, whether by setting default paths in

Agreed, but you always run into stuff like this when leaving Linux (like
AIX, HP-UX, or macOS).  PATHs won't help much for reasons explained in
install.texi.

> /etc/profile or whatever, or by having the relevant patches in GCC's source
> base, such that they work with src/configure && make.

But what should be the default: GNU or native tools?  You have choices
here and need to decide what you need/want.  No one can do this for you.

> I know this isn't your fault, but if more cfarm boxes where set up to go with
> no surprises, I'd add more boxen to my testing harness.

Well, I *did* set up the Solaris cfarm systems, actually ;-)  I see your
point, but things are not that simple unfortunately.  And GCC's
configure doesn't need to cater to users of the cfarm only...

Some of the issues (like the need for --build) have been caused by
upstream (like the config.guess maintainers that refuse to listen to
reason ;-).  I thought about improving the --with-as/ld situation; maybe
something can be done there.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

2024-05-16 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 s11-sparc.cfarm 5.11 11.4.68.164.2 sun4v sparc sun4v logical-domain
> aldyh@s11-sparc:~/bld/clean$ ~/src/clean/configure && gmake -j80 && gmake 
> check
> -k -j80

You need to be careful that the assembler and linker actually used match
gcc's idea thereof: 

https://gcc.gnu.org/install/specific.html#x-x-solaris2

Best specify all of --build sparcv9-sun-solaris2.11 (if you're
bootstrapping with a 64-bit-default gcc/g++) and

--with-as=/usr/gnu/bin/as (or /opt/cfarm/binutils-latest-64/bin/as)
--with-gnu-as

(/usr/bin/as works too, but you need to specify both the path and
--without-gnu-as)

--with-ld=/usr/bin/ld
--without-gnu-ld

Having two different assemblers and linkers (Solaris and GNU) available
can lead to confusion if you rely on PATH alone.

> gmake[3]: Leaving directory '/home/aldyh/bld/clean'
> Comparing stages 2 and 3
> Bootstrap comparison failure!
> gcc/tree-vect-stmts.o differs

I'm not seeing this myself.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

2024-05-16 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 bootstrap was
> already broken.

Huh?  Current trunk bootstraps just fine on Solaris/SPARC without any
patches.  What issue do you see?

Besides, there *is* a Solaris/SPARC system in the cfarm (cfarm216), so
you can try for yourself.

[Bug debug/115066] [debug, gsplit-dwarf, gdwarf-4, g3] DW_MACRO_define_strp used for debug_str_offsets index

2024-05-16 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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?  Theoretically, there could be other targets with similar issues.
>
> This looks like test-case issue, so re-closing the PR.

True, but it's often way simpler to discuss testcase issues in the
original PR rather than open new PRs for every single issue with a
testcase (and there's already been the comment character one here).

> How about:
> ...
> -/* { dg-final { scan-assembler {\.byte\t0xb\t[^\n\r]* Define macro strx} } }
> */
> +/* { dg-final { scan-assembler {\.byte\t0xb\t[^\n\r]* Define macro
> strx|\.byte\t0x1\t[^\n\r]* Define macro}
> ...
> ?

Seems like an option, too (and would work on other affected targets
should they appear).  Tested on sparc-sun-solaris2.11 with as and gas.

Btw., I wonder which of the targets currently skipped with "split DWARF
unsupported" are instances of this problem, too: Solaris doesn't support
-gsplit-dwarf, still the test PASSes on Solaris/SPARC with gas and
Solaris/x86 with either assembler.

[Bug c++/113719] [13/14/15 regression] g++.target/i386/pr103696.C FAILs

2024-05-15 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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-solaris2.11 and
the failure is gone for both 32 and 64-bit.  Thanks.

> cross-compiled solaris gcc but it has some error on varasm with 64bit so I'm
> not sure it can pass all 32/64bit test.

FWIW, there's now a Solaris/x86 cfarm system (cfarm215), just in case
you ever need one ;-)

[Bug analyzer/107750] [13/14/15 Regression] Many gcc.dg/analyzer/fd-*.c tests FAIL

2024-05-14 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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-target-headers.c  (test for warnings, line
19)
FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c  (test for warnings, line
27)
FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c  (test for warnings, line
32)
FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c  (test for warnings, line
39)
FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c  (test for warnings, line
55)
FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for excess errors)

Excess errors:
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/fd-access-mode-target-headers.c:55:3:
warning: named constant 'O_ACCMODE' has unknown value

 (included from ) has

#define O_ACCMODE   (O_SEARCH | O_EXEC | 0x3)

which analyzer cannot handle (not a simple numeric constant; same issue
as with SOCK_*).

Linux/glibc has instead

#define O_ACCMODE   0003

FAIL: gcc.dg/analyzer/fd-glibc-byte-stream-connection-server.c (test for excess
errors)

Excess errors:
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/fd-glibc-byte-stream-connection-server.c:91:3:
error: implicit declaration of function 'memset'
[-Wimplicit-function-declaration]

Solaris  has

#define FD_ZERO(__p)(void) memset((__p), 0, sizeof (*(__p))) 

While one certainly could argue that the header should be
self-contained, it's easy enough to just include  in the test
to avoid this.

[Bug analyzer/107750] [13/14/15 Regression] Many gcc.dg/analyzer/fd-*.c tests FAIL

2024-05-13 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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.h */
#define NC_TPI_COTS 2   /* must agree with netconfig.h */
[...]
#if !defined(_XPG4_2) || defined(__EXTENSIONS__)
#define SOCK_STREAM NC_TPI_COTS /* stream socket */
#define SOCK_DGRAM  NC_TPI_CLTS /* datagram socket */
[...]
#else
#define SOCK_STREAM 2   /* stream socket */
#define SOCK_DGRAM  1   /* datagram socket */

The problem seems to be the indirection: when SOCK_DGRAM etc. are
defined as numeric constants, things work, while the indirection via
NC_TPI_* does not.

[Bug target/112959] install.tex needs updates on FreeBSD

2024-05-13 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 changes I made to the GCC 14 
> branch, so they should be in the GCC 14.2 release.

Great, thanks.

>> However, one issue mentioned in PR target/112959 is missing, namely the
>> problem of getting a working Ada bootstrap compiler. I have no idea if
>> gnat12 has been fixed since and is now able to build Ada on trunk/the
>> gcc-14 branch.  Otherwise, the old GNAT 6.4.1 worked for me, but this
>> isn't easy to find.
>
> Looking at the lang/gnat12 and now lang/gcc13 ports and recent changes
> including ones like
[...]
> (which was a few days after this report was filed) I am hopefully it would
> work. However, I cannot guarantee.
>
> I am temped to mark this report as RESOLVED based on my changes.

I tend to agree: if someone runs into GNAT problems in the future, they
can report them anew.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

2024-05-10 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 bootstrapping on sparc-sun-solaris2.11 with this patch and

commit 36e877996936abd8bd08f8b1d983c8d1023a5842
Author: Aldy Hernandez 
Date:   Tue May 7 14:05:50 2024 +0200

Enable prange support.

reapplied.

It ICEs in stage 2:

Unsupported operand combination in dispatch: RO_PII
during IPA pass: inline
In file included from /vol/gcc/src/hg/master/solaris/gcc/c/c-parser.cc:26971:
./gt-c-c-parser.h:94:2: internal compiler error: in discriminator_fail, at
range-op.cc:205
   94 | };
  |  ^
0x218a05b range_op_handler::discriminator_fail(vrange const&, vrange const&,
vrange const&) const
/vol/gcc/src/hg/master/solaris/gcc/range-op.cc:205
0x218a313 range_op_handler::fold_range(vrange&, tree_node*, vrange const&,
vrange const&, relation_trio) const
/vol/gcc/src/hg/master/solaris/gcc/range-op.cc:229
0x3569d2f ipa_vr_operation_and_type_effects
/vol/gcc/src/hg/master/solaris/gcc/ipa-cp.cc:1663
0x356a337 ipa_value_range_from_jfunc(vrange&, ipa_node_params*, cgraph_edge*,
ipa_jump_func*, tree_node*)
/vol/gcc/src/hg/master/solaris/gcc/ipa-cp.cc:1759
0x1e1cbef evaluate_properties_for_edge(cgraph_edge*, bool, unsigned int*,
unsigned int*, ipa_auto_call_arg_values*, bool)
/vol/gcc/src/hg/master/solaris/gcc/ipa-fnsummary.cc:684
0x1e4ea47 do_estimate_edge_size(cgraph_edge*)
/vol/gcc/src/hg/master/solaris/gcc/ipa-inline-analysis.cc:337
0x1e4fcff estimate_edge_size(cgraph_edge*)
/vol/gcc/src/hg/master/solaris/gcc/ipa-inline.h:79
0x1e4fdbb estimate_edge_growth(cgraph_edge*)
/vol/gcc/src/hg/master/solaris/gcc/ipa-inline.h:100
0x1e4f033 do_estimate_growth_1
/vol/gcc/src/hg/master/solaris/gcc/ipa-inline-analysis.cc:436
0x1971d87 cgraph_node::call_for_symbol_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool)
/vol/gcc/src/hg/master/solaris/gcc/cgraph.h:3429
0x1e4f2a7 estimate_growth(cgraph_node*)
/vol/gcc/src/hg/master/solaris/gcc/ipa-inline-analysis.cc:474
0x359d46f inline_small_functions
/vol/gcc/src/hg/master/solaris/gcc/ipa-inline.cc:2081
0x35a1083 ipa_inline
/vol/gcc/src/hg/master/solaris/gcc/ipa-inline.cc:2850
0x35a24b3 execute
/vol/gcc/src/hg/master/solaris/gcc/ipa-inline.cc:3248

[Bug tree-optimization/114912] [15 regression] SIGBUS in wi::copy<> on SPARC since r15-88-gc60b3e211c5557 since char array is not aligned to what it needs to be

2024-05-09 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 review, or at least a nod from a C++ savvy
>> > person here:
>> >
>> > https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650634.html
>> 
>> I can give the patch a whirl, thanks.
>
> I've attached a rebased patch against current mainline.  Let me know if it
> works on your end, and I'll commit.

I've included both this patch ...

>> I had Andrew's patch in my tree to avoid the issue.  Unfortunately,
>> Solaris/SPARC bootstrap is broken again due to PR ipa/114985.
>
> I have provided a patch for that PR as well, but the IPA folk need to say if
> this is the correct approach.

... and that one in last night's SPARC bootstraps, which worked just
fine again.  Thanks.

[Bug tree-optimization/114912] [15 regression] SIGBUS in wi::copy<> on SPARC since r15-88-gc60b3e211c5557 since char array is not aligned to what it needs to be

2024-05-08 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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.html

I can give the patch a whirl, thanks.

I had Andrew's patch in my tree to avoid the issue.  Unfortunately,
Solaris/SPARC bootstrap is broken again due to PR ipa/114985.

[Bug target/112959] install.tex needs updates on FreeBSD

2024-05-06 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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
> and sufficiently well?

What's there looks good to me.  However, one issue mentioned in PR
target/112959 is missing, namely the problem of getting a working Ada
bootstrap compiler.  I have no idea if gnat12 has been fixed since and
is now able to build Ada on trunk/the gcc-14 branch.  Otherwise, the old
GNAT 6.4.1 worked for me, but this isn't easy to find.  AFAICS, AdaCore
provides no FreeBSD GNAT tarball of any kind.

[Bug tree-optimization/114912] [15 regression] SIGBUS in wi::copy<> on SPARC since r15-88-gc60b3e211c5557 since char array is not aligned to what it needs to be

2024-05-02 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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.

> also try out the solaris machine on the compile farm if possible.

Otherwise, you can just send it my way and I'll give it a whirl.

[Bug c++/113706] c-c++-common/pr103798-2.c FAILs as C++

2024-05-02 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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.

[Bug ada/112958] [12/13/14/15 regression] s-exnllf.ads etc. don't compile on 32-bit FreeBSD/x86

2024-05-02 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 that (and was particularly interested in i386 for
comparison with Solaris/i386 asan).

> Can we disable libgnat (or GNAT) support during configure time?

Sure: --disable-libasan should work for every toplevel library, although
there's little point in building GNAT without the runtime libs.  Given
that there's no --disable-languages (I've filed a PR for that ages ago,
I believe), you have to use

--enable-languages=

instead of

--enable-languages=all --disable-languages=ada

[Bug analyzer/111475] [14/15 regression] Many C++ analyzer tests FAIL

2024-05-01 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 to g++.sum with analyzer.exp so far:
>
> # of expected passes   11395 -> 12015
> # of unexpected failures 684 ->64
> # of unexpected successes  4 -> 0
> # of expected failures   443 ->   447
> # of unsupported tests50
>
> However I'm don't have access to my regular workstation/testing box until late
> tomorrow, so I'm holding off on posting until I've cleaned them up and put 
> them
> through my usual testing regime.

That's excellent news, thanks for the update.

[Bug analyzer/111475] [14/15 regression] Many C++ analyzer tests FAIL

2024-04-26 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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/SPARC).  With
the attached Solaris testcase, you can reproduce it even on Linux.

[Bug target/114416] calling convention incompatibility with vendor compiler for V9

2024-04-25 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 for a couple more
>>> hours, though.
>>
>> The change should be a no-op for this platform.
>
> True.  However, I'd rather wait for the bootstrap to complete.  Should
> be sometime tonight...

That's finished now, too, and as expected there were no regressions.

[Bug target/114416] calling convention incompatibility with vendor compiler for V9

2024-04-24 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 needed an #undef to fix
[...]
> Thanks, fixed.

great, thanks.

>> The sparc64-unknown-linux-gnu one will be running for a couple more
>> hours, though.
>
> The change should be a no-op for this platform.

True.  However, I'd rather wait for the bootstrap to complete.  Should
be sometime tonight...

>> Btw., I thought about running gcc.dg/compat against Studio 12.6 cc.  I'd
>> started trying some time ago, but got distracted.  At the very least, I
>> needed -features=extensions -DSKIP_COMPLEX_INT for a considerable part
>> of that testsuite to compile at all, for the likes of
>> 
>> "/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/compat/pr102024_test.h",
>> line 7: zero-sized struct/union
>> 
>> "/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/compat/struct-layout-1.h",
>> line 197: invalid type combination
>
> I used to do that on a regular basis 20 years ago, which led to:
>   https://gcc.gnu.org/gcc-3.4/sparc-abi.html
> but I lost access to Sun Studio at some point.

FWIW, cfarm216, the new Solaris 11.4/SPARC compile farm host, does have
Studio 12.6 installed.  Right now, it's only the FCS version, but I hope
to get access to the studiosupport repo in the future.  Besides, I've
checked the testcase that prompted this PR with previous Studio versions
quite some time back and their behaviour in this regard is unchanged.

[Bug target/114416] calling convention incompatibility with vendor compiler for V9

2024-04-24 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 testing cycle of the 
>> above
>> tentative fix?  It only affects the 64-bit ABI so a sparc64/sparcv9 one would
>> be sufficient (Unfortunately I no longer have access to my SPARC/Solaris 
>> setup
>> and haven't tried the Compile Farm yet).
>
> Sure: I've kept one half of the T8-1 hosting the new Solaris 11.4/SPARC
> cfarm node to myself ;-)  I've also got a Linux/sparc64 LDom around
> since the cfarm instance has been very unstable lately.

The sparc-sun-solaris2.11 bootstrap (both multilibs) has just completed
successfully without regressions.

However, sparc/sol2.h needed an #undef to fix

In file included from ./tm.h:27,
 from /vol/gcc/src/hg/master/local/gcc/gencheck.cc:23:
/vol/gcc/src/hg/master/local/gcc/config/sparc/sol2.h:460:9: error:
"SUN_V9_ABI_COMPATIBILITY" redefined [-Werror]
  460 | #define SUN_V9_ABI_COMPATIBILITY 1
  | ^~~~
In file included from ./tm.h:24:
/vol/gcc/src/hg/master/local/gcc/config/sparc/sparc.h:1705:9: note: this is the
location of the previous definition
 1705 | #define SUN_V9_ABI_COMPATIBILITY 0
  | ^~~~

The sparc64-unknown-linux-gnu one will be running for a couple more
hours, though.

Btw., I thought about running gcc.dg/compat against Studio 12.6 cc.  I'd
started trying some time ago, but got distracted.  At the very least, I
needed -features=extensions -DSKIP_COMPLEX_INT for a considerable part
of that testsuite to compile at all, for the likes of

"/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/compat/pr102024_test.h",
line 7: zero-sized struct/union

"/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/compat/struct-layout-1.h",
line 197: invalid type combination

[Bug target/114416] calling convention incompatibility with vendor compiler for V9

2024-04-24 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 that there are others (and I cannot test any of them at
this point; I don't even know if current BSDs still support SPARC at all).

> Do you happen to have some spare cycles to conduct a testing cycle of the 
> above
> tentative fix?  It only affects the 64-bit ABI so a sparc64/sparcv9 one would
> be sufficient (Unfortunately I no longer have access to my SPARC/Solaris setup
> and haven't tried the Compile Farm yet).

Sure: I've kept one half of the T8-1 hosting the new Solaris 11.4/SPARC
cfarm node to myself ;-)  I've also got a Linux/sparc64 LDom around
since the cfarm instance has been very unstable lately.

[Bug target/114416] calling convention incompatibility with vendor compiler for V9

2024-04-23 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 with the Studio compilers is pretty important IMO.

* Even though the SCD wording isn't really clear, the intent seems to
  match what Studio cc does according to the colleague on the spec group
  Jakub cited.

* There's no point in waiting beyond GCC 14, I believe: this will break
  compatiblity with GCC <= 13 no matter what.

* Besides, Solaris is pretty quick picking up new GCC releases these
  days, so they'll bundle GCC 14.1.0 not long after it's released, so
  the benefit will be immediate.

* I'm a tad uncertain about what to do on Linux/sparc64, though: while
  it mostly has followed the SCD, there are exceptions (e.g. sizeof
  (long double)) and no vendor compiler to be compatible with.  So
  making the same change there would only mean breaking compatibility
  with older GCCs (and clang) for little gain.

[Bug go/114454] go.test/test/fixedbugs/issue27836.go FAILs with LANG=C

2024-04-04 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 LANG=C and everything
> passes.  In fact, that is exactly how the GCC testsuite runs the test: the GCC
> testsuite sets LANG=C before all tests.
>
> As best I can tell the problem must be arising somehow in the DejaGNU code. 
> The filenames in the test use UTF-8 non-ASCII characters.  But I haven't been
> able to figure out where the problem is.

I've done a bit more digging now, running the test under runtest both
with LANG=en_US.UTF-8 and LANG=C.

* Comparing go.log shows

-PASS: go.test/test/fixedbugs/issue27836.dir/�<84>foo.go  -O -I. (test for
excess errors)
+go1: fatal error: cannot open
/vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue27836.dir/�<83>�<84>foo.go:
No such file or directory

  i.e. a leading "�<83>" is added to the filename.

* Running both under truss, I see that gccgo is invoked differently:

  LANG=UTF-8:

14285: 
execve("/var/gcc/regression/master/11.4-gcc/build/gcc/testsuite/go-issue27836/../../gccgo",
0x00E00790, 0x009A5F10)  argc = 12
14285:   argv:
14285:   
/var/gcc/regression/master/11.4-gcc/build/gcc/testsuite/go-issue27836/../../gccgo
14285:   
-B/var/gcc/regression/master/11.4-gcc/build/gcc/testsuite/go-issue27836/../../
14285:-fdiagnostics-plain-output
14285:   
-I/var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/./libgo
14285:-O -I. -w -pedantic-errors -c -o Ã<84>foo.o
14285:   
/vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue27836.dir/Ã<84>foo.go

  LANG=C:

14441: 
execve("/var/gcc/regression/master/11.4-gcc/build/gcc/testsuite/go-issue27836/../../gccgo",
0x00DFFA40, 0x009A11A0)  argc = 12
14441:   argv:  
14441:   
/var/gcc/regression/master/11.4-gcc/build/gcc/testsuite/go-issue27836/../../gccgo
14441:   
-B/var/gcc/regression/master/11.4-gcc/build/gcc/testsuite/go-issue27836/../../
14441:-fdiagnostics-plain-output
14441:   
-I/var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/./libgo
14441:-O -I. -w -pedantic-errors -c -o Ã<83>Â<84>foo.o
14441:   
/vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue27836.dir/Ã<83>Â<84>foo.go

So the caller of gccgo (runtest/expect) calls it differently.

runtest is the latest version:

DejaGnu version 1.6.3
Expect version  5.45.4
Tcl version 8.6

but expect is ancient (the latest available from 2018).

My inclination to debug runtest or even expect is limited, TBH.

[Bug c++/112652] g++.dg/cpp26/literals2.C FAILs

2024-03-22 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 the OpenSolaris sources, modified not to do that '?' conversion.
>> Worked for a quick check for the UTF-8 -> ASCII example, but the '?' is
>> more prevalent and would need to be eradicated upstream.
>
> If it is always '?' used instead of unknown character, we could also have some
> hack on the libcpp side for it.

It took me a bit to get back to you here since I had to check with both
Solaris engineering and dig up our old Solaris 9 sources (which, unlike,
OpenSolaris, have no relevant parts missing due to copyright issues).

Both what I found in the iconv conversion tables and what's documented
in unicode_iconv(7) confirms the consistent use of '?'.  The manpage has

   If the source character code value is not within a range defined by the
   source  codeset  standard, it is considered as an illegal character. If
   the source character code value is within the range(s) defined  by  the
   standard,  it  will  be considered as non-identical, even if the source
   character code value maps to an undefined or a reserved location within
   the valid range. The non-identical character will map to either ? (0x3f
   in ASCII-compatible codesets) if the target codeset  is  a  non-Unicode
   codeset  or  to  Unicode  replacement  character (U+FFFD) if the target
   codeset is an Unicode codeset.

It will of course be in the respective charset's encoding (0x3f for
ASCII, 0x6f for EBCDIC), but that's all I could find.  This is not a
complete guarantee (I may well have missed something), but seems
plausible enough...

> Like (but limited to Solaris hosts) in convert_using_iconv when converting 
> from
> SOURCE_CHARSET to some other character set don't try to convert the whole 
> UTF-8
> string at once, but split it into chunks at u'?' characters, so
> foo???bar?baz?qux
> would be iconv converted as
> foo
> ???
> bar
> ?
> baz
> ?
> qux
> chunks.  And when converting the non-? chunks, it would after the conversion
> check for the '?' character (in the destination character set - that is
> something that perhaps could be queried during initialization after 
> iconv_open)
> and treat it as an error if it appeared there.  Or always convert also back to
> UTF-8 and check if it has more '?' characters than the source.

Unless we want to take the easy way out and just require GNU libiconv on
Solaris, that seems like a plausible way of handling the issue.

[Bug target/114416] SPARC V9 struct return with floating-point members violates ABI

2024-03-21 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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)   appear in the floating-point registers.

and

%o0 through %o5 Outgoing non-floating-point parameters slots use
up to 6 corresponding out registers. Arguments
beyond the sixth extended-word appear on the stack.

The second line seems pretty clear that the %o[0-5] registers are only
for non-fp parameter slots, while the first could be interpreted either
way (fp *fields only* or fp fields in general).

While compatibility with the vendor compiler is a strong argument, in
the end the ABI remains the reference.

[Bug tree-optimization/96147] [11 regression] gcc.dg/vect/slp-43.c etc. FAIL

2024-03-19 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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/gcc/testsuite/gcc.dg/vect/bb-slp-32.c
--- a/gcc/testsuite/gcc.dg/vect/bb-slp-32.c
+++ b/gcc/testsuite/gcc.dg/vect/bb-slp-32.c
@@ -25,4 +25,4 @@ int foo (int *p, int a, int b)
   return sum;
 }

-/* { dg-final { scan-tree-dump "vectorization is not profitable" "slp2" {
xfail  { vect_no_align && { ! vect_hw_misalign } } } } } */
+/* { dg-final { scan-tree-dump "vectorization is not profitable" "slp2" {
xfail  { ! vect_hw_misalign } } } } */

[Bug tree-optimization/113431] [14 Regression] Wrong code at -O3

2024-03-19 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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/98238.  Thanks.

[Bug d/114155] gdc.test/runnable/literal.d FAILs

2024-03-19 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 taking care of this.

[Bug libobjc/48626] --enable-objc-gc should be automatic

2024-03-19 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 include it (and objc-gc) in my builds to maximize
coverage on uncommon targets: this tends to find bugs that aren't seen
on e.g. Linux.

[Bug tree-optimization/114154] gcc.dg/vect/vect-alias-check-1.c XPASSes

2024-03-18 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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: I've reverted that patch locally, rebuilt cc1 and re-tested:
> the XPASSes remain.

A reghunt identified this patch:

commit d30846a02eb9ea43b61311e74fbf05692ffefba2
Author: Fei Yang 
Date:   Fri Jun 12 11:37:00 2020 +0100

vect: Fix an ICE in vect_loop_versioning [PR95570]

[Bug tree-optimization/114154] gcc.dg/vect/vect-alias-check-1.c XPASSes

2024-03-18 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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.

[Bug libobjc/48626] --enable-objc-gc should be automatic

2024-03-18 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 configuration
> (similar to GMP et. al.) which determines if there's a suitable libgc
> available?

On the contrary: I think support for --enable-objc-gc at both the
toplevel and gcc can just go.

* At the toplevel, it's just a preliminary check which I don't think is
  necessary at all since it's redone in more detail in libobjc.

* In gcc, all that --enable-objc-gc does is set OBJC_BOEHM_GC in
  gcc/Makefile, which isn't ever used.

[Bug c++/112652] g++.dg/cpp26/literals2.C FAILs

2024-03-13 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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> ---
>> >> --- 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
>> >> character set, I'm afraid the Solaris iconv behavior results in violation 
>> >> of
>> 
>> Although I can barely wrap my head around the standardese there, I had a
>> look at n4928 (the last? C++23 draft), which has a different wording
>> here (p.25, 5.13.3):
>
> The testcase is for a C++26 feature, which made those ill-formed.

Should have been obvious from the pathname ;-(  N4971 has that wording...

>> The current Solaris iconv behaviour certainly isn't particularly
>> intuitive and I'll ask the Solaris engineers about it.  However, there's
>> the question what to do about the testcase?  Just xfail it on Solaris or
>> omit just the two affected subtests there?
>
> xfailing is one possibility, but then on Solaris we'll never support C++26
> properly.

I guess it's the best solution in the short term (GCC 14), though.

> Or require using GNU libiconv rather than Solaris iconv if it can't deal with
> that?

At least document the suggestion in install.texi; I wouldn't make it a
hard requirement yet.  I'll also wait what the Solaris engineers can
provide on background for the current behaviour.

FWIW, the iconv conversion tables in /usr/lib/iconv can be regenerated
from the OpenSolaris sources, modified not to do that '?' conversion.
Worked for a quick check for the UTF-8 -> ASCII example, but the '?' is
more prevalent and would need to be eradicated upstream.

[Bug c++/112652] g++.dg/cpp26/literals2.C FAILs

2024-03-13 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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#3.1
>> that program is ill-formed if some character lacks encoding in the execution
>> character set, I'm afraid the Solaris iconv behavior results in violation of

Although I can barely wrap my head around the standardese there, I had a
look at n4928 (the last? C++23 draft), which has a different wording
here (p.25, 5.13.3):

(3.1) — A character-literal with a c-char-sequence consisting of a
 single basic-c-char, simple-escape-sequence, or
 universal-character-name is the code unit value of the
 specified character as encoded in the literal’s associated
 character encoding.

 [Note 2 : If the specified character lacks representation in
 the literal’s associated character encoding or if it cannot be
 encoded as a single code unit, then the literal is a
 non-encodable character literal. —end note

> I've not yet tried to understand what either iconv(3) has to say on the
> matter.

Digging further, Solaris iconv(3C) has

   If  iconv()  encounters  a character in the input buffer that is legal,
   but for which an identical character does not exist in the target  code
   set,  iconv()  performs  an  implementation-defined  conversion on this
   character.

which exactly matches XPG7, so the behaviour seems to be in line with
the standards.

I've also found that Solaris 11 has iconvctl(3C) (obviously patterened
after GNU libiconv) with

   ICONV_SET_TRANSLITERATE

   With  this  request  and  a  pointer to a const int with a non-zero
   value, caller can instruct the current conversion to  transliterate
   non-identical characters from the input buffer during the code con-
   version  as  much  as it can. The value of zero, on the other hand,
   turns it off.

However,

int transliterate = 0;
iconvctl (cd, ICONV_SET_TRANSLITERATE, );

doesn't make a difference.

The current Solaris iconv behaviour certainly isn't particularly
intuitive and I'll ask the Solaris engineers about it.  However, there's
the question what to do about the testcase?  Just xfail it on Solaris or
omit just the two affected subtests there?

[Bug c++/112652] g++.dg/cpp26/literals2.C FAILs

2024-03-12 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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
> character set, I'm afraid the Solaris iconv behavior results in violation of
> the C++ standard requirements, it is hard to argue that in the Solaris case
> e.g. ISO-8859-1 execution charset would be some special character set where ?
> character represents all Unicode characters which don't have a representation
> in the character set in addition to ?.

I've now started digging into this myself.

* Solaris iconv(1) says

   output. If no conversion exists for a particular character,  an  imple-
   mentation-defined conversion is performed on this character.

* This seems to at least partially match with XPG7:

-s  Suppress any messages written to standard error concerning invalid
characters. When -s is not used, the results of encountering invalid
characters in the input stream (either those that are not valid
characters in the codeset of the input file or that have no
corresponding character in the codeset of the output file) shall be
specified in the system documentation. The presence or absence of -s
shall not affect the exit status of iconv.

  AFAIU that's related to what Solaris iconv(1) does, although they
  don't specify the output '?' and produce no message.  However, they
  still exit with 0, which seems wrong to me.

I've not yet tried to understand what either iconv(3) has to say on the
matter.

> I'm afraid we don't want to maintain iconv replacement inside of libcpp 
> though.

Agreed.

[Bug analyzer/110483] [14 Regression] Several gcc.dg/analyzer/out-of-bounds-diagram-*.c tests FAIL

2024-02-29 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 there a config/cfarm machine you see the out-of-bounds-diagram-3.c failure
> on?

GCC on Solaris is bi-arch by default, so this should be a matter of
running the testsuite with both -m32 and -m64, as described in
install.texi (Passing options and running multiple testsuites).

Since properly quoting RUNTESTFLAGS can be trick, I usually use a
site.exp instead like

global target_list

case "$target_triplet" in {
{ "sparc-*-solaris2*" } {
set target_list { "unix{,-m64}" }
}
}

and point the DEJAGNU env variable to its path.

[Bug modula2/102344] gm2/pim/fail/TestLong4.mod FAILs

2024-02-29 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 this was misjudged.  I suspect this patch is a
> candidate for back porting to 13.

It wouldn't hurt given that it's low-risk.  However, I'm concentrating
on 14 right now to finally get cleaner results on Solaris.

Thanks.

[Bug modula2/102344] gm2/pim/fail/TestLong4.mod FAILs

2024-02-29 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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.

[Bug tree-optimization/107855] gcc.dg/vect/vect-ifcvt-18.c FAILs

2024-02-26 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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, but fails otherwise.

I can reproduce things in a VM now: when it doesn't have avx support,
the test is compiled with -msse2 only and FAILs both for the dump and
execution:

FAIL: gcc.dg/vect/vect-ifcvt-18.c -flto -ffat-lto-objects  scan-tree-dump vect
"vectorized 3 loops"
FAIL: gcc.dg/vect/vect-ifcvt-18.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-ifcvt-18.c execution test
FAIL: gcc.dg/vect/vect-ifcvt-18.c scan-tree-dump vect "vectorized 3 loops"

The test aborts here:

Thread 2 received signal SIGABRT, Aborted.

#0  0xfe26e385 in __lwp_sigqueue () from /lib/libc.so.1
#1  0xfe2660ef in thr_kill () from /lib/libc.so.1
#2  0xfe19db82 in raise () from /lib/libc.so.1
#3  0xfe16b1f4 in abort () from /lib/libc.so.1
#4  0x08050d58 in main ()
at
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-ifcvt-18.c:34

and the dump shows

/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-ifcvt-18.c:28:17:
note:  === analyze_loop_nest ===
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-ifcvt-18.c:28:17:
note:   === vect_analyze_loop_form ===
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-ifcvt-18.c:28:17:
note:   using as main loop exit: 13 -> 14 [AUX: 0]
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-ifcvt-18.c:28:17:
missed:   not vectorized: unsupported control flow in loop.
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-ifcvt-18.c:28:17:
missed:  bad loop form.
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-ifcvt-18.c:28:17:
missed: couldn't vectorize loop

When I add avx support to the VM, the test PASSes.

It seems the test is missing some requirement here.

[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs

2024-02-26 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 symbols
of C++ libraries delivered with Solaris now and after a rebuild with
 changed.

Are there other important issues to consider with such a change?

[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3

2024-02-22 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 quoting is one part, certainly.  While clang falls back from <> to
"", gcc does not.  However, even if I change string.h locally to use "",
while this allows machine/trap.h to be found, the subsequent i386/trap.h
is still not found, neither by gcc nor by clang.

I have not idea what they are doing here, but the same construct is used
all over Frameworks/Kernel.framework/Headers.

> We do have control, IIRC, about adding the frameworks search path to "system"
> rather than "user".

That might be an option: I guess we should follow what clang does here.

[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3

2024-02-22 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers

More or less: the symlink is to Versions/Current/Headers.

> so either that's broken or we're failing to follow a symlink somehow.

I've checked: the original invocation is

/private/var/gcc/regression/master/14-gcc/build/gcc/xgcc
-B/private/var/gcc/regression/master/14-gcc/build/gcc/
/vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c
-fdiagnostics-plain-output -F. -S -o framework-1.s

with cc1 called like

 /private/var/gcc/regression/master/14-gcc/build/gcc/cc1 -quiet -v -F. -iprefix
/private/var/gcc/regression/master/14-gcc/build/gcc/../lib/gcc/x86_64-apple-darwin23.3.0/14.0.1/
-isystem /private/var/gcc/regression/master/14-gcc/build/gcc/include -isystem
/private/var/gcc/regression/master/14-gcc/build/gcc/include-fixed -D__DYNAMIC__
/vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c -fPIC -quiet
-dumpbase framework-1.c -dumpbase-ext .c -mmacosx-version-min=14.0.0
-mtune=core2 -version -fdiagnostics-color=never -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-urls=never
-fdiagnostics-path-format=separate-events -fdiagnostics-text-art-charset=none
-o framework-1.s

After the usual messages about nonexistant directories, we get to

#include <...> search starts here:
 .
 /private/var/gcc/regression/master/14-gcc/build/gcc/include
 /private/var/gcc/regression/master/14-gcc/build/gcc/include-fixed
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks
End of search list.

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/string.h

has 

#include 

which lives in

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/machine/trap.h

Given the above search list, "machine/trap.h" should work, but
 doesn't.

When using the bundled clang, I get

$ clang /vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c -F. -S
-o framework-1.s 
In file included from
/vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c:4:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/string.h:55:10:
error: 'machine/trap.h' file not found with  include; use "quotes"
instead
#include 
 ^
In file included from
/vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c:4:
In file included from
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/string.h:55:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/machine/trap.h:32:10:
fatal error: 'i386/trap.h' file not found
#include "i386/trap.h"
 ^
2 errors generated.

[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)

2024-02-22 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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. Are there any issues (SDK, linker, or otherwise) that we need to
>> report to Apple? Or that are already reported but we want taken more
>> seriously?
>
> Do they use [[clang::unsafe_buffer_usage]] then if __has_safe_buffers is
> defined
> even in -std=c11 etc. modes in the headers?

they do AFAICS: their  has no provision for different C std
versions (except the obvious like not using restrict before C99).

The section in question is

#if __has_cpp_attribute(clang::unsafe_buffer_usage)
#define __has_safe_buffers 1
#define __unsafe_buffer_usage [[clang::unsafe_buffer_usage]]
#elif __has_attribute(unsafe_buffer_usage)
#define __has_safe_buffers 1
#define __unsafe_buffer_usage __attribute__((__unsafe_buffer_usage__))
#else
#define __has_safe_buffers 0
#define __unsafe_buffer_usage
#endif

with a long comment explaining the use with clang -Wunsafe-buffer-usage.

[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)

2024-02-22 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 issue left (the gcc.dg/framework-1.c failure) so far seems to
>> be an issue with gcc not setting include paths correctly for frameworks.
>
> Please raise a separate BZ for that - it's a bit surprising (I would have
> expected more fails if that was not working).

Done now: PR target/114049, gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3.

[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)

2024-02-22 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 local (incomplete) 
>> workaround.
>
> I haven’t yet tested Xcode 13.3 myself, and have only followed the PRs from 
> far
> away. Are there any issues (SDK, linker, or otherwise) that we need to report
> to Apple? Or that are already reported but we want taken more seriously?
>
> I can use my channel through Homebrew to get them to prioritise it to some
> extent. It’s probably too late for 13.3 at this point, but we should get it
> fixed anyway for later.

I don't think so (otherwise I'd hopefully done it myself already ;-)

The only issue left (the gcc.dg/framework-1.c failure) so far seems to
be an issue with gcc not setting include paths correctly for frameworks.

[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs

2024-02-22 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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, now I remember: they had to be adjusted back in the day for various
omissions on Solaris and Tru64 UNIX.

During my recent test bootstrap, they didn't show up because I had
changed  and sol2.h's INT8_TYPE etc. in lockstep, so no
inconsistencies occured.

[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)

2024-02-22 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 tested fix.

Thanks a lot for the patch.  I've now re-bootstrapped trunk on macOS 14
with it applied instead of the local (incomplete) 
workaround.  With one unrelated exception

+FAIL: gcc.dg/framework-1.c (test for excess errors)

test results with Xcode 15.1 and 15.3 beta 3 are now identical.

[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs

2024-02-21 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 __INT8_TYPE__ signed char
>> 
>>   With very few exceptions, clang uses the default definitions of the
>>   intN_t types everywhere.
>
> That's interesting. I think GCC defines those __INTn_TYPE__ macros after
> inspecting the target headers (assuming the target provides  or
> ) to ensure they agree. I wonder if Clang intentionally deviated

Unfortunately not: gcc hardcodes all those types all over gcc/config
(e.g. sol2.h) as INT8_TYPE.

> from the Solaris headers to "fix" this issue, or if they just define
> __INT8_TYPE__ to signed char for all 8-bit targets because "obviously" that's
> correct for all targets (even though it isn't actually correct for Solaris).

I guess no one cared enough about Solaris in Clang to notice this.
There isn't even a test to check if Clang's internal idea of e.g. int8_t
and that of the system headers match (but neither does gcc).

> That means GCC and Clang will disagree about the mangling of a C++ function
> like
> void foo(int8_t);

As I found, they won't: while their internal definitions of
__INT8_TYPE__ differ, when one wants to use int8_t, one needs to include
a corresponding header (//), thus will
always get what the header defines.

Only when using __INT8_TYPE__ directly will you get the mangled form of
the compiler's internal idea of int8_t.

To check what happens, I've re-run last night bootstraps (sparc and x86)
with  changed to define int8_t and friends as signed
char, at the same time modifying gcc/config/sol2.h to match.

The bootstrap (i386 so far, sparc still running, though I don't expect
any difference) went without issues: the only regression seen is

+UNRESOLVED: gdc.test/runnable_cxx/stdint.d   compilation failed to produce
executable
+UNRESOLVED: gdc.test/runnable_cxx/stdint.d -shared-libphobos   compilation
failed to produce executable

where the executable fails to link:

Undefined   first referenced
 symbol in file
_Z15testCppI8Manglechchch   /var/tmp//ccJLlOBa.o

This test has D (stdint.d) and C++ (extra-files/stdint.cpp) components,
checking the gdc and g++'s ideas of various types match.  Unlike C/C++,
where the definition of int8_t is from , D has it's
equivalent in libphobos/libdruntime/core/stdc/stdint.d which will have
to be adjusted, too.

>>   However, the question remains how much that counts: given clang/llvm
>>   has seen years of neglect on Solaris, I wonder how much actual code is
>>   really built with it on Solaris.
>> 
>> * The Oracle Studio 12.6 cc has no definition of __INT8_TYPE__ at all
>>   AFAICT.  If that's true, one could change the type's definition simply
>>   by adjusting , which would be nice and easy.
>
> I think those macros are a GCC thing not required by any standard. Oracle
> Studio can just rely on  being present, because they know that's 
> true
> for Solaris. GCC can't (or couldn't historically) rely on  being
> present for all targets so needed some other way to make those types 
> available.

I guess so: I just meant to find out if cc/CC has it's own idea of the
types apart from the system headers.  However, going forward, this can
certainly learned from Oracle.

I'll think given the information so far, I'll take the idea of changing
int8_t for C99+ conformance to them and see what they think.

[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs

2024-02-21 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 assume that int8_t is char on Solaris, rather than signed char?
>>
>> This actually violates the C and C++ standards, which require that intN_t is 
>> a
>> signed integer type, and C 6.2.5 says "There are five standard signed integer
>> types, designated as signed char, short int, int, long int, and long long 
>> int."
>> So char isn't allowed, it should be signed char.
>
> I've done some digging now: / were
> introduced into Solaris 2.6 (the file dates from Jul 16 1997), way
> before the C99 standard was finalized.

Further research has uncovered some interesting facts:

* Neither the SysV SPARC psABI (3rd Edition, 1996) nor the original i386
  psABI (4th Edition, 1997) specify int8_t at all.  Actually no wonder
  because both predate C99.

  However, even the current Intel386 psABI 1.1 (2015) has nothing here,
  nor does the AMD64 psABI 1.0 (2024).

  To my astonishment however, the SPARC Compliance Definition 2.4.1
  (1999), defacto if not in name the SPARC V9 psABI, lists in Figure
  6-140: , p.6P-13:

  typedef signed char int8_t;

  So it seems at least Solaris/SPARCV9 violates its own ABI ;-(

* When checking clang, there were more surprises:

#define __INT8_TYPE__ signed char

  With very few exceptions, clang uses the default definitions of the
  intN_t types everywhere.

  However, the question remains how much that counts: given clang/llvm
  has seen years of neglect on Solaris, I wonder how much actual code is
  really built with it on Solaris.

* The Oracle Studio 12.6 cc has no definition of __INT8_TYPE__ at all
  AFAICT.  If that's true, one could change the type's definition simply
  by adjusting , which would be nice and easy.

[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs

2024-02-20 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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.

[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs

2024-02-20 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 still be a break.

Still, given how serious Sun/Oracle is about ABI compatibility (and
always has been), I'm doubtful they would be amenable to the idea.

[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs

2024-02-20 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 violates the C and C++ standards, which require that intN_t is a
> signed integer type, and C 6.2.5 says "There are five standard signed integer
> types, designated as signed char, short int, int, long int, and long long 
> int."
> So char isn't allowed, it should be signed char.

I've done some digging now: / were
introduced into Solaris 2.6 (the file dates from Jul 16 1997), way
before the C99 standard was finalized.

I've looked around the WG14 archive, and some drafts after that date
(N737 (1997-06-26), N788 (1997-11-17), N851 (1998-09-22)) do have the
`signed integer type' wording.  Unfortunately, all of the previous ones
(which would have been the basis of the Solaris implementation) are no
longer available.

[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)

2024-02-20 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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.

> i.e. if the header is not actually standard-conforming - perhaps there's time
> to get the released SDK fixed (did you raise a feedback?)

Not yet, but I mean to.  However, it's better to have a clean
understanding if the code is wrong first.

[Bug rtl-optimization/60045] gcc.dg/atomic/c11-atomic-exec-[23].c compilation times out

2024-02-19 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 32-bit gcc.dg/atomic/c11-atomic-exec-2.c testcase on my
current SPARC build systems:

* colima (4.267 GHz SPARC-S7):

real  15.13
user  14.70
sys0.10

* gamalama (5.067 GHz SPARC-M8):

real  10.84
user  10.49
sys0.06

While I still have an ancient 1.165 GHz UltraSPARC-T2 system around
(where I originally reported the slow compilation), I haven't done a GCC
build there in ages.

I'd argue that this is no longer an issue on current systems.

[Bug tree-optimization/113910] [12/13 Regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC

2024-02-14 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 -fno-checking which should
> get you reasonably close)

I've done a --enable-checking=release build on trunk and compare compile
times of the -save-temps with g++ 11.4.0:

$ time cc1plus -fpreprocessed AMDGPUDisassembler.cpp.ii -quiet -mcpu=v9 -O
-std=c++17 -o AMDGPUDisassembler.cpp.s

* 11.4.0:

real2:04.33
user2:03.86
sys0.30

* 14.0.1:

real2:17.58
user2:16.47
sys0.87

[Bug tree-optimization/113910] [12/13/14 regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC

2024-02-13 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 you try that if you are comparing compile times?
> Some of the slow down is definitely related to that:
>>  tree SSA verifier : 12.28 ( 1%) 0.02 ( 0%) 12.12 ( 1%) 0 ( 0%)
>> tree STMT verifier : 18.62 ( 1%) 0.00 ( 0%) 18.79 ( 1%) 0 ( 0%)
>>  CFG verifier : 9.77 ( 0%) 0.01 ( 0%) 10.01 ( 1%) 0 ( 0%)
>>  verify RTL sharing : 12.45 ( 1%) 0.01 ( 0%) 12.46 ( 1%) 0 ( 0%)
>
>
> For an example.

13.2.0 takes

real  19.59
user  16.05
sys3.43

but was still in the half-hour range with the original full set of
flags.  I'll retry that and report.

[Bug sanitizer/113785] c-c++-common/asan/swapcontext-test-1.c FAILs

2024-02-13 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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

[Bug sanitizer/113785] c-c++-common/asan/swapcontext-test-1.c FAILs

2024-02-12 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 ucontext_t structure have
   changed as they apply to inputs to makecontext(). Prior to Solaris  10,
   the  ss_sp member of the uc_stack structure represented the high memory
   address of the area reserved for the stack. The ss_sp member now repre-
   sents  the  base  (low  memory  address), in keeping with other uses of
   ss_sp.

   This change in the meaning of ss_sp is now the  default  behavior.  The
   -D__MAKECONTEXT_V2_SOURCE  compilation  flag  used  in Solaris 9 update
   releases to access this behavior is obsolete.

To preserve, binary compatiblity, the old behaviour of makecontext() has
been retained, and the following snippet in  ensures that a
different function with the new behavious is called from user code
instead:

/* makecontext removed in SUSv4 (XPG7, UNIX V7) */
#if !defined(_XPG7) || defined(__EXTENSIONS__)
#ifdef __sparc
#ifdef __PRAGMA_REDEFINE_EXTNAME
#pragma redefine_extnamemakecontext __makecontext_v2
#else
#define makecontext __makecontext_v2
#endif
#endif  /* __sparc */
#endif  /* !defined(_XPG7) || ... */

However, libasan knows nothing about this and just intercepts unadorned
makecontext, but this interceptor is never called.

I've got a patch (attached for reference) that changes the makecontext
interceptor to call __makecontext_v2 instead on Solaris/SPARC.  With
this, the c-c++-common/asan/swapcontext-test-1.c test now PASSes on
Solaris/SPARC.

I'm going to submit it upstream soon.

[Bug d/104739] gdc.test/runnable/mangle.d etc. FAIL with Solaris as

2024-02-05 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 doing this.  With this patch applied locally, adding
DejaGnu support for the new annotation proved to be as easy as I'd
suspected.

[Bug d/104739] gdc.test/runnable/mangle.d etc. FAIL with Solaris as

2024-02-02 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 think could be done is

* Add "//UTF-8 chars" comments to testmodule.d and ufcs.d; mangle.d
  already has one.

* Make gdc-utils.exp (gdc-convert-test) check for those annotations,
  adding

  // { dg-require-effective-target ucn}

  if found.

The new annotations would have to go upstream, I believe.  WDYT?

[Bug target/113700] libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16

2024-02-02 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 demoted to local.

IIUC, this happens because the __PFX__ handling (substitution by
$(LIBGCC_VER_GNU_PREFIX) as needed) is only applied to libgcc-std.ver.in
by Makefile.in.  In the i386/libgcc-*.ver files, this substitution
doesn't happen, the literal "__PFX__fixxfbitint" etc. symbols are not
found in any object, so the unprefixed ones are turned local.

>From what I could see in config.host, LIBGCC_VER_GNU_PREFIX only applies
to non-x86 targets.  Maybe we can just remove __PFX__ from
i386/libgcc-*.ver?  Jakub?

[Bug tree-optimization/113706] c-c++-common/pr103798-2.c FAILs as C++

2024-02-02 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 C++ source, std::memchr is used and GCC doesn't treat std::memchr as
> BUILT_IN_MEMCHR.

I see.  I'm testing a patch to directly define/declare NULL, size_t and
memchr instead of including .  This should still test what the
testcase is supposed to test, I believe.

[Bug preprocessor/105608] [11/12/13/14 Regression] ICE: in linemap_add with a really long defined macro on the command line r11-338-g2a0225e47868fbfc

2024-01-30 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 and then fix it
> properly for GCC 15. I did not consider that it might output different wrong
> locations for different platforms, but I could buy that it may happen, for a
> similar reason why this switched from being silently broken to ICEing since
> r11-338 which was seemingly unrelated. It seems like in one case the wrong
> location is inside the header file and in the other case, the wrong location 
> is
> the line just following the include. It may have to do with line endings or
> some other issue with the treatment of EOF? If this test is causing problems 
> we

It's still weird given that it's exactly the same version of Solaris on
both SPARC and x86.

> could just skip it on some architectures maybe? Once the underlying issue is

I guess that's best for now.  I'll check if the test behaves differently
for a 64-bit-default (amd64-pc-solaris2.11) compiler.

> fixed, the location (line 2 of the .C file) will be correct everywhere. I am
> curious why it gets a different wrong output though, if there is a compile 
> farm
> machine with this architecture I could look into it.

There's no Solaris/x86 system in the cfarm right now, unfortunately.
The only one runs Solaris 11.3/SPARC, where the test works just like
everywhere else.

That said, I've accquired systems to add to the cfarm that will both be
running current Solaris 11.4 (SPARC and x86).  I'm working on installing
and integrating them as we speak, but I don't have an ETA yet.

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

2024-01-24 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 libatomic.1.dylib have been traded for
>> 
>> FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=single  -O2  (test for
>> excess errors)
>> Excess errors: 
>> ld: warning: duplicate -rpath
>> '/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/
>> libatomic/.libs' ignored
>> 
>> This is definitely progress ;-)
>
> hmm I wonder where this is coming from .. as you noted there is a bit of a
> tendency in the testsuite to add stuff somewhat randomly.

Right: I believe sometimes such duplication depends on whether you run
the test sequentially or in parallel.

FWIW, alloc_comp_1.f90 is linked like

spawn -ignore SIGHUP
/private/var/gcc/regression/master/14-gcc/build/gcc/testsuite/gfortran/../../gfortran
-B/private/var/gcc/regression/master/14-gcc/build/gcc/testsuite/gfortran/../../
-B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/./libgfortran/
/vol/gcc/src/hg/master/darwin/gcc/testsuite/gfortran.dg/coarray/alloc_comp_1.f90
-fdiagnostics-plain-output -fdiagnostics-plain-output -fcoarray=single -O2
-B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/./libatomic/
-B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/./libatomic/.libs
-B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/./libgfortran/.libs
-B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/./libatomic/.libs
-B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/./libquadmath/.libs
-lm -o ./alloc_comp_1.exe

In this case (by pure inspection) caf.exp includes both gfortran-dg.exp
and atomic-dg.exp.  The latter adds -B... itself.

[Bug target/112861] [14 regression] Most gdc tests FAIL on macOS 12+

2024-01-24 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 XC 15.1 CLT.
> testing more widely,

I've successfully tested the patch on both x86_64-apple-darwin23.2.0
with Xcode 15.1 CLT and x86_64-apple-darwin20.6.0 with Xcode 13.2 CLT.

macOS 11 results are clean as before, macOS 14 results almost so:

FAIL: gdc.dg/debug/trivial.d -gdwarf-2 -g3 (test for excess errors)
FAIL: gdc.dg/debug/trivial.d -gdwarf-2 -g3 -O (test for excess errors)
FAIL: gdc.dg/debug/trivial.d -gdwarf-2 -g3 -O3 (test for excess errors)

which are due a known dsymutil issue:

Excess errors:
warning: '.debug_macinfo' is not currently supported: file will be skipped
note: while processing
/private/var/folders/n9/ygx22vs12c5crsryv773x1k800021y/T/cc3IYcpb.o

Thanks.

[Bug modula2/113559] gm2/isolib/run/pass/seqappend.mod FAILs

2024-01-24 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 the signed sizetype CSSIZE_T.

I've just successfully tested this version on both i386-pc-solaris2.11
and sparc-sun-solaris2.11.  Thanks.

[Bug testsuite/113558] [14 regression] gcc.dg/vect/vect-outer-4c-big-array.c etc. FAIL

2024-01-24 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 the patch on sparc-sun-solaris2.11 last night and all but
one of the failures are gone.  Seems you missed

FAIL: gcc.dg/vect/vect-reduc-pattern-2a.c scan-tree-dump-times vect
"vect_recog_widen_sum_pattern: detected(?:(?!failed)(?!Re-trying).)*succeeded"
1

Thanks for the quick fix.

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

2024-01-19 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
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 need them for
>> > providing run paths at test time.  BUT, we do not want duplicates
>> > (since, that
>> > triggers a different warning for some Xcode versions, and is
>> > inefficient anyway
>> > - albeit probably a very minor contribution to testing time).
>> 
>> Still there is going to be an impact, even on non-Darwin.  However, this
>> duplication of -B and -L options is present all over the testsuite
>> already, just nobody cared to do something about it so far.  Those Xcode
>> 15 ld warnings my change this, though...
>
> Actually, since -B produces a -L for every -B directory that exists, if we add
> -B we really ought to omit the -L if it's the same - otherwise we get useless
> duplicates on the link line.  Do you know of any exception to the B implies L?

No.  TBH I only really knew about -B to find e.g. library-specific spec
files, not for libraries themselves.

  1   2   3   4   >