https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120188
--- Comment #4 from Bruno Haible ---
> I suspect gm2-15.1 is the same.
Yes, in 15.1.0, with the option -fm2-plugin, I get the same output as you
showed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120188
--- Comment #2 from Bruno Haible ---
(In reply to Richard Biener from comment #1)
> Do you have the m2rte plugin?
Yes, and it has not been used since I installed it:
$ LC_ALL=C ls -lu
/darch/x86_64-linux-gnu/gnu-inst-gcc/15.1.0/lib/gcc/x86_64-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120189
Bug ID: 120189
Summary: documented link command does not work
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120188
Bug ID: 120188
Summary: documented example does not work
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119959
--- Comment #11 from Bruno Haible ---
(In reply to Sam James from comment #10)
> Dupe. See https://gitlab.com/gnu-clisp/clisp/-/merge_requests/12 too.
>
> *** This bug has been marked as a duplicate of bug 118779 ***
Thanks Sam, 1. for the ana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
Bug 87403 depends on bug 108694, which changed state.
Bug 108694 Summary: need a new warning option for preparing migration to ISO C23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694
Bruno Haible changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119959
--- Comment #2 from Bruno Haible ---
Created attachment 61207
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61207&action=edit
foo.c compiled by gcc 15.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119959
--- Comment #1 from Bruno Haible ---
Created attachment 61206
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61206&action=edit
foo.c compiled by gcc 14.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119959
Bug ID: 119959
Summary: [15 regression] simple loop miscompiled into an
endless loop
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116865
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #6 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119915
Bug ID: 119915
Summary: Sprintf1 repeats the entire format string if it starts
with a directive
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119622
Bruno Haible changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
--- Comment #22 from Bruno Haible ---
(In reply to Joseph S. Myers from comment #21)
> If we want such checking, it should be done in CI (similar to the CI that
> verifies generated files that are checked in have been correctly
> regenerated), n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
--- Comment #20 from Bruno Haible ---
Joseph,
When you integrate PO files into GCC's git, would you be willing to install the
newest GNU gettext release, in order to get error checking from "msgfmt -c"?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
--- Comment #19 from Bruno Haible ---
Jakub,
(In reply to Jakub Jelinek from comment #18)
> ... if during patch review the submitter is reminded to
> post a patch against gettext, there could be a few months before it is
> actually needed (Feb-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
--- Comment #17 from Bruno Haible ---
Jakub, Eric,
What's your take on comment #9 and comment #11? How would you like the GCC team
and GNU gettext developers to collaborate in the future?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
--- Comment #12 from Bruno Haible ---
(In reply to Jakub Jelinek from comment #10)
> Is it just about nice to have verification or does msgfmt etc. refuse to
> include translations which contain unknown format specifiers?
When msgfmt is invoked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
--- Comment #9 from Bruno Haible ---
Jakub Jelinek wrote:
> I thought it is the gettext utilities which are supposed to verify this kind
> of stuff, but maybe it hasn't been taught about some GCC format strings yet.
Yes, that is the case: gcc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
--- Comment #11 from Bruno Haible ---
* Another possible idea: The GCC team would agree that all future extensions of
GCC/GFC-internal format follows the following process:
1. The GCC extends the specification of these format strings, but does n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119623
Bug ID: 119623
Summary: broken links in the documentation
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119622
Bug ID: 119622
Summary: runtime libraries are not installed after "make
install"
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #9 from Bruno Haible ---
> But the callee is still allowed to assign the whole struct through the
> non-const pointer.
Oh, I see. Yes,
void
foo (struct S *s)
{
s[-1] = s[0];
}
would disable the optimization.
Yeah, then it need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #6 from Bruno Haible ---
> If you do
> struct S { char a[4]; char b[4]; };
> extern void foo (struct S *);
Yeah, but the submitted case looks more like
struct S { const char a[4]; const char b[4]; };
extern void foo (struct S *);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #4 from Bruno Haible ---
> So, you're basically asking for interprocedural optimization
No, I'm basically asking for type analysis: The compiler could note that the
struct has an "all fields are const" property, and that this is eno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
Bug ID: 119312
Summary: Constant array not allocated in read-only segment
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119311
Bug ID: 119311
Summary: musttail attribute ineffective at -O0 and -O1
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118015
Bug ID: 118015
Summary: bogus "check for NULL after already dereferencing it"
warning
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118013
Bug ID: 118013
Summary: bogus "infinite loop" warning
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117023
--- Comment #5 from Bruno Haible ---
(In reply to Jakub Jelinek from comment #4)
> I think it is just fine to call strncat (s, NULL, 0); because it will
> read no more than 0 characters from src, but I think it is problematic to
> call strncat (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117233
--- Comment #1 from Bruno Haible ---
Setting UBSAN_OPTIONS does not appear to have an influence either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117233
Bug ID: 117233
Summary: UBSAN should catch undefined behavior in realloc
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117023
--- Comment #3 from Bruno Haible ---
The runtime errors regarding bsearch, qsort, memccpy, wcsncpy, wcsncmp, wcsncat
need to be fixed in the glibc header files.
However, the runtime error regarding strndup and the crash in wcsncat come from
GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117023
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116736
Bug ID: 116736
Summary: missing diagnostic for out-of-bounds array access
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116735
Bug ID: 116735
Summary: ICE in build_counted_by_ref
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116481
--- Comment #7 from Bruno Haible ---
(In reply to Richard Biener from comment #6)
> For portability you likely want to convert the function pointer to uintptr_t
> and only that to char */long *. That might also avoid GCCs diagnostic.
Thanks fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116481
--- Comment #4 from Bruno Haible ---
(In reply to Andrew Pinski from comment #3)
> The error message happens on x86_64 also.
Indeed.
> Note I think this code is undefined really unless you use the volatile.
Why? This code is accessing read-on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116481
--- Comment #1 from Bruno Haible ---
A workaround is to declare the local variable 'tramp_address' volatile:
= foo.c =
extern void tramp ();
int is_trampoline (void* function)
{
void* volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116481
Bug ID: 116481
Summary: Compilation error caused by -Warray-bounds and -O2
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116426
--- Comment #2 from Bruno Haible ---
(In reply to Andrew Pinski from comment #1)
> Most likely a missed optimization at -O1 ...
The warning occurs also at -O2 and -O6.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116426
Bug ID: 116426
Summary: [13/14 Regression] bogus -Wnull-dereference warning
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796
--- Comment #14 from Bruno Haible ---
(In reply to Joseph S. Myers from comment #13)
> Everything available with __attribute__ is also available with [[]];
> __attribute__((foo)) is [[gnu::foo]].
Indeed, according to
https://gcc.gnu.org/onlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #12 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659
--- Comment #12 from Bruno Haible ---
(In reply to Jakub Jelinek from comment #11)
> Are there some other targets which say canonicalize NaNs on simple moves?
No, it's only the flds, fldl, fldt instructions on x86 and x86_64. In my
testing on o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54848
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #2 fro
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
Severi
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 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #16 f
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 bug
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 expressio
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 ; e
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&action=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
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #11 f
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 noth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113553
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #12 f
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 glib
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&action=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 -fvar-tracking
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 firs
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,
- bu
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 no
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 fr
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
Compon
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&action=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&action=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
Se
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
Compo
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 ha
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&action=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&action=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: other
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
Compo
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
Com
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*' w
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&action=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
Component
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: norma
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
> optimizin
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&action=edit
test case bar2.c
Find attached a modified test case. I changed the code to
map[i].al
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 (__bui
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: n
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
Pri
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
Co
1 - 100 of 121 matches
Mail list logo
