[Bug lto/40739] [LTO] ICE in bp_pack_value, at lto-streamer.c:336

[bje at gcc dot gnu dot org]

--- Comment #1 from bje at gcc dot gnu dot org  2009-07-14 07:06 ---
Confirmed.


-- 

bje at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-07-14 07:06:28
   date||


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

[Bug fortran/33197] Fortran 2008: math functions

[burnus at gcc dot gnu dot org]

--- Comment #26 from burnus at gcc dot gnu dot org  2009-07-14 07:43 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00739.html
- MPC compile-time evaluation of complex tan and sinh/cosh/tanh
- Run-time complex a(sin,cos,tan)(h) with C99 fallback (for finite values only)

TODO:
- Check-in the patch above
- Support infinite arguments in the fallback?
- TAN(X,Y)  (= TAN2(X,Y)) - and fix wrong TAN2 description in the docs
- BESSEL_JN and BESSEL_YN: Transitional form is missing
- NORM2


-- 


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

[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2009-07-14 07:50 ---
Confirm (kind of) with GCC 4.3.2 on i686-linux. With -DBIGMOD one gets:

/tmp/ccmoM1rS.o: In function `tf_ad_splitting_driver_plane_':
t.F90:(.text+0xad): undefined reference to `span.1'
t.F90:(.text+0x15c): undefined reference to `span.0'
t.F90:(.text+0x20b): undefined reference to `span.2'
t.F90:(.text+0x2ba): undefined reference to `span.3'
t.F90:(.text+0x369): undefined reference to `span.4'


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

   GCC host triplet|sparc-sun-solaris2.10   |
   Keywords||wrong-code
  Known to fail||4.3.2 4.4.0


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

[Bug c++/40740] New: [4.4/4.5 regression] template-id forgotten with arg-dep lookup

[jason at gcc dot gnu dot org]

>From https://bugzilla.redhat.com/show_bug.cgi?id=511168:

template
T addsome(T v) {
  return v+1;
}

int addsome(int v) {
  return v+2;
}

int main() {
  int i = 0;
  if (addsome(i) != 2)
return 1;
  if (addsome<>(i) != 1)
return 2;
  return 0;
}

Broken by fix for PR 13549.


-- 
   Summary: [4.4/4.5 regression] template-id forgotten with arg-dep
lookup
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: jason at gcc dot gnu dot org
ReportedBy: jason at gcc dot gnu dot org


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

[Bug c++/40733] No warning is issued when an implicit conversion can lead to a data loss

[photon at seznam dot cz]

--- Comment #4 from photon at seznam dot cz  2009-07-14 08:37 ---
(In reply to comment #3)
> and with  integer promotion happening with simple stuff like a + b,
> some folks will have a hard time to understand that happens which
> is why it is not enabled with -Wall.

The warning is issued only for rare conversions involving a potential data loss
which should always be explicit.

> 
> Plus there are style warnings not included in -Wall.  I really doubt you want
> style warnings enabled with -Wall :).
> 

-Wall should be a real -Wall. Now it does not include important warnings like
those generated by -Wconversion (potential implicit data loss).

GCC should use numerical warning levels. The current -Wall should be renamed
to, e.g., -W3 and the new -Wall option should enable all warnings as the name
says.


-- 


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

[Bug target/40741] New: code size explosion for integer comparison

[carrot at google dot com]

Compile following function with options -Os -mthumb -march=armv5te:

int returnbool(int a, int b)
{
if (a < b)
return 1;
return 0;
}

Gcc 4.5 generates:

lsr r3, r1, #31
asr r2, r0, #31
cmp r0, r1
adc r2, r2, r3
mov r0, r2
mov r3, #1
eor r0, r0, r3
@ sp needed for prologue
bx  lr

while gcc 4.3.1 generates:

push{lr}
mov r3, #1
cmp r0, r1
blt .L2
mov r3, #0
.L2:
mov r0, r3
@ sp needed for prologue
pop {pc}

If we count instructions to do comparison only, they are 7 vs 4. I don't know
if it is faster to replace one branch instruction with 4 alu instructions. It
is definitely a regression for code size.

The long code sequence is generated by expand pass.


-- 
   Summary: code size explosion for integer comparison
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
 GCC build triplet: i686-linux
  GCC host triplet: i686-linux
GCC target triplet: arm-eabi


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

[Bug target/40741] code size explosion for integer comparison

[carrot at google dot com]

--- Comment #1 from carrot at google dot com  2009-07-14 08:41 ---
Created an attachment (id=18191)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18191&action=view)
test case


-- 


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

[Bug fortran/40743] New: [4.5 Regression] ICE when compiling iso_varying_string.f95 at revision 149591

[dominiq at lps dot ens dot fr]

At revision 149591, compiling iso_varying_string.f95 gives the following error:

[ibook-dhum] f90/bug% gfc -c iso_varying_string.f95
iso_varying_string.f95:2548.29:

end module iso_varying_string
 1
Internal Error at (1):
resolve_code(): Bad statement code

Probably due (or uncovered) by revision 149586.

Note that the same error occurs when compiling the codes in pr40440#0 and
pr40440#2.


-- 
   Summary: [4.5 Regression] ICE when compiling
iso_varying_string.f95 at revision 149591
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr


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

[Bug c/40742] New: GCC (for Microblaze) reports internal compiler error

[klaus-christian dot saalfeld at sma dot de]

Note: GCC for Microblaze was used (mb-gcc)


The code that caused the error:

#define APP_ENTRY_POINT_BASE((unsigned int)0x30)
#define APP_ENTRY_POINT_OFFSET  ((unsigned int)0x20)
#define APP_ENTRY_POINT (APP_ENTRY_POINT_BASE + APP_ENTRY_POINT_OFFSET)

int main()
{
(*((void(*)())APP_ENTRY_POINT))();
}


Call and output of compiler:

mb-gcc -c -mno-xl-soft-mul -mxl-pattern-compare -mcpu=v7.10.d
-I../../microblaze_0_sw_platform/microblaze_0/include -xl-mode-executable -g
-O0 -ostarter.o ../starter.c
../starter.c: In function 'main':
../starter.c:18: error: unrecognizable insn:
(call_insn 8 7 9 1 ../starter.c:11 (parallel [
(call (mem:SI (const_int 5242880 [0x50]) [0 S4 A32])
(const_int 24 [0x18]))
(clobber (reg:SI 15 r15))
]) -1 (nil)
(nil)
(nil))
../starter.c:18: internal compiler error: in extract_insn, at recog.c:2084
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make: *** [starter.o] Error 1
Build complete for project starter


-- 
   Summary: GCC (for Microblaze) reports internal compiler error
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: klaus-christian dot saalfeld at sma dot de


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

[Bug target/40730] redundant memory load

[carrot at google dot com]

--- Comment #4 from carrot at google dot com  2009-07-14 09:14 ---
In TREE level, the two stores are different statements. Only after register
allocation, the two stores get same register and make the load redundant.

try_crossjump_bb tries to find same instruction sequence in all predecessors of
a basic block bb, and move that code sequence to head of bb. It is triggered by
this function, and the store is moved just before the load.

I tried -fgcse-las but it couldn't do the work.

