[Bug rtl-optimization/35044] resource.c:find_dead_or_set_registers doesn't grok COND_EXEC

[amylaar at gcc dot gnu dot org]

-- 

amylaar at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|amylaar at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW


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

[Bug debug/41307] Valgrind failures / illegal reads with VTA turned on.

[aoliva at gcc dot gnu dot org]

--- Comment #5 from aoliva at gcc dot gnu dot org  2009-09-11 07:44 ---
Subject: Bug 41307

Author: aoliva
Date: Fri Sep 11 07:44:06 2009
New Revision: 151628

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151628
Log:
PR debug/41276
PR debug/41307
* cselib.c (cselib_expand_value_rtx_cb): Document callback
interface.
(cselib_expand_value_rtx_1): Use callback for SUBREGs.  Adjust
for VALUEs, to implement the documented interface.
* var-tracking.c (vt_expand_loc_callback): Handle SUBREGs.
Adjust for VALUEs and anything else, to implement the
documented interface.

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


-- 


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

[Bug debug/41276] [4.5 Regression] Segmentation fault in lookup_page_table_entry

[aoliva at gcc dot gnu dot org]

--- Comment #8 from aoliva at gcc dot gnu dot org  2009-09-11 07:44 ---
Subject: Bug 41276

Author: aoliva
Date: Fri Sep 11 07:44:06 2009
New Revision: 151628

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151628
Log:
PR debug/41276
PR debug/41307
* cselib.c (cselib_expand_value_rtx_cb): Document callback
interface.
(cselib_expand_value_rtx_1): Use callback for SUBREGs.  Adjust
for VALUEs, to implement the documented interface.
* var-tracking.c (vt_expand_loc_callback): Handle SUBREGs.
Adjust for VALUEs and anything else, to implement the
documented interface.

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


-- 


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

[Bug c++/41333] Link error on Solaris 10 / GNU 4.3.2

[redi at gcc dot gnu dot org]

--- Comment #5 from redi at gcc dot gnu dot org  2009-09-11 09:35 ---
Does the GCC you built for Solaris 10 have symbol versioning enabled?  You can
check this by looking in the libstdc++-v3/config.log or by running: 

nm /path/to/gcc/lib/libstdc++.so | fgrep @GLIBCXX

If that produces no output, then symbol versioning is not enabled.  The libs
built on Solaris 8 are trying to find versioned symbols.  If that is the case
you might have been bitten by Bug 38923 and you will need to rebuild the
Solaris 10 compiler with /usr/xpg4/bin at the start of your PATH


-- 


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

[Bug rtl-optimization/39779] ICE shifting byte to the right with constant > 7FFFFFFF

[howarth at nitro dot med dot uc dot edu]

--- Comment #7 from howarth at nitro dot med dot uc dot edu  2009-09-11 
09:54 ---
The pr39779.c test case is ICEing the compiler in gcc trunk on
x86_64-apple-darwin10 at r151625 as follows...

Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20090910/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20090910/darwin_objdir/gcc/
/sw/src/fink.build/gcc45-4.4.999-20090910/gcc-4.5-20090910/gcc/testsuite/gcc.dg/pr39779.c
  -w -S  -o pr39779.s(timeout = 300)
/sw/src/fink.build/gcc45-4.4.999-20090910/gcc-4.5-20090910/gcc/testsuite/gcc.dg/pr39779.c:
In function 'test':
/sw/src/fink.build/gcc45-4.4.999-20090910/gcc-4.5-20090910/gcc/testsuite/gcc.dg/pr39779.c:8:1:
error: unrecognizable insn:
(insn 7 6 8 3
/sw/src/fink.build/gcc45-4.4.999-20090910/gcc-4.5-20090910/gcc/testsuite/gcc.dg/pr39779.c:6
(set (reg:QI 61)
(const_int -557921043 [0xdebecced])) -1 (nil))
/sw/src/fink.build/gcc45-4.4.999-20090910/gcc-4.5-20090910/gcc/testsuite/gcc.dg/pr39779.c:8:1:
internal compiler error: in extract_insn, at recog.c:2093
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
compiler exited with status 1
output is:
/sw/src/fink.build/gcc45-4.4.999-20090910/gcc-4.5-20090910/gcc/testsuite/gcc.dg/pr39779.c:
In function 'test':
/sw/src/fink.build/gcc45-4.4.999-20090910/gcc-4.5-20090910/gcc/testsuite/gcc.dg/pr39779.c:8:1:
error: unrecognizable insn:
(insn 7 6 8 3
/sw/src/fink.build/gcc45-4.4.999-20090910/gcc-4.5-20090910/gcc/testsuite/gcc.dg/pr39779.c:6
(set (reg:QI 61)
(const_int -557921043 [0xdebecced])) -1 (nil))
/sw/src/fink.build/gcc45-4.4.999-20090910/gcc-4.5-20090910/gcc/testsuite/gcc.dg/pr39779.c:8:1:
internal compiler error: in extract_insn, at recog.c:2093
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

FAIL: gcc.dg/pr39779.c (internal compiler error)
FAIL: gcc.dg/pr39779.c (test for excess errors)
Excess errors:
/sw/src/fink.build/gcc45-4.4.999-20090910/gcc-4.5-20090910/gcc/testsuite/gcc.dg/pr39779.c:8:1:
error: unrecognizable insn:
(insn 7 6 8 3
/sw/src/fink.build/gcc45-4.4.999-20090910/gcc-4.5-20090910/gcc/testsuite/gcc.dg/pr39779.c:6
(set (reg:QI 61)
(const_int -557921043 [0xdebecced])) -1 (nil))
/sw/src/fink.build/gcc45-4.4.999-20090910/gcc-4.5-20090910/gcc/testsuite/gcc.dg/pr39779.c:8:1:
internal compiler error: in extract_insn, at recog.c:2093


-- 


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

[Bug rtl-optimization/39779] ICE shifting byte to the right with constant > 7FFFFFFF

[howarth at nitro dot med dot uc dot edu]

--- Comment #8 from howarth at nitro dot med dot uc dot edu  2009-09-11 
09:55 ---
Using built-in specs.
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.5-20090910/configure --prefix=/sw
--prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran,objc,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--disable-libjava-multilib --build=x86_64-apple-darwin10
--host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10
Thread model: posix
gcc version 4.5.0 20090911 (experimental) (GCC) 


-- 


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

[Bug middle-end/41334] New: gcc.dg/graphite/run-id-1.c fails execution test

[howarth at nitro dot med dot uc dot edu]

The gcc.dg/graphite/run-id-1.c testcase is failing the execution test on
x86_64-apple-darwin10 at r151625 as follows...

Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20090910/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20090910/darwin_objdir/gcc/
/sw/src/fink.build/gcc45-4.4.999-20090910/gcc-4.5-20090910/gcc/testsuite/gcc.dg/graphite/run-id-1.c
  -O2 -fgraphite-identity  -lm   -o ./run-id-1.exe(timeout = 300)
PASS: gcc.dg/graphite/run-id-1.c (test for excess errors)
Setting LD_LIBRARY_PATH to
:/sw/src/fink.build/gcc45-4.4.999-20090910/darwin_objdir/gcc::/sw/src/fink.build/gcc45-4.4.999-20090910/darwin_objdir/gcc
FAIL: gcc.dg/graphite/run-id-1.c execution test

Using built-in specs.
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.5-20090910/configure --prefix=/sw
--prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran,objc,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--disable-libjava-multilib --build=x86_64-apple-darwin10
--host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10
Thread model: posix
gcc version 4.5.0 20090911 (experimental) (GCC)


-- 
   Summary: gcc.dg/graphite/run-id-1.c fails execution test
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
 GCC build triplet: x86_64-apple-darwin10
  GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple-darwin10


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

[Bug tree-optimization/41026] invariant address load inside loop with -Os.

[rahul at icerasemi dot com]

--- Comment #6 from rahul at icerasemi dot com  2009-09-11 10:03 ---
An interesting regression results as a side effect of loop header copying (this
occurs even in vanilla O2). If I modify my original test case to

struct struct_t {
  int* data;
};

