--- Comment #3 from ngiff at yahoo dot com 2006-08-17 06:55 ---
Sorry. I did not know that 3.4 was no longer supported. I wondered if
upgrading to gcc4 would fix it, but was trying to stay in sync with the rest of
my group. But it sounds like upgrading is something we should all do.
--- Comment #4 from bonzini at gnu dot org 2006-08-17 07:03 ---
Subject: Bug 28573
Author: bonzini
Date: Thu Aug 17 07:02:55 2006
New Revision: 116208
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116208
Log:
2006-08-17 Paolo Bonzini [EMAIL PROTECTED]
PR c++/28573
--- Comment #7 from uros at kss-loka dot si 2006-08-17 07:21 ---
(In reply to comment #6)
I think that remaining time difference is due to strange loop above innermost:
... due to strange _header_ above innermost loop ...
The problem is that we load zero in both arms of if.
This is
--- Comment #8 from uros at kss-loka dot si 2006-08-17 07:45 ---
Also interesting is, that -march=pentium4 produces following de-optimized
code, adding a couple more instructions and wasting %eax register:
.L8:
leal(%ebx,%ebx), %eax
movl40(%esp), %edx
--- Comment #2 from jakub at gcc dot gnu dot org 2006-08-17 07:58 ---
Subject: Bug 28725
Author: jakub
Date: Thu Aug 17 07:58:02 2006
New Revision: 116209
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116209
Log:
PR libgomp/28725
* env.c: Include ctype.h.
--- Comment #3 from jakub at gcc dot gnu dot org 2006-08-17 07:59 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-08-17 08:02
---
Subject: Bug 28711
Author: reichelt
Date: Thu Aug 17 08:02:39 2006
New Revision: 116210
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116210
Log:
PR c++/28711
* pt.c (tsubst_copy_and_build)
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-08-17 08:06
---
Subject: Bug 28710
Author: reichelt
Date: Thu Aug 17 08:06:27 2006
New Revision: 116211
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116211
Log:
PR c++/28710
* decl.c (xref_tag): Improve
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-08-17 08:12
---
Subject: Bug 28710
Author: reichelt
Date: Thu Aug 17 08:12:00 2006
New Revision: 116212
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116212
Log:
PR c++/28710
* decl.c (xref_tag): Improve
--- Comment #21 from bonzini at gnu dot org 2006-08-17 08:16 ---
I'll see if I can construct a case where my patch fails (actually a newer one)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25500
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-08-17 08:22 ---
Subject: Bug 27865
Author: rakdver
Date: Thu Aug 17 08:22:05 2006
New Revision: 116213
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116213
Log:
PR tree-optimization/27865
* tree-vrp.c
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-08-17 08:34 ---
Appearantly fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from mkuvyrkov at gcc dot gnu dot org 2006-08-17 08:48
---
Subject: Bug 28489
Author: mkuvyrkov
Date: Thu Aug 17 08:48:37 2006
New Revision: 116214
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116214
Log:
2006-08-17 Maxim Kuvyrkov [EMAIL PROTECTED]
--- Comment #14 from mkuvyrkov at gcc dot gnu dot org 2006-08-17 08:52
---
Fixed by the earlier attached patch.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from aoliva at gcc dot gnu dot org 2006-08-17 08:55 ---
Subject: Bug 28146
Author: aoliva
Date: Thu Aug 17 08:55:02 2006
New Revision: 116215
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116215
Log:
PR target/28146
* reload.h (reg_equiv_alt_mem_list): New
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-08-17 08:55
---
Subject: Bug 28710
Author: reichelt
Date: Thu Aug 17 08:55:17 2006
New Revision: 116216
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116216
Log:
PR c++/28710
* decl.c (xref_tag): Improve
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-08-17 08:57
---
Fixed on mainline, 4.1 branch, and 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-08-17 08:58
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-08-17 09:07
---
Subject: Bug 28606
Author: reichelt
Date: Thu Aug 17 09:07:39 2006
New Revision: 116217
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116217
Log:
PR c++/28606
* parser.c
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-08-17 09:13
---
Subject: Bug 28606
Author: reichelt
Date: Thu Aug 17 09:13:13 2006
New Revision: 116218
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116218
Log:
PR c++/28606
* parser.c
--- Comment #7 from dwmw2 at infradead dot org 2006-08-17 09:16 ---
The one with proc_mkdir was because the EXPORT_SYMBOL is in a different file to
the original function -- although my version was working correctly, I'm willing
to deal with that case.
The symbol 'proc_root' is also
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-08-17 09:19
---
Subject: Bug 28606
Author: reichelt
Date: Thu Aug 17 09:19:27 2006
New Revision: 116219
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116219
Log:
PR c++/28606
* parser.c
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-08-17 09:20
---
Fixed on mainline, 4.1 branch, and 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from tim at klingt dot org 2006-08-17 09:43 ---
i have the same problem on my machine, using the latest snapshot.
i'm not sure, if the following information is helpful, but gcc -v gives me:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
--- Comment #9 from hubicka at gcc dot gnu dot org 2006-08-17 09:44 ---
Subject: Bug 27865
Author: hubicka
Date: Thu Aug 17 09:44:12 2006
New Revision: 116220
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116220
Log:
PR tree-optimization/27865
* reload1.c
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
Compiled java programs that are linked statically with gcj segfault on startup
(starting with GCC 4.1.x):
# gcj -g -static --main=test -Wl,--whole-archive -lnss_files_p -lnss_dns_p
-lresolv -lpthread -ldl -Wl,--no-whole-archive test.java
# ./a.out
Segmentation fault
with test.java being
--- Comment #1 from aeby at graeff dot com 2006-08-17 11:50 ---
Created an attachment (id=12087)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12087action=view)
Ugly workaround GC_PTHREAD_CREATE_NAME segfault
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760
Sytem information:
- LFS-based Linux, with kernel 2.6.15 (with some genpatches)
GCC configuring
---
./gcc-3.4.3/configure --prefix=/usr \
--libexecdir=/usr/lib --enable-shared \
--enable-threads=posix --enable-__cxa_atexit \
--enable-clocale=gnu
--- Comment #8 from jakub at gcc dot gnu dot org 2006-08-17 11:52 ---
Subject: Bug 28744
Author: jakub
Date: Thu Aug 17 11:52:26 2006
New Revision: 116222
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116222
Log:
PR c/28744
* cgraph.h (struct cgraph_node): Remove
--- Comment #1 from ist_alex at yahoo dot com 2006-08-17 11:52 ---
Created an attachment (id=12088)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12088action=view)
The original source code
Bug related file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28761
--- Comment #2 from ist_alex at yahoo dot com 2006-08-17 11:54 ---
Created an attachment (id=12089)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12089action=view)
The preprocessed source (*.ii) file
Bug related file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28761
--- Comment #3 from pluto at agmk dot net 2006-08-17 12:18 ---
this is not a bug. the c++ standard allows RVO optimization.
see $12.8/15 for more details.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28761
--- Comment #9 from jakub at gcc dot gnu dot org 2006-08-17 12:20 ---
The problem mentioned in #7 is not specific to variables, foo.c:
extern int foo (void);
__attribute__((externally_visible)) void *bar(void)
{
return foo;
}
bar.c:
__attribute__((externally_visible)) int foo (void)
--- Comment #3 from jakub at gcc dot gnu dot org 2006-08-17 12:38 ---
The is just the libstdc++ ABI check not being able to understand
tanl@@GLIBCXX_3.4 - [EMAIL PROTECTED] etc. changes (22 such symbols).
Those are not ABI breakers, all that means is that newly linked programs
won't
--- Comment #9 from brett dot albertson at stratech dot com 2006-08-17
13:02 ---
(In reply to comment #7)
Subject: Bug 27697
This fails on i386-pc-solaris2.10 on trunk with:
Executing on host: /u01/var/tmp/gcc_trunk_svn/gcc_20060817/gcc/xgcc
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-08-17 13:06
---
The fix of PR 28385 changed the behavior on mainline so that the bug
is now fixed on mainline (w.r.t. current version of the standard).
I.e. only the 4.0 branch and the 4.1 branch (and everyting before 3.4.1)
is
--- Comment #9 from spop at gcc dot gnu dot org 2006-08-17 13:14 ---
Subject: Bug 25211
Author: spop
Date: Thu Aug 17 13:14:26 2006
New Revision: 116223
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116223
Log:
PR middle-end/25211
PR middle-end/20256
PR
--- Comment #9 from spop at gcc dot gnu dot org 2006-08-17 13:14 ---
Subject: Bug 26435
Author: spop
Date: Thu Aug 17 13:14:26 2006
New Revision: 116223
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116223
Log:
PR middle-end/25211
PR middle-end/20256
PR
--- Comment #13 from spop at gcc dot gnu dot org 2006-08-17 13:14 ---
Subject: Bug 20256
Author: spop
Date: Thu Aug 17 13:14:26 2006
New Revision: 116223
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116223
Log:
PR middle-end/25211
PR middle-end/20256
PR
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-08-17 13:23 ---
(In reply to comment #0)
Note, this bug had caused a bootstrap failure, discussed here:
http://gcc.gnu.org/ml/gcc/2006-07/msg00108.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28289
--- Comment #4 from ist_alex at yahoo dot com 2006-08-17 13:57 ---
Never thought the C++ standard allows ignoring the code written in a dtor. What
if the dtor does something important (like in the example - it doesn't just
copy the contents)?
--
--- Comment #5 from ist_alex at yahoo dot com 2006-08-17 14:00 ---
I meant the copy ctor, not the dtor.
Anyhow, looking at it again, it makes some sense.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28761
--- Comment #6 from pluto at agmk dot net 2006-08-17 14:11 ---
(In reply to comment #5)
I meant the copy ctor, not the dtor.
Anyhow, looking at it again, it makes some sense.
When certain criteria are met, an implementation is allowed to omit the copy
construction of a class object,
--- Comment #2 from whaley at cs dot utsa dot edu 2006-08-17 14:17 ---
Richard,
Thanks for confirmation. There's no chance of this happening soon, I guess?
I'm working on a release of ATLAS (fast linear algebra), and I can't enable gcc
vectorization until its necessary flags are
--- Comment #3 from bonzini at gnu dot org 2006-08-17 14:28 ---
It probably will not happen before 4.3 and, even if it happened for 4.2, it
will never be backported to 4.1 since this one is in regression fixes-only
mode.
You could help by looking at the source code (there are only a
--- Comment #17 from bjoern dot m dot haase at web dot de 2006-08-17 14:36
---
I have made a superficial analysis of the issue and would like to discuss at
the end of this post a possible approach for resolving PR4131.
The first observation is, that when one is having a code segment
--- Comment #3 from bero at arklinux dot org 2006-08-17 14:45 ---
gcj -C miscompiles just org/eclipse/jdt/internal/compiler/lookup/Scope.java and
org/eclipse/jdt/internal/compiler/ast/QualifiedTypeReference.java -- I can
generate a perfectly working ecj using gcj -C for all files, then
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-17 14:48 ---
This is not a bug as mentioned by comment #6.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pault at gcc dot gnu dot org 2006-08-17 14:57 ---
(In reply to comment #6)
OK I understand it now. The PRIVATE declaration prevents references to 'a' and
'b' from being resolved, when USEing dummybdy_comm, because it suppresses the
symtree. This is demonstrated by
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-08-17 14:58
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-08-17 15:01
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.0 |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20256
--- Comment #8 from pault at gcc dot gnu dot org 2006-08-17 15:03 ---
Sorry, meant to accept this on the last reply.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-08-17 15:08 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-17 15:12 ---
Why are you trying to static link java code? It will almost not work for other
cases.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-17 15:28 ---
These are not strange at all, this is normal, just your prefix == triplet.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-17 15:32 ---
Can you show the output of the orginal configure?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-17 15:33 ---
I will let Daniel Berlin comment on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from hjl at lucon dot org 2006-08-17 15:53 ---
This patch
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00521.html
works for me on ia64:
http://gcc.gnu.org/ml/gcc-testresults/2006-08/msg00722.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28672
--- Comment #3 from daney at gcc dot gnu dot org 2006-08-17 16:18 ---
(In reply to comment #2)
Why are you trying to static link java code? It will almost not work for
other
cases.
We have 7.5X10^6 lines of code in about 800 classes that run fine statically
linked. So it does
The following program:
program write
implicit none
integer :: debuglevel = 1
if (0 debuglevel) write (0, ('test == ', f0.3)) 0.75
end program write
produces the following error at compile time:
gfortran foo.f90
In file foo.f90:5
if (0 debuglevel) write (0, ('test == ', f0.3)) 0.75
I have compiled a sample application that demonstrates my problem (see below
for the sample code).
Basically when I have two structures, one that contains a bitfield and one that
does not, the sizeof macro acts differently between the two structures.
These structures are identical as far as
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-17 18:01 ---
Actually I don't think they have the same alignment requirement.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-17 18:04 ---
Can you quote the ABI document that says they have the same alignment?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from hjl at lucon dot org 2006-08-17 18:16 ---
Wrong target is used for cross compiler build.
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #10 from pcarlini at suse dot de 2006-08-17 18:40 ---
Don't worry, the problem will be *certainly* resolved in time for the release:
the issue is clear, we know in detail what's going wrong and how to fix it.
Benjamin will.
--
--- Comment #8 from Vladislav dot Mikhailikov at paradox-neo dot uz
2006-08-17 18:51 ---
It seems that gcc-4.2 has the same problem. At least all .pch tests fail with
that option set
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28734
--- Comment #2 from pluto at agmk dot net 2006-08-17 19:18 ---
the `Y y2 = 2` requires two impicit user-defined conversions
(realized by conv-ctors) but standard allows at most one.
--
pluto at agmk dot net changed:
What|Removed |Added
--- Comment #13 from pluto at agmk dot net 2006-08-17 19:22 ---
(In reply to comment #12)
The patch is wrong, you need something like
-CFLAGS_FOR_TARGET = -O2 $(CFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET)
+CFLAGS_FOR_TARGET = -O2 $(LIBCFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET)
and similarly
--- Comment #14 from bonzini at gnu dot org 2006-08-17 19:24 ---
Please post to GCC Patches -- I am not a maintainer so I can't approve it
anyway. Also, you need a ChangeLog entry, and the CXXFLAGS_FOR_TARGET needs
the same treatment.
--
bonzini at gnu dot org changed:
--- Comment #4 from aeby at graeff dot com 2006-08-17 19:43 ---
A bug tracker is not the right place to discuss philosophy questions, so if
you'd like to continue the discussion, we should move over to e-mail or the gcj
mailing list (lookout for subject: GCJ 4.1.1 and static linking -
--- Comment #16 from mmitchel at gcc dot gnu dot org 2006-08-17 20:29
---
I think the patch in Comment #8 is OK, but that the right approach would be to
stop using %y to denote two different things. I think we should add
documentation saying that %y has dual meanings and check in this
% gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.4/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--- Comment #3 from mcvick_e at iname dot com 2006-08-17 22:17 ---
Are you telling me that if I put two of those structures side by side in memory
that GNU will mis-align them even though I pass the flag -mstrict-align? That
couldn't possibly be since the align flag states to use
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-17 22:19 ---
-mstrict-align does not do what you think it does. What it does is say the
alignment requirements for loads/stores cannot be violated.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28763
--- Comment #5 from mcvick_e at iname dot com 2006-08-17 22:28 ---
Additional information, if you insist on having an ABI then please go to this
link and look at pages 3-8 and 3-9. It states that bitfields have the same
alignment restrictions as their base types (int for int) (short
--- Comment #4 from jsm28 at gcc dot gnu dot org 2006-08-17 22:34 ---
The original simd-3.c still fails on mainline (my test compiler is configured
with --enable-e500_double but it still appears with -mfloat-gprs=single) though
the reduced test doesn't.
--
jsm28 at gcc dot gnu dot
--- Comment #6 from mcvick_e at iname dot com 2006-08-17 22:35 ---
The spec also has multiple examples of big versus little endian layouts and how
they map in memory and what their alignment is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28763
/ecj.jar
Using built-in specs.
Reading specs from /usr/lib/gcc/i486-linux-gnu/4.2.0/libgcj.spec
[...]
gcc version 4.2.0 20060817 (experimental) (Ubuntu 4.2-20060817-0ubuntu1)
gcj-4.2 -v \
-O2 -g -Wl,-Bsymbolic -fPIC -fjni -findirect-dispatch \
--main
--- Comment #15 from pluto at agmk dot net 2006-08-17 23:39 ---
(In reply to comment #13)
(In reply to comment #12)
The patch is wrong, you need something like
-CFLAGS_FOR_TARGET = -O2 $(CFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET)
+CFLAGS_FOR_TARGET = -O2 $(LIBCFLAGS)
--- Comment #7 from mcvick_e at iname dot com 2006-08-18 00:03 ---
(In reply to comment #4)
-mstrict-align does not do what you think it does. What it does is say the
alignment requirements for loads/stores cannot be violated.
That's fine for the -mstrict-align, however as I stated
I'd like to add Joern to the list.
sh4-unknown-linux-gnu build fails during libjave build with:
../../../ORIG/trunk/libjava/classpath/javax/swing/plaf/basic/BasicTextUI.java:
In class 'javax.swing.plaf.basic.BasicTextUI':
Compile this code with -O2:
#include ext/vstring.h
void foo(__gnu_cxx::__vstring s)
{
s.clear();
}
Look at the resulting assembler code. Do not show it to small children. It is
too scary.
With this simple patch:
--- include/ext/sso_string_base.h (revision 116231)
+++
--- Comment #1 from pcarlini at suse dot de 2006-08-18 02:13 ---
Hi Ian. Please go ahead with the inlining: only, from a stylistical point of
view, please move the entire body inline, do not mark inline the out of line
code. Patch preapproved, thanks a lot!
--
pcarlini at suse dot
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-18 02:23 ---
Actually I am going to implement the fix better, we really should be even
calling c_parser_objc_method_decl at the toplevel of parsing. I think it was
implemented this way because the old bison based parser did
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-18 02:28 ---
Actually no I am not going to fix this. Because it means I have to do a
partical rewrite on how c_parser_external_declaration is done for objc and I am
not going to do it.
--
pinskia at gcc dot gnu dot org
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |schwab at suse dot de
|dot org
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27880
--- Comment #4 from dberlin at gcc dot gnu dot org 2006-08-18 02:41 ---
Should be fixed now
--
dberlin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ngiff at yahoo dot com 2006-08-18 02:52 ---
i guess i'm supposed to verify/close this...
--
ngiff at yahoo dot com changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-18 03:20 ---
Wait a minute the C front-end produces for this testcase:
Unknown tree: compound_literal_expr
struct A D.1524 = {.i=0};
.i = Unknown tree: compound_literal_expr
struct A D.1524 = {.i=0};
.i + 1;
so
The following should be able to compile but does not:
struct A { int i; };
templateint t
void foo()
{
((struct A) { 0 }).i += 1;
}
void g(void)
{
foo0();
}
If we remove the template on foo, the statement with compund literal expression
is accepted.
--
Summary:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 03:30 ---
This is not a regression as far as I can tell.
Note I found this while working on PR 28418.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-18 03:42 ---
for +=/-= we could use PREINCREMENT_EXPR/PREDECREMENT_EXPR trees but for *=,
/=, |=, ^=, we cannot use any of the above.
I wonder if a SAVE_EXPR make this work?
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-18 03:54 ---
Here is a patch (though I have looked to see if it works with templates yet):
Index: init.c
===
--- init.c (revision 116236)
+++ init.c
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-18 04:02 ---
Mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-18 04:06 ---
Confirmed, it did not work in 3.4.0 which almost means this was caused by the
PCH changes.
Janis could you do a regression hunt on this one. The best way I guess to do
this is to put int main(void){} in a .h file.
For this code:
class A {
int f(void);
};
int (A::*ptr) (void);
GCC will output debug information claiming that the type of PTR is:
struct {
void (*__pfn) (args, ...);
ptrdiff_t __delta;
};
At least for dwarf2, GCC should output DW_TAG_ptr_to_member, just like it does
for data members.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 04:13 ---
Confirmed, we add the new attribute but we cannot convert between the types for
some reason. I bet there is a way to reproduce this without using new too but
I cannot find it.
--
pinskia at gcc dot gnu dot org
1 - 100 of 118 matches
Mail list logo
