[Bug c/43469] [4.5 Regression] ICE trying to compile glibc for ARM thumb2

[ramana at gcc dot gnu dot org]

-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2010-03-22 08:56:27
   date||
Summary|ICE trying to compile glibc |[4.5 Regression] ICE trying
   |for ARM thumb2  |to compile glibc for ARM
   ||thumb2


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

[Bug fortran/43409] I/O: INQUIRE for SIZE does not work.

[dominiq at lps dot ens dot fr]

--- Comment #14 from dominiq at lps dot ens dot fr  2010-03-22 09:05 ---
> Dominique, please confirm this fixes it on your machine.

It does (for limited testing only). Thanks for the fix. Note that a "quick" (8
hours latency) way to check what's happen on powerpc is to monitor the tester
"regress" on http://gcc.gnu.org/ml/gcc-testresults/ .
It darwin oriented and does not test everything (no -m64, no graphite, ...),
but it gives early warnings about problems on ppc.


-- 


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

[Bug c/43469] [4.5 Regression] ICE trying to compile glibc for ARM thumb2

[ramana at gcc dot gnu dot org]

--- Comment #3 from ramana at gcc dot gnu dot org  2010-03-22 09:11 ---
Created an attachment (id=20156)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20156&action=view)
Reduced testcase.

Reduced testcase. 


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #20152|0   |1
is obsolete||


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

[Bug rtl-optimization/43470] ICE: powerpc64 with -fno-strict-aliasing -O2 on interersting asm volatiles

[slyfox at inbox dot ru]

--- Comment #5 from slyfox at inbox dot ru  2010-03-22 09:50 ---
Yes, i can confirm gcc-trunk does not fail on this file. What prevents this fix
to be merged to 4.4. branch?

Thanks!


-- 


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

[Bug target/43469] [4.5 Regression] ICE trying to compile glibc for ARM thumb2

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|rguenth at gcc dot gnu dot  |
   |org |
  Component|c   |target
   Target Milestone|--- |4.5.0


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