void testAddr (struct struct_t* sp, int len)
{
short i;
for (i = 0; i < len; i++)
  {
sp->data[len-i-1] = 0;
  }
}

The index is now a short, and I have purposefully added an int to form the
final induction variable.

With gcc -S -O2 -fdump-tree-all, I get the following SSA

  short int i;
  int * D.1220;
  long unsigned int D.1219;
  long unsigned int D.1218;
  long unsigned int D.1217;
  int D.1216;
  int D.1215;
  int * D.1214;

:
  goto ;

:
  D.1214_6 = sp_5(D)->data;
  D.1215_7 = (int) i_1;
  D.1216_8 = len_4(D) - D.1215_7;
  D.1217_9 = (long unsigned int) D.1216_8;
  D.1218_10 = D.1217_9 + -1;
  D.1219_11 = D.1218_10 * 4;
  D.1220_12 = D.1214_6 + D.1219_11;
  *D.1220_12 ={v} 0;
  i_13 = i_1 + 1;

:
  # i_1 = PHI <0(2), i_13(3)>
  D.1215_3 = (int) i_1;
  if (D.1215_3 < len_4(D))
goto ;
  else
goto ;

:
  return;

The following copy propagation and/or FRE passes identify D.1215_7 as a copy of
D.1215_3 and we get

:
  D.1214_6 = sp_5(D)->data;
  D.1216_8 = len_4(D) - D.1215_3;
  D.1217_9 = (long unsigned int) D.1216_8;
  D.1218_10 = D.1217_9 + -1;
  D.1219_11 = D.1218_10 * 4;
  D.1220_12 = D.1214_6 + D.1219_11;
  *D.1220_12 = 0;
  i_13 = i_1 + 1;

Loop header copying introduces a PHI for D.1215

:
  D.1215_19 = 0;
  if (D.1215_19 < len_4(D))
goto ;
  else
goto ;

:
  # i_20 = PHI 
  # D.1215_21 = PHI 
  D.1214_6 = sp_5(D)->data;
  D.1216_8 = len_4(D) - D.1215_21;
  D.1217_9 = (long unsigned int) D.1216_8;
  D.1218_10 = D.1217_9 + -1;
  D.1219_11 = D.1218_10 * 4;
  D.1220_12 = D.1214_6 + D.1219_11;
  *D.1220_12 = 0;
  i_13 = i_20 + 1;
  D.1215_3 = (int) i_13;
  if (D.1215_3 < len_4(D))
goto ;
  else
goto ;

This causes IVOpts below, and all subsequent optimisations to fall over.

:
  D.1214_6 = sp_5(D)->data;
  D.1238_7 = (unsigned int) len_4(D);
  D.1239_1 = D.1238_7 + 0x0;
  __builtin_loop_start (1, D.1239_1);
  D.1241_24 = (unsigned int) len_4(D);

:
  # D.1215_21 = PHI <0(3), D.1215_3(5)>
  # ivtmp.13_14 = PHI <0(3), ivtmp.13_18(5)>
  __builtin_loop_iteration (1);
  D.1216_8 = len_4(D) - D.1215_21;
  D.1217_9 = (long unsigned int) D.1216_8;
  D.1218_10 = D.1217_9 + -1;
  D.1219_11 = D.1218_10 * 4;
  D.1220_12 = D.1214_6 + D.1219_11;
  *D.1220_12 = 0;
  D.1240_19 = ivtmp.13_14 + 1;
  D.1215_23 = (int) D.1240_19;
  D.1215_3 = D.1215_23;
  ivtmp.13_18 = ivtmp.13_14 + 1;
  if (ivtmp.13_18 != D.1241_24)
goto ;
  else
goto ;

On this test using -fno-tree-copy-prop -fno-tree-pre results in better
optimizations, implying either copy propagating (across blocks) / FREing
potential induction variables is undesirable. Or a less ideal solution is
disable loop header copying when dealing with type promoted loop indices.


-- 


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

[Bug rtl-optimization/39779] ICE shifting byte to the right with constant > 7FFFFFFF

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2009-09-11 10:45 ---
That's because Uros didn't actually revert the testcase together with the
reversion of the patch (only testsuite/ChangeLog says so).


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||uros at gcc dot gnu dot org


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

[Bug c++/41275] [4.5 Regression] ICE: expand_expr_real_1, at expr.c:8416

[matz at gcc dot gnu dot org]

--- Comment #7 from matz at gcc dot gnu dot org  2009-09-11 11:08 ---
Subject: Bug 41275

Author: matz
Date: Fri Sep 11 11:08:38 2009
New Revision: 151631

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151631
Log:
PR middle-end/41275
* tree-inline.c (remap_decls): Don't put DECL_EXTERNAL decls
on the local_decls list.

testsuite/
* g++.dg/tree-ssa/pr41275.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr41275.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c


-- 


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

[Bug rtl-optimization/39779] ICE shifting byte to the right with constant > 7FFFFFFF

[ubizjak at gmail dot com]

--- Comment #10 from ubizjak at gmail dot com  2009-09-11 11:22 ---
(In reply to comment #9)
> That's because Uros didn't actually revert the testcase together with the
> reversion of the patch (only testsuite/ChangeLog says so).

Eh, done now.


-- 


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

[Bug fortran/41242] [4.5 Regression] PPC call rejected (related to user-defined assignment?)

[juergen dot reuter at physik dot uni-freiburg dot de]

--- Comment #19 from juergen dot reuter at physik dot uni-freiburg dot de  
2009-09-11 11:56 ---
Subject: Re:  [4.5 Regression] PPC call rejected (related to user-defined
assignment?)

On Friday 11 September 2009 00:51, janus at gcc dot gnu dot org wrote:
> --- Comment #18 from janus at gcc dot gnu dot org  2009-09-10 22:51
> --- Fixed with r151620. Thanks to Juergen for the report.

Hey, Janus!
Muchas gracias fuer die schnelle und gute Arbeit! WHIZARD kompiliert und 
laeuft wieder. Dieser Runtime error ist allerdings immer noch, ich versuche 
dann mal wieder, da mehr rauszubekommen. Ich hatte das zurückgestellt, 
solange WHIZARD net kompilert hatte.
Meinst du, es koennte helfen, wenn ich irgendwann einfach ma nach Giessen 
käme, falls ich net weiterkomme?
Ciao,
JR


-- 


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

[Bug c++/41275] [4.5 Regression] ICE: expand_expr_real_1, at expr.c:8416

[matz at gcc dot gnu dot org]

--- Comment #8 from matz at gcc dot gnu dot org  2009-09-11 12:13 ---
Fixed.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libfortran/41335] New: VOLATILE in Fortran does not take effect

[denis_scherbakov at yahoo dot com]

I am using GCC 4.3.2, but I tested this also with 4.3.4, 4.4.1, 4.4-latest and
4.5-latest. Most of the are compiled with "../configure --prefix=MYPREFIX
--enable-language=fortran"

>From Fortran docs: "If a variable is volatile, the processor is expected to
fetch the value from memory every time that the variable is referenced, even if
a value was previously fetched and there is no evident way for the value to
have changed in the interim."

