is overly strict in assignment to read-only data
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: truedfx at gentoo dot org
--- Comment #6 from truedfx at gentoo dot org 2006-07-02 08:44 ---
> This code is not invalid, and G++ is correct to accept it.
>
> DR68 permits this grammatical production and typedef-names for classes are
> class-names.
Does that mean this code is valid, too?
typedef
: ICE on _Pragma at end of file
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: truedfx at gentoo dot org
at gcc dot gnu dot org
ReportedBy: truedfx at gentoo dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35235
--- Comment #4 from truedfx at gentoo dot org 2008-03-02 10:57 ---
I only came across this bug looking for something else, but anyway, here's a
reduced testcase:
template
class ring {};
template
ring &operator<<(ring&, T *);
class base {};
class derived : publ
--- Comment #5 from truedfx at gentoo dot org 2008-03-15 18:17 ---
This is probably related to #28262. That bug's about
typedef void fn(int = 0);
typedef fn *fp;
void call(fp f) { f(); }
which used to be accepted (up to 4.2), but is now correctly rejected in 4.3.
This bug is r
--- Comment #6 from truedfx at gentoo dot org 2008-03-15 18:24 ---
Or more relevantly, #4205.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35596
--- Comment #4 from truedfx at gentoo dot org 2008-03-23 18:59 ---
(In reply to comment #3)
> As for this PR, the warning from the C front-end seems to be mandated by the
> standard (I say this because using -pedantic-errors gives an error instead, so
> it is a pedwarn, it woul
ity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: truedfx at gentoo dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41842
--- Comment #1 from truedfx at gentoo dot org 2009-10-27 06:26 ---
Same results with the 20091022 snapshot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41842
minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: truedfx at gentoo dot org
GCC host triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31782
--- Comment #1 from truedfx at gentoo dot org 2007-05-02 03:21 ---
Sorry, forgot to mention, I'm using gcc 4.1.2 with binutils 2.17, and I also
tried gcc 3.3.6 with binutils 2.16.1, which behaves the same for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31782
--- Comment #3 from truedfx at gentoo dot org 2007-05-02 05:58 ---
Thanks for the link. I don't see how GAS could be fixed, though. How would the
assembler tell the difference between $0 the constant and $0 the identifier?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31782
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: truedfx at gentoo dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31869
--- Comment #3 from truedfx at gentoo dot org 2007-05-10 00:33 ---
I see the same behaviour with gcc 3.3.6. I'm not able to check even older
versions for now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31869
tus: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: truedfx at gentoo dot org
GCC host triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31940
--- Comment #3 from truedfx at gentoo dot org 2010-04-05 12:54 ---
(In reply to comment #2)
> ยง6.4.4.1 Integer constants:
>
> If an integer constant cannot be represented by any type in its list, it may
> have an extended integer type, if the extended integer type can r
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: truedfx at gentoo dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42415
--- Comment #1 from truedfx at gentoo dot org 2009-12-17 20:51 ---
And here's the generated assembly:
.file "test.cc"
.text
.align 2
.globl _ZN1A1fEv
.type _ZN1A1fEv, @function
_ZN1A1fEv:
.LFB0:
.cfi_startproc
--- Comment #1 from truedfx at gentoo dot org 2010-01-02 20:26 ---
The buffer should be at least PATH_MAX bytes. If PATH_MAX > 1024, then 1024
bytes need not be enough. But anyway, realpath() comes from glibc, so even if
this is a bug, you're reporting it to the wro
--- Comment #4 from truedfx at gentoo dot org 2010-08-07 14:34 ---
I'm having this problem too, and it's still happening with GCC 4.5. The ml
message suggests that this may be hard to fix, but it looks surprisingly easy:
instead of tracing back via INCLUDED_FROM, simply loo
ty: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: truedfx at gentoo dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45234
--- Comment #2 from truedfx at gentoo dot org 2010-08-08 22:44 ---
_Decimal128 has the same problem, and is supported by gcc 4.3, so this may
trigger there too (but I don't have 4.3 installed to check right now)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45234
--- Comment #3 from truedfx at gentoo dot org 2010-08-08 23:09 ---
I've configured a minimal 4.3.5 compiler, and testing shows that
extern void f (_Decimal128);
void g(void)
{
__builtin_alloca (2);
f (0);
}
which also fails with the same ICE with 4.5.0 and 4.4.4, actually
--- Comment #6 from truedfx at gentoo dot org 2010-08-09 16:15 ---
With those two lines removed from 4.5.0, it looks like the stack will be
aligned properly by accident. When changing __builtin_alloca (2) to
__builtin_alloca (6), the only thing that changes in the generated code is
--- Comment #10 from truedfx at gentoo dot org 2010-08-09 16:58 ---
I had already tried simply commenting out the assert, and that caused wrong
code, so changing the assert without anything else won't help :)
FWIW, I now also checked the code difference between alloca(2) and all
--- Comment #13 from truedfx at gentoo dot org 2010-08-09 17:44 ---
Thanks, that seems to work for me too for the reduced code. I'll test the
original larger code that was failing too, but that'll take a little longer for
me to report back anything.
--
http://gcc.gnu.or
--- Comment #14 from truedfx at gentoo dot org 2010-08-10 05:59 ---
In the original code, the patch fixes the problem too. Thanks again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45234
--- Comment #4 from truedfx at gentoo dot org 2007-12-28 20:59 ---
Yes, gcc 2.95.3 got it right, the program used to keep the space:
..
. .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31869
--- Comment #2 from truedfx at gentoo dot org 2008-04-15 19:17 ---
Created an attachment (id=15479)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15479&action=view)
bug.ii
I ran into this same error with different code, which I posted to
<http://gcc.gnu.org/ml/gcc-he
--- Comment #3 from truedfx at gentoo dot org 2007-01-23 00:05 ---
-Wendif-labels and -Wimplicit-int don't turn errors into warnings, so probably,
yes. I did notice something else of interest while testing, though:
int main(char a) {}
gcc bug.c -ansi -pedantic
compiles this wi
--- Comment #4 from truedfx at gentoo dot org 2007-01-23 00:08 ---
(In reply to comment #3)
> -Wendif-labels and -Wimplicit-int don't turn errors into warnings, so
> probably,
> yes.
So probably, no, it does not happen with any other option. Sorry, I read your
: truedfx at gentoo dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30551
--- Comment #6 from truedfx at gentoo dot org 2007-01-23 00:23 ---
Thank you, and done.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26494
34 matches
Mail list logo
