[Bug middle-end/37448] [4.3 Regression] gcc 4.3.1 cannot compile big function

[lucier at math dot purdue dot edu]

--- Comment #14 from lucier at math dot purdue dot edu  2008-09-18 01:30 
---
Created an attachment (id=16351)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16351&action=view)
detailed memory stats with checking enabled and long statistic counters

I reran the test problem with checking enabled and this patch, which changes
the memory statistic counters from int to long, installed:

http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01270.html

So we see that 5,272,694,920 bytes are allocated in alloc_pools, and
331,198,680 btytes are allocated in bitmaps.


-- 


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

[Bug target/36539] IRA+i386 doesn't allocate asm output being returned to eax

[astrange at ithinksw dot com]

--- Comment #7 from astrange at ithinksw dot com  2008-09-18 01:29 ---
Updated to 32-bit only.


-- 

astrange at ithinksw dot com changed:

   What|Removed |Added

   Severity|normal  |enhancement
 GCC target triplet|x86_64-*-*  |i?86-*-*
Summary|IRA doesn't allocate asm|IRA+i386 doesn't allocate
   |output being returned to eax|asm output being returned to
   ||eax


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

[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines

[lucier at math dot purdue dot edu]

--- Comment #75 from lucier at math dot purdue dot edu  2008-09-18 01:19 
---
Created an attachment (id=16350)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16350&action=view)
statistics with checking enabled and using longs to count bytes

Using the patch from

http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01270.html

I gathered statistics using 64-bit longs for this test case. Using it, one
finds that 10,292,897,120 bytes of bitmaps and 6,449,831,120 bytes in
alloc-pools are allocated with mainline for this test case (at least when
checking is enabled).


-- 


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

[Bug tree-optimization/30930] [4.3/4.4 Regression] vector can cause to create an extra variable, DECL_GIMPLE_REG_P not recomputed

[pinskia at gcc dot gnu dot org]

--- Comment #11 from pinskia at gcc dot gnu dot org  2008-09-18 01:00 
---
Here is a testcase which shows a missed optimization in general (on both the
tree level and the RTL one) for x86 with SSE2:
#define vector __attribute((vector_size(16) ))
vector float a;

float f(float b)
{
  vector float c = {0, 0, 0, 0};
  vector float d = {0, 0, 0, 0};
  d += c;
  return ((float*)&c)[2];
}


-- 


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

[Bug tree-optimization/37568] [4.4 regression] ICE returning a struct

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug tree-optimization/37568] New: [4.4 regression] ICE returning a struct

[reichelt at gcc dot gnu dot org]

The following valid C++ testcase triggers an ICE on mainline when compiled
with "-fmudflap -O":

==
struct A
{
  int i;
};

A foo()
{
  A a = { 1 };
  return a;
}

A a = foo();
==

bug.cc: In function 'A foo()':
bug.cc:12: internal compiler error: in analyze_function, at ipa-reference.c:724
Please submit a full bug report, [etc.]

The regression appeared after 2008-09-12.


-- 
   Summary: [4.4 regression] ICE returning a struct
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, monitored
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug testsuite/25241] [C++] DejaGNU does not distinguish between errors and warnings

[janis at gcc dot gnu dot org]

--- Comment #63 from janis at gcc dot gnu dot org  2008-09-17 23:24 ---
Subject: Bug 25241

Author: janis
Date: Wed Sep 17 23:23:11 2008
New Revision: 140437

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140437
Log:
PR testsuite/25241
* g++.old-deja/g++.brendan/crash7.C: Remove "error" or "warning" from
message for dg-error/dg-warning.
* g++.old-deja/g++.jason/crash11.C: Ditto.
* g++.old-deja/g++.oliva/template1.C: Ditto.
* g++.old-deja/g++.benjamin/tem03.C: Ditto.
* g++.dg/rtti/no-rtti.C: Ditto.
* g++.dg/cpp/pedantic-errors.C: Ditto.
* g++.dg/cpp/string-2.C: Ditto.
* g++.dg/ext/fpreg1.C: Ditto.
* g++.dg/ext/altivec-types-1.C: Ditto.
* g++.dg/warn/write-strings-default.C: Ditto.
* g++.dg/warn/Wvla-2.C: Ditto.
* g++.dg/warn/register-var-1.C: Ditto.
* g++.dg/warn/deprecated-3.C: Ditto.
* g++.dg/warn/pr30551-2.C: Ditto.
* g++.dg/warn/overflow-warn-1.C: Ditto.
* g++.dg/warn/pr30551.C: Ditto.
* g++.dg/warn/pointer-integer-comparison.C: Ditto.
* g++.dg/warn/pr12242.C: Ditto.
* g++.dg/warn/write-strings.C: Ditto.
* g++.dg/warn/overflow-warn-3.C: Ditto.
* g++.dg/warn/overflow-warn-4.C: Ditto.
* g++.dg/warn/overflow-warn-6.C: Ditto.
* g++.dg/parse/crash43.C: Ditto.
* g++.dg/parse/crash44.C: Ditto.
* g++.dg/parse/offsetof8.C: Ditto.
* g++.dg/gomp/pr35158.C: Ditto.
* g++.dg/template/crash81.C: Ditto.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp/pedantic-errors.C
trunk/gcc/testsuite/g++.dg/cpp/string-2.C
trunk/gcc/testsuite/g++.dg/ext/altivec-types-1.C
trunk/gcc/testsuite/g++.dg/ext/fpreg1.C
trunk/gcc/testsuite/g++.dg/gomp/pr35158.C
trunk/gcc/testsuite/g++.dg/parse/crash43.C
trunk/gcc/testsuite/g++.dg/parse/crash44.C
trunk/gcc/testsuite/g++.dg/parse/offsetof8.C
trunk/gcc/testsuite/g++.dg/rtti/no-rtti.C
trunk/gcc/testsuite/g++.dg/template/crash81.C
trunk/gcc/testsuite/g++.dg/warn/Wvla-2.C
trunk/gcc/testsuite/g++.dg/warn/deprecated-3.C
trunk/gcc/testsuite/g++.dg/warn/overflow-warn-1.C
trunk/gcc/testsuite/g++.dg/warn/overflow-warn-3.C
trunk/gcc/testsuite/g++.dg/warn/overflow-warn-4.C
trunk/gcc/testsuite/g++.dg/warn/overflow-warn-6.C
trunk/gcc/testsuite/g++.dg/warn/pointer-integer-comparison.C
trunk/gcc/testsuite/g++.dg/warn/pr12242.C
trunk/gcc/testsuite/g++.dg/warn/pr30551-2.C
trunk/gcc/testsuite/g++.dg/warn/pr30551.C
trunk/gcc/testsuite/g++.dg/warn/register-var-1.C
trunk/gcc/testsuite/g++.dg/warn/write-strings-default.C
trunk/gcc/testsuite/g++.dg/warn/write-strings.C
trunk/gcc/testsuite/g++.old-deja/g++.benjamin/tem03.C
trunk/gcc/testsuite/g++.old-deja/g++.brendan/crash7.C
trunk/gcc/testsuite/g++.old-deja/g++.jason/crash11.C
trunk/gcc/testsuite/g++.old-deja/g++.oliva/template1.C


-- 


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

[Bug libstdc++/37547] [c++0x] minmax with initializer_list gives incorrect results

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug libstdc++/37547] [c++0x] minmax with initializer_list gives incorrect results

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2008-09-17 23:04 
---
Fixed.


-- 

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

[Bug libstdc++/37547] [c++0x] minmax with initializer_list gives incorrect results

[paolo at gcc dot gnu dot org]

--- Comment #2 from paolo at gcc dot gnu dot org  2008-09-17 22:59 ---
Subject: Bug 37547

Author: paolo
Date: Wed Sep 17 22:58:38 2008
New Revision: 140435

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

PR libstdc++/37547
* include/bits/stl_algo.h (min(initializer_list<>),
min(initializer_list<>, Compare), max(initializer_list<>),
max(initializer_list<>, Compare), minmax(initializer_list<>),
minmax(initializer_list<>, Compare)): Fix return type.
* include/bits/algorithmfwd.h: Adjust.
* testsuite/25_algorithms/headers/algorithm/synopsis.cc: Likewise.
* testsuite/25_algorithms/max/requirements/explicit_instantiation/3.cc:
Likewise.
* testsuite/25_algorithms/max/requirements/explicit_instantiation/
pod2.cc: Likewise.
* testsuite/25_algorithms/min/requirements/explicit_instantiation/3.cc:
Likewise.
* testsuite/25_algorithms/min/requirements/explicit_instantiation/
pod2.cc: Likewise.
* testsuite/25_algorithms/minmax/requirements/explicit_instantiation/
3.cc: Likewise.
* testsuite/25_algorithms/minmax/requirements/explicit_instantiation/
pod2.cc: Likewise.
* testsuite/25_algorithms/max/37547.cc: New.
* testsuite/25_algorithms/min/37547.cc: Likewise.
* testsuite/25_algorithms/minmax/37547.cc: Likewise.