In other words, variable should be stored and fetched every time it is
referenced. I am working on a "double precision, volatile :: x" and do not
understand, why GCC optimises it, when it should not. (I've seen most reported
bug #323, thanks). Simple code illustrating the problem:

=
file  compiled with :
-
program VolatileTest
  double precision :: uA, uB
  double precision, volatile :: a
  double precision :: b
  double precision :: c

  ! Enter 0.1 two times
  read(*,*) uA, uB

  a = uA*uA
  b = uB*uB
  c = a-b

  ! Nonzero value is correct
  print *,c
end
=
file  compiled with :
-
  PROGRAM VolatileTest
double precision :: uA, uB
volatile double precision a
double precision :: b
double precision :: c

C Enter 0.1 two times
READ(*,*) uA, uB

a = uA*uA
b = uB*uB
c = a-b

C Nonzero value is correct
PRINT *,c
  END
=

If I compile test.F95, no effect of volatile is seen. Variable "a" is
optimised:
-
0x08048715 :fldQWORD PTR [ebp-0x18]  # var a
0x08048718 :fmul   st,st(0)  # a*a
0x0804871a :fldQWORD PTR [ebp-0x20]  # var b
0x0804871d :fmul   st,st(0)  # b*b
0x0804871f :fsubrp st(1),st  # a-b
0x08048721 :fstp   QWORD PTR [ebp-0x10]  # c = a-b
0x08048724 :call   0x8048538 <_gfortran_st_wr...@plt>
-

If I compile test.F, volatile variable is not optimised. This is what I expect:
-
0x08048715 :fldQWORD PTR [ebp-0x18]  # a
0x08048718 :fldQWORD PTR [ebp-0x20]  # b
0x0804871b :fxch   st(1) # swap
0x0804871d :fmul   st,st(0)  # a*a
0x0804871f :fstp   DWORD PTR [ebp-0x13c] # store a
0x08048725 :fldDWORD PTR [ebp-0x13c] # fetch a (correct
!!!)
0x0804872b :fxch   st(1) # swap
0x0804872d :fmul   st,st(0)  # b*b
0x0804872f :fsubrp st(1),st  # a-b
0x08048731 :fstp   QWORD PTR [ebp-0x10]  # c = a-b
0x08048734 :call   0x8048538 <_gfortran_st_wr...@plt>
-

Also if in test.F I replace "volatile double precision a" with "double
precision, volatile :: a" I start getting incorrect result and "volatile"
attribute is discarded.

So is this a bug or a feature?

Denis


-- 
   Summary: VOLATILE in Fortran does not take effect
   Product: gcc
   Version: 4.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: denis_scherbakov at yahoo dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug debug/41259] [4.5 Regression] internal compiler error: verify_ssa failed

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-09-11 13:19 ---
Works for me now.  Re-open if it still fails for you.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/41316] [C++0x] forward_list::sort violates strict aliasing rules

[paolo at gcc dot gnu dot org]

--- Comment #23 from paolo at gcc dot gnu dot org  2009-09-11 13:48 ---
Subject: Bug 41316

Author: paolo
Date: Fri Sep 11 13:47:36 2009
New Revision: 151635

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151635
Log:
2009-09-11  Paolo Carlini  

PR libstdc++/41316
* include/bits/forward_list.h (_Fwd_list_node_base<>::_M_sort_after):
Remove.
(forward_list<>::sort(_Comp)): Only declare.
(forward_list<>::sort()): Forward to the latter.
* include/bits/forward_list.tcc (_Fwd_list_node_base<>::_M_sort_after):
Remove definition.
(forward_list<>::sort(_Comp)): Define.
* testsuite/23_containers/forward_list/requirements/dr438/
assign_neg.cc: Adjust dg-error line number.
* testsuite/23_containers/forward_list/requirements/dr438/
insert_neg.cc: Likewise.
* testsuite/23_containers/forward_list/requirements/dr438/
constructor_1_neg.cc: Likewise.
* testsuite/23_containers/forward_list/requirements/dr438/
constructor_2_neg.cc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/forward_list.h
trunk/libstdc++-v3/include/bits/forward_list.tcc
   
trunk/libstdc++-v3/testsuite/23_containers/forward_list/requirements/dr438/assign_neg.cc
   
trunk/libstdc++-v3/testsuite/23_containers/forward_list/requirements/dr438/constructor_1_neg.cc
   
trunk/libstdc++-v3/testsuite/23_containers/forward_list/requirements/dr438/constructor_2_neg.cc
   
trunk/libstdc++-v3/testsuite/23_containers/forward_list/requirements/dr438/insert_neg.cc


-- 


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

[Bug libstdc++/41316] [C++0x] forward_list::sort violates strict aliasing rules

[paolo dot carlini at oracle dot com]

--- Comment #24 from paolo dot carlini at oracle dot com  2009-09-11 13:50 
---
Ed, I went ahead and committed this, I don't think we can do much better, for
now.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/41316] [C++0x] forward_list::sort violates strict aliasing rules

[rguenth at gcc dot gnu dot org]

--- Comment #25 from rguenth at gcc dot gnu dot org  2009-09-11 13:51 
---
Looks good to me.  Btw, other containers might be affected by similar issues.


-- 


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

[Bug libstdc++/41316] [C++0x] forward_list::sort violates strict aliasing rules

[paolo dot carlini at oracle dot com]

--- Comment #26 from paolo dot carlini at oracle dot com  2009-09-11 13:52 
---
Richard, I'm not sure whether you need this change in 4_4-branch too, in case
just ask me or go ahead yourself, should be backportable as-is.


-- 


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

[Bug libstdc++/41316] [C++0x] forward_list::sort violates strict aliasing rules

[rguenther at suse dot de]

--- Comment #27 from rguenther at suse dot de  2009-09-11 13:53 ---
Subject: Re:  [C++0x] forward_list::sort violates strict
 aliasing rules

On Fri, 11 Sep 2009, paolo dot carlini at oracle dot com wrote:

> --- Comment #26 from paolo dot carlini at oracle dot com  2009-09-11 
> 13:52 ---
> Richard, I'm not sure whether you need this change in 4_4-branch too, in case
> just ask me or go ahead yourself, should be backportable as-is.

It might silence some of the alias warnings, but PRE isn't strong enough
to miscompile it there.

Richard.


-- 


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

[Bug libstdc++/41316] [C++0x] forward_list::sort violates strict aliasing rules

[paolo dot carlini at oracle dot com]

--- Comment #28 from paolo dot carlini at oracle dot com  2009-09-11 13:54 
---
I'll have a look, but I don't think we are really playing these multiple up and
down tricks.


-- 


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

New Hyip - 15-30% Daily - Paid

[psaaber]

[Bug c++/41333] Link error on Solaris 10 / GNU 4.3.2

[vijay dot x dot jain at jpmchase dot com]

--- Comment #6 from vijay dot x dot jain at jpmchase dot com  2009-09-11 
14:19 ---
As suggested i had put /usr/xpg4/bin in PATH in precedence.
from config.log
lt_cv_path_SED=/usr/xpg4/bin/sed
SED='/usr/xpg4/bin/sed'

BUt still versioning is not used
a_dod...@upests-dn24d:.libs:[53] !nm
nm libstdc++.so | fgrep GLIBCXX
a_dod...@upests-dn24d:.libs:[54] pwd


Also I see following in config.log
 #define PACKAGE_VERSION "version-unused"
is this indicator for versioning not used ?

HOw can I make sure that version will be used before I start compiling.


Additional Info from config.log
configure:114744: /home/odyssey/a_dodycc/gcc/gccobjdir/./gcc/xgcc
-B/home/odyssey/a_dodycc/gcc/gccobjdir/./gcc/ -B/home/odyss
ey/a_dodycc/gccinstall/sparc-sun-solaris2.10/bin/
-B/home/odyssey/a_dodycc/gccinstall/sparc-sun-solaris2.10/lib/ -isystem /ho
me/odyssey/a_dodycc/gccinstall/sparc-sun-solaris2.10/include -isystem
/home/odyssey/a_dodycc/gccinstall/sparc-sun-solaris2.10
/sys-include -o conftest  -lgcc_s   conftest.c -lm  >&5
configure:114750: $? = 0
configure:114754: test -z
 || test ! -s conftest.err
configure:114757: $? = 0
configure:114760: test -s conftest
configure:114763: $? = 0
configure:114839: result: yes
configure:114866: WARNING: === Linker version 1800 is too old for
configure:114868: WARNING: === full symbol versioning support in this release
of GCC.
configure:114870: WARNING: === You would need to upgrade your binutils to
version
configure:114872: WARNING: === 21400 or later and rebuild GCC.
configure:114874: WARNING: === Symbol versioning will be disabled.
configure:114925: versioning on shared library symbols is no
configure:114932: checking for size_t as unsigned int
configure:114952: /home/odyssey/a_dodycc/gcc/gccobjdir/./gcc/xgcc
-B/home/odyssey/a_dodycc/gcc/gccobjdir/./gcc/ -B/home/odyss
ey/a_dodycc/gccinstall/sparc-sun-solaris2.10/bin/
-B/home/odyssey/a_dodycc/gccinstall/sparc-sun-solaris2.10/lib/ -isystem /ho
me/odyssey/a_dodycc/gccinstall/sparc-sun-solaris2.10/include -isystem
/home/odyssey/a_dodycc/gccinstall/sparc-sun-solaris2.10
/sys-include -c -Werror  conftest.c >&5