[Bug middle-end/26241] [4.3/4.4/4.5 Regression] None of the IPA passes are documented in passes.texi

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-03-22 09:59 ---
As always, patches welcome.  Internal documentation is not release critical
(and we've historically been not very good in keeping it up-to-date).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P5


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

[Bug target/37367] [4.4/4.5 Regression] gcc-4.4/4.5 speed regression

[rguenther at suse dot de]

--- Comment #8 from rguenther at suse dot de  2010-03-22 10:01 ---
Subject: Re:  [4.4/4.5 Regression] gcc-4.4/4.5 speed
 regression

On Sun, 21 Mar 2010, hjl dot tools at gmail dot com wrote:

> --- Comment #7 from hjl dot tools at gmail dot com  2010-03-21 16:20 
> ---
> (In reply to comment #6)
> > Shouldn't there be a PR about the suboptimal performance from the core2 
> > tuning
> > (in hopes that original contributors from Intel will revisit these issues)?
> > 
> 
> Intel didn't contribute -march=core2. I have been telling
> people to use -mtune=generic.

So should we make -march=core2 turn on -mtune=generic then?


-- 


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

[Bug debug/42977] [4.5 Regression] "-fcompare-debug failure" with "-O2 -finline-functions -fomit-frame-pointer -ftracer -fsched2-use-superblocks -fPIC"

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-03-22 10:12 ---
I believe e.g. DSE, postreload (reload_cse_regs_1), cfgcleanup (thread_jump)
wouldn't mind guarding cselib_process_insn call with
if (!DEBUG_INSN_P (insn))
  cselib_process_insn (insn);
On the other side, e.g. ebb scheduling would care a lot, it uses cselib for
MEMs
both in normal insns and in debug insns to find out if a move is possible and
in case of debug insns if the DEBUG insn doesn't need to be dropped.
I believe gcse (local_cprop_pass) would also care.  So we have 3 passes that
wouldn't care, 2 that would and one (var-tracking) that must handle
DEBUG_INSNs, but where it never can't create any -fcompare-debug failures,
simply because
var-tracking only affects var_location notes and not code and is only run in
the -g case.


-- 


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

[Bug debug/43443] We should yank ASM_OPERANDS locs from var-tracking preserved cselib VALUEs

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-03-22 10:26 ---
Subject: Bug 43443

Author: jakub
Date: Mon Mar 22 10:26:33 2010
New Revision: 157620

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157620
Log:
PR debug/43443
* var-tracking.c (add_cselib_value_chains): Remove ASM_OPERANDS
locs from preserved VALUEs.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/var-tracking.c


-- 


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

[Bug lto/43455] ICE in fold_convert_loc, at fold-const.c:2670 with -O2 -flto

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-03-22 10:30 ---
I get on x86_64-linux

> ./xgcc -B. -flto t1.c t2.c -O2
In file included from t2.c:2:0,
 from t1.c:2,
 from :0:
t1.c: In function 'main':
t1.c:5:22: internal compiler error: in fold_convert_loc, at fold-const.c:2792
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: ././xgcc returned 1 exit status
collect2: lto-wrapper returned 1 exit status

same with the less reduced testcase on x86_64 and i?86 linux.

Thanks for the report.


This is because we do not merge

  struct bar {int x;};

and

  typedef struct{int x;} bar;

but we expect to be able to convert them into each other during inlining:

#2  0x00c120ac in declare_return_variable (id=0x7fffd9d0, 
return_slot=0x0, modify_dest=0x75af03c0)
at /space/rguenther/src/svn/trunk/gcc/tree-inline.c:2690
2690use = fold_convert (caller_type, var);
(gdb) l
2685
2686  /* Build the use expr.  If the return type of the function was
2687 promoted, convert it back to the expected type.  */
2688  use = var;
2689  if (!useless_type_conversion_p (caller_type, TREE_TYPE (var)))
2690use = fold_convert (caller_type, var);


This is really invalid C as bar is re-declared in an incompatible way
(which you'd see if you combine both TUs).

Now, we shouldn't ICE here anyway and LTO should be forgiving to this
kind of errors.

The following fixes the symptoms.

Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c   (revision 157619)
+++ gcc/tree-inline.c   (working copy)
@@ -2687,7 +2687,12 @@ declare_return_variable (copy_body_data
  promoted, convert it back to the expected type.  */
   use = var;
   if (!useless_type_conversion_p (caller_type, TREE_TYPE (var)))
-use = fold_convert (caller_type, var);
+{
+  if (fold_convertible_p (caller_type, var))
+   use = fold_convert (caller_type, var);
+  else
+   use = fold_build1 (VIEW_CONVERT_EXPR, caller_type, var);
+}

   STRIP_USELESS_TYPE_CONVERSION (use);


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-22 10:30:26
   date||
Summary|Compiler hang with -O2 -flto|ICE in fold_convert_loc, at
   ||fold-const.c:2670 with -O2 -
   ||flto


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

[Bug lto/43455] ICE in fold_convert_loc, at fold-const.c:2670 with -O2 -flto

[rguenth at gcc dot gnu dot org]

-- 

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|NEW |ASSIGNED
   Last reconfirmed|2010-03-22 10:30:26 |2010-03-22 10:30:41
   date||


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

[Bug middle-end/40106] [4.4/4.5 Regression] Weird interaction between optimize_insn_for_speed_p and -funsafe-math-optimizations

[rguenth at gcc dot gnu dot org]

--- Comment #56 from rguenth at gcc dot gnu dot org  2010-03-22 10:36 
---
I'm testing fixed comment #48.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|hubicka at gcc dot gnu dot  |rguenth at gcc dot gnu dot
   |org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-10-18 13:22:22 |2010-03-22 10:36:35
   date||


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

[Bug target/37367] [4.4/4.5 Regression] gcc-4.4/4.5 speed regression

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2010-03-22 10:47 ---
>From the numbers Vladimir posted for SPEC2k, x86_64 -mtune=generic vs.
-mtune=core2 has the same rate for SPECint, with core2 slightly smaller code
size, for SPECfp -mtune=core2 has 0.4% worse rate due to 10% drop on facerec
(otherwise it would be 0.4% win) with slightly smaller code for -mtune=core2.
On x86 SPECint is slightly worse with -mtune=core2 and even code size is
slightly larger, SPECfp on the other side has both slightly better rate and
code size with -mtune=core2.  So using generic tuning for core2 is possible.


-- 


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

[Bug target/37367] [4.4/4.5 Regression] gcc-4.4/4.5 speed regression

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2010-03-22 10:49 ---
Created an attachment (id=20157)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20157&action=view)
gcc-minimal-tune=core2.patch

Here is a minimal (and untested too) patch for that.
A bigger patch would drop all PROCESSOR_CORE2, core2_cost, CPU_CORE2 etc.
references (AFAIK there aren't that many in the sources).


-- 


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

[Bug debug/43443] We should yank ASM_OPERANDS locs from var-tracking preserved cselib VALUEs

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-03-22 10:49 ---
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=43443

[Bug middle-end/43475] New: [4.5 Regression] ICE in form_sum, at reload.c:5348

[rguenth at gcc dot gnu dot org]

subroutine ss(w)
  implicit none
  integer :: w(:)
  integer :: b,c,d
  b = w(8)
  c = 5
  d = 3
  call s1(c)
  call s2(b+c)
  call s3(w(b))
end subroutine ss

> gfortran-4.5 -O2 -S t.f90
t.f90: In function ‘ss’:
t.f90:1:0: internal compiler error: in form_sum, at reload.c:5348
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.5 Regression] ICE in form_sum, at reload.c:5348
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: x86-64-*-*


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

[Bug middle-end/43475] [4.5 Regression] ICE in form_sum, at reload.c:5348

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-03-22 11:11 ---
#1  0x00958e6e in form_sum (mode=SImode, x=0x77fb2a80, 
y=0x75ae1b58) at /space/rguenther/src/svn/trunk/gcc/reload.c:5348
5348  gcc_assert (GET_MODE (x) == mode || GET_MODE (x) == VOIDmode);
(gdb) call debug_rtx (x)
(reg/v:DI 41 r12 [orig:61 b ] [61])
(gdb) up
#2  0x0096560c in eliminate_regs_1 (x=0x75ae1af8, 
mem_mode=VOIDmode, insn=0x75ae1ac8, may_use_invariant=1 '\001')
at /space/rguenther/src/svn/trunk/gcc/reload1.c:2678
2678new_rtx = form_sum (GET_MODE (x), new0, new1);
#3  0x00965914 in eliminate_regs_1 (x=0x75ae1ae0, 
mem_mode=VOIDmode, insn=0x75ae1ac8, may_use_invariant=1 '\001')
at /space/rguenther/src/svn/trunk/gcc/reload1.c:2745
2745  new_rtx = eliminate_regs_1 (XEXP (x, 0), mem_mode, insn,
true);
#4  0x009659f0 in eliminate_regs_1 (x=0x75ae1ac8, 
mem_mode=VOIDmode, insn=0x75ae1ac8, may_use_invariant=1 '\001')
at /space/rguenther/src/svn/trunk/gcc/reload1.c:2768
2768  new_rtx = eliminate_regs_1 (XEXP (x, 1), mem_mode, insn,
true);
#5  0x009679c5 in eliminate_regs_in_insn (insn=0x75ade000, 
replace=0) at /space/rguenther/src/svn/trunk/gcc/reload1.c:3596
3596REG_NOTES (insn)
(gdb) call debug_rtx (insn)
(insn 26 25 27 5 /tmp/t.f90:9 (set (mem/c/i:SI (plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])) [6 D.1561+0 S4 A64])
(reg:SI 0 ax [83])) 47 {*movsi_1} (expr_list:REG_DEAD (reg:SI 0 ax
[83])
(expr_list:REG_EQUAL (plus:SI (reg/v:DI 41 r12 [orig:61 b ] [61])
(mem/c/i:SI (plus:DI (reg/f:DI 20 frame)
(const_int -4 [0xfffc])) [6 c+0 S4 A32]))
(nil

somehow in the REG_EQUAL note we have a SI mode PLUS with DI mode arguments.

It is regmove which changes

(insn 26 25 27 5 /tmp/t.f90:9 (set (mem/c/i:SI (plus:DI (reg/f:DI 20 frame)
(const_int -8 [0xfff8])) [6 D.1561+0 S4 A64])
(reg:SI 83)) 47 {*movsi_1} (expr_list:REG_DEAD (reg:SI 83)
(expr_list:REG_EQUAL (plus:SI (reg/v:SI 61 [ b ])
(mem/c/i:SI (plus:DI (reg/f:DI 20 frame)
(const_int -4 [0xfffc])) [6 c+0 S4 A32]))
(nil

to

(insn 26 25 27 5 /tmp/t.f90:9 (set (mem/c/i:SI (plus:DI (reg/f:DI 20 frame)
(const_int -8 [0xfff8])) [6 D.1561+0 S4 A64])
(reg:SI 83)) 47 {*movsi_1} (expr_list:REG_DEAD (reg:SI 83)
(expr_list:REG_EQUAL (plus:SI (reg/v:DI 61 [ b ])
(mem/c/i:SI (plus:DI (reg/f:DI 20 frame)
(const_int -4 [0xfffc])) [6 c+0 S4 A32]))
(nil


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-22 11:11:38
   date||
   Target Milestone|--- |4.5.0


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

[Bug middle-end/43476] New: -ffixed-xxx etc processed too early

[rearnsha at gcc dot gnu dot org]

-ffixed-xxx -fcall-used-xxx and -fcall-saved-xxx are processed before
init_regs() is called, and that function calls CONDITIONAL_REGISTER_USAGE.  If
that macro changes the registers available (for example, to generate an ABI
variant), then it cannot tell whether or not a register's usage model has been
changed on the command-line.

This manifests itself, for example, on ARM when -mfpu=vfpv3 -mfloat-abi=hard
-fcall-used-s16 -fcall-used-s17 does change the callee-saved register set.

Not sure if this is a regression over older compilers.


-- 
   Summary: -ffixed-xxx etc processed too early
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org


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

[Bug middle-end/43475] [4.5 Regression] ICE in form_sum, at reload.c:5348

[matz at gcc dot gnu dot org]

--- Comment #2 from matz at gcc dot gnu dot org  2010-03-22 11:57 ---
optimize_reg_copy_3 misses to replace in notes.  Mine.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||matz at gcc dot gnu dot org
 AssignedTo|unassigned at gcc dot gnu   |matz at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-03-22 11:11:38 |2010-03-22 11:57:36
   date||


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

[Bug middle-end/43476] -ffixed-xxx etc processed too early

[joseph at codesourcery dot com]

--- Comment #1 from joseph at codesourcery dot com  2010-03-22 12:22 ---
Subject: Re:   New: -ffixed-xxx etc processed too early

This has been around for years; when testing my iWMMXt unwind patch 
 I found it 
wasn't possible to test the handling of unwind info for call-clobbered 
registers using these options because of this bug.


-- 


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

[Bug fortran/43409] I/O: INQUIRE for SIZE does not work.

[dominiq at lps dot ens dot fr]

--- Comment #15 from dominiq at lps dot ens dot fr  2010-03-22 12:29 ---
Full regtesting passed on powerpc-apple-darwin9.8.0 for -m32 (see
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01896.html ).


-- 


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

[Bug middle-end/40106] [4.4/4.5 Regression] Weird interaction between optimize_insn_for_speed_p and -funsafe-math-optimizations

[rguenth at gcc dot gnu dot org]

--- Comment #57 from rguenth at gcc dot gnu dot org  2010-03-22 12:38 
---
Subject: Bug 40106

Author: rguenth
Date: Mon Mar 22 12:38:02 2010
New Revision: 157623

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157623
Log:
2010-03-22  Richard Guenther  

PR middle-end/40106
* builtins.c (expand_builtin_pow): Expand pow (x, 1.5) as
x * sqrt (x) even when optimizing for size if the target
has native support for sqrt.

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


-- 


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

[Bug middle-end/43390] [4.5 Regression] ICE: integral result type precision does not match field size of BIT_FIELD_REF

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-03-22 12:39 ---
Subject: Bug 43390

Author: rguenth
Date: Mon Mar 22 12:39:04 2010
New Revision: 157624

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157624
Log:
2010-03-22  Richard Guenther  

PR tree-optimization/43390
* tree-vect-stmts.c (get_vectype_for_scalar_type): Make
sure vector extracts are type correct.

* gfortran.fortran-torture/execute/pr43390.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.fortran-torture/execute/pr43390.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c


-- 


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

[Bug middle-end/40106] [4.4 Regression] Weird interaction between optimize_insn_for_speed_p and -funsafe-math-optimizations

[rguenth at gcc dot gnu dot org]

--- Comment #58 from rguenth at gcc dot gnu dot org  2010-03-22 12:39 
---
Fixed for 4.5.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|rguenth at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW
  Known to work||4.5.0
Summary|[4.4/4.5 Regression] Weird  |[4.4 Regression] Weird
   |interaction between |interaction between
   |optimize_insn_for_speed_p   |optimize_insn_for_speed_p
   |and -funsafe-math-  |and -funsafe-math-
   |optimizations   |optimizations


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

[Bug middle-end/43390] [4.5 Regression] ICE: integral result type precision does not match field size of BIT_FIELD_REF

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-03-22 12:39 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libgomp/42942] OpenMP omp_set_max_active_levels(0) isn't resetting value

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-03-22 12:40 ---
Created an attachment (id=20158)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20158&action=view)
gcc45-pr42942.patch

So far untested fix.


-- 

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


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

[Bug middle-end/43419] gcc replaces pow(x, 0.5) by sqrt(x), invalid when x is -0

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2010-03-22 14:58 ---
Subject: Bug 43419

Author: jakub
Date: Mon Mar 22 14:58:00 2010
New Revision: 157631

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157631
Log:
Backport from mainline:
2010-03-18  Michael Matz  

PR middle-end/43419
* builtins.c (expand_builtin_pow): Don't transform pow(x, 0.5)
into sqrt(x) if we need to preserve signed zeros.

* gcc.dg/pr43419.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr43419.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/builtins.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/43305] [4.4 Regression] ICE: in emit_unop_insn, at optabs.c:3838 with -Os -ffast-math and ilogbl()

[jakub at gcc dot gnu dot org]

--- Comment #13 from jakub at gcc dot gnu dot org  2010-03-22 15:00 ---
Subject: Bug 43305

Author: jakub
Date: Mon Mar 22 15:00:20 2010
New Revision: 157632

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157632
Log:
Backport from mainline:
2010-03-19  Michael Matz  

PR target/43305
* builtins.c (expand_builtin_interclass_mathfn,
expand_builtin_signbit): Use maybe_emit_unop_insn, emit libcalls
if that fails.

* gcc.dg/pr43305.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr43305.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/builtins.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/43116] [4.3/4.4 Regression] ICE when using attributes in a function alias declaration

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-03-22 15:04 ---
Subject: Bug 43116

Author: jakub
Date: Mon Mar 22 15:03:45 2010
New Revision: 157633

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157633
Log:
Backport from mainline:
2010-03-19  Michael Matz  

PR c++/43116
* attribs.c (decl_attributes): When rebuilding a function pointer
type use the same qualifiers as the original pointer type.

* g++.dg/other/pr43116.C: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/pr43116.C
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/attribs.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/43477] New: -march=k8-sse3 on turion-rm75 failed

[aflyhorse at foxmail dot com]

i'm using amd turion RM75 CPU under msys-mingw64 
i want to make a fully optimized gcc of my own, so first i generated a general
version of gcc. when i was making binutils the second time with -march=k8-sse3,
i got this message:

gcc -o chew.$$ -O3 -fomit-frame-pointer -pipe -march=k8-sse3 -mfpmath=sse -m64
-
mthreads -minline-stringops-dynamically -mcmodel=large -s -Wl,--as-needed \
   -I.. -I../../../src/bfd/doc/.. -I../../../src/bfd/doc/../../include
-
I../../../src/bfd/doc/../../intl -I../../intl ../../../src/bfd/doc/chew.c; \
/bin/sh ../../../src/bfd/doc/../../move-if-change chew.$$ chew.exe
../../../src/bfd/doc/chew.c: In function 'push_number':
../../../src/bfd/doc/chew.c:403:10: warning: cast from pointer to integer of
dif
ferent size
../../../src/bfd/doc/chew.c: In function 'compile':
../../../src/bfd/doc/chew.c:1364:29: warning: cast to pointer from integer of
di
fferent size
../../../src/bfd/doc/chew.c: In function 'bang':
../../../src/bfd/doc/chew.c:1386:4: warning: cast to pointer from integer of
dif
ferent size
../../../src/bfd/doc/chew.c: In function 'atsign':
../../../src/bfd/doc/chew.c:1395:13: warning: cast to pointer from integer of
di
fferent size
../../../src/bfd/doc/chew.c:1571:1: error: unable to find a register to spill
in
 class 'AREG'
../../../src/bfd/doc/chew.c:1571:1: error: this is the insn:
(insn 1666 1663 1668 74 ../../../src/bfd/doc/chew.c:1235 (set (mem/f/c/i:DI
(sym
bol_ref:DI ("tos") [flags 0x2] ) [10 tos+0 S8
A12
8])
(symbol_ref:DI ("stack") [flags 0x2] ))
 90 {*movabsdi_1_rex64} (expr_list:REG_EQUAL (symbol_ref:DI ("stack") [flags
0x2
] )
(nil)))
../../../src/bfd/doc/chew.c:1571:1: internal compiler error: in spill_failure,
a
t reload1.c:2158
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

i don't know whether it's a bug of gcc or simply AMD hadn't fully supported
SSE3
thx


-- 
   Summary: -march=k8-sse3 on turion-rm75 failed
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aflyhorse at foxmail dot com
  GCC host triplet: x86_64-w64-mingw32


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

[Bug rtl-optimization/43438] [4.3/4.4 Regression] possible wrong code bug

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2010-03-22 15:06 ---
Subject: Bug 43438

Author: jakub
Date: Mon Mar 22 15:05:46 2010
New Revision: 157634

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157634
Log:
Backport from mainline:
2010-03-20  Richard Guenther  

PR rtl-optimization/43438
* combine.c (make_extraction): Properly zero-/sign-extend an
extraction of the low part of a CONST_INT.  Also handle
CONST_DOUBLE.

* gcc.c-torture/execute/pr43438.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr43438.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/combine.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/43477] -march=k8-sse3 on turion-rm75 failed

[aflyhorse at foxmail dot com]

--- Comment #1 from aflyhorse at foxmail dot com  2010-03-22 15:08 ---
in additional, i'm using the 20100317 version of gcc 4.5.0 and binutils 2.20.51


-- 


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

[Bug debug/43478] New: Missing DW_AT_location for a variable

[jan dot kratochvil at redhat dot com]

gcc (GCC) 4.5.0 20100322 (experimental)
---
int h (void);
int f (void)
{
  int x, y;
  x = h () * 2;
  y = h () * 2;
  return x + y;
}
---
-c -Wall -g -O2
---
 <2><50>: Abbrev Number: 3 (DW_TAG_variable)
<51>   DW_AT_name: x
<55>   DW_AT_type: <0x67>   
<59>   DW_AT_location: 0x4c (location list)
 <2><5d>: Abbrev Number: 4 (DW_TAG_variable)
<5e>   DW_AT_name: y
<62>   DW_AT_type: <0x67>   
... but no DW_AT_location


-- 
   Summary: Missing DW_AT_location for a variable
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug libgomp/42942] OpenMP omp_set_max_active_levels(0) isn't resetting value

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-03-22 15:17 ---
Subject: Bug 42942

Author: jakub
Date: Mon Mar 22 15:16:52 2010
New Revision: 157635

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157635
Log:
PR libgomp/42942
* env.c (parse_unsigned_long): Add ALLOW_ZERO argument.
(initialize_env): Adjust callers.
(omp_set_max_active_levels): Set gomp_max_active_levels_var even
when the argument is 0.

* testsuite/libgomp.c/pr42942.c: New test.

Added:
trunk/libgomp/testsuite/libgomp.c/pr42942.c
Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/env.c


-- 


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

[Bug debug/43479] New: Missing DW_TAG_lexical_block+DW_TAG_variable

[jan dot kratochvil at redhat dot com]

gcc (GCC) 4.5.0 20100322 (experimental)
---
int f (void)
{
  int x;
  {
int y = 1;
x = y;
  }
  return x;
}
---
-c -Wall -g -O2
---
 <1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
<2f>   DW_AT_name: f
 <2><4e>: Abbrev Number: 3 (DW_TAG_variable)
<4f>   DW_AT_name: x
<53>   DW_AT_type: <0x59>   
<57>   DW_AT_const_value : 1
... but neither DW_TAG_lexical_block nor DW_TAG_variable("y")


-- 
   Summary: Missing DW_TAG_lexical_block+DW_TAG_variable
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug debug/42977] [4.5 Regression] "-fcompare-debug failure" with "-O2 -finline-functions -fomit-frame-pointer -ftracer -fsched2-use-superblocks -fPIC"

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2010-03-22 15:21 ---
BTW, when not using cselib_record_sets hook, I believe cselib_process_insn does
really nothing at all on DEBUG_INSNs.  This would also mean that even local
cprop is fine.  The problem are cselib_lookup (x, y, 1); calls sched-deps.c
does
on MEMs in debug_insns.


-- 


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

[Bug libgomp/42942] OpenMP omp_set_max_active_levels(0) isn't resetting value

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-03-22 15:22 ---
Subject: Bug 42942

Author: jakub
Date: Mon Mar 22 15:22:31 2010
New Revision: 157636

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157636
Log:
PR libgomp/42942
* env.c (parse_unsigned_long): Add ALLOW_ZERO argument.
(initialize_env): Adjust callers.
(omp_set_max_active_levels): Set gomp_max_active_levels_var even
when the argument is 0.

* testsuite/libgomp.c/pr42942.c: New test.

Added:
branches/gcc-4_4-branch/libgomp/testsuite/libgomp.c/pr42942.c
Modified:
branches/gcc-4_4-branch/libgomp/ChangeLog
branches/gcc-4_4-branch/libgomp/env.c


-- 


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

[Bug libgomp/42942] OpenMP omp_set_max_active_levels(0) isn't resetting value

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-03-22 15:27 ---
Fixed, thanks for the report.


-- 

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

[Bug rtl-optimization/43438] [4.3 Regression] possible wrong code bug

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2010-03-22 15:28 ---
Fixed also on 4.4 branch.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work|4.1.2 4.5.0 |4.1.2 4.5.0 4.4.4
Summary|[4.3/4.4 Regression]|[4.3 Regression] possible
   |possible wrong code bug |wrong code bug


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

[Bug c++/43116] [4.3 Regression] ICE when using attributes in a function alias declaration

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-03-22 15:29 ---
Fixed also on 4.4 branch.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.2.3 4.3.2 |4.2.3 4.3.2 4.4.3
  Known to work|4.1.3 4.5.0 |4.1.3 4.5.0 4.4.4
Summary|[4.3/4.4 Regression] ICE|[4.3 Regression] ICE when
   |when using attributes in a  |using attributes in a
   |function alias declaration  |function alias declaration


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

[Bug target/43305] [4.4 Regression] ICE: in emit_unop_insn, at optabs.c:3838 with -Os -ffast-math and ilogbl()

[jakub at gcc dot gnu dot org]

--- Comment #14 from jakub at gcc dot gnu dot org  2010-03-22 15:29 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work|4.5.0 4.3.0 |4.5.0 4.3.0 4.4.4
 Resolution||FIXED


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

[Bug tree-optimization/43472] gcc -O3: exhausts memory on whetstone.cbe.

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-03-22 15:47 ---
It is.

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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/43464] copy prop breaks loop closed SSA form

[spop at gcc dot gnu dot org]

--- Comment #13 from spop at gcc dot gnu dot org  2010-03-22 15:47 ---
Note that 

   * tree-ssa-copy.c (init_copy_prop): Loop closed phi nodes can
contain more than one argument.

breaks both 464.h264ref and 416.gamess with -O3.  See for example
http://groups.google.com/group/gcc-graphite-test/browse_thread/thread/f5b0d912e90b598f


-- 


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

[Bug tree-optimization/43415] [4.4 Regression] Consumes large amounts of memory and time in PRE at -O3

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-03-22 15:47 ---
*** Bug 43472 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||edwintorok at gmail dot com


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

[Bug debug/42977] [4.5 Regression] "-fcompare-debug failure" with "-O2 -finline-functions -fomit-frame-pointer -ftracer -fsched2-use-superblocks -fPIC"

[matz at gcc dot gnu dot org]

--- Comment #9 from matz at gcc dot gnu dot org  2010-03-22 16:01 ---
For sched-deps.c there are two calls to cselib_lookup:
1) in sched_analize_1 (for writing to MEM)
2) in sched_analize_2 (for reading a MEM)

