[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy

[doko at ubuntu dot com]

--- Comment #5 from doko at ubuntu dot com  2008-12-16 08:49 ---
The most recent complete build logs can be seen at

http://buildd.debian.org/fetch.cgi?&pkg=gcc-snapshot&ver=20081130-1&arch=armel&stamp=1228429623&file=log
http://launchpadlibrarian.net/20414304/buildlog_ubuntu-jaunty-armel.gcc-snapshot_20081213-0ubuntu1_FULLYBUILT.txt.gz

both builds use -O for the stage1 build.

binutils 2.19 is available either in Debian experimental or in Ubuntu 8.10
(2.18.93) or in the current Ubuntu development version, but test results do not
differ if built with 2.18.x or 2.19.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

[jv244 at cam dot ac dot uk]

--- Comment #18 from jv244 at cam dot ac dot uk  2008-12-16 11:58 ---
(In reply to comment #17)
> BTW, the -O3 compilation is still running (for 17h now).
finished successfully after 23h... 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474

[Bug c++/38541] New: function parameter type T(*)[]

[wolfgang dot roehrl at gi-de dot com]

Dear all,

I would like to post a fault report for the GNU C/C++ compiler 4.3.0.

Used invokation line for the GNU C++ compiler:

gcc -c -x c++ -ansi -Wall -Werror -mcpu=603e -fverbose-asm -mbig
-mmultiple -mstring -mstrict-align -meabi -msdata -fno-common
-fno-exceptions -fno-rtti -O3 -fno-section-anchors
-I
-D
X.CPP -oX.O


// example program

template 
bool f (T_* p);

bool g ()
{ return f(static_cast(0)); }


GNU accepts the code frgment above which is illegal. It is illegal because
a function parameter like "int(*)[]" is illegal (8.3.5/6).

BTW, the Comeau online compiler rejects the code above. 

Kind regards
W. Roehrl


-- 
   Summary: function parameter type T(*)[]
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wolfgang dot roehrl at gi-de dot com
 GCC build triplet: athlon-redhat-linux
  GCC host triplet: i686-pc-mingw32
GCC target triplet: powerpc-rtems4.9


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38541

[Bug c++/37922] [4.4 Regression] code generation error

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2008-12-16 13:09 ---
The problem is that CSE2 extends the live range of CC register, so before DSE1
we have in _ZN11rot_mx_infoC1ERK6rot_mx function:
(insn 15 14 16 2 pr37922.C:469 (set (reg:CC 17 flags)
(compare:CC (reg/v:SI 75 [ proper_order ])
(const_int 0 [0x0]))) 5 {*cmpsi_1_insn} (nil))

(jump_insn 16 15 17 2 pr37922.C:469 (set (pc)
(if_then_else (eq (reg:CC 17 flags)
(const_int 0 [0x0]))
(label_ref:DI 128)
(pc))) 618 {*jcc_1} (expr_list:REG_DEAD (reg:CC 17 flags)
(expr_list:REG_BR_PROB (const_int 3900 [0xf3c])
(nil
...
(insn 28 27 30 3 pr37922.C:472 (set (reg:SI 71 [ proper_r$den_ ])
(mem/s/c:SI (plus:DI (reg/f:DI 20 frame)
(const_int -60 [0xffc4])) [7 proper_r.den_+0 S4
A32])) 47 {*movsi_1} (nil))

(jump_insn 30 28 31 3 pr37922.C:475 (set (pc)
(if_then_else (lt (reg:CC 17 flags)
(const_int 0 [0x0]))
(label_ref 35)
(pc))) 618 {*jcc_1} (expr_list:REG_DEAD (reg:CC 17 flags)
(expr_list:REG_BR_PROB (const_int 2700 [0xa8c])
(nil

and no insn in between jump_insn 16 and 30 touch the flags register (insn 29
which was comparing (reg:SI 75) and (const_int 0) was eliminated during CSE2).

DSE in 4.3/4.4 then attempts to optimize the store of a 64-bit value in insn 27
followed by 32-bit read from the upper 32-bits of that value in insn 28, but
the
sequence it inserts for it (shift down by 32 bytes) unfortunately clobbers CC
register, but replace_read doesn't check for that.
Also, the REG_DEAD note which wasn't removed during CSE2 looks weird.
I guess in replace_read before calling validate_change we should check if insns
don't clobber or modify any hard registers that are live at that point, but am
not sure if DF is initialized for such kind of query at this point.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||zadeck at gcc dot gnu dot
   ||org
 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-12-16 13:09:52
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922

[Bug fortran/38538] ICE with elemental character function

[mikael at gcc dot gnu dot org]

--- Comment #2 from mikael at gcc dot gnu dot org  2008-12-16 15:35 ---
Yes, confirmed. 

The offending line is:
call foo(func("_"//bar()))

In trans-expr.c, se->loop is NULL in the gcc_assert:
2844   else if (sym->result->attr.dimension)
2845 {
2846   gcc_assert (se->loop && info);
2847 
2848   /* Set the type of the array.  */
2849   tmp = gfc_typenode_for_spec (&ts);
2850   info->dimen = se->loop->dimen;
2851 

backtrace:
(gdb) bt
#0  fancy_abort (file=0xbe0240 "../../src/gcc/fortran/trans-expr.c", 
line=2846, function=0xbe0b40 "gfc_conv_function_call")
at ../../src/gcc/diagnostic.c:711
#1  0x004b2e0a in gfc_conv_function_call (se=0x7fff89088320, 
sym=0x2738da0, arg=, 
append_args=)
at ../../src/gcc/fortran/trans-expr.c:2846
#2  0x004b367b in gfc_conv_function_expr (se=0x7fff89088320, 
expr=) at ../../src/gcc/fortran/trans-expr.c:3345
#3  0x004b61d4 in gfc_conv_expr_op (se=0x7fff890884a0, expr=0x27426e0)
at ../../src/gcc/fortran/trans-expr.c:1147
#4  0x004b7943 in gfc_conv_string_length (cl=0x2740dd0, 
expr=, pblock=0x7fff89088870)
at ../../src/gcc/fortran/trans-expr.c:328
#5  0x0049cd14 in gfc_conv_expr_descriptor (se=, 
expr=, ss=0x2742380)
at ../../src/gcc/fortran/trans-array.c:4929
#6  0x004bd987 in gfc_conv_intrinsic_len (se=0x7fff89088d90, 
expr=) at ../../src/gcc/fortran/trans-intrinsic.c:2906
#7  0x004c01d4 in gfc_conv_intrinsic_function (se=0x7fff89088d90, 
expr=0x2741c70) at ../../src/gcc/fortran/trans-intrinsic.c:4682
#8  0x004b3633 in gfc_conv_function_expr (se=0x7fff89088d90, 
expr=0xb1e) at ../../src/gcc/fortran/trans-expr.c:3328
#9  0x004b76ea in gfc_apply_interface_mapping (mapping=0x7fff89088e30, 
se=0x7fff89088d90, expr=0x2741c70)
at ../../src/gcc/fortran/trans-expr.c:2145
#10 0x0049d5bf in gfc_conv_expr_descriptor (se=, 
expr=, ss=0x27416b0)
at ../../src/gcc/fortran/trans-array.c:4721
#11 0x004a06a3 in gfc_conv_array_parameter (se=0x7fff89089030, 
expr=0x2702b90, ss=0x27416b0, g77=, fsym=0x273add0, 
proc_name=0x7fff89087bb0 "") at ../../src/gcc/fortran/trans-array.c:5277
#12 0x004b22d4 in gfc_conv_function_call (se=0x7fff890895f0, 
sym=0x273ab60, arg=0x26b27b0, append_args=)
at ../../src/gcc/fortran/trans-expr.c:2691
#13 0x004cf8df in gfc_trans_call (code=, 
dependency_check=0 '\0') at ../../src/gcc/fortran/trans-stmt.c:356
#14 0x004943c5 in gfc_trans_code (code=0x2738340)
at ../../src/gcc/fortran/trans.c:1117
#15 0x004abe6d in gfc_generate_function_code (ns=0x2737200)
at ../../src/gcc/fortran/trans-decl.c:3843
#16 0x00493a33 in gfc_generate_module_code (ns=)
at ../../src/gcc/fortran/trans.c:1319
#17 0x00461624 in gfc_parse_file ()
at ../../src/gcc/fortran/parse.c:3855
#18 0x00490c9d in gfc_be_parse_file (set_yydebug=)
at ../../src/gcc/fortran/f95-lang.c:236
#19 0x0074545d in toplev_main (argc=, 
argv=) at ../../src/gcc/toplev.c:970
#20 0x7f6a80694526 in __libc_start_main () from /lib/libc.so.6
#21 0x00405d19 in _start ()