My configure options are as follows

/home/odyssey/a_dodycc/gcc/gcc-4.3.2/configure 
--prefix=/home/odyssey/a_dodycc/gccinstall
--with-as=/3rdparty/fsf/binutils/2.18/bin/as 
--with-ld=/home/odyssey/f065093/binuitls/binutils-2.18/install/bin/ld 
--with-gnu-as --with-gnu-ld --disable-nls --enable-languages=c,c++
--with-gmp=/home/odyssey/f065093/gmp/gmp-4.3.1/install
--with-mpfr=/home/odyssey/f065093/mpfr/mpfr-2.4.1/install 
LD=/home/odyssey/f065093/binuitls/binutils-2.18/install/bin/ld 
AR=/home/odyssey/f065093/binuitls/binutils-2.18/install/bin/ar
NM=/home/odyssey/f065093/binuitls/binutils-2.18/install/bin/nm 
RANLIB=/home/odyssey/f065093/binuitls/binutils-2.18/install/bin/ranlib
STRIP=/home/odyssey/f065093/binuitls/binutils-2.18/install/bin/strip
OBJCOPY=/home/odyssey/f065093/binuitls/binutils-2.18/install/bin/objcopy
OBJDUMP=/home/odyssey/f065093/binuitls/binutils-2.18/install/bin/objdump CC=gcc
cc=gcc

I am not sure how is ld version mapped to 1800

/home/odyssey/a_dodycc/gcc/gccobjdir>/home/odyssey/f065093/binuitls/binutils-2.18/install/bin/ld
-v
GNU ld (GNU Binutils)2.18

What do  I do to use ld 21400? HOw can i get this?



As suggested I am using 3.4.6 as base version from www.sunfreeware.com to build
gcc 4.3.2
Following are the configure options of the gcc version 3.4.6

Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77
Thread model: posix
gcc version 3.4.6

Please suggest. We really appreciate you help


-- 


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

[Bug bootstrap/41336] New: [LTO] Bootstrap failed on RHEL5/ia32 and RHEL5/ia64

[hjl dot tools at gmail dot com]

+++ This bug was initially created as a clone of Bug #38992 +++

On RHEL5/ia32 and RHEL5/ia64, revision 151545 gave

cc1: warnings being treated as errors
../../src-lto/gcc/lto/lto-elf.c: In function 'validate_file':
../../src-lto/gcc/lto/lto-elf.c:453:3: error: implicit declaration of function
'elf_getshdrstrndx'
make[6]: *** [lto/lto-elf.o] Error 1


-- 
   Summary: [LTO] Bootstrap failed on RHEL5/ia32 and RHEL5/ia64
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
 BugsThisDependsOn: 38992


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

[Bug bootstrap/41337] New: [LTO] Parallel build failure

[hjl dot tools at gmail dot com]

On Intel Core i7 with "make -j8", I got

flex  -ogengtype-lex.c /export/gnu/import/gcc-lto/gcc/gengtype-lex.l
echo "#define BUILDING_GCC_MAJOR `echo 4.5.0 | sed -e 's/^\([0-9]*\).*$/\1/'`"
>
 bversion.h
make[1]: *** No rule to make target `build/gencondmd', needed by `s-condmd'. 
St
op.
make[1]: *** Waiting for unfinished jobs


-- 
   Summary: [LTO] Parallel build failure
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug bootstrap/41336] [LTO] Bootstrap failed on RHEL5/ia32 and RHEL5/ia64

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-09-11 14:48 ---
You need newer libelf.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug bootstrap/41337] [LTO] Parallel build failure

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2009-09-11 15:01 ---
Pilot error.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libfortran/41335] VOLATILE in Fortran does not take effect

[denis_scherbakov at yahoo dot com]

--- Comment #1 from denis_scherbakov at yahoo dot com  2009-09-11 15:10 
---
I studied the error a little bit more.

"volatile double precision a" declares a variable "doubleprecisiona" which is
not used.

"real, volatile :: a" works and produces expected result
"volatile :: a" works, but type is not specified

Does not work anything with :
"double precision, volatile :: a"
"volatile :: a \n double precision :: a"
"double precision :: a \n volatile :: a"

Denis


-- 


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

[Bug c++/41333] Link error on Solaris 10 / GNU 4.3.2

[redi at gcc dot gnu dot org]

--- Comment #7 from redi at gcc dot gnu dot org  2009-09-11 15:20 ---
(In reply to comment #6)
> configure:114866: WARNING: === Linker version 1800 is too old for
> configure:114868: WARNING: === full symbol versioning support in this release
> of GCC.
> configure:114870: WARNING: === You would need to upgrade your binutils to
> version
> configure:114872: WARNING: === 21400 or later and rebuild GCC.
> configure:114874: WARNING: === Symbol versioning will be disabled.
> configure:114925: versioning on shared library symbols is no

This is the line that matters. This tells you symbol versioning will NOT be
used. This is the same error as I reported in Bug 38923, which means that
/usr/bin/xpg4/sed is NOT being used.

> I am not sure how is ld version mapped to 1800

Read Bug 38923!  I didn't point it out just for my own amusement.


> /home/odyssey/a_dodycc/gcc/gccobjdir>/home/odyssey/f065093/binuitls/binutils-2.18/install/bin/ld
> -v
> GNU ld (GNU Binutils)2.18
> 
> What do  I do to use ld 21400? HOw can i get this?

21400 refers to binutils 2.14, but since you are trying to use 2.18 and it is
identifying it as 1800 that means the sed script is not working. See bug 38923

Either you didn't change your path, or you didn't rebuild properly (remove
everything in objdir and start clean.)


-- 


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

[Bug libfortran/41335] VOLATILE in Fortran does not take effect

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2009-09-11 15:26 ---
> file  compiled with :

Try compiling with -ffree-form.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libfortran/41335] VOLATILE in Fortran does not take effect

[denis_scherbakov at yahoo dot com]

--- Comment #3 from denis_scherbakov at yahoo dot com  2009-09-11 15:40 
---
I compiled fixed form source with -ffree-form.

"real, volatile :: a" produces correct result
"double precision, volatile :: a" not

Why should I compile fixed form source as a free form at all?

Denis


-- 

denis_scherbakov at yahoo dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug libfortran/41335] VOLATILE in Fortran does not take effect

[denis_scherbakov at yahoo dot com]

--- Comment #4 from denis_scherbakov at yahoo dot com  2009-09-11 15:45 
---
I tested "real, volatile" and "double precision, volatile" with fixed form and
free form and "real*" works, "double*" - not.

So it is not a question of a source form now, but rather why "double precision,
volatile :: a" ignores volatile attribute?

Denis


-- 


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

[Bug bootstrap/41336] [LTO] Bootstrap failed on RHEL5/ia32 and RHEL5/ia64

[joseph at codesourcery dot com]

--- Comment #2 from joseph at codesourcery dot com  2009-09-11 15:51 ---
Subject: Re:  [LTO] Bootstrap failed on RHEL5/ia32 and
 RHEL5/ia64

On Fri, 11 Sep 2009, rguenth at gcc dot gnu dot org wrote:

> You need newer libelf.

This should result in a configure error, not an error at a later stage; it 
should disable LTO if libelf is too old and LTO is not explicitily 
requested, or give an error at configure time if LTO is explicitly 
requested but libelf is too old.


-- 


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

[Bug tree-optimization/41101] [4.4 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419

[debian-gcc at lists dot debian dot org]

--- Comment #25 from debian-gcc at lists dot debian dot org  2009-09-11 
16:50 ---
checked the backport of the 2nd chunk on the 4.4 branch without regressions on
i386 and amd64.

  Matthias


-- 


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

[Bug bootstrap/41336] [LTO] Bootstrap failed on RHEL5/ia32 and RHEL5/ia64

[steven at gcc dot gnu dot org]

--- Comment #3 from steven at gcc dot gnu dot org  2009-09-11 17:29 ---
needs configure magician...


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug bootstrap/41336] [LTO] Bootstrap failed on RHEL5/ia32 and RHEL5/ia64

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2009-09-11 17:30 ---
...but bug is real.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-09-11 17:30:05
   date||


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