Added:
trunk/libstdc++-v3/testsuite/25_algorithms/max/37547.cc
trunk/libstdc++-v3/testsuite/25_algorithms/min/37547.cc
trunk/libstdc++-v3/testsuite/25_algorithms/minmax/37547.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/algorithmfwd.h
trunk/libstdc++-v3/include/bits/stl_algo.h
trunk/libstdc++-v3/testsuite/25_algorithms/headers/algorithm/synopsis.cc
   
trunk/libstdc++-v3/testsuite/25_algorithms/max/requirements/explicit_instantiation/3.cc
   
trunk/libstdc++-v3/testsuite/25_algorithms/max/requirements/explicit_instantiation/pod2.cc
   
trunk/libstdc++-v3/testsuite/25_algorithms/min/requirements/explicit_instantiation/3.cc
   
trunk/libstdc++-v3/testsuite/25_algorithms/min/requirements/explicit_instantiation/pod2.cc
   
trunk/libstdc++-v3/testsuite/25_algorithms/minmax/requirements/explicit_instantiation/3.cc
   
trunk/libstdc++-v3/testsuite/25_algorithms/minmax/requirements/explicit_instantiation/pod2.cc


-- 


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

[Bug middle-end/37567] New: tree SSA to normal checking takes abnormally long time

[lucier at math dot purdue dot edu]

When configured with

Configured with: ../../mainline/configure --with-gmp=/pkgs/gmp-4.2.2/
--with-mpfr=/pkgs/gmp-4.2.2/ --prefix=/pkgs/gcc-mainline
--enable-gather-detailed-mem-stats

and run on the testcase of PR 26854 with

/pkgs/gcc-mainline/bin/gcc -Wall -W -Wno-unused -O1 -fno-math-errno
-fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv
-fomit-frame-pointer -fPIC -ftime-report -fmem-report -c all.i >>&
mainline-stats-2008-09-17-c

one line stands out:

 tree SSA to normal: 485.81 (61%) usr   0.12 ( 0%) sys 486.01 (59%) wall  
93945 kB (12%) ggc
 TOTAL : 793.9924.78   819.45
795105 kB

without checking, this is

 tree SSA to normal:  13.31 ( 8%) usr   0.10 ( 1%) sys  13.42 ( 7%) wall  
93945 kB (12%) ggc
 TOTAL : 168.3314.57   183.12
794201 kB

The timings of other parts of a checking-enabled compiler seem reasonable.


-- 
   Summary: tree SSA to normal checking takes abnormally long time
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
 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=37567

[Bug libstdc++/37547] [c++0x] minmax with initializer_list gives incorrect results

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC|paolo dot carlini at oracle |
   |dot com |
 AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
   |dot org |dot com
 Status|NEW |ASSIGNED


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

[Bug tree-optimization/30930] [4.3/4.4 Regression] vector can cause to create an extra variable, DECL_GIMPLE_REG_P not recomputed

[pinskia at gcc dot gnu dot org]

--- Comment #10 from pinskia at gcc dot gnu dot org  2008-09-17 22:50 
---
Here is a testcase where we were missing an optimization at the tree level
because of DECL_GIMPLE_REG_P:
#define vector __attribute__(( vector_size(16) ))

float f(vector float a, int b, vector float c)
{
  vector float dd = c*a;
  a = (vector float){0,0,0,0};
  c = (vector float){0,0,0,0};
  {
   float d = ((float*)&a)[0];
   float d1 = ((float*)&c)[0];
   return d*d1;
  }
}


-- 


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

[Bug tree-optimization/30930] [4.3/4.4 Regression] vector can cause to create an extra variable, DECL_GIMPLE_REG_P not recomputed

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2008-09-17 22:40 ---
Note I needed to add a check to make sure we are only doing this currently for
complex and vector types since those are the ones that have DECL_GIMPLE_REG_P
currently.


-- 


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

[Bug fortran/36454] too cautionous alias checking with renamed variables/types from modules (Error: ACCESS specification already specified)

[pault at gcc dot gnu dot org]

--- Comment #5 from pault at gcc dot gnu dot org  2008-09-17 22:33 ---
Fixed on trunk.

I'll wait a few days and fix on 4.3.

Thanks for the report

Paul


-- 


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

[Bug fortran/36374] nested module inclusion fails

[pault at gcc dot gnu dot org]

--- Comment #5 from pault at gcc dot gnu dot org  2008-09-17 22:31 ---
Fixed on trunk.  I'll wait a few days for 4.3.0.

Thanks for the report.

Paul


-- 


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

[Bug fortran/37274] [Regression on 4.3?] error: type name is ambiguous.

[pault at gcc dot gnu dot org]

--- Comment #19 from pault at gcc dot gnu dot org  2008-09-17 22:30 ---
Fixed on trunk

Thanks for the report

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[Regression 4.4 (and 4.3?)] |[Regression on 4.3?] error:
   |error: type name is |type name is ambiguous.
   |ambiguous.  |


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

[Bug tree-optimization/30930] [4.3/4.4 Regression] vector can cause to create an extra variable, DECL_GIMPLE_REG_P not recomputed

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2008-09-17 22:28 ---
Created an attachment (id=16349)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16349&action=view)
Patch which piggy backs on honza's addressable pass

This is a patch which uses honza's mini-addressable pass to the same thing for
DECL_GIMPLE_REG_P.  It can be used for the generic case instead of just vector
types which will help out the VCE on the LHS side issue.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/37274] [Regression 4.4 (and 4.3?)] error: type name is ambiguous.

[pault at gcc dot gnu dot org]

--- Comment #18 from pault at gcc dot gnu dot org  2008-09-17 22:25 ---
Subject: Bug 37274

Author: pault
Date: Wed Sep 17 22:23:51 2008
New Revision: 140434

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140434
Log:
2008-09-18  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/37274
PR fortran/36374
* module.c (check_for_ambiguous): New function to test loaded
symbol for ambiguity with fixup symbol.
(read_module): Call check_for_ambiguous.
(write_symtree): Do not write the symtree for symbols coming
from an interface body.

PR fortran/36374
* resolve.c (count_specific_procs ): New function to count the
number of specific procedures with the same name as the generic
and emit appropriate errors for and actual argument reference.
(resolve_assumed_size_actual): Add new argument no_formal_args.
Correct logic around passing generic procedures as arguments.
Call count_specific_procs from two locations.
(resolve_function): Evaluate and pass no_formal_args.
(resolve call): The same and clean up a bit by using csym more
widely.

PR fortran/36454
* symbol.c (gfc_add_access): Access can be updated if use
associated and not private.

2008-09-18  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/37274
* gfortran.dg/used_types_22.f90: New test.
* gfortran.dg/used_types_23.f90: New test.

PR fortran/36374
* gfortran.dg/generic_17.f90: New test.
* gfortran.dg/ambiguous_specific_2.f90: New test.
* gfortran.dg/generic_actual_arg.f90: Add test for case that is
not ambiguous.

PR fortran/36454
* gfortran.dg/access_spec_3.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/access_spec_3.f90
trunk/gcc/testsuite/gfortran.dg/ambiguous_specific_2.f90
trunk/gcc/testsuite/gfortran.dg/generic_17.f90
trunk/gcc/testsuite/gfortran.dg/used_types_22.f90
trunk/gcc/testsuite/gfortran.dg/used_types_23.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/generic_actual_arg.f90


-- 


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

[Bug fortran/36374] nested module inclusion fails

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2008-09-17 22:25 ---
Subject: Bug 36374

Author: pault
Date: Wed Sep 17 22:23:51 2008
New Revision: 140434

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140434
Log:
2008-09-18  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/37274
PR fortran/36374
* module.c (check_for_ambiguous): New function to test loaded
symbol for ambiguity with fixup symbol.
(read_module): Call check_for_ambiguous.
(write_symtree): Do not write the symtree for symbols coming
from an interface body.

PR fortran/36374
* resolve.c (count_specific_procs ): New function to count the
number of specific procedures with the same name as the generic
and emit appropriate errors for and actual argument reference.
(resolve_assumed_size_actual): Add new argument no_formal_args.
Correct logic around passing generic procedures as arguments.
Call count_specific_procs from two locations.
(resolve_function): Evaluate and pass no_formal_args.
(resolve call): The same and clean up a bit by using csym more
widely.

PR fortran/36454
* symbol.c (gfc_add_access): Access can be updated if use
associated and not private.

2008-09-18  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/37274
* gfortran.dg/used_types_22.f90: New test.
* gfortran.dg/used_types_23.f90: New test.