-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-12-16 15:35:45
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538

[Bug target/37436] arm-cross-g++. internal compiler error: in extract_insn, at recog.c:1990

[rearnsha at gcc dot gnu dot org]

--- Comment #6 from rearnsha at gcc dot gnu dot org  2008-12-16 12:12 
---
Fixed on trunk


-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37436

[Bug c++/37922] [4.3/4.4 Regression] code generation error

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|4.4.0   |4.3.3
Version|4.4.0   |4.3.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922

[Bug fortran/38538] ICE with elemental character function

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2008-12-16 16:03 ---
If the subroutine

subroutine xmain()
call foo(func("_"//bar()))
end subroutine xmain

is replaced with

subroutine xmain()
character (len=2) :: zz(2)
zz=func("_"//bar())
call foo(zz)
end subroutine xmain

the code compiles and seems to give a sensible executable.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

[jv244 at cam dot ac dot uk]

--- Comment #25 from jv244 at cam dot ac dot uk  2008-12-16 16:17 ---
doing some more profiling, the -O0 problem is to a large extend due to
compute_inline_parameters and estimate_stack_frame_size. Spending 10-30min just
on estimating the stack_frame_size on something that can't be reasonably
inlined anyways seems a waste.


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

[steven at gcc dot gnu dot org]

--- Comment #26 from steven at gcc dot gnu dot org  2008-12-16 16:26 ---
I am going to work on the -O0 problems a bit.

The operand scanner is the problem at -O3. Richi, this is one you may want to
try on the alias improvements branch, if most of the time is spent on virtual
SSA names (I haven't checked, but it's likely with so many aggregate-typed
variables).


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |steven at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-12-15 21:27:40 |2008-12-16 16:26:45
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

[jv244 at cam dot ac dot uk]

--- Comment #27 from jv244 at cam dot ac dot uk  2008-12-16 16:29 ---
the slow routines at -O3 are related to compute_may_aliases, at the point I
interupted the profiling, this routine had called add_virtual_operand 200M
times.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474

[Bug target/38442] Multi-line description used in config/picochip/picochip.opt

[hariharans at gcc dot gnu dot org]

--- Comment #1 from hariharans at gcc dot gnu dot org  2008-12-16 16:35 
---
This has been fixed on 4.4.0 (trunk)


-- 

hariharans at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38442

[Bug c++/38542] New: placement new and name lookup in templates

[wolfgang dot roehrl at gi-de dot com]

Dear all,

I would like to post a fault report for the GNU C/C++ compiler 4.3.0.

Used invokation line for the GNU C++ compiler:

gcc -c -x c++ -ansi -Wall -Werror -mcpu=603e -fverbose-asm -mbig
-mmultiple -mstring -mstrict-align -meabi -msdata -fno-common
-fno-exceptions -fno-rtti -O3 -fno-section-anchors
-I
-D
X.CPP -oX.O


// example program

template 
T_* g (void* p)
{ return new(p) T_(); }

void* operator new (unsigned int, void* p);

int* h (void* p)
{ return g(p); }


GNU accepts the code frgment above which is illegal. It is illegal because
. the name "new" in the body of function g() is a non-dependent name and non-
  dependent names are bound at the point they are used (14.6.3);
. the new-expression in function g() is a placement-new-expression
. only non-placement allocation functions are declared implicitly (3.7.3/2).

BTW, the Comeau online compiler rejects the code above. 

Kind regards
W. Roehrl


-- 
   Summary: placement new and name lookup in templates
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wolfgang dot roehrl at gi-de dot com
 GCC build triplet: athlon-redhat-linux
  GCC host triplet: i686-pc-mingw32
GCC target triplet: powerpc-rtems4.9


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38542

[Bug target/36804] For-loop never exits in gcc for ARM.

[rearnsha at gcc dot gnu dot org]

--- Comment #1 from rearnsha at gcc dot gnu dot org  2008-12-16 16:45 
---
I'm unable to reproduce this with any of svn-trunk, gcc-4.1.3 (debian),
gcc-4.3.3 (SVN) or gcc-4.3.2 (debian).  The loop essentially reads as

  mov  r7, #1
  mov  r6, #0
L5:
  ...
  add  r6, r6, #1
  cmp  r7, r6
  bhi  L5

This will iterate only while r7 is larger than r6 -- that is, exactly once,
when r6 is 0.


-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36804

[Bug target/37436] arm-cross-g++. internal compiler error: in extract_insn, at recog.c:1990

[rearnsha at gcc dot gnu dot org]

--- Comment #5 from rearnsha at gcc dot gnu dot org  2008-12-16 12:04 
---
Subject: Bug 37436

Author: rearnsha
Date: Tue Dec 16 12:03:41 2008
New Revision: 142778

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142778
Log:
PR target/37436
* arm.c (arm_legitimate_index): Only accept addresses that are in
canonical form.
* predicates.md (arm_reg_or_extendqisi_mem_op): New predicate.
* arm.md (extendqihi2): Use arm_reg_or_extendqisi_mem_op predicate
for operand1.
(extendqisi2): Likewise.
(arm_extendqisi, arm_extendqisi_v6): Use arm_extendqisi_mem_op
predicate for operand1.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.md
trunk/gcc/config/arm/predicates.md


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37436

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

[steven at gcc dot gnu dot org]

--- Comment #19 from steven at gcc dot gnu dot org  2008-12-16 12:45 ---
Re. comment #18, I'd say "brilliant" if it wasn't such a poor performance :-)

Did you manage to get a time report out of that run?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474

[Bug middle-end/38533] [4.2/4.3/4.4 regression] tree-ssa-reassoc.c increases register pressure several times

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-12-16 16:57 ---
In particular, the problem is in linearize_expr_tree.  The |s are already
perfectly linearized (in all but the innermost recursive linearize_expr_tree
binlhsisreassoc is 1 and binrhsisreassoc is 0, in the innermost both are 0),
yet:
1645  gsinow = gsi_for_stmt (stmt);
1646  gsilhs = gsi_for_stmt (SSA_NAME_DEF_STMT (binlhs));
1647  gsi_move_before (&gsilhs, &gsinow);
moves all of them to one spot.  Couldn't that moving be deferred till we
actually know it is worthwhile to reassociate something, not blindly just in
case something will be needed?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38533

[Bug middle-end/38533] [4.2/4.3/4.4 regression] tree-ssa-reassoc.c increases register pressure several times

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-12-16 13:49 ---
The culprit is tree-ssa-reassoc.c, with -fno-tree-ssa-reassoc the generated
code is comparable to 3.4.
For some reason it decides:
Transforming err_10 = __err_3 | __err_8;
 into err_10 = __err_8 | __err_3;
(no idea what advantages that has, but anyway) but instead of reinserting
the transformed stmt into the location where err_10 used to be set before,
it moves all the 30 err_A = err_B | __err_C stmts (where each stmt depends on
the preceeding one) after the last asm volatile.  This means that register
pressure jumps through the roof.  In this case (if the transformation actually
makes sense) certainly the first transformed stmt can be inserted into the old
definition spot and all the following stmts can be left untouched.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dberlin at gcc dot gnu dot
   ||org
   Keywords||missed-optimization
Summary|[4.2/4.3/4.4 regression]|[4.2/4.3/4.4 regression]
   |Inefficient stack usage |tree-ssa-reassoc.c increases
   ||register pressure several
   ||times


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38533

[Bug middle-end/38533] [4.2/4.3/4.4 regression] tree-ssa-reassoc.c increases register pressure several times

[dberlin at dberlin dot org]

--- Comment #4 from dberlin at gcc dot gnu dot org  2008-12-16 17:00 ---
Subject: Re:  [4.2/4.3/4.4 regression] tree-ssa-reassoc.c increases register
pressure several times

Yes, that looks like a bug.
There are also numerous ways in which the placement can be improved.
A few people had talked about rewriting it to be a balanced tree
placement, etc, so i've never bothered to do even the small cleanups.
If you want to change placement, go for it.
:)

On Tue, Dec 16, 2008 at 11:57 AM, jakub at gcc dot gnu dot org
 wrote:
>
>
> --- Comment #3 from jakub at gcc dot gnu dot org  2008-12-16 16:57 ---
> In particular, the problem is in linearize_expr_tree.  The |s are already
> perfectly linearized (in all but the innermost recursive linearize_expr_tree
> binlhsisreassoc is 1 and binrhsisreassoc is 0, in the innermost both are 0),
> yet:
> 1645  gsinow = gsi_for_stmt (stmt);
> 1646  gsilhs = gsi_for_stmt (SSA_NAME_DEF_STMT (binlhs));
> 1647  gsi_move_before (&gsilhs, &gsinow);
> moves all of them to one spot.  Couldn't that moving be deferred till we
> actually know it is worthwhile to reassociate something, not blindly just in
> case something will be needed?
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38533
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38533

[Bug target/36209] arm-*-linux-gnueabi-gcc (4.3.0) segment fault during build of procps-3.2.7

[rearnsha at gcc dot gnu dot org]

--- Comment #2 from rearnsha at gcc dot gnu dot org  2008-12-16 17:12 
---
Confirmed.  This appears to be a bug in the register-renaming pass, where the
insn

(insn:HI 84 79 82 8 proc/sysinfo.c:890 (parallel [
(set (reg:CC_NOOV 24 cc)
(compare:CC_NOOV (minus:SI (ashiftrt:SI (reg:SI 2 r2 [170])
(const_int 2 [0x2]))
(reg:SI 3 r3 [173]))
(const_int 0 [0x0])))
(set (reg/v:SI 0 r0 [orig:133 rc.187 ] [133])
(minus:SI (ashiftrt:SI (reg:SI 2 r2 [170])
(const_int 2 [0x2]))
(reg:SI 3 r3 [173])))
]) 265 {*arith_shiftsi_compare0} (nil))

is transformed to

(insn:HI 84 79 82 8 proc/sysinfo.c:890 (parallel [
(set (reg:CC_NOOV 24 cc)
(compare:CC_NOOV (minus:SI (ashiftrt:SI (reg:SI 2 r2 [170])
(const_int 2 [0x2]))
(reg:SI 14 lr [173]))
(const_int 0 [0x0])))
(set (reg/v:SI 0 r0 [orig:133 rc.187 ] [133])
(minus:SI (cc0)
(cc0)))
]) 265 {*arith_shiftsi_compare0} (expr_list:REG_DEAD (reg:SI 3 r3
[173])
(expr_list:REG_DEAD (reg:SI 2 r2 [170])
(nil

The use of cc0 in the second version indicates a failure to correctly transform
the insn.

The bug goes away if -frename-registers is removed from the command line.


-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rearnsha at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.3.3
  Known to work||4.4.0
   Last reconfirmed|-00-00 00:00:00 |2008-12-16 17:12:19
   date||
   Target Milestone|--- |4.3.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36209

[Bug c++/37922] [4.3/4.4 Regression] code generation error

[hjl dot tools at gmail dot com]

--- Comment #14 from hjl dot tools at gmail dot com  2008-12-16 17:18 
---
Here is the original patch which caused this regression:

http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01582.html

Here is the one checked in:

http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00744.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC|rsandifo at gcc dot gnu dot |rsandifo at nildram dot co
   |org |dot uk


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922

[Bug c++/37922] [4.4 Regression] code generation error

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2008-12-16 12:08 ---
Indeed, -O2 -fpic returns 2, -O2 -fpic -fno-dse returns 0.  The difference
between the two are just 4 successful replace_read changes, like:
movq%rdx, 224(%rsp) # D.4704, proper_r
-   shrq$32, %rdx   #, proper_r$den_
+   movl228(%rsp), %edx # proper_r.den_, proper_r$den_
(- is without -fno-dse, + is with -fno-dse).  These look good, unless the
original %rdx is needed somewhere else.  I'll try to debug this.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922

[Bug c++/37922] [4.4 Regression] code generation error

[jakub at gcc dot gnu dot org]

--- Comment #13 from jakub at gcc dot gnu dot org  2008-12-16 15:05 ---
Not doing this optimization if added_clobbers_hard_reg_p would basically kill
it on i386/x86_64 except for constant values, all the shifts clobber hard
registers.  But typically flags register is only live for very short range
between compare and (usually the next insn) following conditional jump.  Given
how many insns clobber the flags it is very rare to have the setter and user
many insns appart.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

[jv244 at cam dot ac dot uk]

--- Comment #20 from jv244 at cam dot ac dot uk  2008-12-16 12:47 ---
(In reply to comment #19)
> Re. comment #18, I'd say "brilliant" if it wasn't such a poor performance :-)

I agree... quite an achievement not to crash in such a case.

> Did you manage to get a time report out of that run?

no... obviously I can rerun this (numbers tomorrow, of course)?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474

[Bug c++/38540] New: Type of 'const int f ()'

[wolfgang dot roehrl at gi-de dot com]

Dear all,

I would like to post a fault report for the GNU C/C++ compiler 4.3.0.

Used invokation line for the GNU C++ compiler:

gcc -c -x c++ -ansi -Wall -Werror -mcpu=603e -fverbose-asm -mbig
-mmultiple -mstring -mstrict-align -meabi -msdata -fno-common
-fno-exceptions -fno-rtti -O3 -fno-section-anchors
-I
-D
X.CPP -oX.O


// example program

const int f ();

template 
void g (T_&);

void h (void)
{ g(f()); }


GNU accepts the code fragment above which is illegal. It is illegal because
. Function f() yields a rvalue (3.10/5);
. the type of f() is "int" and not "const int" since only a class-type
  rvalue can be const-qualified (3.10/9);
. so function g() should be instantiated as g(int&) in the expression
  "g(f())";
. the parameter "int&" of function g(int&) cannot bind a non-const
  rvalue (8.5.3/5).

BTW, the Comeau online compiler rejects the code above. 

Kind regards
W. Roehrl


-- 
   Summary: Type of 'const int f ()'
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wolfgang dot roehrl at gi-de dot com
 GCC build triplet: athlon-redhat-linux
  GCC host triplet: i686-pc-mingw32
GCC target triplet: powerpc-rtems4.9


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38540

[Bug middle-end/38533] [4.2/4.3/4.4 regression] tree-ssa-reassoc.c increases register pressure several times

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2008-12-16 14:58 ---
Sounds similar to PR 32183.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38533

[Bug c++/37922] [4.4 Regression] code generation error

[steven at gcc dot gnu dot org]

--- Comment #12 from steven at gcc dot gnu dot org  2008-12-16 13:45 ---
Looks like something along the lines of gcse.c:can_assign_to_reg_p() is called
for here in replace_read.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922

[Bug target/35624] ARM embeded assembly result error

[rearnsha at gcc dot gnu dot org]

--- Comment #4 from rearnsha at gcc dot gnu dot org  2008-12-16 17:39 
---
Not a bug.  You need to write your macro like this:

#define burst_copy(dst,src,len) {\
  unsigned t1, t2, t3; \
  __asm__ __volatile__ ( \
 "1: \n\t" \
   "ldmia %1!,{r3-r6} \n\t" \
   "stmia %0!,{r3-r6} \n\t" \
   "subs %2, %2, #1 \n\t" \
   "bne 1b \n\t" \
   :"=r"(t1),"=r"(t2),"=r"(t3) \
   :"0"(dst),"1"(src),"2"(len) \
   :"r3","r4","r5","r6", "memory"); \
}

Note that the results are never used, but this informs the compiler that the
input values have been destroyed by the operation.  Also note the clobber of
"memory" to indicate that values in memory have been updated by the operation.

It might be better to use an inline function for this rather than a macro, then
you can use the input operands as your output operands and don't need to
declare the temporaries.   It would also give better error checking in some
circumstances.


-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35624

[Bug c++/37922] [4.4 Regression] code generation error

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2008-12-16 12:48 ---
Created an attachment (id=16912)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16912&action=view)
pr37922.C

Testcase with a bunch of unneeded namespaces removed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

[jv244 at cam dot ac dot uk]

--- Comment #24 from jv244 at cam dot ac dot uk  2008-12-16 14:20 ---
(In reply to comment #23)
reduced testcase timings at -O0 and -O3. Tree operand scan anybody?

> time gfortran -O0 -ffree-line-length-512 -c -ftime-report testcase_reduced.f90

Execution times (seconds)
 garbage collection:   0.51 ( 1%) usr   0.00 ( 0%) sys   0.49 ( 1%) wall   
   0 kB ( 0%) ggc
 callgraph construction:   0.05 ( 0%) usr   0.00 ( 0%) sys   0.06 ( 0%) wall   
4956 kB ( 2%) ggc
 callgraph optimization:   8.13 (18%) usr   0.20 (16%) sys   8.36 (18%) wall   
1280 kB ( 1%) ggc
 cfg cleanup   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 CFG verifier  :   0.48 ( 1%) usr   0.02 ( 2%) sys   0.46 ( 1%) wall   
   0 kB ( 0%) ggc
 trivially dead code   :   0.17 ( 0%) usr   0.00 ( 0%) sys   0.18 ( 0%) wall   
   0 kB ( 0%) ggc
 df live regs  :   0.11 ( 0%) usr   0.00 ( 0%) sys   0.11 ( 0%) wall   
   0 kB ( 0%) ggc
 df reg dead/unused notes:   0.24 ( 1%) usr   0.00 ( 0%) sys   0.23 ( 0%) wall 
  9445 kB ( 4%) ggc
 register information  :   0.11 ( 0%) usr   0.01 ( 1%) sys   0.12 ( 0%) wall   
   0 kB ( 0%) ggc
 alias analysis:   0.10 ( 0%) usr   0.01 ( 1%) sys   0.10 ( 0%) wall   
4239 kB ( 2%) ggc
 rebuild jump labels   :   0.12 ( 0%) usr   0.00 ( 0%) sys   0.11 ( 0%) wall   
   0 kB ( 0%) ggc
 parser:   1.07 ( 2%) usr   0.05 ( 4%) sys   1.12 ( 2%) wall  
22673 kB ( 9%) ggc
 inline heuristics :  16.30 (36%) usr   0.41 (33%) sys  16.75 (36%) wall   
   0 kB ( 0%) ggc
 tree gimplify :   0.06 ( 0%) usr   0.01 ( 1%) sys   0.08 ( 0%) wall   
6435 kB ( 3%) ggc
 tree CFG construction :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall   
 180 kB ( 0%) ggc
 tree find ref. vars   :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
3231 kB ( 1%) ggc
 tree SSA rewrite  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall   
  63 kB ( 0%) ggc
 tree SSA other:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 tree operand scan :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
 236 kB ( 0%) ggc
 tree SSA to normal:   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 tree SSA verifier :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall   
   0 kB ( 0%) ggc
 tree STMT verifier:   0.20 ( 0%) usr   0.01 ( 1%) sys   0.22 ( 0%) wall   
   0 kB ( 0%) ggc
 callgraph verifier:   0.05 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall   
   0 kB ( 0%) ggc
 dominance computation :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall   
   0 kB ( 0%) ggc
 expand:  10.86 (24%) usr   0.38 (30%) sys  11.26 (24%) wall 
132856 kB (52%) ggc
 integrated RA :   4.08 ( 9%) usr   0.05 ( 4%) sys   4.13 ( 9%) wall   
4604 kB ( 2%) ggc
 reload:   1.88 ( 4%) usr   0.07 ( 6%) sys   1.97 ( 4%) wall  
59269 kB (23%) ggc
 thread pro- & epilogue:   0.17 ( 0%) usr   0.00 ( 0%) sys   0.18 ( 0%) wall   
 175 kB ( 0%) ggc
 final :   0.63 ( 1%) usr   0.03 ( 2%) sys   0.66 ( 1%) wall   
3790 kB ( 1%) ggc
 TOTAL :  45.42 1.2546.73
253684 kB
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --enable-checking=release to disable checks.

real0m47.298s
user0m45.923s
sys 0m1.316s

> time gfortran -march=native -O3 -ffree-line-length-512 -c -ftime-report 
> testcase_reduced.f90

Execution times (seconds)
 garbage collection:   1.48 ( 1%) usr   0.01 ( 0%) sys   1.50 ( 1%) wall   
   0 kB ( 0%) ggc
 callgraph construction:   0.03 ( 0%) usr   0.01 ( 0%) sys   0.05 ( 0%) wall   
4955 kB ( 1%) ggc
 callgraph optimization:   6.27 ( 3%) usr   0.15 ( 7%) sys   6.46 ( 4%) wall   
2366 kB ( 0%) ggc
 ipa cp:   0.05 ( 0%) usr   0.01 ( 0%) sys   0.06 ( 0%) wall   
  34 kB ( 0%) ggc
 cfg cleanup   :   0.01 ( 0%) usr   0.01 ( 0%) sys   0.02 ( 0%) wall   
   0 kB ( 0%) ggc
 CFG verifier  :   1.41 ( 1%) usr   0.00 ( 0%) sys   1.33 ( 1%) wall   
   0 kB ( 0%) ggc
 trivially dead code   :   0.62 ( 0%) usr   0.00 ( 0%) sys   0.66 ( 0%) wall   
   0 kB ( 0%) ggc
 df reaching defs  :   0.69 ( 0%) usr   0.01 ( 0%) sys   0.67 ( 0%) wall   
   0 kB ( 0%) ggc
 df live regs  :   1.86 ( 1%) usr   0.00 ( 0%) sys   1.86 ( 1%) wall   
   0 kB ( 0%) ggc
 df live&initialized regs:   0.93 ( 1%) usr   0.00 ( 0%) sys   0.94 ( 1%) wall 
 0 kB ( 0%) ggc
 df use-def / def-use chains:   1.33 ( 1%) usr   0.04 ( 2%) sys   1.38 ( 1%)
wall   0 kB ( 0%) ggc
 df reg dead/unused notes:   0.92 ( 1%) usr   0.00 ( 0%) sys   0.96 ( 1%) wall 
 13469 kB ( 3%) ggc
 register information  :   0.44 ( 0%) usr   0.00 ( 0%) sys   0.43 ( 0%) wall   
   0 kB ( 0%) ggc
 alias analysis:   1.05 ( 1%) usr   0.00 ( 0%) sys   1.05 ( 1%) wall  
24068 kB ( 5%) ggc
 register scan :   0.20 ( 0%) usr   0.00 ( 0%) sys   0.17 ( 0%) wall   
  18 kB ( 0%) ggc
 rebuil

[Bug c++/38525] sse2(int16) code fails with -O3

[leonid at volnitsky dot com]

--- Comment #9 from leonid at volnitsky dot com  2008-12-16 13:21 ---
(In reply to comment #8)
>> int16_t* ip  = (int16_t*)&m1;  
> That is violating C/C++ aliasing rules

The code that you quote is not part of the reported bug.  It was quick and
dirty hack.  But that was it.  Adding -fno-strict-aliasing fixed unit tests.  

But then there is a question.  Full code attached to the bug does not gave any
warning about aliasing violation with  -Wall and -O3.  Is no-warning a bug? 





-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38525

[Bug other/38531] namespace, ,

[mayor1 at uralweb dot ru]

--- Comment #4 from mayor1 at uralweb dot ru  2008-12-16 11:34 ---
Subject: Re:  namespace, , 

On 15 Dec 2008 17:40:49 -
  "jakub at gcc dot gnu dot org" 
 wrote:
> 
> 
> --- Comment #1 from jakub at gcc dot gnu dot org 
> 2008-12-15 17:40 ---
> Why is that considered a bug?
> If you want strlen etc. in std:: namespace, you need to 
>include .

if junior coder include standart c++ header he must not 
know about all functions declaration in this header and 
all subheader - therefore them injected in std namespace

if he write using namespace std; - its his own problem

but if he write:
#include 
using std:: ... ;
int f1() { ... }
f1();

and f1() calls instead of user defined f1(), f1() from 
header cC that was included by cB that was included by cA
- its too dificult to find and debug

check it out:
#include 
using std::cout;
using std::endl;
int strcat(const char* a,const char* b){
  cout<<"you never see it in g++ 4.1.2"
  cout< -- 
> 
> jakub at gcc dot gnu dot org changed:
> 
>   What|Removed |Added
> 
> Status|UNCONFIRMED |WAITING
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38531
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.


http://uralweb.ru - äîáàâü â èçáðàííîå!


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38531

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

[jv244 at cam dot ac dot uk]

--- Comment #21 from jv244 at cam dot ac dot uk  2008-12-16 12:48 ---
(In reply to comment #16)
> Oh, and FWIW, for yukawa_gn_full, stack_vars_num == 67551 for me.

btw, that routine only has 3800 user variables, the rests are FE generated
temporaries (which should have a limited lifetime).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474

[Bug c++/37922] [4.3/4.4 Regression] code generation error

[hjl dot tools at gmail dot com]

--- Comment #15 from hjl dot tools at gmail dot com  2008-12-16 18:41 
---
Is that safe to call find_shift_sequence when CC register is live?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922

[Bug middle-end/32581] make profiledbootstrap - stageprofile - gcc/ada/a-except.adb:1301: error: control flow in the middle of basic block 20

[tim at bishnet dot net]

--- Comment #13 from tim at bishnet dot net  2008-12-16 14:29 ---
Could this change be merged down to the 4.3 branch? Currently 4.3.2 release is
still broken.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32581

[Bug c++/37922] [4.3/4.4 Regression] code generation error

[zadeck at naturalbridge dot com]

--- Comment #16 from zadeck at naturalbridge dot com  2008-12-16 18:43 
---
and how would you ask that question in a machine independent way?

I am going to find the shift sequence and if it has a set or clobber of any
currently live hard reg, i will reject the sequence.

I am working on a fix now.
kenny


-- 

zadeck at naturalbridge dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |zadeck at naturalbridge dot
   |dot org |com
 Status|NEW |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

[steven at gcc dot gnu dot org]

--- Comment #22 from steven at gcc dot gnu dot org  2008-12-16 13:41 ---
We may be better off with a slightly reduced test case for the -O3 report. 
It's not difficult to cut out ~8000 lines (like I did yesterday) and still have
a huge test case (and the horendous compile times to go with that).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

[jv244 at cam dot ac dot uk]

--- Comment #23 from jv244 at cam dot ac dot uk  2008-12-16 14:17 ---
Created an attachment (id=16913)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16913&action=view)
reduced testcase

just so we talk about the same file, I've reduced the testcase to more
managable sizes. This one compiles in about 1min at -O0. I'll attach
time-report output in a  sec.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[thutt at vmware dot com]

--- Comment #2 from thutt at vmware dot com  2008-12-16 14:03 ---
(In reply to comment #1)
> The reason why they are saved is so that you can have a good way of debugging
> noreturn functions.
> 

Can you please elaborate? How is saving these registers, which will never be
restored, going to make it easier to debug noreturn functions?

Can you please explain how the values in the saved registers are relevant
to the 'noreturn' function?

As far as I understand it, the callee saved registers are not used to pass
any information to the callee, so I don't understand how saving them makes
it easier to debug code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534

[Bug c++/38517] Uninitialized reference variable is accepted after an extern declaration

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-12-16 19:18 ---
Simple testcase:
extern int& i;
int& i; // ERROR: this is not ok


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Keywords||accepts-invalid
   Last reconfirmed|-00-00 00:00:00 |2008-12-16 19:18:00
   date||
Summary|At definition of the empty  |Uninitialized reference
   |reference the error is not  |variable is accepted after
   |output. |an extern declaration


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38517

[Bug c++/38517] Uninitialized reference variable is accepted after an extern declaration

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2008-12-16 19:18 ---
Not a regression.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||3.3.3 4.0.0 4.3.0 4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38517

[Bug c++/7876] g++ doesn't diagnose One Reference Rule violation

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2008-12-16 19:21 ---
This has been fixed since 4.3.0:
t.cc:7: error: declaration of 'typedef struct X A::X'
t.cc:2: error: changes meaning of 'X' from 'struct X'


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7876

[Bug middle-end/38474] [4.3/4.4 Regression] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

[pinskia at gcc dot gnu dot org]

--- Comment #28 from pinskia at gcc dot gnu dot org  2008-12-16 19:32 
---
The stack heuristic is new for 4.3.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal
Summary|slow compilation at -O0 |[4.3/4.4 Regression] slow
   |(callgraph optimization,|compilation at -O0
   |inline heuristics, expand ) |(callgraph optimization,
   ||inline heuristics, expand )
   Target Milestone|--- |4.3.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474

[Bug middle-end/38474] [4.3/4.4 Regression] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

[jv244 at cam dot ac dot uk]

-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

   Target Milestone|4.3.4   |4.3.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474

[Bug c/38475] Bugzilla request: hide my e-mail from non-logged-in users

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-12-16 20:37 ---
Why do you want this, this is an free source project after all?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38475

[Bug debug/38479] Incorrect dwarf generated for function with parameters greater 4 words in length

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-12-16 20:38 ---
I want to say this is a duplicate of bug 38367.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |debug
   Keywords||wrong-debug


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38479

[Bug tree-optimization/38480] bogus warning with -O3 -Wall: "array subscript is above array bounds"

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-12-16 20:40 ---
we have:
unsigned short foobar;
int i = (int)foobar;
if (i > 99)
  if (foobar <= 99)
access array[i];

so i can never be negative and foobar will never be greater than 99.
This is both a missed optimization dealing with VRP and a diagnostic issue.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|c   |tree-optimization
 Ever Confirmed|0   |1
   Keywords||diagnostic, missed-
   ||optimization
   Last reconfirmed|-00-00 00:00:00 |2008-12-16 20:40:17
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38480

[Bug c++/38543] New: Cannot specialize variadic template function

[jichaoz at ca dot ibm dot com]

GCC 4.3.2 failed to compile code with vairadic template function
specialization.

Here is the code causing the problem:

template< typename ... T > void foo( T ... args );
template<> void foo( int, double ){}
int main()
{
  foo( 0, 0.0 );
  return 55;
}

I got the following error msg:
test.cpp:3: error: template-id 'foo<>' for 'void foo(int, double)' does not
match any template declaration

However, the specialization using only one parameter can pass:

template< typename ... T > void foo( T ... args );
template<> void foo( int ){}
int main()
{
  foo( 0 );
  return 55;
}

Command used to compile:

g++ -std=c++0xtest.cpp   -o test

Output from -v:

Using built-in specs.
Target: powerpc64-suse-linux
Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local
--infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64
--libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch --program-suffix=-4.3
--enable-version-specific-runtime-libs --enable-linux-futex
--without-system-libunwind --with-cpu=power4 --enable-secureplt
--with-long-double-128 --build=powerpc64-suse-linux
Thread model: posix
gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux)


-- 
   Summary: Cannot specialize variadic template function
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jichaoz at ca dot ibm dot com
  GCC host triplet: powerpc64-suse-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38543

[Bug web/38475] Bugzilla request: hide my e-mail from non-logged-in users

[m dot j dot thayer at googlemail dot com]

--- Comment #2 from m dot j dot thayer at googlemail dot com  2008-12-16 
21:48 ---
I just generally don't like having my e-mail address visible on public web
pages.  Among other things, it provides food for spam-bots.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38475

[Bug rtl-optimization/38544] New: missed opportunity to use adc

[rrh at google dot com]

The optimizer at -O3 for x86_64 finds opportunities to generate the "adc" (add
with carry) instruction to avoid a conditional branch.  However, the dst of the
adc can only be in a register.  The optimizer misses a chance to use "adc" with
the destination in memory, and will instead use a conditional branch in a
straightforward manner.  The following program shows that foo1 uses adc, but
foo0 does not.

Although I haven't tested this, I'm sure that the other 3 possibilities in this
family (involving sbb and/or different literal values to add/subtract) will
also not find the opportunity to do a memory update with adc.

extern void consumep(int *);
extern void consume(int);
void foo0(unsigned a, unsigned b, int *victim)
{
  if (a > b) { (*victim)++; }
  consumep(victim);
}
void foo1(unsigned a, unsigned b, int victim)
{
  if (a > b) { victim++; }
  consume(victim);
}


-- 
   Summary: missed opportunity to use adc
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rrh at google dot com
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38544

[Bug rtl-optimization/38544] missed opportunity to use adc

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38544

[Bug web/38475] Bugzilla request: hide my e-mail from non-logged-in users

[steven at gcc dot gnu dot org]

--- Comment #3 from steven at gcc dot gnu dot org  2008-12-16 23:03 ---
This is not fixable. When a bug is filed, messages are sent out and picked up
by archive mirrors.  This is desirable for GCC the project but probably less so
for individual GCC users.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38475

[Bug middle-end/38533] [4.2/4.3/4.4 regression] tree-ssa-reassoc.c increases register pressure several times

[jakub at gcc dot gnu dot org]

-- 

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 |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-12-16 23:25:08
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38533

[Bug c++/38545] New: [regression 4.4.0] Conflict between a type and an argument sharing the same name.

[giumfr at gmail dot com]

Dear all,

I've notice that the following code does not compile with g++ 4.4.0 (trunk). 
It seems to be a regression from g++ 4.3.2, which compiles this code
successfully.

$ cat error.c
class A;

class B
{
  void foo(int A,
   const A*);
};
$ g++ -Wextra -Wall -c error.cc
error.cc:6: error: ISO C++ forbids declaration of ‘A’ with no type
error.cc:6: error: conflicting declaration ‘const int A’
error.cc:5: error: ‘A’ has a previous declaration as ‘int A’
error.cc:6: error: expected ‘,’ or ‘...’ before ‘*’ token


-- 
   Summary: [regression 4.4.0] Conflict between a type and an
argument sharing the same name.
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: giumfr at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38545

[Bug bootstrap/38546] New: configure: too many arguments

[ltg at zes dot uni-bremen dot de]

I configured with:

CONFIG_SHELL=/usr/bin/bash CFLAGS="-O9 -maltivec -mabi=altivec" CXXFLAGS="-g
-O9 -maltivec -mabi=altivec" CFLAGS_FOR_TARGET="-O9 -maltivec -mabi=altivec"
LIBCFLAGS="-g -O9 -maltivec -mabi=altivec" LIBCXXFLAGS="-g -O9 -maltivec
-mabi=altivec" LIBGCC2_CFLAGS="-g -O9 -maltivec -mabi=altivec"
/home/devel/build/gcc-4.2.4/configure --enable-threads=aix
--enable-version-specific-runtime-libs --disable-nls --enable-libgcj-debug
--enable-libgcj-multifile --with-x --enable-gtk-cairo
--enable-gather-detailed-mem-stats --enable-languages=all

and built with:

CONFIG_SHELL=/usr/bin/bash BOOT_CFLAGS="-O9 -maltivec -mabi=altivec"
CFLAGS="-O9 -maltivec -mabi=altivec" CXXFLAGS="-O9 -maltivec -mabi=altivec"
LIBCFLAGS="-g -O9 -maltivec -mabi=altivec" LIBCXXFLAGS="-g -O9
-fno-implicit-templates -maltivec -mabi=altivec" LIBGCC2_CFLAGS="-g -O9
-maltivec -mabi=altivec" nohup /usr/local/bin/make -j 4 bootstrap&

(I used bash 3.2.48. The AIX version is 5.2.0.0-10. GCC compiler used for
 the build is 3.4.6)

I got the following error output:

ar cru libcpp.a charset.o directives.o errors.o expr.o files.o identifiers.o
ini
t.o lex.o line-map.o macro.o mkdeps.o pch.o symtab.o traditional.o
ranlib libcpp.a
gcc -g -fkeep-inline-functions -Wl,-bbigtoc -o makedepend \
  makedepend.o libcpp.a ../libiberty/libiberty.a \

checking whether ldgetname is declared... make[3]: Leaving directory
`/home/deve
l/build/objdir.424/libcpp'
yes
checking whether times is declared... yes
checking whether sigaltstack is declared... yes
checking for struct tms... yes
checking for clock_t... yes
checking for .preinit_array/.init_array/.fini_array support... no
checking if mkdir takes one argument... no
Using `/home/devel/build/gcc-4.2.4/gcc/config/rs6000/rs6000.c' for
machine-speci
fic logic.
Using `/home/devel/build/gcc-4.2.4/gcc/config/rs6000/rs6000.md' as machine
descr
iption file.
Using the following target machine macro files:
/home/devel/build/gcc-4.2.4/gcc/config/rs6000/rs6000.h
/home/devel/build/gcc-4.2.4/gcc/config/rs6000/aix.h
/home/devel/build/gcc-4.2.4/gcc/config/rs6000/aix52.h
/home/devel/build/gcc-4.2.4/gcc/config/rs6000/xcoff.h
Using host-default.o for host machine hooks.
checking whether NLS is requested... no
checking for as... /usr/bin/as
checking what assembler to use... /usr/bin/as
checking for ld... /usr/bin/ld
checking what linker to use... /usr/bin/ld
/home/devel/build/gcc-4.2.4/gcc/configure: line 13535: test: too many arguments
checking for nm... /usr/bin/nm
checking what nm to use... /usr/bin/nm
checking for objdump... no
checking what objdump to use... not found
checking assembler for .balign and .p2align... no
checking assembler for .p2align with maximum skip... no
checking assembler for working .subsection -1... no
checking assembler for .weak... yes
checking assembler for .weakref... no
checking assembler for .nsubspa comdat... no
checking assembler for .hidden... no
checking linker for .hidden support... no
checking assembler for .sleb128 and .uleb128... no
checking assembler for eh_frame optimization... no
checking assembler for section merging support... no
checking assembler for section merging support... (cached) no
checking assembler for COMDAT group support... no
checking assembler for COMDAT group support... no
checking assembler for thread-local storage support... no
checking linker -Bstatic/-Bdynamic option... no
checking assembler for mfcr field support... no
checking assembler for popcntb support... yes
checking assembler for fp round support... yes
checking assembler for rel16 relocs... no
checking assembler for dwarf2 debug_line support... no
checking assembler for buggy dwarf2 .file directive... no
checking assembler for --gdwarf2 option... no
checking assembler for --gstabs option... no
checking linker read-only and read-write section mixing... unknown
checking linker PT_GNU_EH_FRAME support... no
checking linker position independent executable support... no
checking linker --as-needed support... no
checking linker --sysroot support... no
Using ggc-page for garbage collection.
checking whether to enable maintainer-specific portions of Makefiles... no
Links are now set up to build a native compiler for powerpc-ibm-aix5.2.0.0.
updating cache ./config.cache
configure: creating ./config.status
config.status: creating Makefile
config.status: creating gccbug
config.status: creating mklibgcc
config.status: creating libada-mk
config.status: creating ada/Makefile
config.status: creating auto-host.h
config.status: executing default commands
make[3]: Entering directory `/home/devel/build/objdir.424/gcc'


-- 
   Summary: configure: too many arguments
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ltg at zes dot uni-bremen dot de
 GCC build triplet: powerpc-ibm-aix5.2.0.0
  GCC ho

[Bug middle-end/38474] [4.3/4.4 Regression] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

[jv244 at cam dot ac dot uk]

--- Comment #29 from jv244 at cam dot ac dot uk  2008-12-17 06:50 ---
doing the original testcase again at -O3 has been a useful exercise i think.
13.5h is spent in rename_registers, 2h in tree operand scan, ~1h in inline
heuristics, and 20min in expand. (Note that this is a 4.3 based compiler, maybe
I should redo this with a 4.4 or has nothing changed there despite ira?).

gfortran-4.3 -ffree-line-length-512 -g -fopenmp -ffree-form -D__T_C_G0
-ftime-report -c -O3 -march=native -funroll-loops mpfr_yukawa.f

Execution times (seconds)
 garbage collection:   3.96 ( 0%) usr   0.00 ( 0%) sys   3.95 ( 0%) wall   
   0 kB ( 0%) ggc
 callgraph construction:   0.42 ( 0%) usr   0.01 ( 0%) sys   0.44 ( 0%) wall  
10751 kB ( 1%) ggc
 callgraph optimization:   0.78 ( 0%) usr   0.02 ( 0%) sys   0.82 ( 0%) wall  
14320 kB ( 1%) ggc
 ipa reference :   0.17 ( 0%) usr   0.00 ( 0%) sys   0.17 ( 0%) wall   
   0 kB ( 0%) ggc
 ipa pure const:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 cfg cleanup   :   0.08 ( 0%) usr   0.00 ( 0%) sys   0.08 ( 0%) wall   
   0 kB ( 0%) ggc
 trivially dead code   :   5.36 ( 0%) usr   0.00 ( 0%) sys   5.38 ( 0%) wall   
   0 kB ( 0%) ggc
 df reaching defs  :   6.56 ( 0%) usr   0.07 ( 1%) sys   6.60 ( 0%) wall   
   0 kB ( 0%) ggc
 df live regs  :  16.93 ( 0%) usr   0.00 ( 0%) sys  16.96 ( 0%) wall   
   0 kB ( 0%) ggc
 df live&initialized regs:   7.39 ( 0%) usr   0.00 ( 0%) sys   7.38 ( 0%) wall 
 0 kB ( 0%) ggc
 df use-def / def-use chains:  14.49 ( 0%) usr   0.02 ( 0%) sys  14.52 ( 0%)
wall   0 kB ( 0%) ggc
 df reg dead/unused notes:  10.94 ( 0%) usr   0.00 ( 0%) sys  10.96 ( 0%) wall 
 37217 kB ( 3%) ggc
 register information  :   4.97 ( 0%) usr   0.00 ( 0%) sys   4.97 ( 0%) wall   
   0 kB ( 0%) ggc
 alias analysis:   8.84 ( 0%) usr   0.01 ( 0%) sys   8.86 ( 0%) wall  
49164 kB ( 3%) ggc
 register scan :   1.78 ( 0%) usr   0.00 ( 0%) sys   1.80 ( 0%) wall   
   0 kB ( 0%) ggc
 rebuild jump labels   :   3.93 ( 0%) usr   0.00 ( 0%) sys   3.93 ( 0%) wall   
   0 kB ( 0%) ggc
 parser:   3.24 ( 0%) usr   0.10 ( 1%) sys   3.35 ( 0%) wall  
60522 kB ( 4%) ggc
 inline heuristics :2516.42 ( 4%) usr   4.20 (35%) sys2542.00 ( 4%) wall   
   0 kB ( 0%) ggc
 tree gimplify :   0.55 ( 0%) usr   0.00 ( 0%) sys   0.54 ( 0%) wall   
3453 kB ( 0%) ggc
 tree eh   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 tree CFG construction :   0.02 ( 0%) usr   0.01 ( 0%) sys   0.03 ( 0%) wall   
7185 kB ( 1%) ggc
 tree CFG cleanup  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   1 kB ( 0%) ggc
 tree VRP  :   0.25 ( 0%) usr   0.00 ( 0%) sys   0.23 ( 0%) wall   
  36 kB ( 0%) ggc
 tree copy propagation :   0.63 ( 0%) usr   0.00 ( 0%) sys   0.60 ( 0%) wall   
   6 kB ( 0%) ggc
 tree find ref. vars   :   0.12 ( 0%) usr   0.01 ( 0%) sys   0.12 ( 0%) wall   
8202 kB ( 1%) ggc
 tree PTA  :   3.61 ( 0%) usr   0.07 ( 1%) sys   3.64 ( 0%) wall   
  96 kB ( 0%) ggc
 tree alias analysis   :   6.71 ( 0%) usr   0.11 ( 1%) sys   6.74 ( 0%) wall   
   3 kB ( 0%) ggc
 tree call clobbering  :   0.39 ( 0%) usr   0.00 ( 0%) sys   0.37 ( 0%) wall   
   0 kB ( 0%) ggc
 tree flow sensitive alias:   0.11 ( 0%) usr   0.00 ( 0%) sys   0.12 ( 0%) wall
  9 kB ( 0%) ggc
 tree flow insensitive alias:   3.54 ( 0%) usr   0.00 ( 0%) sys   3.53 ( 0%)
wall   0 kB ( 0%) ggc
 tree memory partitioning:  18.88 ( 0%) usr   0.03 ( 0%) sys  18.93 ( 0%) wall 
 0 kB ( 0%) ggc
 tree PHI insertion:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall   
   1 kB ( 0%) ggc
 tree SSA rewrite  :   0.17 ( 0%) usr   0.00 ( 0%) sys   0.18 ( 0%) wall  
25972 kB ( 2%) ggc
 tree SSA other:   0.02 ( 0%) usr   0.03 ( 0%) sys   0.08 ( 0%) wall   
   0 kB ( 0%) ggc
 tree SSA incremental  :   0.82 ( 0%) usr   0.00 ( 0%) sys   0.82 ( 0%) wall   
   9 kB ( 0%) ggc
 tree operand scan :6681.62 (11%) usr   0.55 ( 5%) sys6698.35 (11%) wall  
19727 kB ( 1%) ggc
 dominator optimization:   0.26 ( 0%) usr   0.00 ( 0%) sys   0.25 ( 0%) wall   
  11 kB ( 0%) ggc
 tree SRA  :   0.06 ( 0%) usr   0.00 ( 0%) sys   0.06 ( 0%) wall   
   0 kB ( 0%) ggc
 tree STORE-CCP:   0.15 ( 0%) usr   0.00 ( 0%) sys   0.15 ( 0%) wall   
   1 kB ( 0%) ggc
 tree CCP  :   0.18 ( 0%) usr   0.00 ( 0%) sys   0.19 ( 0%) wall   
   3 kB ( 0%) ggc
 tree reassociation:   0.07 ( 0%) usr   0.00 ( 0%) sys   0.08 ( 0%) wall   
   2 kB ( 0%) ggc
 tree PRE  :   0.37 ( 0%) usr   0.00 ( 0%) sys   0.38 ( 0%) wall   
2289 kB ( 0%) ggc
 tree FRE  :   0.38 ( 0%) usr   0.01 ( 0%) sys   0.38 ( 0%) wall   
2297 kB ( 0%) ggc
 tree linearize phis   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 tree forward propagate:   0.04 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall   
   0 kB ( 0%) ggc
 tree conservative DC

[Bug middle-end/38474] [4.3/4.4 Regression] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

[steven at gcc dot gnu dot org]

--- Comment #30 from steven at gcc dot gnu dot org  2008-12-17 07:01 ---
I think redoing this with 4.4.0 would be useful, to check if new code (like
IRA) uses this kind of non-linear algorithms.  But the register renaming patch
hasn't changed between 4.3 and 4.4, so I would compile with
-fno-rename-registers ;-)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474

[Bug c++/38547] New: duplicate symbols with g++

[tammer at tammer dot net]

Hello,
I get the following duplicate symbols with g++ on AIX.

g++ (GCC) 4.2.4

g++ hello.cpp -o hello (hello.cpp is just a cout hello world...)

ld: 0711-224 WARNING: Duplicate symbol: .__divdi3
ld: 0711-224 WARNING: Duplicate symbol: .__moddi3
ld: 0711-224 WARNING: Duplicate symbol: .__udivdi3
ld: 0711-224 WARNING: Duplicate symbol: .__umoddi3
ld: 0711-224 WARNING: Duplicate symbol: .__udivmoddi4
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.

I will upload a log with a more detailed error description.

Bye
  Rainer Tammer


-- 
   Summary: duplicate symbols with g++
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tammer at tammer dot net
 GCC build triplet: powerpc-ibm-aix5.3.0.0
  GCC host triplet: powerpc-ibm-aix5.3.0.0
GCC target triplet: powerpc-ibm-aix5.3.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38547

[Bug c++/38547] duplicate symbols with g++

[tammer at tammer dot net]

--- Comment #1 from tammer at tammer dot net  2008-12-17 07:29 ---
Created an attachment (id=16914)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16914&action=view)
build log of sample


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38547

[Bug fortran/38538] ICE with elemental character function

[tkoenig at gcc dot gnu dot org]

--- Comment #4 from tkoenig at gcc dot gnu dot org  2008-12-17 07:33 ---
Not a regression:

 gfortran ice.f90
ice.f90: In function 'xmain':
ice.f90:8: internal compiler error: in gfc_conv_function_call, at
fortran/trans-expr.c:2846
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
$ gfortran-4.3 ice.f90
ice.f90: In function 'xmain':
ice.f90:8: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
$ gfortran-4.2 ice.f90
ice.f90: In function 'xmain':
ice.f90:5: internal compiler error: in expand_expr_real_1, at expr.c:6956
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 .


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu dot
   ||org
OtherBugsDependingO||19276, 32834
  nThis||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538