[Bug other/41338] New: High memory consumption when compiling with -O3 -g

[d dot g dot gorbachev at gmail dot com]

GCC 4.5.0 20090910, compile with `cc1 -O3 -g tree.i' command.


-- 
   Summary: High memory consumption when compiling with -O3 -g
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot g dot gorbachev at gmail dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug other/41338] High memory consumption when compiling with -O3 -g

[d dot g dot gorbachev at gmail dot com]

--- Comment #1 from d dot g dot gorbachev at gmail dot com  2009-09-11 
17:53 ---
Created an attachment (id=18565)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18565&action=view)
gzipped preprocessed source file


-- 


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

[Bug ada/18302] ACATS tests hang: c74004a, c960004, and others

[ro at gcc dot gnu dot org]

--- Comment #22 from ro at gcc dot gnu dot org  2009-09-11 18:06 ---
Fixed for 4.5.0.  Before, the patch had only been applied to two RedHat vendor
branches.


-- 


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

[Bug libfortran/41335] VOLATILE in Fortran does not take effect

[kargl at gcc dot gnu dot org]

--- Comment #5 from kargl at gcc dot gnu dot org  2009-09-11 18:18 ---
(In reply to comment #4)
> I tested "real, volatile" and "double precision, volatile" with fixed form and
> free form and "real*" works, "double*" - not.
> 
> So it is not a question of a source form now, but rather why "double 
> precision,
> volatile :: a" ignores volatile attribute?
> 

Can you define what you mean by works?  The intermediate code that
-fdump-tree-original produces is identical for the REAL(4) and REAL(8)
with the obvious difference of the kind type parameter.

program VolatileTest
  double precision, volatile :: a
  double precision :: uA, uB, b, c
  real, volatile :: ra
  real :: ruA, ruB, rb, rc
  read(*,*) uA, uB, ruA, ruB
  a = uA * uA
  b = uB * uB
  c = a - b
  ra = ruA * ruA
  rb = ruB * ruB
  rc = ra - rb
  print *, c, rb
end program VolatileTest


gives


volatiletest ()
{
  volatile real(kind=8) a;
  real(kind=8) b;
  real(kind=8) c;
  volatile real(kind=4) ra;
  real(kind=4) rb;
  real(kind=4) rc;
  real(kind=4) rua;
  real(kind=4) rub;
  real(kind=8) ua;
  real(kind=8) ub;

  {
struct __st_parameter_dt dt_parm.0;

dt_parm.0.common.filename = &"dd.f90"[1]{lb: 1 sz: 1};
dt_parm.0.common.line = 6;
dt_parm.0.common.flags = 128;
dt_parm.0.common.unit = 5;
_gfortran_st_read (&dt_parm.0);
_gfortran_transfer_real (&dt_parm.0, &ua, 8);
_gfortran_transfer_real (&dt_parm.0, &ub, 8);
_gfortran_transfer_real (&dt_parm.0, &rua, 4);
_gfortran_transfer_real (&dt_parm.0, &rub, 4);
_gfortran_st_read_done (&dt_parm.0);
  }
  a = (volatile real(kind=8)) (ua * ua);
  b = (real(kind=8)) (ub * ub);
  c = (real(kind=8)) (a - b);
  ra = (volatile real(kind=4)) (rua * rua);
  rb = (real(kind=4)) (rub * rub);
  rc = (real(kind=4)) (ra - rb);


  {
struct __st_parameter_dt dt_parm.1;

dt_parm.1.common.filename = &"dd.f90"[1]{lb: 1 sz: 1};
dt_parm.1.common.line = 13;
dt_parm.1.common.flags = 128;
dt_parm.1.common.unit = 6;
_gfortran_st_write (&dt_parm.1);
_gfortran_transfer_real (&dt_parm.1, &c, 8);
_gfortran_transfer_real (&dt_parm.1, &rb, 4);
_gfortran_st_write_done (&dt_parm.1);
  }
}


main (integer(kind=4) argc, character(kind=1) * * argv)
{
  static integer(kind=4) options.2[8] = {68, 255, 0, 0, 0, 1, 0, 1};

  _gfortran_set_args (argc, argv);
  _gfortran_set_options (8, &options.2[0]);
  volatiletest ();
  return 0;
}


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu dot org


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

[Bug libfortran/41335] VOLATILE in Fortran does not take effect

[denis_scherbakov at yahoo dot com]

--- Comment #6 from denis_scherbakov at yahoo dot com  2009-09-11 18:38 
---
By saying "works" I mean that on my system program with

"real, volatile :: a"
returns nonzero result. This is correct, because 80-bit floating point
gets truncated to 64-bit and then loaded again into FPU.

"double precision, volatile :: a"
returns zero result. It means that variable "a" stays in FPU registers.

I am not sure about your code, but when I compile both versions of a sample
program on my machine "real, volatile" is stored and then fetched again,
"double precision, volatile" stays in FPU.

By the way. A ran your program and got the same wrong result:

u...@localhost ~ $ gfortran -std=f2003 -O2 test.F95 -o test-F95
u...@localhost ~ $ ./test-F95
0.1
0.1
0.1
0.1
   0.   1.0007E-02

0.0 means that "double precision" stayed in FPU registers instead of being
saved.


-- 


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

[Bug libfortran/41335] VOLATILE in Fortran does not take effect

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #7 from sgk at troutmask dot apl dot washington dot edu  
2009-09-11 18:57 ---
Subject: Re:  VOLATILE in Fortran does not take effect

> - Comment #6 from denis_scherbakov at yahoo dot com  2009-09-11 18:38 ---
> By saying "works" I mean that on my system program with
> 
> "real, volatile :: a"
> returns nonzero result. This is correct, because 80-bit floating point
> gets truncated to 64-bit and then loaded again into FPU.
> 
> "double precision, volatile :: a"
> returns zero result. It means that variable "a" stays in FPU registers.
> 
> I am not sure about your code, but when I compile both versions of a sample
> program on my machine "real, volatile" is stored and then fetched again,
> "double precision, volatile" stays in FPU.
> 

If you want -ffloat-store semantics then use that option.  The
Fortran 2003 standard does not require anything about fetching
and storing a volatile entity to memory.  The standard states:

The VOLATILE attribute specifies that an object may be referenced,
defined, or become undefined, by means not specified by the program.

An object may have the VOLATILE attribute in a particular scoping
unit without necessarily having it in other scoping units.  If an
object has the VOLATILE attribute, then all of its subobjects also
have the VOLATILE attribute.

NOTE 5.21
  The Fortran processor should use the most recent definition of a
  volatile object when a value is required.  Likewise, it should
  make the most recent Fortran definition available.  It is the
  programmer's responsibility to manage the interactions with the
  non-Fortran processes.

Note 5.21 is only informative text.  However, gfortran is essentially
doing what 5.21 states.  You're most recent definition of a is given
by a = Ua * Ua, then when you compute c = a - b it uses the most recent
definition.  There is no requirement that a had to be written to and
retrieved from memory.


-- 


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

[Bug libfortran/41335] VOLATILE in Fortran does not take effect

[denis_scherbakov at yahoo dot com]

--- Comment #8 from denis_scherbakov at yahoo dot com  2009-09-11 19:02 
---
Ok, but then "real" and "double precision" datatypes should
behave in the same way? No?

Denis


-- 


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

[Bug libfortran/41335] VOLATILE in Fortran does not take effect

[denis_scherbakov at yahoo dot com]

--- Comment #9 from denis_scherbakov at yahoo dot com  2009-09-11 19:12 
---
And how would you know that by leaving "a" in FPU register after a = aU*aU
you still have the most recent version of "a" during computation of "c" without
storing it?

Denis


-- 


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

[Bug libfortran/41335] VOLATILE in Fortran does not take effect

[mikael at gcc dot gnu dot org]

--- Comment #10 from mikael at gcc dot gnu dot org  2009-09-11 19:39 ---
(In reply to comment #5)
> Can you define what you mean by works? 
The following change in the provided testcase (fixed form):

--- pr41335.f.old   2009-09-11 23:12:01.0 +0200
+++ pr41335.f   2009-09-11 22:32:07.0 +0200
@@ -1,6 +1,6 @@
   PROGRAM VolatileTest
 double precision :: uA, uB
-volatile double precision a
+double precision, volatile :: a
 double precision :: b
 double precision :: c

produces the following difference in the code generated:

--- pr41335.f.003t.original.old 2009-09-11 22:36:44.0 +0200
+++ pr41335.f.003t.original 2009-09-11 22:38:02.0 +0200
@@ -1,6 +1,6 @@
 volatiletest ()
 {
-  real(kind=4) a;
+  volatile real(kind=8) a;
   real(kind=8) b;
   real(kind=8) c;
   real(kind=8) ua;
@@ -20,9 +20,9 @@
 _gfortran_transfer_real (&dt_parm.1, &ub, 8);
 _gfortran_st_read_done (&dt_parm.1);
   }
-  a = (real(kind=4)) (ua * ua);
+  a = (volatile real(kind=8)) (ua * ua);
   b = ub * ub;
-  c = (real(kind=8)) a - b;
+  c = a - b;
   {
 struct __st_parameter_dt dt_parm.2;


that is : variable a loses its volatile and double precision attribute
In fact, a is implicitly typed ;
Adding implicit none, I get :

pr41335_test.f:11.9:

a = uA*uA   
 1
Error: Symbol 'a' at (1) has no IMPLICIT type
pr41335_test.f:4.35:

volatile double precision a 
   1
Error: Symbol 'doubleprecisiona' at (1) has no IMPLICIT type


But I think plain volatile double precision is invalid (f2008) :
   type-declaration-stmt is declaration-type-spec [ [ , attr-spec ] ... :: ]
entity-decl -list

Only the comma/double-colon version should be allowed
confirmed as diagnostic bug, though I'm wondering if this shouldn't be simply
closed as invalid.


By the way, ALWAYS USE IMPLICIT NONE!


-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2009-09-11 19:39:11
   date||


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

[Bug libfortran/41335] VOLATILE in Fortran does not take effect

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #11 from sgk at troutmask dot apl dot washington dot edu  
2009-09-11 19:45 ---
Subject: Re:  VOLATILE in Fortran does not take effect

> Ok, but then "real" and "double precision" datatypes should
> behave in the same way? No?
> 

They do behave the same at least from the Fortran front-end
perspective.  I've already posted the generated intermediate
code.  Here it is again with the REAL(4) on the left and
the REAL(8) on the right.

volatiletest ()
{
  volatile real(kind=4) ra;  volatile real(kind=8) a;
  real(kind=4) rb;   real(kind=8) b;
  real(kind=4) rc;   real(kind=8) c;
  real(kind=4) rua;  real(kind=8) ua;
  real(kind=4) rub;  real(kind=8) ub;
  a=(volatile real(kind=8))(ua*ua);  ra=(volatile real(kind=4))(rua*rua);
  b = (real(kind=8)) (ub * ub);  rb = (real(kind=4)) (rub * rub);
  c = (real(kind=8)) (a - b);rc = (real(kind=4)) (ra - rb);
}

I'll simply note that on my hardware I get 

troutmask:sgk[204] ./z
0.1 0.1 0.1 0.1
   0.0.000

forall options that I tried.

You've already mentioned the infamous PR 324, so I suspect
you're familiar with the pitfalls of floating point math
and the I387 behavior.  I won't rehash that here.  If you
want the middle-end and back-end to do what you want, then
you'll need to convince others that there is a problem.  See
PR 324 for the joy.

Now, what volatile should be doing is inhibiting the optimizer
from optimizing

   real, volatile :: a
   real b
   a = 0.1
   call sub1
   b = a

to

   call sub1
   b = 0.1


-- 


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

[Bug libfortran/41335] VOLATILE in Fortran does not take effect

[denis_scherbakov at yahoo dot com]

--- Comment #12 from denis_scherbakov at yahoo dot com  2009-09-11 20:05 
---
Steve Kargl,

What is your hardware? x86 or something else?
I have Atlon 2000 MP and Intel Quad and on both of these systems I get
differences
in output for "real" and "double precision".

What I can do to prove that I do have differences and what to do to find out
why?

Denis


-- 


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

[Bug libfortran/41335] VOLATILE in Fortran does not take effect

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #13 from sgk at troutmask dot apl dot washington dot edu  
2009-09-11 20:26 ---
Subject: Re:  VOLATILE in Fortran does not take effect

> 
> What is your hardware? x86 or something else?

Opteron.

> I have Atlon 2000 MP and Intel Quad and on both of these systems I get
> differences in output for "real" and "double precision".
> 
> What I can do to prove that I do have differences and what to do to find out
> why?
> 

Have you tried -ffloat-store?  This should save/load a FPU register
after every operation. 

There is the -fpmath= option, but I'm not sure which switches
are appropriate for your cpu.  There is also the -msse set of
options.

To find out why you have differences, print out intermediate values
to 16 and 7 significant figures for real and double precision.  It
may also be helpful to read Goldberg's paper if you haven't (see
the gfortran wiki, manuals section).


-- 


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

[Bug libfortran/41335] VOLATILE in Fortran does not take effect

[mikael at gcc dot gnu dot org]

--- Comment #14 from mikael at gcc dot gnu dot org  2009-09-11 20:39 ---
With this:

Index: scanner.c
===
--- scanner.c   (revision 151461)
+++ scanner.c   (working copy)
@@ -1274,6 +1274,16 @@
 }


+char
+gfc_next_ascii_char_litteral (void)
+{
+  gfc_char_t c = gfc_wide_tolower(gfc_next_char_literal (0));
+  
+  return (gfc_wide_fits_in_byte (c) ? (unsigned char) c : 
+ (unsigned char) UCHAR_MAX);
+}
+
+
 gfc_char_t
 gfc_peek_char (void)
 {
Index: match.c
===
--- match.c (revision 151461)
+++ match.c (working copy)
@@ -522,7 +522,7 @@
   old_loc = gfc_current_locus;
   gfc_gobble_whitespace ();

-  c = gfc_next_ascii_char ();
+  c = gfc_next_ascii_char_litteral ();
   if (!(ISALPHA (c) || (c == '_' &&
gfc_option.flag_allow_leading_underscore)))
 {
   if (gfc_error_flag_test() == 0 && c != '(')
@@ -544,7 +544,7 @@
}

   old_loc = gfc_current_locus;
-  c = gfc_next_ascii_char ();
+  c = gfc_next_ascii_char_litteral ();
 }
   while (ISALNUM (c) || c == '_' || (gfc_option.flag_dollar_ok && c == '$'));



I get:

pr41335.f:3.23:

volatile double precision a 
   1
Error: Syntax error in VOLATILE statement at (1)


-- 


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

[Bug libfortran/41335] VOLATILE in Fortran does not take effect

[denis_scherbakov at yahoo dot com]

--- Comment #15 from denis_scherbakov at yahoo dot com  2009-09-11 20:54 
---
I just tried -ffloat-store and the results stay the same.

I would like to note that for "real" and "double precision" different assembler
code is produced. At least on my machine. Could somebody use -same-temps and
post assembler code that performs float operations? Please compile two times:
one with
"real", the other time with "double precision". Otherwise you'll get a mess.

In my assembler code you can clearly see, where differences start.


-- 


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

[Bug tree-optimization/41339] New: Variables can occur multiple times in cfun->local_decls

[baldrick at free dot fr]

While mucking around with gcc internals, I noticed that occasionally the
same tree can occur several times in the same cfun->local_decls list.
That seems like a bug(let).  Here's a testcase:

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

The problem shows up at -O2, presumably due to inlining:
  gcc -c -O2 testcase.c
To make the problem easy to see, I'll attach a debugging patch to this PR
that causes "error: Repeated variable in list of local declarations" to be
printed if a repeated variable is detected.  You have to set
VERIFY_LOCAL_DECLS in the environment for the patch to do anything.
Here's an example session:

$ export VERIFY_LOCAL_DECLS=true
$ gcc -c -O2 testcase.c
testcase.c: In function ‘__float128’:
testcase.c:2:1: error: Repeated variable in list of local declarations

I have no idea why it thinks the function is called __float128.


-- 
   Summary: Variables can occur multiple times in cfun->local_decls
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at free dot fr
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug tree-optimization/41339] Variables can occur multiple times in cfun->local_decls

[baldrick at free dot fr]

--- Comment #1 from baldrick at free dot fr  2009-09-11 21:05 ---
Created an attachment (id=18566)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18566&action=view)
Debugging patch that shows the problem

You need to build with checking enable.  You need to define VERIFY_LOCAL_DECLS
in the environment for the patch to do anything (I did this because otherwise
gcc will not build due to the check firing).


-- 


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

[Bug libfortran/41335] VOLATILE in Fortran does not take effect

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #16 from sgk at troutmask dot apl dot washington dot edu  
2009-09-11 21:08 ---
Subject: Re:  VOLATILE in Fortran does not take effect

On Fri, Sep 11, 2009 at 08:39:38PM -, mikael at gcc dot gnu dot org wrote:
> 
> I get:
> 
> pr41335.f:3.23:
> 
> volatile double precision a 
>1
> Error: Syntax error in VOLATILE statement at (1)
> 

Is this for fixed-form or free-form source code?
For fixed-form, the above should parse as 
'volatile doubleprecisiona'


-- 


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

[Bug tree-optimization/41339] Variables can occur multiple times in cfun->local_decls

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-09-11 21:12 ---
Is this after http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41275 ?

Because we should not have local_decls should be empty for these two functions
as far as I can tell ...


-- 


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

[Bug libfortran/41335] VOLATILE in Fortran does not take effect

[mikael at gcc dot gnu dot org]

--- Comment #17 from mikael at gcc dot gnu dot org  2009-09-11 21:18 ---
(In reply to comment #16)
> Is this for fixed-form or free-form source code?
> For fixed-form, the above should parse as 
> 'volatile doubleprecisiona'
> 
Yes, I've just discovered that.
Then the current behaviour is correct.


-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug other/41340] New: [4.5 Regression] G++ produces different code with and without -g option

[d dot g dot gorbachev at gmail dot com]

GCC 4.5.0 20090903, 20090910: bootstrap with `--enable-build-with-cxx' failed.