Regarding (2): cselib_lookup is called on a copy of X (made into T) which
then is replaced into XEXP(t,0).  But for debug-insn that very T isn't used
at all further down.  So we can disregard the use at (2) (and move the whole
manipulation of T into the !DEBUG_INSN_P block).

Regarding (1): Here we don't handle debug-insns specially, but sched_analize_1
is called only on PRE/POST_DEC/INC/MODIFY, top-level SET/CLOBBER insns (maybe
in a PARALLEL) or CLOBBERS in CALL_INSN_FUNCTION_USAGE.

It better should be true that debug-insn don't contain a
PRE/POST_DEC/INC/MODIFY side-effect, or a top-level SET/CLOBBER.  IOW
sched_analyze_1 never should be called on debug-insns.  So we can disregard
case (1) too.

Next: if the cselib_lookup calls (that always have their 'create' argument
be true) ever create a new VALUE for a MEM in a debug-insn, that same wouldn't
happen without debug-insn, or in different order.  I think this would lead
to debug-miscompare later down anyway.

So, I think any calls into cselib on debug-insns that happen to create new
values are actually bugs waiting to be discovered.


-- 


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

[Bug middle-end/43419] gcc replaces pow(x, 0.5) by sqrt(x), invalid when x is -0

[mikpe at it dot uu dot se]

