https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114309
--- Comment #11 from M Welinder ---
> Anyway, in GCC's testcase we have:
>
> 9 if (a == 123)
> 10 [[likely]] c = 5; // { dg-warning "both" }
> 11 else
> 12 [[likely]] b = 77;
> Here we have two possible paths, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114309
--- Comment #1 from M Welinder ---
Created attachment 57672
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57672=edit
Preprocessed source code
++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
g++ warns over the following program which uses [[unlikely]] for aborting error
reporting and conditionally chooses between two error messages:
# /usr/local/products/gcc/13.1.0/bin/g
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
In stl_algo.h, function __rotate for RandomAccessIterator lines 1280-1362 for
me, there are two divisions of integers:
__n %= __k;
on lines 1332 and 1356. They look harmless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #48 from M Welinder ---
It's your (1). gcc is changing a program that can rely on errno not being
changed to one where the C library can change it. (The current C library or
any future library that the resulting binary may be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #46 from M Welinder ---
Should "-std=c99" imply turning off these optimizations?
Creating calls to, say, strlen is incompatible with the C99 standard and
perhaps better limited to "-std=gnu-something" or an opt-in f-flag.
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 56636
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56636=edit
Preprocessed source code
It looks like compile-time conversion of -NAN and -(double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100903
--- Comment #11 from M Welinder ---
>/home/jwakely/gcc/14/include/c++/14.0.0/compare:160:5: note: declared here
> 160 | operator<=>(partial_ordering, __cmp_cat::__not_literal_zero auto)
> = delete;
> | ^~~~
I don't think we
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
The move assignment operator for _CachedPosition does not check for
self-assignment and it is not obviously safe for other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102725
M Welinder changed:
What|Removed |Added
CC||terra at gnome dot org
--- Comment #10
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 55119
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55119=edit
Preprocessed source code
The following piece of code, when compiled, shows a warn
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 54875
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54875=edit
Preprocessed source code
The follow
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 54861
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54861=edit
Preprocessed source code
The following prog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108108
--- Comment #4 from M Welinder ---
> Since it was not read again, the file is not considered included ...
It must have been read -- how else could gcc decide it was the same?
# strace -f gcc -MM c.c 2>&1 >Makefile | grep 'open.*\.h' | grep
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
This is a spin-off from bug 52566
#!/bin/sh
rm -f a.h b.h c.c c.o Makefile
(echo '#pragma once'; echo '// Killroy was here') > a.h
cp -p a.h b.h
# or even "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52566
--- Comment #5 from M Welinder ---
>From 108101:
Note also:
# gcc -MM c.c
c.o: c.c a.h
No b.h present!
I.e., Makefiles built with this will not pick up changes to the second file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108101
--- Comment #3 from M Welinder ---
Note also:
# gcc -MM c.c
c.o: c.c a.h
No b.h present!
iority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
# (echo '#pragma once'; echo 'Killroy was here') > a.h
# (echo '#pragma once'; echo 'Killroy was here') > b.h
# (echo '#include "a.h"'; ec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105960
--- Comment #4 from M Welinder ---
And added to the link lines too, btw.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105960
M Welinder changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 53130
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53130=edit
Source files and compile script
The attached archive shows a crash when running 32-bit binaries compiled with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #9 from M Welinder ---
I went back and looked at the proposal's revision history.
TLDR: this just adds to the confusion.
r3 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1099r3.html):
* I read it as allowing "using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #7 from M Welinder ---
Maybe kick it up to the C++ people?
Note, that if the code is not allowed then a type alias is no longer as
powerful as the original type. I really doubt that was intended.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #6 from M Welinder ---
elaborated-enum-specifier can be a elaborated-type-specifier. It is in the
"enum Hog H;" case.
But elaborated-enum-specifier is NOT an elaborated-type-specifier in the "using
enum Hog;" case,
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #3 from M Welinder ---
I actually think gcc is right there.
http://eel.is/c++draft/dcl.type.elab#nt:elaborated-enum-specifier
There are requirements for elaborated-type-specifier, but none for
elaborated-enum-specifier. It's a
mponent: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
See https://bugs.llvm.org/show_bug.cgi?id=52403
enum class Pig { Oink };
using Hog = Pig;
using enum Hog;
gcc 11.1 accepts this code. clang13 does n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103081
--- Comment #4 from M Welinder ---
That version of clang does not do "using enum" at all. clang 13 accepts this
code, but it has other issues with "using enum".
mponent: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
This code triggers an internal compiler error.
enum class Pig { OINK };
struct Hog {
using enum Pig;
Hog(Pig) { }
};
template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100903
--- Comment #2 from M Welinder ---
IMHO, nullptr_t would not be an improvement here. We would still have the
combination of:
(1) Correct usage causing a warning
(2) The warning hinting at using the incorrect nullptr instead.
(3) po>>
bool
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 50926
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50926=edit
Preprocesses source code
g++ emits a bogus warning when a std::par
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 50498
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50498=edit
Preprocesses source code
The documentation for std::filesystem::absolute sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96570
--- Comment #4 from M Welinder ---
> Explicit casts don't, and that's what I was questioning.
They most certainly do. That's an empirical statement from having gone over a
fairly large code base. It is not a statement that they should occur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96570
--- Comment #2 from M Welinder ---
> Why? If somebody wants to be explicitly stupid, that's their prerogative.
I agree with the second sentence.
However, casts are not a clear indication that somebody wants to be explicitly
stupid, at least
++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
This is a wishlist item. It's filed for C++ but would apply to C too.
It would be useful to have some mechanism to cause warnings to be emitted at
compile-time when values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96484
--- Comment #1 from M Welinder ---
I should note that not only does it allocate 500M, it also zeroes it.
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 49004
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49004=edit
Preprocessed ttt.C
This program takes ~0.25s per round in the loop for a to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96282
--- Comment #1 from M Welinder ---
Created attachment 48916
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48916=edit
preprocessed test program
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 48915
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48915=edit
shawn.C
With to-be-attached program I get an inter
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 48680
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48680=edit
Preprocessed ttt.C
C++ smart-poin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95209
--- Comment #4 from M Welinder ---
Sorry about the missing "-v". It is indeed a x86_64-suse-linux system. (It's
not internet facing or I'd go get the full output.)
"Implementation defined", yes, but the implementation is the os, not the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95209
--- Comment #1 from M Welinder ---
Created attachment 48567
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48567=edit
preprocessed test program
ty: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 48566
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48566=edit
test program
lexically_normal tran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90612
--- Comment #1 from M Welinder ---
fs_path.cc line 281 reads...
std::uninitialized_copy (to + oldsize, new_size - oldsize,
from + oldsize);
1st and 3rd arguments are swapped.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 46404
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46404=edit
Preprocessed source code
# /usr/local/products/gcc/9.1.0/bin/g++ -std=gnu++2a
-Wl,-rpath,/usr/lo
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 46170
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46170=edit
Preprocessed source code
The following code fails to compile with the debugging vers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
M Welinder changed:
What|Removed |Added
CC||terra at gnome dot org
--- Comment #22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
--- Comment #7 from M Welinder ---
Actually, it's more like 50+ instructions for destructing the string that
never (or almost never) needs destructing. 16 of those appear to need
linker fixup.
Sample for the C++14 mode:
call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
--- Comment #6 from M Welinder ---
> const_cast(s)="some longer string so it needs proper deletion";
Is that really valid?
This comes down to whether the temporary object creating with the function
call is constant [in which case the above is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
--- Comment #2 from M Welinder ---
Created attachment 44789
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44789=edit
Proof-on-concept patch
This proof-of-concept improves the situation dramatically. I don't
know if it is actually
iority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 44776
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44776=edit
Preprocessed source code
It appears that gcc is creating quite poor
: demangler
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
See https://sourceware.org/bugzilla/show_bug.cgi?id=23283
which is the same issue filed for gdb.
There is a patch over there too.
The demangler fails to demangle the symbol
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 43949
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43949=edit
Preprocessed source code
Priority: low
#include
int
main (int argc,char **a
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 41426
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41426=edit
g++ -E output, just in case it's needed
It looks like copying a pristine vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292
--- Comment #3 from M Welinder ---
The actual code I got this warning from was...
if (!lower_tail == (p > phalf)) {
where lower_tail is an int and p and phalf are doubles.
That's simply a comparison of two booleans. Note,
NCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
The warning introduced in bug 62183 is trigger-happy.
int
foo (int a, int b)
{
// Make it obvious that these ar
++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
"...this statement, but the latter is misleadingly indented as if it is guarded
by the 'if'"
--> "[...] as if it were [...]"
The guarding is hypothetical, s
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
g++ 6.1 fails to complain about "bar" below. The other two get the
expected "logical 'or' of collectively exhaustive tests is always true"
warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71393
--- Comment #3 from M Welinder ---
Bug 70847 claims "virtual" is necessary, so that is probably unrelated.
This bug is "virtual"-free.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71393
--- Comment #1 from M Welinder ---
Created attachment 38631
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38631=edit
Preprocessed version of MyClass.C
++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 38630
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38630=edit
MyClass.C
g++ -fsanitize=undefined -Wall -c -g -O2 MyClass.C
[hangs]
This didn't happen in
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 36325
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36325=edit
Preprocessed source code
# /usr/local/products/gcc/5.2.0/bin/g++ -fsanit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #14 from M Welinder terra at gnome dot org ---
1) Your malloc is too small. It has to be sizeof (biggest member).
So you're invoking undefined behavior.
Can you produce a specific authoritative reference for that statement?
I.e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #15 from M Welinder terra at gnome dot org ---
FYI, I filed a related bug for valgrind covering the problem with the
conditional jump being detected as undefined:
https://bugs.kde.org/show_bug.cgi?id=340392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #17 from M Welinder terra at gnome dot org ---
You keep saying undefined behaviour, but you keep avoiding
substantiating that claim.
Where, in the C99 standard, is the clause that makes things undefined?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #18 from M Welinder terra at gnome dot org ---
The example at strict-aliasing in the gcc man page covers a different
situation: you don't get to access a double via an int.
I get it.
But the standard says that in certain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #22 from M Welinder terra at gnome dot org ---
Given
GnmExprBinary res;
GnmExpr const *expr = (GnmExpr *)res;
the C standard does not define where the result of the conversion points;
How do you read C99's Section 6.5 #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
M Welinder terra at gnome dot org changed:
What|Removed |Added
Attachment #33809|0 |1
is obsolete
: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Created attachment 33809
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33809action=edit
Test program
I am observing valgrind errors from the to-be-attached reduced
test case. The oper test on line 36 should fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #1 from M Welinder terra at gnome dot org ---
Created attachment 33810
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33810action=edit
Preprocessed version of the program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #3 from M Welinder terra at gnome dot org ---
Why do you think so?
I think it is covered by this:
6.5 Expressions
[...]
[#7] An object shall have its stored value accessed only by
an lvalue expression that has one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
M Welinder terra at gnome dot org changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #8 from M Welinder terra at gnome dot org ---
That is a different issue. You access expr-func.argc and expr-func.func
in your if expression. And of course they are uninitialised.
No, I don't. You see, C has this feature
: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Compiling the (nonsense) program:
class x class
xx(x(x(x(x(x(x(x(x(x(x(x(x(x(x(x(x(x(x(x(x(x(x(x(x(x(x(x(x(x(x(x(x(x(x(x(x(x(
prints one error and starts using insane amounts of memory. GBs worth of it.
gcc version 4.8.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62169
--- Comment #5 from M Welinder terra at gnome dot org ---
I agree that anyone depending on map and multimap iterators to mix deserves
whatever happens as a result. It would, however, be nice g++ would reject such
programs outright. Currently
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
The two types
std::mapint,int::iterator
std::mapconst int,int::iterator
are the same when compiled normally, but different under _GLIBCXX_DEBUG.
I actually don't know if the standard allows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62169
--- Comment #1 from M Welinder terra at gnome dot org ---
Created attachment 33346
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33346action=edit
Preprocessed source code for normal case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62169
--- Comment #2 from M Welinder terra at gnome dot org ---
Created attachment 33347
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33347action=edit
Preprocessed source code for debug case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62169
--- Comment #3 from M Welinder terra at gnome dot org ---
A similar divergence of types occurs between the types
std::mapint,int::iterator
std::multimapint,int::iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
M Welinder terra at gnome dot org changed:
What|Removed |Added
CC||terra at gnome dot
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Created attachment 31199
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31199action=edit
sc.c
welinder@sherwood:~ gcc --version
gcc (SUSE Linux) 4.7.1 20120723 [gcc-4_7-branch revision 189773]
When sin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59089
--- Comment #1 from M Welinder terra at gnome dot org ---
Version and arch details:
welinder@sherwood:~ gcc -v -Wall -O0 sc.c -lm
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.7/lto-wrapper
Target
--- Comment #4 from terra at gnome dot org 2009-11-03 13:47 ---
I'm not sure whether using A in a union causes the implicitly-declared copy
assignment operator to be implicitly defined, but that seems to be what's
happening.
No, that's not quite it.
The requirement for union
--- Comment #6 from terra at gnome dot org 2009-11-03 17:44 ---
cp/class.c has code like this:
/* If any field is const, the structure type is pseudo-const. * /
if (CP_TYPE_CONST_P (type))
{
...
/* ARM $12.6.2: [A member initializer list] (or, for an
aggregate
ReportedBy: terra at gnome dot org
GCC host triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39934
ReportedBy: terra at gnome dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39603
gnu dot org
ReportedBy: terra at gnome dot org
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39547
for (... ? ... : ...)
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terra at gnome dot org
GCC build triplet: i686-pc-linux-gnu
GCC host
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terra at gnome dot org
GCC host triplet: i686-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33859
this.
--
Summary: -fPIC failure
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terra at gnome dot org
GCC build triplet: x86_64
: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terra at gnome dot org
GCC build triplet: i586-suse-linux
GCC host triplet: i586-suse-linux
GCC target triplet: i586-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30128
gnu dot org
ReportedBy: terra at gnome dot org
GCC build triplet: 686-pc-linux-gnu
GCC host triplet: 686-pc-linux-gnu
GCC target triplet: 686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25975
--- Comment #1 from terra at gnome dot org 2006-01-26 14:43 ---
Created an attachment (id=10732)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10732action=view)
Output from gcc-4.0.2 -E -ffast-math nan.c
gcc-4.0.2 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured
--- Comment #4 from terra at gnome dot org 2006-01-26 17:22 ---
ok, thanks. I'll prevent this by checking for __FAST_MATH__ in my code.
One could argue for a warning like
nan.c:13: warning: comparison is always false due to limited range of data type
for use of isnan and similarly
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terra at gnome dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: sparc-sun-solaris2.8, i586-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430
: Execution-time sizeof drops side effects
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terra at gnome dot org
are used
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terra at gnome dot org
CC: gcc-bugs at gcc dot
96 matches
Mail list logo
