[Bug target/18032] New: [4.0.0] SH: wrong code for EH
The program below doesn't exit with 0 as expected when it's compiled
with -O2. It works fine with -O1 or -O2 -fno-delayed-branch.
--
int *dummy;
void
bar (int *p)
{
dummy = p;
}
void
foo (int x)
{
int var;
bar (&var);
if (x)
throw 1;
}
int
main ()
{
try {
foo (1);
} catch (...) {
return 0;
}
return 1;
}
--
With -O2, the function foo looks like:
_Z3fooi:
.LFB3:
mov.l r8,@-r15
.LCFI3:
mov r4,r8
mov.l r14,@-r15
.LCFI4:
sts.l pr,@-r15
.LCFI5:
mov.l .L11,r1
add #-4,r15
.LCFI6:
mov r15,r14
.LCFI7:
jsr @r1
mov r14,r4
tst r8,r8
bf/s.L10
add #4,r14
mov r14,r15
lds.l @r15+,pr
mov.l @r15+,r14
rts
mov.l @r15+,r8
.align 5
.L10:
mov.l .L12,r0
jsr @r0
mov #4,r4
mov #1,r1
mov.l r1,@r0
mov.l .L13,r1
mov r0,r4
mov.l .L14,r5
jsr @r1
mov #0,r6
...
Thus the throw part starting with .L10 is called after the excution of
"add #4,r14" in the delayed slot. It seems that this doesn't match
the frame info of foo:
$ readelf -a ./a.out | grep foo
99: 00400760 100 FUNCGLOBAL DEFAULT 11 _Z3fooi
$ readelf --debug-dump=frames ./a.out
The section .eh_frame contains:
...
001c 0028 0020 FDE cie= pc=00400760..004007c4
Augmentation data: 00 00 00 00
DW_CFA_advance_loc: 2 to 00400762
DW_CFA_def_cfa_offset: 4
DW_CFA_offset: r8 at cfa-4
DW_CFA_advance_loc: 4 to 00400766
DW_CFA_def_cfa_offset: 8
DW_CFA_advance_loc: 2 to 00400768
DW_CFA_def_cfa_offset: 12
DW_CFA_advance_loc: 4 to 0040076c
DW_CFA_def_cfa_offset: 16
DW_CFA_offset: r17 at cfa-12
DW_CFA_offset: r14 at cfa-8
DW_CFA_advance_loc: 2 to 0040076e
DW_CFA_def_cfa_reg: r14
DW_CFA_nop
DW_CFA_nop
which assumes that r14 points the bottom of the frame when the throw
part is called.
--
Summary: [4.0.0] SH: wrong code for EH
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkojima at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: sh4-unknown-linux-gnu
GCC host triplet: sh4-unknown-linux-gnu
GCC target triplet: sh4-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18032
[Bug target/18032] [4.0.0] SH: wrong code for EH
-- What|Removed |Added Known to fail||3.4.2 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18032
[Bug middle-end/17793] [4.0 Regression] Ada bootstrap failure
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-16 09:02 --- > No this is an Ada front-end problem. Did you investigate? > I think the main issue is that the tree-ssa expects that INTEGER types are > close to the same and that pointers to them are compatible if the types are > themselves compatible so maybe the Ada front-end should be producing types > which are like that. Really if types are compatiable so should be the > pointers to them. Did you read what I wrote? The types are not compatible so the Ada front-end correctly puts a NOP_EXPR between them. But the gimplifier decides to strip it and later thinks it should not have done so. And, please, don't unassign PRs without discussing with the assignee beforehand. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Component|ada |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17793
[Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm
--- Additional Comments From amodra at bigpond dot net dot au 2004-10-16 10:58 --- Michal's reduced testcase, in comment #5, fails on powerpc-linux too. expand_increment is expanding the inline function body twice, at line 9261 op0 = expand_expr (incremented, NULL_RTX, VOIDmode, 0); and at line 9353 temp = expand_assignment (incremented, newexp, ! post && ! ignore); Targets such as x86 don't do the second expansion, because even though "post" is zero due to expr.c line 8774 /* Faster to treat as pre-increment if result is not used. */ return expand_increment (exp, ! ignore, ignore); "single_insn" is true. That suggested a slight modification to Michal's testcase might fail on x86, and indeed it does. So it seems this bug will hit all targets. Hopefully the clue I've given here about multiple expansion of the inline function body will trigger an "Ah ha!" moment in someone who knows their way around tree-inline.c. $ gcc/xgcc -Bgcc/ -xc++ -O -DBUG -S /src/tmp/pr17972.c $ cat pr17972.s .file "pr17972.c" .text .align 2 .globl _Z2fnv .type _Z2fnv, @function _Z2fnv: .LFB3: pushl %ebp .LCFI0: movl%esp, %ebp .LCFI1: .L2: jmp .L2 .LFE3: .size _Z2fnv, .-_Z2fnv .section.note.GNU-stack,"",@progbits .ident "GCC: (GNU) 3.4.3 20041015 (prerelease)" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
[Bug c++/10479] __alignof__(double) not compile time constant inside template class
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-16 11:05 --- Subject: Bug 10479 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-10-16 11:04:59 Modified files: gcc/cp : ChangeLog parser.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/ext: attrib16.C Log message: PR c++/10479 * parser.c (cp_parser_parenthesized_expression_list): Fold non-dependent expressions in attribute lists. PR c++/10479 * g++.dg/ext/attrib16.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4439&r2=1.4440 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&r1=1.264&r2=1.265 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4461&r2=1.4462 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/attrib16.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10479
[Bug c++/10479] alignof and sizeof (and other expressions) in attributes does not compile inside template classes
--- Additional Comments From giovannibajo at libero dot it 2004-10-16 11:06 --- Fixed in GCC 4.0.0. Thanks for your report! -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|__alignof__(double) not |alignof and sizeof (and |compile time constant inside|other expressions) in |template class |attributes does not compile ||inside template classes Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10479
[Bug libstdc++/8670] Alignment problem in std::basic_string
-- Bug 8670 depends on bug 10479, which changed state. Bug 10479 Summary: alignof and sizeof (and other expressions) in attributes does not compile inside template classes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10479 What|Old Value |New Value Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
[Bug libstdc++/8670] Alignment problem in std::basic_string
--- Additional Comments From giovannibajo at libero dot it 2004-10-16 11:10
---
I see this report is marked as a v3 report. I do not understand exactly what
you still need to fix in C++. I have a patch in my (long) queue which fixes
this:
template
struct S {
enum { K = 8 };
char foo __attribute__((aligned(K)));
};
Can I assume that this bug is about this issue, and thus assigning this to me
(if Gaby does not mind) or is it better if I open a new report?
--
What|Removed |Added
CC||giovannibajo at libero dot
||it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
[Bug libstdc++/8670] Alignment problem in std::basic_string
--- Additional Comments From giovannibajo at libero dot it 2004-10-16 12:38 --- (In reply to comment #7) > I do not understand exactly what you still need to fix in C++. I meant: I do not understand exactly what needs to be fixed in the C++ FE and what needs to be fixed in v3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
[Bug rtl-optimization/17428] [4.0 Regression] internal compiler error: in spill_failure, at reload1.c:1880
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-16 13:29 --- Speculative prefetching is now disabled by default on mainline by David Edelsohn's patch http://gcc.gnu.org/ml/gcc-cvs/2004-10/msg00928.html Therefore, one has to add -fspeculative-prefetching to the command line to trigger the bug on mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17428
[Bug c++/18024] IOT/Abort trap (core dumped) on AIX with -pthread
--- Additional Comments From askees at appfluent dot com 2004-10-16 13:48 --- After many attempts with various configure settings, I was able to get 3.4.2 (with both libstdc++-v3 and libgcc_s_pthread) installed. As in 3.3.5, the problem still exists if both libpthread (in /usr/lib/libpthreads.a) and libgcc_s_pthread are linked. If I explicitly remove libgcc_s_pthread, the core does not occur. However, this library is linked automatically by the -pthread option, so I assume it is important and required. As a side note, I tried the example code in bug #13391 and those test cases are broken as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18024
[Bug c++/17743] __alignof__ vs. typedefs
--- Additional Comments From bkoz at redhat dot com 2004-10-16 13:52 --- Subject: Re: __alignof__ vs. typedefs >OK. But XFAIL the tr1 test cases so those do not show up as new FAILs. I think I just took care of this. Giovanni, thanks! -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17743
[Bug middle-end/17793] [4.0 Regression] Ada bootstrap failure
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-16 13:55 --- check_pointer_types_r is wrong but so is Ada assuming that integer types are not compatible (read the full bug report which I reported in the first place): "The integer_type's are not compatible by defined by the front-end, why?" See this is where Ada becomes wrong with respect to generic and gimple where it needs integer types which have the same PRECISION, UNSIGNEDness, and SIZE are consided compatible types (so are their POINTERs). For Kenner here, Generic and Gimple have the same type system which is partly described above. Yes this is not documented but should be. This again is an Ada bug not doing what the middle-end generic and gimple expects to happen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17793
[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-16 13:57 --- Confirmed, this needs a tree combiner. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-10-16 13:57:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18031
[Bug target/18032] [4.0.0] SH: wrong code for EH
-- What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18032
[Bug bootstrap/18033] New: --disable-aix64 doesn't remove ppc64 from multilib list
The --disable-aix64 (--enable-aix64=no) configuration switch claims to remove ppc64 from the multilib list; however, it doesn't seem to work. On a 32-bit AIX system, it must be disabled or the build fails when "checking whether the C compiler works". The larger --disable-multilib switch works, but is not desirable since it disables all other libraries including libgcc_s_pthread. config.status: #! /bin/sh # Generated automatically by configure. # Run this file to recreate the current configuration. # This directory was configured as follows, # on host askees-aix: # # /home/downloads/gcc/gcc-3.4.2/configure --enable-threads=posix --prefix=/usr/ local/gcc/gcc-3.4.2 --enable-languages=c,c++ --enable-aix64=no --with-gcc-versio n-trigger=/home/downloads/gcc/gcc-3.4.2/gcc/version.c Bootstrap failure (you can see it entering ppc64 despite being disable): gmake[2]: Leaving directory `/home/downloads/gcc/gcc-3.4.2.objdir3/powerpc-ibm- aix5.1.0.0/powerpc/libstdc++-v3/include' Running configure in multilib subdir ppc64 pwd: /home/downloads/gcc/gcc-3.4.2.objdir3/powerpc-ibm-aix5.1.0.0 mkdir ppc64 configure: creating cache ./config.cache checking build system type... powerpc-ibm-aix5.1.0.0 checking host system type... powerpc-ibm-aix5.1.0.0 checking target system type... powerpc-ibm-aix5.1.0.0 checking for a BSD-compatible install... /home/downloads/gcc/gcc-3.4.2/install- sh -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether gmake sets $(MAKE)... yes checking for powerpc-ibm-aix5.1.0.0-gcc... /home/downloads/gcc/gcc- 3.4.2.objdir3/gcc/xgcc -B/home/downloads/gcc/gcc-3.4.2.objdir3/gcc/ - B/usr/local/gcc/gcc-3.4.2/powerpc-ibm-aix5.1.0.0/bin/ -B/usr/local/gcc/gcc- 3.4.2/powerpc-ibm-aix5.1.0.0/lib/ -isystem /usr/local/gcc/gcc-3.4.2/powerpc-ibm- aix5.1.0.0/include -isystem /usr/local/gcc/gcc-3.4.2/powerpc-ibm-aix5.1.0.0/sys- include -maix64 checking for C compiler default output... a.out checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. gmake[1]: *** [configure-target-libstdc++-v3] Error 1 gmake[1]: Leaving directory `/home/downloads/gcc/gcc-3.4.2.objdir3' gmake: *** [bootstrap] Error 2 -- Summary: --disable-aix64 doesn't remove ppc64 from multilib list Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: askees at appfluent dot com CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: powerpc-ibm-aix5.1.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18033
[Bug bootstrap/18033] --disable-aix64 doesn't remove ppc64 from multilib list
-- What|Removed |Added GCC host triplet||powerpc-ibm-aix5.1.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18033
[Bug tree-optimization/16611] Terrible code generated for vector
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-16 14:11
---
We look much better now but still little problems:
bool f(const std::vector >&, size_t) (v, x)
{
ptrdiff_t __n.82;
unsigned int SR.77;
_Bit_type * __x;
ptrdiff_t __n;
struct _Bit_iterator & __x;
:
__x = &v->D.10279._M_impl._M_start; //<--this could be pushed into the next two
instructions
__n = (ptrdiff_t) (__x->D.8752._M_offset + (unsigned int) (ptrdiff_t) x);
__x = __x->D.8752._M_p + (_Bit_type *) ((unsigned int) (__n / 32) * 4);
__n.82 = __n % 32;
if (__n.82 < 0) goto ; else goto ; //<-- could be done based on __n instead
of __n.82
:;
SR.77 = (unsigned int) (__n.82 + 32);
__x = __x - 4B;
goto ();
:;
SR.77 = (unsigned int) __n.82;
:;
return (int) (bool) (int) (bool) (int) (bool) ((1 << (int) SR.77 & *__x) != 0);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16611
[Bug debug/17076] [3.4 regression] ICE on variable size array initialization in debug mode in C++
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC build triplet|sparc-sun-solaris2.9| GCC host triplet|sparc-sun-solaris2.9| GCC target triplet|sparc-sun-solaris2.9| Last reconfirmed|-00-00 00:00:00 |2004-10-16 14:24:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17076
[Bug libstdc++/8670] Alignment problem in std::basic_string
--- Additional Comments From gdr at cs dot tamu dot edu 2004-10-16 14:48 ---
Subject: Re: Alignment problem in std::basic_string
"giovannibajo at libero dot it" <[EMAIL PROTECTED]> writes:
| I see this report is marked as a v3 report. I do not understand exactly what
| you still need to fix in C++. I have a patch in my (long) queue which fixes
| this:
|
| template
| struct S {
|enum { K = 8 };
|char foo __attribute__((aligned(K)));
| };
|
| Can I assume that this bug is about this issue, and thus assigning this to me
| (if Gaby does not mind) or is it better if I open a new report?
I don't mind you take on bugs, as far as they are fixed :-)
The V3 bits in this is that we need to get basic_string fixed.
If the front-end ix fixed, then we can use the aligned attribute in a
meaningful way.
Thanks
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
[Bug pending/18034] New: GCC 3.4.2/GNAT bootstrap problem
NOTE: Defaulting component because reported component no longer exists The bootstrap process fails during stage 3 when the stage 2 xgcc is used to compile the root file of the Ada Standard library, the package Ada itself: stage2/xgcc -Bstage2/ -B/usr/local2/mips-sgi-irix6.2/bin/ -c -g -O2 -gnatpg -gnata -I- -I. -Iada -I../../srcdir/gcc/ada ../../srcdir/gcc/ada/ada.ads -o ada/ada.o xgcc: Internal error: Segmentation fault (program gnat1) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [ada/ada.o] Error 1 make[2]: Leaving directory `/usr/people/franke/install/objdir/gcc' make[1]: *** [stage3_build] Error 2 make[1]: Leaving directory `/usr/people/franke/install/objdir/gcc' make: *** [bootstrap] Error 2 A core file is generated: (glanzer 504) $ file install/objdir/gcc/core install/objdir/gcc/core:IRIX N32 core dump of 'gnat1' (glanzer 505) $ strings install/objdir/gcc/core | head gnat1 stage2/gnat1 -I- -I. -Iada -I../../srcdir/gcc/adstage2/gnat1 -I- -I. -Iada -I../../srcdir/gcc/ada -quiet -dumpbase ada.ads -g - Environment: System: IRIX64 glanzer 6.2 06101031 IP28 host: mips-sgi-irix6.2 build: mips-sgi-irix6.2 target: mips-sgi-irix6.2 configured with: ../srcdir/configure --enable-languages=c,c++,ada --prefix=/usr/local2 --disable-nls --disable-multilib How-To-Repeat: Rerun the bootstrap. --- Additional Comments From franke at euro-telematik dot de 2004-10-16 14:49 --- Fix: Fix unknown, but behaviour observed in 3.4.0 and 3.4.1, too. -- Summary: GCC 3.4.2/GNAT bootstrap problem Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: critical Priority: P2 Component: pending AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: franke at euro-telematik dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: mips-sgi-irix6.2 GCC host triplet: mips-sgi-irix6.2 GCC target triplet: mips-sgi-irix6.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18034
[Bug c/17957] [4.0 regression] vector type node used after garbage-collected
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-16 15:00 --- Confirmed. Jan, the problem appears with your patch http://gcc.gnu.org/ml/gcc-cvs/2004-09/msg00192.html Could you please have a look? -- What|Removed |Added CC||hubicka at gcc dot gnu dot ||org, reichelt at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||monitored Known to fail||4.0.0 Known to work||3.4.2 Last reconfirmed|-00-00 00:00:00 |2004-10-16 15:00:04 date|| Summary|vector type node used after |[4.0 regression] vector type |garbage-collected |node used after garbage- ||collected Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17957
[Bug target/18034] GCC 3.4.2/GNAT bootstrap problem
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-16 15:01 --- Try looking into PR 6552 and PR 6669. Those two might tell you what the problem is. It might be stage1 is being miscompile which miscompiles stage2 which causes this problem. -- What|Removed |Added Severity|critical|normal Component|pending |target Keywords||build, wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18034
[Bug libstdc++/8670] Alignment problem in std::basic_string
--- Additional Comments From giovannibajo at libero dot it 2004-10-16 15:14 --- Ok, then this is mine for the time being. I will fix the testcases in comment #6 and comment #7 in a short while. -- What|Removed |Added AssignedTo|gdr at gcc dot gnu dot org |giovannibajo at libero dot ||it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
[Bug c++/18028] nested calls to template constructors generate incorrect result
--- Additional Comments From bangerth at dealii dot org 2004-10-16 15:26 ---
Yes, to be more specific: in this situation
-
struct X {
template X(T t);
};
int main () {
X x;
X y(x);
}
-
the compiler has to generate a copy constructor itself, the template
copy constructor is only used for arguments T which are not of type
X. You will want to have an additional, non-template constructor.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18028
[Bug middle-end/18005] [4.0 Regression] ICE with simple loop
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-16 15:37
---
Here's an even shorter example. Just compile with "-O".
const int n = 2;
void foo()
{
int a[1][n], i;
for (i=0; i<2; ++i)
if (a[0][i]) return;
}
Sebastian, the problem appeared with your patch
http://gcc.gnu.org/ml/gcc-cvs/2004-10/msg00852.html
Could you please have a look?
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
GCC build triplet|x86_64-linux-gnu|
GCC host triplet|x86_64-linux-gnu|
GCC target triplet|x86_64-linux-gnu|
Keywords||monitored
Summary|[4.0 Regression] ICE in |[4.0 Regression] ICE with
|fold-const.c/fold |simple loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18005
[Bug c++/10479] alignof and sizeof (and other expressions) in attributes does not compile inside template classes
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2004-10-16 15:42 --- Subject: Re: alignof and sizeof (and other expressions) in attributes does not compile inside template classes giovannibajo at libero dot it wrote: > --- Additional Comments From giovannibajo at libero dot it 2004-10-16 11:06 > --- > Fixed in GCC 4.0.0. Thanks for your report! Can this be trivially backported to 3.4? That would be cool. Thanks, Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10479
[Bug middle-end/18030] OR is inefficient in 2-bit bitfield
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-16 15:49 --- A patch here: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01333.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18030
[Bug middle-end/18029] an xor of a single bit bitfield is inefficient
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-16 15:49 --- A patch here: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01333.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18029
gcc-bugs@gcc.gnu.org
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-16 16:07 --- Andrew, your patch http://gcc.gnu.org/ml/gcc-cvs/2004-08/msg01149.html seems to be responsible for the regression. -- What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Keywords||monitored http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17885
gcc-bugs@gcc.gnu.org
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-16 16:10 --- Yes it is responable in finding the latent bug in the gimplifier, if I have time I will try to see how to fix it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17885
[Bug c/18035] New: target "gcc-no-fixedincludes" in Makefile doesn't check for proper return value of sub-make
When I run these commands to install gcc (in a separate build directory):
-
make prefix=/mnt/hvlinux/static install-no-fixedincludes 1> make.log 2>&1
echo "Return value of Make = ${?}"
-
the return value is zero. But if I check the log (make.log), I can see that
there was an error in one of the sub-make called. The reason is that the shell
code in the "gcc-no-fixedincludes" target doesn't check if the sub-make return
value is valid, and continues anyway whatever the return code is. The value
returned by the sub-make command is 2 in my case. Here is the part of the
Makefile that causes that:
# Install the gcc headers files, but not the fixed include files,
# which Cygnus is not allowed to distribute. This rule is very
# dependent on the workings of the gcc Makefile.in.
.PHONY: gcc-no-fixedincludes
gcc-no-fixedincludes:
@if [ -f ./gcc/Makefile ]; then \
rm -rf gcc/tmp-include; \
mv gcc/include gcc/tmp-include 2>/dev/null; \
mkdir gcc/include; \
cp $(srcdir)/gcc/gsyslimits.h gcc/include/syslimits.h; \
touch gcc/stmp-fixinc gcc/include/fixed; \
rm -f gcc/stmp-headers gcc/stmp-int-hdrs; \
r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}` ; export s; \
$(SET_LIB_PATH) \
(cd ./gcc && \
$(MAKE) $(GCC_FLAGS_TO_PASS) install); \
echo "return-code-test: error=$${?}"; \
rm -rf gcc/include; \
mv gcc/tmp-include gcc/include 2>/dev/null; \
else true; fi
--
Summary: target "gcc-no-fixedincludes" in Makefile doesn't check
for proper return value of sub-make
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hugo at hugovil dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: 3.4.2
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18035
[Bug c/18035] target "gcc-no-fixedincludes" in Makefile doesn't check for proper return value of sub-make
--- Additional Comments From hugo at hugovil dot com 2004-10-16 16:20 --- Created an attachment (id=7364) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7364&action=view) Output of make with the failure in a sub-make not handled correctly -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18035
[Bug bootstrap/18035] target "gcc-no-fixedincludes" in Makefile doesn't check for proper return value of sub-make
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-16 16:25 --- Is this before or after building gcc if before you have to build gcc first. -- What|Removed |Added Component|c |bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18035
[Bug bootstrap/18035] target "gcc-no-fixedincludes" in Makefile doesn't check for proper return value of sub-make
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-16 16:28 --- Also install-no-fixedincludes should not be used unless you know what you are doing as most of the times you need fixed includes as the version of glibc headers use __thread as an agrument which is used for a type spec now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18035
[Bug target/18024] IOT/Abort trap (core dumped) on AIX with -pthread
-- What|Removed |Added Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18024
[Bug fortran/18023] ice on trying to convert between int and float
--- Additional Comments From tobi at gcc dot gnu dot org 2004-10-16 16:31 --- Patch here: http://gcc.gnu.org/ml/fortran/2004-10/msg00162.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18023
[Bug rtl-optimization/17723] [4.0 regression] gcc segfaults with -O2
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-16 16:42 --- Subject: Bug 17723 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-10-16 16:42:32 Modified files: gcc: ChangeLog cfgcleanup.c Log message: PR rtl-optimization/17723 * cfgcleanup.c (merge_memattrs): Handle case when MEM_SIZE == NULL_RTX. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5904&r2=2.5905 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cfgcleanup.c.diff?cvsroot=gcc&r1=1.131&r2=1.132 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17723
[Bug rtl-optimization/17723] [4.0 regression] gcc segfaults with -O2
--- Additional Comments From rakdver at gcc dot gnu dot org 2004-10-16 16:43 --- Fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17723
[Bug rtl-optimization/17723] [4.0 regression] gcc segfaults with -O2
--- Additional Comments From rakdver at gcc dot gnu dot org 2004-10-16 16:43 --- Really :-) -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17723
[Bug tree-optimization/17560] [4.0 Regression] Infinite recursion in tree-scalar-evolution with -Os
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-16 16:45 --- Subject: Bug 17560 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-10-16 16:45:38 Modified files: gcc: ChangeLog predict.c Log message: PR tree-optimization/17560 * predict.c (tree_estimate_probability): Mark irreducible loops. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5905&r2=2.5906 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/predict.c.diff?cvsroot=gcc&r1=1.128&r2=1.129 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17560
[Bug tree-optimization/17560] [4.0 Regression] Infinite recursion in tree-scalar-evolution with -Os
--- Additional Comments From rakdver at gcc dot gnu dot org 2004-10-16 16:46 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17560
[Bug tree-optimization/17704] [4.0 Regression] Infinite recursion in tree-scalar-evolution with -Os
-- Bug 17704 depends on bug 17560, which changed state. Bug 17560 Summary: [4.0 Regression] Infinite recursion in tree-scalar-evolution with -Os http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17560 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17704
[Bug tree-optimization/17766] [4.0 Regression] cc1 hangs in with -O3, works with -O2
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-16 16:59 --- Subject: Bug 17766 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-10-16 16:58:59 Modified files: gcc: ChangeLog basic-block.h cfghooks.c dominance.c tree-cfg.c tree-complex.c tree-mudflap.c Log message: PR tree-optimization/17766 * basic-block.h (enum dom_state): DOM_CONS_OK removed. (dom_info_available_p): Declare. * cfghooks.c (split_block, make_forwarder_block): Use dom_info_available_p. * dominance.c (compute_dom_fast_query, calculate_dominance_info, free_dominance_info, verify_dominators): Ditto. (dom_info_available_p): New function. * tree-cfg.c (cleanup_control_expr_graph): Free dominance information. (thread_jumps): Use dom_info_available_p. * tree-complex.c (expand_complex_div_wide): Ditto. * tree-mudflap.c (mf_build_check_statement_for): Ditto. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5907&r2=2.5908 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/basic-block.h.diff?cvsroot=gcc&r1=1.219&r2=1.220 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cfghooks.c.diff?cvsroot=gcc&r1=1.16&r2=1.17 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dominance.c.diff?cvsroot=gcc&r1=1.31&r2=1.32 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gcc&r1=2.77&r2=2.78 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-complex.c.diff?cvsroot=gcc&r1=2.12&r2=2.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-mudflap.c.diff?cvsroot=gcc&r1=2.29&r2=2.30 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17766
[Bug tree-optimization/17766] [4.0 Regression] cc1 hangs in with -O3, works with -O2
--- Additional Comments From rakdver at gcc dot gnu dot org 2004-10-16 16:59 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17766
[Bug middle-end/17793] [4.0 Regression] Ada bootstrap failure
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-16 17:26 --- [Thanks for elaborating on your position.] > check_pointer_types_r is wrong but so is Ada assuming that integer types are > not compatible (read the full bug report which I reported in the first place): > "The integer_type's are not compatible by defined by the front-end, why?" My understanding is that type compatibility is purely a front-end business, so there is not really a notion of being right or wrong here. The middle-end should be able to cope with either situation. > See this is where Ada becomes wrong with respect to generic and gimple where > it needs integer types which have the same PRECISION, UNSIGNEDness, and SIZE > are consided compatible types (so are their POINTERs). Could you point me at where this requirement is documented? The Ada front-end contains this comment (misc.c:560): ??? We may also want to generalize to considering lots of integer types compatible, but we need to understand the effects of alias sets first. > For Kenner here, Generic and Gimple have the same type system which is partly > described above. Yes this is not documented but should be. This again is an > Ada bug not doing what the middle-end generic and gimple expects to happen. I think the issue is orthogonal to the discussion on the type systems of GENERIC and GIMPLE. The front-end generates a correct GENERIC tree AFAICS so the gimplifier should be able to deal with it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17793
[Bug bootstrap/18035] target "gcc-no-fixedincludes" in Makefile doesn't check for proper return value of sub-make
--- Additional Comments From hugo at hugovil dot com 2004-10-16 18:00 --- This happens after I have successfully configured and built gcc. But the reason why the error happens is not important for me right now. My concern is that an error occured during gcc installation, but the make return code doesn't reflect that error. And by looking at the gcc-no-fixedincludes target, you will see that the error code returned by "$(MAKE) $(GCC_FLAGS_TO_PASS) install" is never verified for validity. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18035
[Bug c++/10479] alignof and sizeof (and other expressions) in attributes does not compile inside template classes
--- Additional Comments From giovannibajo at libero dot it 2004-10-16 18:16 --- There are good chances that this can be easily backported to 3.4. On the other hand, this is not a regression, so you will need to talk Mark into doing it. I can easily test and commit the patch also there, if Mark agrees. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10479
[Bug c/17957] [4.0 regression] vector type node used after garbage-collected
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-16 18:36 --- Note I see something like this with --enable-intermodule but I did not reduce the problem (there might be another bug like this too). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17957
[Bug c++/16572] [3.4 regression] Wrong filename/line number were reported by g++ in inlining's warning messages
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-16 19:23 --- Jan's patch fixed the wrong line number information also in other cases like PR17523. -- What|Removed |Added OtherBugsDependingO||17523 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16572
[Bug c++/17523] extra ';' warning on wrong line
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17523
[Bug target/17224] [3.4/4.0 Regression]: relocation truncated to fit: GPREL22
--- Additional Comments From hjl at lucon dot org 2004-10-16 19:31 --- This is a 3.4/4.0 regression. Gcc 3.2 generates correct code: .file "foo.c" .pred.safe_across_calls p1-p5,p16-p63 .sbss .align 4 .type n.0#,@object .size n.0#,4 n.0: .skip 4 .text .align 16 .global main# .proc main# main: .prologue .body .mib nop 0 mov r8 = r14 br.ret.sptk.many b0 .endp main# .align 16 .global foo# .proc foo# foo: .prologue .body .mlx addl r2 = @gprel(n.0#), gp movl r3 = -357910392 ;; .mib nop 0 add r8 = r2, r3 br.ret.sptk.many b0 .endp foo# .ident "GCC: (GNU) 3.2.3 20030502 (Red Hat Linux 3.2.3-42)" -- What|Removed |Added Summary|relocation truncated to fit:|[3.4/4.0 Regression]: |GPREL22 |relocation truncated to fit: ||GPREL22 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17224
[Bug libgcj/18036] Bad interaction between interpreter and Class.forName()
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-16 22:17 --- Can you attach the source? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18036
[Bug c/17957] [4.0 regression] vector type node used after garbage-collected
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-16 22:18 --- Never mind about my --enable-intermodule problem is a related but not the same problem (Dale posted a patch to fix it). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17957
[Bug c++/15172] Copy constructor optimization in aggregate initialization
--- Additional Comments From acehreli at yahoo dot com 2004-10-16 22:57 ---
I don't think the paragraphs from the standard that are mentioned above are
completely relevant. There isn't an opportunity for optimization in this case.
This is aggregate initialization.
I found the following paragraphs to be describing this case exactly:
8.5.1/1
8.5.1/13
12.6.1/2
The first example under 12.6.1/2 is directly relevant:
[Example:
complex v[6] = { 1,complex(1,2),complex(),2 };
Here, complex::complex(double) is called for the initialization of v[0] and v
[3], complex::complex(double,double) is called for the initialization of v[1],
complex::complex() is called for the initialization v[2], v[4], and v[5].
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15172
[Bug ada/17527] Ada Bootstrap problem because of -Werror
--- Additional Comments From v dot haisman at sh dot cvut dot cz 2004-10-16 23:27 --- Subject: Re: Ada Bootstrap problem because of -Werror It still fails to build for me on FreeBSD 4.10. stage1/xgcc -Bstage1/ -B/home/4/wilx/i386-unknown-freebsd4.10/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes-Werror -fno-common -DHAVE_CONFIG_H \ -I/home/4/wilx/include -I. -Iada -I../../srcdir/gcc -I../../srcdir/gcc/ada -I../../srcdir/gcc/../include -I../../srcdir/gcc/../libcpp/include ../../srcdir/gcc/ada/init.c -o ada/init.o cc1: warnings being treated as errors ../../srcdir/gcc/ada/init.c:1586: warning: function declaration isn't a prototype ../../srcdir/gcc/ada/init.c: In function '__gnat_error_handler': ../../srcdir/gcc/ada/init.c:1597: warning: assignment discards qualifiers from pointer target type ../../srcdir/gcc/ada/init.c:1602: warning: assignment discards qualifiers from pointer target type ../../srcdir/gcc/ada/init.c:1607: warning: assignment discards qualifiers from pointer target type ../../srcdir/gcc/ada/init.c:1612: warning: assignment discards qualifiers from pointer target type ../../srcdir/gcc/ada/init.c:1617: warning: assignment discards qualifiers from pointer target type ../../srcdir/gcc/ada/init.c:1587: warning: unused parameter 'code' ../../srcdir/gcc/ada/init.c:1588: warning: unused parameter 'sc' ../../srcdir/gcc/ada/init.c: At top level: ../../srcdir/gcc/ada/init.c:1642: warning: function declaration isn't a prototype make[2]: *** [ada/init.o] Error 1 make[2]: Leaving directory `/home/4/wilx/tmp/gcc-head/objdir/gcc' make[1]: *** [stage2_build] Error 2 make[1]: Leaving directory `/home/4/wilx/tmp/gcc-head/objdir/gcc' make: *** [bootstrap] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17527
[Bug c++/15172] Copy constructor optimization in aggregate initialization
--- Additional Comments From bangerth at dealii dot org 2004-10-16 23:28 ---
Something is definitely wrong with this testcase. I think that storing and
printing the _this pointer is only obstructing the view of the problem
somehow, so consider this example here:
int printf (const char *format, ...);
struct A {
A ()
{ printf ("A::A () : this = %p\n", this); }
A (const A & a)
{ printf ("A::A (const A&) : this = %p\n", this); }
~ A ()
{ printf ("A::~A () : this = %p\n", this); }
void print ()
{ printf ("print () : this = %p\n", this); }
};
struct B {
A a;
};
B b = { A () };
int main () {
b.a.print ();
}
I think we all agree that we always have to have matching calls to
(copy) constructors and destructors for a this pointer, but we really
get this here:
g/x> c++ x.cc
g/x> ./a.out
A::A () : this = 0xbfffeaa0
print () : this = 0x80499c8
A::~A () : this = 0x80499c8
I don't think this can ever be right.
This used to work in gcc2.95, but is broken between 3.2 and 3.4. It works
fine in mainline again, though, so this is a 3.3/3.4 branch regression
only.
W.
--
What|Removed |Added
Keywords|missed-optimization |wrong-code
Known to fail||3.2.3 3.3.5 3.4.2
Known to work||2.95 4.0.0
Last reconfirmed|2004-06-03 22:57:00 |2004-10-16 23:28:23
date||
Target Milestone|--- |3.4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15172
[Bug c++/15172] [3.3/3.4 regression] Copy constructor optimization in aggregate initialization
--- Additional Comments From bangerth at dealii dot org 2004-10-16 23:34 ---
The reason, btw, why I believe that this is wrong code is that the this
pointer of the object being constructed can escape, like here:
extern "C" int printf (const char *format, ...);
struct A;
void register_A (const A* a) {printf ("registering %p\n", a); }
void deregister_A (const A* a) {printf ("deregistering %p\n", a); }
struct A {
A (){ register_A(this); }
A (const A & a) { register_A(this); }
~ A () { deregister_A(this); }
};
struct B {
A a;
};
B b = { A () };
int main () {}
It is certainly more than just a nuisance ("missed optimization") that
the calls to register and deregister don't match!
g/x> c++ x.cc
g/x> ./a.out
g/x> c++ x.cc
g/x> ./a.out
registering 0xbfffeaa0
deregistering 0x8049990
W.
--
What|Removed |Added
Severity|enhancement |critical
Summary|Copy constructor|[3.3/3.4 regression] Copy
|optimization in aggregate |constructor optimization in
|initialization |aggregate initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15172
[Bug tree-optimization/17672] [4.0 Regression] ICE in build_classic_dist_vector
--- Additional Comments From dberlin at gcc dot gnu dot org 2004-10-17 00:20 --- Actually, this just lets us run into another bug, i'm about to submit a patch to fix bootstrap fully with -ftree-loop-linear -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17672
[Bug c++/15172] [3.3/3.4 regression] Copy constructor optimization in aggregate initialization
--- Additional Comments From acehreli at yahoo dot com 2004-10-17 01:01 --- We've seen the problem in 2.95.3 and 3.4.2. There is a recent posting to comp.lang.c++.moderated about the same problem, with the subject "Bitwise copy during aggregate initialization (a compiler bug?)". Ali -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15172
[Bug c++/18037] New: g++ segfaults on templated code (simple test file included)
[EMAIL PROTECTED]:~/random/gcc$ g++ -v -save-temps foo.cpp
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.4/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib
--enable-nls --without-included-gettext --enable-__cxa_atexit
--enable-clocale=gnu --enable-debug --enable-java-gc=boehm
--enable-java-awt=xlib --enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.4 (Debian 1:3.3.4-13)
/usr/lib/gcc-lib/i486-linux/3.3.4/cc1plus -E -D__GNUG__=3 -quiet -v
-D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=4 -D_GNU_SOURCE foo.cpp foo.ii
ignoring nonexistent directory "/usr/i486-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/3.3
/usr/include/c++/3.3/i486-linux
/usr/include/c++/3.3/backward
/usr/local/include
/usr/lib/gcc-lib/i486-linux/3.3.4/include
/usr/include
End of search list.
/usr/lib/gcc-lib/i486-linux/3.3.4/cc1plus -fpreprocessed foo.ii -quiet
-dumpbase foo.cpp -auxbase foo -version -o foo.s
GNU C++ version 3.3.4 (Debian 1:3.3.4-13) (i486-linux)
compiled by GNU C version 3.3.4 (Debian 1:3.3.4-13).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64537
foo.cpp:50: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
.
[EMAIL PROTECTED]:~/random/gcc$ cat foo.cpp
#include
#include
template
class PatternMap {
typedef std::vector vecT;
typedef std::pair pairT;
typedef std::vector vecP;
typedef std::map mapT;
public:
class iterator {
public:
iterator(const iterator& i);
~iterator();
T& operator*();
T* operator->();
iterator& operator++();
iterator operator++(int);
bool atEnd() const;
private:
iterator();
void updateMixed();
int n;
vecT* allParent;
typename vecT::iterator all;
vecP* mixedParent;
typename vecP::iterator mixed;
vecT* literalParent;
typename vecT::iterator literal;
};
PatternMap();
virtual ~PatternMap();
iterator find(const int &n);
private:
vecT all;
mapT mixed;
mapT literal;
};
template PatternMap::iterator&
PatternMap::iterator::iterator& operator++() {
if(allParent && all != allParent->end()) {
++all;
if(all == allParent->end()) {
updateMixed();
}
return *this;
}
if(mixedParent && mixed != mixedParent->end()) {
++mixed;
updateMixed();
return *this;
}
if(literalParent && literal != literalParent->end()) {
++litIt;
}
return *this;
}
int main(int argc, char** argv) {
}
[EMAIL PROTECTED]:~/random/gcc$
--
Summary: g++ segfaults on templated code (simple test file
included)
Product: gcc
Version: 3.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mfowles at bluefinrobotics dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18037
[Bug c++/18037] g++ segfaults on templated code (simple test file included)
--- Additional Comments From mfowles at bluefinrobotics dot com 2004-10-17 01:41 --- Created an attachment (id=7365) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7365&action=view) the file that makes it segfault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18037
[Bug c++/18037] g++ segfaults on templated code (simple test file included)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-17 02:24 --- Fixed in 3.4.0 and above, the code is invalid: template PatternMap::iterator& PatternMap::iterator::iterator& operator++( "iterator& operator" should be "iterator::operator" and there needs to be a typename infront of the first "PatternMap::iterator&". -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||ice-on-invalid-code Resolution||FIXED Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18037
[Bug other/16615] throughout gcc docu and code numerous "can not"'s appear
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-17 03:17 --- I changed some of them but I got yelled for changing them. -- What|Removed |Added Last reconfirmed|2004-07-18 17:15:24 |2004-10-17 03:17:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16615
[Bug c++/17743] __alignof__ vs. typedefs
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-17 04:39 --- Subject: Bug 17743 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-10-17 04:39:46 Modified files: gcc/cp : ChangeLog decl2.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/ext: attrib17.C Log message: PR c++/17743 * decl2.c (grokfield): Apply attributes also to TYPE_DECLs. PR c++/17743 * g++.dg/ext/attrib17.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4440&r2=1.4441 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gcc&r1=1.753&r2=1.754 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4463&r2=1.4464 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/attrib17.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17743
[Bug c++/17743] dependent expressions in attributes
--- Additional Comments From giovannibajo at libero dot it 2004-10-17 04:47
---
OK, I fixed part of this for 4.0. The missing part is when the expression in
attributes is dependent, like:
template
struct A {
char foo __attribute__((aligned(__alignof__(T;
};
This is non-trivial to fix. Benjamin, if you want you can keep this bugreport
open to track this. I do not plan to be able to fix this in the 4.0 timeframe,
so I have unassigned the bug (I will attempt something though). If somebody
more expert than me wants to help the v3 guys, feel free.
Otherwise, if you do not care about this, just close this bug.
--
What|Removed |Added
AssignedTo|giovannibajo at libero dot |unassigned at gcc dot gnu
|it |dot org
Status|ASSIGNED|NEW
Summary|__alignof__ vs. typedefs|dependent expressions in
||attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17743
[Bug middle-end/18038] New: addition in a multibit bitfield is inefficient
Consider:
struct B {
unsigned b : 2;
};
void
store (struct B *b, int v)
{
b->b += v;
}
./cc1 -O2 -fomit-frame-pointer -mregparm=3 generates
store:
movb(%eax), %cl
andl$3, %ecx
addl%edx, %ecx
andl$3, %ecx
movl(%eax), %edx
andl$-4, %edx
orl %ecx, %edx
movl%edx, (%eax)
ret
We don't need two "andl". We could do something like
store:
movl(%eax), %ecx
addl%ecx, %edx
andl$3, %edx
andl$-4, %ecx
orl %ecx, %edx
movl%edx, (%eax)
ret
--
Summary: addition in a multibit bitfield is inefficient
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18038
[Bug target/17990] [3.4/4.0 Regression] unaligned xmm movaps on the stack with -O2 -msse
--- Additional Comments From shadow at serverart dot org 2004-10-17 06:24 --- possibly related to http://www.cygwin.com/ml/cygwin/2004-04/msg01103.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17990
[Bug target/17224] [3.4/4.0 Regression]: relocation truncated to fit: GPREL22
-- What|Removed |Added Keywords||wrong-code Target Milestone|--- |3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17224
[Bug libstdc++/8670] Alignment problem in std::basic_string
--- Additional Comments From pcarlini at suse dot de 2004-10-16 20:09 --- Great! This means that, within the 3.4/4.0 ABI, will be able to provide an additional range of improvements to the string class that I didn't expect! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
[Bug libgcj/18036] New: Bad interaction between interpreter and Class.forName()
The following code creates a user defined classloader which is then used to load
a simple class C from byte code. An instance of this class is created and from
this instance Class.forName("C") is called. This should result in the same class
object from the same (user defined) classloader.
It does work when compiled to native code. But it fails when compiled to byte
code and run with gij.
With gij 3.4 it works correctly.
Current CVS gcj (GCC) 4.0.0 20041016 (experimental) fails
Expected output:
true
true
true
--
Summary: Bad interaction between interpreter and Class.forName()
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mark at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18036
