[Bug tree-optimization/34027] [4.3 regression] -Os code size nearly doubled

[bunk at stusta dot de]

--- Comment #6 from bunk at stusta dot de  2007-11-10 07:58 ---
I remove the dependency on PR32044:

This bug is really just something I observed by chance when looking at the
kernel compilation problem, but unless I completely misunderstood your comments
here whatever is required to fix this issue does not depend on PR32044 being
fixed.

Also the other way round __umoddi3 wouldn't be better than __udivdi3 for the
kernel although it mightbe what gets emitted after this bug gets fixed.


-- 

bunk at stusta dot de changed:

   What|Removed |Added

  BugsThisDependsOn|32044   |


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

[Bug fortran/34020] Bogus codegen for openmp atomics w/ indirects operands on IPF

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2007-11-10 07:55 ---
Fixed on the trunk so far.


-- 


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

[Bug middle-end/34018] [4.3 Regression] ICE: verify_stmts failed

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2007-11-10 07:53 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/32241] [4.1/4.2 regression] ICE trying to call x.~X(); in a template

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2007-11-10 07:53 ---
Fixed so far on the trunk.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.1/4.2/4.3 regression] ICE|[4.1/4.2 regression] ICE
   |trying to call x.~X(); in a |trying to call x.~X(); in a
   |template|template


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

[Bug tree-optimization/33680] [4.3 Regression] ICE when compilling elbg.c from ffmpeg (vectorizer)

[jakub at gcc dot gnu dot org]

--- Comment #22 from jakub at gcc dot gnu dot org  2007-11-10 07:52 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/34020] Bogus codegen for openmp atomics w/ indirects operands on IPF

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2007-11-10 07:52 ---
Subject: Bug 34020

Author: jakub
Date: Sat Nov 10 07:51:55 2007
New Revision: 130069

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130069
Log:
PR fortran/34020
* gimplify.c (goa_lhs_expr_p): Inside INDIRECT_REF handle unshared
nops.

* testsuite/libgomp.fortran/pr34020.f90: New test.

Added:
trunk/libgomp/testsuite/libgomp.fortran/pr34020.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/libgomp/ChangeLog


-- 


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

[Bug middle-end/34018] [4.3 Regression] ICE: verify_stmts failed

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2007-11-10 07:46 ---
Subject: Bug 34018

Author: jakub
Date: Sat Nov 10 07:46:31 2007
New Revision: 130068

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130068
Log:
PR middle-end/34018
* tree-inline.h (copy_body_data): Add regimplify field.
* tree-inline.c (copy_body_r): Set id->regimplify to true
if an TREE_INVARIANT ADDR_EXPR is no longer invariant after
substitutions.
(copy_bb): Clear id->regimplify before walk_tree, if it is
set afterwards, regimplify the whole statement.

* g++.dg/opt/inline14.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/inline14.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c
trunk/gcc/tree-inline.h


-- 


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

[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use

[bunk at stusta dot de]

--- Comment #25 from bunk at stusta dot de  2007-11-10 07:41 ---
Adding workarounds in all affected places in the kernel would be horribly
fragile, but I've confirmed your -fno-tree-scev-cprop suggestion works around
it and I'll submit a patch to the Linux kernel to use it with gcc 4.3.


-- 


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

[Bug tree-optimization/33680] [4.3 Regression] ICE when compilling elbg.c from ffmpeg (vectorizer)

[jakub at gcc dot gnu dot org]

--- Comment #21 from jakub at gcc dot gnu dot org  2007-11-10 07:40 ---
Subject: Bug 33680

Author: jakub
Date: Sat Nov 10 07:40:37 2007
New Revision: 130067

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130067
Log:
PR tree-optimization/33680
* tree-data-ref.c (split_constant_offset) : Punt
if the added cast involves variable length types.

* gcc.c-torture/compile/20071108-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/20071108-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-data-ref.c


-- 


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

[Bug c++/32241] [4.1/4.2/4.3 regression] ICE trying to call x.~X(); in a template

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2007-11-10 07:36 ---
Subject: Bug 32241

Author: jakub
Date: Sat Nov 10 07:36:09 2007
New Revision: 130066

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130066
Log:
PR c++/32241
* pt.c (tsubst_copy_and_build) : If object_type
is not scalar type, let finish_class_member_access_expr handle
diagnostics.  Pass BIT_NOT_EXPR argument to
finish_pseudo_destructor_expr.  Handle SCOPE_REF properly.

* g++.dg/template/pseudodtor3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/template/pseudodtor3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/34048] New: [4.3 Regression]: Revision 130040 miscompiles 450.soplex

[hjl at lucon dot org]

Revision 130040 miscompiles 450.soplex in SPEC CPU 2006 with -O2 -ffast-math
on Linux/x86-64:

  Running (#1) 450.soplex ref base o2 default

450.soplex: copy #0 non-zero return code (rc=0, signal=11)

Error with '/export/spec/src/2006/x86_64/spec/bin/specinvoke -E -d
/export/spec/src/2006/x86_64/spec/benchspec/CPU2006/450.soplex/run/run_base_ref_o2.
-c 1 -e compare.err -o compare.stdout -f compare.cmd': check file
'/export/spec/src/2006/x86_64/spec/benchspec/CPU2006/450.soplex/run/run_base_ref_o2./.err'
*** Miscompare of ref.stderr, see
/export/spec/src/2006/x86_64/spec/benchspec/CPU2006/450.soplex/run/run_base_ref_o2./ref.stderr.mis
*** Miscompare of ref.out, see
/export/spec/src/2006/x86_64/spec/benchspec/CPU2006/450.soplex/run/run_base_ref_o2./ref.out.mis
Invalid run; unable to continue.  If you wish to ignore errors please use '-I'
or ignore_errors


-- 
   Summary: [4.3 Regression]: Revision 130040 miscompiles 450.soplex
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
GCC target triplet: x86_64-unknown-linux-gnu
OtherBugsDependingO 33604
 nThis:


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

[Bug bootstrap/33992] Building libstdc++-v3: include/limits: stray '\275' in program

[dirtyepic at gentoo dot org]

--- Comment #6 from dirtyepic at gentoo dot org  2007-11-10 06:42 ---
this error doesn't happen on x86 but i did reproduce it w/ make
profiledbootstrap using today's trunk on x86_64.  if no one else is hitting
this it points to a problem on our end, but i'll look further into it soon.


-- 

dirtyepic at gentoo dot org changed:

   What|Removed |Added

 CC||dirtyepic at gentoo dot org


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

[Bug c++/30297] [4.1/4.2 regression] ICE with extern "C" and inheritance

[patchapp at dberlin dot org]

--- Comment #11 from patchapp at dberlin dot org  2007-11-10 04:05 ---
Subject: Bug number PR c++/30297

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00435.html


-- 


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

[Bug fortran/30285] gfortran excessive memory usage with COMMON blocks in modules

[patchapp at dberlin dot org]

--- Comment #18 from patchapp at dberlin dot org  2007-11-10 04:01 ---
Subject: Bug number PR 30285

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00552.html


-- 


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

[Bug c++/30297] [4.1/4.2 regression] ICE with extern "C" and inheritance

[patchapp at dberlin dot org]

--- Comment #10 from patchapp at dberlin dot org  2007-11-10 04:00 ---
Subject: Bug number PR c++/30297

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00435.html


-- 


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

[Bug c++/30297] [4.1/4.2 regression] ICE with extern "C" and inheritance

[patchapp at dberlin dot org]

--- Comment #9 from patchapp at dberlin dot org  2007-11-10 03:55 ---
Subject: Bug number PR c++/30297

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00435.html


-- 


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

[Bug fortran/33945] PROCEDURE in module somtimes wrongly rejected

[patchapp at dberlin dot org]

--- Comment #6 from patchapp at dberlin dot org  2007-11-10 03:54 ---
Subject: Bug number PR33945

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00416.html


-- 


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

[Bug target/16350] gcc only understands little endian ARM systems

[patchapp at dberlin dot org]

--- Comment #19 from patchapp at dberlin dot org  2007-11-10 03:53 ---
Subject: Bug number PR16350

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00362.html


-- 


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

[Bug target/16350] gcc only understands little endian ARM systems

[patchapp at dberlin dot org]

--- Comment #18 from patchapp at dberlin dot org  2007-11-10 03:53 ---
Subject: Bug number PR16350

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00358.html


-- 


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

[Bug c/29062] unclear diagnostic for declaration after label

[patchapp at dberlin dot org]

--- Comment #9 from patchapp at dberlin dot org  2007-11-10 03:47 ---
Subject: Bug number PR c/29062

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00111.html


-- 


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

[Bug tree-optimization/26264] Extraneous warning with __builtin_stdarg_start and optimization

[patchapp at dberlin dot org]

--- Comment #11 from patchapp at dberlin dot org  2007-11-10 03:47 ---
Subject: Bug number PR middle-end/26264

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00106.html


-- 


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

[Bug c++/33510] Array size of array with size determined by the initializer wrong with packs

[dgregor at gcc dot gnu dot org]

--- Comment #2 from dgregor at gcc dot gnu dot org  2007-11-10 02:54 ---
Fixed


-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/33510] Array size of array with size determined by the initializer wrong with packs