--- Comment #9 from mikpe at it dot uu dot se  2010-03-22 16:02 ---
This bug also affects 4.3 branch. The upstream patch applies Ok and fixes it.


-- 


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

[Bug other/43480] New: build: random timestamps have multilib conflicts

[jan dot kratochvil at redhat dot com]

The problem I am trying to solve is:

Transaction Check Error:
  file /usr/share/man/man1/gcj-dbtool.1.gz conflicts between attempted installs
of libgcj-4.4.3-8.fc13.x86_64 and libgcj-4.4.3-8.fc13.i686
  file /usr/share/man/man1/gij.1.gz conflicts between attempted installs of
libgcj-4.4.3-8.fc13.x86_64 and libgcj-4.4.3-8.fc13.i686
  file /usr/share/man/man1/grmic.1.gz conflicts between attempted installs of
libgcj-4.4.3-8.fc13.x86_64 and libgcj-4.4.3-8.fc13.i686
  file /usr/share/man/man1/jv-convert.1.gz conflicts between attempted installs
of libgcj-4.4.3-8.fc13.x86_64 and libgcj-4.4.3-8.fc13.i686

It is due to:

gzip -dc ./libgcj-4.4.3-8.fc13.i686/usr/share/man/man1/gij.1.gz >gij-i686
gzip -dc ./libgcj-4.4.3-8.fc13.x86_64/usr/share/man/man1/gij.1.gz >gij-x86_64
diff -u gij-*
--- gij-i6862010-03-22 10:17:59.0 +0100
+++ gij-x86_64  2010-03-22 10:18:07.0 +0100
@@ -124,7 +124,7 @@
 .\" 
 .\"
 .IX Title "GIJ 1"
-.TH GIJ 1 "2010-02-27" "gcc-4.4.3" "GNU"
+.TH GIJ 1 "2010-02-26" "gcc-4.4.3" "GNU"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l

One host built that file a different time (day) then a different host.

Moreover the files content should not depend on their time of build.

Patch applies to both GCC HEAD SVN and fastjar CVS.


fastjar/
2010-03-22  Jan Kratochvil  

* Makefile.am (fastjar.pod, grepjar.pod): Preserve modification time.
* Makefile.in: Regenerate.

gcc/java/
2010-03-22  Jan Kratochvil  

* Make-lang.in (gcj.pod, jcf-dump.pod, gij.pod, jv-convert.pod)
(grmic.pod, gcj-dbtool.pod, gc-analyze.pod, aot-compile.pod)
(rebuild-gcj-db.pod): Preserve modification time.

gcc/fortran/
2010-03-22  Jan Kratochvil  

* Make-lang.in (gfortran.pod): Preserve modification time.

gcc/
2010-03-22  Jan Kratochvil  

* Makefile.in (%.pod, gcc.pod, gfdl.pod, fsf-funding.pod, gpl.pod):
Preserve modification time.

libjava/classpath/
2010-03-22  Jan Kratochvil  

* doc/Makefile.am (gappletviewer.pod, gjarsigner.pod, gjar.pod)
(gcjh.pod, gjavah.pod, gkeytool.pod, gnative2ascii.pod, gorbd.pod)
(grmid.pod, grmiregistry.pod, gserialver.pod, gtnameserv.pod)
(gjdoc.pod): Preserve modification time.
* doc/Makefile.in: Regenerate.


-- 
   Summary: build: random timestamps have multilib conflicts
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com


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

[Bug other/43480] build: random timestamps have multilib conflicts

[jan dot kratochvil at redhat dot com]

--- Comment #1 from jan dot kratochvil at redhat dot com  2010-03-22 16:03 
---
Created an attachment (id=20159)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20159&action=view)
Fix.


-- 


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

[Bug debug/39524] Duplicate C++ DW_TAG_variable breaking its DW_AT_location resolution

[dodji at gcc dot gnu dot org]

--- Comment #7 from dodji at gcc dot gnu dot org  2010-03-22 16:11 ---
This got fixed in 4.4 but the PR never got closed. Closing now.


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug target/43437] ICE in CSE, during libgcc build

[law at redhat dot com]

--- Comment #8 from law at redhat dot com  2010-03-22 16:12 ---
I'd tend to agree with comment #7 -- multiple side effects on a single register
in a single insn like this seems like a huge rats nest of problems.


-- 


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

