https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119822
--- Comment #3 from M Welinder ---
Thanks. Confirmed working.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 61125
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61125&action=edit
Preprocessed source
Linking fails when std::stacktrace is used in a 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
--- Comment #13 from M Welinder ---
> The reason why full destructor is inlined is that we do not know what
> foo is doing and it may make the string bigger. "const" does not promise
> that the callee does not modify the object.
:-(
> So I th
++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 58987
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58987&action=edit
Preprocessed source code
I *think* the following ought to work with the "con
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 the
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&action=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 dynami
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&action=edit
Preprocessed source code
It looks like compile-time conversion of -
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 c
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&action=edit
Preprocessed source code
The following piece of code, when compiled,
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&action=edit
Preprocessed source co
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&action=edit
Preprocessed source code
The fo
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 -v
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
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.
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&action=edit
Source files and compile script
The attached archive shows a crash when running 32-bit binaries c
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 enu
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 http://eel.
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 se
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&action=edit
Preprocesses source code
g++ emits a bogus w
: 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&action=edit
Preprocesses source code
The documentation for std::filesystem::absolute
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 th
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 not
++
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 valu
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&action=edit
Preprocessed ttt.C
This program takes ~0.25s per round in the loop for
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&action=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&action=edit
shawn.C
With to-be-attached program I
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&action=edit
Preprocessed ttt.C
C+
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
compil
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&action=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&action=edit
test program
lexically_
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&action=edit
Preprocessed source code
# /usr/local/products/gcc/9.1.0/bin/g++ -std=gnu++2a
-Wl,-rpa
: 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&action=edit
Preprocessed source code
The following code fails to compile with the de
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:
callZ3fo
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 U
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&action=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&action=edit
Preprocessed source code
It appears that gcc is creatin
: 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&action=edit
Preprocessed source code
Priority: low
#include
int
main (int argc,char
: 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&action=edit
g++ -E output, just in case it's needed
It looks like copyin
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, that
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 hypot
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"
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&action=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&action=edit
MyClass.C
g++ -fsanitize=undefined -Wall -c -g -O2 MyClass.C
[hangs]
This didn't h
: 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&action=edit
Preprocessed source code
# /usr/local/products/gcc/5.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #22 from M Welinder ---
>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, then?
Doesn't that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #18 from M Welinder ---
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 circumstances you really do get
to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #17 from M Welinder ---
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 #15 from M Welinder ---
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 #14 from M Welinder ---
> 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., a reference to the sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
M Welinder changed:
What|Removed |Added
Attachment #33809|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #8 from M Welinder ---
> 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 for the && operator that i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
M Welinder changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #3 from M Welinder ---
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 of the following types:63
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #1 from M Welinder ---
Created attachment 33810
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33810&action=edit
Preprocessed version of the program
: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Created attachment 33809
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33809&action=edit
Test program
I am observing valgrind errors from the to-be-attached reduced
test case. The oper test on line 36 should f
: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Compiling the (nonsense) program:
class x class
x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62169
--- Comment #5 from M Welinder ---
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 this is accepted:
st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62169
--- Comment #3 from M Welinder ---
A similar divergence of types occurs between the types
std::map::iterator
std::multimap::iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62169
--- Comment #2 from M Welinder ---
Created attachment 33347
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33347&action=edit
Preprocessed source code for debug case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62169
--- Comment #1 from M Welinder ---
Created attachment 33346
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33346&action=edit
Preprocessed source code for normal case
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
The two types
std::map::iterator
std::map::iterator
are the same when compiled normally, but different under _GLIBCXX_DEBUG.
I actually don't know if the standard allows that, but if it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
M Welinder changed:
What|Removed |Added
CC||terra at gnome dot org
--- Comment #31
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59089
--- Comment #1 from M Welinder ---
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: x86_64-suse-linux
Confi
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Created attachment 31199
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31199&action=edit
sc.c
welinder@sherwood:~> gcc --version
gcc (SUSE Linux) 4.7.1 20120723 [gcc-4_7-branch revision 189
--- 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
--- 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.
T
nu dot org
ReportedBy: terra at gnome dot org
GCC host triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39934
: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terra at gnome dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39603
nassigned at gcc dot 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
mary: Wrong type 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-
Component: c
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
line" silences 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 do
: UNCONFIRMED
Severity: normal
Priority: 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
--- 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 simi
--- 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=10732&action=view)
Output from "gcc-4.0.2 -E -ffast-math nan.c"
> gcc-4.0.2 -v
Using built-in specs.
Target: i686-pc-
: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot 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
us: UNCONFIRMED
Severity: normal
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
e3(10);
return 0;
}
--
Summary: 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 o
rs 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
100 matches
Mail list logo