[dgregor at gcc dot gnu dot org]

--- Comment #1 from dgregor at gcc dot gnu dot org  2007-11-10 02:53 ---
Subject: Bug 33510

Author: dgregor
Date: Sat Nov 10 02:53:31 2007
New Revision: 130065

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130065
Log:
2007-11-09  Douglas Gregor  <[EMAIL PROTECTED]>

PR c++/33510
* decl.c (cp_complete_array_type): If any of the initializer
elements are pack expansions, don't compute the array size yet.

2007-11-09  Douglas Gregor  <[EMAIL PROTECTED]>

PR c++/33510
* g++.dg/cpp0x/variadic-init.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-init.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/33335] [4.3 Regression] FAIL: 26_numerics/complex/inserters_extractors/wchar_t/1.cc

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca  2007-11-10 
02:44 ---
Subject: Re:  [4.3 Regression] FAIL:
26_numerics/complex/inserters_extractors/wchar_t/1.cc

> jakub at gcc dot gnu dot org changed:
> 
>What|Removed |Added
> 
> URL||http://gcc.gnu.org/ml/gcc-
>||patches/2007-
>||11/msg00266.html

This patch eliminates all the optab failures on hppa2.0w-hp-hpux11.11.

Thanks,
Dave


-- 


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

[Bug target/30315] optimize unsigned-add overflow test on x86 to use cpu flags from addl

[rask at gcc dot gnu dot org]

--- Comment #16 from rask at gcc dot gnu dot org  2007-11-10 01:32 ---
Two testcases which aren't optimized:

unsigned int bad1 (unsigned int a)
{
  unsigned int c = a - 1;
  if (c > a)
abort ();
  else
return c;
}

unsigned int bad2 (unsigned int a)
{
  unsigned int c = a - 2;
  if (c > a)
abort ();
  else
return c;
}

See also http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01359.html>.


-- 


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

[Bug target/33474] bfin: ICE: RTL check: expected code 'set' or 'clobber', have 'parallel' in bfin_adjust_cost, at config/bfin/bfin.c:3120

[rask at gcc dot gnu dot org]

--- Comment #2 from rask at gcc dot gnu dot org  2007-11-10 01:21 ---
I can't reproduce this with revision 127331 or 129967.


-- 


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

[Bug fortran/30285] gfortran excessive memory usage with COMMON blocks in modules

[Tobias dot Schlueter at physik dot uni-muenchen dot de]

--- Comment #17 from Tobias dot Schlueter at physik dot uni-muenchen dot de 
 2007-11-10 01:16 ---
Subject: Re:  gfortran excessive memory usage with COMMON
 blocks in modules

fxcoudert at gcc dot gnu dot org wrote:
> --- Comment #16 from fxcoudert at gcc dot gnu dot org  2007-11-09 23:59 
> ---
> (In reply to comment #15)
>> I wrote this code originally, and I agree with your analysis.
> 
> But regtesting doesn't agree with my analysis... in case of common with
> bind(c,name="..."), this patch hampers the diagnosis of commons with the same
> name but different labels. I've tried hard to get it rolling that way, because
> I agree it's cleaner, but I couldn't. I'll propose a different approach (a
> hack, to avoid writing twice the same combination of name and binding label) 
> to
> the list when it finishes regtesting.

There was no BIND(C) when I wrote it :-)

I'll give it a look tomorrow.


-- 


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

[Bug rtl-optimization/23813] redundant register assignments not eliminated

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2007-11-10 01:07 ---
So the issue here is that lshiftrt and ashift is not split up.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.3 Regression] redundant  |redundant register
   |register assignments not|assignments not eliminated
   |eliminated  |


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

[Bug rtl-optimization/23813] [4.3 Regression] redundant register assignments not eliminated

[rask at gcc dot gnu dot org]

--- Comment #4 from rask at gcc dot gnu dot org  2007-11-10 00:59 ---
We are regressing! Number of asm lines, not counting directives:
4.1.2:  88
4.2.0:  80
4.2.1:  80
4.2.2:  80
4.3.0: 100 (revision 129967)


-- 

rask at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|redundant register  |[4.3 Regression] redundant
   |assignments not eliminated  |register assignments not
   ||eliminated


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

[Bug fortran/25252] ICE on invalid code

[fxcoudert at gcc dot gnu dot org]

--- Comment #16 from fxcoudert at gcc dot gnu dot org  2007-11-10 00:53 
---
The following patch clears part of the problem, for example the following
testcase:

module g
  interface i
module procedure sint => sreal
  end interface i
end module g

More is needed, but I'm stuck. I've used valgrind, and I think we don't recover
well after gfc_match_modproc() exiting with MATCH_ERROR.


Index: decl.c
===
--- decl.c  (revision 129869)
+++ decl.c  (working copy)
@@ -5862,12 +5862,23 @@ gfc_match_modproc (void)

   for (;;)
 {
+  bool last = false;
+
   m = gfc_match_name (name);
   if (m == MATCH_NO)
goto syntax;
   if (m != MATCH_YES)
return MATCH_ERROR;

+  /* Check for syntax error before starting to add symbols to the
+current namespace.  */
+  if (gfc_match_eos () == MATCH_YES)
+   last = true;
+  if (!last && gfc_match_char (',') != MATCH_YES)
+   goto syntax;
+
+  /* Now we're sure the syntax is valid, we process this item
+further.  */
   if (gfc_get_symbol (name, module_ns, &sym))
return MATCH_ERROR;

@@ -5881,10 +5892,8 @@ gfc_match_modproc (void)

   sym->attr.mod_proc = 1;

-  if (gfc_match_eos () == MATCH_YES)
+  if (last)
break;
-  if (gfc_match_char (',') != MATCH_YES)
-   goto syntax;
 }

   return MATCH_YES;


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
   Last reconfirmed|2007-11-02 13:18:42 |2007-11-10 00:53:08
   date||


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

[Bug middle-end/33315] If condition not getting eliminated

[steven at gcc dot gnu dot org]

--- Comment #3 from steven at gcc dot gnu dot org  2007-11-10 00:27 ---
As a missed optimization, this bug adds new information.  But as a regression,
this is a dup of bug 30905.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.3 Regression] If |If condition not getting
   |condition not getting   |eliminated
   |eliminated  |


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

[Bug rtl-optimization/15792] missed subreg optimization

[rask at gcc dot gnu dot org]

--- Comment #10 from rask at gcc dot gnu dot org  2007-11-10 00:15 ---
This was fixed in 4.3.0.


-- 