cc1plus -O2 -g rtl.ii


-- 
   Summary: [4.5 Regression] G++ produces different code with and
without -g option
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot g dot gorbachev at gmail dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug other/41340] [4.5 Regression] G++ produces different code with and without -g option

[d dot g dot gorbachev at gmail dot com]

--- Comment #1 from d dot g dot gorbachev at gmail dot com  2009-09-11 
21:33 ---
Created an attachment (id=18567)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18567&action=view)
gzipped preprocessed source file


-- 


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

[Bug c++/41341] New: gcc fails to reject inclass partial specialization of iherited class template

[tomek at jot23 dot org]

In the attached code partial specialization of struct apply in struct
METAFUNCTION2 should be rejected according to C++ Standard 14.7.3/3:

A declaration of a function template or class template being explicitly
specialized shall be in scope at the point of declaration of an explicit
specialization.

What's more troublesome is a fact that specialization in METAFUNCTION2 seems to
affect the template in METAFUNCTION. The program produces:

int
double
double

while I would expect:

int
HELPER
double


-- 
   Summary: gcc fails to reject inclass partial specialization of
iherited class template
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tomek at jot23 dot org


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

[Bug c++/41341] gcc fails to reject inclass partial specialization of iherited class template

[tomek at jot23 dot org]