PR fortran/36374
* gfortran.dg/generic_17.f90: New test.
* gfortran.dg/ambiguous_specific_2.f90: New test.
* gfortran.dg/generic_actual_arg.f90: Add test for case that is
not ambiguous.

PR fortran/36454
* gfortran.dg/access_spec_3.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/access_spec_3.f90
trunk/gcc/testsuite/gfortran.dg/ambiguous_specific_2.f90
trunk/gcc/testsuite/gfortran.dg/generic_17.f90
trunk/gcc/testsuite/gfortran.dg/used_types_22.f90
trunk/gcc/testsuite/gfortran.dg/used_types_23.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/generic_actual_arg.f90


-- 


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

[Bug fortran/36454] too cautionous alias checking with renamed variables/types from modules (Error: ACCESS specification already specified)

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2008-09-17 22:25 ---
Subject: Bug 36454

Author: pault
Date: Wed Sep 17 22:23:51 2008
New Revision: 140434

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140434
Log:
2008-09-18  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/37274
PR fortran/36374
* module.c (check_for_ambiguous): New function to test loaded
symbol for ambiguity with fixup symbol.
(read_module): Call check_for_ambiguous.
(write_symtree): Do not write the symtree for symbols coming
from an interface body.

PR fortran/36374
* resolve.c (count_specific_procs ): New function to count the
number of specific procedures with the same name as the generic
and emit appropriate errors for and actual argument reference.
(resolve_assumed_size_actual): Add new argument no_formal_args.
Correct logic around passing generic procedures as arguments.
Call count_specific_procs from two locations.
(resolve_function): Evaluate and pass no_formal_args.
(resolve call): The same and clean up a bit by using csym more
widely.

PR fortran/36454
* symbol.c (gfc_add_access): Access can be updated if use
associated and not private.

2008-09-18  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/37274
* gfortran.dg/used_types_22.f90: New test.
* gfortran.dg/used_types_23.f90: New test.

PR fortran/36374
* gfortran.dg/generic_17.f90: New test.
* gfortran.dg/ambiguous_specific_2.f90: New test.
* gfortran.dg/generic_actual_arg.f90: Add test for case that is
not ambiguous.

PR fortran/36454
* gfortran.dg/access_spec_3.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/access_spec_3.f90
trunk/gcc/testsuite/gfortran.dg/ambiguous_specific_2.f90
trunk/gcc/testsuite/gfortran.dg/generic_17.f90
trunk/gcc/testsuite/gfortran.dg/used_types_22.f90
trunk/gcc/testsuite/gfortran.dg/used_types_23.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/generic_actual_arg.f90


-- 


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

[Bug tree-optimization/37102] [4.3/4.4 Regression] out-of-SSA is broken

[amacleod at redhat dot com]

--- Comment #17 from amacleod at redhat dot com  2008-09-17 21:55 ---
Created an attachment (id=16348)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16348&action=view)
Patch submitted

Doh. The last patch for the dead code removal had a disabling check in it that
I was using for some testing, so it didn't actually do anything :-P

This is the correct patch which I will be checking in. It has been bootstrapped
and passed all tests with no regressions on x86_64-unknown-linux-gnu. 


-- 

amacleod at redhat dot com changed:

   What|Removed |Added

  Attachment #16343|0   |1
is obsolete||
  Attachment #16345|0   |1
is obsolete||


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

[Bug fortran/37536] [4.3/4.4 Regression] a mfcr is produced instead of branches for DO loops

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2008-09-17 21:53 ---
Fixed on the trunk.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|4.3.3   |4.4.0


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

[Bug fortran/37536] [4.3/4.4 Regression] a mfcr is produced instead of branches for DO loops

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2008-09-17 21:53 ---
Subject: Bug 37536

Author: jakub
Date: Wed Sep 17 21:51:50 2008
New Revision: 140433

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140433
Log:
PR fortran/37536
* trans-stmt.c (gfc_trans_do): Optimize integer type non-simple
do loop initialization.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-stmt.c


-- 


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

[Bug objc/37460] [4.4 Regression]: NeXT runtime ICEs

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2008-09-17 21:40 ---
Subject: Bug 37460

Author: pinskia
Date: Wed Sep 17 21:39:13 2008
New Revision: 140430

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140430
Log:
2008-09-17  Andrew Pinski  <[EMAIL PROTECTED]>

* tree.c (get_callee_fndecl): Don't call the language hook.
* langhooks.h (lang_hooks): Remove lang_get_callee_fndecl.
* langhooks-def.h (LANG_HOOKS_GET_CALLEE_FNDECL): Kill.
(LANG_HOOKS_INITIALIZER): Remove LANG_HOOKS_GET_CALLEE_FNDECL.


2008-09-17  Andrew Pinski  <[EMAIL PROTECTED]>

PR objc/37460
* objc-lang.c (LANG_HOOKS_GET_CALLEE_FNDECL): Don't define.
* objc-act.h (objc_get_callee_fndecl): Remove prototype.
* objc-act.c (objc_get_callee_fndecl): Kill.

2008-09-17  Andrew Pinski  <[EMAIL PROTECTED]>

* lang.c (LANG_HOOKS_GET_CALLEE_FNDECL): Don't define.
(java_get_callee_fndecl): Kill.

2008-09-17  Andrew Pinski  <[EMAIL PROTECTED]>

PR objc/37460
* objcp-lang.c (LANG_HOOKS_GET_CALLEE_FNDECL): Don't define.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/java/ChangeLog
trunk/gcc/java/lang.c
trunk/gcc/langhooks-def.h
trunk/gcc/langhooks.h
trunk/gcc/objc/ChangeLog
trunk/gcc/objc/objc-act.c
trunk/gcc/objc/objc-act.h
trunk/gcc/objc/objc-lang.c
trunk/gcc/objcp/ChangeLog
trunk/gcc/objcp/objcp-lang.c
trunk/gcc/tree.c


-- 


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

[Bug objc/37460] [4.4 Regression]: NeXT runtime ICEs

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2008-09-17 21:39 ---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/35782] support for standard layout types

[jason at gcc dot gnu dot org]

--- Comment #7 from jason at gcc dot gnu dot org  2008-09-17 21:17 ---
8.5.1 says "An aggregate is an array or a class (Clause 9) with ... no base
classes (Clause 10)"

Lawrence's suggestion won't work because the copy constructor is deleted.  To
make aggregate initialization work, we need to expand the definition of
aggregate to include classes with user-provided constructors that are all
deleted.


-- 


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

[Bug c++/37553] [4.3/4.4 Regression] ICE in build_c_cast

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-09-17 21:02 ---
I get a different internal compiler error:
t.cc:24: internal compiler error: canonical types differ for identical types
ui32 and ui32a
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2008-09-17 21:02:56
   date||
Summary|ICE in build_c_cast |[4.3/4.4 Regression] ICE in
   ||build_c_cast
   Target Milestone|--- |4.3.3


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

[Bug c++/37563] [4.3/4.4 regression] Trouble calling qualified member function

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-09-17 21:00 ---
I think this is related to PR 32384.


-- 


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

[Bug fortran/37566] gfortran segfaults

[brian at dessent dot net]

--- Comment #3 from brian at dessent dot net  2008-09-17 20:44 ---
Subject: Re:  gfortran segfaults

You don't appear to be building FSF gcc but instead a Redhat patched
gcc:

configure:10520:
/builddir/build/BUILD/gcc-4.3.2-20080905/obj-sparc64-redhat-linux/./gcc/gfortran
-B/builddir/build/BUILD/gcc-4.3.2-20080905/obj-sparc64-redhat-linux/./gcc/
-B/usr/sparc64-redhat-linux/bin/ -B/usr/sparc64-redhat-linux/lib/
-isystem /usr/sparc64-redhat-linux/include -isystem
/usr/sparc64-redhat-linux/sys-include --version &5
GNU Fortran (GCC) 4.3.2 20080905 (Red Hat 4.3.2-3)
Copyright (C) 2008 Free Software Foundation, Inc.


configure:13398:
/builddir/build/BUILD/gcc-4.3.2-20080905/obj-sparc64-redhat-linux/./gcc/gfortran
-B/builddir/build/BUILD/gcc-4.3.2-20080905/obj-sparc64-redhat-linux/./gcc/
-B/usr/sparc64-redhat-linux/bin/ -B/usr/sparc64-redhat-linux/lib/
-isystem /usr/sparc64-redhat-linux/include -isystem
/usr/sparc64-redhat-linux/sys-include -c -g -O2  conftest.f >&5
: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

You should report the ICE to redhat bugzilla as it says in the error.


-- 


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

[Bug fortran/37566] gfortran segfaults

[brian at dessent dot net]