(In reply to comment #2)
> -fgcse-las should do the trick.  Note that PRE would do this kind of
> optimization on the tree-level, but it is disabled with -Os (so is gcse).
> 
> :
>   D.1614_2 = p2_1(D)->front;
>   p1_3(D)->head = D.1614_2;
>   goto ;
> 
> :
>   D.1616_8 = D.1615_4->next;
>   p1_3(D)->head = D.1616_8;
> 
> :
>   D.1615_4 = p1_3(D)->head;
> 


-- 


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

[Bug target/40730] redundant memory load

[steven at gcc dot gnu dot org]

--- Comment #5 from steven at gcc dot gnu dot org  2009-07-14 09:18 ---
As you said, try_crossjump_bb tries to find the same instruction sequence in
*all* predecessors of a basic block bb. Meaning that the load must have been
redundant even before cross jumping occurred.

If you are right, and this redundancy is not exposed until after register
allocation, then this may be another case that postreload-gcse should handle
(but probably does not).

There are a couple of bugs about the need for a more powerful postreload-gcse.
We should perhaps group them (in a meta-bug for example) and make a plan for a
fix...


-- 


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

[Bug target/40730] redundant memory load

[steven at gcc dot gnu dot org]

--- Comment #6 from steven at gcc dot gnu dot org  2009-07-14 09:20 ---
Carrot, can you please try this test case with my patch
"crossjump_abstract.diff" from Bug 20070 applied?


-- 


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

[Bug target/40735] [4.3/4.4 regression] memory hog compiling big functions with -fPIE

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-07-14 09:20 ---
I cannot compile the attached testcase.

gcc-4.2 -S -o /dev/null -g -fstack-protector -fPIE -Os test_node.i -std=c99
In file included from ../nih/test_alloc.h:32,
 from ../nih/test.h:36,
 from tests/test_node.c:23:
../nih/list.h:110: warning: declaration does not declare anything
In file included from tests/test_node.c:40:
./parse.h:71: warning: declaration does not declare anything
tests/test_node.c: In function ‘test_start_tag’:
tests/test_node.c:211: error: ‘ParseStack’ has no member named ‘node’
tests/test_node.c:251: error: ‘ParseStack’ has no member named ‘node’
tests/test_node.c:297: error: ‘ParseStack’ has no member named ‘data’
tests/test_node.c:297: error: ‘ParseStack’ has no member named ‘data’
tests/test_node.c:365: error: ‘ParseStack’ has no member named ‘node’
tests/test_node.c:422: error: ‘ParseStack’ has no member named ‘data’
tests/test_node.c:422: error: ‘ParseStack’ has no member named ‘data’
tests/test_node.c: In function ‘test_object_functions’:
tests/test_node.c:1256: error: ‘NihListEntry’ has no member named ‘str’
tests/test_node.c:1256: error: ‘NihListEntry’ has no member named ‘str’
...


-- 


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

[Bug lto/40739] [LTO] ICE in bp_pack_value, at lto-streamer.c:336

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-07-14 09:22 ---
Recent regression, revision 149585 works.


-- 


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

[Bug target/40741] code size explosion for integer comparison

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-07-14 09:22 ---
Maybe caused by the cond-optab rework.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org


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

[Bug target/40742] GCC (for Microblaze) reports internal compiler error

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-07-14 09:23 ---
GCC 4.1.1 is no longer maintained, please update to at least GCC 4.3.3 and
try there.  Also always paste the output of gcc -v.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
  Component|c   |target


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

[Bug c++/40733] No warning is issued when an implicit conversion can lead to a data loss

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2009-07-14 09:24 ---
-Wconversion hits extremely often, it is definitely not a warning that can or
should be enabled in -Wall, nor in -W.


-- 


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

[Bug c/40742] GCC (for Microblaze) reports internal compiler error

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2009-07-14 09:26 ---
Microblaze is not an FSF GCC version.

Please report this bug to the distributor of mb-gcc (Google says this is
http://www.petalogix.com/resources/downloads/mb-gcc). and kindly request them
to adjust the bug-reporting URL also.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
  Component|target  |c
 Resolution||INVALID


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

[Bug target/40741] code size explosion for integer comparison

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-07-14 09:27:35
   date||


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

[Bug lto/40739] [LTO] ICE in bp_pack_value, at lto-streamer.c:336

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-07-14 09:28 ---
Hm, or rather it works for me (on x86_64 w/ and w/o -m32).


-- 


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

[Bug rtl-optimization/37889] [4.3 Regression] SEGV, conditional execution proactively executed the false arm.

[rguenth at gcc dot gnu dot org]

--- Comment #21 from rguenth at gcc dot gnu dot org  2009-07-14 09:33 
---
Subject: Bug 37889

Author: rguenth
Date: Tue Jul 14 09:32:55 2009
New Revision: 149620

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149620
Log:
2009-07-14  Richard Guenther  

Backport from mainline
2009-02-05  Paolo Bonzini  

PR rtl-optimization/39110
* rtlanal.c (rtx_addr_can_trap_p_1): Shortcut unaligned
addresses, not aligned ones.

2009-02-04  Paolo Bonzini  
Hans-Peter Nilsson  

PR rtl-optimization/37889
* rtlanal.c (rtx_addr_can_trap_p_1): Add offset and size arguments.
Move offset handling from PLUS to before the switch.  Use new
arguments when considering SYMBOL_REFs too.
(rtx_addr_can_trap_p): Pass dummy offset and size.
(enum may_trap_p_flags): Remove.
(may_trap_p_1): Pass size from MEM_SIZE.

PR rtl-optimization/38921
* loop-invariant.c (find_invariant_insn): Use may_trap_or_fault_p.
* rtl.h (may_trap_after_code_motion_p): Delete prototype.
* rtlanal.c (may_trap_after_code_motion_p): Delete.
(may_trap_p, may_trap_or_fault_p): Pass 0/1 as flags.

Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/loop-invariant.c
branches/gcc-4_3-branch/gcc/rtl.h
branches/gcc-4_3-branch/gcc/rtlanal.c


-- 


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

[Bug rtl-optimization/39110] [4.4 Regression] Revision 143939 breaks bootstrap on Linux/ia64

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2009-07-14 09:33 
---
Subject: Bug 39110

Author: rguenth
Date: Tue Jul 14 09:32:55 2009
New Revision: 149620

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149620
Log:
2009-07-14  Richard Guenther  

Backport from mainline
2009-02-05  Paolo Bonzini  

PR rtl-optimization/39110
* rtlanal.c (rtx_addr_can_trap_p_1): Shortcut unaligned
addresses, not aligned ones.

2009-02-04  Paolo Bonzini  
Hans-Peter Nilsson  

PR rtl-optimization/37889
* rtlanal.c (rtx_addr_can_trap_p_1): Add offset and size arguments.
Move offset handling from PLUS to before the switch.  Use new
arguments when considering SYMBOL_REFs too.
(rtx_addr_can_trap_p): Pass dummy offset and size.
(enum may_trap_p_flags): Remove.
(may_trap_p_1): Pass size from MEM_SIZE.

PR rtl-optimization/38921
* loop-invariant.c (find_invariant_insn): Use may_trap_or_fault_p.
* rtl.h (may_trap_after_code_motion_p): Delete prototype.
* rtlanal.c (may_trap_after_code_motion_p): Delete.
(may_trap_p, may_trap_or_fault_p): Pass 0/1 as flags.

Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/loop-invariant.c
branches/gcc-4_3-branch/gcc/rtl.h
branches/gcc-4_3-branch/gcc/rtlanal.c


-- 


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

[Bug rtl-optimization/38921] [4.3 Regression] NULL access in delay-slot

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2009-07-14 09:33 
---
Subject: Bug 38921

Author: rguenth
Date: Tue Jul 14 09:32:55 2009
New Revision: 149620

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149620
Log:
2009-07-14  Richard Guenther  

Backport from mainline
2009-02-05  Paolo Bonzini  

PR rtl-optimization/39110
* rtlanal.c (rtx_addr_can_trap_p_1): Shortcut unaligned
addresses, not aligned ones.

2009-02-04  Paolo Bonzini  
Hans-Peter Nilsson  

PR rtl-optimization/37889
* rtlanal.c (rtx_addr_can_trap_p_1): Add offset and size arguments.
Move offset handling from PLUS to before the switch.  Use new
arguments when considering SYMBOL_REFs too.
(rtx_addr_can_trap_p): Pass dummy offset and size.
(enum may_trap_p_flags): Remove.
(may_trap_p_1): Pass size from MEM_SIZE.

PR rtl-optimization/38921
* loop-invariant.c (find_invariant_insn): Use may_trap_or_fault_p.
* rtl.h (may_trap_after_code_motion_p): Delete prototype.
* rtlanal.c (may_trap_after_code_motion_p): Delete.
(may_trap_p, may_trap_or_fault_p): Pass 0/1 as flags.

Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/loop-invariant.c
branches/gcc-4_3-branch/gcc/rtl.h
branches/gcc-4_3-branch/gcc/rtlanal.c


-- 


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

[Bug rtl-optimization/37889] [4.3 Regression] SEGV, conditional execution proactively executed the false arm.

[rguenth at gcc dot gnu dot org]

--- Comment #22 from rguenth at gcc dot gnu dot org  2009-07-14 09:33 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail|4.3.0   |4.3.0 4.3.3
  Known to work|4.2.3 4.4.0 |4.2.3 4.3.4 4.4.0
 Resolution||FIXED


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

[Bug rtl-optimization/38921] [4.3 Regression] NULL access in delay-slot

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2009-07-14 09:34 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail|4.3.4   |4.3.3
  Known to work|4.4.0   |4.3.4 4.4.0
 Resolution||FIXED


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

[Bug fortran/40743] [4.5 Regression] ICE when compiling iso_varying_string.f95 at revision 149591

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-07-14 09:46 ---
> Probably due (or uncovered) by revision 149586

That's: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149586
2009-07-13  Janus Weil  
PR fortran/40646


-- 


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

[Bug fortran/40743] [4.5 Regression] ICE when compiling iso_varying_string.f95 at revision 149591

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2009-07-14 09:47 ---
> [ibook-dhum] f90/bug% gfc -c iso_varying_string.f95

I assume that's the file: http://www.fortran.com/iso_varying_string.f95


-- 


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

[Bug target/40741] code size explosion for integer comparison

[bonzini at gnu dot org]

--- Comment #3 from bonzini at gnu dot org  2009-07-14 10:08 ---
One side problem here is that

mov r0, r2
mov r3, #1
eor r0, r0, r3

could become

mov r0, #1
eor r0, r0, r2


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2009-07-14 09:27:35 |2009-07-14 10:08:06
   date||


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

[Bug target/40735] [4.3/4.4 regression] memory hog compiling big functions with -fPIE

[doko at ubuntu dot com]

--- Comment #3 from doko at ubuntu dot com  2009-07-14 10:31 ---
my bad, should be -std=gnu99 instead: gcc-4.2 -S -o /dev/null -g
-fstack-protector -fPIE -Os test_node.i -std=gnu99


-- 


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

[Bug target/40741] code size explosion for integer comparison

[bonzini at gnu dot org]

--- Comment #4 from bonzini at gnu dot org  2009-07-14 10:34 ---
... and besides that, we do not take rtx_costs into account.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bonzini at gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-07-14 10:08:06 |2009-07-14 10:34:21
   date||


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

[Bug rtl-optimization/34849] Missed autoincrement opportunities due to a different basic block structure.

[ramana at gcc dot gnu dot org]

-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
   Last reconfirmed|2009-04-30 13:18:25 |2009-07-14 10:47:37
   date||


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

[Bug target/39715] [4.5 Regression][cond-optab] extra sign extensions on Thumb

[bonzini at gnu dot org]

--- Comment #2 from bonzini at gnu dot org  2009-07-14 10:51 ---
Here combine simplifies the zero extension from

(lshiftrt:SI (ashift:SI (subreg:SI (reg:QI 138) 0)
(const_int 24 [0x18]))
(const_int 24 [0x18]))

to (ne:SI (subreg:SI (reg:QI 138)).  From there it cannot derive anymore that
nonzero_bits of the operand is 1 and thus the NE is redundant.

But shouldn't the subreg actually be a ZERO_EXTEND?


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu dot
   ||org


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

[Bug fortran/40743] [4.5 Regression] ICE when compiling iso_varying_string.f95 at revision 149591

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2009-07-14 10:54 ---
> I assume that's the file: http://www.fortran.com/iso_varying_string.f95

yes.


-- 


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

[Bug tree-optimization/40744] New: SRA scalarizes dead objects, single-use objects

[rguenth at gcc dot gnu dot org]

struct X { int i; int j; };
void foo(void)
{
  struct X x;
  x.i = 1;
  x.j = 2;
}

early SRA produces

foo ()
{
  int x$j;
  int x$i;
  struct X x;

:
  x$i_3 = 1;
  x$j_2 = 2;
  return;


which is unnecessary work as DCE will end up removing the stores anyway.
We should avoid doing useless work here (and thus not skew statistics
compared to when somebody inserts DCE before ESRA).  At least if it is
easy to do.

Likewise for

struct X { int i; int j; };
int foo(struct X x)
{
  return x.i;
}

early SRA produces an extra register copy with no benefit.

foo (struct X x)
{
  int x$i;
  int D.1606;

:
  x$i_3 = x.i;
  D.1606_1 = x$i_3;
  return D.1606_1;

}

both cases, only loads from a structure or only stores to a structure
probably should be simply skipped.


-- 
   Summary: SRA scalarizes dead objects, single-use objects
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug target/40735] [4.3/4.4 regression] memory hog compiling big functions with -fPIE

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-07-14 11:31 ---
This is likely caused by the DF merge.  There are numerous bugs about this
already and nothing really can be done here.

Btw, my numbers are

rguent...@murzim:/tmp> ~/bin/maxmem2.sh gcc-4.4 -S -o /dev/null -g
-fstack-protector -fPIE -Os test_node.i -std=gnu99
total: 744108 kB
rguent...@murzim:/tmp> ~/bin/maxmem2.sh gcc-4.3 -S -o /dev/null -g
-fstack-protector -fPIE -Os test_node.i -std=gnu99
total: 719836 kB
rguent...@murzim:/tmp> ~/bin/maxmem2.sh gcc-4.2 -S -o /dev/null -g
-fstack-protector -fPIE -Os test_node.i -std=gnu99
total: 459757 kB

Thus not 1.5GB but 750MB vs 450MB.

rguent...@murzim:/tmp> ~/bin/maxmem2.sh gcc-4.4 -S -o /dev/null -fPIE -Os
test_node.i -std=gnu99
total: 743380 kB
rguent...@murzim:/tmp> ~/bin/maxmem2.sh gcc-4.4 -S -o /dev/null -Os test_node.i
-std=gnu99
total: 630756 kB

the -fPIE effect itself is even less recognizable.


-- 


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

[Bug rtl-optimization/40710] [4.3.4 regression] Linux kernel miscompiled for sh4-linux

[ebotcazou at gcc dot gnu dot org]

-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |major
  Component|target  |rtl-optimization
  GCC build triplet|i686-pc-linux-gnu   |
   GCC host triplet|i686-pc-linux-gnu   |
Summary|SH: gcc-4.3.4 miscompiles   |[4.3.4 regression] Linux
   |linux kernel for sh4-linux  |kernel miscompiled for sh4-
   ||linux
   Target Milestone|--- |4.3.4


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

[Bug rtl-optimization/40710] [4.3 Regression] Linux kernel miscompiled for sh4-linux

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-07-14 12:32 ---
If 4.3.3 worked please add that release in the known-to-work field.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.3.4
Summary|[4.3.4 regression] Linux|[4.3 Regression] Linux
   |kernel miscompiled for sh4- |kernel miscompiled for sh4-
   |linux   |linux


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

[Bug target/39715] [4.5 Regression][cond-optab] extra sign extensions on Thumb

[bonzini at gnu dot org]

--- Comment #3 from bonzini at gnu dot org  2009-07-14 12:56 ---
Richard, is your testcase also a regression?  In that case the culprit is
mostly

#if 0
  /* Disabled to avoid exponential mutual recursion between nonzero_bits
 and num_sign_bit_copies.  */
  if (num_sign_bit_copies (XEXP (x, 0), GET_MODE (x))
  == GET_MODE_BITSIZE (GET_MODE (x)))
nonzero = 1;
#endif

in rtlanal.c that makes GCC unable to see through

9 r142:SI=-ltu(r139:SI,r138:SI)
   10 r141:SI=-r142:SI

produced by

  emit_insn (gen_cstoresi_nltu_thumb1 (scratch, op3, operands[2]));
  emit_insn (gen_negsi2 (operands[0], scratch));


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bonzini at gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-05-21 10:49:12 |2009-07-14 12:56:22
   date||


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

[Bug middle-end/40745] New: [4.5 regression] Revision 149624 caused x86-64 failures

[hjl dot tools at gmail dot com]

Revision 149624:

http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg00505.html

caused:

FAIL: gcc.target/x86_64/abi/test_3_element_struct_and_unions.c compilation, 
-O0  (internal compiler error)
FAIL: gcc.target/x86_64/abi/test_basic_array_size_and_align.c compilation,  -O0
 (internal compiler error)


-- 
   Summary: [4.5 regression] Revision 149624 caused x86-64 failures
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug fortran/40743] [4.5 Regression] ICE when compiling iso_varying_string.f95 at revision 149591

[janus at gcc dot gnu dot org]

--- Comment #4 from janus at gcc dot gnu dot org  2009-07-14 13:20 ---
Here is a minimal test case:

  implicit none

  type :: varying_string
  end type

  interface assignment(=)
 procedure op_assign_VS_CH
  end interface

contains

  subroutine op_assign_VS_CH (var, exp)
type(varying_string), intent(out) :: var
character(LEN=*), intent(in)  :: exp
  end subroutine

  subroutine split_VS
type(varying_string) :: string
call split_CH(string)
  end subroutine

  subroutine split_CH (string)
type(varying_string) :: string
string = ""
  end subroutine

end


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-07-14 13:20:29
   date||


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

[Bug fortran/40643] maxloc/minloc: Wrong result for NaN at position 1

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2009-07-14 13:26 ---
Created an attachment (id=18192)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18192&action=view)
gcc45-pr40643.patch

Slightly adjusted patch, so that even when array size isn't known compile time
constant it can avoid expensive runtime tests in the loop.


-- 


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

[Bug fortran/40643] maxloc/minloc: Wrong result for NaN at position 1

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2009-07-14 13:31 ---
Created an attachment (id=18193)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18193&action=view)
gcc45-pr40643.patch