[Bug fortran/43481] New: huge object files generated for un-initialized data

[developer at sandoe-acoustics dot co dot uk]

simple definitions of un-initialized data are using the .space asm directive
which results in huge object files where fortran common variables are sizeable.

Although this is reported against fortran, it is possible that it also
manifests for other components.

credit for reporting this to  Andy Nelson


-- 
   Summary: huge object files generated for un-initialized data
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: developer at sandoe-acoustics dot co dot uk
GCC target triplet: *-apple-darwin*


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

[Bug fortran/43481] huge object files generated for un-initialized data

[developer at sandoe-acoustics dot co dot uk]

--- Comment #1 from developer at sandoe-acoustics dot co dot uk  2010-03-22 
16:18 ---
Created an attachment (id=20160)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20160&action=view)
reduced testcase

this compiles to an 7.6Mb object on current trunk.


-- 


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

[Bug fortran/43481] huge object files generated for un-initialized data

[developer at sandoe-acoustics dot co dot uk]

--- Comment #2 from developer at sandoe-acoustics dot co dot uk  2010-03-22 
16:21 ---
Created an attachment (id=20161)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20161&action=view)
provisional fix against 157594

this is plagiarized in its entirety from  apple/llvm 4.2 (was fixed in that
tree in 2002 apparently).  
Credit for the fix should go to turley.

reg-tested on i686-apple-darwin9.


-- 


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

[Bug middle-end/43475] [4.5 Regression] ICE in form_sum, at reload.c:5348

[matz at gcc dot gnu dot org]

--- Comment #3 from matz at gcc dot gnu dot org  2010-03-22 16:29 ---
Subject: Bug 43475

Author: matz
Date: Mon Mar 22 16:28:51 2010
New Revision: 157640

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157640
Log:
PR middle-end/43475
* recog.c (validate_replace_rtx_group): Replace also in
REG_EQUAL and REG_EQUIV notes.

testsuite/
* gfortran.dg/pr43475.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/pr43475.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/recog.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug testsuite/43482] New: Fix *.log tests merged output containing "==="

[jan dot kratochvil at redhat dot com]

Posted at, creating PR as its tracker:
  http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00309.html

while *.sum files were OK the *.log files sometimes miss the content present
in *.sum results.  For example [GDB gdb.base/bitfields.exp output was missing
while gdb.base/bitfields.exp output was present].

It got broken if arbitrary "===" string has appeared in the tests output.

Grepped dejagnu the proposed more strict pattern should match fine:

$ grep === `rpm -ql dejagnu`
/usr/share/dejagnu/framework.exp:   clone_output "\n\t\t=== $tool Summary
for $current_target_name ===\n"
/usr/share/dejagnu/framework.exp:   clone_output "\n\t\t=== $tool Summary
===\n"
/usr/share/dejagnu/runtest.exp:clone_output "\n\t\t=== $tool tests ===\n"

For GDB `grep '^Running ' gdb.log | wc -l' changes 1770 -> 1818.
For GCC `cat *.log | wc -l' changes 444633 -> 482178.
(checked the output change looks OK for both cases)

I am not aware why there was "/\===/" instead of just "/===/".

contrib/
2010-03-08  Jan Kratochvil  

Fix *.log tests output containing "===".
* dg-extract-results.sh (/\===/): Rename to ...
(/^\t\t=== .* ===$/): ... this pattern.


-- 
   Summary: Fix *.log tests merged output containing "==="
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com


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

[Bug middle-end/43475] [4.5 Regression] ICE in form_sum, at reload.c:5348

[matz at gcc dot gnu dot org]

--- Comment #4 from matz at gcc dot gnu dot org  2010-03-22 16:30 ---
Fixed.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug testsuite/43482] Fix *.log tests merged output containing "==="

[jan dot kratochvil at redhat dot com]

--- Comment #1 from jan dot kratochvil at redhat dot com  2010-03-22 16:30 
---
Created an attachment (id=20162)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20162&action=view)
Fix.


-- 


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

[Bug tree-optimization/43415] [4.4 Regression] Consumes large amounts of memory and time in PRE at -O3

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-03-22 16:33 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/43415] [4.4 Regression] Consumes large amounts of memory and time in PRE at -O3

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2010-03-22 16:33 ---
Subject: Bug 43415

Author: rguenth
Date: Mon Mar 22 16:32:58 2010
New Revision: 157641

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157641
Log:
2010-03-22  Richard Guenther  

Backport from mainline:
2010-03-19  Richard Guenther  

PR tree-optimization/43415
* tree-ssa-pre.c (phi_translate): Split out worker to ...
(phi_translate_1): ... this.
(phi_translate): Move all caching here.  Cache all NARY
and REFERENCE translations.

* gcc.c-torture/compile/pr43415.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr43415.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/tree-ssa-pre.c


-- 


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

[Bug c++/43333] [4.5 Regression] __is_pod seems broken

[matz at gcc dot gnu dot org]

--- Comment #8 from matz at gcc dot gnu dot org  2010-03-22 16:34 ---
Re comment #6: well, then we still need to fix the c++98 case.
Re comment #7: note carefully how I have avoided is_pod<> in the testcase,
but instead used the internal mean to implement the former.  That's the
regression I'm interested about.  (well, to tell the truth I would also
consider it a regression of is_pod<>, if not by the letter of the standard,
then as quality of implementation, because we _do_ have compiler support)


-- 


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

[Bug c++/43333] [4.5 Regression] __is_pod seems broken

[paolo dot carlini at oracle dot com]

--- Comment #9 from paolo dot carlini at oracle dot com  2010-03-22 16:43 
---
Michael, I'm not sure to follow all the philosophical details of the issue. To
be sure:
1- __is_pod implements, to date, the correct C++0x semantics, modulo ISO DRs
(probably forthcoming, but a resolution seems quite far)
2- Thus, by definition, __is_pod is the right way to implement std::is_pod.
3- About tr1::is_pod, the issue is a little more muddled, but given my Comment
#7, we cannot really do wrong as regards TR1 is concerned (and, frankly I don't
care much about TR1). Note that the semantics of tr1::is_pod already changed
once, when __is_pod started to be used as an implementation detail.

All in all, if you ask me, until the ISO DR issue is resolved I don't think we
should do anything here.


-- 


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

[Bug target/43481] huge object files generated for un-initialized data

[jb at gcc dot gnu dot org]

--- Comment #3 from jb at gcc dot gnu dot org  2010-03-22 16:51 ---
Seems to be a target bug, nothing to do with the Fortran frontend. 

Also, unless "turley" has a copyright assignment on file with the FSF (didn't
find him/her in the MAINTAINERS file), the patch unfortunately cannot be
accepted.


-- 

jb at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|fortran |target


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

[Bug c++/43333] [4.5 Regression] __is_pod seems broken

[matz at gcc dot gnu dot org]

--- Comment #10 from matz at gcc dot gnu dot org  2010-03-22 16:54 ---
Hmm, well, but there's code out there that expects the "old" TR1 semantic,
namely blocxx, and if the definition is indeed muddled than IMNSHO we should
retain the behaviour as it was in older GCC versions, instead of breaking
existing code.


-- 


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

[Bug target/43481] huge object files generated for un-initialized data

[developer at sandoe-acoustics dot co dot uk]

--- Comment #4 from developer at sandoe-acoustics dot co dot uk  2010-03-22 
16:59 ---
(In reply to comment #3)

> Also, unless "turley" has a copyright assignment on file with the FSF (didn't
> find him/her in the MAINTAINERS file), the patch unfortunately cannot be
> accepted.

It's from the apple / llvm tree which is already under FSF license - albeit V2. 
INAL - but I'm under the impression that there's no barrier to ports from that
tree (other than time/effort/skill).


-- 


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

[Bug c++/43333] [4.5 Regression] __is_pod seems broken

[paolo dot carlini at oracle dot com]

--- Comment #11 from paolo dot carlini at oracle dot com  2010-03-22 17:07 
---
We discussed a bit the issue with Jason in Pittsburgh *before* realizing that
likely the C++1x WD is wrong about not categorizing strPOD as POD, which now
seems the real issue. My personal point of view is still that all the builtins
should reflect, consistently, the ISO C++1x semantics. As an interim solution,
until the ISO defect is resolved, we could have an __is_cxx98_pod and an
__is_pod. That would be my preference. Jason - again, before realizing that we
have a real ISO issue - proposed changing back __is_pod to the c++98 semantics
and using __is_trivially_copyable and __is_standard_layout to implement
std::is_pod. Frankly, long term, I don't think this is the most consistent and
clear solution, in particular to people using the naked builtins, which then
would have to learn that *all* the builtins reflect the C++1x semantics
*beside* __is_pod. But what can I say, if you really think this is the best
interim solution, I can live with it, only let's make **really** sure an ISO
issue is opened and resolved quickly, clarifying the mess + let's document
those semantics.


-- 


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

[Bug testsuite/43482] Fix *.log tests merged output containing "==="

[jan dot kratochvil at redhat dot com]

--- Comment #2 from jan dot kratochvil at redhat dot com  2010-03-22 17:55 
---
Checked-in:
http://gcc.gnu.org/viewcvs?view=revision&revision=157645

2010-03-22  Jan Kratochvil  

Fix *.log tests output containing "===".
* dg-extract-results.sh (/\===/): Rename to ...
(/^\t\t=== .* ===$/): ... this pattern.


-- 

jan dot kratochvil at redhat dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug debug/43479] Missing DW_TAG_lexical_block+DW_TAG_variable

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-03-22 18:01 ---
Well, in this particular case I believe it is correct.
In *.optimized we have:
f ()
{
:
  # DEBUG y => 1
  # DEBUG x => 1
  return 1;
}
where return 1, the only actual statement left, has the function body lexical
block as opposed to the nested lexical block, and as no insn is in the scope of
that block, it doesn't make any sense to emit it.