--- Comment #2 from brian at dessent dot net  2008-09-17 20:39 ---
Subject: Re:   New: gfortran segfaults

> [EMAIL PROTECTED] obj-sparc64-redhat-linux]$ gcc/gfortran conftest.f -o
> conftest
> gfortran: error trying to exec 'f951': execvp: No such file or directory

This doesn't demonstrate anything out of the orindary as you can't run
uninstalled compilers out of the build directory without the proper -B
flag, otherwise they can't locate their components.


-- 


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

[Bug fortran/37566] gfortran segfaults

[dennis at ausil dot us]

--- Comment #1 from dennis at ausil dot us  2008-09-17 20:32 ---
Created an attachment (id=16347)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16347&action=view)
config log 


-- 


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

[Bug fortran/37566] New: gfortran segfaults

[dennis at ausil dot us]

while trying to build gcc-4.3.2-3.srpm for sparc gfortran segfaults when
building for sparcv9

sparc64 builds ok 

if i try and build the conf test manually that fails i get 

[EMAIL PROTECTED] obj-sparc64-redhat-linux]$ cat conftest.f

  program foo
  real, parameter :: bar = sin (12.34 / 2.5)
  end program foo
[EMAIL PROTECTED] obj-sparc64-redhat-linux]$ gcc/gfortran conftest.f -o
conftest
gfortran: error trying to exec 'f951': execvp: No such file or directory


ill attach the config log also


-- 
   Summary: gfortran segfaults
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dennis at ausil dot us
 GCC build triplet: sparc64-redhat-linux
  GCC host triplet: sparc64-redhat-linux
GCC target triplet: sparc64-redhat-linux


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

[Bug middle-end/37565] __optimize__ attribute doesn't work correctly

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2008-09-17 20:26 ---
Then lets say it is a middle-end issue.  Still nowhere has you touched the C
front-end.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |middle-end


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

[Bug c/37565] __optimize__ attribute doesn't work correctly

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2008-09-17 20:24 ---
If the  __optimize__ attribute is handled properly, we
may be able to fold the __target__ attribute into the
__optimize__ attribute and all backends can support
function specific -mXXX options like

void foo (void) __attribute__
((__optimize__(2,"omit-frame-pointer,-mtune=core2")));


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Component|target  |c


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

[Bug target/37565] __optimize__ attribute doesn't work correctly

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-09-17 20:16 ---
(In reply to comment #3)
> (In reply to comment #1)
> > This is a target bug as the warning happens in the back-end.
> > 
> 
> But there is no chance for a backend to do anything about it.
> It can happen to any backends which check flag_XXX in
> OVERRIDE_OPTIONS.

But what does C front-end have to do it then?  Nothing.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |target


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

[Bug c/37565] __optimize__ attribute doesn't work correctly

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2008-09-17 20:13 ---
(In reply to comment #1)
> This is a target bug as the warning happens in the back-end.
> 

But there is no chance for a backend to do anything about it.
It can happen to any backends which check flag_XXX in
OVERRIDE_OPTIONS.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Component|target  |c


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

[Bug c/37565] __optimize__ attribute doesn't work correctly

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2008-09-17 20:07 ---
Here is one approach to add OVERRIDE_OPTIMIZATION_OPTIONS so
that a backend can have a chance to override optimization
options.

--- gcc/config/i386/i386.h.override 2008-09-11 16:48:39.0 -0700
+++ gcc/config/i386/i386.h  2008-09-17 13:02:45.0 -0700
@@ -482,6 +482,8 @@ enum calling_abi

 #define OVERRIDE_OPTIONS override_options (true)

+#define OVERRIDE_OPTIMIZATION_OPTIONS override_options (false)
+
 /* Define this to change the optimizations performed by default.  */
 #define OPTIMIZATION_OPTIONS(LEVEL, SIZE) \
   optimization_options ((LEVEL), (SIZE))
--- gcc/opts.c.override 2008-09-15 08:44:27.0 -0700
+++ gcc/opts.c  2008-09-17 13:00:58.0 -0700
@@ -1105,8 +1105,14 @@ decode_options (unsigned int argc, const
 }
 #endif

+#ifndef OVERRIDE_OPTIMIZATION_OPTIONS
+#define OVERRIDE_OPTIMIZATION_OPTIONS do { } while (0)
+#endif
+
   /* Save the current optimization options if this is the first call.  */
-  if (first_time_p)
+  if (!first_time_p)
+OVERRIDE_OPTIMIZATION_OPTIONS;
+  else
 {
   optimization_default_node = build_optimization_node ();
   optimization_current_node = optimization_default_node;


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Component|target  |c


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

[Bug target/37565] __optimize__ attribute doesn't work correctly

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-09-17 20:07 ---
This is a target bug as the warning happens in the back-end.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |target
 GCC target triplet||i?86-*-* x86_64-*-*


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

[Bug c/37565] New: __optimize__ attribute doesn't work correctly

[hjl dot tools at gmail dot com]

Many backends need to override optimization options after
we have processed all optimization options.  It is done
in OVERRIDE_OPTIONS. But it is only called once for a given
input. We do have OPTIMIZATION_OPTIONS, which is executed
when the optimization options are changed via "pragma GCC optimize"
or by using the "optimize" attribute. But OPTIMIZATION_OPTIONS
isn't enough. On Linux/x86-64, it gives

[EMAIL PROTECTED] gcc]$ cat /tmp/x.i
void foo (void) __attribute__ ((__optimize__(2,"omit-frame-pointer")));
void
foo (void)
{
}
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -S  /tmp/x.i -mno-accumulate-outgoing-args 
-fomit-frame-pointer
/tmp/x.i:1: warning: unwind tables currently require either a frame pointer or
-maccumulate-outgoing-args for correctness
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -S  /tmp/x.i -mno-accumulate-outgoing-args
[EMAIL PROTECTED] gcc]$ 

That means we may silently generate wrong codes. To properly support
"pragma GCC optimize" and the "optimize" attribute, we need a way for
a backend to override the optimization options whenever they are
changed.


-- 
   Summary: __optimize__  attribute doesn't work correctly
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
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=37565

[Bug libfortran/37564] collect2: ld returned 1 exit status make[3]: *** [libgfortran.la] Error 1

[brian at dessent dot net]

--- Comment #6 from brian at dessent dot net  2008-09-17 19:38 ---
Subject: Re:  collect2: ld returned 1 exit status make[3]: 
 *** [libgfortran.la] Error 1

Even worse, you may have to start over with a clean source tree.  See
pr32272 for an example of where a previous attempt at configuring in the
source directory caused later failures when properly building in a
separate directory.


-- 


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

[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |4.3.3


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

[Bug c++/22374] C++ front-end produces mis-match types in MODIFY_EXPR (dynamic_cast)

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-09-17 19:08 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/22374] C++ front-end produces mis-match types in MODIFY_EXPR (dynamic_cast)

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-09-17 19:08 ---
Subject: Bug 22374

Author: rguenth
Date: Wed Sep 17 19:07:27 2008
New Revision: 140427

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140427
Log:
2008-09-17  Richard Guenther  <[EMAIL PROTECTED]>

PR c++/22374
* rtti.c (build_dynamic_cast_1): Convert the COND_EXPR
result to the correct type.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/rtti.c


-- 


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

[Bug libfortran/37564] collect2: ld returned 1 exit status make[3]: *** [libgfortran.la] Error 1

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2008-09-17 19:08 ---
> Currently I run make from /home/rkraft/apps/gcc-4.3.1
>
> Here is my configure:
> 
> ./configure --prefix=/home/rkraft/apps/gcc4

Try:

cd /home/rkraft/apps/
mkdir gcc-4.3.1-build
cd gcc-4.3.1-build
../gcc-4.3.1/configure --prefix=/home/rkraft/apps/gcc4  \
--with-mpfr=/home/rkraft/apps/mpfr-2.3.2 --disable-multilib \
--enable-languages=fortran,c,c++ --with-gmp=/home/rkraft/apps/gmp-4.2.3 \
--with-gmp-lib=/home/rkraft/apps/gmp-4.2.3/lib \
--with-mpfr-lib=/home/rkraft/apps/mpfr-2.3.2/lib:

As Andrew already wrote: You should not build in the source directory but you
should build into another, empty directory like I did in the example above.


-- 


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

[Bug bootstrap/35619] [4.3/4.4 Regression] fixed includes not being found if building in src dir

[pinskia at gcc dot gnu dot org]

--- Comment #23 from pinskia at gcc dot gnu dot org  2008-09-17 19:07 
---
*** Bug 37564 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||reuben dot kraft at gmail
   ||dot com


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

[Bug libfortran/37564] collect2: ld returned 1 exit status make[3]: *** [libgfortran.la] Error 1

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-09-17 19:07 ---
Please read http://gcc.gnu.org/install/configure.html:
First, we highly recommend that GCC be built into a separate directory than the
sources which does not reside within the source tree. This is how we generally
build GCC; building where srcdir == objdir should still work, but doesn't get
extensive testing; building where objdir is a subdirectory of srcdir is
unsupported.




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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug inline-asm/37562] [4.2] -funroll-loops destroys inline asm code for powerpc

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2008-09-17 19:06 ---
You can also use __builtin_bswap32 in GCC 4.3 and above which gives you the
best code generation as it understands loading from memory and if the value is
in a register already.


-- 


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

[Bug libfortran/37564] collect2: ld returned 1 exit status make[3]: *** [libgfortran.la] Error 1

[reuben dot kraft at gmail dot com]

--- Comment #3 from reuben dot kraft at gmail dot com  2008-09-17 19:04 
---
Do you mean do not run "make" from gcc-4.3.1 ?  Or do mean do not set prefix to
gcc-4.3.1 ? 

Currently I run make from /home/rkraft/apps/gcc-4.3.1 and I set prefix to
/home/rkraft/apps/gcc4

Here is my configure:

./configure --prefix=/home/rkraft/apps/gcc4
--with-mpfr=/home/rkraft/apps/mpfr-2.3.2 --disable-multilib
--enable-languages=fortran,c,c++ --with-gmp=/home/rkraft/apps/gmp-4.2.3 
--with-gmp-lib=/home/rkraft/apps/gmp-4.2.3/lib
--with-mpfr-lib=/home/rkraft/apps/mpfr-2.3.2/lib:


-- 


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

[Bug inline-asm/37562] [4.2] -funroll-loops destroys inline asm code for powerpc

[rbuergel at web dot de]

--- Comment #5 from rbuergel at web dot de  2008-09-17 18:57 ---
Too bad for newbies to ppc asm. :)
But thank you for your explanations