--- Comment #1 from tomek at jot23 dot org  2009-09-11 21:40 ---
Created an attachment (id=18568)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18568&action=view)
the offending code


-- 


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

[Bug libfortran/41335] VOLATILE in Fortran does not take effect

[burnus at gcc dot gnu dot org]

--- Comment #18 from burnus at gcc dot gnu dot org  2009-09-11 22:07 ---
I looked at the assembler and the result is the following (non volatile vs.
volatile) [which is essentially the same with REAL(8) and REAL(4)]:

@@ -9,7 +9,7 @@
movl%esp, %ebp
subl$392, %esp
movl$.LC0, -360(%ebp)
-   movl$9, -356(%ebp)
+   movl$8, -356(%ebp)
movl$128, -368(%ebp)
movl$5, -364(%ebp)
leal-368(%ebp), %eax
@@ -33,16 +33,16 @@
flds-24(%ebp)
flds-24(%ebp)
fmulp   %st, %st(1)
-   fstps   -12(%ebp)
+   fstps   -16(%ebp)
flds-28(%ebp)
flds-28(%ebp)
fmulp   %st, %st(1)
-   fstps   -16(%ebp)
-   flds-12(%ebp)
-   fsubs   -16(%ebp)
+   fstps   -12(%ebp)
+   flds-16(%ebp)
+   fsubs   -12(%ebp)
fstps   -20(%ebp)
movl$.LC0, -360(%ebp)
-   movl$16, -356(%ebp)
+   movl$15, -356(%ebp)
movl$128, -368(%ebp)
movl$6, -364(%ebp)
leal-368(%ebp), %eax


-- 


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

[Bug fortran/39876] module procedure name that collides with the GNU intrinsic

[kargl at gcc dot gnu dot org]

--- Comment #8 from kargl at gcc dot gnu dot org  2009-09-11 22:11 ---
Subject: Bug 39876

Author: kargl
Date: Fri Sep 11 22:11:06 2009
New Revision: 151645

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151645
Log:
2009-09-11 Steven G. Kargl  

Backport from mainline, r147279:

2009-05-08  Janus Weil  

PR fortran/39876
* intrinsic.c (gfc_is_intrinsic): Do not add the EXTERNAL attribute if
the symbol is a module procedure.

2009-05-08  Janus Weil  

PR fortran/39876
* gfortran.dg/intrinsic_3.f90: New.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/intrinsic_3.f90
  - copied unchanged from r147279,
trunk/gcc/testsuite/gfortran.dg/intrinsic_3.f90
Modified:
branches/gcc-4_4-branch/gcc/fortran/ChangeLog
branches/gcc-4_4-branch/gcc/fortran/intrinsic.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/41222] [4.4 Regression] "-std=f95" forbids USEd functions named like f03/f08 intrisics

[kargl at gcc dot gnu dot org]

--- Comment #5 from kargl at gcc dot gnu dot org  2009-09-11 22:16 ---
I've merged revision 147279 from mainline to the 4.4 branch.
Thanks for the bug report.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libfortran/41335] VOLATILE in Fortran does not take effect

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #19 from sgk at troutmask dot apl dot washington dot edu  
2009-09-11 22:39 ---
Subject: Re:  VOLATILE in Fortran does not take effect

On Fri, Sep 11, 2009 at 06:18:35PM -, kargl at gcc dot gnu dot org wrote:
> 
> program VolatileTest
>   double precision, volatile :: a
>   double precision :: uA, uB, b, c
>   real, volatile :: ra
>   real :: ruA, ruB, rb, rc
>   read(*,*) uA, uB, ruA, ruB
>   a = uA * uA
>   b = uB * uB
>   c = a - b
>   ra = ruA * ruA
>   rb = ruB * ruB
>   rc = ra - rb
>   print *, c, rb
> end program VolatileTest
> 

Minor correction.  The print statement should be

   print *, c, rc


-- 


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

[Bug target/41246] should "sorry" when regparm=3 and nested functions are encountered

[rth at gcc dot gnu dot org]

--- Comment #16 from rth at gcc dot gnu dot org  2009-09-11 23:15 ---
Mine.


-- 

rth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-09-03 17:11:30 |2009-09-11 23:15:31
   date||


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

[Bug middle-end/41250] hppa has DECL_VALUE_EXPR decls appearing in the function

[jamborm at gcc dot gnu dot org]

--- Comment #2 from jamborm at gcc dot gnu dot org  2009-09-11 23:38 ---
I ran into too many problems when I tried to inhibit value_expr
PARM_DECL substitutions in the gimplifier.  At the moment I believe we
should not use the value_expr just for debug info and rather try
BLOCK_NONLOCALIZED_VARS from pretty-ipa.  