rask at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Keywords||ra
  Known to fail||4.1.2 4.2.0 4.2.1 4.2.2
  Known to work||4.3.0
 Resolution||FIXED


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

[Bug fortran/30285] gfortran excessive memory usage with COMMON blocks in modules

[fxcoudert at gcc dot gnu dot org]

--- Comment #16 from fxcoudert at gcc dot gnu dot org  2007-11-09 23:59 
---
(In reply to comment #15)
> I wrote this code originally, and I agree with your analysis.

But regtesting doesn't agree with my analysis... in case of common with
bind(c,name="..."), this patch hampers the diagnosis of commons with the same
name but different labels. I've tried hard to get it rolling that way, because
I agree it's cleaner, but I couldn't. I'll propose a different approach (a
hack, to avoid writing twice the same combination of name and binding label) to
the list when it finishes regtesting.


-- 


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

[Bug rtl-optimization/11873] inefficient use of registers induces size and time overhead

[rask at gcc dot gnu dot org]

--- Comment #4 from rask at gcc dot gnu dot org  2007-11-09 23:51 ---
This has improved (-O2 -fomit-frame-pointer):

test:
movl4(%esp), %eax   # 32*movsi_1/1  [length = 4]
movl8(%esp), %edx   # 44*movsi_1/1  [length = 4]
orl %eax, %edx  # 6 *iorsi_1/1  [length = 2]
addl$1, %eax# 35*addsi_1/1  [length = 3]
cmpl$1, %edx# 38*cmpsi_1_insn/1 [length = 3]
sbbl%edx, %edx  # 39x86_movsicc_0_m1[length = 2]
notl%edx# 40*one_cmplsi2_1  [length = 2]
andl%edx, %eax  # 41*andsi_1/1  [length = 2]
ret # 47return_internal [length = 1]
.ident  "GCC: (GNU) 4.3.0 20071102 (experimental)"

With -Os -fomit-frame-pointer we get:

test:
movl4(%esp), %edx   # 32*movsi_1/1  [length = 4]
xorl%eax, %eax  # 48*movsi_xor  [length = 2]
movl8(%esp), %ecx   # 43*movsi_1/1  [length = 4]
orl %edx, %ecx  # 7 *iorsi_3[length = 2]
je  .L3 # 8 *jcc_1  [length = 2]
leal1(%edx), %eax   # 44*lea_1  [length = 3]
.L3:
ret # 47return_internal [length = 1]

With -O2/-Os -fomit-frame-pointer -march=pentiumpro:

test:
movl4(%esp), %edx   # 32*movsi_1/1  [length = 4]
xorl%eax, %eax  # 46*movsi_xor  [length = 2]
leal1(%edx), %ecx   # 41*lea_1  [length = 3]
orl 8(%esp), %edx   # 36*iorsi_3[length = 4]
cmovne  %ecx, %eax  # 38*movsicc_noc/1  [length = 3]
ret # 44return_internal [length = 1]

I would probably code it like so:

movl4(%esp), %eax   ; 4
movl8(%esp), %edx   ; 4
orl %eax,   %edx; 2
addl$-1,%edx; 3
adcl$0, %eax; 3
ret ; 1


-- 


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

[Bug fortran/34044] OpenMP: Crashes with valid code.

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2007-11-09 23:50 ---
Ok, reading the thread in there it is clear the stack size is the problem.
As it needs 16MB of memory on the stack, it should be run with
ulimit -s 16384
(note that ulimit -s unlimited doesn't imply unlimited thread stack size,
just the default, which is not very large for these purposes).


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/34047] [4.3 Regression] ice for legal code in vectorizer

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2007-11-09 22:58 ---


*** This bug has been marked as a duplicate of 33856 ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/33856] [4.3 Regression] Segfault in create_data_ref/compute_data_dependences_for_loop

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2007-11-09 22:58 ---
*** Bug 34047 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com


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

[Bug rtl-optimization/33737] [4.3 Regression] verify_flow_info failed: Wrong probability of edge 94->1 -6651

[rguenth at gcc dot gnu dot org]

--- Comment #14 from rguenth at gcc dot gnu dot org  2007-11-09 22:56 
---
*** Bug 33867 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tbm at cyrius dot com


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

[Bug tree-optimization/33867] [4.3 Regression] ICE verify_flow_info failed (Wrong frequency of block)

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2007-11-09 22:56 ---


*** This bug has been marked as a duplicate of 33737 ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/34013] callee-save register value sometimes corrupted when __stkchk called

[acn1 at cam dot ac dot uk]

--- Comment #1 from acn1 at cam dot ac dot uk  2007-11-09 22:56 ---
Created an attachment (id=14522)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14522&action=view)
patch to gcc/config/i386/i386.c

This tries to avoid saving regs before allocating the stack frame if the frame
will be bigh enough to need probes (whihc will be a call to __stkchk) when the
save_regs_using_mov option has been selected. With this you will not save the
one cycle in the prologue if your frame is large, but maybe you get the right
answers? My patch does this for all i386 targets and that may not be necessary
since the problem that bugs me only arises if TARGET_STACK_PROBE leads to
generation of a call instruction.


-- 


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

[Bug rtl-optimization/33737] [4.3 Regression] verify_flow_info failed: Wrong probability of edge 94->1 -6651

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2007-11-09 22:55 
---
*** Bug 34046 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com


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

[Bug middle-end/34046] [4.3 Regression] verify_flow_info failed

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2007-11-09 22:55 ---


*** This bug has been marked as a duplicate of 33737 ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/19097] [4.1/4.2/4.3 regression] Quadratic behavior with many sets for the same register in VRP

[steven at gcc dot gnu dot org]

--- Comment #43 from steven at gcc dot gnu dot org  2007-11-09 22:08 ---
IMVHO this should be closed as WONTFIX.


-- 


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

[Bug fortran/33698] FAIL: gfortran.dg/gamma_5.f90

[tkoenig at gcc dot gnu dot org]

--- Comment #21 from tkoenig at gcc dot gnu dot org  2007-11-09 21:50 
---
(In reply to comment #20)

Hi FX,

> I can work on the C version of lgamma at some point in the week-end, if you
> want me to.

That would be great.  Real Life has caught up with me in a big
way the last few weeks, so I couldn't do anything in this direction.


-- 


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

[Bug middle-end/34046] [4.3 Regression] verify_flow_info failed

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|c++ |middle-end
   Keywords||ice-on-valid-code
Summary|verify_flow_info failed |[4.3 Regression]
   ||verify_flow_info failed
   Target Milestone|--- |4.3.0


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

[Bug tree-optimization/34047] [4.3 Regression] ice for legal code in vectorizer

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|c   |tree-optimization
   Keywords||ice-on-valid-code
Summary|ice for legal code  |[4.3 Regression] ice for
   ||legal code in vectorizer
   Target Milestone|--- |4.3.0


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

[Bug fortran/34044] OpenMP: Crashes with valid code.

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2007-11-09 21:30 ---
Given how big the array is it is very likely they just overflow the thread
stack.
What ulimit -s they are using?


-- 


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

[Bug fortran/34044] OpenMP: Crashes with valid code.

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2007-11-09 21:21 ---
> Yeah, the crash was clearly because j was not initialized.

My inability to generate test cases does not mean that there is not necessarily
no bug in gfortran. See http://gcc.gnu.org/ml/fortran/2007-11/msg00052.html

I'm not claiming that there is a bug, but several people see crashes.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
   Keywords||openmp
 Resolution|INVALID |


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

[Bug c/34047] ice for legal code

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2007-11-09 20:53 ---
Created an attachment (id=14521)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14521&action=view)
C source code


-- 


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

[Bug c/34047] New: ice for legal code

[dcb314 at hotmail dot com]

I just tried to compile the Suse Linux package spandsp-0.0.3-43
with the GNU C compiler version 4.3 snapshot 20071102

The compiler said

v17rx.c: In function 'v17_rx_restart':
v17rx.c:12020: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Source code attached. Flags -O2 -ftree-vectorize -w  -std=gnu99 required.