And now a patch which uses two loops instead of one if needed for performance
(in the honor nans case or when mask is used).  The first loop will stop after
changing pos the first time, the second loop then can just use val < limit
comparison.

E.g. on
subroutine bar(a, n)
  real, allocatable :: a(:)
  integer :: n
end subroutine
program main
  implicit none
  interface bar
subroutine bar(a, n)
  real, allocatable :: a(:)
  integer :: n
end subroutine
  end interface
  integer :: n
  real, allocatable :: a(:)
  integer :: i

  allocate (a(100))
  call random_number(a)
  do i=1, 1000
n = minloc(a, dim=1)
call bar(a, n)
  end do
end program main

this patch shows very noticeable difference both for -O3 -ffast-math
-funroll-loops and for -O3 -funroll-loops.
If you think this is the way we should go, I can change also the inline
minval/maxval version and attempt to change the library routines as well.


-- 


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

[Bug fortran/40743] [4.5 Regression] ICE when compiling iso_varying_string.f95 at revision 149591

[janus at gcc dot gnu dot org]

--- Comment #5 from janus at gcc dot gnu dot org  2009-07-14 13:38 ---
Backtrace for the code in comment #4:

#0  resolve_code (code=0x2f26580, ns=0x2f25520) at
/home/jweil/gcc45/trunk/gcc/fortran/resolve.c:7168
#1  0x00512703 in resolve_codes (ns=0x2f25520) at
/home/jweil/gcc45/trunk/gcc/fortran/resolve.c:10966
#2  0x00512640 in resolve_codes (ns=0x2f1f4f0) at
/home/jweil/gcc45/trunk/gcc/fortran/resolve.c:10956
#3  0x005127ef in gfc_resolve (ns=0x2f1f4f0) at
/home/jweil/gcc45/trunk/gcc/fortran/resolve.c:10990
#4  0x00506280 in gfc_parse_file () at
/home/jweil/gcc45/trunk/gcc/fortran/parse.c:3924
#5  0x0053af15 in gfc_be_parse_file (set_yydebug=0) at
/home/jweil/gcc45/trunk/gcc/fortran/f95-lang.c:241
#6  0x0098408d in compile_file () at
/home/jweil/gcc45/trunk/gcc/toplev.c:1026
#7  0x00986232 in do_compile () at
/home/jweil/gcc45/trunk/gcc/toplev.c:2346
#8  0x00986302 in toplev_main (argc=2, argv=0x7fff2fc770a8) at
/home/jweil/gcc45/trunk/gcc/toplev.c:2391
#9  0x005ab99b in main (argc=2, argv=0x7fff2fc770a8) at
/home/jweil/gcc45/trunk/gcc/main.c:35