I have a different testcase though:
void
foo (int k, int l, int m, int n)
{
  l++;
  {
int h = n;
{ int i = k; k++; }
{ int j = m; m++; }
  }
  asm volatile ("" : : "r" (k), "r" (l), "r" (m));
}
and the generated code on x86_64 has 3 addl $1, reg insns, and still optimizing
away the nested lexical blocks.  In this case I believe two of them should be
said to be in the inner scope.


-- 


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

[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants

[tromey at gcc dot gnu dot org]

--- Comment #19 from tromey at gcc dot gnu dot org  2010-03-22 18:21 ---
Created an attachment (id=20163)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20163&action=view)
undebugged patch to track macro expansion locations

I wanted to record my unfinished patch to track macro expansion locations,
and this bug seemed like an appropriate place.


-- 


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

[Bug debug/43479] Missing DW_TAG_lexical_block+DW_TAG_variable

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-03-22 18:22 ---
In the second testcase it is actually TER that breaks this (both on the trunk
and 4.4-RH).
In *.nrv we still have:
  [d.c : 4:4] l_2 = l_1(D) + 1;
  [d.c : 4:4] # DEBUG l => l_2
  [d.c : 6:9] # DEBUG h => n_3(D)
  [d.c : 7:11] # DEBUG i => k_5(D)
  [d.c : 7:19] k_7 = k_5(D) + 1;
  [d.c : 7:19] # DEBUG k => k_7
  [d.c : 8:11] # DEBUG j => m_8(D)
  [d.c : 8:19] m_10 = m_8(D) + 1;
  [d.c : 8:19] # DEBUG m => m_10
  [d.c : 10:3] __asm__ __volatile__("" :  : "r" k_7, "r" l_2, "r" m_10);
  [d.c : 11:1] return;
and the right block.  Not sure why we do TER for "r" constraint, but even if we
do and it turns that some of the generated insns match what has been TERed, it
would be good to adjust locus and block of the insns.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||matz at gcc dot gnu dot org


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

[Bug c++/19351] operator new[] can return heap blocks which are too small

[tglek at mozilla dot com]

--- Comment #18 from tglek at mozilla dot com  2010-03-22 18:40 ---
Perhaps someone could turn this into a landable patch
https://bugzilla.mozilla.org/attachment.cgi?id=352646&action=edit

This seemed to fix the problem for us


-- 


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

[Bug target/43481] huge object files generated for un-initialized data

[developer at sandoe-acoustics dot co dot uk]

--- Comment #5 from developer at sandoe-acoustics dot co dot uk  2010-03-22 
18:55 ---
(In reply to comment #3)

> Also, unless "turley" has a copyright assignment on file with the FSF (didn't
> find him/her in the MAINTAINERS file), the patch unfortunately cannot be
> accepted.

for the record also - my typo:

the fix author was Turly O'Connor (tu...@apple.com) listed in the MAINTAINER's
file for the tree revision from which the patch was taken  [although not listed
in MAINTAINERs for trunk]


-- 


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

[Bug target/33120] Data not put in BSS section on Mac OS

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2010-03-22 18:57 ---
*** Bug 43481 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||developer at sandoe-
   ||acoustics dot co dot uk


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

[Bug target/43481] huge object files generated for un-initialized data

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2010-03-22 18:57 ---


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


-- 

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

[Bug debug/43478] Missing DW_AT_location for a variable

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-03-22 19:16 ---
Several issues:
1) reassoc changes:
  [pr43478.c : 6:9] D.2722_1 = h ();
  [pr43478.c : 6:5] x_2 = D.2722_1 * 2;
  [pr43478.c : 6:5] # DEBUG x => x_2
  [pr43478.c : 7:9] D.2723_3 = h ();
  [pr43478.c : 7:5] y_4 = D.2723_3 * 2;
  [pr43478.c : 7:5] # DEBUG y => y_4
  [pr43478.c : 8:3] D.2724_5 = x_2 + y_4;
  return D.2724_5;
into
  [pr43478.c : 6:9] D.2722_1 = h ();
  [pr43478.c : 6:5] # DEBUG x => [pr43478.c : 6] D.2722_1 * 2
  [pr43478.c : 7:9] D.2723_3 = h ();
  D.2728_2 = D.2723_3 + D.2722_1;
  D.2728_4 = D.2728_2 * 2;
  [pr43478.c : 7:5] # DEBUG y => [pr43478.c : 7] D.2723_3 * 2
  [pr43478.c : 8:3] D.2724_5 = D.2728_4;
  return D.2724_5;
Perhaps it would be helpful if the DEBUG stmt got moved first in this case if
it in the end only references SSA names from before the statements.
2) during fwprop1, the well known DF dropping DEBUG_INSNS referencing DEAD
stmts
triggers:
(insn 9 8 10 2 pr43478.c:7 (set (reg:SI 60 [ D.2723 ])
(reg:SI 0 ax)) 47 {*movsi_1} (nil))

(insn 10 9 11 2 pr43478.c:7 (parallel [
(set (reg:SI 59 [ D.2728 ])
(plus:SI (reg:SI 60 [ D.2723 ])
(reg:SI 58 [ D.2722 ])))
(clobber (reg:CC 17 flags))
]) 251 {*addsi_1} (nil))

(debug_insn 11 10 12 2 pr43478.c:7 (var_location:SI y (mult:SI (reg:SI 60 [
D.2723 ])
(const_int 2 [0x2]))) -1 (nil))
becomes:
(insn 9 8 10 2 pr43478.c:7 (set (reg:SI 60 [ D.2723 ])
(reg:SI 0 ax)) 47 {*movsi_1} (expr_list:REG_DEAD (reg:SI 0 ax)
(nil)))