Here is valgrind helping out with some debug 
information

==22690== Invalid read of size 2
==22690==at 0x6EE9E6: create_data_ref (tree-data-ref.c:746)
==22690==by 0x6F4016: compute_data_dependences_for_loop
(tree-data-ref.c:3975)
==22690==by 0x816402: vect_analyze_loop (tree-vect-analyze.c:3209)
==22690==by 0x833716: vectorize_loops (tree-vectorizer.c:2498)
==22690==by 0x6439F8: execute_one_pass (passes.c:1118)
==22690==by 0x643BCF: execute_pass_list (passes.c:1171)
==22690==by 0x643BE4: execute_pass_list (passes.c:1172)
==22690==by 0x643BE4: execute_pass_list (passes.c:1172)
==22690==by 0x71EEAF: tree_rest_of_compilation (tree-optimize.c:404)
==22690==by 0x8C1791: cgraph_expand_function (cgraphunit.c:1060)
==22690==by 0x8C3BFB: cgraph_optimize (cgraphunit.c:1123)
==22690==by 0x4162BD: c_write_global_declarations (c-decl.c:8081)
==22690==  Address 0x0 is not stack'd, malloc'd or (recently) free'd


-- 
   Summary: ice for legal code
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: suse-linux-x86_64


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

[Bug c++/34046] verify_flow_info failed

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2007-11-09 20:50 ---
Created an attachment (id=14520)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14520&action=view)
C++ source code


-- 


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

[Bug c++/34046] New: verify_flow_info failed

[dcb314 at hotmail dot com]

I just tried to compile the Suse Linux package snes9x-1.5-107
with the GNU C++ compiler version 4.3 snapshot 20071102

The compiler said

spc700.cpp:977: warning: deprecated conversion from string constant to 'char*'
spc700.cpp: In function 'void ApuCA()':
spc700.cpp:807: error: verify_flow_info: Wrong probability of edge 12->13
-25535
spc700.cpp:807: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Source code attached. Flag -O3 required.


-- 
   Summary: verify_flow_info failed
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: suse-linux-x86_64


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

[Bug target/31943] very missed optimization.

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2007-11-09 20:43 ---
This was the normal "subreg" issue which was fixed by Ian back on 2007-01-31.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug rtl-optimization/18560] better optimalization of EOR/MOV block.

[rask at gcc dot gnu dot org]

--- Comment #7 from rask at gcc dot gnu dot org  2007-11-09 20:40 ---
This has been fixed for more than a year:

reverse:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
eor r3, r0, r0, ror #16 @ 12*arith_shiftsi  [length = 4]
bic r3, r3, #16711680   @ 13*arm_andsi3_insn/2  [length
= 4]
mov r0, r0, ror #8  @ 15*arm_shiftsi3   [length = 4]
eor r0, r0, r3, lsr #8  @ 23*arith_shiftsi  [length = 4]
@ lr needed for prologue@ 36prologue_use[length = 4]
bx  lr  @ 39return  [length = 12]
.size   reverse, .-reverse
.ident  "GCC: (GNU) 4.2.0 20060729 (experimental)"

4.3.0 (revision 129967) generates the same code.


-- 

rask at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.2.0 4.3.0
 Resolution||FIXED


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

[Bug target/31943] very missed optimization.

[pluto at agmk dot net]

--- Comment #4 from pluto at agmk dot net  2007-11-09 20:33 ---
current 4.3 works fine:

(32-bits):

_Z3msby:
movzbl  11(%esp), %eax
ret

(64-bits):
_Z3msby:
shrq$56, %rdi
movl%edi, %eax
ret


-- 

pluto at agmk dot net changed:

   What|Removed |Added

  Known to fail||4.2.2
  Known to work||4.3.0


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

[Bug rtl-optimization/21150] Suboptimal byte extraction from 64bits

[rask at gcc dot gnu dot org]

--- Comment #4 from rask at gcc dot gnu dot org  2007-11-09 19:48 ---
I think this might be a middle-end issue related to PR 7061 or PR 15184. We're
doing slightly better with GCC 4.3.0 (because of subreg lowering, I guess), but
not much (asm output with -dp for readability):

a:
movlv+44, %eax  # 53*movsi_1/1  [length = 5]
movlv+8, %edx   # 23*movsi_1/1  [length = 6]
shrl$8, %eax# 54*lshrsi3_1/1[length = 3]
xorbv+36, %al   # 11*xorqi_1/1  [length = 6]
xorbv, %al  # 13*xorqi_1/1  [length = 6]
xorbv+54, %al   # 17*xorqi_1/1  [length = 6]
xorbv+63, %al   # 21*xorqi_1/1  [length = 6]
shrl$8, %edx# 24*lshrsi3_1/1[length = 3]
xorl%edx, %eax  # 66*xorsi_1/1  [length = 2]
xorbv+18, %al   # 29*xorqi_1/1  [length = 6]
xorbv+27, %al   # 33*xorqi_1/1  [length = 6]
ret # 69return_internal [length = 1]
b:
pushl   %ebx# 75*pushsi2[length = 1]
movlv+20, %edx  # 69*movsi_1/1  [length = 6]
movlv+12, %ebx  # 67*movsi_1/1  [length = 6]
movlv+8, %ecx   # 66*movsi_1/1  [length = 6]
movlv+16, %eax  # 68*movsi_1/1  [length = 5]
shrdl   $8, %ebx, %ecx  # 81x86_shrd_1/1[length = 4]
shrdl   $16, %edx, %eax # 83x86_shrd_1/1[length = 4]
movlv+24, %edx  # 71*movsi_1/1  [length = 6]
xorl%ecx, %eax  # 70*xorsi_1/1  [length = 2]
movlv+28, %ecx  # 72*movsi_1/1  [length = 6]
xorbv, %al  # 13*xorqi_1/1  [length = 6]
popl%ebx# 78popsi1  [length = 1]
shrdl   $24, %ecx, %edx # 85x86_shrd_1/1[length = 4]
xorl%edx, %eax  # 73*xorsi_1/1  [length = 2]
movlv+44, %edx  # 53*movsi_1/1  [length = 6]
xorbv+36, %al   # 21*xorqi_1/1  [length = 6]
shrl$8, %edx# 54*lshrsi3_1/1[length = 3]
xorl%edx, %eax  # 74*xorsi_1/1  [length = 2]
xorbv+54, %al   # 29*xorqi_1/1  [length = 6]
xorbv+63, %al   # 33*xorqi_1/1  [length = 6]
ret # 79return_internal [length = 1]
c:
movzbl  v+9, %eax   # 7 *movqi_1/3  [length = 7]
xorbv+18, %al   # 8 *xorqi_1/1  [length = 6]
xorbv, %al  # 9 *xorqi_1/1  [length = 6]
xorbv+27, %al   # 10*xorqi_1/1  [length = 6]
xorbv+36, %al   # 11*xorqi_1/1  [length = 6]
xorbv+45, %al   # 12*xorqi_1/1  [length = 6]
xorbv+54, %al   # 13*xorqi_1/1  [length = 6]
xorbv+63, %al   # 14*xorqi_1/1  [length = 6]
ret # 33return_internal [length = 1]
d:
pushl   %ebx# 75*pushsi2[length = 1]
movlv+20, %edx  # 69*movsi_1/1  [length = 6]
movlv+12, %ebx  # 67*movsi_1/1  [length = 6]
movlv+8, %ecx   # 66*movsi_1/1  [length = 6]
movlv+16, %eax  # 68*movsi_1/1  [length = 5]
shrdl   $8, %ebx, %ecx  # 81x86_shrd_1/1[length = 4]
shrdl   $16, %edx, %eax # 83x86_shrd_1/1[length = 4]
movlv+24, %edx  # 71*movsi_1/1  [length = 6]
xorl%ecx, %eax  # 70*xorsi_1/1  [length = 2]
movlv+28, %ecx  # 72*movsi_1/1  [length = 6]
xorbv, %al  # 13*xorqi_1/1  [length = 6]
popl%ebx# 78popsi1  [length = 1]
shrdl   $24, %ecx, %edx # 85x86_shrd_1/1[length = 4]
xorl%edx, %eax  # 73*xorsi_1/1  [length = 2]
movlv+44, %edx  # 53*movsi_1/1  [length = 6]
xorbv+36, %al   # 21*xorqi_1/1  [length = 6]
shrl$8, %edx# 54*lshrsi3_1/1[length = 3]
xorl%edx, %eax  # 74*xorsi_1/1  [length = 2]
xorbv+54, %al   # 29*xorqi_1/1  [length = 6]
xorbv+63, %al   # 33*xorqi_1/1  [length = 6]
ret # 79return_internal [length = 1]
.ident  "GCC: (GNU) 4.3.0 20071102 (experimental)"