-- 


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

[Bug fortran/40743] [4.5 Regression] ICE when compiling iso_varying_string.f95 at revision 149591

[janus at gcc dot gnu dot org]

--- Comment #6 from janus at gcc dot gnu dot org  2009-07-14 13:50 ---
The error goes away with the following patch:

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 149623)
+++ gcc/fortran/resolve.c   (working copy)
@@ -9845,20 +9845,6 @@ resolve_symbol (gfc_symbol *sym)
   if (sym->formal_ns && sym->formal_ns != gfc_current_ns)
 gfc_resolve (sym->formal_ns);

-  /* Make sure the formal namespace is present.  */
-  if (sym->formal && !sym->formal_ns)
-{
-  gfc_formal_arglist *formal = sym->formal;
-  while (formal && !formal->sym)
-   formal = formal->next;
-
-  if (formal)
-   {
- sym->formal_ns = formal->sym->ns;
- sym->formal_ns->refs++;
-   }
-}
-
   /* Check threadprivate restrictions.  */
   if (sym->attr.threadprivate && !sym->attr.save && !sym->ns->save_all
   && (!sym->attr.in_common

However, I don't quite see the connection yet. Also, this will regress e.g. on
proc_ptr_22.f90 (which is the reason why I added this hunk for PR40646).


-- 


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

[Bug c++/37276] Trouble with some (C99?) math builtins and namespace std

[paolo dot carlini at oracle dot com]

--- Comment #11 from paolo dot carlini at oracle dot com  2009-07-14 14:00 
---
Jason, this is the issue, you are in CC. Actually, using declarations are not
directly involved - I was misremembering - are only part of my ugly workaround,
and, beware, I menace to use it... ;)


-- 


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

[Bug c++/40733] No warning is issued when an implicit conversion can lead to a data loss

[manu at gcc dot gnu dot org]

--- Comment #6 from manu at gcc dot gnu dot org  2009-07-14 14:04 ---
There is a FAQ for the new Wconversion:

http://gcc.gnu.org/wiki/NewWconversion#faq

It should answer users' concerns.

As for Wall, we have users requesting less warnings from Wall and users
requesting more. We try to find a balance. But you are free to suggest that
existing warnings be moved to Wall or Wextra. However, first try compiling a
few big projects (like the kernel, QT libraries and KDE) and check that the
suggested warning only finds real bugs. Thanks.


-- 

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=40733

[Bug middle-end/40745] [4.5 regression] Revision 149624 caused x86-64 failures

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-07-14 14:08 ---
Subject: Bug 40745

Author: rguenth
Date: Tue Jul 14 14:08:09 2009
New Revision: 149627

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149627
Log:
2009-07-14  Richard Guenther  

PR middle-end/40745
* cfgexpand.c (partition_stack_vars): Do not bother to update
alias information when not optimizing.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c


-- 


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

[Bug middle-end/40745] [4.5 regression] Revision 149624 caused x86-64 failures

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-07-14 14:08 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug target/40487] Extra zero extensions produced for ARM.

[rearnsha at gcc dot gnu dot org]

--- Comment #11 from rearnsha at gcc dot gnu dot org  2009-07-14 14:53 
---
The following define_split works for this specific case, but it needs to be
made more generic (handling IOR and HImode variants).

It also needs reworking for big-endian -- that needs (subreg...3).