(insn 10 9 11 2 pr43478.c:7 (parallel [
(set (reg:SI 59 [ D.2728 ])
(plus:SI (reg:SI 60 [ D.2723 ])
(reg:SI 58 [ D.2722 ])))
(clobber (reg:CC 17 flags))
]) 251 {*addsi_1} (expr_list:REG_DEAD (reg:SI 60 [ D.2723 ])
(expr_list:REG_DEAD (reg:SI 58 [ D.2722 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)

(debug_insn 11 10 12 2 pr43478.c:7 (var_location:SI y (clobber (const_int 0
[0x0]))) -1 (nil))
because reg:SI 60 is REG_DEAD in the insn before it.  In this case we even
can't
rematerialize it as (mult:SI (minus:SI (reg:SI 59) (reg:SI 58)) (const_int 2))
(while plus is reversible operation, both pseudos 60 and 58 are REG_DEAD in the
previous insn).
3) even if we handle this all the way through to var-tracking, while in theory
we can express it on the addition insn, the variable value is irrevocably lost
on the shl $1, %eax insn.


-- 


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

[Bug rtl-optimization/43413] Powerpc generates worse code for -mvsx on gromacs even though there are no VSX instructions used

[law at redhat dot com]

--- Comment #4 from law at redhat dot com  2010-03-22 19:49 ---
FWIW, I seem to get considerably worse code from mainline than you -- for -O3
-ffast-math -mcpu=power7 -mvsx -maltivec I get 140 stfs and 192 lfs insns
(compared to 117 & 139 respectively that you reported).

Just for fun, I ran the same code through the a ppc compiler with the LRS code
from reload-v2 and get 133:178 stfs/lsf insns, so that code clearly is helping,
but it's not enough to offset the badness shown by IRA.


I couldn't reconcile how -fno-ira-share-spill-slots would be changing the
number of load/store insns, so I poked at that a bit. 
-fno-ira-share-spill-slots twiddles whether or not a pseudo which gets assigned
a hard reg is put into live_throughout or dead_or_set_p in the reload chain
structures, which in turn changes what pseudos get reassigned hard regs during
reload.  This is a somewhat odd effect and should be investigated further.



-- 

law at redhat dot com changed:

   What|Removed |Added

Summary|Powerpc generates worse code|Powerpc generates worse code
   |for -mvsx on gromacs even   |for -mvsx on gromacs even
   |though there are no VSX |though there are no VSX
   |instructions used   |instructions used


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

[Bug libstdc++/43483] New: STL sort SIGSEV

[richardlee at snowshoefox dot com]

The STL sort implementation in stl_algo.h SIGSEVs under certain conditions due
to not checking the position of the __first and __last iterator positions.

Here is a diff between a working version and the buggy version in 4.4.1:

2228d2227
<   int len = __last - __first;
2231c2230
< while (__first != __last && __comp(*__first, __pivot))
---
> while (__comp(*__first, __pivot))
2233,2234c2232,2233
< --__last; 
< while (len-- > 0 && __comp(__pivot, *__last))
---
> --__last;
> while (__comp(__pivot, *__last))

The fix is to make sure __first and __last stays within the boundary of
[__first, __last).


-- 
   Summary: STL sort SIGSEV
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: richardlee at snowshoefox dot com
  GCC host triplet: 2.6.31-20-generic #58-Ubuntu SMP x86_64 GNU/Linux


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

[Bug libstdc++/43483] STL sort SIGSEV

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-03-22 20:05 
---
Please provide a complete, self-contained testcase, otherwise nothing will
happen.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug rtl-optimization/43484] New: GCC 4.5 does not build gamess, zeusmp on powerpc -m32 with loop unrolling

[meissner at gcc dot gnu dot org]

If I build gamess and zeusmp with my normal spec optimization options, I get an
internal compiler error in the change_address_1 function in emit-rtl.c, due to
an address needing fixup has been generated after register allocation has been
done.  I have narrowed the options down to -m32 -mcpu=power4 -O2 -funroll-loops
that causes the problem.  I was able to build all of spec with the normal
options on March 3rd.

foo.f: In function ‘gcidav’:
foo.f:670:0: internal compiler error: in change_address_1, at emit-rtl.c:1912
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: GCC 4.5 does not build gamess, zeusmp on powerpc -m32
with loop unrolling
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: meissner at gcc dot gnu dot org
 GCC build triplet: powerpc64-unknown-linux-gnu
  GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu


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

[Bug rtl-optimization/43484] GCC 4.5 does not build gamess, zeusmp on powerpc -m32 with loop unrolling

[meissner at gcc dot gnu dot org]

--- Comment #1 from meissner at gcc dot gnu dot org  2010-03-22 20:11 
---
Created an attachment (id=20164)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20164&action=view)
Reduced function that causes the problem

To replicate this, use -m32 -O2 -mcpu=power4 -funroll-loops


-- 


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

[Bug target/38085] gcc -m64 -pg generates invalid assembler code on Solaris 10/x86

[ro at gcc dot gnu dot org]

--- Comment #8 from ro at gcc dot gnu dot org  2010-03-22 20:12 ---
Subject: Bug 38085

Author: ro
Date: Mon Mar 22 20:12:34 2010
New Revision: 157648

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157648
Log:
gcc:
PR target/38085
* config/i386/i386.c (x86_function_profiler)
[!NO_PROFILE_COUNTERS]: Fix typo.
* config/i386/gmon-sol2.c (_mcleanup) [__x86_64__]: Use call
instead of callq.

libgcc:
PR target/38085
* config/i386/t-sol2 ($(T)gmon.o): Use CFLAGS instead of
MULTILIB_CFLAGS.
($(T)gcrt1.o): Likewise.
($(T)crt1.o): Likewise.
($(T)crti.o): Likewise.
($(T)crtn.o): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/gmon-sol2.c
trunk/gcc/config/i386/i386.c
trunk/libgcc/ChangeLog
trunk/libgcc/config/i386/t-sol2


-- 


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

[Bug libstdc++/43483] STL sort SIGSEV

[richardlee at snowshoefox dot com]

--- Comment #2 from richardlee at snowshoefox dot com  2010-03-22 20:18 
---
Created an attachment (id=20165)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20165&action=view)
Proposed patch using 'patch -up'... run patch in the 4.4.1/bits/ folder.


-- 


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

[Bug rtl-optimization/43484] [4.5 Regression] GCC 4.5 does not build gamess, zeusmp on powerpc -m32 with loop unrolling

[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
   Keywords||ice-on-valid-code
Summary|GCC 4.5 does not build  |[4.5 Regression] GCC 4.5
   |gamess, zeusmp on powerpc - |does not build gamess,
   |m32 with loop unrolling |zeusmp on powerpc -m32 with
   ||loop unrolling
   Target Milestone|--- |4.5.0


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

[Bug libstdc++/43483] STL sort SIGSEV

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2010-03-22 20:26 
---
The patch is incorrect for various formal reasons (eg, should be against
current mainline not vs a random old release; should use difference_type, not
int; should use an uglified __len) + should come with a detailed analysis and a
ChangeLog entry. Even more important now, at this preliminary stage, it lacks a
small, self contained testcase, useful to reproduce the proble: missing it the
PR will be soon closed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

   Severity|major   |normal


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

[Bug c++/43281] [c++0x] ICE with invalid auto

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2010-03-22 20:39 ---
Subject: Bug 43281

Author: jason
Date: Mon Mar 22 20:38:46 2010
New Revision: 157651

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157651
Log:
PR c++/43281
* pt.c (contains_auto_r): New fn.
(do_auto_deduction): Use it.
(tsubst): Don't look at TREE_TYPE of a TEMPLATE_TYPE_PARM.

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


-- 


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

[Bug c++/43333] [4.5 Regression] __is_pod seems broken

[jason at gcc dot gnu dot org]

--- Comment #12 from jason at gcc dot gnu dot org  2010-03-22 20:39 ---
Subject: Bug 4

Author: jason
Date: Mon Mar 22 20:38:57 2010
New Revision: 157652

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157652
Log:
PR c++/4
* tree.c (pod_type_p): Use old meaning in C++98 mode.

Added:
trunk/gcc/testsuite/g++.dg/ext/is_pod_98.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/is_pod.C


-- 


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

[Bug target/38085] gcc -m64 -pg generates invalid assembler code on Solaris 10/x86

[ro at gcc dot gnu dot org]

--- Comment #9 from ro at gcc dot gnu dot org  2010-03-22 20:39 ---
Fixed for 4.5.0.


-- 

ro 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=38085

[Bug target/42040] [ia64] Inappropriate address spills

[sje at cup dot hp dot com]

--- Comment #12 from sje at cup dot hp dot com  2010-03-22 20:48 ---
Since the proposed patch to meant to address non-optimimal code generation I
decided to try the patch with SPEC2006 and see if it helped the performance. On
SPECint, I got a 3% slowdown, mostly due to 429.mcf slowing down a lot (20%). 
471.omnetap also slowed down (7%) and nothing else changed much.  With SPECfp,
we got a 0.36% speedup, with 434.zeusmp (4.4%) and 459.GemsFTDT (3.39%)
speeding up the most and no significant slowdowns.  I will try to see what
happened with 429.mcf and see why that slowed down so much.


-- 


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

[Bug rtl-optimization/43484] [4.5 Regression] GCC 4.5 does not build gamess, zeusmp on powerpc -m32 with loop unrolling

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-03-22 20:49 ---
apin...@apinski-desktop:~/src/gcc-fsf/local/gcc/objdir-ppc/gcc$ ./gfortran -B.
t.f -S -m32 -mcpu=power4 -O2 -funroll-loops -v
Using built-in specs.
COLLECT_GCC=./gfortran
Target: powerpc64-linux-gnu
Configured with: ../configure --target=powerpc64-linux-gnu --enable-tls :
(reconfigured) 
Thread model: posix
gcc version 4.5.0 20100322 (experimental) [trunk revision 157646] (GCC) 
COLLECT_GCC_OPTIONS='-B.' '-S' '-m32' '-mcpu=power4' '-O2' '-funroll-loops'
'-v'
 ./f951 t.f -ffixed-form -quiet -dumpbase t.f -m32 -mcpu=power4 -auxbase t -O2
-version -funroll-loops -o t.s -fintrinsic-modules-path finclude
GNU Fortran (GCC) version 4.5.0 20100322 (experimental) [trunk revision 157646]
(powerpc64-linux-gnu)
compiled by GNU C version 4.3.2, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) version 4.5.0 20100322 (experimental) [trunk revision 157646]
(powerpc64-linux-gnu)
compiled by GNU C version 4.3.2, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
COMPILER_PATH=./
LIBRARY_PATH=./
COLLECT_GCC_OPTIONS='-B.' '-S' '-m32' '-mcpu=power4' '-O2' '-funroll-loops'
'-v'


