https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33193
--- Comment #11 from Chris Lattner ---
Cool, thanks for tidying this up Andrew!
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33193
Chris Lattner sabre at nondot dot org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
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:
--- 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
--- 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
--- 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
--- 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
--- 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 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
--- 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 #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
--- 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
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
--- 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 stdio.h
#include stdint.h
struct X {
unsigned char pad : 4;
uint64_t a : 64;
uint64_t b : 60;
} __attribute__((packed));
int main (void
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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
--- 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
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 #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
--- 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
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
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
.
-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
--- 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
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 required
--- 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
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
--- 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
--- 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
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
--- 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
--- 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 #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
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
--- 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
--- 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
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
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, ?= is.
-Chris
--
sabre at nondot dot org changed:
What|Removed |Added
--- 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
--- 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
--- 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
--- 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
--- 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
: 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 preprocessor.
-Chris
--- 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
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|Removed
: 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
org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28165
: 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
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
--- 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 continue
--- 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
: 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
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
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/bugzilla/show_bug.cgi?id=27750
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26426
: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26408
: 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
--- 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
--- 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
1 - 100 of 142 matches
Mail list logo
