https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54848
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114920
Bug ID: 114920
Summary: null_terminated_string_arg attribute does not warn for
non-nul-terminated strings
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114876
--- Comment #4 from Bruno Haible ---
(In reply to Jakub Jelinek from comment #3)
> Given that there are or at least were implementations which
> emitted no characters
Yes, musl libc emits/emitted 0 characters in this case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114876
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659
--- Comment #9 from Bruno Haible ---
(In reply to Andrew Pinski from comment #7)
> Much more related to PR 56831 and PR 57484 rather than the other two ...
Well, bug #56831 is more about function calls and the ABI, whereas this bug
here and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659
--- Comment #8 from Bruno Haible ---
(In reply to Andrew Pinski from comment #6)
> I doubt there is not much to be done here.
I see it as an incorrect modelization of the x87 hardware, together with a
missing distinction in the common
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659
--- Comment #5 from Bruno Haible ---
Related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93271
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659
--- Comment #4 from Bruno Haible ---
Related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659
--- Comment #3 from Bruno Haible ---
Also reproducible in 64-bit mode, with '-mfpmath=387':
$ gcc -mfpmath=387 -Wall tf.c
$ ./a.out ; echo $?
0
$ gcc -mfpmath=387 -Wall -O2 tf.c
$ ./a.out ; echo $?
1
$ gcc -mfpmath=387 -Wall td.c
$ ./a.out ;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659
Bruno Haible changed:
What|Removed |Added
Build||x86_64-linux-gnu
Host|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659
--- Comment #1 from Bruno Haible ---
Created attachment 57913
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57913=edit
test case td.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659
Bug ID: 114659
Summary: gcc miscompiles a __builtin_memcpy on i386, leading to
wrong results for SNaN
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189
--- Comment #10 from Bruno Haible ---
It is fixed in
- glibc 2.35 + gcc 11.4 (verified on Ubuntu 22.04),
- glibc 2.39 + gcc 13.2.1 (verified on Arch Linux 2024.04).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111289
--- Comment #6 from Bruno Haible ---
(In reply to John David Anglin from comment #5)
> Don't include on hpux to avoid conflicting type declarations
> for mode_t. This fixes test on houx.
Why not entirely remove the '#include '? There is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113553
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112836
--- Comment #5 from Bruno Haible ---
(In reply to John Paul Adrian Glaubitz from comment #4)
> I tried this patch but it does not address the issue with posix_spawn that I
> am seeing.
>
> Trying to build gcc from git on Linux sparc64 with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111288
Bruno Haible changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112836
--- Comment #1 from Bruno Haible ---
Created attachment 56779
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56779=edit
proposed fix
Although the error is not easily reproducible, it is easy to analyze
and fix:
The piece of error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112836
Bug ID: 112836
Summary: gcc fails when job control is used
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112708
--- Comment #10 from Bruno Haible ---
(In reply to Jakub Jelinek from comment #9)
> var-tracking is very compile time intensive,
> so it would significantly slow down -O0 compilation.
Indeed, these are the timings of "time make" that I observe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112708
--- Comment #8 from Bruno Haible ---
(In reply to Richard Biener from comment #7)
> It's -fvar-tracking, not -fvar-tracking-assignments. At -O0 debug info
> during the prologue is unreliable without that.
Then how about enabling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112708
--- Comment #6 from Bruno Haible ---
For comparison, what clang 17 with -fsanitize=address does in this situation,
is to not generate a stepping point at the function entry (xg-message.c:50).
The gdb 'step' command brings me directly to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112708
--- Comment #5 from Bruno Haible ---
(In reply to Andrew Pinski from comment #3)
> Also did you add -fvar-tracking-assignments ?
No, I haven't. I have specified CFLAGS=-ggdb, indicating that
- I don't care about the optimization level,
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112708
--- Comment #4 from Bruno Haible ---
(In reply to Andrew Pinski from comment #1)
> Is this with or without optimization?
Since in step 5, I specified CFLAGS=-ggdb, it is without optimization.
(configure sets CFLAGS="-O2 -g" only if CFLAGS is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112708
Bug ID: 112708
Summary: "gcc -fsanitize=address" produces wrong debug info for
variables in function prologue
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
--- Comment #3 from Bruno Haible ---
(In reply to Andrew Pinski from comment #1)
> Hmm. similar issue happen with gdb 5 years ago:
> https://lists.gnu.org/archive/html/bug-gnulib/2018-08/msg00151.html
Thanks; this is helpful. In this thread we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112098
--- Comment #1 from Bruno Haible ---
The code that gets executed inside gcc is maybe the one mentioned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907#c2 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112098
Bug ID: 112098
Summary: suboptimal optimization of inverted bit extraction
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111904
--- Comment #4 from Bruno Haible ---
I've added your fix to gnulib:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=f8ce7e779de156cb6d0fa51dbaef49cd255b7171
Thank you, Alexandre!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111814
--- Comment #2 from Bruno Haible ---
Created attachment 56111
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56111=edit
test case for long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111814
--- Comment #1 from Bruno Haible ---
Created attachment 56110
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56110=edit
test case for double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111814
Bug ID: 111814
Summary: on sh4, __builtin_nan* returns signalling NaNs instead
of quiet NaNs and vice versa
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111289
Bug ID: 111289
Summary: Unwarranted -Wanalyzer-va-arg-type-mismatch warning
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111288
--- Comment #4 from Bruno Haible ---
My proposed patch is a correction to commit
2b4e0415ad664cdb3ce87d1f7eee5ca26911a05b by Jakub Jelinek.
> patches should be posted to gcc-patches@ after reading
> https://gcc.gnu.org/contribute.html
I do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111288
--- Comment #2 from Bruno Haible ---
Created attachment 55841
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55841=edit
Rendering after applying the fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111288
--- Comment #1 from Bruno Haible ---
Created attachment 55840
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55840=edit
Rendering before applying the fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111288
Bug ID: 111288
Summary: formatting mistake in HTML documentation
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111287
Bug ID: 111287
Summary: doc: "strict ISO mode" definition is not up-to-date
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110149
Bug ID: 110149
Summary: std::format for pointer arguments allows a '0' option
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110143
--- Comment #4 from Bruno Haible ---
(In reply to Jonathan Wakely from comment #2)
> Those are the pointer specializations that are supported, and you can't use
> them to format int*
I see. If 'int*' was supported as a "pointer" here, 'char*'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110143
--- Comment #1 from Bruno Haible ---
Created attachment 55273
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55273=edit
test case bug2.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110143
Bug ID: 110143
Summary: std::format for pointer arguments does not work
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110112
Bruno Haible changed:
What|Removed |Added
Host||x86_64-linux-gnu
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110112
Bug ID: 110112
Summary: [11/12/13 Regression] gcc -fanalyzer takes an
excessive amount of time
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109914
--- Comment #3 from Bruno Haible ---
(In reply to Jan Hubicka from comment #2)
> The reason why gcc warns is that it is unable to prove that the function is
> always finite. This means that it can not auto-detect pure attribute since
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109995
Bug ID: 109995
Summary: Bogus warning about __builtin_memset, from
-Wstringop-overflow
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990
--- Comment #5 from Bruno Haible ---
Created attachment 55170
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55170=edit
test case bar2.c
Find attached a modified test case. I changed the code to
map[i].alias =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990
--- Comment #4 from Bruno Haible ---
> >
> > char *new_pool = (char *) realloc (string_space,
> > new_size);
> > if (new_pool == ((void *)0))
> > goto out;
> > if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990
Bug ID: 109990
Summary: [12 Regression] Bogus -Wuse-after-free warning after
realloc
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109916
Bug ID: 109916
Summary: warning reported despite of "#pragma GCC diagnostic
ignored", due to -flto
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109915
Bug ID: 109915
Summary: --suggest-attribute=const misdiagnoses static
functions
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109914
Bug ID: 109914
Summary: --suggest-attribute=pure misdiagnoses static functions
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109155
Bug ID: 109155
Summary: A note is diagnosed, without any warning or error
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694
--- Comment #4 from Bruno Haible ---
(In reply to Aaron Ballman from comment #3)
OK. So, except for this unlucky (*) choice of attribution in case of a conflict
between function declaration and function definition, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694
--- Comment #2 from Bruno Haible ---
(In reply to Florian Weimer from comment #1)
> “()” is going to be fine when matched with an empty parameter list in a
> definition, or an empty argument list in a call. I don't think it's
> necessary to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694
Bug ID: 108694
Summary: need a new warning option for preparing migration to
ISO C 23
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108231
Bug ID: 108231
Summary: g++ mistakenly reports ambiguity between equivalent
function declarations
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105527
--- Comment #3 from Bruno Haible ---
Created attachment 52955
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52955=edit
Patch to document also --with-zstd-include and --with-zstd-lib
Hi Martin,
The patch you added is pretty minimal: it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105527
Bug ID: 105527
Summary: configure option --with-zstd is not documented
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101494
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30267
Bruno Haible changed:
What|Removed |Added
Known to work||10.3.0, 11.1.0, 6.5.0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100735
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51793
--- Comment #4 from Bruno Haible ---
Correction to comment #3:
It works fine on
- Solaris 11.4 (gcc 7.3.0): foo.s contains '.p2align 4,,15'
- Solaris 11 OpenIndiana (gcc 7.2.0): likewise
- Solaris 11 OmniOS (gcc 9.3.0): foo.s contains '.p2align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51793
Bruno Haible changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98396
--- Comment #4 from Bruno Haible ---
(In reply to Richard Biener from comment #3)
> But note that while free() may clobber errno the state after it is undefined
> (it's not documented to set it to any specific value). So I'd argue the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98396
Bruno Haible changed:
What|Removed |Added
Known to work||4.0.4, 4.1.2, 4.2.4, 4.3.6,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98396
Bug ID: 98396
Summary: gcc wrongly assumes that free preserves errno
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98165
Bruno Haible changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98165
--- Comment #1 from Bruno Haible ---
Created attachment 49691
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49691=edit
Test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98165
Bug ID: 98165
Summary: Use of the UB sanitizer links the the program with
libstdc++
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98162
Bug ID: 98162
Summary: Documentation mentions non-existent option -mcet
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029
--- Comment #8 from Bruno Haible ---
> what is the reason to require that b >= 0 in all of this?
In the 1990ies there were portability problems with a%b, b < 0. ANSI C said
that the result was machine-dependent if a < 0 or b < 0. Fortunately
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029
--- Comment #5 from Bruno Haible ---
Nice! Thank you.
76 matches
Mail list logo
