[Bug rtl-optimization/41033] RTL alias-oracle does not honor -fno-strict-aliasing

[abel at gcc dot gnu dot org]

--- Comment #1 from abel at gcc dot gnu dot org  2009-08-12 07:40 ---
Confirmed on trunk.  As we discussed on IRC, the below obvious patch makes
nonoverlapping_component_refs_p punt when !flag_strict_aliasing and thus fixes
the testcase.  I have looked at the other rtl alias oracle functions used in
*_dependence, and it seems that they are safe.  E.g.,
fixed_scalar_and_varying_struct_p already punts when fno-strict-aliasing, and
the other stuff mainly deals with base+offset disambiguations.

(Interestingly enough, I couldn't make a test case in which incorrect PRE or
CSE (not DSE) would happen, as these probably don't look through stores.  On
some platforms though, the scheduler will likely fail.)

I will post the patch after bootstrap+regtest. 


Index: alias.c
===
*** alias.c (revision 150675)
--- alias.c (working copy)
*** nonoverlapping_component_refs_p (const_t
*** 1980,1985 
--- 1980,1988 
  {
const_tree fieldx, fieldy, typex, typey, orig_y;

+   if (!flag_strict_aliasing)
+ return false;
+
do
  {
/* The comparison has to be done at a common type, since we don't


-- 

abel at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||abel at gcc dot gnu dot org
 AssignedTo|unassigned at gcc dot gnu   |abel at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-12 07:40:55
   date||


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

[Bug fortran/41034] [4.5 Regression] Wrongly rejected proc pointer assignment with CDECL (compiler-directive_1.f90)

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2009-08-12 08:06 ---
If one looks at the failing test case one finds:

  !gcc$ attributes cdecl :: cdecl
  !gcc$ attributes stdcall :: stdcall
  procedure(), pointer :: ptr
  procedure(), pointer :: cdecl
  procedure(), pointer :: stdcall
  procedure(), pointer :: fastcall
  !gcc$ attributes fastcall :: fastcall

Only the cdecl and stdcall are failing, i.e. those where the attributes cdecl
comes _before_ the PROCEDURE statement.

The problem seems to be gfc_copy_attr:
  dest->ext_attr = src->ext_attr
The issue is that "dest" is alreay set correctly while "src" has the bit
pattern "0". Patch is now regtesting.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |burnus at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-12 08:06:38
   date||


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

[Bug fortran/40940] [F03] CLASS statement

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2009-08-12 08:42 ---
r150620 implements simple parsing and resolution of CLASS statements, without
actual polymorphism. Some things missing for full polymorphism:

 * CLASS(*)
 * SELECT_TYPE
 * EXTENDS_TYPE_OF
 * SAME_TYPE_AS


-- 


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

[Bug ada/41040] New: -fwide-exec-charset defaults to UCS-4/UCS-2, not UTF-32/UTF-16

[samuel dot thibault at ens-lyon dot org]

Hello,  the manual page says `Set the wide execution character set, used for
wide string and character constants.  The default is UTF-32 or UTF-16,
whichever corresponds to the width of "wchar_t".'  This should read UCS-4 or
UCS-2 instead. See attached program behavior when compiled without
-fwide-exec-charset and with -fwide-exec-charset=UTF-32 , UTF-16, UCS-4 or
UCS-2. Attached patch fixes it.  Samuel


-- 
   Summary: -fwide-exec-charset defaults to UCS-4/UCS-2, not UTF-
32/UTF-16
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: samuel dot thibault at ens-lyon dot org


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

[Bug ada/41041] New: -fwide-exec-charset defaults to UCS-4/UCS-2, not UTF-32/UTF-16

[samuel dot thibault at ens-lyon dot org]

Hello,  the manual page says `Set the wide execution character set, used for
wide string and character constants.  The default is UTF-32 or UTF-16,
whichever corresponds to the width of "wchar_t".'  This should read UCS-4 or
UCS-2 instead. See attached program behavior when compiled without
-fwide-exec-charset and with -fwide-exec-charset=UTF-32 , UTF-16, UCS-4 or
UCS-2. Attached patch fixes it.  Samuel


-- 
   Summary: -fwide-exec-charset defaults to UCS-4/UCS-2, not UTF-
32/UTF-16
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: samuel dot thibault at ens-lyon dot org


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

[Bug ada/41041] -fwide-exec-charset defaults to UCS-4/UCS-2, not UTF-32/UTF-16

[samuel dot thibault at ens-lyon dot org]

--- Comment #1 from samuel dot thibault at ens-lyon dot org  2009-08-12 
08:45 ---
Created an attachment (id=18342)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18342&action=view)
testcase


-- 


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

[Bug ada/41041] -fwide-exec-charset defaults to UCS-4/UCS-2, not UTF-32/UTF-16

[samuel dot thibault at ens-lyon dot org]

--- Comment #2 from samuel dot thibault at ens-lyon dot org  2009-08-12 
08:45 ---
Created an attachment (id=18343)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18343&action=view)
fix


-- 


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

[Bug ada/41042] New: -fwide-exec-charset defaults to UCS-4/UCS-2, not UTF-32/UTF-16

[samuel dot thibault at ens-lyon dot org]

Hello,  the manual page says `Set the wide execution character set, used for
wide string and character constants.  The default is UTF-32 or UTF-16,
whichever corresponds to the width of "wchar_t".'  This should read UCS-4 or
UCS-2 instead. See attached program behavior when compiled without
-fwide-exec-charset and with -fwide-exec-charset=UTF-32 , UTF-16, UCS-4 or
UCS-2. Attached patch fixes it.  Samuel


-- 
   Summary: -fwide-exec-charset defaults to UCS-4/UCS-2, not UTF-
32/UTF-16
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: samuel dot thibault at ens-lyon dot org


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

[Bug ada/41042] -fwide-exec-charset defaults to UCS-4/UCS-2, not UTF-32/UTF-16

[samuel dot thibault at ens-lyon dot org]

--- Comment #1 from samuel dot thibault at ens-lyon dot org  2009-08-12 
08:46 ---


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


-- 

samuel dot thibault at ens-lyon dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug ada/41041] -fwide-exec-charset defaults to UCS-4/UCS-2, not UTF-32/UTF-16

[samuel dot thibault at ens-lyon dot org]

--- Comment #3 from samuel dot thibault at ens-lyon dot org  2009-08-12 
08:46 ---
*** Bug 41042 has been marked as a duplicate of this bug. ***


-- 


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

[Bug libstdc++/41005] [C++0x] Unable to link fstream open and ctor with std::string argument.

[jwakely dot gcc at gmail dot com]

--- Comment #8 from jwakely dot gcc at gmail dot com  2009-08-12 08:55 
---
Created an attachment (id=18344)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18344&action=view)
compile fstream-inst.cc as c++0x to instantiate new members

i'm testing this patch


-- 


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

[Bug libstdc++/41005] [C++0x] Unable to link fstream open and ctor with std::string argument.

[redi at gcc dot gnu dot org]

-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |redi at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-08-10 15:09:05 |2009-08-12 08:57:39
   date||


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

[Bug debug/40990] bad .debug_pubnames entry from gcj

[dodji at gcc dot gnu dot org]

--- Comment #2 from dodji at gcc dot gnu dot org  2009-08-12 09:02 ---
Subject: Bug 40990

Author: dodji
Date: Wed Aug 12 09:02:17 2009
New Revision: 150677

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150677
Log:
Fix PR debug/40990

PR debug/40990
* lang.c (put_decl_node): Outputs different level of information
depending on the verbosity level.

Modified:
branches/gcc-4_4-branch/gcc/java/ChangeLog
branches/gcc-4_4-branch/gcc/java/lang.c


-- 


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

[Bug fortran/41034] [4.5 Regression] Wrongly rejected proc pointer assignment with CDECL (compiler-directive_1.f90)

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2009-08-12 09:04 ---
Subject: Bug 41034

Author: burnus
Date: Wed Aug 12 09:03:38 2009
New Revision: 150678

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

PR fortran/41034
* symbol.c (gfc_copy_attr): Merge bits instead of replace
bits in gfc_copy_attr.
* gfc_check_pointer_assign (gfc_check_pointer_assign):
Initialize ext_attr bits by zero.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/symbol.c


-- 


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

[Bug debug/40990] bad .debug_pubnames entry from gcj

[dodji at gcc dot gnu dot org]

--- Comment #3 from dodji at gcc dot gnu dot org  2009-08-12 09:06 ---
Fixed in 4.4 and 4.5


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/41034] [4.5 Regression] Wrongly rejected proc pointer assignment with CDECL (compiler-directive_1.f90)

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2009-08-12 09:07 ---
FIXED on the trunk (4.5)


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/41031] [4.5 Regression] ICE in insert_value_copy_on_edge preventing bootstrap on sparc64 and s390x, testcase on cris-elf

[laurent at guerby dot net]

--- Comment #5 from laurent at guerby dot net  2009-08-12 09:09 ---
Same happens on sparc64 in 64 bits bootstrap in all-stage2-libiberty:

/home/guerby/build/./prev-gcc/xgcc -B/home/guerby/build/./prev-gcc/
-B/n/62/guerby/install-trunk-64/sparc64-unknown-linux-gnu/bin/
-B/n/62/guerby/install-trunk-64/sparc64-unknown-linux-gnu/bin/ -B/n/62/guer\
by/install-trunk-64/sparc64-unknown-linux-gnu/lib/ -isystem
/n/62/guerby/install-trunk-64/sparc64-unknown-linux-gnu/include -isystem
/n/62/guerby/install-trunk-64/sparc64-unknown-linux-gnu/sys-include-c\
 -DHAVE_CONFIG_H -g -O2  -I. -I../../trunk/libiberty/../include  -W -Wall
-Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic 
../../trunk/libiberty/regex.c -o regex.o
In file included from ../../trunk/libiberty/regex.c:638:0:
../../trunk/libiberty/regex.c: In function 'byte_re_match_2_internal':
../../trunk/libiberty/regex.c:7476:5: warning: jump skips variable
initialization
../../trunk/libiberty/regex.c:5952:12: note: label 'restore_best_regs' defined
here
../../trunk/libiberty/regex.c:5913:16: note: 'same_str_p' declared here
../../trunk/libiberty/regex.c:5543:1: internal compiler error: in
insert_value_copy_on_edge, at tree-outof-ssa.c:223

According to my logs revision range is:

150589 ok
150648 ko


-- 

laurent at guerby dot net changed:

   What|Removed |Added

  Component|tree-optimization   |bootstrap
   GCC host triplet|x86_64-unknown-linux-gnu|
 GCC target triplet|cris-axis-elf   |
   Priority|P3  |P1
Summary|[4.5 Regression]: build |[4.5 Regression] ICE in
   |breakage for cris-elf   |insert_value_copy_on_edge
   |building newlib, ICE in |preventing bootstrap on
   |insert_value_copy_on_edge   |sparc64 and s390x, testcase
   ||on cris-elf


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

[Bug bootstrap/41031] [4.5 Regression] ICE in insert_value_copy_on_edge preventing bootstrap on sparc64 and s390x, testcase on cris-elf

[laurent at guerby dot net]

--- Comment #6 from laurent at guerby dot net  2009-08-12 09:13 ---
>From just reading the ChangeLog, a likely candidate:

2009-08-09  Richard Sandiford  

   * tree-out-of-ssa.c (insert_value_copy_on_edge): If the source
   and destination have different modes, Use promote_mode to
   determine the signedness of the conversion.  Assert that the
   promoted source mode matches the destination mode.  Don't pass
   the destination and destination mode to expand_expr if the source
   mode is different.  Simplify conversion logic.

--- gcc/tree-outof-ssa.c(revision 150589)
+++ gcc/tree-outof-ssa.c(revision 150648)
@@ -195,7 +195,9 @@
 insert_value_copy_on_edge (edge e, int dest, tree src, source_location locus)
 {
   rtx seq, x;
-  enum machine_mode mode;
+  enum machine_mode dest_mode, src_mode;
+  int unsignedp;
+
   if (dump_file && (dump_flags & TDF_DETAILS))
 {
   fprintf (dump_file,
@@ -214,14 +216,21 @@
 set_curr_insn_source_location (locus);

   start_sequence ();
-  mode = GET_MODE (SA.partition_to_pseudo[dest]);
-  x = expand_expr (src, SA.partition_to_pseudo[dest], mode, EXPAND_NORMAL);
-  if (GET_MODE (x) != VOIDmode && GET_MODE (x) != mode)
-x = convert_to_mode (mode, x, TYPE_UNSIGNED (TREE_TYPE (src)));
-  if (CONSTANT_P (x) && GET_MODE (x) == VOIDmode
-  && mode != TYPE_MODE (TREE_TYPE (src)))
-x = convert_modes (mode, TYPE_MODE (TREE_TYPE (src)),
- x, TYPE_UNSIGNED (TREE_TYPE (src)));
+
+  src_mode = TYPE_MODE (TREE_TYPE (src));
+  unsignedp = TYPE_UNSIGNED (TREE_TYPE (src));
+  dest_mode = promote_mode (TREE_TYPE (src), src_mode, &unsignedp);
+  gcc_assert (dest_mode == GET_MODE (SA.partition_to_pseudo[dest]));
+
+  if (src_mode != dest_mode)
+{
+  x = expand_expr (src, NULL, src_mode, EXPAND_NORMAL);
+  x = convert_modes (dest_mode, src_mode, x, unsignedp);
+}
+  else
+x = expand_expr (src, SA.partition_to_pseudo[dest],
+dest_mode, EXPAND_NORMAL);
+
   if (x != SA.partition_to_pseudo[dest])
 emit_move_insn (SA.partition_to_pseudo[dest], x);
   seq = get_insns ();


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net,
   ||rdsandiford at googlemail
   ||dot com


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

[Bug bootstrap/41031] [4.5 Regression] ICE in insert_value_copy_on_edge preventing bootstrap on sparc64 and s390x, testcase on cris-elf

[laurent at guerby dot net]

--- Comment #7 from laurent at guerby dot net  2009-08-12 09:15 ---
There's a patch.


-- 

laurent at guerby dot net changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||08/msg00615.html


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

[Bug c++/41039] Member reordering rule is overly strict

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-08-12 09:28 ---
Use -fpermissive.


-- 


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

[Bug c++/41039] Member reordering rule is overly strict

[jwakely dot gcc at gmail dot com]

--- Comment #4 from jwakely dot gcc at gmail dot com  2009-08-12 09:41 
---
I think maybe the second example is rejected because of 2) not 3)

2) A name N used in a class S shall refer to the same declaration in its
context and when re-evaluated in the
completed scope of S. No diagnostic is required for a violation of this rule.

'foo' is used in the class, but in the completed scope which includes the
function body of S::foo() 'foo' refers to the member function.

If you don't want to use -fpermissive you can convince gcc to compile it by
referring to the type as '::foo' because in that case the name always refers to
the global type even in the completed scope.

struct foo { };
struct bar {
  ::foo foo();
};


-- 


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

[Bug c++/41038] [4.4/4.5 regression] Parsing error related to qualified name id

[redi at gcc dot gnu dot org]

--- Comment #1 from redi at gcc dot gnu dot org  2009-08-12 09:55 ---
reduced:

struct S
{
int size() const;
};

template
struct Packer
{
int foo() {
return  Packer::var.size();
}
const S& var;
};


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.4.1 4.5.0
  Known to work||4.3.4
Summary|Parsing error related to|[4.4/4.5 regression] Parsing
   |qualified name id   |error related to qualified
   ||name id


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

[Bug bootstrap/41031] [4.5 Regression] ICE in insert_value_copy_on_edge preventing bootstrap on sparc64 and s390x, testcase on cris-elf

[hp at gcc dot gnu dot org]

--- Comment #8 from hp at gcc dot gnu dot org  2009-08-12 10:30 ---
(In reply to comment #6)
> From just reading the ChangeLog, a likely candidate:

That's already established by the revision range in the description. :)
The patch is already approved, so I'm going to commit it on behalf of rsandifo.


-- 


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

[Bug bootstrap/41031] [4.5 Regression] ICE in insert_value_copy_on_edge preventing bootstrap on sparc64 and s390x, testcase on cris-elf

[hp at gcc dot gnu dot org]

--- Comment #9 from hp at gcc dot gnu dot org  2009-08-12 10:34 ---
(In reply to comment #8)
> The patch is already approved, so I'm going to commit it on behalf of 
> rsandifo.

Oops, I see it's not completely tested yet.
Ok, I'm doing a test-run on cris-elf first.
(If someone knows it's already sufficiently tested somewhere, please do the
honors.)


-- 


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

[Bug rtl-optimization/41033] RTL alias-oracle does not honor -fno-strict-aliasing

[abel at gcc dot gnu dot org]

--- Comment #2 from abel at gcc dot gnu dot org  2009-08-12 11:50 ---
Subject: Bug 41033

Author: abel
Date: Wed Aug 12 11:50:22 2009
New Revision: 150680

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150680
Log:
2009-08-12  Andrey Belevantsev  

PR rtl-optimization/41033
* alias.c (nonoverlapping_component_refs_p): Punt if strict aliasing is
disabled.

2009-08-12  Richard Guenther  

PR rtl-optimization/41033
* gcc.dg/pr41033.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr41033.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/alias.c
trunk/gcc/testsuite/ChangeLog


-- 


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

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

[ami_stuff at o2 dot pl]

--- Comment #2 from ami_stuff at o2 dot pl  2009-08-12 12:09 ---
The same problem happens with GCC 4.4.1.


-- 


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

[Bug tree-optimization/41019] Variate_generator with mt19937 and normal_distribution produces wrong sequence for "-O3".

[irar at il dot ibm dot com]

--- Comment #6 from irar at il dot ibm dot com  2009-08-12 12:14 ---
Looks like a problem in data-ref analysis:

Creating dr for this_6(D)->_M_x[__k_87]
...
base_address: this_6(D)
offset from base address: 0
constant offset from base address: 0
step: 8
aligned to: 128
base_object: this_6(D)->_M_x[0]

And the vectorizer creates accesses relatively to this_6(D) (base_address
above) with zero offset (instead of this_6(D)->_M_x[0] or with an offset of
_M_x).

Ira


-- 


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

[Bug fortran/41043] New: [4.4/4.5 Regression] virtual memory exhausted: Cannot allocate memory

[dominiq at lps dot ens dot fr]

On *-apple-darwin9 with gfortran 4.5.0 or 4.4.1, the following code gives at
-O2:

! { dg-do compile }
subroutine foo
  implicit none

  integer :: i

  call gee_i(int(i**huge(0_8),kind=kind(i)))
!  call gee_i(int(i**(-huge(0_8)-1_8),kind=kind(i)))

end subroutine foo

gives at -O2:

[ibook-dhum] f90/bug% time gfc -O2 integer_exponentiation_2_db_red.f90
virtual memory exhausted: Cannot allocate memory
28.270u 4.114s 1:27.92 36.8%0+0k 0+11io 282pf+0w

The code compiles with values other than huge(0_8) or with gfortran 4.3.


-- 
   Summary: [4.4/4.5 Regression] virtual memory exhausted: Cannot
allocate memory
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: *-apple-darwin9
  GCC host triplet: *-apple-darwin9
GCC target triplet: *-apple-darwin9


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

[Bug tree-optimization/41019] Variate_generator with mt19937 and normal_distribution produces wrong sequence for "-O3".

[rguenther at suse dot de]

--- Comment #7 from rguenther at suse dot de  2009-08-12 12:37 ---
Subject: Re:  Variate_generator with mt19937
 and normal_distribution produces wrong sequence for "-O3".

On Wed, 12 Aug 2009, irar at il dot ibm dot com wrote:

> --- Comment #6 from irar at il dot ibm dot com  2009-08-12 12:14 ---
> Looks like a problem in data-ref analysis:
> 
> Creating dr for this_6(D)->_M_x[__k_87]
> ...
> base_address: this_6(D)
> offset from base address: 0
> constant offset from base address: 0
> step: 8
> aligned to: 128
> base_object: this_6(D)->_M_x[0]
> 
> And the vectorizer creates accesses relatively to this_6(D) (base_address
> above) with zero offset (instead of this_6(D)->_M_x[0] or with an offset of
> _M_x).

Oh.  Did you manage to reduce or reproduce with a smaller testcase?

Thanks,
Richard.


-- 


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

[Bug fortran/41043] [4.4/4.5 Regression] virtual memory exhausted: Cannot allocate memory

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-08-12 13:14 ---
Confirmed.  We are doing a very hard job folding a tree generating lots of
garbage during VRP in adjust_range_with_scev (my personal friend).

:
D.1534_2 = (integer(kind=8)) i_1(D);
D.1535_3 = D.1534_2 * D.1534_2;
D.1536_4 = D.1534_2 * D.1535_3;
D.1537_5 = D.1536_4 * D.1536_4;
D.1538_6 = D.1536_4 * D.1537_5;
D.1539_7 = D.1538_6 * D.1538_6;
D.1540_8 = D.1538_6 * D.1539_7;
D.1541_9 = D.1539_7 * D.1539_7;
D.1542_10 = D.1540_8 * D.1541_9;
D.1543_11 = D.1542_10 * D.1542_10;
D.1544_12 = D.1543_11 * D.1543_11;
D.1545_13 = D.1544_12 * D.1544_12;
D.1546_14 = D.1535_3 * D.1535_3;
D.1547_15 = D.1536_4 * D.1546_14;
D.1548_16 = D.1545_13 * D.1547_15;
D.1549_17 = D.1548_16 * D.1548_16;
D.1550_18 = D.1549_17 * D.1549_17;
D.1551_19 = D.1550_18 * D.1550_18;
D.1552_20 = D.1551_19 * D.1547_15;
D.1553_21 = D.1552_20 * D.1552_20;
D.1554_22 = D.1553_21 * D.1553_21;
D.1555_23 = D.1554_22 * D.1554_22;
D.1556_24 = D.1555_23 * D.1547_15;
D.1557_25 = D.1556_24 * D.1556_24;
D.1558_26 = D.1557_25 * D.1557_25;
D.1559_27 = D.1558_26 * D.1558_26;
D.1560_28 = D.1559_27 * D.1547_15;
D.1561_29 = D.1560_28 * D.1560_28;
D.1562_30 = D.1561_29 * D.1561_29;
D.1563_31 = D.1562_30 * D.1562_30;
D.1564_32 = D.1563_31 * D.1547_15;
D.1565_33 = D.1564_32 * D.1564_32;
D.1566_34 = D.1565_33 * D.1565_33;
D.1567_35 = D.1566_34 * D.1566_34;
D.1568_36 = D.1567_35 * D.1547_15;
D.1569_37 = D.1568_36 * D.1568_36;
D.1570_38 = D.1569_37 * D.1569_37;
D.1571_39 = D.1570_38 * D.1570_38;
D.1572_40 = D.1571_39 * D.1547_15;
D.1573_41 = D.1572_40 * D.1572_40;
D.1574_42 = D.1573_41 * D.1573_41;
D.1575_43 = D.1574_42 * D.1574_42;
D.1576_44 = D.1575_43 * D.1547_15;
D.1577_45 = D.1576_44 * D.1576_44;
D.1578_46 = D.1577_45 * D.1577_45;
D.1579_47 = D.1578_46 * D.1578_46;
D.1580_48 = D.1579_47 * D.1547_15;
D.1581_49 = D.1580_48 * D.1580_48;
D.1582_50 = D.1581_49 * D.1581_49;
D.1583_51 = D.1582_50 * D.1582_50;
D.1584_52 = D.1583_51 * D.1547_15;
D.1585_53 = D.1584_52 * D.1584_52;
D.1586_54 = D.1585_53 * D.1585_53;
D.1587_55 = D.1586_54 * D.1586_54;
D.1588_56 = D.1587_55 * D.1547_15;
D.1589_57 = D.1588_56 * D.1588_56;
D.1590_58 = D.1589_57 * D.1589_57;
D.1591_59 = D.1590_58 * D.1590_58;
D.1592_60 = D.1591_59 * D.1547_15;
D.1593_61 = D.1592_60 * D.1592_60;
D.1594_62 = D.1593_61 * D.1593_61;
D.1595_63 = D.1594_62 * D.1594_62;
D.1596_64 = D.1595_63 * D.1547_15;
D.1597_65 = D.1596_64 * D.1596_64;
D.1598_66 = D.1597_65 * D.1597_65;
D.1599_67 = D.1598_66 * D.1598_66;
D.1600_68 = D.1599_67 * D.1547_15;
D.1601_69 = D.1600_68 * D.1600_68;
D.1602_70 = D.1601_69 * D.1601_69;
D.1603_71 = D.1602_70 * D.1602_70;
D.1604_72 = D.1603_71 * D.1547_15;
D.1605_73 = D.1604_72 * D.1604_72;
D.1606_74 = D.1605_73 * D.1605_73;
D.1607_75 = D.1606_74 * D.1606_74;
D.1608_76 = D.1607_75 * D.1547_15;
D.1609_77 = D.1608_76 * D.1608_76;
D.1610_78 = D.1609_77 * D.1609_77;
D.1611_79 = D.1610_78 * D.1610_78;
D.1612_80 = D.1611_79 * D.1547_15;
D.1613_81 = D.1612_80 * D.1612_80;
D.1614_82 = D.1613_81 * D.1613_81;
D.1615_83 = D.1614_82 * D.1614_82;
D.1616_84 = D.1615_83 * D.1547_15;
D.1617_85 = D.1616_84 * D.1616_84;
D.1618_86 = D.1617_85 * D.1617_85;
D.1619_87 = D.1618_86 * D.1618_86;
D.1620_88 = D.1619_87 * D.1547_15;
D.1623_89 = (integer(kind=4)) D.1620_88;

didn't I fix a similar case not too long ago (PR40062)?  Bah.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-12 13:14:04
   date||


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

[Bug fortran/41043] [4.4/4.5 Regression] virtual memory exhausted: Cannot allocate memory

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-08-12 13:36 ---
We take a lot of time and memory in

  /* Convert (T1)(X * Y) into (T1)X * (T1)Y if T1 is narrower than the
 type of X and Y (integer types only).  */
  if (INTEGRAL_TYPE_P (type)
  && TREE_CODE (op0) == MULT_EXPR
  && INTEGRAL_TYPE_P (TREE_TYPE (op0))
  && TYPE_PRECISION (type) < TYPE_PRECISION (TREE_TYPE (op0)))
{
...
 tem = fold_build2 (MULT_EXPR, mult_type,
 fold_convert (mult_type,
   TREE_OPERAND (op0, 0)),
 fold_convert (mult_type,
   TREE_OPERAND (op0, 1)));

building

character(kind=4)) i_1(D) * (character(kind=4)) i_1(D)) *
(character(kind=4)) i_1(D)) * character(kind=4)) i_1(D) * ...