-- 


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

[Bug libfortran/37564] collect2: ld returned 1 exit status make[3]: *** [libgfortran.la] Error 1

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-09-17 18:53 ---
Did you compile in the source directory?  If so, don't.  It is not well
supported and it is currently known to be broken for this same reason, see PR
35619.


-- 


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

[Bug inline-asm/37562] [4.2] -funroll-loops destroys inline asm code for powerpc

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-09-17 18:50 ---
From:
http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Machine-Constraints.html#Machine-Constraints

b
Address base register

Address base register is the standard saying rN or 0 (if r0 is used).  This is
just the way PPC asm works.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug inline-asm/37562] [4.2] -funroll-loops destroys inline asm code for powerpc

[rbuergel at web dot de]

--- Comment #3 from rbuergel at web dot de  2008-09-17 18:46 ---
> The second constraint should be using "b" instead of "r" as b says
> don't use r0.
Is this documented anywhere? The gcc manual says "r" means "any general purpose
register" and "b" means "Address base register". Any Documentation (for example
http://developer.apple.com/documentation/DeveloperTools/Reference/Assembler/PPCInstructions/chapter_6_section_2.html
) i've found, lists r0-r31 as general purpose registers.

Anyway, ignoring this point, you seem to be right. I remember 4.3.1 using r6
instead of r0, probably that's why it works. Unfortunately, i can't check your
suggestion until monday, when i'm back at work.


-- 


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

[Bug target/37394] [4.4 Regression] Segfault in ia64_variable_issue with -O -fschedule-insns2

[hjl dot tools at gmail dot com]

--- Comment #8 from hjl dot tools at gmail dot com  2008-09-17 18:06 ---
It may also impact PR 37283.


-- 


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

[Bug c++/37450] [4.4 Regression] C++ FE times out on duplicated parameter

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2008-09-17 17:59 ---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/37450] [4.4 Regression] C++ FE times out on duplicated parameter

[hjl at gcc dot gnu dot org]

--- Comment #3 from hjl at gcc dot gnu dot org  2008-09-17 17:58 ---
Subject: Bug 37450

Author: hjl
Date: Wed Sep 17 17:57:24 2008
New Revision: 140425

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140425
Log:
2008-09-17  H.J. Lu  <[EMAIL PROTECTED]>

PR c++/37450
* name-lookup.c (pushdecl_maybe_friend): Don't return the old
parameter for duplicate.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c


-- 


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

[Bug middle-end/37448] [4.3 Regression] gcc 4.3.1 cannot compile big function

[lucier at math dot purdue dot edu]

--- Comment #13 from lucier at math dot purdue dot edu  2008-09-17 17:49 
---
In the attached statistics file you find where this allocation overflowed

Alloc-pool KindPools  Allocated  PeakLeak
-
df_scan_ref pool 868 -1403330584  607042176  0

which is similar to what happens in 26854, so perhaps this PR could also be
improved with factored use-def chains.


-- 


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

[Bug testsuite/37561] [4.4 Regression] Revision 140405 caused g++.old-deja/g++.mike/warn1.C

[janis at gcc dot gnu dot org]

--- Comment #4 from janis at gcc dot gnu dot org  2008-09-17 17:38 ---
The same thing happens in C for the simplified testcase; z.c is a copy of z.C
from comment #3:

  elm3b149% /home/janis/tools/gcc-trunk-anonsvn/bin/gcc -c -m32 z.c
  z.c: In function ‘foo’:
  z.c:3: error: lvalue required as increment operand
  z.c: In function ‘bar’:
  z.c:4: warning: cast to pointer from integer of different size
  elm3b149% /home/janis/tools/gcc-trunk-anonsvn/bin/gcc -c -m64 z.c
  z.c: In function ‘foo’:
  z.c:3: error: lvalue required as increment operand
  z.c: In function ‘bar’:
  z.c:4: warning: cast to pointer from integer of different size


-- 


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

[Bug libstdc++/37547] [c++0x] minmax with initializer_list gives incorrect results

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2008-09-17 17:35 
---
Thanks for catching this early, apparently this is a fundamental issue with the
current proposal: having such overloads returning const refs to elements of the
initializer_list is a very bad idea, because the initializer_list goes away
upon function return. The important point here is that when the
initializer_list is build it contains a *copy* of v, not v itself, which thus
goes away when the initializer_list dies.

Let's fix the proposal... ;)


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-09-17 17:35:05
   date||


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

[Bug c++/37558] [4.4 regression] rev 140120 changes the accessibility of a friend decl.

[jason at gcc dot gnu dot org]

--- Comment #2 from jason at gcc dot gnu dot org  2008-09-17 17:31 ---
Fixed


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug testsuite/37561] [4.4 Regression] Revision 140405 caused g++.old-deja/g++.mike/warn1.C

[janis at gcc dot gnu dot org]

--- Comment #3 from janis at gcc dot gnu dot org  2008-09-17 17:02 ---
This is twisting my brain, but in this simplified testcase:

  __PTRDIFF_TYPE__ p;
  short q;
  void foo () { ((char *)p)++; }
  void bar () { ((char *)q)++; }

we get an error with both -m32 and-m64 for foo but not for bar:

  elm3b149% /home/janis/tools/gcc-trunk-anonsvn/bin/g++ -c -m32 z.C
  z.C: In function ‘void foo()’:
  z.C:3: error: lvalue required as increment operand
  elm3b149% /home/janis/tools/gcc-trunk-anonsvn/bin/g++ -c -m64 z.C
  z.C: In function ‘void foo()’:
  z.C:3: error: lvalue required as increment operand

although the expression "(char *)q" in bar is not an lvalue.  What am I
missing?


-- 


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

[Bug inline-asm/37562] [4.2] -funroll-loops destroys inline asm code for powerpc

[pinskia at gmail dot com]

--- Comment #2 from pinskia at gmail dot com  2008-09-17 16:52 ---
Subject: Re:   New: [4.2] -funroll-loops destroys inline asm code von powerpc



Sent from my iPhone

On Sep 17, 2008, at 8:42 AM, "rbuergel at web dot de" <[EMAIL PROTECTED] 
 > wrote:

> typedef unsigned int UInt32;
> typedef unsigned char UInt8;
>
> struct Data
> {
>  UInt8 data[16];
>
>  const UInt8* getData() const
>  {
>return data + 4;
>  }
> };
>
> struct Value {
>  UInt32 value;
>  static void update (Value& signal, const Data& source, UInt32  
> startBit);
> };
>
> void Value::update(Value& signal, const Data& source, UInt32  
> startByte)
> {
>  UInt32& value = signal.value;
>  const UInt8* data = source.getData();
>  asm( "lwbrx %0,%1,%2;\n":"=r"(value): "r"(data), "r"(startByte),  
> "m" (*(data
> + startByte)) );
> }

The second constraint should be using "b" instead of "r" as b says  
don't use r0.