(define_split
  [(set (match_operand:SI 0 "s_register_operand" "")
(xor:SI (and:SI (ashift:SI (match_operand:SI 1 "s_register_operand" "")
   (match_operand:SI 2 "const_int_operand" ""))
(match_operand:SI 3 "const_int_operand" ""))
(zero_extend:SI (subreg:QI (match_dup 1) 0]
  "TARGET_32BIT && INTVAL (operands[3]) == (255 & (255 << (INTVAL
(operands[2]"
  [(set (match_dup 0) (xor:SI (ashift:SI (match_dup 1) (match_dup 2))
  (match_dup 1)))
   (set (match_dup 0) (and:SI (match_dup 0) (const_int 255)))]
  "")


-- 


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

[Bug c++/40746] New: namespace-qualified lookup misses some ambiguities

[jason at gcc dot gnu dot org]

namespace A
{
  int i;// { dg-error "i" }
}
using namespace A;
namespace B
{
  namespace B2
  {
int i;  // { dg-error "i" }
  }
  using namespace B2;
}
using namespace B;

int j = ::i;// { dg-error "ambiguous" }

The code currently doesn't look into B2 because it found something in A.


-- 
   Summary: namespace-qualified lookup misses some ambiguities
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: jason at gcc dot gnu dot org
ReportedBy: jason at gcc dot gnu dot org


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

[Bug c++/40746] namespace-qualified lookup misses some ambiguities

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-07-14 14:55:48
   date||


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

[Bug debug/40705] [4.5 Regression] ICE in gen_type_die_with_usage, at dwarf2out.c:15117

[dodji at gcc dot gnu dot org]

--- Comment #5 from dodji at gcc dot gnu dot org  2009-07-14 15:02 ---
Subject: Bug 40705

Author: dodji
Date: Tue Jul 14 15:01:55 2009
New Revision: 149628

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149628
Log:
2009-07-14  Dodji Seketeli  

gcc/ChangeLog:
PR debug/40705
PR c++/403057
* dwarf2.out.c (gen_type_die_with_usage): Added comment.

gcc/cp/ChangeLog:
PR debug/40705
PR c++/403057
* decl2.c (grokfield): Don't call set_underlying_type on typedef
decls that are type names.

gcc/testsuite/ChangeLog:
PR debug/40705
PR c++/403057
* g++.dg/debug/dwarf2/typedef1.C: New test.
* g++.dg/other/typedef3.C: Likewise.


Added:
trunk/gcc/testsuite/g++.dg/debug/dwarf2/typedef1.C
trunk/gcc/testsuite/g++.dg/other/typedef3.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/40733] No warning is issued when an implicit conversion can lead to a data loss

[photon at seznam dot cz]

--- Comment #7 from photon at seznam dot cz  2009-07-14 15:13 ---
(In reply to comment #5)
> -Wconversion hits extremely often, it is definitely not a warning that can or
> should be enabled in -Wall, nor in -W.
> 

The fact that "it hits often" should not be an argument against including it in
the warning level -Wall. Implicit conversion to a smaller type occurs
infrequently and should always be explicit to avoid hard to find bugs.


-- 


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

[Bug debug/40705] [4.5 Regression] ICE in gen_type_die_with_usage, at dwarf2out.c:15117

[dodji at gcc dot gnu dot org]

--- Comment #6 from dodji at gcc dot gnu dot org  2009-07-14 15:19 ---
Fixed in gcc 4.5


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/40357] [4.5 Regression] compiler hang for C++ code

[dodji at gcc dot gnu dot org]

--- Comment #4 from dodji at gcc dot gnu dot org  2009-07-14 15:29 ---
Fixed by the patch for PR debug/40705


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/40733] No warning is issued when an implicit conversion can lead to a data loss

[photon at seznam dot cz]

--- Comment #8 from photon at seznam dot cz  2009-07-14 15:31 ---
(In reply to comment #6)
> 
> As for Wall, we have users requesting less warnings from Wall and users
> requesting more. We try to find a balance. But you are free to suggest that
> existing warnings be moved to Wall or Wextra. 

There should be no discussion about adding or removing anything from the -Wall
level. It should include all warnings available. The current -Wall should be
renamed to something like -W3 to prevent misleading users. Each warning should
be assigned a warning level depending on the severity. The user should normally
only need to specify the desired warning level. -Wall should be used only
occasionally to make sure no warning is missed.


> However, first try compiling a
> few big projects (like the kernel, QT libraries and KDE) and check that the
> suggested warning only finds real bugs. Thanks.
> 

Are you suggesting that -Wconversion does not find real bugs?


-- 


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

[Bug c/40747] New: [4.4/4.5 Regression] wrong code for int-is-in-range test at -O1 and above

[zsojka at seznam dot cz]

Tested with:

trunk r149624
# ./gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++
--prefix=/mnt/svn/gcc-trunk/build/
Thread model: posix
gcc version 4.5.0 20090714 (experimental) (GCC)

and gentoo's 4.4.0, 4.5_alpha20090709

The following code is miscompiled

// command line: gcc tst.c -c -o tst.o -O1
// or: with -m32
int f3(int i) {
return (i < 4 && i >= 0) ? i : 4;
}


Resulting (relevant) asm is:

f3:
.LFB0:
.cfi_startproc
cmpl$4, %edi
movl$4, %eax
cmovle  %edi, %eax
ret
.cfi_endproc


For the following code:

// command line: gcc tst.c -c -o tst.o -O1
// or: with -m32
#include 

int f3(int i) {
return (i < 4 && i >= 0) ? i : 4;
}

int main() {
printf("%d %d %d\n", f3(-1), f3(2), f3(5));
}

Result is "-1 2 4", but it should be "4 2 4" (as it is with -O0)


-- 
   Summary: [4.4/4.5 Regression] wrong code for int-is-in-range test
at -O1 and above
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu


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

[Bug tree-optimization/40744] SRA scalarizes dead objects, single-use objects

[jamborm at gcc dot gnu dot org]

--- Comment #1 from jamborm at gcc dot gnu dot org  2009-07-14 16:32 ---
OK, I have now added this to my todo list.  The simple tweaks would be
simple.  On  the other hand, if  DCE is clever, it  still might figure
out a structure is dead at  some code paths while I don't even attempt
to and still remove some statements.

> only loads from a structure or only stores to a structure
> probably should be simply skipped.

I've been thinking about not scalarizing accesses that occur only once
too.  Thinking about it more,  I wonder whether requiring at least one
load and  a store or  at least  two loads is  a good idea.   (Load and
store for the case where we  store something to an aggregate first and
then load it and  two loads for the case when we  can finally get away
with one.)

I'll try to come up with something this simple quickly and hopefully
we can benchmark it over the weekend or so...


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|mjambor at suse dot cz  |jamborm at gcc dot gnu dot
   ||org
 AssignedTo|unassigned at gcc dot gnu   |jamborm at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-07-14 16:32:37
   date||


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

[Bug c/40747] [4.4/4.5 Regression] wrong code for int-is-in-range test at -O1 and above

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2009-07-14 16:35 ---
Created an attachment (id=18194)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18194&action=view)
preprocessed source

most of that file is content of included 


-- 


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

[Bug c++/40733] No warning is issued when an implicit conversion can lead to a data loss

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2009-07-14 16:47 ---
(In reply to comment #8)
>  The current -Wall should be
> renamed to something like -W3 to prevent misleading users. 

It only misleading users who don't read the documentation.  The all part is
described in the documentation as:
"This enables all the warnings about constructions that some users consider
questionable, and that are easy to avoid (or modify to prevent the warning),
even in conjunction with macros. "

So the all is accurate in the sense it is all useful warnings; but it is not
all warnings.  

Most folks don't want -Wformat-nonliteral and -Wformat-security in their
warning set.  Or even -Wmissing-include-dirs or even -Winvalid-pch which will
warn if you have a PCH done for -O0 and one done for -O2 and you are compiling
at -O2 (and yes this happens all the time).

So your definition of -Wall is not very useful at all and will be even more
misleading to users or why the warnings are happening.


-- 


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

[Bug fortran/40743] [4.5 Regression] ICE when compiling iso_varying_string.f95 at revision 149591

[janus at gcc dot gnu dot org]

--- Comment #7 from janus at gcc dot gnu dot org  2009-07-14 16:53 ---
Here is a much better patch:

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 149623)
+++ gcc/fortran/resolve.c   (working copy)
@@ -9842,7 +9842,8 @@ resolve_symbol (gfc_symbol *sym)
   formal_arg_flag = 0;

   /* Resolve formal namespaces.  */
-  if (sym->formal_ns && sym->formal_ns != gfc_current_ns)
+  if (sym->formal_ns && sym->formal_ns != gfc_current_ns
+  && !sym->attr.contained)
 gfc_resolve (sym->formal_ns);

   /* Make sure the formal namespace is present.  */

At least this works for iso_varying_string.f90 and the procptr test cases.
Starting a full regtest now.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-07-14 13:20:29 |2009-07-14 16:53:59
   date||


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

[Bug c/40748] New: simple switch/case, if/else and arithmetics result in different code

[zsojka at seznam dot cz]

Tested r149624, 4.4.0 and 4.3.3

# ./gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++
--prefix=/mnt/svn/gcc-trunk/build/
Thread model: posix
gcc version 4.5.0 20090714 (experimental) (GCC)

4.4.0 and 4.5 have better behaviour in the case of "switch"

The following code:
---
unsigned f1(unsigned i)
{
switch (i) {
case 0: return 0;
case 1: return 1;
case 2: return 2;
case 3: return 3;
default: return 4;
}
}

unsigned f2(unsigned i)
{
if (i == 0) return 0;
if (i == 1) return 1;
if (i == 2) return 2;
if (i == 3) return 3;
return 4;
}

unsigned f3(unsigned i)
{
return i < 4 ? i : 4;
}
---

f1(), f2() and f3() do the same, but the resulting code differs a lot.


-- 
   Summary: simple switch/case, if/else and arithmetics result in
different code
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu


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

[Bug c++/40749] New: g++ doesnt report missing return if return is of type const

[mfribeiro at gmail dot com]

This code below wont generate a warning for function a(). Compiled with -Wall.
If you remove the const from the return, it will work.


class A {
public:
};

const A a() {
}

int main() {
  A b = a();
}



-- 
   Summary: g++ doesnt report missing return if return is of type
const 
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mfribeiro at gmail dot com
 GCC build triplet: x86_64 GNU/Linux
  GCC host triplet: x86_64 GNU/Linux
GCC target triplet: x86_64 GNU/Linux


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

[Bug c/40747] [4.4/4.5 Regression] wrong code for int-is-in-range test at -O1 and above

[sezeroz at gmail dot com]

--- Comment #2 from sezeroz at gmail dot com  2009-07-14 17:16 ---
Also happens with i686-pc-linux-gnu with gcc-4.4.1 (gcc-4_4-branch, r149543).


-- 

sezeroz at gmail dot com changed:

   What|Removed |Added

 CC||sezeroz at gmail dot com


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

[Bug c/40748] simple switch/case, if/else and arithmetics result in different code

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2009-07-14 17:11 ---
Created an attachment (id=18195)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18195&action=view)
testcase

Even at -O3, f1() and f2() don't have the same code as f3().


-- 


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

[Bug c/40747] [4.4/4.5 Regression] wrong code for int-is-in-range test at -O1 and above

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2009-07-14 17:25 ---
Confirmed, introduced between r134374 + r134467, looking into it.


-- 

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 |2009-07-14 17:25:58
   date||


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

[Bug bootstrap/39022] lto-plugin is built unconditionally

[ro at techfak dot uni-bielefeld dot de]

--- Comment #5 from ro at techfak dot uni-bielefeld dot de  2009-07-14 
17:26 ---
Subject: Re:  lto-plugin is built unconditionally

> --- Comment #4 from bje at gcc dot gnu dot org  2009-07-14 04:39 ---
> Can this PR be closed now, Rainer?

Yes, this works now.

Rainer


-- 


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

[Bug c/40747] [4.4/4.5 Regression] wrong code for int-is-in-range test at -O1 and above

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2009-07-14 18:00 ---
Indeed, caused by http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01303.html
(r134384).


-- 


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

[Bug c++/40733] No warning is issued when an implicit conversion can lead to a data loss

[photon at seznam dot cz]

--- Comment #10 from photon at seznam dot cz  2009-07-14 18:11 ---
(In reply to comment #9)
> 
> So your definition of -Wall is not very useful at all and will be even more
> misleading to users or why the warnings are happening.
> 

MSC's /Wall enables all warnings and I don't find it misleading at all.

http://msdn.microsoft.com/en-us/library/thxezb7y(VS.71).aspx


-- 


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

[Bug c++/40750] New: Side-effect of member function call not produced in certain circumstances

[schaub-johannes at web dot de]

GCC mis-compiles the following code for mysterious reasons. While it should
output "called", it outputs nothing at all

// snip
typedef void Fn() const; 

struct Foo { Fn fn; }; 
void Foo::fn() const { std::cout << "called" << std::endl; } 

int main() { Foo f; f.fn(); }
// snap

Any one of the following makes it show "called" properly:

- Adding "inline" function specifier in the declaration of the function at
class or namespace scope.
- Replacing "Fn fn;" by a declaration with a function declarator "void fn()
const;" 
- Making the function non-const (in the typedef and in the definition of the
function).


-- 
   Summary: Side-effect of member function call not produced in
certain circumstances
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c++/40740] [4.4/4.5 regression] template-id forgotten with arg-dep lookup

[jason at gcc dot gnu dot org]

--- Comment #1 from jason at gcc dot gnu dot org  2009-07-14 18:15 ---
Subject: Bug 40740

Author: jason
Date: Tue Jul 14 18:15:35 2009
New Revision: 149636

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149636
Log:
PR c++/40740
* semantics.c (perform_koenig_lookup): Handle empty template args.

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


-- 


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

[Bug c++/37276] Trouble with some (C99?) math builtins and namespace std

[jason at gcc dot gnu dot org]

--- Comment #12 from jason at gcc dot gnu dot org  2009-07-14 18:16 ---
Subject: Bug 37276

Author: jason
Date: Tue Jul 14 18:16:03 2009
New Revision: 149638

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149638
Log:
PR c++/37276
* decl.c (decls_match): A non-extern-C declaration doesn't match
a builtin extern-C declaration.

Added:
trunk/gcc/testsuite/g++.dg/lookup/builtin5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/other/error22.C
trunk/gcc/testsuite/g++.dg/warn/Warray-bounds.C
trunk/gcc/testsuite/gcc.dg/compat/compat-common.h


-- 


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

[Bug c++/40740] [4.4/4.5 regression] template-id forgotten with arg-dep lookup

[jason at gcc dot gnu dot org]

--- Comment #2 from jason at gcc dot gnu dot org  2009-07-14 18:35 ---
Subject: Bug 40740

Author: jason
Date: Tue Jul 14 18:35:13 2009
New Revision: 149640

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149640
Log:
PR c++/40740
* semantics.c (perform_koenig_lookup): Handle empty template args.


Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/koenig8.C
  - copied unchanged from r149636,
trunk/gcc/testsuite/g++.dg/template/koenig8.C
Modified:
branches/gcc-4_4-branch/gcc/   (props changed)
branches/gcc-4_4-branch/gcc/ChangeLog-2008   (props changed)
branches/gcc-4_4-branch/gcc/cp/ChangeLog
branches/gcc-4_4-branch/gcc/cp/ChangeLog-2007   (props changed)
branches/gcc-4_4-branch/gcc/cp/ChangeLog-2008   (props changed)
branches/gcc-4_4-branch/gcc/cp/semantics.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog-2008   (props changed)
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/   (props changed)
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/decltype-38655.C  
(props changed)
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr36227.c   (props
changed)
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/x86_64/abi/callabi/  
(props changed)

Propchange: branches/gcc-4_4-branch/gcc/
('svn:mergeinfo' modified)

Propchange: branches/gcc-4_4-branch/gcc/ChangeLog-2008
('svn:mergeinfo' modified)

Propchange: branches/gcc-4_4-branch/gcc/cp/ChangeLog-2007
('svn:mergeinfo' modified)

Propchange: branches/gcc-4_4-branch/gcc/cp/ChangeLog-2008
('svn:mergeinfo' modified)

Propchange: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog-2008
('svn:mergeinfo' modified)

Propchange: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/
('svn:mergeinfo' modified)

Propchange: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/decltype-38655.C
('svn:mergeinfo' modified)

Propchange: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr36227.c
('svn:mergeinfo' modified)

Propchange:
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/x86_64/abi/callabi/
('svn:mergeinfo' modified)


-- 


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

[Bug c++/40740] [4.4/4.5 regression] template-id forgotten with arg-dep lookup

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2009-07-14 18:41 ---
Fixed for 4.4.1.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/40746] namespace-qualified lookup misses some ambiguities

[jason at gcc dot gnu dot org]

--- Comment #1 from jason at gcc dot gnu dot org  2009-07-14 18:43 ---
Fixed for 4.5.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/37276] Trouble with some (C99?) math builtins and namespace std