I've just sent an email about this to the gcc mailing list:
http://gcc.gnu.org/ml/gcc/2009-09/msg00218.html


-- 


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

[Bug debug/41342] New: Var tracking appears to run out of memory .

[ramana at gcc dot gnu dot org]

For the attached case distilled from eglibc sources - the compiler ends up by
running out of Virtual memory for compilations with -O2 -g . Turning this off
using -fno-var-tracking-location appears to workaround the issue.

Here's the memory usage that I see for this one.  


 PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND 
32172 ramana20   0 3047m 2.7g 3856 R   67 92.4   0:57.00 cc1 


The tools were configured with --target=arm-none-eabi --with-float=softfp
--with-fpu=neon . However running the attached testcase with march=armv4t
mfpu=vfp and mfloat-abi=soft doesn't have any different visible effects.


-- 
   Summary: Var tracking appears to run out of memory .
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-none-eabi


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

[Bug debug/41342] Var tracking appears to run out of memory .

[ramana at gcc dot gnu dot org]

--- Comment #1 from ramana at gcc dot gnu dot org  2009-09-11 23:52 ---
Created an attachment (id=18569)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18569&action=view)
Failed testcase.

Testcase for failure.  Test by running -O2 -g on arm-none-eabi


-- 


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

[Bug target/41246] should "sorry" when regparm=3 and nested functions are encountered

[rth at gcc dot gnu dot org]

--- Comment #17 from rth at gcc dot gnu dot org  2009-09-12 00:00 ---
Created an attachment (id=18570)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18570&action=view)
trampoline push, version 1

Here's a lightly tested patch that implements the idea in comment #14.
Will those that care about this topic please give this a workout over
the weekend, and I'll finish it up next week.


-- 

rth at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #18480|0   |1
is obsolete||
  Attachment #18482|0   |1
is obsolete||


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

[Bug libfortran/41335] VOLATILE in Fortran does not take effect

[kargl at gcc dot gnu dot org]

--- Comment #20 from kargl at gcc dot gnu dot org  2009-09-12 01:31 ---
AFAICT, this PR 323.

program VolatileTest

  implicit none

  real(8), volatile :: a
  real(8) uA, uB, b, c

  real(4), volatile :: ra
  real(4) ruA, ruB, rb, rc

  read(*,*) uA, uB, rua, ruB

  a = uA * uA
  b = uB * uB
  c = a - b

  ra = ruA * ruA
  rb = ruB * ruB
  rc = ra - rb

  write(*,'(3ES24.16)')  a,  b,  c
  write(*,'(Z16,1X,Z16,1X,Z16)')a,  b,  c

  write(*,'(3ES15.7)')  ra, rb, rc
  write(*,'(Z8,1X,Z8,1X,Z8)')  ra, rb, rc

end program VolatileTest

My  test system,

CPU: Intel(R) Core(TM)2 Duo CPU T7250  @ 2.00GHz (1995.02-MHz 686-class
CPU)
  Origin = "GenuineIntel"  Id = 0x6fd  Stepping = 13
 
Features=0xbfebfbff
  Features2=0xe3bd
  AMD Features=0x2010
  AMD Features2=0x1
  TSC: P-state invariant

REMOVE:kargl[52] gfc4x -o z dd.f90
REMOVE:kargl[53] ./z
0.1 0.1 0.1 0.1
  1.0002E-02  1.0002E-02  0.E+00
3F847AE147AE147C 3F847AE147AE147C0
  1.001E-02  1.001E-02  0.000E+00
3C23D70B 3C23D70B0


REMOVE:kargl[54] gfc4x -o z -O2 dd.f90
REMOVE:kargl[55] ./z
0.1 0.1 0.1 0.1 0.1
  1.0002E-02  1.0002E-02  0.E+00
3F847AE147AE147C 3F847AE147AE147C0
  1.001E-02  1.001E-02  4.0978193E-10
3C23D70B 3C23D70B 2FE147AE



REMOVE:kargl[56] gfc4x -o z -O2 -mfpmath=387 dd.f90
REMOVE:kargl[57] ./z
0.1 0.1 0.1 0.1
  1.0002E-02  1.0002E-02  0.E+00
3F847AE147AE147C 3F847AE147AE147C0
  1.001E-02  1.001E-02  4.0978193E-10
3C23D70B 3C23D70B 2FE147AE



REMOVE:kargl[59] gfc4x -o z -O2 -mfpmath=387 -ffloat-store dd.f90
REMOVE:kargl[60] ./z
0.1 0.1 0.1 0.1
  1.0002E-02  1.0002E-02  0.E+00
3F847AE147AE147C 3F847AE147AE147C0
  1.001E-02  1.001E-02  0.000E+00
3C23D70B 3C23D70B0


-- 


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

[Bug middle-end/41343] New: sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[froydnj at gcc dot gnu dot org]

When compiling the attached file as:

powerpc-linux-gnu-gcc dosincos.i -g -O2 -std=gnu99 -fgnu89-inline
-fmerge-all-constants

The memory use of GCC balloons to 4GB+.  I have a low ulimit on my machine, so
I don't know whether leaving it alone with more memory would let the
compilation finish.  Using -fdump-tree-all-details indicates that things die
somewhere in the inline_param3 pass.

Discussion on IRC demonstrates the same behavior with a cross compiler from
x86-64, with memory usage up to 12GB without finishing.


-- 
   Summary: sysdeps/ieee754/dbl-64/dosincos.c from glibc causes
excessive memory use
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: froydnj at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: powerpc-linux-gnu


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

[Bug middle-end/41343] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[froydnj at gcc dot gnu dot org]

--- Comment #1 from froydnj at gcc dot gnu dot org  2009-09-12 04:05 ---
Created an attachment (id=18571)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18571&action=view)
testcase


-- 


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

[Bug fortran/41219] libgfortran build warnings

[nightstrike at gmail dot com]

--- Comment #12 from nightstrike at gmail dot com  2009-09-12 05:36 ---
Current warning list as of revision 151630:

../../../../../build/gcc/gcc/libgfortran/io/write.c:328:8: warning: passing
argument 2 of 'write_default_char4' from incompatible pointer type
../../../../../build/gcc/gcc/libgfortran/intrinsics/iso_c_binding.c:98:24:
warning: 'str' may be used uninitialized in this function
../../../../../build/gcc/gcc/libgfortran/intrinsics/unpack_generic.c:60:32:
warning: unused parameter 'fsize'


-- 


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

[Bug middle-end/41343] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[aoliva at gcc dot gnu dot org]

--- Comment #2 from aoliva at gcc dot gnu dot org  2009-09-12 06:39 ---
Created an attachment (id=18572)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18572&action=view)
patch that might help alleviate the problem

This patch helped me save a lot of memory on another PPC testcase that involved
lots of expressions with equivalent values, which causes “interesting“ behavior
in var-tracking/cselib, generating a lot of RTL junk.  From your description,
it's not clear that it's the same problem, but I thought I'd post the
(unpolished) patch anyway, because a proper algorithmic fix to var-tracking
will take longer.  Even more so because I'm away for a week, starting today.  I
hope this helps.  Please let me know.


-- 


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

[Bug debug/41342] Var tracking appears to run out of memory .

[ramana at gcc dot gnu dot org]

--- Comment #2 from ramana at gcc dot gnu dot org  2009-09-12 06:48 ---
This looks like a dup of PR41343. I'm marking this as a dup of PR41343 because
there's a patch submitted there and an extra comment from Alex.

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


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/41343] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[ramana at gcc dot gnu dot org]

--- Comment #3 from ramana at gcc dot gnu dot org  2009-09-12 06:48 ---
*** Bug 41342 has been marked as a duplicate of this bug. ***


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu dot
   ||org


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

[Bug middle-end/41343] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[ramana at gcc dot gnu dot org]

--- Comment #4 from ramana at gcc dot gnu dot org  2009-09-12 06:49 ---
This test case fails for an arm-linux-gnueabi target as well.


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 GCC target triplet|powerpc-linux-gnu   |powerpc-linux-gnu, arm-
   ||linux-gnueabi


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