This works for me with a cross, am I missing an option?


-- 


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

[Bug c++/43333] [4.5 Regression] __is_pod seems broken

[jason at gcc dot gnu dot org]

--- Comment #13 from jason at gcc dot gnu dot org  2010-03-22 20:49 ---
Fixed by reverting to old semantics in C++98 mode.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/43281] [c++0x] ICE with invalid auto

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2010-03-22 20:50 ---
Fixed.


-- 

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

[Bug libstdc++/43483] STL sort SIGSEV

[richardlee at snowshoefox dot com]

--- Comment #4 from richardlee at snowshoefox dot com  2010-03-22 20:55 
---
Here is a very simplified version of the scenario that triggered the bug.

bool compare(int t1, int t2) {
return true;
}

int main(int argc, char** argv) {
vector v;
v.assign(32, 2);
cout << v.size() << endl; 
sort(v.begin(), v.end(), compare);
}


-- 


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

[Bug rtl-optimization/43484] [4.5 Regression] GCC 4.5 does not build gamess, zeusmp on powerpc -m32 with loop unrolling

[meissner at gcc dot gnu dot org]

--- Comment #3 from meissner at gcc dot gnu dot org  2010-03-22 21:02 
---
I just replicated on my x86_64 cross compiler:

bug-43484.f: In function ‘gcidav’:
bug-43484.f:670:0: internal compiler error: in change_address_1, at
emit-rtl.c:1912
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I used the following configure options:
 --enable-languages=c,c++,fortran --enable-stage1-languages=c,c++,fortran
--disable-bootstrap --enable-checking=release --enable-stage1-checking
--enable-decimal-float --with-long-double-128 --enable-secureplt
--target=powerpc64-linux --disable-shared --disable-libssp --enable-lto


-- 


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

[Bug rtl-optimization/43484] [4.5 Regression] GCC 4.5 does not build gamess, zeusmp on powerpc -m32 with loop unrolling

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2010-03-22 21:04 ---
>-with-long-double-128 --enable-secureplt

Those two options might cause the difference for me.  Let me reconfigure my
build and try again.


-- 


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

[Bug middle-end/31241] Post Increment opportunity missed

[ramana at gcc dot gnu dot org]

--- Comment #6 from ramana at gcc dot gnu dot org  2010-03-22 21:16 ---
Unrolling the loop still doesn't show better use of auto-incs.


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||missed-optimization


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

[Bug libstdc++/43483] STL sort SIGSEV

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2010-03-22 21:24 
---
compare is not irreflexive, as it must be per 25.3/4.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug ada/43485] New: select ... then abort ... end select don't abort

[vaurele at gmx dot com]

On the small program below, "Something_Usefull" is never aborted: when I enter
a string, my CPU usage go to 100% but then Put_Line following the "select then
abort" is never executed.

This was observed on my Ubuntu Karmic with gnat-4.4 and gnat-4.3. A friend of
mine reproduced it with 4.4.3 and 4.5.0

for information:
% gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)


---
with Ada.Text_IO; use Ada.Text_IO;
with Ada.Real_Time; use Ada.Real_Time;

procedure Test_Select is
 type State_Type is (Start, Stop);
 protected State is
   procedure Set (Value : State_Type);
   entry Wait_For (State_Type);
 private
   Current : State_Type := Stop;
 end State;

 protected body State is
   procedure Set (Value : State_Type) is
   begin
 Current := Value;
   end Set;

   entry Wait_For (for S in State_Type) when Current = S is
   begin
 null;
   end Wait_For;
 end State;

 task Keyboard;
 task body Keyboard is
 begin
   declare
 S : String(1 .. 1024);
 Last : Integer;
 pragma Unreferenced (Last);
   begin
 Get_Line (S, Last);
 State.Set (Start);
 Put_Line ("State is now 'Start'");
   end;
 end Keyboard;

 procedure Something_Usefull is
 begin
   loop
 null;
 delay until Clock + To_Time_Span (0.1);
   end loop;
 end Something_Usefull;

begin
 Put_Line ("Before select");
 select
   State.Wait_For (Start);
 then abort
   Something_Usefull;
 end select;
 Put_Line ("Done");
end Test_Select;


-- 
   Summary: select ... then abort ... end select don't abort
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vaurele at gmx 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=43485

[Bug target/14352] New FP code not compiled for non-arm-elf targets

[ramana at gcc dot gnu dot org]

--- Comment #6 from ramana at gcc dot gnu dot org  2010-03-22 21:46 ---
This refers to the arm-linux and arm-elf configurations which are largely in
maintenance mode only now. Pulling priority down to P5 and marking as an
enhancement. 


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Priority|P2  |P5


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

[Bug target/43435] [4.3/4/4 Regression] SH: Bad registers are restored before ISR is leaved

[kkojima at gcc dot gnu dot org]

--- Comment #2 from kkojima at gcc dot gnu dot org  2010-03-22 22:02 ---
I've confirmed that this is 4.3/4.4 regression solved on trunk with
the patch mentioned in #1.  I'll backport the patch to 4.3/4.4 branches
when it passes the usual test on those branches.


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to fail||4.3.4 4.4.3
  Known to work||4.2.4 4.5.0
   Priority|P3  |P4
   Last reconfirmed|-00-00 00:00:00 |2010-03-22 22:02:15
   date||
Summary|Bad registers are restored  |[4.3/4/4 Regression] SH: Bad
   |before ISR is leaved|registers are restored
   ||before ISR is leaved


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

[Bug rtl-optimization/43413] Powerpc generates worse code for -mvsx on gromacs even though there are no VSX instructions used

[vmakarov at redhat dot com]

--- Comment #5 from vmakarov at redhat dot com  2010-03-22 22:16 ---
(In reply to comment #0)
> 
> In the enclosed test case, it generates the following spills for the options:
> -O3 -ffast-math -mcpu=power7 -mvsx -maltivec: 117 stfs, 139 lfs
> -O3 -ffast-math -mcpu=power5 -maltivec: 80 stfs, 100 lfs
> -O3 -ffast-math -mcpu=power5: 80 stfs, 100 lfs

Hi, Mike.  I think the comparison should be done with the same -mcpu because
there is 1st insn scheduling which increases register pressure differently for
different architectures.  But that is not so important.  I see a lot of spills
during assigning because memory is more profitable.  Graph coloring pushes them
on the stack suggesting that they get registers (and that is not happened
during the assignment).

On one my branch, I got 
-O3 -ffast-math -mcpu=power7 -mno-vsx -maltivec: 248 of stfs and lfs
-O3 -ffast-math -mcpu=power7 -mvsx -maltivec: 331 of stfs and lfs
-O3 -ffast-math -mcpu=power7 -mvsx -maltivec -fsched-pressure: 310
-O3 -ffast-math -mcpu=power7 -mvsx -maltivec -fsched-pressure -fexper: 179

Where -fexper switches on a new graph coloring code without cover classes which
I am working on.

So I think that this new code and register pressure sensitive insn scheduling
will help.

Still I'll investigate a bit more why there are a lot of unexpected spills
during assignment with -mvsx for the current code.


-- 


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

[Bug rtl-optimization/43413] Powerpc generates worse code for -mvsx on gromacs even though there are no VSX instructions used

[vmakarov at redhat dot com]

--- Comment #6 from vmakarov at redhat dot com  2010-03-22 22:20 ---
(In reply to comment #4)
> FWIW, I seem to get considerably worse code from mainline than you -- for -O3
> -ffast-math -mcpu=power7 -mvsx -maltivec I get 140 stfs and 192 lfs insns
> (compared to 117 & 139 respectively that you reported).
> 

I suspect the differnce is because Mike calculated only stfs/lfs and you
stfs(x)/lfs(x).  But may be I am wrong.

> Just for fun, I ran the same code through the a ppc compiler with the LRS code
> from reload-v2 and get 133:178 stfs/lsf insns, so that code clearly is 
> helping,
> but it's not enough to offset the badness shown by IRA.
> 
> 
> I couldn't reconcile how -fno-ira-share-spill-slots would be changing the
> number of load/store insns, so I poked at that a bit.

Yes, I cannot understand that too.

> -fno-ira-share-spill-slots twiddles whether or not a pseudo which gets 
> assigned
> a hard reg is put into live_throughout or dead_or_set_p in the reload chain
> structures, which in turn changes what pseudos get reassigned hard regs during
> reload.  This is a somewhat odd effect and should be investigated further.
> 
> 


-- 


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