>
>
> generated for gcc-4.2.4 on powerpc:
>  <_ZN5Value6updateERS_RK4Dataj>:
>   0:   38 04 00 04 addir0,r4,4
>   4:   7c 80 2c 2c lwbrx   r4,0,r5
>   8:   90 83 00 00 stw r4,0(r3)
>   c:   4e 80 00 20 blr
>
> the correct version without -funroll-loops reads:
>  <_ZN5Value6updateERS_RK4Dataj>:
>   0:   38 84 00 04 addir4,r4,4
>   4:   7c 84 2c 2c lwbrx   r4,r4,r5
>   8:   90 83 00 00 stw r4,0(r3)
>   c:   4e 80 00 20 blr
>
>
> lwbrx sums the contents of r4 and r5 and accesses this address,  
> swaps it's
> value and stores it again in r4. The incorrect version accesses an  
> invalid
> address, which leads to a segmentation fault.
>
> this is corrected at least with gcc-4.3.1, there i couldn't  
> reproduce the
> behaviour.
>
>
> -- 
>   Summary: [4.2] -funroll-loops destroys inline asm code von
>powerpc
>   Product: gcc
>   Version: 4.2.4
>Status: UNCONFIRMED
>  Severity: normal
>  Priority: P3
> Component: inline-asm
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: rbuergel at web dot de
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37562
>


-- 


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

Re: [Bug inline-asm/37562] New: [4.2] -funroll-loops destroys inline asm code von powerpc

[Andrew Thomas Pinski]

Sent from my iPhone

On Sep 17, 2008, at 8:42 AM, "rbuergel at web dot de" <[EMAIL PROTECTED] 
> wrote:



typedef unsigned int UInt32;
typedef unsigned char UInt8;

struct Data
{
 UInt8 data[16];

 const UInt8* getData() const
 {
   return data + 4;
 }
};

struct Value {
 UInt32 value;
 static void update (Value& signal, const Data& source, UInt32  
startBit);

};

void Value::update(Value& signal, const Data& source, UInt32  
startByte)

{
 UInt32& value = signal.value;
 const UInt8* data = source.getData();
 asm( "lwbrx %0,%1,%2;\n":"=r"(value): "r"(data), "r"(startByte),  
"m" (*(data

+ startByte)) );
}


The second constraint should be using "b" instead of "r" as b says  
don't use r0.






generated for gcc-4.2.4 on powerpc:
 <_ZN5Value6updateERS_RK4Dataj>:
  0:   38 04 00 04 addir0,r4,4
  4:   7c 80 2c 2c lwbrx   r4,0,r5
  8:   90 83 00 00 stw r4,0(r3)
  c:   4e 80 00 20 blr

the correct version without -funroll-loops reads:
 <_ZN5Value6updateERS_RK4Dataj>:
  0:   38 84 00 04 addir4,r4,4
  4:   7c 84 2c 2c lwbrx   r4,r4,r5
  8:   90 83 00 00 stw r4,0(r3)
  c:   4e 80 00 20 blr


lwbrx sums the contents of r4 and r5 and accesses this address,  
swaps it's
value and stores it again in r4. The incorrect version accesses an  
invalid

address, which leads to a segmentation fault.

this is corrected at least with gcc-4.3.1, there i couldn't  
reproduce the

behaviour.


--
  Summary: [4.2] -funroll-loops destroys inline asm code von
   powerpc
  Product: gcc
  Version: 4.2.4
   Status: UNCONFIRMED
 Severity: normal
 Priority: P3
Component: inline-asm
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: rbuergel at web dot de


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

[Bug c++/37558] [4.4 regression] rev 140120 changes the accessibility of a friend decl.

[jason at gcc dot gnu dot org]

--- Comment #1 from jason at gcc dot gnu dot org  2008-09-17 16:19 ---
This doesn't have anything to do with accessibility, but it is a new bug.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Priority|P3  |P1
   Last reconfirmed|-00-00 00:00:00 |2008-09-17 16:19:57
   date||
Summary|rev 140120 changes the  |[4.4 regression] rev 140120
   |accessibility of a friend   |changes the accessibility of
   |decl.   |a friend decl.


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

[Bug c++/37208] C++0x deleted functions and SFINAE

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2008-09-17 16:14 ---
Fixed.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/37544] [4.4 Regression] Conversion double -> unsigned long long -> unsigned -> double gives wrong results

[ubizjak at gmail dot com]

--- Comment #11 from ubizjak at gmail dot com  2008-09-17 16:13 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01221.html


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||09/msg01221.html
 Status|NEW |ASSIGNED
   Keywords||patch
   Last reconfirmed|2008-09-16 19:17:21 |2008-09-17 16:13:33
   date||
   Target Milestone|4.3.4   |4.2.5


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

[Bug c++/37302] function parameters are declared too late

[jason at gcc dot gnu dot org]

--- Comment #1 from jason at gcc dot gnu dot org  2008-09-17 16:13 ---
Fixed.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/37439] ICE using auto return-type in template function

[jason at gcc dot gnu dot org]

--- Comment #1 from jason at gcc dot gnu dot org  2008-09-17 16:12 ---
Fixed.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug testsuite/37561] [4.4 Regression] Revision 140405 caused g++.old-deja/g++.mike/warn1.C

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2008-09-17 16:11 ---
(In reply to comment #1)
> I tested with -m32 on powerpc64-linux, not with both -m32/-m64 which would 
> have
> caught this; I'll test with both for related patches.
> 
> The test previously used { dg-warning "" }, which matched any message from 
> that
> line.  The patch, in preparation to using new versions of dg-error and
> dg-warning that actually check for "warning" and "error", changed that to {
> dg-error "lvalue" }, which matches the error message for -m32 but not the
> warning message for -m64.  It's a bug in the compiler that the error isn't
> reported for -m64, and the change to the test merely detected that.
> 
> This should be a C++ bug, not a testsuite bug.
> 

I am not sure if it is a C++ bug. The differences between -m32
and -m64 are the sizes of __SIZE_TYPE__, int and pointer. Replace
int with long gives me
[EMAIL PROTECTED] tmp]$ cat x.cc 
typedef char * charptr;
typedef __SIZE_TYPE__ size_t;
char c[]={'A','B','C','D'};
long i=size_t(&c);
long *pp=&i;
void foo() { }
int main()
{
   charptr(*pp)++;// { dg-warning "" } 
return 0;
}
[EMAIL PROTECTED] tmp]$ gcc -Wall x.cc -S -m64 
x.cc: In function ‘int main()’:
x.cc:9: error: lvalue required as increment operand
[EMAIL PROTECTED] tmp]$ gcc -Wall x.cc -S -m32
x.cc: In function ‘int main()’:
x.cc:9: error: lvalue required as increment operand
[EMAIL PROTECTED] tmp]$ 


-- 


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

[Bug c++/37552] [4.4 regression] ICE with invalid array access

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-09-17 16:10 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/37552] [4.4 regression] ICE with invalid array access

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-09-17 16:08 ---
Subject: Bug 37552

Author: jakub
Date: Wed Sep 17 16:07:08 2008
New Revision: 140422

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140422
Log:
PR c++/37552
* typeck.c (build_array_ref): Use protected_set_expr_location instead
of SET_EXPR_LOCATION when ret might not be an expression.

* g++.dg/parse/crash49.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/parse/crash49.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug preprocessor/37324] [4.4 Regression] FAIL: gcc.dg/utf-array.c (test for errors)

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-09-17 16:07 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug preprocessor/37324] [4.4 Regression] FAIL: gcc.dg/utf-array.c (test for errors)

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-09-17 16:06 ---
Subject: Bug 37324

Author: jakub
Date: Wed Sep 17 16:05:11 2008
New Revision: 140421

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140421
Log:
PR preprocessor/37324
* lib/target-supports.exp
(check_effective_target_wchar_t_char16_t_compatible,
check_effective_target_wchar_t_char32_t_compatible): New.
* gcc.dg/utf-array.c: Use __CHAR{16,32}_TYPE__ macros in typedefs.
Only require from incompatible errors for char{16,32}_t vs. wchar_t
initializations if those types are indeed incompatible.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/utf-array.c
trunk/gcc/testsuite/lib/target-supports.exp


-- 


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

[Bug libfortran/37564] collect2: ld returned 1 exit status make[3]: *** [libgfortran.la] Error 1

[reuben dot kraft at gmail dot com]

--- Comment #1 from reuben dot kraft at gmail dot com  2008-09-17 16:04 
---
Created an attachment (id=16346)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16346&action=view)
x86_64-unknown-linux-gnu/libgfortran/config.log


-- 


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

[Bug libfortran/37564] New: collect2: ld returned 1 exit status make[3]: *** [libgfortran.la] Error 1

[reuben dot kraft at gmail dot com]

