--- 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
NCONFIRMED
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
--- 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
--- 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 thin
--- 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
en #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
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
--- 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
--- 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
--- 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 con
--- 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
-
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
ne 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/bug
gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28165
n: 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
--- 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|Re
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
3
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
--- 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 prepr
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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&#x
--- 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
--- 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 |
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24691
--- Comment #5 from sabre at nondot dot org 2005-11-13 01:24 ---
Is this safe? People can define their own operator new's, some of which may
return null...
-Chris
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476
--- Comment #7 from sabre at nondot dot org 2005-11-13 02:13 ---
> Yes because the normal operator new guarante not to return NULL by the C++
> standard.
Sure.
> And if it returns a NULL that is undefined behavior, it should be
> throwing an exception when memory
--- Comment #9 from sabre at nondot dot org 2005-11-13 02:51 ---
yup, you're right. Great!
-Chris
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24867
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24868
--- Comment #2 from sabre at nondot dot org 2005-11-15 05:59 ---
As I mentioned, there are *several* places where chainon is used where it
shouldn't be. For example, several structs are built, with chainon being used
as an expensive "push_back". It would be better to bu
--- Comment #4 from sabre at nondot dot org 2005-11-16 01:47 ---
> Without more information, this bug
> does not contain much information
I listed three specific areas that can be improved. If you'd like me to close
this and open 3 bugs I can. In addition there are many o
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
--- Comment #1 from sabre at nondot dot org 2005-12-20 19:57 ---
Created an attachment (id=10537)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10537&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
--- Comment #6 from sabre at nondot dot org 2005-12-20 21:47 ---
Re: comment #5:
That is a similar testcase, but not an identical one. A better one would be
something like:
void foo() {
if (...) {
std::pair = ..
...
}
if (...) {
std::pair = ..
...
}
if
ned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25542
--- Comment #1 from sabre at nondot dot org 2005-12-23 07:29 ---
Sorry, my error. I'm just confused.
-Chris
--
sabre at nondot dot org changed:
What|Removed |
--- Comment #10 from sabre at nondot dot org 2006-01-15 22:23 ---
Actually, it would be impossible/impractical for the middle end to do this.
The middle end can't know that the called functions (which are passed the stack
objects by reference) don't hang on to a pointe
This:
#define x =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
ormal
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
--- 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
--- 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
--- Comment #4 from sabre at nondot dot org 2006-07-28 23:58 ---
I realize that ?= is not a token. However, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
--- 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'
--- Comment #6 from sabre at nondot dot org 2006-07-29 00:05 ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
--- Comment #7 from sabre at nondot dot org 2006-07-29 00:06 ---
more specifically http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
--- 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
--- 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
--- 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
--- 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
--- 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
--- Comment #9 from sabre at nondot dot org 2006-07-29 05:03 ---
ok
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28521
wer 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
--- Comment #2 from sabre at nondot dot org 2006-08-03 18:31 ---
Andrew, I'm well aware that vector stores things in compact form. If you
read my example, it's clear that I understand that.
Even with the current algorithm used by vector, it should not use
std::fill inte
--- Comment #4 from sabre at nondot dot org 2006-08-03 19:21 ---
>the people actively working in the C++ Standard Commitee strongly dislike
>vector for many reasons, and probably it will be deprecated in C++03 and
> replacement added. That implies, in turn, that it's
--- 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
--- 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
--- 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
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/sh
--- 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
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
nedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33193
--- 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
--- Additional Comments From sabre at nondot dot org 2005-04-11 19:40
---
This code from stl_bvector.h is the problem:
void _M_incr(ptrdiff_t __i) {
difference_type __n = __i + _M_offset;
_M_p += __n / _M_word_bit;
__n = __n % _M_word_bit;
if (__n <
--- Additional Comments From sabre at nondot dot org 2005-04-12 14:31
---
This is definately a libstdc++ issue.
-Chris
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16611
--- 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
--- 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
--- 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
--- 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
#include
struct X {
unsigned char pad : 4;
uint64_t a : 64;
uint64_t b : 60;
} __attribute__((packed));
int main (void)
{
struct X x
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
--- 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
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
igned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32122
--- 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
--- 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
--- 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
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32511
P2
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=24208
--- Comment #1 from sabre at nondot dot org 2005-10-05 00:03 ---
Created an attachment (id=9886)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9886&action=view)
Large C++ file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24208
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
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=24222
--- Comment #4 from sabre at nondot dot org 2005-10-06 01:51 ---
The gimplifier apparently emits these three errors:
error ("memory input %d is not directly addressable", i);
error ("invalid lvalue in asm output %d", i);
error ("too few arguments to function %
--- Comment #5 from sabre at nondot dot org 2005-10-09 22:02 ---
Some updates: the -ftime-report problems were a local problem with apple's gcc,
now fixed. This testcase has some templates (e.g. the match stuff), but mostly
it is just big branchy compiler code :), not atypical of
--- Comment #19 from sabre at nondot dot org 2005-10-11 16:58 ---
To clarify: you are saying that the response in comment #12 is wrong?
-Chris
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
--- Comment #21 from sabre at nondot dot org 2005-10-11 17:03 ---
"required optimization" doesn't make sense to me. To put it more clearly, do
you agree that this:
"In particular, I think the C++ standard specifies that memory is zero
initialized and then ctors (
--- Comment #23 from sabre at nondot dot org 2005-10-11 17:10 ---
Ah, very interesting. Thanks for the clarification. Should I file another PR
about cases where this is mishandled?
-Chris
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
rity: P2
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=24312
--- Comment #24 from sabre at nondot dot org 2005-10-11 17:15 ---
At pinskia's request, I filed Bug 24312 to show the miscompilation due to
mishandling this. I thought it would be better to keep this PR focused on the
missed-optimization aspect.
-Chris
--
http://gcc.gn
--- Comment #1 from sabre at nondot dot org 2005-10-11 17:15 ---
Note that this could be handled in a straight-forward way with init priorities.
--
sabre at nondot dot org changed:
What|Removed |Added
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
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23067
--- Additional Comments From sabre at nondot dot org 2005-07-26 04:49
---
The ABI clearly states that the maximum alignment for non-initial structure
elements is 32-bits.
-Chris
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23067
1 - 100 of 142 matches
Mail list logo
