--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-07-03 05:19
---
I'm sorry; I had missed the fact that the elaborated type specifier refers uses
a typedef-name. This code is in fact invalid, since an elaborated type
specifier may not refer to a typedef-name.
--
mmitchel at
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-03 03:36 ---
You are violating the alignment requirement that C depends. If you use -W
-Wall you should get a warning about this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |A
--- Comment #104 from pinskia at gcc dot gnu dot org 2006-07-03 03:36
---
*** Bug 28228 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-03 03:36 ---
You violating C aliasing rules:
int c = *((int *)(&a[1]));
*** This bug has been marked as a duplicate of 21920 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from kargl at gcc dot gnu dot org 2006-07-03 03:15 ---
I have a patch for this, but I want to see if I can move
it up into the parsing/matching portion of gfortran.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
---
test.c
--
int
main () {
char ba[8] = {0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08};
short a[4] = { 0x04, 0x05, 0x06, 0x07};
int c = *((int *)(&a[1]));
int d = *((int *)(&ba[1]));
printf("%08x\n", c );
printf("%08x\n", d );
return 0;
}
-
sh-elf-linux -m4a -
test.c
-
int
main () {
char ba[8] = {0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08};
short a[4] = { 0x04, 0x05, 0x06, 0x07};
int c = *((int *)(&a[1]));
int d = *((int *)(&ba[1]));
printf("%08x\n", c );
printf("%08x\n", d );
return 0;
}
--
gcc
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: norm
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-03 00:18 ---
http://gcc.gnu.org/ml/java-patches/2006-q3/msg0.html
http://gcc.gnu.org/ml/java-patches/2006-q2/msg00543.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pluto at agmk dot net 2006-07-03 00:08 ---
Created an attachment (id=11803)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11803&action=view)
updated build hack for mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24403
/mnt/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc -B/mnt/gnu/gcc/objdir/./gcc
-nostd
inc++ -L/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src
-L/mnt/gnu/gc
c/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-B/opt/gnu/gcc/gcc-4.2.0/h
ppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.2.0/hppa2
--- Comment #1 from tbm at cyrius dot com 2006-07-02 23:52 ---
(gdb) run ~/test.cc
Starting program: /home/tbm/tmp/gcc/i386/gcc/cc1plus ~/test.cc
static void foo::bar::apply(const T1&, T2&) void
foo::operator()(T1&, T3&)
Program received signal SIGSEGV, Segmentation fault.
type_dependen
[ Forwarded from http://bugs.debian.org/376148 ]
The following bug has been reported by Alexei Sheplyakov who submitted a
testcase which shows a segfault with gcc 4.0, 4.1 and 4.2. gcc 3.4 produces an
error:
(sid)1311:[EMAIL PROTECTED]: ~] g++-4.0 -c test.cc
test.cc: In member function 'void foo
--
fche at redhat dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fche at redhat dot com
|dot org |
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-07-02 23:10
---
I can look into this.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-07-02 22:37 ---
Fixed so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Statu
If I'm not completely mistaken, Fortran 2003 allows to read namelists from
internal files whereas it was forbidden in Fortran 95.
At least I find in the F95/2005 book (in the f95 section) that it is forbidden,
but I cannot find it in the Fortran 2003 standard.
And also Richard E Maine
(http://www.c
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-07-02 21:23
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-07-02 21:23
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-07-02 21:23
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.1.
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-07-02 21:22
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASS
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-07-02 21:22
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-07-02 21:17
---
Subject: Bug 28081
Author: fxcoudert
Date: Sun Jul 2 21:17:05 2006
New Revision: 115134
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115134
Log:
PR fortran/28094
* trans-intrinsic.c (gf
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-07-02 21:17
---
Subject: Bug 23862
Author: fxcoudert
Date: Sun Jul 2 21:17:05 2006
New Revision: 115134
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115134
Log:
PR fortran/28094
* trans-intrinsic.c (gf
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-07-02 21:17
---
Subject: Bug 27965
Author: fxcoudert
Date: Sun Jul 2 21:17:05 2006
New Revision: 115134
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115134
Log:
PR fortran/28094
* trans-intrinsic.c (gf
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-07-02 21:17
---
Subject: Bug 28094
Author: fxcoudert
Date: Sun Jul 2 21:17:05 2006
New Revision: 115134
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115134
Log:
PR fortran/28094
* trans-intrinsic.c (gf
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-07-02 21:17
---
Subject: Bug 26801
Author: fxcoudert
Date: Sun Jul 2 21:17:05 2006
New Revision: 115134
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115134
Log:
PR fortran/28094
* trans-intrinsic.c (gf
--- 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
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
--- Comment #5 from tobi at gcc dot gnu dot org 2006-07-02 18:12 ---
Fixed on the mainline.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #6 from gnu_andrew at member dot fsf dot org 2006-07-02 17:45
---
This assertion fails:
gcc_assert (!uid_region_num[INSN_UID (r->label)]);
in gcc/except.c (remove_unreachable_regions)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28222
--- Comment #5 from gnu_andrew at member dot fsf dot org 2006-07-02 17:40
---
Created an attachment (id=11802)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11802&action=view)
Assembler file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28222
--- Comment #4 from gnu_andrew at member dot fsf dot org 2006-07-02 17:39
---
Created an attachment (id=11801)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11801&action=view)
Assembler file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28222
--- Comment #3 from gnu_andrew at member dot fsf dot org 2006-07-02 17:39
---
Created an attachment (id=11800)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11800&action=view)
Assembler file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28222
--- Comment #2 from gnu_andrew at member dot fsf dot org 2006-07-02 17:38
---
Failed command is:
/home/gandalf/projects/java/classpath/gcj/build/gcc/gcj
-B/home/gandalf/projects/java/classpath/gcj/build/x86_64-unknown-linux-gnu/libjava/
-B/home/gandalf/projects/java/classpath/gcj/build
--- Comment #1 from gnu_andrew at member dot fsf dot org 2006-07-02 17:37
---
Created an attachment (id=11799)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11799&action=view)
Output of the failed command
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28222
--- Comment #7 from fang at csl dot cornell dot edu 2006-07-02 17:37
---
Subject: Re: clause 7.1.5.3/2 of the c++ is not enforced
Would it be appropriate to prefix [DR 68] to the subject?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21498
The gcj-eclipse branch fails compiling the
gnu/java/security/x509/X509Certificate.java file
as part of the build.
Output and assembler files are attached.
--
Summary: [ecj] Fails compiling
gnu/java/security/x509/X509Certificate.java
Product: gcc
--- Comment #5 from gdr at integrable-solutions dot net 2006-07-02 16:37
---
Subject: Re: Diagnostic about wrong use _Complex prints __complex__
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| (In reply to comment #3)
| > Indeed. However, we can approximate a fix by te
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P3
Target Milestone|--- |4.2.0
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28189
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
Version|unknown |4.1.1
http://
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-02 16:24 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-07-02 16:20 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-07-02 16:11 ---
(In reply to comment #3)
> Indeed. However, we can approximate a fix by testing whether we're
> compiling under C99, GNU99, or just C90, or C++.
That would not work as _Complex is accepted in GNU90 more and with the
--- Comment #8 from sayle at gcc dot gnu dot org 2006-07-02 16:05 ---
Subject: Bug 27428
Author: sayle
Date: Sun Jul 2 16:05:28 2006
New Revision: 115133
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115133
Log:
PR middle-end/27428
* c-lex.c (c_lex_with_flags)
--- Comment #3 from gdr at integrable-solutions dot net 2006-07-02 16:03
---
Subject: Re: Diagnostic about wrong use _Complex prints __complex__
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Confirmed, we don't record in the preprocessor which keyword is
| used, _Com
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from schwab at suse dot de 2006-07-02 14:53 ---
*** Bug 28219 has been marked as a duplicate of this bug. ***
--
schwab at suse dot de changed:
What|Removed |Added
-
--- Comment #3 from schwab at suse dot de 2006-07-02 14:53 ---
*** This bug has been marked as a duplicate of 28217 ***
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #11 from pluto at agmk dot net 2006-07-02 14:40 ---
4.1.2svn still broken.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21952
--- Comment #18 from richard at codesourcery dot com 2006-07-02 13:39
---
Subject: Re: [4.2 Regression] wrong code in spec tests for -ftree-vectorize
-maltivec
"hubicka at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
> Increasing alignment of static variable during tree optimizati
--- Comment #17 from hubicka at gcc dot gnu dot org 2006-07-02 13:13
---
Increasing alignment of static variable during tree optimization should be as
easy as increasing the DECL_ALIGN. All variables are output after all
functions.
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #1 from tbm at cyrius dot com 2006-07-02 11:13 ---
Created an attachment (id=11798)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11798&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28221
[ Forwarded from http://bugs.debian.org/376084 ]
We're seeing the following ICE on ia64 with gcc 4.1:
merulo% g++-4.1 -c -O2 000.c
000.c: In member function 'k3d::mesh*
libk3dprimitives::lawn_implementation::on_create_geometry()':
000.c:7597: internal compiler error: in add_insn_before, at emit-r
--- Comment #2 from fnf at specifixinc dot com 2006-07-02 10:48 ---
Created an attachment (id=11797)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11797&action=view)
GDB backtrace from segfault
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28220
--- Comment #1 from fnf at specifixinc dot com 2006-07-02 10:47 ---
Created an attachment (id=11796)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11796&action=view)
Input file to reproduce the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28220
While working on a report for a different bug, I mistyped the command line and
triggered what looks like a separate bug. Here is how to reproduce it:
$ gzip -d bug.h.gz
$ touch bug.gch
$ ./cc1plus bug.h -fpreprocessed -o bug.s -quiet bug.gch
bug.gch:1: sorry, unimplemented: inter-module optimizat
--- Comment #2 from fnf at specifixinc dot com 2006-07-02 10:38 ---
Created an attachment (id=11795)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11795&action=view)
Bactrace from gdb
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28219
--- Comment #1 from fnf at specifixinc dot com 2006-07-02 10:37 ---
Created an attachment (id=11794)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11794&action=view)
Input file to reproduce the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28219
I'm getting an error bootstrapping the latest "top of tree" development gcc on
an i686 Fedora Core 4 system:
$ gzip -d bug.h.gz
$ ./cc1plus -quiet bug.h -fpreprocessed -o bug.s --output-pch=bug.gch
/build/latest/trunk/i686-pc-linux-gnu/gcc/i686-pc-linux-gnu/libstdc++-v3/include/ext/pb_ds/detail/bi
--- 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 class A {} a;
c
64 matches
Mail list logo
