[Bug middle-end/40981] aermod.f90 ICEs on -O2 -fgraphite-identity -floop-strip-mine

[spop at gcc dot gnu dot org]

--- Comment #27 from spop at gcc dot gnu dot org  2009-08-15 07:10 ---
Subject: Bug 40981

Author: spop
Date: Sat Aug 15 07:10:20 2009
New Revision: 150789

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150789
Log:
Correct the use of ppl_Pointset_Powerset_C_Polyhedron_maximize.

2009-08-15  Sebastian Pop  

PR middle-end/40981
* graphite-interchange.c (ppl_max_for_le): Moved...
* graphite-poly.c (pbb_number_of_iterations): Call ppl_max_for_le.
* graphite-ppl.c (ppl_max_for_le): ... here.  Correct the use of
ppl_Pointset_Powerset_C_Polyhedron_maximize.
* graphite-ppl.h (ppl_max_for_le): Declared.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ChangeLog.graphite
trunk/gcc/graphite-interchange.c
trunk/gcc/graphite-poly.c
trunk/gcc/graphite-ppl.c
trunk/gcc/graphite-ppl.h


-- 


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

[Bug target/41076] New: [avr] pessimal code for logical OR of 8-bit fields

[pb at gcc dot gnu dot org]

This trivial function:

unsigned short f(unsigned char a, unsigned char b)
{
  return a | (b << 8);
}

generates the code:

f:
/* prologue: function */
/* frame size = 0 */
mov r21,r22
ldi r20,lo8(0)
mov r18,r24
ldi r19,lo8(0)
or r18,r20
or r19,r21
mov r24,r18
mov r25,r19
/* epilogue start */
ret

In other words, GCC is first zero-extending the two 8-bit quantities to 16
bits, then performing a 16-bit logical OR operation on the result.  For each
half of the OR operation, though, one side is a constant zero and hence these
operations are redundant.

In this particular trivial case, the function could be implemented as:

mov r25, r21
ret

with all the other operations omitted.


-- 
   Summary: [avr] pessimal code for logical OR of 8-bit fields
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pb at gcc dot gnu dot org
GCC target triplet: avr-elf


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

[Bug fortran/31593] Invariant DO loop variables and subroutines

[jv244 at cam dot ac dot uk]

