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 changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
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 and
--- 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 |
--- 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 #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 #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 #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 #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-06 22:44 ---
FWIW, llvm-g++ gets this right.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11211
--- 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 #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-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 #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
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-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
--- 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 #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 #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 #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 #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 const
--- 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
undefined.'
QoI
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36941
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 #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.c
--- 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 thi
--- 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 #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 #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
-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
--- 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 #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
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.
--
--- 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
--- 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
nedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33193
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
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32511
--- 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
--- 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 #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
igned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32122
--- 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
--- 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
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 #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
--- 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
ty: 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
--- 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
--- 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 #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
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 #9 from sabre at nondot dot org 2006-07-29 05:03 ---
ok
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28521
--- 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 #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 #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 #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 #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 #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:05 ---
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 #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 #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 #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
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
This:
#define x =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
--- 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 #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
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
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
--- 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
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
gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28165
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
-
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
--- 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
--- 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 #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 #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
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
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
--- 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
--- 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 #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
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 #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 #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 #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
--- 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
gned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26426
--- 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 |
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
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
--- 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 do
--- 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
1 - 100 of 142 matches
Mail list logo