-- 

rask at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.3.0


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

[Bug fortran/34044] OpenMP: Crashes with valid code.

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2007-11-09 19:43 ---
Yeah, the crash was clearly because j was not initialized.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug bootstrap/34045] New: gcc does not build on Debian etch AMD64

[laurent dot bonnaud at inpg dot fr]

Hi,

I tried to compile gcc 4.2.2 from source on Debian etch AMD64 and failed.  I
used the system compiler:

$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
x86_64-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

Here is what I did and got in return:

$ ./configure --prefix=/usr/local/gcc-4.2
[No error]
$ make bootstrap
[...]
config.status: executing default-1 commands
Adding multilib support to Makefile in ../.././libmudflap
multidirs=32
with_multisubdir=
Running configure in multilib subdirs 32
pwd: /var/tmp/LB/gcc-4.2.2/x86_64-unknown-linux-gnu/libmudflap
Running configure in multilib subdir 32
pwd: /var/tmp/LB/gcc-4.2.2/x86_64-unknown-linux-gnu
configure: creating cache ./config.cache
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for --enable-version-specific-runtime-libs... no
checking whether to enable maintainer-specific portions of Makefiles... no
checking for x86_64-unknown-linux-gnu-gcc...
/var/tmp/LB/gcc-4.2.2/host-x86_64-unknown-linux-gnu/gcc/xgcc
-B/var/tmp/LB/gcc-4.2.2/host-x86_64-unknown-linux-gnu/gcc/
-B/usr/local/gcc-4.2/x86_64-unknown-linux-gnu/bin/
-B/usr/local/gcc-4.2/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/gcc-4.2/x86_64-unknown-linux-gnu/include -isystem
/usr/local/gcc-4.2/x86_64-unknown-linux-gnu/sys-include  -m32
checking for C compiler default output file name... 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.
make[1]: *** [configure-target-libmudflap] Error 1
make[1]: Leaving directory `/var/tmp/LB/gcc-4.2.2'
make: *** [bootstrap] Error 2


-- 
   Summary: gcc does not build on Debian etch AMD64
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent dot bonnaud at inpg dot fr
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug bootstrap/34045] gcc does not build on Debian etch AMD64

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-11-09 19:29 ---
What happens if you don't build in the source directory?


-- 


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

[Bug fortran/34044] OpenMP: Crashes with valid code.

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2007-11-09 19:18 ---
(In reply to comment #0)
>y(j) = 0.0_dp

This part is nonsense and should be "y = 0.0_dp".
The original dump looks ok; I don't know whether something else goes wrong. -
It does not crash here anymore (x86-64 -m32/-m64, after fixing my stupid typo
above).


-- 


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

[Bug c++/34039] -Werror does not trigger non zero exit code

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2007-11-09 19:13 ---
Moreover, those should be "error:" messages in GCC 4.3. I don't think such a
change would be backported to GCC 4.1


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


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

[Bug fortran/34044] New: OpenMP: Crashes with valid code.

[burnus at gcc dot gnu dot org]

Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/9a7daa8d75084b6b/

The program looks valid. It crashes here at run time with -m32, but not with
-m64; with "y(j) = 0.0_dp" commented out it does not crash at all, here.


program sums
   implicit none
   integer, parameter :: sp = kind(1.0)
   integer, parameter :: dp = selected_real_kind(2*precision(1.0_sp))
   integer, parameter  :: num_steps = 200
   real:: t1, t2
   integer :: i, j
   real(kind=dp), dimension(0:num_steps-1) :: y

   call cpu_time(t1)
   y(j) = 0.0_dp
!$omp parallel do private(i)
   do j=0,num_steps-1
 do i=0,49
   y(j) = y(j) + 0.7_dp**i
 end do
   end do
!$omp end parallel do
   call cpu_time(t2)
   print *, "y(end) = ", y(num_steps-1)
   print *, "Reached result in ", t2-t1, " seconds processor time."
end program sums


-- 
   Summary: OpenMP: Crashes with valid code.
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug target/34042] Segfault in mips_cannot_change_mode_class

[rsandifo at gcc dot gnu dot org]

-- 

rsandifo at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rsandifo at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-09 18:55:04
   date||


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

[Bug rtl-optimization/34040] [4.3 Regression] ICE: in simplify_subreg, at simplify-rtx.c:4921 building libgfortran

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|middle-end  |rtl-optimization
   Target Milestone|--- |4.3.0


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

[Bug c++/34039] -Werror does not trigger non zero exit code

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-11-09 18:48 ---
This works for me:
cc1plus: warnings being treated as errors
t.c:3: warning: unused parameter 'a'
t.c:3: warning: unused parameter 'b'
t.c: In function 'float f(float, float)':
t.c:6: warning: control reaches end of non-void function
1

g++ -W -Wall t.c -S -Werror ;echo $?


-- 


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

[Bug fortran/33230] Missing check: specification function must be pure

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2007-11-09 18:45 
---
This was fixed (and the testsuite fixed also):

$ gfortran char_result_7.f90
char_result_7.f90:29.20:

character (len = fn (i)) :: f1
   1
Error: Specification function 'fn' at (1) must be PURE


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/33698] FAIL: gfortran.dg/gamma_5.f90

[fxcoudert at gcc dot gnu dot org]

--- Comment #20 from fxcoudert at gcc dot gnu dot org  2007-11-09 18:40 
---
Created an attachment (id=14519)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14519&action=view)
gamma from netlib, converted to C

(In reply to comment #18)
> OTOH, maybe using straight Netlib code would be better.

Thomas, here is my C version of the netlib gamma, including some testing code.
I also think using the netlib version is rather safe and we shouldn't take any
risk for a fallback implementation of a math function.

I can work on the C version of lgamma at some point in the week-end, if you
want me to.


-- 


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

[Bug tree-optimization/30604] Unable to coalesce ssa_names and which are marked as MUST COALESCE

[amacleod at redhat dot com]

--- Comment #13 from amacleod at redhat dot com  2007-11-09 18:40 ---
Then perhaps we should remove the attachment from this PR if it isn't
relevant...


-- 


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

[Bug c++/17577] [4.0/4.1/4.2/4.3 Regression] #pragma implementation no longer diagnoses use after file to which it applies

[tromey at gcc dot gnu dot org]

--- Comment #9 from tromey at gcc dot gnu dot org  2007-11-09 18:28 ---
Testing a patch.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu dot
   ||org
 AssignedTo|unassigned at gcc dot gnu   |tromey at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-02-12 17:53:38 |2007-11-09 18:28:17
   date||


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

[Bug tree-optimization/30604] Unable to coalesce ssa_names and which are marked as MUST COALESCE

[pinskia at gcc dot gnu dot org]

--- Comment #12 from pinskia at gcc dot gnu dot org  2007-11-09 18:27 
---
(In reply to comment #11)
> OK, new investigation show that using the smaller testcase firebird2-nav.cc
> shows the inliner is misbehaving. 

That smaller testcase is a different issue as explained in comment #6 and has
been filed under PR 31081 already.  


-- 


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

[Bug target/34025] Warning when compiling with -m64 -ffast-math on Intel Darwin

[dominiq at lps dot ens dot fr]

--- Comment #6 from dominiq at lps dot ens dot fr  2007-11-09 18:26 ---
Note that I still get the warning after having recompiled
gcc/config/i386/crtfastmath.c with -m64.


-- 


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

[Bug tree-optimization/34043] Missed optimization causing extra loads and stores when using x86_64 builtin function together with aggregate types.

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-11-09 18:24 ---
Related to PR 33790 (and most likely fixed by it).  There is another issue with
that bug relating to not deleting the extra store.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug debug/28834] [4.0/4.1/4.2/4.3 Regression] -g crashes sometimes when using may_alias and structs (ICE in splice_child_die)

[pinskia at gcc dot gnu dot org]

--- Comment #28 from pinskia at gcc dot gnu dot org  2007-11-09 18:21 
---
*** Bug 34041 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org


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

[Bug target/34041] ICE on __may_alias__ with -g

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-11-09 18:21 ---


*** This bug has been marked as a duplicate of 28834 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug testsuite/33775] Memset

[manu at gcc dot gnu dot org]

--- Comment #3 from manu at gcc dot gnu dot org  2007-11-09 18:16 ---
(In reply to comment #2)
> IMO the proposed change would make the code more readable.

Johan, the code you quote is in a file from the testsuite. Such code is used to
test for some correct behavior under various circumstances. Therefore, there is
typically a very good reason for the code to be written like that. Moreover, in
the testsuite you will find not only unreadable code but also code that is
broken on purpose to test that the compiler can handle such code.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/34001] Incorrect __attribute__ fastcall behavior

[hjl at lucon dot org]

--- Comment #3 from hjl at lucon dot org  2007-11-09 17:34 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00531.html


-- 

hjl at lucon dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2007-
   ||11/msg00531.html
   Keywords||patch


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

[Bug rtl-optimization/34035] [4.3 Regression] ICE in calc_dfs_tree with -O2 -fnon-call-exceptions -ffast-math -fno-gcse

[janis at gcc dot gnu dot org]

--- Comment #3 from janis at gcc dot gnu dot org  2007-11-09 17:23 ---
The option list should have included -O2.  This is one of the failures found by
compiling SPEC CPU2000 with lots of sets of options and running with the test
input, as described in http://gcc.gnu.org/ml/gcc/2007-09/msg00496.html.


-- 


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

[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use

[rguenther at suse dot de]

--- Comment #24 from rguenther at suse dot de  2007-11-09 17:11 ---
Subject: Re:  [4.3 regression] udivdi3 counterproductive,
 unwarranted use

On Fri, 9 Nov 2007, bunk at stusta dot de wrote:

> --- Comment #23 from bunk at stusta dot de  2007-11-09 17:09 ---
> We need a way to globally prevent it in the kernel or it will be a repeating
> source of problems there.
> 
> Is -fno-tree-scev-cprop a reasonable (and not too expensive) workaround for 
> the
> Linux kernel?

Yes, as is using volatile on this particular loop variable.

Richard.


-- 


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

[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use

[bunk at stusta dot de]

--- Comment #23 from bunk at stusta dot de  2007-11-09 17:09 ---
We need a way to globally prevent it in the kernel or it will be a repeating
source of problems there.

Is -fno-tree-scev-cprop a reasonable (and not too expensive) workaround for the
Linux kernel?


-- 


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

[Bug target/34001] Incorrect __attribute__ fastcall behavior

[hjl at lucon dot org]

--- Comment #2 from hjl at lucon dot org  2007-11-09 16:55 ---
From

http://msdn2.microsoft.com/en-us/library/6xa169sk(VS.80).aspx

"The first two DWORD or smaller arguments are passed in ECX and EDX registers;
all other arguments are passed right to left."

But it isn't clear if it applies to structure/union. We tested all MS compilers
we have and verified that the above doesn't apply to structure/union. To make
fastcall compatible with MS compilers, we should only put scalar arguments
in ECX and EDX.


-- 

hjl at lucon dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hjl at lucon dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-11-08 17:12:05 |2007-11-09 16:55:09
   date||


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

[Bug fortran/33592] FAIL: gfortran.dg/array_constructor_11.f90 -O1 execution test

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca  2007-11-09 
16:45 ---
Subject: Re:  FAIL: gfortran.dg/array_constructor_11.f90  -O1  execution test

> Could you test this patch?

Yes, tonight.  Thanks.

Dave


-- 


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

[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use

[rguenther at suse dot de]

--- Comment #22 from rguenther at suse dot de  2007-11-09 16:33 ---
Subject: Re:  [4.3 regression] udivdi3 counterproductive,
 unwarranted use

On Fri, 9 Nov 2007, bunk at stusta dot de wrote:

> --- Comment #21 from bunk at stusta dot de  2007-11-09 16:26 ---
> Let's leave the right/wrong discussion and look at it more pragmatically:
> 
> Could gcc get some kind of --expensive-libgcc flag that tells gcc that libgcc
> calls are a bit more expensive than usually and should be avoided?

While this is technically possible we already face stability and
maintainability problems in other areas where we do so (for example
the conditionally available C99 math has in the past lead to many
internal compiler errors).  So I would prefer not to go this route.
Which does _not_ mean that we absolutely will not fix this issue
and try to avoid creating final value replacement that involves
a division/modulus.

But as there exist multiple work-arounds for this issue, a nice and
complete solution is certainly not very high priority.

Richard.


-- 


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

[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use

[bunk at stusta dot de]

--- Comment #21 from bunk at stusta dot de  2007-11-09 16:26 ---
Let's leave the right/wrong discussion and look at it more pragmatically:

Could gcc get some kind of --expensive-libgcc flag that tells gcc that libgcc
calls are a bit more expensive than usually and should be avoided?


-- 

bunk at stusta dot de changed:

   What|Removed |Added

 CC||bunk at stusta dot de


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

[Bug tree-optimization/34043] Missed optimization causing extra loads and stores when using x86_64 builtin function together with aggregate types.

[jsjodin at gcc dot gnu dot org]

--- Comment #3 from jsjodin at gcc dot gnu dot org  2007-11-09 16:17 ---
Created an attachment (id=14518)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14518&action=view)
Assembly code for good code.


-- 


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

[Bug tree-optimization/34043] Missed optimization causing extra loads and stores when using x86_64 builtin function together with aggregate types.

[jsjodin at gcc dot gnu dot org]

--- Comment #2 from jsjodin at gcc dot gnu dot org  2007-11-09 16:16 ---
Created an attachment (id=14517)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14517&action=view)
Assembly code for bad code.


-- 


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

[Bug tree-optimization/34043] Missed optimization causing extra loads and stores when using x86_64 builtin function together with aggregate types.

[jsjodin at gcc dot gnu dot org]

--- Comment #1 from jsjodin at gcc dot gnu dot org  2007-11-09 16:16 ---
Created an attachment (id=14516)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14516&action=view)
Source code to expose the missed optimization


-- 


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

[Bug tree-optimization/34043] New: Missed optimization causing extra loads and stores when using x86_64 builtin function together with aggregate types.

[jsjodin at gcc dot gnu dot org]

Compile the attached file test.cpp with the following flags:
g++ -DNDEBUG -m32 -msse2 -O2 -msse2 -DSHOW_BUG gcc_bug.cpp -S

In the generated code there are useless stores and loads of %xmm0 to
-40(%eps) and -56(%eps).  If the code is compiled without -DSHOW_BUG
it will generate a more optimal version without the extra memory
accesses. See the attached generated files test_bad.s and test_good.s
for the resulting code. This is an old problem existing in 4.1.x.


-- 
   Summary: Missed optimization causing extra loads and stores when
using x86_64 builtin function together with aggregate
types.
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsjodin at gcc dot gnu dot org


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

[Bug fortran/33592] FAIL: gfortran.dg/array_constructor_11.f90 -O1 execution test

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2007-11-09 16:07 
---
My mistake. This comes from a typo in trans.c (a EQ_EXPR instead of an
NE_EXPR). Could you test this patch?


Index: trans.c
===
--- trans.c (revision 129869)
+++ trans.c (working copy)
@@ -829,19 +829,19 @@ internal_realloc (void *mem, size_t size
 {
   if (size < 0)
 runtime_error ("Attempt to allocate a negative amount of memory.");
-  mem = realloc (mem, size);
-  if (!mem && size != 0)
+  res = realloc (mem, size);
+  if (!res && size != 0)
 _gfortran_os_error ("Out of memory");

   if (size == 0)
 return NULL;

-  return mem;
+  return res;
 }  */
 tree
 gfc_call_realloc (stmtblock_t * block, tree mem, tree size)
 {
-  tree msg, res, negative, zero, null_result, tmp;
+  tree msg, res, negative, nonzero, zero, null_result, tmp;
   tree type = TREE_TYPE (mem);

   size = gfc_evaluate_now (size, block);
@@ -868,10 +868,10 @@ gfc_call_realloc (stmtblock_t * block, t
   gfc_add_modify_expr (block, res, fold_convert (type, tmp));
   null_result = fold_build2 (EQ_EXPR, boolean_type_node, res,
 build_int_cst (pvoid_type_node, 0));
-  zero = fold_build2 (EQ_EXPR, boolean_type_node, size,
- build_int_cst (size_type_node, 0));
+  nonzero = fold_build2 (NE_EXPR, boolean_type_node, size,
+build_int_cst (size_type_node, 0));
   null_result = fold_build2 (TRUTH_AND_EXPR, boolean_type_node, null_result,
-zero);
+nonzero);
   msg = gfc_build_addr_expr (pchar_type_node,
 gfc_build_cstring_const ("Out of memory"));
   tmp = fold_build3 (COND_EXPR, void_type_node, null_result,
@@ -881,6 +881,7 @@ gfc_call_realloc (stmtblock_t * block, t

   /* if (size == 0) then the result is NULL.  */
   tmp = fold_build2 (MODIFY_EXPR, type, res, build_int_cst (type, 0));
+  zero = fold_build1 (TRUTH_NOT_EXPR, boolean_type_node, nonzero);
   tmp = fold_build3 (COND_EXPR, void_type_node, zero, tmp,
 build_empty_stmt ());
   gfc_add_expr_to_block (block, tmp);


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
  Component|target  |fortran
 Ever Confirmed|0   |1
   Keywords||wrong-code
  Known to fail||4.3.0
   Last reconfirmed|-00-00 00:00:00 |2007-11-09 16:07:17
   date||
   Target Milestone|--- |4.3.0


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

[Bug libstdc++/34032] -std=c++0x causes undeclared symbols errors on cygwin

[pcarlini at suse dot de]

--- Comment #6 from pcarlini at suse dot de  2007-11-09 15:56 ---
Fixed.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

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


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

[Bug libstdc++/34032] -std=c++0x causes undeclared symbols errors on cygwin

[paolo at gcc dot gnu dot org]

--- Comment #5 from paolo at gcc dot gnu dot org  2007-11-09 15:54 ---
Subject: Bug 34032

Author: paolo
Date: Fri Nov  9 15:54:33 2007
New Revision: 130047

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130047
Log:
2007-11-09  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/34032
* acinclude.m4 ([GLIBCXX_ENABLE_C99], [GLIBCXX_CHECK_C99_TR1]):
Use -std=c++98 instead of the default -std=gnu++98.
* configure: Regenerate.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/acinclude.m4
trunk/libstdc++-v3/configure


-- 


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

[Bug tree-optimization/30604] Unable to coalesce ssa_names and which are marked as MUST COALESCE

[amacleod at redhat dot com]

--- Comment #11 from amacleod at redhat dot com  2007-11-09 15:37 ---
OK, new investigation show that using the smaller testcase firebird2-nav.cc
shows the inliner is misbehaving. 

before inlining  (*041t.profile):

  # BLOCK 2 freq:1
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  D.2709_4 = request_3(D)->req_pool;
  D.2710_5 = (struct blk *) D.2709_4;
  D.2711_6 = request_3(D)->req_transaction;
  D.2712_10 = VIO_get (tdbb_7(D), rpb_8(D), rsb_9(D), D.2711_6, D.2710_5);
  # SUCC: 4 (ab,eh,exec) 3 [100.0%]  (fallthru,exec)

  # BLOCK 3 freq:1
  # PRED: 2 [100.0%]  (fallthru,exec)
  result_12(ab) = (BOOLEAN) D.2712_10;
<...>
  BTR_key (tdbb_7(D), D.2719_20, D.2718_19, D.2717_18, &value, 0B);
  goto ;
  # SUCC: 4 (ab,eh,exec) 5 [100.0%]  (fallthru,exec)

  # BLOCK 4
  # PRED: 2 (ab,eh,exec) 3 (ab,eh,exec)
  # result_1(ab) = PHI 
:;
  <...>

 # BLOCK 5 freq:1
  # PRED: 3 [100.0%]  (fallthru,exec) 4 [100.0%]  (fallthru,exec)
  # result_2 = PHI 
  return result_2;
  # SUCC: EXIT [100.0%]



and after inlining (*046i.inline) we see:



:

:
  D.2882_11 = request_9(D)->req_pool;
  D.2883_12 = (struct blk *) D.2882_11;
  D.2884_13 = request_9(D)->req_transaction;
  D.2885_14 = VIO_get (tdbb_8(D), rpb_3(D), rsb_1(D), D.2884_13, D.2883_12);

:
  result_15(ab) = (BOOLEAN) D.2885_14;
<...>
  BTR_key (tdbb_8(D), D.2892_22, D.2891_21, D.2890_20, &value, 0B);
  goto ;

  # result_24(ab) = PHI 
:;
<...>

:
  # result_23 = PHI 
  if (result_23 != 0)
goto ;
  else
goto ;

:
  return 1;



Basic block 7 is missing a PHI node which should merge result_23 and result_10.
 The result of this missing PHI should then be used in block 5 instead of
result_10.

The way it currently sits, result 10 is live through basic block 3, which makes
it conflict with result_15, and makes the abnormal edges uncoalescable.

Someone familiar with the inliner can probably fix this quickly. I took a quick
look but its a different world in there :-)


-- 

amacleod at redhat dot com changed:

   What|Removed |Added

 CC||jh at suse dot cz


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

[Bug bootstrap/34003] [4.2/4.3 Regression] gcc 4.3.0 unable to bootstrap itself; Unsatisfied symbols: ggc_free

[r dot emrich at de dot tecosim dot com]

--- Comment #15 from r dot emrich at de dot tecosim dot com  2007-11-09 
15:06 ---
Created an attachment (id=14515)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14515&action=view)
preprocessed source


-- 


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

[Bug fortran/34026] Internal compiler error: in gfc_add_modify, at fortran/trans.c:159

[Christian dot Carli at cern dot ch]

--- Comment #7 from Christian dot Carli at cern dot ch  2007-11-09 15:00 
---
Subject: Re:  Internal compiler error: in gfc_add_modify, at
fortran/trans.c:159


   Hello,

   I have now the more recent gfortran binary (even though it is still
version 4.3.0) and can compile this routine without receiving an error
message.
  Thanks a lot,
 Christian

On Nov 9, 2007, at 12:56 AM, fxcoudert at gcc dot gnu dot org wrote:

>
>
> --- Comment #6 from fxcoudert at gcc dot gnu dot org   
> 2007-11-08 23:56 ---
> Hi Christian,
>
> I've tried on i686-darwin, and it works fine with GNU Fortran (GCC)  
> 4.3.0
> 20071017. I will thus close this report as fixed, and I suggest you  
> download
> more recent binaries (either from macresearch, or from
> http://gcc.gnu.org/wiki/GFortranBinaries).
>
> Please reopen the report if by any chance this problem persists  
> with a compiler
> more recent that the date I mentionned above.
>
> Thanks!
>
>
> -- 
>
> fxcoudert at gcc dot gnu dot org changed:
>
>What|Removed |Added
> -- 
> --
>  CC||fxcoudert at gcc  
> dot gnu dot
>||org
>  Status|UNCONFIRMED |RESOLVED
>  Resolution||FIXED
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34026
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
> You reported the bug, or are watching the reporter.


-- 


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

[Bug bootstrap/34003] [4.2/4.3 Regression] gcc 4.3.0 unable to bootstrap itself; Unsatisfied symbols: ggc_free

[r dot emrich at de dot tecosim dot com]

--- Comment #14 from r dot emrich at de dot tecosim dot com  2007-11-09 
14:40 ---
nm ggc-none.o
Symbols from ggc-none.o:

NameValue   Scope  TypeSubspace

$CODE$  | 0|static|data   |$CODE$
$CODE$  | 0|static|data   |$CODE$
$CODE$  | 0|static|data   |$CODE$
$CODE$  | 0|static|data   |$CODE$
$CODE$  | 0|static|data   |$CODE$
$CODE$  | 0|static|data   |$CODE$
$CODE$  | 0|static|data   |$CODE$
free|  |undef |code   |
ggc_alloc_cleared_stat| 0|extern|entry  |$CODE$
ggc_alloc_stat  | 0|extern|entry  |$CODE$
ggc_alloc_typed_stat| 0|extern|entry  |$CODE$
ggc_free| 0|extern|entry  |$CODE$
ggc_realloc_stat| 0|extern|entry  |$CODE$
xcalloc |  |undef |code   |
xmalloc |  |undef |code   |
xrealloc|  |undef |code   |


-- 


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

[Bug debug/34037] [4.1/4.2/4.3 Regression] Bounds for VLAs not emitted into debuginfo

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug debug/34037] [4.1/4.2/4.3 Regression] Bounds for VLAs not emitted into debuginfo

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2007-11-09 13:56 ---
I have tried:
--- dwarf2out.c.jj9 2007-11-05 09:05:44.0 +0100
+++ dwarf2out.c 2007-11-09 14:29:04.0 +0100
@@ -11032,6 +11032,26 @@ add_bound_info (dw_die_ref subrange_die,
   later parameter.  */
if (decl_die != NULL)
  add_AT_die_ref (subrange_die, bound_attr, decl_die);
+   /* Handle gimplified type bounds.  */
+else if (TREE_CODE (bound) == VAR_DECL
+&& DECL_ARTIFICIAL (bound)
+&& !DECL_NAME (bound)
+&& !TREE_STATIC (bound)
+&& current_function_decl
+&& (lookup_decl_loc (bound)
+|| loc_descriptor_from_tree (bound)))
+ {
+   dw_die_ref ctx, decl_die;
+
+   ctx = lookup_decl_die (current_function_decl);
+
+   decl_die = new_die (DW_TAG_variable, ctx, bound);
+   add_AT_flag (decl_die, DW_AT_artificial, 1);
+   add_type_attribute (decl_die, TREE_TYPE (bound), 1, 0, ctx);
+   add_location_or_const_value_attribute (decl_die, bound,
+  DW_AT_location);
+   add_AT_die_ref (subrange_die, bound_attr, decl_die);
+ }
break;
   }

but that still doesn't work, because instantiate_decl etc. hasn't been called
on this, only BLOCK_VARS are treated that way.  So, either we need to put these
artificial vars into BLOCK_VARS, or find a way to also keep the original
non-gimplified expression in TYPE_DOMAIN.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.1.3   |---


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

[Bug target/34042] New: Segfault in mips_cannot_change_mode_class

[fxcoudert at gcc dot gnu dot org]

$ cat foo.i
typedef long double Tal2ldouble __attribute__((aligned (2)));
struct S2015 { Tal2ldouble a; };
extern struct S2015 check2015 ();
extern void checkx2015 (struct S2015);
void test2015 (void) { checkx2015 (check2015 ()); }
boltzmann ~/devel/irun $ cat foo.i
typedef long double Tal2ldouble __attribute__((aligned (2)));
struct S2015 { Tal2ldouble a; };
extern struct S2015 check2015 ();
extern void checkx2015 (struct S2015);
void test2015 (void) { checkx2015 (check2015 ()); }
boltzmann ~/devel/irun $ ./bin/gcc foo.i
gcc: Internal error: Segmentation fault (program cc1)

$ ./bin/gcc foo.i
gcc: Internal error: Segmentation fault (program cc1)

The backtrace for the segfault is:

Program received signal SIGSEGV, Segmentation fault.
0x1014a75c in mips_cannot_change_mode_class (from=TImode, to=DImode,
class=FP_REGS) at ../../trunk/gcc/config/mips/mips.c:8732
8732{
(gdb) bt
#0  0x1014a75c in mips_cannot_change_mode_class (from=TImode, to=DImode,
class=FP_REGS) at ../../trunk/gcc/config/mips/mips.c:8732
#1  0x104b7ef4 in simplify_subreg (outermode=DImode, op=0x40bb280,
innermode=TImode, byte=0) at ../../trunk/gcc/simplify-rtx.c:5021
#2  0x104b8bec in simplify_gen_subreg (outermode=TImode, op=0xa,
innermode=SImode, byte=0) at ../../trunk/gcc/simplify-rtx.c:5218
#3  0x1020d0a0 in emit_move_multi_word (mode=TImode, x=0x50e1660, y=0x40bb280)
at ../../trunk/gcc/expr.c:3265
#4  0x10209e50 in emit_move_insn (x=0x50e1660, y=0x40bb280)
at ../../trunk/gcc/expr.c:3408
#5  0x101aaef4 in copy_to_reg (x=0x40bb280) at ../../trunk/gcc/explow.c:617
#6  0x1018fc6c in operand_subword_force (op=0x40bb280, offset=0, mode=TImode)
at ../../trunk/gcc/emit-rtl.c:1448
#7  0x1020d2b0 in emit_move_multi_word (mode=TImode, x=0x50e1640, y=0x40bb280)
at ../../trunk/gcc/expr.c:3276
#8  0x10209e50 in emit_move_insn (x=0x50e1640, y=0x40bb280)
at ../../trunk/gcc/expr.c:3408
#9  0x101aaef4 in copy_to_reg (x=0x40bb280) at ../../trunk/gcc/explow.c:617
#10 0x1018fc6c in operand_subword_force (op=0x40bb280, offset=0, mode=TImode)
at ../../trunk/gcc/emit-rtl.c:1448


-- 
   Summary: Segfault in mips_cannot_change_mode_class
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
 GCC build triplet: mips-sgi-irix6.5
  GCC host triplet: mips-sgi-irix6.5
GCC target triplet: mips-sgi-irix6.5


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

[Bug testsuite/33775] Memset

[johan dot walles at gmail dot com]

--- Comment #2 from johan dot walles at gmail dot com  2007-11-09 13:13 
---
IMO the proposed change would make the code more readable.


-- 

johan dot walles at gmail dot com changed:

   What|Removed |Added

 CC||johan dot walles at gmail
   ||dot com


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

[Bug middle-end/30442] Expanded array initialization can use memset builtin function

[johan dot walles at gmail dot com]

--- Comment #3 from johan dot walles at gmail dot com  2007-11-09 13:09 
---
This optimization would have made grep 2.5.3 30% faster in a real-world test
case:

http://bugs.debian.org/450649


-- 

johan dot walles at gmail dot com changed:

   What|Removed |Added

 CC||johan dot walles at gmail
   ||dot com


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

[Bug rtl-optimization/34012] [4.3 Regression] Pessimization caused by fwprop

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2007-11-09 13:05 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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