[Bug c/33193] slopiness in __real/__imag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33193 --- Comment #11 from Chris Lattner --- Cool, thanks for tidying this up Andrew!
[Bug c++/26426] Type layout bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26426 --- Comment #4 from Chris Lattner --- Works for me, I'm not following GCC bugs these days. Thanks, -Chris
[Bug c/33193] slopiness in __real/__imag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33193 Chris Lattner sabre at nondot dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #6 from Chris Lattner sabre at nondot dot org 2010-11-18 17:15:32 UTC --- http://gcc.gnu.org/onlinedocs/gcc/Complex.html#Complex still does not document what arguments are accepted to __real and __imag.
[Bug c/46509] New: -Wparentheses shouldn't warn about: A || Y foo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46509 Summary: -Wparentheses shouldn't warn about: A || Y foo Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: sa...@nondot.org Per the subject, -Wparentheses shouldn't warn about possible ||/ precedence issues if the operand to the or is always false or the operand to is always true. These should not warn: if (a || b 1) if (0 || a b) They shouldn't warn because even if the user is confused about precedence, the order of evaluation doesn't affect the result of the computation. This happens to come up frequently for coding standards that use messages in asserts, e.g.: assert(A == 1 || A == 3 some reason this property should hold); -Chris
[Bug middle-end/31878] Spurious warnings with -Wreturn-type due to not performing CCP/VRP in the front-end
--- Comment #10 from sabre at nondot dot org 2009-12-30 01:46 --- Yes, clang warns: $ clang t.c t.c:7:1: warning: control may reach end of non-void function [-Wreturn-type] } ^ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31878
[Bug middle-end/31878] Spurious warnings with -Wreturn-type due to not performing CCP/VRP in the front-end
--- Comment #8 from sabre at nondot dot org 2009-12-29 06:07 --- Clang does not produce diagnostics from the optimizer. We intentionally do not want to do this, because of the fragility of the diagnostics as the optimizer evolves. IMO it is much better to produce a consistent and predictable set of diagnostics rather than trying to avoid all false positives by relying on the optimizer to be tricky. -- sabre at nondot dot org changed: What|Removed |Added CC||sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31878
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #30 from sabre at nondot dot org 2009-12-10 23:44 --- FWIW, the darwin10 version of ___divdc3 comes from http://compiler-rt.llvm.org/ sounds like a bug there. -- sabre at nondot dot org changed: What|Removed |Added CC||sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug target/40171] GCC does not pass -mtune and -march options to assembler!
--- Comment #2 from sabre at nondot dot org 2009-05-25 00:46 --- This is very odd? What is the assembler doing that the compiler isn't? -- sabre at nondot dot org changed: What|Removed |Added CC||sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40171
[Bug preprocessor/35010] preprocessor loses leading whitespace
--- Comment #4 from sabre at nondot dot org 2009-04-27 01:31 --- If the definition is: #define debug(format, ...) format,## __VA_ARGS__) Then we should still get: Z, ); W, ); If the definition is: #define debug(format,...) format,##__VA_ARGS__) Then we should get: Z,); W,); (and gcc currently gets this right) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35010
[Bug preprocessor/35010] preprocessor loses leading whitespace
--- Comment #5 from sabre at nondot dot org 2009-04-27 01:31 --- Sorry I can't give a more detailed analysis of what is going on, I have no idea how the placemarker system works in gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35010
[Bug c++/38377] __builtin_constant_p(t) ? t : 1 is not considered a constant integer expression
--- Comment #6 from sabre at nondot dot org 2008-12-12 18:02 ---
Here are the testcases I checked in with the clang implementation of this if
you're interested:
// __builtin_constant_p as the condition of ?: allows arbitrary foldable
// constants to be transmogrified into i-c-e's.
char b[__builtin_constant_p((int)(1.0+2.0)) ? (int)(1.0+2.0) : -1];
struct c {
int a : ( // expected-error {{expression is not an integer constant
expression}}
__builtin_constant_p((int)(1.0+2.0)) ? (int)(1.0+
expr // expected-note {{subexpression not valid in an integer constant
expression}}
) : -1);
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38377
[Bug c++/38377] __builtin_constant_p(t) ? t : 1 is not considered a constant integer expression
--- Comment #7 from sabre at nondot dot org 2008-12-12 18:04 --- oh, that also has 'int expr;' at global scope earlier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38377
[Bug c++/38377] __builtin_constant_p(t) ? t : 1 is not considered a constant integer expression
--- Comment #5 from sabre at nondot dot org 2008-12-12 06:42 --- That is a lot more clear. Thank you for the explanation Joseph! I agree with you that if you want this to be acceptable that the folded version of the operand is really what is interesting. That seems much trickier to model though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38377
[Bug c++/38377] __builtin_constant_p(t) ? t : 1 is not considered a constant integer expression
--- Comment #1 from sabre at nondot dot org 2008-12-06 18:42 --- This is a bug in the C front-end. They need to use __builtin_choose_expr. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38377
[Bug c++/38377] __builtin_constant_p(t) ? t : 1 is not considered a constant integer expression
--- Comment #3 from sabre at nondot dot org 2008-12-06 21:31 --- Ok, so this is a special case when __builtin_constant_p is immediately the operand of ?:? Do you allow things like __builtin_constant_p(...)+0 as the operand? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38377
[Bug c++/11211] trivial static initializers of const objects should be done at compile time
--- Comment #6 from sabre at nondot dot org 2008-12-06 22:44 --- FWIW, llvm-g++ gets this right. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11211
[Bug c/37874] New: gcc sometimes accepts attribute in identifier list
GCC rejects the former, but not the later. void f2(y, __attribute__(()) x); void f3(__attribute__(()) x, y); -- Summary: gcc sometimes accepts attribute in identifier list Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37874
[Bug c/37874] gcc sometimes accepts attribute in identifier list
--- Comment #1 from sabre at nondot dot org 2008-10-20 01:08 --- It also accepts this: void f4(__attribute__(())); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37874
[Bug c/37874] gcc sometimes accepts attribute in identifier list
--- Comment #3 from sabre at nondot dot org 2008-10-20 02:10 --- as it turns out, f3 could also be considered valid in c89... because it makes x and y be implicit int's, not an identifier list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37874
[Bug tree-optimization/37867] inconsistent results on -O2 when reading bits from packed struct
--- Comment #3 from sabre at nondot dot org 2008-10-18 18:06 --- Does it work with -fno-strict-aliasing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37867
[Bug tree-optimization/37867] inconsistent results on -O2 when reading bits from packed struct
--- Comment #5 from sabre at nondot dot org 2008-10-18 18:11 --- Please clone/reopen this bug, it should work with -fno-strict-aliasing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37867
[Bug tree-optimization/37868] code that breaks TBAA is misoptimized even with -fno-strict-aliasing
--- Comment #1 from sabre at nondot dot org 2008-10-18 18:29 ---
Here is the testcase. I should work with -fno-strict-aliasing:
#include stdio.h
#include stdint.h
struct X {
unsigned char pad : 4;
uint64_t a : 64;
uint64_t b : 60;
} __attribute__((packed));
int main (void)
{
struct X x;
uint64_t bad_bits;
x.pad = 255;
x.a = -1ULL;
x.b = -1ULL;
bad_bits = ((uint64_t)-1ULL) ^ *(1+(uint64_t *) x);
printf(bad bits: %llx\n, bad_bits);
return bad_bits != 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37868
[Bug c/35441] [4.2/4.3/4.4 regression] Completely broken diagnostics
--- Comment #2 from sabre at nondot dot org 2008-08-14 04:23 --- FYI, clang produces: t.c:3:3: error: called object is not a function or function pointer (p - q)(); ^ t.c:8:3: error: called object is not a function or function pointer (p q ? p : q)(); ^ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35441
[Bug c/36941] New: gcc does not reject invalid cast
GCC accepts:
extern struct S x;
void foo() { (void)x; }
But correctly rejects:
extern struct S x;
void foo() { x; }
Comeau rejects both in c99 mode.
--
Summary: gcc does not reject invalid cast
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36941
[Bug c/36941] gcc does not reject invalid cast
--- Comment #2 from sabre at nondot dot org 2008-07-25 22:30 --- 'If the lvalue has an incomplete type and does not have array type, the behavior is unde#64257;ned.' QoI -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36941
[Bug c/36941] gcc does not reject invalid cast
--- Comment #3 from sabre at nondot dot org 2008-07-25 22:31 ---
Though that does raise a question. Does GCC normally emit errors for undefined
behavior? I thought the policy was to insert runtime traps? If so, doesn't
the { x; } case qualify, or does it violate some other constraint?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36941
[Bug c/36941] gcc does not reject invalid cast
--- Comment #5 from sabre at nondot dot org 2008-07-26 05:10 --- Ok, so is it right or wrong? :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36941
[Bug c++/23383] builtin array operator new is not marked with malloc attribute
--- Comment #4 from sabre at nondot dot org 2008-06-04 03:21 --- This would not be legal, there is no reason operator new can't return a pointer that already exists in the program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
[Bug c++/23383] builtin array operator new is not marked with malloc attribute
--- Comment #6 from sabre at nondot dot org 2008-06-04 04:32 --- This has been extensively discussed on the C++ reflector. They decided (informally, on the reflector) that people should be able to globally override operator new to do logging, etc, which can make malloc have arbitrary side effects. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
[Bug c++/23383] builtin array operator new is not marked with malloc attribute
--- Comment #7 from sabre at nondot dot org 2008-06-04 04:32 --- That said, it would be fine to add support for this under a non-standards-mode option of some sort of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
[Bug c++/23383] builtin array operator new is not marked with malloc attribute
--- Comment #9 from sabre at nondot dot org 2008-06-04 04:48 --- This isn't possible. The user can override operator new at the very last minute: e.g. by interposing a shared object with LD_PRELOAD. There is no way that a compiler or even LTO optimizing linker can know about this. A special non-standard compiler flag is required. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
[Bug c++/23383] builtin array operator new is not marked with malloc attribute
--- Comment #11 from sabre at nondot dot org 2008-06-04 05:34 --- Expecting people to modify their source is bad news. LLVM's LTO does nothing for operator new, it treats it as any other external function with undefined behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
[Bug c/36399] New: FSF GCC ABI bug on darwin/x86-32
This testcase:
#include xmmintrin.h
__m128i r(__m128 d1, __m128 d2, __m128 d3, __m128i r, int t, __m128i s) {return
r+s;}
compiles to:
_r:
subl$12, %esp
movdqa %xmm3, %xmm0
paddq 32(%esp), %xmm0
addl$12, %esp
ret
with apple gcc 4.0 and 4.2.
It compiles to this with FSF 4.2:
_r:
subl$12, %esp
movdqa 48(%esp), %xmm0
paddq 16(%esp), %xmm0
addl$12, %esp
ret
Since apple GCC defines the ABI on darwin, this is an FSF GCC ABI bug for that
platform.
--
Summary: FSF GCC ABI bug on darwin/x86-32
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36399
[Bug c/32511] GCC inlines weak function
--- Comment #3 from sabre at nondot dot org 2008-02-17 19:48 --- I understand the desire to optimize with -fpic, but miscompiling the code seems unreasonable... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32511
[Bug c/32511] GCC inlines weak function
--- Comment #5 from sabre at nondot dot org 2008-02-18 07:35 --- That works for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32511
[Bug preprocessor/35010] New: preprocessor loses leading whitespace
This testcase: #define debug(format, ...) format, ## __VA_ARGS__) debug(X); debug(Y, 1, 2); debug(Y, 1, 2 ); debug(Z, ); debug(W,); Should preprocess to: X); Y, 1, 2); Y, 1, 2); Z, ); W, ); not: X); Y, 1, 2); Y, 1, 2); Z,); W,); Z/W should have spaces. -- Summary: preprocessor loses leading whitespace Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35010
[Bug c/31128] __builtin_stack_restore/__builtin_stack_save should not be exposed to the user
--- Comment #11 from sabre at nondot dot org 2007-11-28 20:57 --- Please don't disable these. There are a variety of compilers that optionally or only generate C code, particularly for the functional languages. This is useful functionality for these compilers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31128
[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code
--- Comment #27 from sabre at nondot dot org 2007-11-22 21:14 --- sounds fine to me, thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
[Bug c/33192] New: __imag operator drops side effects in subexpr
GCC miscompiles this:
int bar();
void foo() {
int X = __imag bar();
}
to not call bar.
-Chris
--
Summary: __imag operator drops side effects in subexpr
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33192
[Bug c/33193] New: slopiness in __real/__imag
Some issues: __real accepts a struct argument, __imag doesn't. __real and __imag both accept pointer arguments. both accept vectors. What does a complex vector mean? They should all reject all of them. Though it seems questionable to accept a scalar argument at all to real/imag, they certainly shouldn't accept pointers or aggregates. -Chris -- Summary: slopiness in __real/__imag Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33193
[Bug c/33193] slopiness in __real/__imag
--- Comment #1 from sabre at nondot dot org 2007-08-26 05:28 --- Further, http://gcc.gnu.org/onlinedocs/gcc/Complex.html#Complex does not document what arguments are accepted to __real and __imag at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33193
[Bug c/32511] New: GCC inlines weak function
GCC generally doesn't inline weak functions, because their body may be
redefined by the linker: if the compiler inlined the call, the linker changing
the behavior of the function wouldn't change the inlined copy. For example,
GCC does not inline this:
void bar () __attribute__((weak));
void bar () {}
void foo() { bar(); }
However, GCC apparently overrides this if the inline keyword is added (and
potentially if the weak function is defined in a c++ class where it would be
implicit inline?). As such, it cause the following to be inlined:
inline void bar () __attribute__((weak));
void bar () {}
void foo() { bar(); }
However, again, this breaks the semantics of weak linkage. If bar is redefined
at link-time, the inlined copy is not updated. Because 'inline' is an
optimization request, not a requirement, it seems best for the compiler to
ignore the inline request in this case.
-Chris
--
Summary: GCC inlines weak function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32511
[Bug c/31128] __builtin_stack_restore/__builtin_stack_save should not be exposed to the user
--- Comment #8 from sabre at nondot dot org 2007-05-29 15:14 --- Right, you could do that, but it is a) not guaranteed to work going forward, and b) expects properly structured (e.g. nested) control flow. If I had b, I could just make a vla :) -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31128
[Bug c/32122] New: invalid indirect goto accepted
GCC accepts this:
void foo() { goto *1; }
The Labels as Values section of the doc states that indirect gotos take Any
expression of type void *. 1 is not of type void*.
it looks like gcc accepts anything convertible to a pointer type. Trying to
jump to a structure yields:
t.c:15: error: cannot convert to a pointer type
-Chris
--
Summary: invalid indirect goto accepted
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32122
[Bug c++/32121] [4.1/4.2/4.3 Regression] C++ front-end accepts invalid __label__ declarations
--- Comment #1 from sabre at nondot dot org 2007-05-28 07:36 --- isn't this also likely a 3.4 regression? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32121
[Bug c/31128] __builtin_stack_restore/__builtin_stack_save should not be exposed to the user
--- Comment #6 from sabre at nondot dot org 2007-05-28 17:44 --- This is very useful for compilers generating C code (e.g. LLVM, and various other source - C compilers). Why remove it? These compilers are generating partially structured code, that don't have syntactic blocks required for VLAs. -- sabre at nondot dot org changed: What|Removed |Added CC||sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31128
[Bug target/31903] unwanted anonymous namespacing linkage
--- Comment #6 from sabre at nondot dot org 2007-05-12 01:00 --- The real bug here is that they are not getting internal linkage. Just uniquing/randifying the names would allow them to link, but could be a perf issue (more symbols for the static/dynamic linker). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903
[Bug c/31678] New: invalid C99 code accepted with warning
int test(int* A, int B) { return A B; }
$ gcc t.c -fsyntax-only -pedantic -ansi -std=c99
t.c: In function 'test':
t.c:3: warning: comparison between pointer and integer
According to C99 6.5.8p2, this should be rejected.
-Chris
--
Summary: invalid C99 code accepted with warning
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31678
[Bug c/31678] invalid C99 code accepted with warning
--- Comment #2 from sabre at nondot dot org 2007-04-24 01:14 --- Doh, right, thanks! :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31678
[Bug c/31513] Miscompilation of Function Passing Bit Field Value to Function
--- Comment #1 from sabre at nondot dot org 2007-04-09 17:38 --- Among other things, this bug causes GCC 4.2 to miscompile LLVM. -- sabre at nondot dot org changed: What|Removed |Added CC||sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31513
[Bug c/30057] New: error diagnosed with warning
For:
void blah(X, Y)
int X, Y;
struct foo;
{
}
GCC emits a warning for 'foo', this seems like it should be an error.
-Chris
--
Summary: error diagnosed with warning
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30057
[Bug c/30057] error diagnosed with warning
--- Comment #2 from sabre at nondot dot org 2006-12-03 07:47 --- Fair enough! -- sabre at nondot dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30057
[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #16 from sabre at nondot dot org 2006-09-22 17:27 --- Out of curiosity, which powerpc processors are affected by this? -Chris -- sabre at nondot dot org changed: What|Removed |Added CC||sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug libstdc++/28587] vectorbool is extremely slow (900x slower than it should be)
--- Comment #15 from sabre at nondot dot org 2006-08-05 23:30 --- Thanks a *lot* Paolo! It works great now. -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28587
[Bug libstdc++/28587] New: vectorbool is extremely slow (900x slower than it should be)
Compare this trivial program compiled with -DVBOOL and not:
#include vector
int main() {
unsigned N = 10;
for (unsigned i = 0; i 10; ++i) {
#if VBOOL
std::vectorbool V;
V.resize(N);
#else
char *X = new char[(N+7)/8];
memset(X, 0, (N+7)/8);
delete[] X;
#endif
}
}
Compiled at -O3 on a 2.5Ghz G5, the -DVBOOL version takes 47.951s, the memset
version takes 0.053s.
This spends all of it's time in std::fill, inserting one bit at a time into the
vector when it resizes. This is bad and stuff.
-Chris
--
Summary: vectorbool is extremely slow (900x slower than it
should be)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28587
[Bug libstdc++/28587] vectorbool is extremely slow (900x slower than it should be)
--- Comment #2 from sabre at nondot dot org 2006-08-03 18:31 --- Andrew, I'm well aware that vectorbool stores things in compact form. If you read my example, it's clear that I understand that. Even with the current algorithm used by vectorbool, it should not use std::fill internally, it should use memset, which would be far more efficient. Again, actually read the example plz. -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28587
[Bug libstdc++/28587] vectorbool is extremely slow (900x slower than it should be)
--- Comment #4 from sabre at nondot dot org 2006-08-03 19:21 --- the people actively working in the C++ Standard Commitee strongly dislike vectorbool for many reasons, and probably it will be deprecated in C++03 and replacement added. That implies, in turn, that it's not so easy to find people willing to spend much time on (the various) implementations... Fair enough. My impression was that this was because std::vectorbool is not a container and that the specialization doesn't act like the parent container. My (possibly flawed) understanding was that they were planning on eliminating vectorbool but were planning to introduce the same capability under a new name, e.g. bit_vector or something like it. If that's the case, the effort isn't lost. -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28587
[Bug preprocessor/28520] New: preprocessed output does not lex to correct tokens
This: #define x = ?x preprocesses to: ?= It should preprocess to: ? = -Chris -- Summary: preprocessed output does not lex to correct tokens Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28521] New: -E output incorrectly concatenates tokens into trigraphs
gcc -E on: #define z ? ?z( emits: ??( This won't lex correctly when trigraphs are enabled. -Chris -- Summary: -E output incorrectly concatenates tokens into trigraphs Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28521
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #2 from sabre at nondot dot org 2006-07-28 16:26 --- It should print a space for the same reason that this does: #define x - -x -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28521] -E output incorrectly concatenates tokens into trigraphs
--- Comment #2 from sabre at nondot dot org 2006-07-28 16:26 --- It should print a space for the same reason that this does: #define x - -x -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28521
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #4 from sabre at nondot dot org 2006-07-28 23:58 --- I realize that ?= is not a token. However, ?= is. -Chris -- sabre at nondot dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28521] -E output incorrectly concatenates tokens into trigraphs
--- Comment #4 from sabre at nondot dot org 2006-07-28 23:59 --- I realize that tokenization is correct. As per: http://gcc.gnu.org/onlinedocs/cppinternals/Token-Spacing.html#Token-Spacing GCC should be emitting the space so that the subsequent relex of the output won't lex incorrectly. -Chris -- sabre at nondot dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28521
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #6 from sabre at nondot dot org 2006-07-29 00:05 --- ?= is not a trigraph. -- sabre at nondot dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #7 from sabre at nondot dot org 2006-07-29 00:06 --- more specifically ?= is the C++ min-equal extension operator. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28521] -E output incorrectly concatenates tokens into trigraphs
--- Comment #6 from sabre at nondot dot org 2006-07-29 00:08 --- Andrew, I'm well aware that a trigraph is not a token. If you read the report, I say that gcc -E produces output that a subsequent GCC will not reparse into the same result. Again, this is the whole point of: http://gcc.gnu.org/onlinedocs/cppinternals/Token-Spacing.html#Token-Spacing and the reason why GCC doesn't -E this: #define x - -x to -- -Chris -- sabre at nondot dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28521
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #9 from sabre at nondot dot org 2006-07-29 00:09 --- As I mention above, it is a GCC extension. Isn't gcc great? :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #12 from sabre at nondot dot org 2006-07-29 00:13 --- ... which means it's a bug, so please stop closing it! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #16 from sabre at nondot dot org 2006-07-29 00:15 --- Do what ever you want, but it certainly is a bug with current GCC. I filed this bug out of desire to help free software get better, not out of any great need to have the bug fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #18 from sabre at nondot dot org 2006-07-29 01:08 --- ok, fair enough. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28521] -E output incorrectly concatenates tokens into trigraphs
--- Comment #9 from sabre at nondot dot org 2006-07-29 05:03 --- ok -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28521
[Bug preprocessor/28388] New: stringify (#) operator broken
GCC warns for: #define A(b) #b A(\ \\) but not for: #define A(b) #b A(\`\\) or seemingly any other character but space. While \ is not a valid escape in a string, neither is \` or \Z. Either all or none should be warned about. Further, the string should not be chopped into the really illegal result: \ \ Which is what A(\ \\) currently preprocesses to with -E. -Chris -- Summary: stringify (#) operator broken Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28388
[Bug preprocessor/28388] stringify (#) operator broken
--- Comment #3 from sabre at nondot dot org 2006-07-15 05:23 --- Also without -E, we do warn about the second one: t.c:2:7: warning: unknown escape sequence '\`' Right, but that is presumably the parser, not the preprocessor doing it... so it is a bug in the preprocessor. -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28388
[Bug preprocessor/28388] stringify (#) operator broken
--- Comment #5 from sabre at nondot dot org 2006-07-15 05:26 --- Okay, I don't care who does or doesn't do it. :) It doesn't get diagnosed in -E mode, though it's in clear violation of C99 6.10.3.2p2. -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28388
[Bug preprocessor/28223] New: _Pragma GCC poison broken
This should produce two diagnostics. Only the second one is correctly emitted. #define BAR _Pragma (GCC poison XYZW) XYZW /*missing diagnostic*/ BAR XYZW /* correct diagnostic*/ -Chris -- Summary: _Pragma GCC poison broken Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28223
[Bug preprocessor/28223] _Pragma GCC poison broken
--- Comment #1 from sabre at nondot dot org 2006-07-02 20:21 --- Sorry, this bug is invalid. The XYZW token is used (in the macro definition) before it is poisoned (in the instantiation), so it's ok. -Chris -- sabre at nondot dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28223
[Bug preprocessor/28227] New: valid #ifdef rejected
GCC rejects this: #ifdef defined #endif Even though C99 6.10.8.4 specifies that 'defined' is only disallowed after #undef or #define. -Chris -- Summary: valid #ifdef rejected Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28227
[Bug preprocessor/28165] New: _Pragma GCC system_header broken
In a main translation unit, this: #pragma GCC system_header results in this warning: warning: #pragma system_header ignored outside include file However, this doesn't: _Pragma (GCC system_header) In fact, this causes GCC to emit a line marker switching the main translation unit to look like a system header. -Chris -- Summary: _Pragma GCC system_header broken Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28165
[Bug preprocessor/28079] New: #line range not verified
Preprocessing this: #line 12312312312435 produces: # 2936042099 .../foo.c C99 specifies that the argument to #line shall be 0 and 2^31-1, and even if it didn't, truncation like this should at least be warned about. -Chris -- Summary: #line range not verified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28079
[Bug preprocessor/28022] New: Incorrect pedwarn for , expression in #if in c99 mode
This testcase: #if 1 , 0 #endif Should not warn with -std=c99 -pedantic. It currently does due to an inverted conditional. This (cpplib/expr.c:1376): default: /* case CPP_COMMA: */ if (CPP_PEDANTIC (pfile) (!CPP_OPTION (pfile, c99) || !pfile-state.skip_eval)) cpp_error (pfile, CPP_DL_PEDWARN, comma operator in operand of #if); should be: if (CPP_PEDANTIC (pfile) !(CPP_OPTION (pfile, c99) || pfile-state.skip_eval)) -Chris -- Summary: Incorrect pedwarn for , expression in #if in c99 mode Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28022
[Bug c++/26058] [4.0/4.1/4.2 Regression] C++ error recovery regression
--- Comment #4 from sabre at nondot dot org 2006-05-31 19:13 --- I guess I don't follow your logic here. I agree that the EDG approach is inferior to the current GCC implementation, but the current GCC approach is inferior to the old GCC implementation (thus it's a regression, if not a very important one). Why does EDG not doing well mean that GCC can't do well? -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26058
[Bug c++/26058] [4.0/4.1/4.2 Regression] C++ error recovery regression
--- Comment #5 from sabre at nondot dot org 2006-05-31 19:14 --- ... Adding mark so that he will hopefully see the previous comment. -- sabre at nondot dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26058
[Bug c++/26058] [4.0/4.1/4.2 Regression] C++ error recovery regression
--- Comment #7 from sabre at nondot dot org 2006-05-31 22:17 --- Ok, makes sense. The strategy that made sense to me was If I see a definition for something that obviously has to be at global scope, but is defined inside of a function, pop all the way out to global scope and continue, there must be a missing }. I have no idea how hard that is to implement though. If you think it's infeasible to implement or would confuse some other important case, then I'm ok with RESOLVED INVALID. -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26058
[Bug c++/26058] [4.0/4.1/4.2 Regression] C++ error recovery regression
--- Comment #9 from sabre at nondot dot org 2006-05-31 23:00 ---
Right, clearly issuing good diagnostics is a matter of balancing cases against
each other. While I agree that this is valid:
void f() {
void g();
g();
}
I don't see it used very often, particularly not in C++ code (I'm accustomed to
seeing it in pre-ansi C code most of the time). I personally think that
forgetting (or losing track of) the brace occurs more often than the erroneous
version of this, but if you disagree, that's fine and I'll stop bugging you!
-Chris
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26058
[Bug preprocessor/27783] New: Garbage at end of #include line ignored
The following malformed program is not diagnosed: #include stdio.h bar -Chris -- Summary: Garbage at end of #include line ignored Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27783
[Bug preprocessor/27777] New: Bad diagnostic emission when #error contains a trigraph
Testcase, compiled with -trigraphs: #error BUG??! produces: x.c:3:2: error: #error BUG|x.c:3:12: warning: trigraph ??! converted to | The diagnostics are good, but there should be a newline in-between those. -Chris -- Summary: Bad diagnostic emission when #error contains a trigraph Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug preprocessor/27750] New: bogus 'backslash-newline at end of file' warning
Consider this reduced translation unit: --- // foo ??/ x --- ... where there is no newline after the X. Compiled like so: $ gcc bug.c -Wall -pedantic -fsyntax-only -trigraphs -std=c99 yields: bug.c:2:9: warning: trigraph ??/ converted to \ bug.c:2:9: warning: backslash-newline at end of file bug.c:2:1: warning: multi-line comment bug.c:1: warning: ISO C forbids an empty source file A couple of issues. First, the diagnostics are not sorted. The last one should be issued first. Second, more importantly, the 2nd diagnostic is incorrect. There is no backslash-newline at the end of the file. The first and third diagnostics are accurate. Again, note that there should be *no* newline after the x to reproduce this. -Chris -- Summary: bogus 'backslash-newline at end of file' warning Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27750
[Bug preprocessor/27750] bogus 'backslash-newline at end of file' warning
--- Comment #1 from sabre at nondot dot org 2006-05-24 06:21 --- I guess I should have been more specific. Instead of backslash-newline at end of file, I'd expect to get no newline at end of file, which is also missing. -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27750
[Bug preprocessor/27750] bogus 'backslash-newline at end of file' warning
--- Comment #4 from sabre at nondot dot org 2006-05-24 06:26 --- This might be why it is undefined at compile time if the file does not end in a new-line or not :). However, GCC *does* supports this as an extension, hence the expected pedwarn. I don't think that warning is that bogus. It is true too. Huh? The backslash-newline occur in the middle of a comment, not at the end of a file. -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27750
[Bug preprocessor/27750] bogus 'backslash-newline at end of file' warning
--- Comment #6 from sabre at nondot dot org 2006-05-24 06:36 --- It is not really an extension, just undefined at compile time which isdiffferent than supporting. It's marked as a pedwarn. That's a pretty clear demonstration that this is a feature, and that it's a known extension. I realize that GCC need not support the extension. If the extension is removed, this bug can be closed. so ... The standard requires that to be an backslash-newline even without thecomment there. I fail to see your point. -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27750
[Bug tree-optimization/27140] Compiling LLVM now takes nearly 5x as long with 4.1 as it did with 4.0
--- Comment #3 from sabre at nondot dot org 2006-04-13 16:31 --- Note: (albeit 2 million source lines) isn't right, it's only 79K LOC. :) -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27140
[Bug c++/21581] (optimisation) Functions in anonymous namespaces should default to hidden visibility
--- Comment #13 from sabre at nondot dot org 2006-03-21 18:03 --- Pardon the potentially silly question here, but why 'hidden'? Why not TREE_PUBLIC(decl) = 0? It seems that members of anonymous namespaces should be completely internal, and not depend on platform support for hidden visibility. If I understand correctly, marking something hidden places more slightly more burden on the static linker than marking it internal, and not all platforms support hidden. Should I (re)open a new bug for to request TREE_PUBLIC(decl) = 0 behavior? -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21581
[Bug c++/21581] (optimisation) Functions in anonymous namespaces should default to hidden visibility
--- Comment #15 from sabre at nondot dot org 2006-03-21 18:06 --- Great, thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21581
[Bug middle-end/16660] attribute((aligned)) doesn't work for variables on the stack for greater than required alignement
--- Comment #4 from sabre at nondot dot org 2006-03-18 23:43 --- Huh? Why can't it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16660
[Bug target/26408] incorrect handling of x86 H registers in inline asm
--- Comment #3 from sabre at nondot dot org 2006-02-22 16:11 --- Fair enough. Shouldn't this be diagnosed with an error though? -Chris -- sabre at nondot dot org changed: What|Removed |Added CC||schwab at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26408
[Bug c++/26426] New: Type layout bug
Consider:
struct A { virtual ~A(); }; // 4
struct B { virtual ~B(); }; // 4
struct X : virtual public A,
virtual public B { // 8
};
struct Y : virtual public B { // 4
virtual ~Y();
};
struct Z : virtual public X, public Y { // 8
Z();
};
Z::Z() {}
In this example, the DECL_SIZE_UNIT of Z is 8 bytes. Here, the FIELD_DECL
corresponding to it's Y superclass has an offset of 0 bytes and size 4 bytes.
The FIELD_DECL for the X superclass has an offset of 4 bytes and and a size of
8 bytes, which means that the end of the object is 12 bytes, despite the fact
that Z has a DECL_SIZE_UNIT of 8 bytes.
-Chris
--
Summary: Type layout bug
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26426
[Bug inline-asm/26408] New: incorrect handling of x86 H registers in inline asm
Consider:
short test(int X, int Y) {
register char Yr asm(ch) = Y;
__asm__(foo %0 %1 %2 : =r(X): r(X), r(Yr));
return X;
}
This compiles to:
test:
movl4(%esp), %edx
movb8(%esp), %cl
#APP
foo %eax %edx %cl
#NO_APP
cwtl
ret
I would expect CH, not CL, to be used.
-Chris
--
Summary: incorrect handling of x86 H registers in inline asm
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26408
[Bug c++/26058] New: C++ error recovery regression
GCC 3.3 emitted one parse error before `{' token error on this code, GCC 4
emits one error for *every* function defined after the error. It would be nice
to only say error: a function-definition is not allowed here before '{' token
once, and perhaps pop up to global scope so that the rest of the file is parsed
in a sane way.
---
int t1() {
{ // unclosed brace
}
int t2() {}
int t3() {}
int t4() {}
int t5() {}
int t6() {}
int t7() {}
int t8() {}
---
-Chris
--
Summary: C++ error recovery regression
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26058
[Bug c++/25915] use ODR rules to make C++ objects not be TREE_PUBLIC
--- Comment #3 from sabre at nondot dot org 2006-01-23 21:23 --- Absolutely, it would be great to handle that as well. The risk of making a particular bugzilla PR more general is that it reduces the chance that it will ever get fixed though. -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25915
[Bug c++/25915] use ODR rules to make C++ objects not be TREE_PUBLIC
--- Comment #5 from sabre at nondot dot org 2006-01-23 22:00 --- Subject: Re: use ODR rules to make C++ objects not be TREE_PUBLIC Already done. The subject is now use ODR rules to make C++ objects not be TREE_PUBLIC Thanks, -Chris On Mon, 23 Jan 2006, gdr at cs dot tamu dot edu wrote: --- Comment #4 from gdr at cs dot tamu dot edu 2006-01-23 21:58 --- Subject: Re: instantiated templates with anonymous namespace class as arguments should be static geoffk at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Let's make this more general. Geoff and me had discussed this on the GCC mailing list in the past. Just to clarify and make sure we are all at the same page., the notion of static shall not be that of the C or C++ source language rule, but that of the linker. This PR subject should be changed to reflect that. -- Gaby -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25915