--- Comment #27 from jv244 at cam dot ac dot uk  2009-08-15 07:50 ---
(In reply to comment #26)
> If it weren't for the outermost loop it would actually be perfectly legal to
> modify 'value' inside the loops.  If there were a way of telling the compiler
> "this pointer can't escape" this would be really easy to solve.

actually value can be legally modified in the inner loops (I believe), only it
doesn't influence the loop count (which is determined before the loop start). I
believe it is only the do loop variable which is not allowed to be modified.


-- 


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

[Bug fortran/31593] Invariant DO loop variables and subroutines

[jv244 at cam dot ac dot uk]

--- Comment #28 from jv244 at cam dot ac dot uk  2009-08-15 07:53 ---
(In reply to comment #23)

>   subroutine output(i1,i2,i3,i4,i5)
> print '(5(I0,:" "))',i1,i2,i3,i4,i5
>   end subroutine output

[..]

>  if (p1 * p2 * p3 * p4 == value * 100) &
>  & call output(value,p1,p2,p3,p4)
[..]
>  if (p1 * p2 * p3 * p4 == value * 100) &
>  & call output((value),(p1),(p2),(p3),(p4))
> still produces much better code.

obviously this optimization is only allowed if the arguments of 'output' would
be explicitly declared intent in (or the compiler nows this, e.g. because it is
an intrinsic or e.g. a write statement).


-- 


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

[Bug target/41077] New: [avr] excessive prologue/epilogue for interrupt handler

[pb at gcc dot gnu dot org]

This function:

void __vector_7 (void) __attribute__ ((signal,used, externally_visible)) ; 

void __vector_7 (void)
{
 timerCounter++;
 (*(volatile uint8_t *)(0x89)) = 0;
 (*(volatile uint8_t *)(0x88)) = 0;
 (*(volatile uint8_t *)(0x7C)) = 0;
}

yields the code:

__vector_7: 
push __zero_reg__ 
push r0 
in r0,__SREG__ 
push r0 
clr __zero_reg__ 
push r24 
push r25 
/* prologue: Signal */ 
/* frame size = 0 */ 
lds r24,timerCounter 
lds r25,(timerCounter)+1 
adiw r24,1 
sts (timerCounter)+1,r25 
sts timerCounter,r24 
sts 137,__zero_reg__ 
sts 136,__zero_reg__ 
sts 124,__zero_reg__ 
/* epilogue start */ 
pop r25 
pop r24 
pop r0 
out __SREG__,r0 
pop r0 
pop __zero_reg__ 
reti 

Note that r0 is not clobbered by the function body so the save/restore of this
register is unnecessary.  Also note that, in this case, the usage of
__zero_reg__ could be replaced with one of r24 or r25, avoiding the need to
save and restore r1 as well.


-- 
   Summary: [avr] excessive prologue/epilogue for interrupt handler
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pb at gcc dot gnu dot org
GCC target triplet: avr-elf


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

[Bug fortran/31593] Invariant DO loop variables and subroutines

[tkoenig at gcc dot gnu dot org]

--- Comment #29 from tkoenig at gcc dot gnu dot org  2009-08-15 09:22 
---
Subject: Re:  Invariant DO loop variables and subroutines

On Sat, 2009-08-15 at 07:53 +, jv244 at cam dot ac dot uk wrote:
> 
> --- Comment #28 from jv244 at cam dot ac dot uk  2009-08-15 07:53 ---
> (In reply to comment #23)
> 
> >   subroutine output(i1,i2,i3,i4,i5)
> > print '(5(I0,:" "))',i1,i2,i3,i4,i5
> >   end subroutine output
> 
> [..]
> 
> >  if (p1 * p2 * p3 * p4 == value * 100) &
> >  & call output(value,p1,p2,p3,p4)
> [..]
> >  if (p1 * p2 * p3 * p4 == value * 100) &
> >  & call output((value),(p1),(p2),(p3),(p4))
> > still produces much better code.
> 
> obviously this optimization is only allowed if the arguments of 'output' would
> be explicitly declared intent in (or the compiler nows this, e.g. because it 
> is
> an intrinsic or e.g. a write statement).

It's the other way around:  If output were to modify any of its
arguments, the program would be illegal.  Therefore, the compiler can
assume that this doesn't happen.  Intent(in) would be redundant for this
particular case (though useful, so the compiler could easier detect
errors).


-- 


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

[Bug fortran/31593] Invariant DO loop variables and subroutines

[tkoenig at gcc dot gnu dot org]

--- Comment #30 from tkoenig at gcc dot gnu dot org  2009-08-15 09:25 
---
Subject: Re:  Invariant DO loop variables and subroutines

On Fri, 2009-08-14 at 22:58 +, tobi at gcc dot gnu dot org wrote:
> 
> --- Comment #26 from tobi at gcc dot gnu dot org  2009-08-14 22:58 ---
> (In reply to comment #25)
> > (In reply to comment #23)
> > 
> > Actually, you're right.  In nested loops, there's no way without copying.
> > 
> If it weren't for the outermost loop it would actually be perfectly legal to
> modify 'value' inside the loops.  If there were a way of telling the compiler
> "this pointer can't escape" this would be really easy to solve.

Escaping pointers for non-target dummy arguments can't happen in
Fortran, can they?  Could we just disable this (or ad a
TREE_CANNOT_ALIAS flag to the middle end, which is on by default for
Fortran)?


-- 


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

[Bug middle-end/41069] lto1: error: type mismatch in indirect reference

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2009-08-15 09:42 ---
Subject: Bug 41069

Author: rguenth
Date: Sat Aug 15 09:42:28 2009
New Revision: 150791

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150791
Log:
2009-08-15  Richard Guenther  

PR lto/41069
* gimple.c (gimple_types_compatible_p): Handle vector and complex
types.
* lto-streamer-out.c (lto_output_ts_decl_minimal_tree_pointers):
Do not give names to unnamed things.

* gfortran.dg/lto/lto.exp: Adjust glob pattern.
* gfortran.dg/lto/pr41069_0.f90: New testcase.
* gfortran.dg/lto/pr41069_1.f90: Likewise.
* gfortran.dg/lto/pr41069_2.f90: Likewise.

Added:
branches/lto/gcc/testsuite/gfortran.dg/lto/pr41069_0.f90
branches/lto/gcc/testsuite/gfortran.dg/lto/pr41069_1.f90
branches/lto/gcc/testsuite/gfortran.dg/lto/pr41069_2.f90
Modified:
branches/lto/gcc/ChangeLog.lto
branches/lto/gcc/gimple.c
branches/lto/gcc/lto-streamer-out.c
branches/lto/gcc/testsuite/ChangeLog.lto
branches/lto/gcc/testsuite/gfortran.dg/lto/lto.exp


-- 


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

[Bug fortran/31593] Invariant DO loop variables and subroutines

[tobi at gcc dot gnu dot org]

--- Comment #31 from tobi at gcc dot gnu dot org  2009-08-15 09:51 ---
(In reply to comment #30)
> Escaping pointers for non-target dummy arguments can't happen in
> Fortran, can they?  Could we just disable this (or ad a
> TREE_CANNOT_ALIAS flag to the middle end, which is on by default for
> Fortran)?

Yes.  I've asked Richard about this on the mailing list.  BTW with my patches,
aermodf90 runs ~8% faster, and the other polyhedron benchmarks also seem to
have consistently improved.


-- 


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

[Bug middle-end/41069] lto1: error: type mismatch in indirect reference

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2009-08-15 09:52 ---
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=41069

[Bug target/41076] [avr] pessimal code for logical OR of 8-bit fields

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-08-15 09:55 ---
because this is what C says you are doing:

  return (unsigned short) ((int) a | ((int) b << 8));

which is harder to transform back into what you expect.


-- 


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

[Bug fortran/31593] Invariant DO loop variables and subroutines

[jv244 at cam dot ac dot uk]

--- Comment #32 from jv244 at cam dot ac dot uk  2009-08-15 10:05 ---
(In reply to comment #29)

> It's the other way around:  If output were to modify any of its
> arguments, the program would be illegal.  Therefore, the compiler can
> assume that this doesn't happen.  Intent(in) would be redundant for this
> particular case (though useful, so the compiler could easier detect
> errors).
that's true for pX, but value can be modified by output. I.e. this is (afaict)
valid fortran that write the numbers from 1 to 10
n=10
DO i=1,n
n=0
write(6,*)i
ENDDO


-- 


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

[Bug fortran/31593] Invariant DO loop variables and subroutines

[Tobias Schlüter]

--- Comment #33 from =?ISO-8859-1?Q?Tobias_Schl=FCter?=
   2009-08-15 10:17 
---
Subject: Re:  Invariant DO loop variables and subroutines

jv244 at cam dot ac dot uk wrote:
> --- Comment #32 from jv244 at cam dot ac dot uk  2009-08-15 10:05 ---
> (In reply to comment #29)
> 
>> It's the other way around:  If output were to modify any of its
>> arguments, the program would be illegal.  Therefore, the compiler can
>> assume that this doesn't happen.  Intent(in) would be redundant for this
>> particular case (though useful, so the compiler could easier detect
>> errors).
> that's true for pX, but value can be modified by output. I.e. this is (afaict)
> valid fortran that write the numbers from 1 to 10
> n=10
> DO i=1,n
> n=0
> write(6,*)i
> ENDDO

Actually, we're buggy there, and my patch fixes it.  I'm just now trying 
out testcases.


-- 


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

[Bug fortran/31593] Invariant DO loop variables and subroutines

[tkoenig at gcc dot gnu dot org]

--- Comment #34 from tkoenig at gcc dot gnu dot org  2009-08-15 10:57 
---
(In reply to comment #33)

> Actually, we're buggy there, and my patch fixes it.  I'm just now trying 
> out testcases.

Are we really buggy?

$ cat gaga.f90
n=10
do i=1,n
call foo(n)
print *,i
end do
end

subroutine foo(n)
n=4
end
$ gfortran -O2 gaga.f90 && ./a.out
   1
   2
   3
   4
   5
   6
   7
   8
   9
  10
$ gfortran-4.4 -O2 gaga.f90 && ./a.out
   1
   2
   3
   4
   5
   6
   7
   8
   9
  10


-- 


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

[Bug fortran/31593] Invariant DO loop variables and subroutines

[Tobias Schlüter]

--- Comment #35 from =?ISO-8859-1?Q?Tobias_Schl=FCter?=
   2009-08-15 10:58 
---
Subject: Re:  Invariant DO loop variables and subroutines

tkoenig at gcc dot gnu dot org wrote:
> --- Comment #34 from tkoenig at gcc dot gnu dot org  2009-08-15 10:57 
> ---
> (In reply to comment #33)
> 
>> Actually, we're buggy there, and my patch fixes it.  I'm just now trying 
>> out testcases.
> 
> Are we really buggy?

No, I looked at the wrong thing, sorry.


-- 


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

[Bug middle-end/41069] lto1: error: type mismatch in indirect reference

[jv244 at cam dot ac dot uk]

--- Comment #10 from jv244 at cam dot ac dot uk  2009-08-15 12:12 ---
great... with this fix CP2K can be compiled and linked at -flto -O2


-- 


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

[Bug middle-end/41069] lto1: error: type mismatch in indirect reference

[rguenther at suse dot de]

--- Comment #11 from rguenther at suse dot de  2009-08-15 12:14 ---
Subject: Re:  lto1: error: type mismatch in indirect
 reference

On Sat, 15 Aug 2009, jv244 at cam dot ac dot uk wrote:

> --- Comment #10 from jv244 at cam dot ac dot uk  2009-08-15 12:12 ---
> great... with this fix CP2K can be compiled and linked at -flto -O2

You definitely want to add -fwhole-program for extra optimization and
a less overall program size.  Does CP2K also work? ;)

Richard.


-- 


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

[Bug middle-end/41069] lto1: error: type mismatch in indirect reference

[jv244 at cam dot ac dot uk]

--- Comment #12 from jv244 at cam dot ac dot uk  2009-08-15 12:25 ---
(In reply to comment #11)

> You definitely want to add -fwhole-program for extra optimization and
> a less overall program size.  

there are still the two issues I reported in PR40011 with  -fwhole-file.. hmm
actually -fwhole-program you say. I'll give it a try, but it is slow process,
-flto needs about 35min compile time and 10.5Gb RAM.

Can I relink tobjects compiled without -fwhole-program with that option, or do
compile time and 'lto'-time options need to match?

> Does CP2K also work? ;)

I only tried two tests, but these seem fine.


-- 


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

[Bug middle-end/41069] lto1: error: type mismatch in indirect reference

[rguenther at suse dot de]

--- Comment #13 from rguenther at suse dot de  2009-08-15 12:28 ---
Subject: Re:  lto1: error: type mismatch in indirect
 reference

On Sat, 15 Aug 2009, jv244 at cam dot ac dot uk wrote:

> 
> 
> --- Comment #12 from jv244 at cam dot ac dot uk  2009-08-15 12:25 ---
> (In reply to comment #11)
> 
> > You definitely want to add -fwhole-program for extra optimization and
> > a less overall program size.  
> 
> there are still the two issues I reported in PR40011 with  -fwhole-file.. hmm
> actually -fwhole-program you say. I'll give it a try, but it is slow process,
> -flto needs about 35min compile time and 10.5Gb RAM.

Doh.  How does that compare to the all-CP2K in one file builds?
Sounds like you might want to try -fwhopr as well ...

> Can I relink tobjects compiled without -fwhole-program with that option, or do
> compile time and 'lto'-time options need to match?

Yes, you can re-link with -fwhole-program, it is only relevant at link 
stage.

> > Does CP2K also work? ;)
> 
> I only tried two tests, but these seem fine.

Nice.

Richard.


-- 


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

[Bug debug/37801] DWARF output for inlined functions doesn't always use DW_TAG_inlined_subroutine

[dodji at gcc dot gnu dot org]

--- Comment #7 from dodji at gcc dot gnu dot org  2009-08-15 15:38 ---
Patch posted to http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00813.html .


-- 


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

[Bug bootstrap/41078] New: [4.5 Regression] Build failure with --enable-maintainer-mode

[tkoenig at gcc dot gnu dot org]

This is with revision 150791.

See http://gcc.gnu.org/ml/gcc/2009-08/msg00257.html

$ ../../gcc/trunk/configure --prefix=$HOME --enable-languages=c,fortran
--enable-maintainer-mode && make && make install

...

make[3]: Leaving directory `/var/work/gcc-bin/trunk/libdecnumber'
make[3]: Entering directory `/var/work/gcc-bin/trunk/gcc'
(cd ../../../gcc/trunk/gcc && aclocal -I ../config -I ..)
(cd ../../../gcc/trunk/gcc && autoconf)
configure:3123: error: possibly undefined macro: AC_REQUIRE_AUX_FILE
  If this token and others are legitimate, please use
m4_pattern_allow.
  See the Autoconf documentation.
make[3]: *** [../../../gcc/trunk/gcc/configure] Error 1
make[3]: Leaving directory `/var/work/gcc-bin/trunk/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/var/work/gcc-bin/trunk'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/var/work/gcc-bin/trunk'
make: *** [all] Error 2


-- 
   Summary: [4.5 Regression] Build failure with --enable-maintainer-
mode
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org


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

[Bug bootstrap/41078] [4.5 Regression] Build failure with --enable-maintainer-mode

[tkoenig at gcc dot gnu dot org]

-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |critical
   Target Milestone|--- |4.5.0


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

[Bug c++/40092] -std=gnu++0x expansion pattern fails with error about derived template instead of actual template

[cppljevans at suddenlink dot net]

--- Comment #11 from cppljevans at suddenlink dot net  2009-08-15 15:44 
---
Created an attachment (id=18371)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18371&action=view)
test case for gcc/testsuite/g++.dg/cpp0x with gcc-4.5 compile 

This is even a "more minimal" test case.  This is modelled after
the other files in gcc/testsuite/g++.dg/cpp0x.

Would someone conform this as a bug or briefly explain why it's
not a bug?

TIA.


-- 


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

[Bug lto/41079] New: Bootstrap comparison fails, executables contain .gnu.lto_* sections

[rguenth at gcc dot gnu dot org]

Likely because .gnu.lto_* sections remain in the final executables (like for
example cc1-dummy) bootstrap with BOOT_CFLAGS="-O2 -flto -g"
BOOT_LDFLAGS="-flto"
currently fails at comparing stage2 and stage3.

Comparing stage2 and stage3 cc1-dummy readelf -S output reveals:

--- a   2009-08-15 17:25:19.0 +0200
+++ b   2009-08-15 17:25:22.0 +0200
@@ -1,4 +1,4 @@
-There are 13739 section headers, starting at offset 0x67e1b6c:
+There are 13739 section headers, starting at offset 0x67e3424:

 Section Headers:
   [Nr] Name  TypeAddr OffSize   ES Flg Lk Inf
Al
@@ -29,13718 +29,13718 @@
   [24] .bss  NOBITS  08b090c0 ac00c0 06f6b8 00  WA  0   0
32
   [25] .gnu.lto_.referen PROGBITS ac00c0 0019c6 00  0   0 
4
   [26] .gnu.lto_.purecon PROGBITS ac1a88 008daa 00  0   0 
4
-  [27] .gnu.lto_init_adj PROGBITS aca834 0005db 00  0   0 
4
+  [27] .gnu.lto_init_adj PROGBITS aca834 0005d9 00  0   0 
4
   [28] .gnu.lto_.cgraph  PROGBITS acae10 0eaea1 00  0   0 
4
   [29] .gnu.lto_.statics PROGBITS bb5cb4 002a22 00  0   0 
4
-  [30] .gnu.lto_.decls   PROGBITS bb86d8 1ecd2ce 00  0   0
 4
(further all is different due to offset and size mismatches)

The offset difference of the section headers is odd as well.

Program headers are the same.


-- 
   Summary: Bootstrap comparison fails, executables contain
.gnu.lto_* sections
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
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=41079

[Bug fortran/41080] New: gfortran -dumpversion does not behave like gcc or g++

[david dot kirkby at onetel dot net]

The 'dumpversion' option of gcc and g++ show just the version number, which is
useful. The same is not true of gfortran, which shows a lot of other
information, making getting the version more difficult 

drkir...@smudge:[~] $ g++ -dumpversion
4.4.1
drkir...@smudge:[~] $ gcc -dumpversion
4.4.1
drkir...@smudge:[~] $ gfortran -dumpversion
GNU Fortran (GCC) 4.4.1
Copyright (C) 2009 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING


-- 
   Summary: gfortran -dumpversion does not behave like gcc or g++
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot kirkby at onetel dot net
 GCC build triplet: Solaris 10 update 7 on Sun Ultra 80
  GCC host triplet: Solaris 10 update 7 on Sun Ultra 80
GCC target triplet: Solairs 10 update 7 on Sun Ultra 80


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

[Bug libstdc++/41061] Compile of program using std random fails.

[3dw4rd at verizon dot net]

--- Comment #9 from 3dw4rd at verizon dot net  2009-08-15 16:04 ---
Subject: Re:  Compile of program using std random fails.

paolo dot carlini at oracle dot com wrote:
> --- Comment #7 from paolo dot carlini at oracle dot com  2009-08-14 23:34 
> ---
> Fixed.
>
>
>   
Paolo,

Thanks for getting those old test cases cleaned up and back in.  And 
thanks for putting this in.

Ed


-- 


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

[Bug bootstrap/41078] [4.5 Regression] Build failure with --enable-maintainer-mode

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2009-08-15 16:05 ---
Caused by wrong version of aclocal, sorry for the noise.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/41061] Compile of program using std random fails.

[paolo dot carlini at oracle dot com]

--- Comment #10 from paolo dot carlini at oracle dot com  2009-08-15 16:27 
---
You are welcome. By the way, Walter Brown told me in private email that is
working on the "de-conceptified" specifications, let's see what happens of
those comparison operators...


-- 


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

[Bug middle-end/40981] aermod.f90 ICEs on -O2 -fgraphite-identity -floop-strip-mine

[howarth at nitro dot med dot uc dot edu]

--- Comment #28 from howarth at nitro dot med dot uc dot edu  2009-08-15 
16:44 ---
Fixed on x86_64-apple-darwin10 with current gcc trunk. Thanks.


-- 

howarth at nitro dot med dot uc dot edu changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/41061] Compile of program using std random fails.

[3dw4rd at verizon dot net]

--- Comment #11 from 3dw4rd at verizon dot net  2009-08-15 17:29 ---
Subject: Re:  Compile of program using std random fails.

paolo dot carlini at oracle dot com wrote:
> --- Comment #10 from paolo dot carlini at oracle dot com  2009-08-15 
> 16:27 ---
> You are welcome. By the way, Walter Brown told me in private email that is
> working on the "de-conceptified" specifications, let's see what happens of
> those comparison operators...
>
>
>   
I agree we'll wait and see.  I think he'll need comparison operators.  
You could compare the contents of param_type because all the bits are 
available as calls.  But you'll still want to compare the other private 
parts of the states (such as other distributions).

On a completely different note I seem to remember you saying that you 
had some tools to check distributions and random numbers.  I think some 
tools like that would be great for TR2 along with some tools to get 
statistical moments.  Another day perhaps ;-).  I think if some user 
were to actually try to pick their own numbers for the engine templates 
that some QA tools would be essential.

Ed


-- 


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

[Bug libstdc++/41061] Compile of program using std random fails.

[paolo dot carlini at oracle dot com]

--- Comment #12 from paolo dot carlini at oracle dot com  2009-08-15 17:41 
---
(In reply to comment #11)
> I agree we'll wait and see.  I think he'll need comparison operators.  
> You could compare the contents of param_type because all the bits are 
> available as calls.  But you'll still want to compare the other private 
> parts of the states (such as other distributions).

Yes, but I think it's better to wait a bit more - should not be more than 1
month or two - because, *before* "conceptification", the comparisons did not
exist. By the way, if you have been able to find an ISO paper / discussion
around the time of the original "conceptification" where the rationale for
adding the operators was discussed, I'd like to see it...

> On a completely different note I seem to remember you saying that you 
> had some tools to check distributions and random numbers.  I think some 
> tools like that would be great for TR2 along with some tools to get 
> statistical moments.  Another day perhaps ;-).  I think if some user 
> were to actually try to pick their own numbers for the engine templates 
> that some QA tools would be essential.

Yes. I'd like to polish a bit some code developed with a friend, in private,
already rather close to do what we want wrt testing the shape of the
distribution in the testsuite. If you like, I can send you what I have...


-- 


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

[Bug fortran/41080] gfortran -dumpversion does not behave like gcc or g++

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-08-15 18:14 ---
Trivial patch:

Index: gcc/fortran/gfortranspec.c
===
--- gcc/fortran/gfortranspec.c  (Revision 150791)
+++ gcc/fortran/gfortranspec.c  (Arbeitskopie)
@@ -186,8 +186,6 @@ lookup_option (Option *xopt, int *xskip,
opt = OPTION_syntax_only;
   else if (!strcmp (text, "-static-libgfortran"))
opt = OPTION_static_libgfortran;
-  else if (!strcmp (text, "-dumpversion"))
-   opt = OPTION_version;
   else if (!strcmp (text, "-fversion"))/* Really --version!! */
opt = OPTION_version;
   else if (!strcmp (text, "-Xlinker") || !strcmp (text, "-specs"))


-- 


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

[Bug middle-end/41069] lto1: error: type mismatch in indirect reference

[jv244 at cam dot ac dot uk]

--- Comment #14 from jv244 at cam dot ac dot uk  2009-08-15 18:46 ---
(In reply to comment #13)
> > -flto needs about 35min compile time and 10.5Gb RAM.
> 
> Doh.  How does that compare to the all-CP2K in one file builds?

an all-in-one-file-CP2K takes about 2.5Gb and 30min last time I tested. So it
is mostly the memory increase that is really significant. 

BTW, -fwhole-program seems to make the build more expensive. The following
(with consistently compiled objects) requires now 67min:

gfortran -flto -fwhole-file -fwhole-program -O3 -ffast-math -funroll-loops
-march=native -ffree-form *.o [..]


-- 


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

[Bug fortran/41080] gfortran -dumpversion does not behave like gcc or g++

[david dot kirkby at onetel dot net]

--- Comment #2 from david dot kirkby at onetel dot net  2009-08-15 20:10 
---
Thank you. Does this mean the next version of gcc will support this? 


-- 


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

[Bug middle-end/41069] lto1: error: type mismatch in indirect reference

[rguenther at suse dot de]

--- Comment #15 from rguenther at suse dot de  2009-08-15 20:18 ---
Subject: Re:  lto1: error: type mismatch in indirect
 reference

On Sat, 15 Aug 2009, jv244 at cam dot ac dot uk wrote:

> --- Comment #14 from jv244 at cam dot ac dot uk  2009-08-15 18:46 ---
> (In reply to comment #13)
> > > -flto needs about 35min compile time and 10.5Gb RAM.
> > 
> > Doh.  How does that compare to the all-CP2K in one file builds?
> 
> an all-in-one-file-CP2K takes about 2.5Gb and 30min last time I tested. So it
> is mostly the memory increase that is really significant. 

Ok, that's interesting.  I'm curious if compiling all-in-one CP2K with
-flto is any different.

> BTW, -fwhole-program seems to make the build more expensive. The following
> (with consistently compiled objects) requires now 67min:
> 
> gfortran -flto -fwhole-file -fwhole-program -O3 -ffast-math -funroll-loops
> -march=native -ffree-form *.o [..]

Yes, -fwhole-program opens up more optimization opportunities, especially
around cloning which gets cheaper.

Richard.


-- 


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

[Bug fortran/41080] gfortran -dumpversion does not behave like gcc or g++

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2009-08-15 20:52 ---
Subject: Bug 41080

Author: burnus
Date: Sat Aug 15 20:51:55 2009
New Revision: 150792

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150792
Log:
2009-08-15  Tobias Burnus  

PR fortran/41080
* gfortranspec.c (lookup_option): Remove gfortran-specific
version of -dumpversion.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortranspec.c


-- 


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

[Bug fortran/41080] gfortran -dumpversion does not behave like gcc or g++

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2009-08-15 20:57 ---
(In reply to comment #2)
> Thank you. Does this mean the next version of gcc will support this? 

Now yes - I have just committed it to the trunk, i.e. the 4.5.0 release will
have it (as will have the nightly trunk builds).

Thanks for the bugreport!

Close as FIXED.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c/39959] [4.5 Regression] IMA is broken

[hp at gcc dot gnu dot org]

--- Comment #8 from hp at gcc dot gnu dot org  2009-08-16 00:16 ---
(In reply to comment #7)
> It was fixed between revision revision 150368 and revision 150371.

For the record, "covered up" rather than "fixed" according to
.

Richi, the "I have a patch" comment, is that stale or still in the pipe?


-- 


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

[Bug rtl-optimization/40086] [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution

[hp at gcc dot gnu dot org]

--- Comment #17 from hp at gcc dot gnu dot org  2009-08-16 00:31 ---
For the record, the gfortran.dg/forall_1.f90 regression has been covered since
r150588.  (And I'm still on the hook to address the concerns with the posted
patch.)


-- 


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

[Bug c/40454] GCC 4.4.0 vs 3.4.0 - PNGCrush is about 20% slower when compiled with GCC 4.4.0

[ami_stuff at o2 dot pl]

--- Comment #3 from ami_stuff at o2 dot pl  2009-08-16 01:28 ---
This slowdown is because of libz. When I use minigzip from libz package to
compress data, I get the same slowdown with GCC 4.4.1. Maybe someone will try
to fix it?


-- 


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

[Bug target/41081] New: redundant ZERO_EXTENDs

[amodra at bigpond dot net dot au]

Linux kernel block sha1 code on powerpc64 has many redundant clrldi
instructions, significantly slowing execution time.  Current gcc seems to
generate more of these than 3.4.5 which is in turn worse than 3.3.

Breakdown of clrldi insns
- 140 redundant clrldi on rotate insn output
- 79 other redundant clrldi
- 11 useful


-- 
   Summary: redundant ZERO_EXTENDs
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amodra at bigpond dot net dot au
GCC target triplet: powerpc64-linux


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

[Bug target/41081] redundant ZERO_EXTENDs

[amodra at bigpond dot net dot au]

--- Comment #1 from amodra at bigpond dot net dot au  2009-08-16 02:41 
---
Created an attachment (id=18372)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18372&action=view)
block sha1 source

blk_SHA1Block takes all its input from unsigned ints and only writes to
unsigned ints, thus all zero_extends in the body of this function are redundant


-- 

amodra at bigpond dot net dot au changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |amodra at bigpond dot net
   |dot org |dot au
 Status|UNCONFIRMED |ASSIGNED


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

[Bug target/41081] redundant ZERO_EXTENDs

[amodra at bigpond dot net dot au]

--- Comment #2 from amodra at bigpond dot net dot au  2009-08-16 02:45 
---
Created an attachment (id=18373)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18373&action=view)
Cure the zero_extends on rotate output

This patch teaches gcc that the powerpc rotate/shift unit appropriately zero or
sign extends to the full register width, at least for the most common case of
SImode operations.


-- 


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

[Bug target/41081] redundant ZERO_EXTENDs

[amodra at bigpond dot net dot au]

--- Comment #3 from amodra at bigpond dot net dot au  2009-08-16 03:05 
---
Created an attachment (id=18374)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18374&action=view)
aims to teach gcc that rotate/shift insn input register's high bits are ignored

This patch is aimed at the "79 other redundant clrldi", removing 59 cases on
rotate/shift input.  I'm not particularly happy with it due to hack for
LOAD_EXTEND_OP zero_extends.  Before I discovered that particular problem,
fwprop seemed a natural place to teach gcc about insn inputs.  If we don't
leave those zero_extends alone, some rotate insns will take their input
directly from the load, while other insns still need the zero_extend.  This
prevents combine from removing the zero_extend on loads.


-- 


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

[Bug target/41081] redundant ZERO_EXTENDs

[amodra at bigpond dot net dot au]

--- Comment #4 from amodra at bigpond dot net dot au  2009-08-16 03:07 
---
Please ignore the RS6000_ALT_REG_ALLOC_ORDER hunk in rs6000-2.diff.  I forgot
to edit that out..


-- 


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