from

(character(kind=4)) (integer(kind=8)) i_1(D) * ((integer(kind=8)) i_1(D) *
(integer(kind=8)) i_1(D))) * (((integer(kind=8)) i_1(D) * ((integer(kind=8))
i_1(D) * (integer(kind=8)) i_1(D))) * ...

appearantly something odd happens as that above transformation should
take linear time only.


-- 


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

[Bug fortran/41043] [4.4/4.5 Regression] virtual memory exhausted: Cannot allocate memory

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.2


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

[Bug bootstrap/41031] [4.5 Regression] ICE in insert_value_copy_on_edge preventing bootstrap on sparc64 and s390x, testcase on cris-elf

[hp at gcc dot gnu dot org]

--- Comment #10 from hp at gcc dot gnu dot org  2009-08-12 14:11 ---
(In reply to comment #9)
> (In reply to comment #8)
> > The patch is already approved, so I'm going to commit it on behalf of 
> > rsandifo.
> 
> Oops, I see it's not completely tested yet.
> Ok, I'm doing a test-run on cris-elf first.
> (If someone knows it's already sufficiently tested somewhere, please do the
> honors.)

The patch fixes the build problem with no regressions at r150593.  I'm not
committing it though, see
.
(FWIW, r150678 has a separate ICE at build for cris-elf.)


-- 


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

Re: [Bug c++/40092] solution in cp_tree_equal (was Re: [Bug c++/40092] New: -std=gnu++0x expansion pattern fails with error about derived template instead of actual template

[Larry Evans]

On 05/10/09 11:20, cppljevans at suddenlink dot net wrote:

When compile trysto expand:

  : seq
  < integral_c
< Integral
, Vals
>...

the error diagnostic prints integral_c instead of 
integral_c.  The integral_constant template

is derived from integral_c and does have T and val args:

struct integral_constant:public mpl::integral_c < T, val >

However, when that is replaced with:

struct integral_constant;//:public mpl::integral_c < T, val >

Compilation succeeds.




When cp_tree_equal in cp/tree.c at around line 1903 is changed to:


case TEMPLATE_PARM_INDEX:
  {
if (TEMPLATE_PARM_IDX (t1) != TEMPLATE_PARM_IDX (t2)) return false;
if (TEMPLATE_PARM_LEVEL (t1) != TEMPLATE_PARM_LEVEL (t2)) return false;
  #if 1
if (TEMPLATE_PARM_PARAMETER_PACK (t1) != TEMPLATE_PARM_PARAMETER_PACK 
(t2)) return false;
  #endif
return same_type_p ( TREE_TYPE (TEMPLATE_PARM_DECL (t1)),
 TREE_TYPE (TEMPLATE_PARM_DECL (t2)));
  }



the test passes.  Apparently, when the test:


  if (comp_template_args (TREE_PURPOSE (spec), args))


at around line pt.c:962 is executed, it passes when it shouldn't
and selects a previous instantiation with different value for
TEMPLATE_PARM_PARAMETER_PACK.  This different instantiation leads
to the failure of the test in:


  if (TEMPLATE_PARM_PARAMETER_PACK (t))
parameter_pack_p = true;


at round pt.c:2463 which causes the error message.

[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold

[rmansfield at qnx dot com]

--- Comment #39 from rmansfield at qnx dot com  2009-08-12 14:22 ---
I came across a original-tree-changed-by-fold ICE building libsupc++ for a
arm-unknown-linux-gnu target with --enable-checking=fold.

gcc version 4.5.0 20090812 (experimental) [trunk revision 150681] (GCC)

../../../../libstdc++-v3/libsupc++/dyncast.cc: In function 'void*
__cxxabiv1::__dynamic_cast(const void*, const __cxxabiv1::__class_type_info*,
const __cxxabiv1::__class_type_info*, ptrdiff_t)':
../../../../libstdc++-v3/libsupc++/dyncast.cc:86:1: internal compiler error:
fold check: original tree changed by fold
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [dyncast.lo] Error 1
make[4]: Leaving directory
`/home/ryan/gcc/trunk/gcc/arm-build/arm-unknown-linux-gnu/libstdc++-v3/libsupc++'


-- 

rmansfield at qnx dot com changed:

   What|Removed |Added

 CC||rmansfield at qnx dot com


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

[Bug ada/40775] ICE in find_valid_class, at reload.c:701

[joel at gcc dot gnu dot org]

--- Comment #1 from joel at gcc dot gnu dot org  2009-08-12 14:25 ---
4.3.4 definitely builds.


-- 

joel at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.3.4


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

[Bug middle-end/40980] air.f90 ICEs compiler with -fgraphite-identity

[spop at gcc dot gnu dot org]

--- Comment #4 from spop at gcc dot gnu dot org  2009-08-12 14:33 ---
Subject: Bug 40980

Author: spop
Date: Wed Aug 12 14:32:31 2009
New Revision: 150694

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150694
Log:
Prepare expressions to be good phi arguments.

2009-08-11  Sebastian Pop  

PR middle-end/40980
* sese.c (convert_for_phi_arg): New.
(add_guard_exit_phis): Use convert_for_phi_arg.

* testsuite/gfortran.dg/graphite/id-17.f: New.


Added:
trunk/gcc/testsuite/gfortran.dg/graphite/id-17.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ChangeLog.graphite
trunk/gcc/sese.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/40980] air.f90 ICEs compiler with -fgraphite-identity

[spop at gcc dot gnu dot org]

--- Comment #5 from spop at gcc dot gnu dot org  2009-08-12 14:41 ---
Fixed.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/40982] induct.f90 ICEs compiler using -O3 -fgraphite-identity -floop-interchange

[spop at gcc dot gnu dot org]

--- Comment #1 from spop at gcc dot gnu dot org  2009-08-12 14:42 ---
Fixed.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

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

[spop at gcc dot gnu dot org]

--- Comment #1 from spop at gcc dot gnu dot org  2009-08-12 14:46 ---
Fixed.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/40979] induct benchmark 60% slower when compiled with -fgraphite-identity

[spop at gcc dot gnu dot org]

--- Comment #1 from spop at gcc dot gnu dot org  2009-08-12 14:58 ---
Still fails on my machine, on rev150694.

~/gcc/svn/trunk/usr/bin/gfortran -ffast-math -funroll-loops -msse3 -O3
induct.f90 -o induct
time ./induct
real0m16.596s
user0m16.393s
sys 0m0.076s

~/gcc/svn/trunk/usr/bin/gfortran -fgraphite-identity -ffast-math -funroll-loops
-msse3 -O3 induct.f90 -o induct
time ./induct
real0m25.740s
user0m25.634s
sys 0m0.084s


-- 


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

[Bug tree-optimization/41011] [4.5 Regression] ICE in ipcp_lattice_from_jfunc, at ipa-cp.c:328

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-08-12 15:01 ---
I have a patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-12 15:01:58
   date||


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

[Bug middle-end/40965] [4.5 Regression][graphite] slow compilation

[spop at gcc dot gnu dot org]

--- Comment #7 from spop at gcc dot gnu dot org  2009-08-12 15:03 ---
This still fails on rev150694.  The problem is in the data dependence analyzer:

Graphite loop transforms:   0.34 ( 0%) usr   0.00 ( 0%) sys   0.29 (0%) wall   
2105 kB ( 7%) ggc
Graphite data dep analysis: 107.68 (95%) usr   0.67 (92%) sys 109.43 (95%) wall
  0 kB ( 0%) ggc
Graphite code generation:   0.21 ( 0%) usr   0.00 ( 0%) sys   0.15 (0%) wall   
 157 kB ( 1%) ggc


-- 


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

[Bug bootstrap/40103] CLooG header files are not -Wc++-compat ready

[spop at gcc dot gnu dot org]

--- Comment #9 from spop at gcc dot gnu dot org  2009-08-12 15:14 ---
Subject: Bug 40103

Author: spop
Date: Wed Aug 12 15:13:52 2009
New Revision: 150696

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150696
Log:
Remove pragma GCC diagnostic warning "-Wc++-compat".

2009-08-12  Sebastian Pop  

PR bootstrap/40103
* graphite.c: Remove pragma GCC diagnostic warning "-Wc++-compat".


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


-- 


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

[Bug bootstrap/41031] [4.5 Regression] ICE in insert_value_copy_on_edge preventing bootstrap on sparc64 and s390x, testcase on cris-elf

[bonzini at gcc dot gnu dot org]

--- Comment #11 from bonzini at gnu dot org  2009-08-12 16:28 ---
Subject: Bug 41031

Author: bonzini
Date: Wed Aug 12 16:28:36 2009
New Revision: 150701

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150701
Log:
2009-08-12  Richard Sandiford  

PR tree-optimization/41031
* tree-outof-ssa.c (insert_value_copy_on_edge): Use promote_decl_mode
on the partition variable rather than promote_mode on the source
type.  Assert that the partition variable's type has the same
mode as the source value's.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-outof-ssa.c


-- 


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

[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23

[bonzini at gnu dot org]

--- Comment #24 from bonzini at gnu dot org  2009-08-12 16:29 ---
patch committed as r150700


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c/41045] New: Extended asm with C operands doesn�t work at top level

[anders at kaseorg dot com]

I’d like to be able to write toplevel inline assembly with C operands that are
compile-time constants, e.g.

static const char foo[] = "Hello, world!";
enum { bar = 17 };
asm(".pushsection baz; .long %c0, %c1, %c2; .popsection"
: : "i" (foo), "i" (sizeof(foo)), "i" (bar));

However, this currently fails with “error: expected ‘)’ before ‘:’ token” at
the top level, even though it works fine inside a function.


-- 
   Summary: Extended asm with C operands doesn’t work at top level
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anders at kaseorg dot com


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

[Bug c/41045] Extended asm with C operands doesn�t work at top level

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-08-12 16:56 ---
For you example why can you do something like:
static void *bazsection1[] __attribute__((section("baz"), used)) = {
(void*)foo, (void*)(sizeof(foo)), (void*)(bar) };

This seems like a better option than using inline-asm and cleaner and more
portable.


-- 


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

[Bug c/41046] New: decNumber leaves printf call in libgcc

[janis at gcc dot gnu dot org]

The decNumber package has debugging code with calls to printf.  Most of those
calls are protected by DECCHECK or DECTRACE, but a couple of them are not.  The
printf calls should not be in the normal build of libgcc.

I'm about to submit a fix but want a PR to keep track of this issue.


-- 
   Summary: decNumber leaves printf call in libgcc
   Product: gcc
   Version: 4.3.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: janis at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org


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

[Bug tree-optimization/41035] AIX cexp builtin underflow

[dje at gcc dot gnu dot org]

--- Comment #1 from dje at gcc dot gnu dot org  2009-08-12 17:35 ---
This started failing after I started compiling with MPC library.  Is this an
MPC bug or interaction bug?


-- 

dje 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-08-12 17:35:11
   date||


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

[Bug middle-end/41047] New: gcc.target/mips/memcpy-1.c failing

[nemet at gcc dot gnu dot org]

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

Seems like we losing alignment on string literals again (PR/27226).  The
testcase is from dhrystone.


-- 
   Summary: gcc.target/mips/memcpy-1.c failing
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nemet at gcc dot gnu dot org
GCC target triplet: mips64*-linux


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

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

[tkoenig at gcc dot gnu dot org]

--- Comment #6 from tkoenig at gcc dot gnu dot org  2009-08-12 17:53 ---
We get a dramatic speedup when enclosing the arguments to
print in parentheses:

This is something we can do for

- write and print statements
- intent(in) arguments
- any do variable passed as an argument within the loop

$ gfortran -O2 count-2.f90 && time ./a.out > /dev/null

real0m11.395s
user0m11.361s
sys 0m0.004s
$ gfortran -O2 count-3.f90 && time ./a.out > /dev/null

real0m4.607s
user0m4.560s
sys 0m0.040s

$ cat count-2.f90
program main 
  implicit none  
  integer :: value
  integer :: p1, p2, p3, p4
  integer :: i 

  do value = 750,800
 do i=1, 10 
do p1 = 1, value-2
   do p2 = p1 + 1, value - p1
  do p3 = p2 + 1, (value - (p1 + p2))/2
 p4 = value - p1 - p2 - p3 
 if (p1 * p2 * p3 * p4 == value * 100) &
  print '(5(I0,:" "))',value,p1,p2,p3,p4
  end do
   end do
end do
 end do
  end do
end program main
$ cat count-3.f90
program main
  implicit none
  integer :: value
  integer :: p1, p2, p3, p4
  integer :: i

  do value = 750,800
 do i=1, 10
do p1 = 1, value-2
   do p2 = p1 + 1, value - p1
  do p3 = p2 + 1, (value - (p1 + p2))/2
 p4 = value - p1 - p2 - p3
 if (p1 * p2 * p3 * p4 == value * 100) &
  print '(5(I0,:" "))',(value),(p1),(p2),(p3),(p4)
  end do
   end do
end do
 end do
  end do
end program main


-- 


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

[Bug middle-end/41047] gcc.target/mips/memcpy-1.c failing

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-08-12 17:54 ---
Is that a recent regression?


-- 


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

[Bug tree-optimization/41011] [4.5 Regression] ICE in ipcp_lattice_from_jfunc, at ipa-cp.c:328

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-08-12 17:55 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/41011] [4.5 Regression] ICE in ipcp_lattice_from_jfunc, at ipa-cp.c:328

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-08-12 17:56 ---
Subject: Bug 41011

Author: rguenth
Date: Wed Aug 12 17:55:40 2009
New Revision: 150705

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

PR tree-optimization/41011
* ipa-cp.c (ipcp_lattice_from_jfunc): Deal with failing fold
and reference constructing.

* gfortran.dg/pr41011.f: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/pr41011.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-cp.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/41047] gcc.target/mips/memcpy-1.c failing

[anemet at caviumnetworks dot com]

--- Comment #2 from anemet at caviumnetworks dot com  2009-08-12 18:08 
---
Subject:  gcc.target/mips/memcpy-1.c failing

rguenth at gcc dot gnu dot org writes:
> Is that a recent regression?

Last 12 days.  Guerby has results from 7/30 that don't show this.

Adam


-- 


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

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

[Tobias Schlüter]

--- Comment #7 from =?ISO-8859-1?Q?Tobias_Schl=FCter?=
   2009-08-12 18:11 
---
Subject: Re:  Invariant DO loop variables and subroutines

tkoenig at gcc dot gnu dot org wrote:
> --- Comment #6 from tkoenig at gcc dot gnu dot org  2009-08-12 17:53 
> ---
> We get a dramatic speedup when enclosing the arguments to
> print in parentheses:
> 
> This is something we can do for
> 
> - write and print statements
> - intent(in) arguments
> - any do variable passed as an argument within the loop

An interesting approach.  As long as you don't print array slices in the 
loops this should work around the escaping pointer problem.  It comes at 
the risk of creating excessive copies.

Actually, perhaps the right way of achieving this is not to add 
OP_PARENTHESES in the frontend, but to do a copy when creating the call.

Cheers,
- Tobi


-- 


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

[Bug target/40934] [4.5 Regression] ICE in get_hard_regnum, at reg-stack.c:741

[sezeroz at gmail dot com]

--- Comment #14 from sezeroz at gmail dot com  2009-08-12 18:20 ---
anything new on this?


-- 


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

[Bug middle-end/41047] gcc.target/mips/memcpy-1.c failing

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-08-12 18:54 ---
We used to get

  memcpy (&c, &"12345678"[2], 6); [tail call]
  memcpy (&c, "123456", 6); [tail call]

for expansion, but now we get

  D.2386_1 = (const void * restrict) "123456";
  c.1_2 = (void * restrict) &c;
  memcpy (c.1_2, D.2386_1, 6); [tail call]

and

  D.2383_1 = (const void * restrict) "12345678";
  D.2384_2 = D.2383_1 + 2;
  c.0_3 = (void * restrict) &c;
  memcpy (c.0_3, D.2384_2, 6); [tail call]

it's probably me that caused this - will have a look and add a target
independent testcase.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-12 18:54:55
   date||


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

[Bug c++/41038] [4.4/4.5 regression] Parsing error related to qualified name id

[crowl at google dot com]

--- Comment #2 from crowl at google dot com  2009-08-12 18:42 ---
It looks like the compiler is not properly handling injected class names.  The
original example was not the best use of the injected class name, but should be
accepted.  Jonathan's example is better code, and still shows the problem.

The workaround is to drop the qualifier.  Since the base is public, its member
will be found.


-- 


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

[Bug fortran/41022] [F03] procedure pointer components as actual arguments

[reuter at physik dot uni-freiburg dot de]

--- Comment #8 from reuter at physik dot uni-freiburg dot de  2009-08-12 
19:09 ---
The fix seems not to work with the test program. 
On Linux 32 bit I get the following when compiling:
/tmp/cciQlmr1.o: In function `MAIN__':
foo.f90:(.text+0x1b): undefined reference to `proc_'
collect2: ld returned 1 exit status

and on MAC OS X:
Undefined symbols:
  "_proc_", referenced from:
  _proc_$non_lazy_ptr in ccJFt47G.o
ld: symbol(s) not found
collect2: ld returned 1 exit status


-- 

reuter at physik dot uni-freiburg dot de changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

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

[cppljevans at suddenlink dot net]

--- Comment #9 from cppljevans at suddenlink dot net  2009-08-12 19:15 
---
As indicated here:

http://article.gmane.org/gmane.comp.gcc.bugs/254672

the problem occurs because an additional test is needed
in cp_tree_equal.


-- 


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

[Bug debug/41048] New: bad DW_AT_data_member_location from g++

[tromey at gcc dot gnu dot org]

This example came from the gdb list:

#include "stdio.h"
class Blah
{
public:
Blah(): mFlag(0) {}
void setFlag( int value ) {
mFlag = value;
}
void printFlag() {
printf( "Flag value is %d\n", mFlag );
}
private:
int mHugeArray[0x0801];
int mFlag;
};

int main( int argc, char* argv[] )
{
Blah* foo = new Blah();
foo->setFlag(1);
foo->printFlag();
return 0;
}


I compiled this using today's svn trunk g++.
Then readelf shows:

 <2><8e>: Abbrev Number: 7 (DW_TAG_member)
<8f>   DW_AT_name: (indirect string, offset: 0x9f): mHugeArray  
<93>   DW_AT_decl_file   : 1
<94>   DW_AT_decl_line   : 13   
<95>   DW_AT_type: <0xf2>   
<99>   DW_AT_data_member_location: 2 byte block: 23 0  
(DW_OP_plus_uconst: 0)
<9c>   DW_AT_accessibility: 3   (private)
 <2><9d>: Abbrev Number: 7 (DW_TAG_member)
<9e>   DW_AT_name: (indirect string, offset: 0x0): mFlag
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 14   
   DW_AT_type: <0x53>   
   DW_AT_data_member_location: 2 byte block: 23 0  
(DW_OP_plus_uconst: 0)
   DW_AT_accessibility: 3   (private)


Both fields the same DW_AT_data_member_location.


-- 
   Summary: bad DW_AT_data_member_location from g++
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org


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

[Bug fortran/41022] [F03] procedure pointer components as actual arguments

[reuter at physik dot uni-freiburg dot de]

--- Comment #9 from reuter at physik dot uni-freiburg dot de  2009-08-12 
19:21 ---
Sorry, false alarm. Had a truncated test file.


-- 

reuter at physik dot uni-freiburg dot de changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug debug/41048] bad DW_AT_data_member_location from g++

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-08-12 19:25 ---
I think this only happens for HWI == 32bits.  It works for me with a compiler
for ppc64-linux-gnu but fails with i686-linux-gnu.  (Oh it works for
i386-darwin too which has HWI as being 64bits).

One more reason to change HWI for x86 to be 64bits by default.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 GCC target triplet||HWi == 32bits


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

[Bug middle-end/41047] gcc.target/mips/memcpy-1.c failing

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-08-12 20:10 ---
Created an attachment (id=18345)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18345&action=view)
patch

Fix I am testing.


-- 


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

[Bug middle-end/41047] [4.5 Regression] gcc.target/mips/memcpy-1.c failing

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||missed-optimization
Summary|gcc.target/mips/memcpy-1.c  |[4.5 Regression]
   |failing |gcc.target/mips/memcpy-1.c
   ||failing
   Target Milestone|--- |4.5.0
Version|4.4.0   |4.5.0


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

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

[tkoenig at gcc dot gnu dot org]

--- Comment #8 from tkoenig at gcc dot gnu dot org  2009-08-12 20:36 ---
(In reply to comment #7)

> An interesting approach.  As long as you don't print array slices in the 
> loops this should work around the escaping pointer problem.  It comes at 
> the risk of creating excessive copies.

Apparently, the optimizers are smart enough for that at least for
simple cases.

The loop in the following subroutine gets translated to

subroutine foo
  do i=1,10
call bar((i))
  end do
end subroutine foo

   leal-12(%ebp), %esi
.p2align 4,,7
L2:
movl%ebx, -12(%ebp)
addl$1, %ebx
movl%esi, (%esp)
callbar_
cmpl$11, %ebx
jne L2

which is pretty good.

> Actually, perhaps the right way of achieving this is not to add 
> OP_PARENTHESES in the frontend, but to do a copy when creating the call.

This would likely have the same result, the subprogram

subroutine foo
  do i=1,10
j = i
call bar(j)
  end do
end subroutine foo

gets the same code as the one above.

For comparision, the unadorned

$ cat a.f90
subroutine foo
  do i=1,10
call bar(i)
  end do
end subroutine foo

gets

movl$1, -12(%ebp)
.L2:
movl%ebx, (%esp)
callbar_
movl-12(%ebp), %eax
leal1(%eax), %edx
cmpl$10, %eax
movl%edx, -12(%ebp)
jne .L2


-- 


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

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

[tobi at gcc dot gnu dot org]

--- Comment #9 from tobi at gcc dot gnu dot org  2009-08-12 20:52 ---
Side remark:
  DO i = 1,10
call bar(i)
  END DO
wouldn't be valid if bar changed its argument, i.e. the compiler should
generate the same, better code it does for the case where you copy the argument
(bar((i))).

I was worrying about the case where a whole array is passed as an argument, for
a contrived example say:
DO I=1,1000
  DO J=1,1000
 a(i,j) = i*j
 PRINT *, a  ! don't want to copy all of a here
  END DO
END DO

The remark about OP_PARENTHESES was more about a clean implementation. 
Implementing this via OP_PARENTHESES would likely only be a few lines here and
there, but it would be hackish as it would be workign around a deficiency
further down.


-- 


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

[Bug c/41049] New: conversion from integer to decimal float loses trailing zeros

[janis at gcc dot gnu dot org]

IEEE 754 says that the preferred exponent of the result of a conversion from an
integer to a decimal float value is zero.  In all active branches of GCC a
compile-time conversion discards trailing zeros and then adds one back, and a
runtime conversion for the densely-packed decimal format adds an extra trailing
zero.  Runtime conversions for the BID format are correct, as are runtime
conversions for DPD using hardware DFP.

This test demonstrates the problem:


#include 

int
main ()
{
  volatile _Decimal32 d;
  volatile long long ll;

  d = 5.DF;
  printf ("5.DF constant0x%x  want this\n", *(int *)&d);
  d = 5.0DF;
  printf ("5.0DF constant   0x%x  not this\n", *(int *)&d);
  d = 5;
  printf ("5 constant   0x%x\n", *(int *)&d);
  d = 5LL;
  printf ("5LL constant 0x%x\n", *(int *)&d);
  ll = 5LL;
  d = ll;
  printf ("5LL variable 0x%x\n", *(int *)&d);
  printf ("\n");

  d = 50.DF;
  printf ("50.DF constant   0x%x  want this\n", *(int *)&d);
  d = 50.0DF;
  printf ("50.0DF constant  0x%x  not this\n", *(int *)&d);
  d = 50;
  printf ("50 constant  0x%x\n", *(int *)&d);
  d = 50LL;
  printf ("50LL constant0x%x\n", *(int *)&d);
  ll = 50LL;
  d = ll;
  printf ("50LL variable0x%x\n", *(int *)&d);
  printf ("\n");

  d = 500.DF;
  printf ("500.DF constant  0x%x  want this\n", *(int *)&d);
  d = 5.0E2DF;
  printf ("5.0E2DF constant 0x%x  not this\n", *(int *)&d);
  d = 500.0DF;
  printf ("500.0DF constant 0x%x  not this\n", *(int *)&d);
  d = 500;
  printf ("500 constant 0x%x\n", *(int *)&d);
  d = 500LL;
  printf ("500LL constant   0x%x\n", *(int *)&d);
  ll = 500LL;
  d = ll;
  printf ("500LL variable   0x%x\n", *(int *)&d);

  return 0;
}


With DPD on either powerpc64-linux or i686-linux the results are:

laptop% /home/janis/tools/gcc-trunk-dpd/bin/gcc bug3.c && ./a.out
5.DF constant0x2255  want this
5.0DF constant   0x22400050  not this
5 constant   0x22400050
5LL constant 0x22400050
5LL variable 0x22400050

50.DF constant   0x22500050  want this
50.0DF constant  0x22400280  not this
50 constant  0x22500050
50LL constant0x22500050
50LL variable0x22400280

500.DF constant  0x22500280  want this
5.0E2DF constant 0x22600050  not this
500.0DF constant 0x22401400  not this
500 constant 0x22600050
500LL constant   0x22600050
500LL variable   0x22401400

For BID on i686-linux the results are:

laptop% /home/janis/tools/gcc-trunk-bid/bin/gcc bug3.c && ./a.out
5.DF constant0x3285  want this
5.0DF constant   0x3232  not this
5 constant   0x3232
5LL constant 0x3232
5LL variable 0x3285

50.DF constant   0x32800032  want this
50.0DF constant  0x320001f4  not this
50 constant  0x32800032
50LL constant0x32800032
50LL variable0x32800032

500.DF constant  0x328001f4  want this
5.0E2DF constant 0x3332  not this
500.0DF constant 0x32001388  not this
500 constant 0x3332
500LL constant   0x3332
500LL variable   0x328001f4

I'm working on fixes to the compiler and to the DPD runtime.


-- 
   Summary: conversion from integer to decimal float loses trailing
zeros
   Product: gcc
   Version: 4.3.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: janis at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org


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

[Bug middle-end/41047] [4.5 Regression] gcc.target/mips/memcpy-1.c failing

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-08-12 21:20 ---
Created an attachment (id=18346)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18346&action=view)
good patch

better patch, the old one missed the tree-ssa.c hunk and the testcase was
broken.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #18345|0   |1
is obsolete||


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

[Bug middle-end/41047] [4.5 Regression] gcc.target/mips/memcpy-1.c failing

[nemet at gcc dot gnu dot org]

--- Comment #6 from nemet at gcc dot gnu dot org  2009-08-12 21:27 ---
It fixes the testcase on mips64octeon-linux.  Thanks.


-- 


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

[Bug c/40967] Bad 64-bit codegen for modified 39495 testcase

[brian dot e dot bliss at intel dot com]

--- Comment #3 from brian dot e dot bliss at intel dot com  2009-08-12 
21:29 ---
It doesn't look like the problem is confined to Intel64 code.  Here's the IPF
assembly for the GOMP_loop_dynamic_start call:

addp4 r15 = r14, r0
adds r14 = -24, r37
mov r39 = r16
;;
mov r40 = r15
addp4 r41 = 4294967294 - 0x1, r0
addl r42 = 1, r0
mov r43 = r14
adds r44 = -32, r37
br.call.sptk.many b0 = GOMP_loop_dynamic_start#

The "addp" instruction clears bits 32:60 of the result.  "adds" (14-byte
sign-extended immediate form) should be used.


-- 

brian dot e dot bliss at intel dot com changed:

   What|Removed |Added

Summary|Bad Intel64 codegen for |Bad 64-bit codegen for
   |modified 39495 testcase |modified 39495 testcase


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

[Bug target/40125] libgcc_s DLL installed in wrong directory in cross toolchain

[davek at gcc dot gnu dot org]

-- 

davek at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |davek at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-12 22:14:39
   date||


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

[Bug target/41029] ICE RTL check: expected code 'reg', have 'post_inc' in rhs_regno, at rtl.h:1008

[kkojima at gcc dot gnu dot org]

--- Comment #5 from kkojima at gcc dot gnu dot org  2009-08-12 22:26 ---
Subject: Bug 41029

Author: kkojima
Date: Wed Aug 12 22:26:13 2009
New Revision: 150709

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150709
Log:
PR target/41029
* config/sh/sh.md (reload_outdf__RnFRm+4): Fix thinko.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md


-- 


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

[Bug middle-end/30789] complex folding inexact

[ghazi at gcc dot gnu dot org]

--- Comment #3 from ghazi at gcc dot gnu dot org  2009-08-12 22:28 ---
(In reply to comment #2)

Joseph - Thanks for your reply and testvalues.

> There are also cases for exact rounding where you'd expect MPC to produce 
> the right results but would *not* expect operations executed at runtime to 
> produce exactly those results.  For example, (1.0 + DBL_EPSILON + 1.0i) * 
> (1.0 - DBL_EPSILON + 1.0i), which would only work at runtime if the code 
> happens to use exactly the right fused multiply-add operation.

What is the "right result" for this case?  GCC with MPC produces:
-4.93038065763132378382330353301741393545754021943139377981e-32 + 2.0i)

Unpatched GCC as well as the runtime on my x86_64 box says:
0.0 + 2.0i

So the runtime here is not using the fused instruction?

Is the MPC value correct?

Thanks.


-- 


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

[Bug target/41029] ICE RTL check: expected code 'reg', have 'post_inc' in rhs_regno, at rtl.h:1008

[kkojima at gcc dot gnu dot org]

--- Comment #6 from kkojima at gcc dot gnu dot org  2009-08-12 22:29 ---
Fixed.


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/40125] libgcc_s DLL installed in wrong directory in cross toolchain

[davek at gcc dot gnu dot org]

--- Comment #1 from davek at gcc dot gnu dot org  2009-08-12 22:57 ---
Even the target-specific i686-mingw32/bin directory contains host applications,
i.e. the non-$target-prefixed versions of the binutils.

So since these DLLs are never going to be used on the host, we could put them
in $target/lib.  That might end up altering the link order a bit, since ld
supports linking directly against dlls but $prefix/bin isn't usually in the
link path; however as long as the compiler's private directory
$prefix/lib/gcc/$target/$version is first in the list, the dll's related import
lib will always be found first.

The other place to install them would be in GCC's private dir.  I'm not sure
yet which might be preferable.


-- 


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

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

[howarth at nitro dot med dot uc dot edu]

--- Comment #2 from howarth at nitro dot med dot uc dot edu  2009-08-12 
23:40 ---
What revision fixed this on trunk? I am still seeing the ICE with r150709 on
x86_64-apple-darwin10.


-- 


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

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

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2009-08-13 00:14 ---
On amd64-linux at r150694, I have all the polyhedron bmks compiling fine.
I double checked for aermod.f90 with exactly the same options where you see the
error:
gfortran -O2 -fgraphite-identity -floop-strip-mine aermod.f90 -o aermo


-- 


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

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

[howarth at nitro dot med dot uc dot edu]

--- Comment #4 from howarth at nitro dot med dot uc dot edu  2009-08-13 
00:43 ---
I am actually seeing this problem with the aermod, air, capacita, doduc,
fatigue, gas_dyn, induct, linpk, mdbx, nf, protein, rnflow, test_fpu and tfft
benchmarks with...

-O2 -fgraphite-identity -floop-strip-mine

The ICEs are...

tfft.f90: In function ‘tfft’:
tfft.f90:3:0: internal compiler error: Floating point exception

rnflow.f90: In function ‘invima’:
rnflow.f90:2878:0: internal compiler error: Floating point exception

test_fpu.f90: In function ‘gauss’:
test_fpu.f90:89:0: internal compiler error: Floating point exception

protein.f90: In function ‘superficie_proteina’:
protein.f90:1585:0: internal compiler error: Floating point exception

nf.f90: In function ‘trisolve’:
nf.f90:227:0: internal compiler error: Floating point exception

mdbx.f90: In function ‘cbuild’:
mdbx.f90:1425:0: internal compiler error: Floating point exception

linpk.f90: In function ‘matgen’:
linpk.f90:44:0: internal compiler error: Floating point exception

induct.f90: In function ‘mutual_ind_cir_cir_coils’:
induct.f90:777:0: internal compiler error: Floating point exception

gas_dyn.f90: In function ‘cortesa’:
gas_dyn.f90:1791:0: internal compiler error: Floating point exception

fatigue.f90: In function ‘iztaccihuatl’:
fatigue.f90:1265:0: internal compiler error: Floating point exception

doduc.f90: In function ‘s00017’:
doduc.f90:1480:0: internal compiler error: Floating point exception

capacita.f90: In function ‘capacitance’:
capacita.f90:573:0: internal compiler error: Floating point exception

air.f90: In function ‘state’:
air.f90:1034:0: internal compiler error: Floating point exception

aermod.f90: In function ‘chk_endyr’:
aermod.f90:5620:0: internal compiler error: Floating point exception

In case it helps reproduce the problem on x86_64 linux, on
x86_64-apple-darwin10...

touch t.f90
gfortran -fverbose-asm t.f90 -S
more t.s
# GNU Fortran (GCC) version 4.5.0 20090812 (experimental)
(x86_64-apple-darwin10)
#   compiled by GNU C version 4.5.0 20090812 (experimental), GMP version
4.3.1, MPFR version 2.4.1
# GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
# options passed:  t.f90 -fPIC -mmacosx-version-min=10.6.0 -mtune=generic
# -fverbose-asm -fintrinsic-modules-path
# /sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin10/4.5.0/finclude
# options enabled:  -fPIC -falign-loops -fargument-noalias-anything
# -fasynchronous-unwind-tables -fauto-inc-dec -fbranch-count-reg -fcommon
# -fdelete-null-pointer-checks -fearly-inlining
# -feliminate-unused-debug-types -ffunction-cse -fgcse-lm -fident
# -finline-functions-called-once -fira-share-save-slots
# -fira-share-spill-slots -fivopts -fkeep-static-consts
# -fleading-underscore -fmerge-debug-strings -fmove-loop-invariants
# -fpeephole -freg-struct-return -fsched-critical-path-heuristic
# -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock
# -fsched-last-insn-heuristic -fsched-rank-heuristic
# -fsched-reg-pressure-heuristic -fsched-spec -fsched-spec-insn-heuristic
# -fsched-stalled-insns-dep -fshow-column -fsigned-zeros
# -fsplit-ivs-in-unroller -ftrapping-math -ftree-cselim -ftree-forwprop
# -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize
# -ftree-parallelize-loops= -ftree-phiprop -ftree-pta -ftree-reassoc
# -ftree-scev-cprop -ftree-slp-vectorize -ftree-switch-conversion
# -ftree-vect-loop-version -funit-at-a-time -funwind-tables
# -fvect-cost-model -fverbose-asm -fzero-initialized-in-bss
# -m128bit-long-double -m64 -m80387 -maccumulate-outgoing-args
# -malign-stringops -mfancy-math-387 -mfp-ret-in-387 -mfused-madd -mieee-fp
# -mmmx -mno-sse4 -mpush-args -mred-zone -msse -msse2 -msse3

.subsections_via_symbols


-- 


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

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

[howarth at nitro dot med dot uc dot edu]

--- Comment #5 from howarth at nitro dot med dot uc dot edu  2009-08-13 
01:15 ---
These ICEs also occur with...

-O1 -fgraphite-identity -floop-strip-mine

but not...

-O0 -fgraphite-identity -floop-strip-mine


-- 

howarth at nitro dot med dot uc dot edu changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug middle-end/39757] inconsistency in array bounds checking with -O3

[petteri dot kettunen at nokia dot com]

--- Comment #4 from petteri dot kettunen at nokia dot com  2009-08-13 01:15 
---
This is a bit odd but the bug was not reproducible when I tried to compile a
minimal example in a file containing that function only. I shall investigate a
bit more.


-- 


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

[Bug middle-end/30789] complex folding inexact

[joseph at codesourcery dot com]

--- Comment #4 from joseph at codesourcery dot com  2009-08-13 01:25 ---
Subject: Re:  complex folding inexact

On Wed, 12 Aug 2009, ghazi at gcc dot gnu dot org wrote:

> 
> 
> --- Comment #3 from ghazi at gcc dot gnu dot org  2009-08-12 22:28 ---
> (In reply to comment #2)
> 
> Joseph - Thanks for your reply and testvalues.
> 
> > There are also cases for exact rounding where you'd expect MPC to produce 
> > the right results but would *not* expect operations executed at runtime to 
> > produce exactly those results.  For example, (1.0 + DBL_EPSILON + 1.0i) * 
> > (1.0 - DBL_EPSILON + 1.0i), which would only work at runtime if the code 
> > happens to use exactly the right fused multiply-add operation.
> 
> What is the "right result" for this case?  GCC with MPC produces:
> -4.93038065763132378382330353301741393545754021943139377981e-32 + 2.0i)
> 
> Unpatched GCC as well as the runtime on my x86_64 box says:
> 0.0 + 2.0i
> 
> So the runtime here is not using the fused instruction?
> 
> Is the MPC value correct?

It looks correct.  You expect real part -DBL_EPSILON*DBL_EPSILON, 
imaginary part 2.0.

I believe existing x86_64 hardware does not have fused multiply-add 
instructions.


-- 


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

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

[spop at gcc dot gnu dot org]

--- Comment #6 from spop at gcc dot gnu dot org  2009-08-13 01:36 ---
Could you please run gdb on f951 and then report a backtrace of where it fails?

Thanks,
Sebastian


-- 


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

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

[howarth at nitro dot med dot uc dot edu]

--- Comment #7 from howarth at nitro dot med dot uc dot edu  2009-08-13 
01:49 ---

(gdb) r -O2 -fgraphite-identity -floop-strip-mine aermod.f90 -o aermod
Starting program: /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10/4.5.0/f951
-O2 -fgraphite-identity -floop-strip-mine aermod.f90 -o aermod
Reading symbols for shared libraries .++.. done
 aermod main hrloop julian gregor hrqext o3ext errhdl terrst sumtbl msgwrt
pnpoly allsetup allresult datime filopn header dcdlat preset preinclud srcsiz
presoinc recsiz prereinc precart pregencar prexypnts prepolr prepoldst
pregenpol preradrng prebound set_window chk_endyr calc pcalc aercalc prmcalc
gamcalc centroid refl_ht psrdeb vcalc volcalc acalc ardist ocalc setsrc fluxes
heff prmheff pdis vdis adisy adisz aer_pchi prm_pchi aer_achi debout penfct
cplume prm_plume acplume gcubic ltopg vdp scavrat pdep pdepg deplete f2int
prm_pdep prm_pdepg prm_deplete prm_f2int qatr2 qg2d2 olm_calc pvmrm_calc
plume_vol reldisp emfact distf wakflg xydist fterm fyplm fypan meandr critds
pdf skcalc crcalc alcalc becalc aacalc bbcalc llcalc decay vrtsbl vrtsbn vrtcbl
pfract erfx sumval aver hivals nhigh hsetfg maxvalue msetfg maxfil postfl
toxxfl prtday rsdump evlini evalck evalfl cocard titles modopt avetim pollid
edecay runnot flagdf evntfl savefl initfl errfil debopt myear gddef gdseas
gvsubd gdland urbopt o3val o3fil no2eq ev_setup ev_setord ev_oucard oevent
evloop meread ev_metext ev_chkdat hqread ev_hrqext evcalc ev_sumval stodbl
averev ev_output prtsoc prtdet metdet ev_flush evcard evper evloc iblval metini
locate anyavg inpsum prtopt prtsrc prtrec chkrec prtmet rsinit resini mecard
surfil profil sfdata uadata ondata prbase staend dayrng wdrota wscats meopen
scimit metext set_metdata set_dates metchk chkdat cmpdat chkclm chkmsg metqa
metdat metsum pflcnv pflini ziaver gintrp urbcalc grdurban grdpturb metdeb
grdeps oucard outqa ouhigh oumxvl oudaly oumxfl oupost ouplot perpst perplt
outoxx ouseas ourank oueval perave shave hiper pstann pltann plotfl output
prtann prtnhi sprtht prtmax prtsum evefil mxevnt prtpm10 maxpm10 prtpm10sum
shout rankfl averts areain plumef pside xwidth pwidth zbrent pside2 hpsort
escape adjemi amfrac lwind pdepth ptfrac piteff pitemi ctheta qatr3 pside_tox
pside2_tox qg2 prime1 numpr1 numrise rate lump marching unlump zmet nummet
zstream position numgrad wake_drdx wake_ini wake_scales wake_dfsn wake_dfsn2
wake_turb wake_u wake_xa wake_xa2 wake_dim wake_sig wake_dbg wake_cav0 cav_src
wake_fqc frgauss erfdif erf erfc wake_xsig cavity_ht sigypr sigzpr szsfclpr
deltah prmdelh hsprim sblris cblprd cblprn cblpr3 recard reelun recart gencar
xypnts setcar repolr polorg poldst genpol radrng setpol terhgt hilhgt flghgt
discar dispol sbyval evcart setup lwrupr define getfld expath exkey setord
stonum sindex fsplit varini includ grdsv refsv refsvc refsvm ntrpsv xtrpsv
grdsw refsw refswc refswm ntrpsw xtrpsw sigy sigz bid szsfcl rmssig socard
srcqa soelun soloca soparm pparm vparm aparm apparm arvert acparm gencir oparm
dsbldg dsfill emvary effill emunit counit dpunit partdep inppdm inpphi inppdn
gasdep meth_2 sogrp asngrp setidg vdp1 hremis urbans no2rat olmgrp comptg
tginit grdptg refptg ntrptg xtrptg xtrpdn grdpt grdden tgcard terfil terloc
tgelun tgdata tgqa zinterp grdws refws unstu stblu ntrpws xtrpws grdwd refwd1
ntrpwd xtrpwd
Analyzing compilation unit
 {GC 39382k -> 26129k} {GC 34004k -> 29619k} {GC 38591k -> 33458k} {GC 43523k
-> 37575k} {GC 48894k -> 42656k}Performing interprocedural optimizations
   {GC 55526k -> 50076k} {GC 65102k ->
63107k} Assembling
functions:
 aermod main hrloop julian gregor hrqext o3ext errhdl terrst sumtbl msgwrt
pnpoly allsetup {GC 82097k -> 71012k} allresult datime filopn header dcdlat
preset preinclud srcsiz presoinc recsiz prereinc precart pregencar prexypnts
prepolr prepoldst pregenpol preradrng prebound set_window chk_endyr
Program received signal EXC_ARITHMETIC, Arithmetic exception.
0x00014164a15d in __gmp_exception ()
(gdb) bt
#0  0x00014164a15d in __gmp_exception ()
#1  0x00014164a17e in __gmp_divide_by_zero ()
#2  0x00014166121f in __gmpz_tdiv_q ()
#3  0x000100518f46 in pbb_number_of_iterations (pbb=0x1575618c0,
loop_depth=0, niter=0x7fff5fbfd3c0) at
../../gcc-4.5-20090812/gcc/graphite-poly.c:734
#4  0x0001005122ab in scop_do_strip_mine (scop=) at
../../gcc-4.5-20090812/gcc/graphite-blocking.c:169
#5  0x000100517f08 in apply_poly_transforms (scop=0x15750ca30) at
../../gcc-4.5-20090812/gcc/graphite-poly.c:258
#6  0x000100511d43 in graphite_transform_loops () at
../../gcc-4.5-20090812/gcc/graphite.c:274
#7  0x00010077444a in graphite_transforms () at
../../gcc-4.5-20090812/gcc/tree-ssa-loop.c:300
#8  0x0001005c52a9 in execute_one_pass (pass=0x100bea580) at
../../gcc-4.5-20090812/gcc/passes.c:1291
#9  0x0001005c553d in execute_pass_list (pass=0x100bea580) at
../../gcc-4.5-20090812/gcc/passes.c:1340
#10 0x0001005c554f in

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

[howarth at nitro dot med dot uc dot edu]

--- Comment #8 from howarth at nitro dot med dot uc dot edu  2009-08-13 
02:03 ---
Another example is...

(gdb) r  -O2 -fgraphite-identity -floop-strip-mine air.f90 -o air
Starting program: /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10/4.5.0/f951
-O2 -fgraphite-identity -floop-strip-mine air.f90 -o air
Reading symbols for shared libraries .++.. done
 MAIN__ main state spectop bound points fvspltx2 fvsplty2 derivx derivy xx
grid6 inlet aexit botwall topwall
Analyzing compilation unit
 {GC 6638k -> 4188k}Performing interprocedural optimizations
   {GC 5842k -> 5718k} {GC 7502k -> 6028k}
Assembling functions:
 MAIN__ {GC 7858k -> 6199k} {GC 8281k -> 6211k} {GC 12794k -> 7064k} {GC 9743k
-> 8201k} {GC 11386k -> 8305k} main state
Program received signal EXC_ARITHMETIC, Arithmetic exception.
0x00014164a15d in __gmp_exception ()
(gdb) bt
#0  0x00014164a15d in __gmp_exception ()
#1  0x00014164a17e in __gmp_divide_by_zero ()
#2  0x00014166121f in __gmpz_tdiv_q ()
#3  0x000100518f46 in pbb_number_of_iterations (pbb=0x14275e670,
loop_depth=0, niter=0x7fff5fbfd3d0) at
../../gcc-4.5-20090812/gcc/graphite-poly.c:734
#4  0x0001005122ab in scop_do_strip_mine (scop=) at
../../gcc-4.5-20090812/gcc/graphite-blocking.c:169
#5  0x000100517f08 in apply_poly_transforms (scop=0x142756f80) at
../../gcc-4.5-20090812/gcc/graphite-poly.c:258
#6  0x000100511d43 in graphite_transform_loops () at
../../gcc-4.5-20090812/gcc/graphite.c:274
#7  0x00010077444a in graphite_transforms () at
../../gcc-4.5-20090812/gcc/tree-ssa-loop.c:300
#8  0x0001005c52a9 in execute_one_pass (pass=0x100bea580) at
../../gcc-4.5-20090812/gcc/passes.c:1291
#9  0x0001005c553d in execute_pass_list (pass=0x100bea580) at
../../gcc-4.5-20090812/gcc/passes.c:1340
#10 0x0001005c554f in execute_pass_list (pass=0x100bea2e0) at
../../gcc-4.5-20090812/gcc/passes.c:1341
#11 0x0001005c554f in execute_pass_list (pass=0x100be9980) at
../../gcc-4.5-20090812/gcc/passes.c:1341
#12 0x0001006eec6f in tree_rest_of_compilation (fndecl=0x14297c100) at
../../gcc-4.5-20090812/gcc/tree-optimize.c:390
#13 0x00010088b4ad in cgraph_expand_function (node=0x14297c300) at
../../gcc-4.5-20090812/gcc/cgraphunit.c:1114
#14 0x00010088d60a in cgraph_expand_all_functions [inlined] () at
/sw/src/fink.build/gcc45-4.4.999-20090812/gcc-4.5-20090812/gcc/cgraphunit.c:1173
#15 0x00010088d60a in cgraph_finalize_compilation_unit () at
../../gcc-4.5-20090812/gcc/cgraphunit.c:1396
#16 0x0001005714d6 in write_global_declarations () at
../../gcc-4.5-20090812/gcc/langhooks.c:314
#17 0x000100687d80 in compile_file [inlined] () at
/sw/src/fink.build/gcc45-4.4.999-20090812/gcc-4.5-20090812/gcc/toplev.c:1038
#18 0x000100687d80 in toplev_main (argc=7, argv=0x7fff5fbfd770) at
../../gcc-4.5-20090812/gcc/toplev.c:2351
#19 0x00010a34 in start ()

FYI, gcc trunk is built against gmp 4.3.1 and mpfr 2.4.1 in case it matters.


-- 


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

[Bug middle-end/40979] induct benchmark 60% slower when compiled with -fgraphite-identity

[howarth at nitro dot med dot uc dot edu]

--- Comment #2 from howarth at nitro dot med dot uc dot edu  2009-08-13 
02:25 ---
Interestingly, this benchmark is also the one that shows the best improvement
from -floop-interchange...

Compile Command : gfortran -ffast-math -funroll-loops -msse3 -O3 %n.f90 -o %n
Benchmarks  : induct
Maximum Times   : 2000.0

   Benchmark   Compile  Executable   Ave Run  Number   Estim
Name(secs) (bytes)(secs) Repeats   Err %
   -   ---  --   --- ---  --
  induct  6.83   1 12.44  10  0.0153

Compile Command : gfortran -ffast-math -funroll-loops -msse3 -O3
-fgraphite-identity  %n.f90 -o %n
Benchmarks  : induct

   Benchmark   Compile  Executable   Ave Run  Number   Estim
Name(secs) (bytes)(secs) Repeats   Err %
   -   ---  --   --- ---  --
  induct 25.09   1 20.19  10  0.0113

Compile Command : gfortran -ffast-math -funroll-loops -msse3 -O3
-fgraphite-identity -floop-interchange %n.f90 -o %n
Benchmarks  : induct

   Benchmark   Compile  Executable   Ave Run  Number   Estim
Name(secs) (bytes)(secs) Repeats   Err %
   -   ---  --   --- ---  --
  induct 26.48   1  7.43  10  0.0045


-- 


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

[Bug c++/41050] New: Placement new not seeing base class protected functions

[igodard at pacbell dot net]

This code:

#include
class   foo {
protected:
foo() {}
foo(int) {}
public:
};

class   bar : public foo {
public:
bar() : foo() {
new (this) foo(5);
}
};

bar b;


gets you:

~/ootbc/sim$ g++ foo.cc
foo.cc: In constructor ‘bar::bar()’:
foo.cc:5: error: ‘foo::foo(int)’ is protected
foo.cc:12: error: within this context


-- 
   Summary: Placement new not seeing base class protected functions
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net


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

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

[spop at gcc dot gnu dot org]

--- Comment #9 from spop at gcc dot gnu dot org  2009-08-13 02:37 ---
Subject: Re:  aermod.f90 ICEs on -O2 -fgraphite-identity 
-floop-strip-mine

Could you please try the attached patch?

Thanks,
Sebastian


--- Comment #10 from spop at gcc dot gnu dot org  2009-08-13 02:37 ---
Created an attachment (id=18347)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18347&action=view)


-- 


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

[Bug c++/41050] Placement new not seeing base class protected functions

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-08-13 02:42 ---
I think this is correct as you are not calling a protected method on this but a
new object that is created from this. 


-- 


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

[Bug c++/41050] Placement new not seeing base class protected functions

[igodard at pacbell dot net]

--- Comment #2 from igodard at pacbell dot net  2009-08-13 02:47 ---
Well, if the call is on foo then surely a foo can call; its own methods,
whereas if the call is on bar then a bar should see the protected methods of
its base class foo. Either way it should be visible.


-- 


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

[Bug middle-end/41051] New: -O1/-O2/-O3 -fgraphite-identity -floop-interchange miscompiles air.f90

[howarth at nitro dot med dot uc dot edu]

The Polyhedron 2005 benchmark air.f90 is miscompiled when -O1/-O2/-O3
-fgraphite-identity -floop-interchange  is used such that the program
outputs...

 AIRFLOW IN A BOX
Version 2.0  
   (c) Hanley Innovations  1995 
  1.2E-002  0.210.000  
0.100010
   272.769998272.769998272.769998  
 272.7699980. 
  11  12
  X-DATA
   1   0.   0.100014
   2  5.00028E-002  0.220004
   3  0.10001   0.24
   4  0.20001   0.400024
   5  0.2   0.54
   6  0.40002   0.599984
   7  0.5   0.699964
   8  0.59998   0.800044
   9  0.69996   0.900024
  10  0.80004   0.969974
  11  0.900021.4
  Y-DATA
   0.   0.100014
  4.8E-002  0.149994
  8.00017E-002  0.200014
  0.14999   0.24
  0.20001   0.400024
  0.2   0.54
  0.40002   0.599984
  0.5   0.699964
  0.59998   0.800044
  0.69996   0.890014
  0.80004   0.949964
  0.949961.4
  ITERATION#  TIME FINAL  MASS RESIDUAL
   14  100.43187820   0.0100 NaN
 deltat, final t, iterations
   100.00100.4318782042   14
  14   NaN

when executed. This is seen with r150709 with the compiler specs of...

Target: x86_64-apple-darwin10
Configured with: ../gcc-4.5-20090812/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 20090812 (experimental) (GCC)


-- 
   Summary: -O1/-O2/-O3 -fgraphite-identity -floop-interchange
miscompiles air.f90
   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=41051

[Bug middle-end/41051] -O1/-O2/-O3 -fgraphite-identity -floop-interchange miscompiles air.f90

[howarth at nitro dot med dot uc dot edu]

--- Comment #1 from howarth at nitro dot med dot uc dot edu  2009-08-13 
03:05 ---
Interestingly,  -O2/-O3 -fgraphite-identity also miscompiles air.f90, however
-O1 -fgraphite-identity results in the ICE...

air.f90: In function ‘state’:
air.f90:1034:0: internal compiler error: in scan_tree_for_params, at
graphite-sese-to-poly.c:826


-- 


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

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

[howarth at nitro dot med dot uc dot edu]

--- Comment #11 from howarth at nitro dot med dot uc dot edu  2009-08-13 
03:28 ---
Still crashes with proposed patch...

(gdb) r  -O2 -fgraphite-identity -floop-strip-mine air.f90 -o air
Starting program: /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10/4.5.0/f951
-O2 -fgraphite-identity -floop-strip-mine air.f90 -o air
Reading symbols for shared libraries .++.. done
 MAIN__ main state spectop bound points fvspltx2 fvsplty2 derivx derivy xx
grid6 inlet aexit botwall topwall
Analyzing compilation unit
 {GC 6638k -> 4188k}Performing interprocedural optimizations
   {GC 5842k -> 5718k} {GC 7502k -> 6028k}
Assembling functions:
 MAIN__ {GC 7858k -> 6199k} {GC 8281k -> 6211k} {GC 12794k -> 7064k} {GC 9743k
-> 8201k} {GC 11386k -> 8305k} main state
Program received signal EXC_ARITHMETIC, Arithmetic exception.
0x00014164a15d in __gmp_exception ()
(gdb) bt
#0  0x00014164a15d in __gmp_exception ()
#1  0x00014164a17e in __gmp_divide_by_zero ()
#2  0x00014166121f in __gmpz_tdiv_q ()
#3  0x000100518f46 in pbb_number_of_iterations (pbb=0x14275e670,
loop_depth=0, niter=0x7fff5fbfd3d0) at
../../gcc-4.5-20090812/gcc/graphite-poly.c:734
#4  0x0001005122ab in scop_do_strip_mine (scop=) at
../../gcc-4.5-20090812/gcc/graphite-blocking.c:169
#5  0x000100517f08 in apply_poly_transforms (scop=0x142756f80) at
../../gcc-4.5-20090812/gcc/graphite-poly.c:258
#6  0x000100511d43 in graphite_transform_loops () at
../../gcc-4.5-20090812/gcc/graphite.c:274
#7  0x00010077444a in graphite_transforms () at
../../gcc-4.5-20090812/gcc/tree-ssa-loop.c:300
#8  0x0001005c52a9 in execute_one_pass (pass=0x100bea580) at
../../gcc-4.5-20090812/gcc/passes.c:1291
#9  0x0001005c553d in execute_pass_list (pass=0x100bea580) at
../../gcc-4.5-20090812/gcc/passes.c:1340
#10 0x0001005c554f in execute_pass_list (pass=0x100bea2e0) at
../../gcc-4.5-20090812/gcc/passes.c:1341
#11 0x0001005c554f in execute_pass_list (pass=0x100be9980) at
../../gcc-4.5-20090812/gcc/passes.c:1341
#12 0x0001006eec6f in tree_rest_of_compilation (fndecl=0x14297c100) at
../../gcc-4.5-20090812/gcc/tree-optimize.c:390
#13 0x00010088b4ad in cgraph_expand_function (node=0x14297c300) at
../../gcc-4.5-20090812/gcc/cgraphunit.c:1114
#14 0x00010088d60a in cgraph_expand_all_functions [inlined] () at
/sw/src/fink.build/gcc45-4.4.999-20090812/gcc-4.5-20090812/gcc/cgraphunit.c:1173
#15 0x00010088d60a in cgraph_finalize_compilation_unit () at
../../gcc-4.5-20090812/gcc/cgraphunit.c:1396
#16 0x0001005714d6 in write_global_declarations () at
../../gcc-4.5-20090812/gcc/langhooks.c:314
#17 0x000100687d80 in compile_file [inlined] () at
/sw/src/fink.build/gcc45-4.4.999-20090812/gcc-4.5-20090812/gcc/toplev.c:1038
#18 0x000100687d80 in toplev_main (argc=7, argv=0x7fff5fbfd770) at
../../gcc-4.5-20090812/gcc/toplev.c:2351
#19 0x00010a34 in start ()


-- 


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

[Bug c++/19291] Warning "cannot pass objects of non-POD type" should be an error

[wallaces3 at yahoo dot com]

--- Comment #3 from wallaces3 at yahoo dot com  2009-08-13 04:02 ---
I totally agree with David Faure, please make this warning controllable:
-Werror=invalid-offsetof

All other warnings have a type that can be ignored, but when using the
-fdiagnostics-show-option option to see what the warning type is for this
non-POD warning I was amazed that it does not have a type.  In the
gcc/Warnings-Options.html the type is listed as invalid-offsetof
Please, please, please make this warning controllable.
Thanks.


-- 

wallaces3 at yahoo dot com changed:

   What|Removed |Added

 CC||wallaces3 at yahoo dot com


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

[Bug c++/35722] [C++0x] Variadic templates expansion into non-variadic class template

[jack dot q dot word at gmail dot com]

--- Comment #8 from jack dot q dot word at gmail dot com  2009-08-13 05:01 
---
Created an attachment (id=18348)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18348&action=view)
tuple & union examples with possibly proper variadic return type case relying
on variadic template expansion


-- 


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

[Bug c++/35722] [C++0x] Variadic templates expansion into non-variadic class template

[jack dot q dot word at gmail dot com]

--- Comment #9 from jack dot q dot word at gmail dot com  2009-08-13 05:04 
---
(In reply to comment #8)
> Created an attachment (id=18348)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18348&action=view) [edit]
> tuple & union examples with possibly proper variadic return type case relying
> on variadic template expansion
> 

the unnamed structs/unions, and RecursiveStruct/Union can be discarded, and use
'byte Data[VarTypeNav< cT, vT...>::Size];' ...


-- 


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

[Bug c++/35722] [C++0x] Variadic templates expansion into non-variadic class template

[jack dot q dot word at gmail dot com]

--- Comment #10 from jack dot q dot word at gmail dot com  2009-08-13 05:05 
---

> 'byte Data[VarTypeNav< cT, vT...>::Size];' ...

or 'char Data[VarTypeNav< cT, vT...>::Size];' ...


-- 


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

[Bug c++/35722] [C++0x] Variadic templates expansion into non-variadic class template

[jack dot q dot word at gmail dot com]

--- Comment #11 from jack dot q dot word at gmail dot com  2009-08-13 05:14 
---
(From update of attachment 18348)
template< class cT, class... vT >
struct VarTypeNav
{
typedef cT T;
typedef VarTypeNav< vT..., void > Next;
struct scT { cT v; };
static const size_t Size =
sizeof(scT) + Next::Size;
static const size_t Count =
1 + Next::Count;
};

template< class... vT >
struct VarTypeNav< void, vT... >
{
typedef void T; 
typedef void Next;
static const size_t Size = 0;
static const size_t Count = 0;
};

template< const size_t nIndex, class cT, class... vT >
struct VarTypeSelect
{
typedef VarTypeSelect< nIndex-1, vT... >::T T;
struct scT { T v; };
static const size_t Offset =
sizeof(scT) + VarTypeSelect< nIndex-1, vT... >::Offset;
};

template< class cT, class... vT >
struct VarTypeSelect< 0, cT, vT... >
{
typedef cT T;
static const size_t Offset = 0;
};

template< class cT, class... vT >
struct Tuple
{
char Data[VarTypeNav::Size];
template< const size_t index >
VarTypeSelect< index, vT... >::T & operator [] ( const size_t index )
{
static_assert(!(index > VarTypeNav< vT... >::Count ), "Index
out of bounds");
char * pThisChars = (char *) this;
return *(
(VarTypeSelect< index, vT... >::T *)
pThisChars[ VarTypeSelect< index, vT...
>::Offset ]));
}
template< const size_t index >
const VarTypeSelect< index, vT... >::T & operator [] ( const size_t
index ) const
{
static_assert(!(index > VarTypeNav< vT... >::Count ), "Index
out of bounds");
const char * pThisChars = (const char *) this;
return *(
(const VarTypeSelect< index, vT... >::T *)
pThisChars[ VarTypeSelect< index, vT...
>::Offset ]));
}
};

int main() {
Tuple< size_t, char * > x; /* = { 32, new char[32] }; *//* ? */
x[0] = 32;
x[1] = new char[32];
x[1][31] = 0;
return (int) &x[1][0] != 0;
}


-- 


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