Hello,

>From the terminal, I many lines that look similar to:
.libs/in_unpack_generic.o(.text+0x820): In function `getline':
/usr/include/bits/stdio.h:103: multiple definition of `getline'
.libs/backtrace.o(.text+0xbc0):/usr/include/bits/stdio.h:103: first defined
here
.libs/in_unpack_generic.o(.text+0x830): In function `putchar_unlocked':
/usr/include/bits/stdio.h:94: multiple definition of `putchar_unlocked'
.libs/backtrace.o(.text+0xbd0):/usr/include/bits/stdio.h:94: first defined here
...
...
...


After that terminal output says:

collect2: ld returned 1 exit status
make[3]: *** [libgfortran.la] Error 1
make[3]: Leaving directory
`/home/rkraft/apps/gcc-4.3.1/x86_64-unknown-linux-gnu/libgfortran'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/home/rkraft/apps/gcc-4.3.1/x86_64-unknown-linux-gnu/libgfortran'
make[1]: *** [all-target-libgfortran] Error 2
make[1]: Leaving directory `/home/rkraft/apps/gcc-4.3.1'
make: *** [all] Error 2

I get this same error for gcc4.3.2 also.  What cause this and how do I fix it?
Configure log from x86_64-unknown-linux-gnu/libgfortran/ attached.

Thanks for your time.


-- 
   Summary: collect2: ld returned 1 exit status make[3]: ***
[libgfortran.la] Error 1
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reuben dot kraft at gmail dot com


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

[Bug c++/37563] [4.3/4.4 regression] Trouble calling qualified member function

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.3


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

[Bug c++/37563] New: [4.3/4.4 regression] Trouble calling qualified member function

[reichelt at gcc dot gnu dot org]

The following valid code snippet is rejected since GCC 4.3.0:

==
struct A {};

template struct Traits
{
  typedef void X;
};

template<> struct Traits<0>
{
  typedef A X;
};

template struct B
{
  typedef typename Traits::X Y;

  void foo(Y y)
  {
y.Y::A::~A();
  }
};
==

bug.cc: In member function 'void B::foo(typename Traits::X)':
bug.cc:19: error: 'void' is not a class type


-- 
   Summary: [4.3/4.4 regression] Trouble calling qualified member
function
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug testsuite/37561] [4.4 Regression] Revision 140405 caused g++.old-deja/g++.mike/warn1.C

[janis at gcc dot gnu dot org]

--- Comment #1 from janis at gcc dot gnu dot org  2008-09-17 16:00 ---
I tested with -m32 on powerpc64-linux, not with both -m32/-m64 which would have
caught this; I'll test with both for related patches.

The test previously used { dg-warning "" }, which matched any message from that
line.  The patch, in preparation to using new versions of dg-error and
dg-warning that actually check for "warning" and "error", changed that to {
dg-error "lvalue" }, which matches the error message for -m32 but not the
warning message for -m64.  It's a bug in the compiler that the error isn't
reported for -m64, and the change to the test merely detected that.

This should be a C++ bug, not a testsuite bug.


-- 


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

[Bug c/37560] bitfield not promoted to int

[joseph at codesourcery dot com]

--- Comment #3 from joseph at codesourcery dot com  2008-09-17 15:55 ---
Subject: Re:  bitfield not promoted to int

On Wed, 17 Sep 2008, clemens at ladisch dot de wrote:

> According to the proposed TC in DR 315 ("If an int can represent all values of
> the original type (as restricted by the width, for a bit-field), the type is
> converted to an int;"), 

That's part of the integer promotions, which are only applied in certain 
contexts (and the operand of sizeof is not one of those contexts).


-- 


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

[Bug inline-asm/37562] [4.2] -funroll-loops destroys inline asm code von powerpc

[rbuergel at web dot de]

--- Comment #1 from rbuergel at web dot de  2008-09-17 15:44 ---
oops, i forgot to mention my command line to compile it:
powerpc-linux-g++ -O3 -funroll-loops -c -o GetBytes2.o GetBytes2.cpp

using -O3 is important for reproducing this error


-- 


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

[Bug inline-asm/37562] New: [4.2] -funroll-loops destroys inline asm code von powerpc

[rbuergel at web dot de]

typedef unsigned int UInt32;
typedef unsigned char UInt8;

struct Data
{
  UInt8 data[16];

  const UInt8* getData() const
  {
return data + 4;
  }
};

struct Value {
  UInt32 value;
  static void update (Value& signal, const Data& source, UInt32 startBit);
};

void Value::update(Value& signal, const Data& source, UInt32 startByte)
{
  UInt32& value = signal.value;
  const UInt8* data = source.getData();
  asm( "lwbrx %0,%1,%2;\n":"=r"(value): "r"(data), "r"(startByte), "m" (*(data
+ startByte)) );
}

generated for gcc-4.2.4 on powerpc:
 <_ZN5Value6updateERS_RK4Dataj>:
   0:   38 04 00 04 addir0,r4,4
   4:   7c 80 2c 2c lwbrx   r4,0,r5
   8:   90 83 00 00 stw r4,0(r3)
   c:   4e 80 00 20 blr

the correct version without -funroll-loops reads:
 <_ZN5Value6updateERS_RK4Dataj>:
   0:   38 84 00 04 addir4,r4,4
   4:   7c 84 2c 2c lwbrx   r4,r4,r5
   8:   90 83 00 00 stw r4,0(r3)
   c:   4e 80 00 20 blr


lwbrx sums the contents of r4 and r5 and accesses this address, swaps it's
value and stores it again in r4. The incorrect version accesses an invalid
address, which leads to a segmentation fault.

this is corrected at least with gcc-4.3.1, there i couldn't reproduce the
behaviour.


-- 
   Summary: [4.2] -funroll-loops destroys inline asm code von
powerpc
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rbuergel at web dot de


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

[Bug tree-optimization/37508] [4.4 Regression] ICE in in simplify_truth_ops_using_ranges, at tree-vrp.c:6334

[rguenther at suse dot de]

--- Comment #8 from rguenther at suse dot de  2008-09-17 15:24 ---
Subject: Re:  [4.4 Regression] ICE in in
 simplify_truth_ops_using_ranges, at tree-vrp.c:6334

On Wed, 17 Sep 2008, bonzini at gnu dot org wrote:

> --- Comment #7 from bonzini at gnu dot org  2008-09-17 15:17 ---
> Do you have a missed optimization for optimizing the functions to "return 1"? 
> Or does your patch fix it too?

See PR37541.

Richard.


-- 


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

[Bug fortran/37536] [4.3/4.4 Regression] a mfcr is produced instead of branches for DO loops

[luisgpm at linux dot vnet dot ibm dot com]

--- Comment #9 from luisgpm at linux dot vnet dot ibm dot com  2008-09-17 
15:22 ---
Gathered some PPC 32/64 performance numbers with the patch (based on 140409).
No noticeable performance regressions were found. 32-bit swin and 64-bit art
had a little boost on speed (7.8% and 3.4% respectivelly).


-- 

luisgpm at linux dot vnet dot ibm dot com changed:

   What|Removed |Added

 CC||luisgpm at linux dot vnet
   ||dot ibm dot com


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

[Bug c++/37559] pow() function outputs NaN in debug build

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-09-17 15:19 ---
GCC 4.0.1 is no longer supported by the FSF.  Please update to at least GCC
4.2.4
and re-check if the problem is fixed.  You may also want to report to Apple
instead which is known to heavily modify their compilers.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug tree-optimization/37508] [4.4 Regression] ICE in in simplify_truth_ops_using_ranges, at tree-vrp.c:6334

[bonzini at gnu dot org]

--- Comment #7 from bonzini at gnu dot org  2008-09-17 15:17 ---
Do you have a missed optimization for optimizing the functions to "return 1"? 
Or does your patch fix it too?


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org


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

[Bug tree-optimization/37525] [4.4 Regression] IVOPTS difference causing 20% degradation in 173.applu benchmark

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-09-17 15:12 ---
I guess the problem might be that Fortran has signed size_type_node (and
unsigned
sizetype), so what the newly added code in int_fits_type_p does breaks Fortran
assumptions.  Say for sizetype -25 (i.e. unsigned value), when it is
force_fit_type_double into a signed type, it becomes signed -25, and given that
type_low_bound (of sizetype) is 0 and -25 is smaller than 0, int_fits_type_p
fails.
Perhaps just adding another TYPE_UNSIGNED (size_type_node) check to the if
would be sufficient.
That said, I still think such change isn't appropriate for 4.3 branch.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu dot org


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

[Bug c/37560] bitfield not promoted to int

[clemens at ladisch dot de]

