https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #22 from John David Anglin ---
I was about to install a similar patch for hppa-hpux.
I think the builtin falls back to emitting sync libcalls when enabled or calls
to libatomic. Not sure whether the atomic support detection could b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #21 from Jørgen Kvalsvik ---
Does that mean that the feature detection of atomics, leading to the use
BUILT_IN_ATOMIC_FETCH_* is wrong? We use the BUILT_IN for emitting
instructions. It could be that it's the detection itself that ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #20 from John David Anglin ---
(In reply to John David Anglin from comment #19)
> It's not clear why gcov-30 passes on Linux. I searched the entire tree and
> couldn't find how TARGET_HAVE_LIBATOMIC gets set on Linux. Also, always
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #19 from John David Anglin ---
(In reply to Jørgen Kvalsvik from comment #18)
> Ok, thanks, I pushed a fix for the gcov %zu prints, at least for gcov.
Thanks.
> To recap:
>
> * gcov-pr86536.c sporadically fails? (which has to be u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #18 from Jørgen Kvalsvik ---
Ok, thanks, I pushed a fix for the gcov %zu prints, at least for gcov.
To recap:
* gcov-pr86536.c sporadically fails? (which has to be unrelated to these
prints)
* -fprofile-update=atomic warns (and fai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #17 from GCC Commits ---
The master branch has been updated by Jorgen Kvalsvik :
https://gcc.gnu.org/g:dd87540491de7242416751666089fcdbce434e7b
commit r16-493-gdd87540491de7242416751666089fcdbce434e7b
Author: Jørgen Kvalsvik
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #16 from John David Anglin ---
Your patch works for me:
https://gcc.gnu.org/pipermail/gcc-testresults/2025-May/846366.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #15 from Jørgen Kvalsvik ---
I don't know why it's only defined for rtems, but I would imagine it's either
an oversight, or that it's the only target with libatomic support without
hardware atomics. Is there a libatomic for hppa, or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #14 from John David Anglin ---
(In reply to Jørgen Kvalsvik from comment #13)
> (In reply to John David Anglin from comment #12)
> > With patch, gcov-29 now passes. But gcov-30 fails with excess errors
> >
> > FAIL: gcc.misc-tests/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #13 from Jørgen Kvalsvik ---
(In reply to John David Anglin from comment #12)
> With patch, gcov-29 now passes. But gcov-30 fails with excess errors
>
> FAIL: gcc.misc-tests/gcov-30.c (test for excess errors)
> Excess errors:
> /ho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #12 from John David Anglin ---
With patch, gcov-29 now passes. But gcov-30 fails with excess errors
FAIL: gcc.misc-tests/gcov-30.c (test for excess errors)
Excess errors:
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.misc-tests/gcov-30.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #11 from John David Anglin ---
(In reply to Jørgen Kvalsvik from comment #9)
> Created attachment 61335 [details]
> Patch: fix, printf properly on systems without %zu
>
> I just posted this on gcc-patches. It should fix the issue in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #10 from John David Anglin ---
(In reply to Richard Biener from comment #7)
> Possibly using %llu and (unsigned long long) casts on the value would be a
> good fix.
I tested this and it didn't completely fix fails:
FAIL: expected: '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #9 from Jørgen Kvalsvik ---
Created attachment 61335
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61335&action=edit
Patch: fix, printf properly on systems without %zu
I just posted this on gcc-patches. It should fix the issu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #7 from Richard Biener ---
Possibly using %llu and (unsigned long long) casts on the value would be a good
fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #6 from John David Anglin ---
On hppa, size_t is unsigned long. I'll test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #5 from Jørgen Kvalsvik ---
Does the pretty-print.cc test fail, too?
Anyway, the fix is simple, in a way -- we don't really need the full size_t
width (probably), so I'd wager it's harmless to change it to %u. It's not the
nicest ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #4 from John David Anglin ---
Guess this is a problem in other files:
bash-5.1$ grep zu *.cc
crc-verification.cc:fprintf (dump_file, "Checking %zu bit.\n", it_end);
crc-verification.cc:fprintf (dump_file, "Checking %zu bit.\
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #3 from John David Anglin ---
(In reply to Jørgen Kvalsvik from comment #2)
> Interesting. I looked at the attach'd .gcov file and it is filled with these:
>
> paths covered 1 of zu
>
> Does the target not support size_t with print
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #2 from Jørgen Kvalsvik ---
Interesting. I looked at the attach'd .gcov file and it is filled with these:
paths covered 1 of zu
Does the target not support size_t with printf("%zu")?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #1 from John David Anglin ---
Similar fails:
FAIL: gcc.misc-tests/gcov-30.c gcov: 0 failures in line counts, 0 in branch
percentages, 0 in condition/decision, 12 in prime-paths, 0 in return
percentages, 0 in intermediate format, 0 fa
22 matches
Mail list logo