[jason at gcc dot gnu dot org]

--- Comment #13 from jason at gcc dot gnu dot org  2009-07-14 18:44 ---
Fixed for 4.5.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/40687] [C++0x]: error with auto and 7.1.6.4/7 in N2914

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2009-07-14 18:50 ---
Yeah, that's a known issue; it's XFAILed in one of the auto tests.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-07-14 18:50:44
   date||


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

[Bug c++/40751] New: G++ never packs typedef'd enums

[bryce dot schober at gmail dot com]

The following enumerated type definitions packs to one byte as expected in C,
but not in C++:

typedef enum __attribute__ ((packed)) {
ZERO = 0,
ONE,
TWO
} my_enum_t;

The enum will pack as expected if using -fshort-enums, but that doesn't allow
me to pack on a per-enum basis. Neither will the above enum pack as a packed
member in a structure or as a member in a packed structure.

Test case to follow.


-- 
   Summary: G++ never packs typedef'd enums
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bryce dot schober at gmail dot com
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug c++/40751] G++ never packs typedef'd enums

[bryce dot schober at gmail dot com]

--- Comment #1 from bryce dot schober at gmail dot com  2009-07-14 19:09 
---
Created an attachment (id=18196)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18196&action=view)
test case

Built without warnings, to try to make sure I'm not doing something marginal:

gcc -Wall -Wextra -pedantic -lstdc++ -0 size size.c size.gcc


-- 


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

[Bug c++/40752] New: -Wconversion generates false warnings

[photon at seznam dot cz]

-Wconversion generates false warnings for the following clean code:

{
char c = 1;
char c2 = 2;

// warning: conversion to ‘char’ from ‘int’ may alter its value
c >>= 1;
c += (char) 1;
c += c2;
c = ~c2;
}


-- 
   Summary: -Wconversion generates false warnings
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: photon at seznam dot cz


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

[Bug fortran/40643] maxloc/minloc: Wrong result for NaN at position 1

[tkoenig at gcc dot gnu dot org]

--- Comment #6 from tkoenig at gcc dot gnu dot org  2009-07-14 19:18 ---
See also PR 30694.


-- 


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

[Bug c++/40752] -Wconversion generates false warnings

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-07-14 19:21 ---
Theses are not false warnings:
c >>= 1;

is really c = (int)c >> 1;

c += (char) 1;

c =  (int)c + (int)(char)1;

c += c2;

c = (int)c + (int) c2;


c = ~c2;

c = ~(int)c2;

Only the last one might be a false warning depending on if c2 is negative or
unsigned or not.  The rest are correct because of the way C/C++ define
arithmetic operations and automatic promotions.


-- 


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

[Bug debug/40705] [4.5 Regression] ICE in gen_type_die_with_usage, at dwarf2out.c:15117

[phorgan1 at gmail dot com]

--- Comment #7 from phorgan1 at gmail dot com  2009-07-14 19:37 ---
Verified that original test case now compiles with -g flag--Thanks!


-- 


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

[Bug bootstrap/40753] New: ICE in refs_may_alias_p_1 for libffi/src/powerpc/ffi.c

[janis at gcc dot gnu dot org]

Compiling libffi/src/powerpc/ffi.c as part of a bootstrap for powerpc*-*-linux*
fails starting with this patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=149624

r149624 | rguenth | 2009-07-14 09:59:18 + (Tue, 14 Jul 2009)

This minimized testcase demonstrates the problem:

--
typedef long unsigned int size_t;
typedef struct {
  unsigned nargs;
} ffi_cif;
typedef struct {
  char tramp[24];
  ffi_cif *cif;
} ffi_closure;
extern void *memcpy (void *, const void *, size_t);
extern void ffi_closure_LINUX64 (void);

int
ffi_prep_closure_loc (ffi_closure *closure, ffi_cif *cif)
{
  void **tramp = (void **) &closure->tramp[0];

  memcpy (tramp, (char *) ffi_closure_LINUX64, 16);
  closure->cif = cif;

  return 0;
}
--

elm3b149% /home/janis/build/build-gcc-trunk-anonsvn/gcc/cc1 -quiet -O2
bug0714.c
bug0714.c: In function ‘ffi_prep_closure_loc’:
bug0714.c:21:1: internal compiler error: in refs_may_alias_p_1, at
tree-ssa-alias.c:746
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE in refs_may_alias_p_1 for libffi/src/powerpc/ffi.c
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc*-*-linux*


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

[Bug tree-optimization/38072] [4.3 Regression] ICE during inlining of valid code

[mikpe at it dot uu dot se]