--- Comment #2 from clemens at ladisch dot de  2008-09-17 15:11 ---
According to the proposed TC in DR 315 ("If an int can represent all values of
the original type (as restricted by the width, for a bit-field), the type is
converted to an int;"), 


-- 

clemens at ladisch dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/36343] [4.3 Regression] Wrong code due to bad TBAA pruning of points-to-sets and use in call clobbering

[rguenther at suse dot de]

--- Comment #8 from rguenther at suse dot de  2008-09-17 15:10 ---
Subject: Re:  [4.3 Regression] Wrong code due
 to bad TBAA pruning of points-to-sets and use in call clobbering

On Wed, 17 Sep 2008, ebotcazou at gcc dot gnu dot org wrote:

> --- Comment #7 from ebotcazou at gcc dot gnu dot org  2008-09-17 15:07 
> ---
> > This is the patch we use for openSUSE to fix this bug.
> 
> Any particular reason for not installing it at the FSF as well?

It disables optimizations and the testcase was artificially created by
me from looking at the source.  But let me just submit the patch
(again) and ask for feedback.

Richard.


-- 


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

[Bug tree-optimization/36343] [4.3 Regression] Wrong code due to bad TBAA pruning of points-to-sets and use in call clobbering

[ebotcazou at gcc dot gnu dot org]

--- Comment #7 from ebotcazou at gcc dot gnu dot org  2008-09-17 15:07 
---
> This is the patch we use for openSUSE to fix this bug.

Any particular reason for not installing it at the FSF as well?


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org


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

[Bug middle-end/18071] [4.2/4.3/4.4 Regression] -Winline does not respect -fno-default-inline

[hubicka at gcc dot gnu dot org]

--- Comment #37 from hubicka at gcc dot gnu dot org  2008-09-17 15:02 
---
Subject: Bug 18071

Author: hubicka
Date: Wed Sep 17 15:00:59 2008
New Revision: 140418

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140418
Log:
PR c++/18071
* tree.h (DECL_INLINE): remove.
(DECL_DECLARED_INLINE_P): Update docs.
(DECL_NO_INLINE_WARNING_P): new.
(tree_function_decl): Replace inline_flag by no_inline_warning_flag.
* tree-inline.c (inlinable_function_p): Set DECL_NO_INLINE_WARNING_P.

Java:
* class.c (add_method_1): Do not initialize DECL_INLINE.
(make_local_function_alias): Likewise.
* expr.c (rewrite_arglist_getcaller): Set DECL_UNINLINABLE.
* lang.c (java_decl_ok_for_sibcall): Use DECL_UNINLINABLE.

Objc:
* objc/objc-act.c (objc_finish_method_definition): Do not set
DECL_INLINE.

C++:
* cp/decl.c (start_method): Set DECL_NO_INLINE_WARNING_P.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/java/ChangeLog
trunk/gcc/java/class.c
trunk/gcc/java/expr.c
trunk/gcc/java/lang.c
trunk/gcc/objc/ChangeLog
trunk/gcc/objc/objc-act.c
trunk/gcc/tree-inline.c
trunk/gcc/tree.h


-- 


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

[Bug c/37560] bitfield not promoted to int

[joseph at codesourcery dot com]

--- Comment #1 from joseph at codesourcery dot com  2008-09-17 14:50 ---
Subject: Re:   New: bitfield not promoted to int

On Wed, 17 Sep 2008, clemens at ladisch dot de wrote:

> In the following program, the type of the assignment expression "f.x = 1"
> should be int, according to the integer promotion rules.
> However, gcc 4.xx (on all architectures I've tested) prints "1".

Why do you think the type should be int instead of int:1?  The conclusion 
from C90 DRs was that bit-fields have their own types, and from C99 DRs 
was to leave whether they have their own types implementation-defined, and 
GCC follows the C90 DRs and so the assignment has type int:1 and is not 
promoted as an operand of sizeof.

Now, for C++ you have a valid bug report, since there bit-fields do not 
have their own types, and the reported behavior appears for C++ as well.


-- 


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

[Bug testsuite/37561] New: [4.4 Regression] Revision 140405 caused g++.old-deja/g++.mike/warn1.C

[hjl dot tools at gmail dot com]

bash-3.2$ cat g++.old-deja/g++.mike/warn1.C
// { dg-do assemble  }
// { dg-options "-Wall" }

typedef char * charptr;
typedef __SIZE_TYPE__ size_t;
char c[]={'A','B','C','D'};
int i=size_t(&c);
int *pp=&i;
void foo() { }
int main()
{
 charptr(*pp)++;// { dg-warning "" } 
 return 0;
}
bash-3.2$ gcc -Wall -S -o /tmp/x.s g++.old-deja/g++.mike/warn1.C -m64
g++.old-deja/g++.mike/warn1.C: In function ‘int main()’:
g++.old-deja/g++.mike/warn1.C:12: warning: value computed is not used
bash-3.2$ gcc -Wall -S -o /tmp/x.s g++.old-deja/g++.mike/warn1.C -m32
g++.old-deja/g++.mike/warn1.C: In function ‘int main()’:
g++.old-deja/g++.mike/warn1.C:12: error: lvalue required as increment operand
bash-3.2$ 

On Linux/x86-64, I got

FAIL: g++.old-deja/g++.mike/warn1.C  (test for errors, line 12)
FAIL: g++.old-deja/g++.mike/warn1.C (test for excess errors)


-- 
   Summary: [4.4 Regression] Revision 140405 caused g++.old-
deja/g++.mike/warn1.C
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
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=37561

[Bug tree-optimization/37102] [4.3/4.4 Regression] out-of-SSA is broken

[amacleod at redhat dot com]

--- Comment #16 from amacleod at redhat dot com  2008-09-17 14:48 ---
Created an attachment (id=16345)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16345&action=view)
Potential patch #2

This is the other option, eliminate dead PHIs.  compiling all of GCC .c files
at -O3, it finds a total of 12 instances of dead phis, and 3 of those were
"extra" ones made dead by elimination of the original dead PHI.


This patch has not yet been bootstrapped and fully tested, its ongoing now.


-- 


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

[Bug tree-optimization/36343] [4.3 Regression] Wrong code due to bad TBAA pruning of points-to-sets and use in call clobbering

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-09-17 14:46 ---
Created an attachment (id=16344)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16344&action=view)
patch disabling TBAA pruning

This is the patch we use for openSUSE to fix this bug.


-- 


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

[Bug c++/37260] [4.1/4.2/4.3 Regression] infinite loop in init

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug tree-optimization/37102] [4.3/4.4 Regression] out-of-SSA is broken

[amacleod at redhat dot com]

--- Comment #15 from amacleod at redhat dot com  2008-09-17 14:39 ---
Created an attachment (id=16343)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16343&action=view)
potential patch 1

This is the first option which simply doesn't add the result of a PHI with no
uses to the partition map.  It passes bootstrap and all tests on
x86_64-unknown-linux-gnu with no regressions.


-- 

amacleod at redhat dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |amacleod at redhat dot com
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug tree-optimization/37102] [4.3/4.4 Regression] out-of-SSA is broken

[rguenth at gcc dot gnu dot org]

--- Comment #14 from rguenth at gcc dot gnu dot org  2008-09-17 14:38 
---
Hm, it doesn't work - bootstrap fails as gengtype segfaults.


-- 


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

[Bug tree-optimization/37310] [4.3 Regression] gfortran errors in compilation and the making for upgraded compilers

[rguenth at gcc dot gnu dot org]

--- Comment #17 from rguenth at gcc dot gnu dot org  2008-09-17 14:34 
---
I think this is a duplicate of PR36747 as I no longer can reporduce this with
4.3.2.

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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to fail|4.2.0   |4.2.0 4.3.1
  Known to work|4.4.0   |4.4.0 4.3.2
 Resolution||DUPLICATE


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

[Bug middle-end/36747] ICE in set_uids_in_ptset, at tree-ssa-structalias.c:4785 with -O

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-09-17 14:34 ---
*** Bug 37310 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||petermorgan at grapevine dot
   ||net dot au


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

[Bug tree-optimization/37102] [4.3/4.4 Regression] out-of-SSA is broken

[amacleod at redhat dot com]

--- Comment #13 from amacleod at redhat dot com  2008-09-17 14:34 ---
I was in the middle of updating this PR and taking possesion :-)

Upon further reflection, I don't think it is acceptable for out-of-ssa to
generate incorrect code simply because an optimization wasn't run before it.

So, there are 2 basic choices. ONnis as you state, only there is an additional
bit required during the rewrite verification.  

The other option is a very mini dead phi removal done at the same time as
virtual phis are eliminated. its only a few lines of code and simple removes
PHIs with no uses, and takes care of the ripple effect as well. I have a patch
for it as well, its just not completely tested yet.

I'll attach both in a minute, I just wanted you to know I was looking at it :-)


-- 


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