https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89448
--- Comment #6 from Keith Thompson ---
Since Bug 91980 has been closed as a duplicate of this one, I'll
mention explicitly that another symptom of the bug is that this:
#include
complex x;
// _Complex y;
produces no diagnostic.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54486
Bug #: 54486
Summary: Spurious printf format warning mentions nonexistent
type 'sizetype'
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50662
Bug #: 50662
Summary: Incorrect diagnostic returning non-const array pointer
Classification: Unclassified
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53391
Bug #: 53391
Summary: Slightly misleading warning on printf format mismatch
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53391
--- Comment #2 from Keith Thompson
2012-05-18 18:26:31 UTC ---
The cleverness I was referring to was having diagnostics refer to an
appropriate typedef rather than to the original type (e.g., "size_t" rather
than "unsigned int"). I find this cle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54188
Bug #: 54188
Summary: Inconsistent __alignof__(long long)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54188
--- Comment #1 from Keith Thompson
2012-08-06 09:33:43 UTC ---
Forgot to mention: I compiled and executed the demo program as follows:
gcc alignof_bug.c -o alignof_bug && ./alignof_bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54188
--- Comment #3 from Keith Thompson
2012-08-06 19:28:37 UTC ---
The results of the _Alignof operator (new in the 2011 ISO C standard)
are the same as for the __alignof__ operator (not surprisingly).
N1370 (C11 draft) 6.5.3.4 paragraph 3 says:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33101
Keith Thompson changed:
What|Removed |Added
CC||Keith.S.Thompson at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33101
--- Comment #11 from Keith Thompson
2012-03-16 19:30:17 UTC ---
And since the C++ code is valid, the title of this bug should be changed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33101
--- Comment #14 from Keith Thompson
2012-03-16 21:41:18 UTC ---
On re-reading DR 577, I agree that it implies the current standard
says that only "(void)" is allowed, and in particular that a typedef
is not. I might have interpreted it different
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51115
Bug #: 51115
Summary: "-Wstrict-prototypes" is rejected for C++ (ok) but
accepted for Ada (meaningless)
Classification: Unclassified
Product: gcc
Version: 4.5.2
Statu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
Bug #: 51628
Summary: __attribute__((packed)) is unsafe in some cases
Classification: Unclassified
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #1 from Keith Thompson
2011-12-19 23:05:50 UTC ---
A commenter on stackoverflow points out that a possible fix would be to permit
the address of a member of a packed structure to be assigned only to a pointer
object that is itself dec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #3 from Keith Thompson
2011-12-20 00:36:52 UTC ---
I see no "-Walign" option, either in the versions of gcc I'm using or in the
online documentation. Were you thinking of a different option?
What I'm suggesting, primarily, is that t
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
Target Milestone: ---
Test case:
int main() {
int a;
&(a=0);
}
Demonstration:
$ g++ -c -Wunused-value confusing_warning.cpp
confusing_warning.cpp: In function ‘int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91314
--- Comment #1 from Keith Thompson ---
Irrelevant correction: The post was in comp.lang.c, not comp.lang.c++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87519
Keith Thompson changed:
What|Removed |Added
CC||Keith.S.Thompson at gmail dot
com
mponent: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
Target Milestone: ---
"gcc -std=c11 -pedantic-errors" does not issue a required
diagnostic for a declaration using type "complex". The
C standard requires "float _Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91980
--- Comment #3 from Keith Thompson ---
Not surprisingly, when I modify my "complex-bug.c" changing
#include
to
#include "complex.h"
and add a "complex.h file containing only
#define complex _Complex
the problem goes away (i.e., the c
NCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
Target Milestone: ---
$ gcc --version
gcc (GCC) 7.1.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free sof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584
--- Comment #1 from Keith Thompson ---
Tested on x86_64 Ubuntu 17.04, gcc 7.1.0 built from source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584
--- Comment #4 from Keith Thompson ---
I'm aware that the standard has not changed in this area from C90 to C99
to C11. The conversion is undefined behavior, not a constraint violation,
in all three editions.
If the conversion is forbidden, wha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584
--- Comment #6 from Keith Thompson ---
Andreas: As I understand it, POSIX requires conversions between
object pointers and function pointers to work only for the specific
values returned by dlsym().
In any case, that's not directly relevant to t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584
--- Comment #7 from Keith Thompson ---
I don't agree that this bug report is invalid. I see that the
Bugzilla interface lets me change the status. Would it be appropriate
to do so?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584
Keith Thompson changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584
--- Comment #12 from Keith Thompson ---
Andrew:
In my opinion, such conversions have undefined behavior (simply because
the standard does not define their behavior), but they are not forbidden.
The "-pedantic" and "-pedantic-errors" options, as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584
--- Comment #18 from Keith Thompson ---
Something I probably should have noticed earlier:
Why was this bug closed as a duplicate of bug 11234?
Bug 11234 complains that conversions between function pointer and void*
are accepted. This bug is exa
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
Target Milestone: ---
The line of code that causes the problem is from this answer on Stack Overflow,
posted by Alain Totouom: http://stackoverflow.com/a/3078/827263
: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
Target Milestone: ---
This program:
int main(void) {
goto *(void*)42;
}
shows a legal use of gcc's computed goto extension.
This program:
int main(void) {
goto *42;
}
results in the same gene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66318
--- Comment #6 from Keith Thompson ---
Thanks to this:
http://undeadly.org/cgi?action=article&sid=20160308204011
I've now constructed a case where compiling a malicious source file can cause
xterm to freeze.
The source file uses a UTF-8 charac
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
Target Milestone: ---
I'm using g++ 7.1.0, built from source, on Ubuntu 16.10 x86_64.
$ g++ --version
g++ (GCC) 7.1.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80648
Keith Thompson changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80648
--- Comment #4 from Keith Thompson ---
Then what does
> Issues with DR, accepted, DRWP, and WP status are NOT part of the
> International Standard for C++.
mean? The web page itself says that issues with DR status are not
part of C++11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80648
--- Comment #6 from Keith Thompson ---
Shall I submit a separate ticket against the documentation?
"info gcc" for gcc-7.1.0 has the following description for -std=c=+98 and
std=++03:
'c++98'
'c++03'
The 1998 ISO C++ standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80648
--- Comment #8 from Keith Thompson ---
That's a surprising interpretation of the word "amendment".
Searching isocpp.org and other sites, I haven't found any official reference
to an "amendment" to the C++ standard. The nearest thing I've found,
ty: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
Target Milestone: ---
I'm using gcc 7.2.0-8ubuntu3 on Ubuntu 17.10, x86_64.
$ cat c.c
void f(double a) { }
int main(void) {
int i;
f(
NCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
Credit goes to "Lumbering Lummox", the author of this Stack Overflow post:
http://stackoverflow.com/q/23747641/827263
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
Target Milestone: ---
This is an obscure problem, unlikely to occur in the real world.
I do not suggest handling it "correctly", whatever that might mean,
just de
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
Target Milestone: ---
Error messages include the (presumed) name of the source file in which
the error was detected. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66318
--- Comment #2 from Keith Thompson ---
Martin:
Good point. I don't suggest altering the string to which the __FILE__
macro expands, merely sanitizing file names to be displayed in error
messages.
I see my original description wasn't 100% clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66318
--- Comment #5 from Keith Thompson ---
Mikhail: Newlines in file names (either the actual file name or via a
#line directive) cause problems with __FILE__, though that particular
problem occurs only if there's an explicit reference to __FILE__.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
If a C++ program includes a standard header (I use in my example), a
typedef
typedef unsigned int uint;
becomes visible. The identifie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59945
--- Comment #1 from Keith Thompson ---
This came up in this question:
http://stackoverflow.com/q/21356275/827263
on Stack Overflow; the original version of the question used "uint" without
declaring it and compiled without error (at least without
mponent: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
"gcc --version" says
gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2
"uname -a" says
Linux bomb20 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014
x86_64 x86_64 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63611
--- Comment #1 from Keith Thompson ---
A bug report for a similar issue with clang is here:
http://llvm.org/bugs/show_bug.cgi?id=21327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #6 from Keith Thompson ---
In the test case for Bug 63611 (marked as a duplicate of this one)
we have:
element x[1];
element y[1];
element *const x0 = x;
element *const x1 = x0 + 1;
element *const y0 = y;
When th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #8 from Keith Thompson ---
I'm not (deliberately) considering anything other than the requirements
of the C standard.
The standard talks about an array object immediately following another
array object in the address space. Since tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #10 from Keith Thompson ---
I strongly disagree with your interpretation.
Do you believe that the authors of the standard meant it the way you do?
I suggest that the footnote:
> Two objects may be adjacent in memory because they ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #14 from Keith Thompson ---
The C standard requires that, if y "happens to immediately follow"
x in the address space, then a pointer just past the end of x shall
compare equal to a pointer to the beginning of y (C99 and C11 6.5.9p6).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087
Keith Thompson changed:
What|Removed |Added
Version|4.0.0 |5.3.0
--- Comment #13 from Keith Thomps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087
--- Comment #17 from Keith Thompson ---
I just took a quick look at the discussion on the gcc-patches mailing
list.
It's true that the standard doesn't classify plain "char" either as a
signed integer type or as an unsigned integer type.
But I
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
Target Milestone: ---
$ uname -a
Linux m5 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64
x86_64 x86_64 GNU/Linux
$ gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66618
--- Comment #3 from Keith Thompson ---
It would be easier to argue that gcc accepts "other forms of constant
expressions" if (a) those other forms were documented and (b) they were
accepted at all optimization levels.
Admittedly the standard do
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
Target Milestone: ---
#include
#include
int main(void) {
#ifdef __STDC_IEC_559_COMPLEX__
printf("__STDC_IEC_559_COMPLEX__ is defined as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108531
--- Comment #1 from Keith Thompson ---
After I submitted this, I found that this is probably a duplicate of:
https://sourceware.org/bugzilla/show_bug.cgi?id=15720
(I disagree with the resolution of that bug report.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108531
--- Comment #3 from Keith Thompson ---
In the latest C2X draft,
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf
Annex G still requires imaginary number support for any implementation
that defines __STDC_IEC_60559_COMPLEX__ or __STDC_I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108531
--- Comment #5 from Keith Thompson ---
FYI, I've sent an email to the C standard editors (the addresses at
the top of the N3054 draft) suggesting that imaginary number support
should be optional even if __STDC_IEC_559_COMPLEX__ and
__STDC_IEC_60
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
Target Milestone: ---
When a parameter is declared with the (new in C99) [static] syntax, and
the argument is a null pointer, the warning incorrectly refers to the
expected size in bytes of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986
--- Comment #1 from Keith Thompson ---
A similar case. The warning refers to the size in bytes, but unlike
the first case it's not incorrect, though referring to the length
would IMHO be clearer.
Note also that the warning appears twice. It onl
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
Target Milestone: ---
Source file:
```
#include
enum { toobig = UINT_MAX };
```
gcc version 11.2.0 on Ubuntu 20.04.4, x86_64
INT_MAX is 2147483647
UINT_MAX is 4294967295
The C11 and C17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105156
--- Comment #2 from Keith Thompson ---
Andrew, did you use "-std=c17 -pedantic-errors"? Both gcc and clang
correctly diagnose "enum { toobig = 0x7fff * 2U + 1U };".
I'm seeing weird behavior that I don't understand. Replacing the UINT_MAX
m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105156
--- Comment #4 from Keith Thompson ---
OK, that explains the bug.
It sounds like the code that suppresses warnings in system headers needs
to be a bit more clever. Using UINT_MAX here isn't an error in the header.
ty: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
Target Milestone: ---
When I compile this source file:
double bad(void) {
return (void*)0;
}
double good(void) {
return 42;
}
64 matches
Mail list logo