--- Comment #15 from mikpe at it dot uu dot se  2009-07-14 19:51 ---
(In reply to comment #14)
> Bah.  So this then becomes "it would be interesting to know what fixed this on
> the gimple-tuples-branch" ...

Revision 134191 fixed this on gimple-tuples-branch.


-- 


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

[Bug target/39716] [4.5 Regression][cond-optab] worse MAX_EXPR expansion for Thumb

[bonzini at gnu dot org]

--- Comment #1 from bonzini at gnu dot org  2009-07-14 20:35 ---
This fails for me with r149508 with a reload failure.


-- 


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

[Bug target/39719] [4.5 Regression][cond-optab] uses libcall instead of branch on m68hc11

[bonzini at gnu dot org]

--- Comment #1 from bonzini at gnu dot org  2009-07-14 20:36 ---
I meant that on most targets this testcase was improved by cond-optab, but not
on m68hc11.


-- 


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

[Bug lto/40754] New: lto1 dies with SIGBUS/SIGSEGV on Solaris 11/SPARC

[ro at gcc dot gnu dot org]

Running the testsuite on sparc-sun-solaris2.11 with the lto branch as of
20090709
reveals many testsuite errors like this:

Executing on host:
/vol/gccsrc/obj/gcc-lto-20090709/11-gcc/gcc/testsuite/g++/../../g++
-B/vol/gccsrc/obj/gcc-lto-20090709/11-gcc/gcc/testsuite/g++/../../
cp_lto_20080709_0.o  -nostdinc++
-I/vol/gccsrc/obj/gcc-lto-20090709/11-gcc/sparc-sun-solaris2.11/libstdc++-v3/include/sparc-sun-solaris2.11
-I/vol/gccsrc/obj/gcc-lto-20090709/11-gcc/sparc-sun-solaris2.11/libstdc++-v3/include
-I/vol/gcc/src/gcc-lto/libstdc++-v3/libsupc++
-I/vol/gcc/src/gcc-lto/libstdc++-v3/include/backward
-I/vol/gcc/src/gcc-lto/libstdc++-v3/testsuite/util -fmessage-length=0 -O0
-fwhopr
-L/vol/gccsrc/obj/gcc-lto-20090709/11-gcc/sparc-sun-solaris2.11/./libstdc++-v3/src/.libs

-L/vol/gccsrc/obj/gcc-lto-20090709/11-gcc/sparc-sun-solaris2.11/./libstdc++-v3/src/.libs
-L/vol/gccsrc/obj/gcc-lto-20090709/11-gcc/sparc-sun-solaris2.11/./libiberty 
-lm   -o g++-dg-lto-20080709-01(timeout = 300)
lto1: internal compiler error: Bus Error


Please submit a full bug report,


with preprocessed source if appropriate.


See  for instructions.


make: *** [ccFjaiMJ-cp_lto_20080709_0.o.lto.ltrans.o] Error 1


lto1: fatal error:
/vol/gccsrc/obj/gcc-lto-20090709/11-gcc/gcc/testsuite/g++/../../ltrans-driver
terminated with status 512


compilation terminated.


lto-wrapper:
/vol/gccsrc/obj/gcc-lto-20090709/11-gcc/gcc/testsuite/g++/../../g++ returned 1
exit status


collect2: lto-wrapper returned 1 exit status


compiler exited with status 1
output is:
lto1: internal compiler error: Bus Error


Please submit a full bug report,


with preprocessed source if appropriate.


See  for instructions.


make: *** [ccFjaiMJ-cp_lto_20080709_0.o.lto.ltrans.o] Error 1


lto1: fatal error:
/vol/gccsrc/obj/gcc-lto-20090709/11-gcc/gcc/testsuite/g++/../../ltrans-driver
terminated with status 512


compilation terminated.


lto-wrapper:
/vol/gccsrc/obj/gcc-lto-20090709/11-gcc/gcc/testsuite/g++/../../g++ returned 1
exit status


collect2: lto-wrapper returned 1 exit status



FAIL: g++.dg/lto/20080709 cp_lto_20080709_0.o-cp_lto_20080709_0.o link, 
(internal compiler error)

Running lto1 under gdb reveals

Program received signal SIGSEGV, Segmentation fault.
lto_main (debug_p=0) at /vol/gcc/src/gcc-lto/gcc/lto/lto.c:180
(gdb) where
#0  lto_main (debug_p=0) at /vol/gcc/src/gcc-lto/gcc/lto/lto.c:180
#1  0x003901e0 in toplev_main (argc=15, argv=0xffbff55c) at
/vol/gcc/src/gcc-lto/gcc/toplev.c:1039
#2  0x00097ee4 in _start ()

this can only happen if data (aka header) is NULL at this point, but gdb
cannot print them


-- 
   Summary: lto1 dies with SIGBUS/SIGSEGV on Solaris 11/SPARC
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
 GCC build triplet: sparc-sun-solaris2.11
  GCC host triplet: sparc-sun-solaris2.11
GCC target triplet: sparc-sun-solaris2.11


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

[Bug c++/40752] -Wconversion generates false warnings

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2009-07-14 20:55 ---
Andrew, what you say is true, but in this case the warning is not very useful.
I'd prefer to warn only when the operator is larger than the target of the
assignment. I would like to hear other opinions.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||iant at google dot com, manu
   ||at gcc dot gnu dot org


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

[Bug c++/40752] -Wconversion generates false warnings

[manu at gcc dot gnu dot org]

--- Comment #3 from manu at gcc dot gnu dot org  2009-07-14 20:56 ---
Joseph, could you comment on this?


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||joseph at codesourcery dot
   ||com


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

[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817

[pthaugen at gcc dot gnu dot org]

--- Comment #22 from pthaugen at gcc dot gnu dot org  2009-07-14 21:15 
---
The original problem, multi-block loop preventing movement of loads, was
reintroduced with revision 149206, Jan's CD-DCE patch to remove empty loops.


-- 

pthaugen at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jh at suse dot cz


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

[Bug target/39722] [4.5 Regression][cond-optab] worse code with bitfields on v850, mn10300, avr

[bonzini at gnu dot org]

--- Comment #2 from bonzini at gnu dot org  2009-07-14 21:17 ---
(This is gcc.c-torture/compile/20071128-1.c).


-- 


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

[Bug target/39721] [4.5 Regression][cond-optab] worse register allocation on mn10300

[bonzini at gnu dot org]

--- Comment #1 from bonzini at gnu dot org  2009-07-14 21:25 ---
(This is peak-gcc-src/gcc/testsuite/gcc.c-torture/compile/pr38564.c).

I cannot reproduce this anymore.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug tree-optimization/40744] SRA scalarizes dead objects, single-use objects

[rguenther at suse dot de]

--- Comment #2 from rguenther at suse dot de  2009-07-14 21:28 ---
Subject: Re:  SRA scalarizes dead objects,
 single-use objects

On Tue, 14 Jul 2009, jamborm at gcc dot gnu dot org wrote:

> --- Comment #1 from jamborm at gcc dot gnu dot org  2009-07-14 16:32 
> ---
> OK, I have now added this to my todo list.  The simple tweaks would be
> simple.  On  the other hand, if  DCE is clever, it  still might figure
> out a structure is dead at  some code paths while I don't even attempt
> to and still remove some statements.
> 
> > only loads from a structure or only stores to a structure
> > probably should be simply skipped.
> 
> I've been thinking about not scalarizing accesses that occur only once
> too.  Thinking about it more,  I wonder whether requiring at least one
> load and  a store or  at least  two loads is  a good idea.   (Load and
> store for the case where we  store something to an aggregate first and
> then load it and  two loads for the case when we  can finally get away
> with one.)

Note that it is important to keep the structure copyprop case

 tmp = b;
 return tmp;

which happens quite often in C++ code.

Richard.


-- 


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

[Bug target/39720] [4.5 Regression][cond-optab] combine does not use LOAD_EXTEND_OP?

[bonzini at gnu dot org]

--- Comment #1 from bonzini at gnu dot org  2009-07-14 21:32 ---
Cannot reproduce this anymore.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug target/39724] [4.5 Regression][cond-optab] reload_cse_simplify_operands complicates code on vax

[bonzini at gnu dot org]

--- Comment #1 from bonzini at gnu dot org  2009-07-14 21:34 ---
I cannot reproduce this anymore.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug lto/40739] [LTO] ICE in bp_pack_value, at lto-streamer.c:336

[dnovillo at gcc dot gnu dot org]

--- Comment #4 from dnovillo at gcc dot gnu dot org  2009-07-14 21:41 
---

This is likely fixed by
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00819.html,
could you try again?


-- 

dnovillo at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dnovillo at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-07-14 07:06:28 |2009-07-14 21:41:56
   date||


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

[Bug bootstrap/40753] [4.5 Regression] ICE in refs_may_alias_p_1 for libffi/src/powerpc/ffi.c

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-07-14 21:46 ---
Obviously mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-07-14 21:46:29
   date||
Summary|ICE in refs_may_alias_p_1   |[4.5 Regression] ICE in
   |for libffi/src/powerpc/ffi.c|refs_may_alias_p_1 for
   ||libffi/src/powerpc/ffi.c
   Target Milestone|--- |4.5.0


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

[Bug bootstrap/40753] [4.5 Regression] ICE in refs_may_alias_p_1 for libffi/src/powerpc/ffi.c

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-07-14 21:58 ---
Huh, we end up with a FUNCTION_DECL here, from

(gdb) call debug_rtx (mem)
(mem/c/i:SI (const:SI (plus:SI (symbol_ref:SI ("ffi_closure_LINUX64") [flags
0x41] )
(const_int 12 [0xc]))) [0 ffi_closure_LINUX64+12 S4 A8])

that doesn't make much sense but is easy to fix.

Index: alias.c
===
--- alias.c (revision 149643)
+++ alias.c (working copy)
@@ -279,6 +279,11 @@ ao_ref_from_mem (ao_ref *ref, const_rtx 
   && TREE_CODE (TREE_OPERAND (base, 0)) != SSA_NAME)
 return false;

+  /* The tree oracle doesn't like to have these.  */
+  if (TREE_CODE (base) == FUNCTION_DECL
+  || TREE_CODE (base) == LABEL_DECL)
+return false;
+
   /* If this is a reference based on a partitioned decl replace the
  base with an INDIRECT_REF of the pointer representative we
  created during stack slot partitioning.  */


-- 


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

[Bug c++/40752] -Wconversion generates false warnings

[ian at airs dot com]

--- Comment #4 from ian at airs dot com  2009-07-14 22:23 ---
Manu, I agree that these warnings are in some sense technically correct but
they are not useful.  They can't point to any actual bug.  I guess would be
that if every input to the expression has the size of the target of the
expression, then the warning should be suppressed.


-- 


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