date:20090813

[Bug middle-end/40194] fortran rules for optimizing

2009-08-13 Thread jv244 at cam dot ac dot uk



--- Comment #8 from jv244 at cam dot ac dot uk  2009-08-13 07:23 ---
Michael,

this is somewhat related to your 'restrict-for-fortran-patch'

http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00610.html

do you think it also fixes the issue here ?


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

 CC||matz at suse dot de


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

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

2009-08-13 Thread abel at gcc dot gnu dot org



--- Comment #4 from abel at gcc dot gnu dot org  2009-08-13 08:10 ---
Subject: Bug 41033

Author: abel
Date: Thu Aug 13 08:10:21 2009
New Revision: 150714

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

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

2009-08-13  Richard Guenther  

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


Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr41033.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/alias.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

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

2009-08-13 Thread abel at gcc dot gnu dot org



--- Comment #5 from abel at gcc dot gnu dot org  2009-08-13 08:12 ---
Fixed in trunk, 4.3 and 4.4.


-- 

abel at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

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

2009-08-13 Thread rguenth at gcc dot gnu dot org

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-08-13 08:19 ---
Subject: Bug 41047

Author: rguenth
Date: Thu Aug 13 08:19:10 2009
New Revision: 150715

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

PR middle-end/41047
* tree-ssa-ccp.c (ccp_fold): When folding pointer additions
use the constant pointer type.
* gimplify.c (canonicalize_addr_expr): Canonicalize independent
of CV qualifiers on the target pointer type.
* tree-ssa.c (useless_type_conversion_p): Move incomplete pointer
conversion check before restrict check.

* gcc.dg/tree-ssa/ssa-ccp-27.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ccp-27.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c
trunk/gcc/tree-ssa.c

-- 

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

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

2009-08-13 Thread rguenth at gcc dot gnu dot org



--- Comment #8 from rguenth at gcc dot gnu dot org  2009-08-13 08:38 ---
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=41047

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

2009-08-13 Thread rguenth at gcc dot gnu dot org



--- Comment #3 from rguenth at gcc dot gnu dot org  2009-08-13 08:42 ---
EDG rejects it as well:

t.C(12): error #453: protected function "foo::foo(int)" (declared at line 5) is
not accessible through a "foo" pointer or object
new (this) foo(5);
  ^

compilation aborted for t.C (code 2)


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/41053] internal compiler error: in emit_swap_insn, at reg-stack.c:827

2009-08-13 Thread rguenth at gcc dot gnu dot org



-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c/41052] ICE: verify_gimple failed when using -combine

2009-08-13 Thread rguenth at gcc dot gnu dot org



--- Comment #2 from rguenth at gcc dot gnu dot org  2009-08-13 08:47 ---
LTO gets this right.  It will work with --disable-checking, but eventually
miscompile because you will have two struct s which will get two different
alias-sets.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-checking, ice-on-valid-
   ||code
   Last reconfirmed|-00-00 00:00:00 |2009-08-13 08:47:30
   date||


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

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

2009-08-13 Thread rguenth at gcc dot gnu dot org



--- Comment #9 from rguenth at gcc dot gnu dot org  2009-08-13 08:56 ---
>From a look at the sources it seems that _M_x is at offset zero.


-- 


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

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

2009-08-13 Thread jv244 at cam dot ac dot uk



--- Comment #10 from jv244 at cam dot ac dot uk  2009-08-13 09:13 ---
(In reply to comment #9)

I believe there are at least two important independent issues. One is the fact
that the compiler ignores INTENT(IN) and similarly issues (see also PR 40194).
This holds for general variables. Loop variables have an even stronger
property, that it doesn't even matter if an INTENT is present.


-- 


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

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

2009-08-13 Thread redi at gcc dot gnu dot org



--- Comment #4 from redi at gcc dot gnu dot org  2009-08-13 10:31 ---
(In reply to comment #1)
> It cannot be as it is only undefined behavior and the C++ (and C standard by 
> the way) says that 
> undefined behavior cannot be an error only a warning.

I don't know about C, but C++ says:

"permissible undefined behavior ranges from ignoring the situation completely
with unpredictable results, to behaving during translation or program execution
in a documented manner characteristic of the environment (with or without
the issuance of a diagnostic message), to terminating a translation or
execution (with the issuance of a diagnostic message)." [defns.undefined]

So it is permissible to terminate translation and issue a diagnostic.


-- 


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

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

2009-08-13 Thread redi at gcc dot gnu dot org



--- Comment #4 from redi at gcc dot gnu dot org  2009-08-13 10:59 ---
(In reply to comment #2)
> Well, if the call is on foo then surely a foo can call; its own methods,

Yes, a foo can call its own methods, but a bar can only call them through a bar
object, not on an object with static type foo.  i.e. bar only has access to the
protected members of a foo that is a sub-object of a bar, and not otherwise.

> 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.

The call is not on a bar, it's on a foo.

Consider:

class foo
{
protected:
int i;
};

class bar : public foo
{
public:
void f()
{
this->i; // OK
foo().i; // protected
static_cast(this)->i;  // protected
}
};

This is the same situation as your testcase, bar is trying to access protected
members of a foo without going through a bar.


-- 


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

[Bug fortran/40995] [4.5 Regression] Spurious "Type specified for intrinsic function...ignored" message

2009-08-13 Thread janus at gcc dot gnu dot org

--- Comment #7 from janus at gcc dot gnu dot org  2009-08-13 11:16 ---
Subject: Bug 40995

Author: janus
Date: Thu Aug 13 11:16:16 2009
New Revision: 150716

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150716
Log:
2009-08-13  Janus Weil  

PR fortran/40995
* resolve.c (resolve_symbol): Move some checking code to
resolve_intrinsic, and call this from here.
(resolve_intrinsic): Some checking code moved here from resolve_symbol.
Make sure each intrinsic is only resolved once.

2009-08-13  Janus Weil  

PR fortran/40995
* gfortran.dg/intrinsic_4.f90: New.
* gfortran.dg/intrinsic_subroutine.f90: An error message moved to a
different line.

Added:
trunk/gcc/testsuite/gfortran.dg/intrinsic_4.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/intrinsic_subroutine.f90

-- 

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

[Bug fortran/40995] [4.5 Regression] Spurious "Type specified for intrinsic function...ignored" message

2009-08-13 Thread janus at gcc dot gnu dot org



--- Comment #8 from janus at gcc dot gnu dot org  2009-08-13 11:20 ---
Fixed with r150716. Closing.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

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

2009-08-13 Thread irar at il dot ibm dot com



--- Comment #10 from irar at il dot ibm dot com  2009-08-13 11:34 ---
Reduced testcase:

#include 
#include 

#define N 4

long int a[N];
int main ()
{
  int k;

  for (k = 0; k < N; ++k)
a[k] = a[k] != 5 ? 12 : 10;

  for (k = 0; k < N; ++k)
printf ("%u ", a[k]);

  printf ("\n");

  return 0;
}

%gcc -O3 t.c
% ./a.out
0 0 0 0

%gcc -O2 t.c
% ./a.out
12 12 12 12

If the type of 'a' is int, there is no problem. The vectorizer produces almost
the same code in both cases (except for number of iterations and types).
I am attaching the assembly for int and long int versions.

Ira


-- 


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

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

2009-08-13 Thread irar at il dot ibm dot com



--- Comment #11 from irar at il dot ibm dot com  2009-08-13 11:36 ---
Created an attachment (id=18350)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18350&action=view)
The assembly for the long int version (wrong code)


-- 


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

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

2009-08-13 Thread irar at il dot ibm dot com



--- Comment #12 from irar at il dot ibm dot com  2009-08-13 11:37 ---
Created an attachment (id=18351)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18351&action=view)
The assembly for the int version (correct)


-- 


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

[Bug middle-end/40194] fortran rules for optimizing

2009-08-13 Thread matz at gcc dot gnu dot org



--- Comment #9 from matz at gcc dot gnu dot org  2009-08-13 12:16 ---
It is indeed somewhat related, but currently the patchset doesn't help here.
The first issue is, that I create new types with unconflicting alias sets
only for global variables, not local ones (as I1 is in this case).  I believe
I can change this meanwhile (the restriction came from earlier versions of
the patch).  But even if this is fixed we can't figure out the difference
between INTENT(IN) and INTENT(OUT), i.e. even then we still believe that 
I1 can possibly be changed by the call.

We have three ways out of this:
1) make the frontend not pass INTENT(IN) parameters by reference, maybe
   at least for scalars.  That would be the preferred way, but unfortunately
   this probably would break a lot of code assuming such calling convention
   especially when interfacing with C code :-/
2) invent a new attribute that we can attach to the individual arguments
   that would indicate non-clobbering via this reference
3) find a combination of existing things (DECL_BY_REFERENCE/TREE_READONLY/etc)
   that could be used by the middle end to conclude non-clobbering.
   Something like a const reference comes to mind, but unfortunately (the
   middle-end coming mostly from the C/C++ side) we don't conclude many
   interesting things about const refs/pointers.


-- 


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

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

2009-08-13 Thread joseph at codesourcery dot com

--- Comment #5 from joseph at codesourcery dot com  2009-08-13 12:23 ---
Subject: Re:  Warning "cannot pass objects of non-POD type"
 should be an error

On Thu, 13 Aug 2009, redi at gcc dot gnu dot org wrote:

> I don't know about C, but C++ says:
> 
> "permissible undefined behavior ranges from ignoring the situation completely
> with unpredictable results, to behaving during translation or program 
> execution
> in a documented manner characteristic of the environment (with or without
> the issuance of a diagnostic message), to terminating a translation or
> execution (with the issuance of a diagnostic message)." [defns.undefined]
> 
> So it is permissible to terminate translation and issue a diagnostic.

You have to read the relevant standard text carefully to determine whether 
it is the program that is undefined, or a particular execution of the 
program, in this particular instance of undefined behavior.  If the 
undefinedness is a property of the program (for example, ODR violation), 
translation may be terminated.  If the undefinedness is a property of a 
particular execution of the program (for example, signed integer 
overflow), translation may not be terminated unless all possible 
executions of the program exhibit that undefined behavior.

-- 

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

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

2009-08-13 Thread rguenth at gcc dot gnu dot org



--- Comment #13 from rguenth at gcc dot gnu dot org  2009-08-13 12:25 
---
Err, the expansion is already completely bogus:

;; *vect_pa.50 = [vec_cond_expr]  VEC_COND_EXPR < *vect_pa.44 != { 5, 5 } , {
12, 12 } , { 10, 10 } > ;

(insn 7 6 8 t.c:12 (set (reg:V2DI 63)
(mem/u/c/i:V2DI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [2 S16 A128]))
-1 (expr_list:REG_EQUAL (const_vector:V2DI [
(const_int 5 [0x5])
(const_int 5 [0x5])
])
(nil)))

(insn 8 7 9 t.c:12 (set (reg:V2DI 64)
(mem/u/c/i:V2DI (symbol_ref/u:DI ("*.LC1") [flags 0x2]) [2 S16 A128]))
-1 (expr_list:REG_EQUAL (const_vector:V2DI [
(const_int 12 [0xc])
(const_int 12 [0xc])
])
(nil)))

(insn 9 8 10 t.c:12 (set (reg:V2DI 65)
(mem/u/c/i:V2DI (symbol_ref/u:DI ("*.LC2") [flags 0x2]) [2 S16 A128]))
-1 (expr_list:REG_EQUAL (const_vector:V2DI [
(const_int 10 [0xa])
(const_int 10 [0xa])
])
(nil)))

(insn 10 9 0 t.c:12 (set (mem:V2DI (reg/f:DI 58 [ vect_pa.50 ]) [2 S16 A128])
(reg:V2DI 62)) -1 (nil))


so - we load three constants and store the uninitialized reg 62.

Which means the optabs for this case are broken.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||uros at gcc dot gnu dot org
  Component|tree-optimization   |target


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

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

2009-08-13 Thread rguenth at gcc dot gnu dot org



--- Comment #14 from rguenth at gcc dot gnu dot org  2009-08-13 12:32 
---
ix86_expand_int_vcond fails because the operation is not supported with SSE2,
but
gen_vcondv2di doesn't handle the failure, but ignores it.

The vcond patterns are not properly reflecting the restrictions.


-- 


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

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

2009-08-13 Thread redi at gcc dot gnu dot org



--- Comment #6 from redi at gcc dot gnu dot org  2009-08-13 12:51 ---
(In reply to comment #3)
> 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

I don't think the docs do say that.  -Winvalid-offsetof may be related to
non-POD types but is distinct from this error.

(In reply to comment #5)
> You have to read the relevant standard text carefully to determine whether 
> it is the program that is undefined, or a particular execution of the 
> program, in this particular instance of undefined behavior.  If the 
> undefinedness is a property of the program (for example, ODR violation), 
> translation may be terminated.  If the undefinedness is a property of a 
> particular execution of the program (for example, signed integer 
> overflow), translation may not be terminated unless all possible 
> executions of the program exhibit that undefined behavior.

Passing a non-POD class type to a variadic function is a property of the
program, detectable at compile time, so I think it would be conforming to make
it an error (please correct me if I've misunderstood.)

I don't feel strongly about making it always an error, but I disagree that this
request is INVALID because the standard forbids making it an error.  It seems
like a valid enhancement to add a new warning option so this users can choose
to make it an error.


-- 


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

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

2009-08-13 Thread ubizjak at gmail dot com



--- Comment #15 from ubizjak at gmail dot com  2009-08-13 13:02 ---
(In reply to comment #14)

> The vcond patterns are not properly reflecting the restrictions.

Are you sure?

(define_expand "vcond"
  [(set (match_operand:SSEMODEI 0 "register_operand" "")
(if_then_else:SSEMODEI
  (match_operator 3 ""
[(match_operand:SSEMODEI 4 "nonimmediate_operand" "")
 (match_operand:SSEMODEI 5 "nonimmediate_operand" "")])
  (match_operand:SSEMODEI 1 "general_operand" "")
  (match_operand:SSEMODEI 2 "general_operand" "")))]
  "TARGET_SSE2"
{
  if (ix86_expand_int_vcond (operands))
DONE;
  else
FAIL;
})


-- 


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

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

2009-08-13 Thread ubizjak at gmail dot com



--- Comment #16 from ubizjak at gmail dot com  2009-08-13 13:04 ---
Looking into it...


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-08-11 15:24:24 |2009-08-13 13:04:39
   date||


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

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

2009-08-13 Thread rguenther at suse dot de



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

On Thu, 13 Aug 2009, ubizjak at gmail dot com wrote:

> 
> 
> --- Comment #15 from ubizjak at gmail dot com  2009-08-13 13:02 ---
> (In reply to comment #14)
> 
> > The vcond patterns are not properly reflecting the restrictions.
> 
> Are you sure?
> 
> (define_expand "vcond"
>   [(set (match_operand:SSEMODEI 0 "register_operand" "")
> (if_then_else:SSEMODEI
>   (match_operator 3 ""
> [(match_operand:SSEMODEI 4 "nonimmediate_operand" "")
>  (match_operand:SSEMODEI 5 "nonimmediate_operand" "")])
>   (match_operand:SSEMODEI 1 "general_operand" "")
>   (match_operand:SSEMODEI 2 "general_operand" "")))]
>   "TARGET_SSE2"

It says TARGET_SSE2 but vcondv2di is only available with TARGET_SSE4+

Richard.


-- 


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

[Bug c++/41054] New: Cryptic error message when type is not defined.

2009-08-13 Thread tobias dot hahn at ableton dot com

Steps to reproduce:
1. Create a file error.cpp containing

class Foo
{
public:
  Foo* myMethod(Bar bar);
};

2. Compile with 
$ gcc error.cpp

Expected Results:
error.cpp:4: error: type Bar is undefined.

Actual Results:
error.cpp:4: error: expected ; before ( token

Notes:
The error message is wrong and misleading.

Version info:
$ gcc -v -save-temps error.cpp 
i686-apple-darwin9-gcc-4.0.1: gcc: No such file or directory
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5490~1/src/configure --disable-checking
-enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=i686-apple-darwin9 --with-arch=apple --with-tune=generic
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5490)
 /usr/libexec/gcc/i686-apple-darwin9/4.0.1/cc1plus -E -quiet -v -D__DYNAMIC__
error.cpp -fPIC -mmacosx-version-min=10.5.8 -mtune=generic -march=apple
-fpch-preprocess -D__private_extern__=extern -o error.ii
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../../i686-apple-darwin9/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.0.0
 /usr/include/c++/4.0.0/i686-apple-darwin9
 /usr/include/c++/4.0.0/backward
 /usr/lib/gcc/i686-apple-darwin9/4.0.1/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
 /usr/libexec/gcc/i686-apple-darwin9/4.0.1/cc1plus -fpreprocessed error.ii
-fPIC -quiet -dumpbase error.cpp -mmacosx-version-min=10.5.8 -mtune=generic
-march=apple -auxbase error -version -D__private_extern__=extern -o error.s
GNU C++ version 4.0.1 (Apple Inc. build 5490) (i686-apple-darwin9)
compiled by GNU C version 4.0.1 (Apple Inc. build 5490).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d717d63b348495df150b35f29da70e48
error.cpp:4: error: expected ; before ( token


-- 
   Summary: Cryptic error message when type is not defined.
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot hahn at ableton dot com


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

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

2009-08-13 Thread rguenth at gcc dot gnu dot org



--- Comment #11 from rguenth at gcc dot gnu dot org  2009-08-13 13:30 
---
  DO i = 1,10
call bar(i)
  END DO

if bar may not modify i then the frontend can simply communicate that to the
middle-end by doing

  DO i = 1,10
j = i;
call bar (j)
  END DO

likewise if loop bounds are not allowed to be changed (are they?)

  Do i = n,m
...

to
  tmp1 = n
  tmp2 = m
  Do i = tmp1,tmp2
...


-- 


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

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

2009-08-13 Thread ubizjak at gmail dot com



--- Comment #18 from ubizjak at gmail dot com  2009-08-13 13:35 ---
(In reply to comment #17)

> It says TARGET_SSE2 but vcondv2di is only available with TARGET_SSE4+

Yes, but FAIL invalidates complete expansion.


-- 


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

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

2009-08-13 Thread tobi at gcc dot gnu dot org



--- Comment #12 from tobi at gcc dot gnu dot org  2009-08-13 13:39 ---
(In reply to comment #11)
>   DO i = 1,10
> call bar(i)
>   END DO
> 
> if bar may not modify i then the frontend can simply communicate that to the
> middle-end by doing
> 
>   DO i = 1,10
> j = i;
> call bar (j)
>   END DO

That's exactly what Thomas is achieving by adding parentheses.  Thomas, If you
want to tackle something more difficult, I'm willing to do this over the
weekend in order to warm up my knowledge of gfortran's internals.


-- 

tobi at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tobi at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-02-19 16:08:27 |2009-08-13 13:39:23
   date||


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

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

2009-08-13 Thread ubizjak at gmail dot com



--- Comment #19 from ubizjak at gmail dot com  2009-08-13 13:39 ---
(In reply to comment #18)
> (In reply to comment #17)
> 
> > It says TARGET_SSE2 but vcondv2di is only available with TARGET_SSE4+
> 
> Yes, but FAIL invalidates complete expansion.

Oh, I see the problem. Middle end doesn't handle FAIL in this case, just checks
the presence of the pattern.

Oh, well... I'll split the pattern into two parts.


-- 


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

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

2009-08-13 Thread m_albert137 at yahoo dot com



--- Comment #20 from m_albert137 at yahoo dot com  2009-08-13 14:27 ---
Please let me say that I am deeply impressed by both the technical expertise of
those who have helped with the issue that I raised and the willingness to
respond so quickly.

I thank you and consider myself to be in debt to you.

Sincerely,
 Mike Albert


-- 


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

[Bug c/41055] New: libgcc functions and -mregparm don't work well together

2009-08-13 Thread patrick dot georgi at coresystems dot de

When building code with -mregparm=x on i?86 which uses libgcc functions (eg.
udivdi3), the calls to the libgcc functions use the calling convention as given
by mregparm, even though libgcc is internal to the compiler (and the user has
no ultimate control about when it is used).

Adding the compiler-native calling convention as regparm attribute to all calls
that are synthesized by the compiler might fix the problem.

The following shell script exhibits the problem.

cat > test.c << EOF
int main() {
 long long a= 40;
 return a / 43937;
}
EOF

gcc -S test.c
mv test.s test.default.s

gcc -mregparm=3 -S test.c
mv test.s test.mregparm3.s

diff -u test.default.s test.mregparm3.s
exit 0
# there should be no difference in the calling convention
# as __divdi3 is taken from libgcc, but I get the result:
--- test.default.s  Do. Aug 13 15:47:28 2009
+++ test.mregparm3.sDo. Aug 13 15:47:28 2009
 -18,10 +18,9 @@
movl$0, -4(%ebp)
movl-8(%ebp), %eax
movl-4(%ebp), %edx
+   subl$8, %esp
pushl   $0
pushl   $43937
-   pushl   %edx
-   pushl   %eax
call__divdi3
addl$16, %esp
leave


-- 
   Summary: libgcc functions and -mregparm don't work well together
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: patrick dot georgi at coresystems dot de


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

[Bug c/41055] libgcc functions and -mregparm don't work well together

2009-08-13 Thread rguenth at gcc dot gnu dot org



--- Comment #1 from rguenth at gcc dot gnu dot org  2009-08-13 14:58 ---
-mregparm changes the ABI, you have to rebuild libgcc with -mregparm to be
able to use it.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/41056] New: Wrong code for polyhedron test linpk.f90 compiled with -fwholefile at -O3

2009-08-13 Thread dominiq at lps dot ens dot fr

At revision 150716 the polyhedron test linpk.f90 compiled with -fwholefile at
-O3 does not give the right results:

[ibook-dhum] lin/test% gfc -O3 linpk.f90
[ibook-dhum] lin/test% time a.out 
 norm. resid  resid   machep x(1)  x(n)
  2.50952975D+01  2.78588264D-11  2.22044605D-16  1.D+00 
1.D+00
27.756u 0.194s 0:28.12 99.3%0+0k 0+0io 25pf+0w
[ibook-dhum] lin/test% gfc -O3 -fwhole-file linpk.f90
[ibook-dhum] lin/test% time a.out
 norm. resid  resid   machep x(1)  x(n)
 NaN  0.D+00  2.22044605D-16 NaN
NaN
4.808u 0.071s 0:04.89 99.5% 0+0k 0+0io 0pf+0w
[ibook-dhum] lin/test% gfc -O2 -fwhole-file linpk.f90
[ibook-dhum] lin/test% time a.out
 norm. resid  resid   machep x(1)  x(n)
  2.50952975D+01  2.78588264D-11  2.22044605D-16  1.D+00 
1.D+00
27.807u 0.232s 0:28.22 99.3%0+0k 0+0io 0pf+0w
[ibook-dhum] lin/test% gfc -m64 -O3 -fwhole-file linpk.f90
[ibook-dhum] lin/test% time a.out
 norm. resid  resid   machep x(1)  x(n)
 NaN  0.D+00  2.22044605D-16 NaN
NaN
5.016u 0.068s 0:05.18 97.8% 0+0k 0+0io 29pf+0w


-- 
   Summary: Wrong code for polyhedron test linpk.f90 compiled with -
fwholefile at -O3
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: major
  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=41056

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

2009-08-13 Thread howarth at nitro dot med dot uc dot edu



--- Comment #12 from howarth at nitro dot med dot uc dot edu  2009-08-13 
15:05 ---
Sebastian,
   Is there any other debug information, I can get for you to help pin this bug
down?


-- 


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

[Bug c/41055] libgcc functions and -mregparm don't work well together

2009-08-13 Thread stepan at coresystems dot de



--- Comment #2 from stepan at coresystems dot de  2009-08-13 15:08 ---
So we have to rebuild parts of the compiler in order to get a working compiler,
depending on the compiler flags we use? That sounds pretty broken to me. In my
opinion, since -mregparm is a gcc run time option, not a compile time option,
the compiler should provide libgcc for every possible ABI and choose among
those.

Closing this bug is especially weird since #12081 implies that building the
compiler with -mregparm=3 is broken.


-- 


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

[Bug fortran/41056] Wrong code for polyhedron test linpk.f90 compiled with -fwholefile at -O3

2009-08-13 Thread dominiq at lps dot ens dot fr



--- Comment #1 from dominiq at lps dot ens dot fr  2009-08-13 15:09 ---
Note that the right code was obtained with the patch in
http://gcc.gnu.org/ml/fortran/2009-07/msg00232.html.

With this patch compiling aermod.f90 gave an ICE:

[ibook-dhum] lin/test% time gfc aermod.f90 -m64 -O3 -finline-limit=600
-fwhole-file
aermod.f90: In function 'anyavg_.clone.17':
aermod.f90:21763:0: error: type mismatch between an SSA_NAME and its symbol
while verifying SSA_NAME hts_1 in statement
hts_1 = (real(kind=4)[0:D.11239] *) &gridht;
aermod.f90:21763:0: error: type mismatch between an SSA_NAME and its symbol
aermod.f90:21763:0: error: in statement
hts_1 = (real(kind=4)[0:D.11239] *) &gridht;
aermod.f90:21763:0: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
35.524u 1.639s 0:37.38 99.3%0+0k 0+18io 40pf+0w


-- 

dominiq at lps dot ens dot fr changed:

   What|Removed |Added

 CC||pault at gcc dot gnu dot org


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

[Bug c/41055] libgcc functions and -mregparm don't work well together

2009-08-13 Thread patrick dot georgi at coresystems dot de



--- Comment #3 from patrick dot georgi at coresystems dot de  2009-08-13 
15:10 ---
(In reply to comment #1)
> -mregparm changes the ABI, you have to rebuild libgcc with -mregparm to be
> able to use it.
> 

I agree with that notion for general purpose libraries as used by the user. But
libgcc is an implementation artefact of GCC. I'd prefer not to use it, but GCC
forces me to.

If I use __divdi3 myself, GCC can expect that I fix up the call myself (using
some __attribute__((regparm))), but if GCC uses it, I think it's not to much to
ask for it to fix it up itself (as I don't have the means to do so, short of
rewriting assembler code)

I see three good solutions:
1. GCC calls its own libgcc calls in a proper way (and it should be able to do
so, if I as a user can change calling conventions per function call)
2. It refuses to use libgcc with mregparm, as it will break.
3. GCC supports multiple libgccs, choosing the right one automatically.

My guess is that solution 1 is the easiest. Hacks like
http://trac.nchc.org.tw/grid/browser/gpfs_3.1_ker2.6.20/lpp/mmfs/src/gpl-linux/mmwrap.c
shouldn't be necessary.


-- 

patrick dot georgi at coresystems dot de changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

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

2009-08-13 Thread ubizjak at gmail dot com



--- Comment #21 from ubizjak at gmail dot com  2009-08-13 15:26 ---
Created an attachment (id=18353)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18353&action=view)
patch to fix the failure

I'm testing the attached patch.

There is a little complication w.r.t to V2DI handling. Since vcond pattern
assumes that we have full set of comparisons, we cannot enable V2DI on
TARGET_SSE4.1 because SSE4.1 handles only EQ comparison. SSE4.2 and SSE5 handle
full set, so V2DI vcond pattern can again be enabled on these targets.


-- 


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

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

2009-08-13 Thread spop at gcc dot gnu dot org



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

Could you try this patch on top of trunk?
If this fails with the gcc_assert, then probably the bug is in PPL.

Sebastian


--- Comment #14 from spop at gcc dot gnu dot org  2009-08-13 15:28 ---
Created an attachment (id=18354)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18354&action=view)


-- 


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

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

2009-08-13 Thread dominiq at lps dot ens dot fr



--- Comment #15 from dominiq at lps dot ens dot fr  2009-08-13 15:30 ---
On *-apple-darwin9 (revision 150716) I do not see the ICEs:

[ibook-dhum] lin/test% time gfc -O2 -fgraphite-identity -floop-strip-mine
ac.f90
7.181u 0.151s 0:07.53 97.3% 0+0k 0+12io 3pf+0w
[ibook-dhum] lin/test% time gfc -O2 -fgraphite-identity -floop-strip-mine
aermod.f90
130.702u 3.544s 2:14.83 99.5%   0+0k 0+34io 12pf+0w
[ibook-dhum] lin/test% time gfc -O2 -fgraphite-identity -floop-strip-mine
air.f90
12.748u 0.251s 0:13.25 98.0%0+0k 0+13io 3pf+0w
[ibook-dhum] lin/test% time gfc -O2 -fgraphite-identity -floop-strip-mine
capacita.f90
2.426u 0.081s 0:02.65 94.3% 0+0k 2+4io 19pf+0w
[ibook-dhum] lin/test% time gfc -O2 -fgraphite-identity -floop-strip-mine
channel.f90
2.798u 0.086s 0:02.94 97.6% 0+0k 0+9io 0pf+0w
[ibook-dhum] lin/test% time gfc -O2 -fgraphite-identity -floop-strip-mine
doduc.f90
8.552u 0.258s 0:08.92 98.6% 0+0k 0+13io 3pf+0w
[ibook-dhum] lin/test% time gfc -O2 -fgraphite-identity -floop-strip-mine
fatigue.f90
7.047u 0.187s 0:07.40 97.5% 0+0k 3+22io 3pf+0w
[ibook-dhum] lin/test% time gfc -O2 -fgraphite-identity -floop-strip-mine
gas_dyn.f90
3.010u 0.121s 0:03.24 96.6% 0+0k 0+4io 7pf+0w
[ibook-dhum] lin/test% time gfc -O2 -fgraphite-identity -floop-strip-mine
induct.f90
99.419u 0.880s 1:40.68 99.6%0+0k 0+21io 1pf+0w
[ibook-dhum] lin/test% time gfc -O2 -fgraphite-identity -floop-strip-mine
linpk.f90
37.233u 0.295s 0:37.87 99.0%0+0k 0+6io 0pf+0w
[ibook-dhum] lin/test% time gfc -O2 -fgraphite-identity -floop-strip-mine
mdbx.f90
2.870u 0.109s 0:03.01 98.6% 0+0k 0+9io 0pf+0w
[ibook-dhum] lin/test% time gfc -O2 -fgraphite-identity -floop-strip-mine
nf.f90
3.999u 0.086s 0:04.11 99.0% 0+0k 0+2io 0pf+0w
[ibook-dhum] lin/test% time gfc -O2 -fgraphite-identity -floop-strip-mine
protein.f90
5.646u 0.264s 0:06.11 96.5% 0+0k 2+23io 2pf+0w
[ibook-dhum] lin/test% time gfc -O2 -fgraphite-identity -floop-strip-mine
rnflow.f90
9.138u 0.196s 0:09.71 95.9% 0+0k 0+11io 1pf+0w
[ibook-dhum] lin/test% time gfc -O2 -fgraphite-identity -floop-strip-mine
test_fpu.f90
7.993u 0.152s 0:08.26 98.5% 0+0k 1+18io 1pf+0w
[ibook-dhum] lin/test% time gfc -O2 -fgraphite-identity -floop-strip-mine
tfft.f90
2.821u 0.057s 0:02.94 97.6% 0+0k 0+1io 1pf+0w

[ibook-dhum] lin/test% time gfc -m64 -O2 -fgraphite-identity -floop-strip-mine
ac.f90
7.180u 0.152s 0:07.49 97.8% 0+0k 0+0io 0pf+0w
[ibook-dhum] lin/test% time gfc -m64 -O2 -fgraphite-identity -floop-strip-mine
aermod.f90
141.691u 4.258s 2:28.96 97.9%   0+0k 0+40io 10pf+0w
[ibook-dhum] lin/test% time gfc -m64 -O2 -fgraphite-identity -floop-strip-mine
air.f90
9.735u 0.259s 0:10.52 94.8% 0+0k 0+15io 0pf+0w
[ibook-dhum] lin/test% time gfc -m64 -O2 -fgraphite-identity -floop-strip-mine
capacita.f90
2.429u 0.085s 0:02.77 90.2% 0+0k 1+10io 0pf+0w
[ibook-dhum] lin/test% time gfc -m64 -O2 -fgraphite-identity -floop-strip-mine
channel.f90
2.747u 0.086s 0:02.87 98.2% 0+0k 0+15io 1pf+0w
[ibook-dhum] lin/test% time gfc -m64 -O2 -fgraphite-identity -floop-strip-mine
doduc.f90
8.166u 0.318s 0:09.47 89.4% 0+0k 0+17io 1pf+0w
[ibook-dhum] lin/test% time gfc -m64 -O2 -fgraphite-identity -floop-strip-mine
fatigue.f90
6.978u 0.183s 0:07.83 91.3% 0+0k 0+13io 0pf+0w
[ibook-dhum] lin/test% time gfc -m64 -O2 -fgraphite-identity -floop-strip-mine
gas_dyn.f90
3.008u 0.119s 0:03.15 98.7% 0+0k 0+17io 0pf+0w
[ibook-dhum] lin/test% time gfc -m64 -O2 -fgraphite-identity -floop-strip-mine
induct.f90
29.788u 0.471s 0:30.57 98.9%0+0k 0+20io 0pf+0w
[ibook-dhum] lin/test% time gfc -m64 -O2 -fgraphite-identity -floop-strip-mine
linpk.f90
31.518u 0.200s 0:32.15 98.6%0+0k 0+11io 0pf+0w
[ibook-dhum] lin/test% time gfc -m64 -O2 -fgraphite-identity -floop-strip-mine
mdbx.f90
2.746u 0.110s 0:02.95 96.6% 0+0k 0+11io 0pf+0w
[ibook-dhum] lin/test% time gfc -m64 -O2 -fgraphite-identity -floop-strip-mine
nf.f90
4.237u 0.084s 0:04.41 97.7% 0+0k 0+0io 0pf+0w
[ibook-dhum] lin/test% time gfc -m64 -O2 -fgraphite-identity -floop-strip-mine
protein.f90
5.807u 0.251s 0:06.13 98.6% 0+0k 0+16io 0pf+0w
[ibook-dhum] lin/test% time gfc -m64 -O2 -fgraphite-identity -floop-strip-mine
rnflow.f90
9.182u 0.190s 0:09.85 95.1% 0+0k 0+14io 0pf+0w
[ibook-dhum] lin/test% time gfc -m64 -O2 -fgraphite-identity -floop-strip-mine
test_fpu.f90
8.251u 0.167s 0:08.48 99.1% 0+0k 0+13io 0pf+0w
[ibook-dhum] lin/test% time gfc -m64 -O2 -fgraphite-identity -floop-strip-mine
tfft.f90
2.834u 0.062s 0:02.92 98.9% 0+0k 0+19io 0pf+0w

Note that I used the following config:

Configured with: ../gcc-4.5-work/configure --prefix=/opt/gcc/gcc4.5w
--mandir=/opt/gcc/gcc4.5w/share/man --infodir=/opt/gcc/gcc4.5w/share/info
--build=i686-apple-darwin9 --enable-languages=c,c++,fortran,objc,obj-c++,java
--with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-cloog=/sw
--with-ppl=/sw --with-mpc=/opt/mpc/build


-

[Bug c/41055] libgcc functions and -mregparm don't work well together

2009-08-13 Thread matz at gcc dot gnu dot org



--- Comment #4 from matz at gcc dot gnu dot org  2009-08-13 15:36 ---
I agree with the reporters.  libgcc isn't some random library, GCC should call
it correctly even in the presence of -mregparm.


-- 


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

[Bug lto/41032] Wrong code from TBAA because not completing structs during merging

2009-08-13 Thread rguenth at gcc dot gnu dot org

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-08-13 15:44 ---
Subject: Bug 41032

Author: rguenth
Date: Thu Aug 13 15:44:01 2009
New Revision: 150719

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

PR lto/41032
* tree.c (free_lang_data): NULL the types_compatible_p langhook.
* gimple.c (gtc_visited): Global type compatibility hashtable.
(compare_field_offset): New helper function.
(gimple_compare_types): Fold into ...
(gimple_types_compatible_p): ... here.  Types with differing
hash values are not compatible.  Adjust function now that it
is no longer used as types_compatible_p langhook.  Complete
incomplete pointer targets.
(iterative_hash_type_name): New helper function.
(iterative_hash_gimple_type): Do not hash type sizes.  Do not
recurse into aggregate pointer targets.  Properly hash
complex and vector types.  Hash the name of record types.
(print_gimple_types_stats): Print stats of gtc_visited.
* lto-symtab.c (lto_merge_qualifiers): Remove.
(lto_merge_types): Likewise.
(merge_incomplete_and_complete_type): New helper function.
(maybe_merge_incomplete_and_complete_type): Likewise.
(lto_symtab_compatible): Remove do_warn arg.  Complete types
during decl merging.  Forcefully merge more types than
elsewhere.  Do not compare DECL_MODE.
(lto_symtab_prevailing_decl): Use gimple_types_compatible_p, not
lto_symtab_compatible for finding the decl we merged with.

lto/
* lto-lang.c (LANG_HOOKS_TYPES_COMPATIBLE_P): Define to NULL.

* gcc.dg/lto/20090812_0.c: New testcase.
* gcc.dg/lto/20090812_1.c: Likewise.

Added:
branches/lto/gcc/testsuite/gcc.dg/lto/20090812_0.c
branches/lto/gcc/testsuite/gcc.dg/lto/20090812_1.c
Modified:
branches/lto/gcc/ChangeLog.lto
branches/lto/gcc/gimple.c
branches/lto/gcc/lto-symtab.c
branches/lto/gcc/lto/ChangeLog
branches/lto/gcc/lto/lto-lang.c
branches/lto/gcc/testsuite/ChangeLog.lto
branches/lto/gcc/tree.c

-- 

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

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

2009-08-13 Thread rahul at icerasemi dot com



--- Comment #4 from rahul at icerasemi dot com  2009-08-13 15:46 ---
Confirmed. Introducing loop header copy for Os, resolves the problem.
On our port, this not only helps move the invariant load outside the loop, but
also correctly uses an auto-increment address mode via the AutoInc patches we
use. Other examples also confirm that the header copying enables more induction
variables to be identified and hence post-increment opportunities.

Does better loop analysis and hence potential for further optimizations
outweigh the cost of copying the loop header? It would be ideal to relax the
loop header copy predicate for Os and select an appropriate threshold,
currently set at 20 insn, a lower value to start with perhaps.


-- 


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

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

2009-08-13 Thread rguenther at suse dot de



--- Comment #5 from rguenther at suse dot de  2009-08-13 15:58 ---
Subject: Re:  invariant address load inside loop
 with -Os.

On Thu, 13 Aug 2009, rahul at icerasemi dot com wrote:

> --- Comment #4 from rahul at icerasemi dot com  2009-08-13 15:46 ---
> Confirmed. Introducing loop header copy for Os, resolves the problem.
> On our port, this not only helps move the invariant load outside the loop, but
> also correctly uses an auto-increment address mode via the AutoInc patches we
> use. Other examples also confirm that the header copying enables more 
> induction
> variables to be identified and hence post-increment opportunities.
> 
> Does better loop analysis and hence potential for further optimizations
> outweigh the cost of copying the loop header? It would be ideal to relax the
> loop header copy predicate for Os and select an appropriate threshold,
> currently set at 20 insn, a lower value to start with perhaps.

Experimenting with that would be certainly useful.

Richard.


-- 


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

[Bug lto/41058] New: FAIL: hash_data_map_rand

2009-08-13 Thread rguenth at gcc dot gnu dot org

segfaults with -O2 -flto, doesn't with -O2.


-- 
   Summary: FAIL: hash_data_map_rand
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug lto/41058] FAIL: hash_data_map_rand

2009-08-13 Thread rguenth at gcc dot gnu dot org



--- Comment #1 from rguenth at gcc dot gnu dot org  2009-08-13 16:05 ---
Created an attachment (id=18355)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18355&action=view)
testcase

somewhat reduced testcase.  Manual love and analyzing necessary.


-- 


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

[Bug target/41019] [4.3/4.4/4.5 Regression] Vector conditional move produces wrong code with -O3.

2009-08-13 Thread ubizjak at gmail dot com



--- Comment #22 from ubizjak at gmail dot com  2009-08-13 16:20 ---
Also fails on 4.3.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC|uros at gcc dot gnu dot org |
  Known to fail|4.4.1 4.5.0 |4.3.4 4.4.1 4.5.0
Summary|Variate_generator with  |[4.3/4.4/4.5 Regression]
   |mt19937 and |Vector conditional move
   |normal_distribution produces|produces wrong code with -
   |wrong sequence for "-O3".   |O3.
   Target Milestone|--- |4.3.5


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

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

2009-08-13 Thread janis at gcc dot gnu dot org

--- Comment #1 from janis at gcc dot gnu dot org  2009-08-13 16:54 ---
Subject: Bug 41046

Author: janis
Date: Thu Aug 13 16:54:28 2009
New Revision: 150720

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150720
Log:
PR c/41046
* decContext.c (decContextTestEndian): Call printf only if DECCHECK.
* decCommon.c ( decFloatShow): Define function only for DECCHECK
or DECTRACE.

Modified:
trunk/libdecnumber/ChangeLog
trunk/libdecnumber/decCommon.c
trunk/libdecnumber/decContext.c

-- 

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

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

2009-08-13 Thread howarth at nitro dot med dot uc dot edu



--- Comment #16 from howarth at nitro dot med dot uc dot edu  2009-08-13 
16:55 ---
Dominique,
 Could you try a build for x86_64-apple-darwin9? I would expect there could
be a big difference in the bugs tickled since the compiler is 64-bit code in
that case.


-- 


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

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

2009-08-13 Thread janis at gcc dot gnu dot org

--- Comment #2 from janis at gcc dot gnu dot org  2009-08-13 16:58 ---
Subject: Bug 41046

Author: janis
Date: Thu Aug 13 16:58:06 2009
New Revision: 150721

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150721
Log:
PR c/41046
* decCommon.c ( decFloatShow): Define function only for DECCHECK
or DECTRACE.

Modified:
branches/gcc-4_4-branch/libdecnumber/ChangeLog
branches/gcc-4_4-branch/libdecnumber/decCommon.c

-- 

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

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

2009-08-13 Thread janis at gcc dot gnu dot org

--- Comment #3 from janis at gcc dot gnu dot org  2009-08-13 17:01 ---
Subject: Bug 41046

Author: janis
Date: Thu Aug 13 17:00:49 2009
New Revision: 150722

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150722
Log:
PR c/41046
* decCommon.c ( decFloatShow): Define function only for DECCHECK
or DECTRACE.

Modified:
branches/gcc-4_3-branch/libdecnumber/ChangeLog
branches/gcc-4_3-branch/libdecnumber/decCommon.c

-- 

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

[Bug fortran/41059] New: -fwhole-file and error messages

2009-08-13 Thread dominiq at lps dot ens dot fr

At revision 150706 -fwhole-file change the errors messages in an unexpected
(non necessary?) way.
So far I have analyzed two cases:

(1) the order of messages is changed as in the following test

program main
  integer,parameter :: k = selected_int_kind (range (0_8) + 1)
  integer(kind=k), dimension(3) :: ik

  ik = (/ -1, 1, -3 /)
  call sub_ik(ik(1:3:2))
  if (any(ik /= (/ 3, 1, 2 /))) call abort
end program main

subroutine sub_ik(i)
  integer,parameter :: k = selected_int_kind (range (0_8) + 1)
  integer(kind=k), dimension(2) :: i
  if (i(1) /= -1) call abort
  if (i(2) /= -3) call abort
  i(1) = 3
  i(2) = 2
end subroutine sub_ik

The difference between wo/with -fwhole-file is:

--- int_no  2009-07-28 13:09:04.0 +0200
+++ int_wf  2009-07-28 13:09:19.0 +0200
@@ -8,11 +8,6 @@ internal_pack_3_db.f90:11.16:
   call sub_ik(ik(1:3:2))
 1
 Error: Syntax error in argument list at (1)
-internal_pack_3_db.f90:10.2:
-
-  ik = (/ -1, 1, -3 /)
-  1
-Error: Incompatible ranks 0 and 1 in assignment at (1)
 internal_pack_3_db.f90:17.16:

   integer(kind=k), dimension(2) :: i
@@ -28,3 +23,8 @@ internal_pack_3_db.f90:21.3:
   i(2) = 2
1
 Error: 'i' at (1) is not a variable
+internal_pack_3_db.f90:10.2:
+
+  ik = (/ -1, 1, -3 /)
+  1
+Error: Incompatible ranks 0 and 1 in assignment at (1)

This is a minor inconvenience when I compare the results of my test suite as it
give spurious differences.

(2) Some messages are repeated instead of different messages given without
-fwhole-file. This explain for instance the failure of
gcc/testsuite/gfortran.dg/entry_17.f90:

@@ -3,10 +3,10 @@
   character(*) :: bar3 ! { dg-warning "Obsolescent feature" }
   1
 Warning: Obsolescent feature: CHARACTER(*) function 'bar3' at (1)
-/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/entry_17.f90:27.57:
+/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/entry_17.f90:20:

-end function test3 ! { dg-warning "Obsolescent feature" }
- 1
+function test3() ! { dg-warning "Obsolescent feature" }
+1
 Warning: Obsolescent feature: CHARACTER(*) function 'master.2.test3' at (1)
 /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/entry_17.f90:20:

@@ -33,10 +33,10 @@ Warning: Extension: Function test5 at (1
 function test6() ! { dg-warning "Obsolescent feature|returning variables of
dif
 1
 Warning: Extension: Function test6 at (1) with entries returning variables of
different string lengths
-/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/entry_17.f90:55.57:
+/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/entry_17.f90:48:

-end function test6 ! { dg-warning "Obsolescent feature" }
- 1
+function test6() ! { dg-warning "Obsolescent feature|returning variables of
dif
+1
 Warning: Obsolescent feature: CHARACTER(*) function 'master.5.test6' at (1)
 /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/entry_17.f90:48:

Note that -fwhole-file fixes pr37744 (see comment #5).


-- 
   Summary: -fwhole-file and error messages
   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=41059

[Bug fortran/37744] ICE-on-invalid with ISO_C_BINDING and TYPEs

2009-08-13 Thread dominiq at lps dot ens dot fr



--- Comment #5 from dominiq at lps dot ens dot fr  2009-08-13 17:05 ---
At revision 150706 the ICEs go away on *-apple-darwin9 with -fwhole-file (see
pr41059).


-- 


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

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

2009-08-13 Thread dominiq at lps dot ens dot fr



--- Comment #17 from dominiq at lps dot ens dot fr  2009-08-13 17:10 ---
> Dominique,
>  Could you try a build for x86_64-apple-darwin9? I would expect there 
> could
> be a big difference in the bugs tickled since the compiler is 64-bit code in
> that case.

I have tried once in the pats but failed due to the following problem:

ld warning: in /sw/lib/libcloog.dylib, file is not of required architecture
ld warning: in /sw/lib/libppl_c.dylib, file is not of required architecture
ld warning: in /sw/lib/libppl.dylib, file is not of required architecture
ld warning: in /sw/lib/libgmpxx.dylib, file is not of required architecture
ld warning: in /sw/lib/libmpfr.dylib, file is not of required architecture
ld warning: in /sw/lib/libgmp.dylib, file is not of required architecture

and I did not find how to link with the 64 bit libs.


-- 


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

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

2009-08-13 Thread jason at gcc dot gnu dot org



--- Comment #5 from jason at gcc dot gnu dot org  2009-08-13 17:14 ---
Dodji, want to take a look at this some time?


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-13 17:14:08
   date||


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

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

2009-08-13 Thread dodji at gcc dot gnu dot org



--- Comment #6 from dodji at gcc dot gnu dot org  2009-08-13 17:34 ---
OK, it's mine.


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dodji at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-08-13 17:14:08 |2009-08-13 17:34:14
   date||


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

[Bug target/41019] [4.3/4.4/4.5 Regression] Vector conditional move produces wrong code with -O3.

2009-08-13 Thread ubizjak at gmail dot com



--- Comment #23 from ubizjak at gmail dot com  2009-08-13 18:27 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00700.html


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

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


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

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

2009-08-13 Thread tkoenig at gcc dot gnu dot org



--- Comment #13 from tkoenig at gcc dot gnu dot org  2009-08-13 18:55 
---
(In reply to comment #12)

> That's exactly what Thomas is achieving by adding parentheses.  Thomas, If you
> want to tackle something more difficult, I'm willing to do this over the
> weekend in order to warm up my knowledge of gfortran's internals.

I'm glad if you take this on.

Will you do this for scalar actual arguments corresponding to intent(in)
dummy arguments, and for scalar writes as well?


-- 


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

[Bug target/8603] [Alpha] s?addl pattern doesn't work

2009-08-13 Thread uros at gcc dot gnu dot org

--- Comment #9 from uros at gcc dot gnu dot org  2009-08-13 18:57 ---
Subject: Bug 8603

Author: uros
Date: Thu Aug 13 18:57:15 2009
New Revision: 150723

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150723
Log:
PR target/8603
* config/alpha/alpha.md (addsi3): Remove expander.
(addsi3): Rename from *addsi3_internal insn pattern.
(subsi3): Remove expander.
(subsi3): Rename from *subsi3_internal insn pattern.

Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config/alpha/alpha.md

-- 

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

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

2009-08-13 Thread cppljevans at suddenlink dot net



--- Comment #10 from cppljevans at suddenlink dot net  2009-08-13 19:15 
---
Created an attachment (id=18356)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18356&action=view)
minimal test case demonstrating bug

The comments at bottom show that wrong template instance is being
selected by cp_tree_equal.  For example, with:

  //#define INTEGRAL0_C

cp_tree_equal tries to select the integral_c<,Values> from struct package_c for
integral1_c<,Value_1>::type_1; however, since Value_1
is not a parameter pack, compiler gives confusing error message about
Values not being expanded, 

OTOH, with:

  #define INTEGRAL0_C

the compiler tries to use the type of integral0_c<,Value_0>::type_0
for the integral<,Values> in the supertype of package_c; however, since,
in this case, Value_0 is not a parameter pack, compiler gives error
about no contained argument packs.


-- 


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

[Bug c++/41060] New: Wconversion Ignores static_cast

2009-08-13 Thread robert dot stewart at sig dot com

When building C++ code with GCC 4.3, the new and improved Wconversion option
ignores the use of static_cast.  According to
http://gcc.gnu.org/wiki/NewWconversion, C-style casts can be used to suppress
Wconversion warnings, but static_casts don't have the same effect.  This is
frustrating for one that avoids C-style casts.


-- 
   Summary: Wconversion Ignores static_cast
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: robert dot stewart at sig dot com


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

[Bug debug/30161] GCC should generate dwarf info about template parameters

2009-08-13 Thread dodji at gcc dot gnu dot org



--- Comment #7 from dodji at gcc dot gnu dot org  2009-08-13 19:24 ---
A candidate patch was sent to
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00703.html .


-- 


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

[Bug fortran/40941] gfc_typespec: put derived and cl into union

2009-08-13 Thread janus at gcc dot gnu dot org

--- Comment #2 from janus at gcc dot gnu dot org  2009-08-13 19:47 ---
Subject: Bug 40941

Author: janus
Date: Thu Aug 13 19:46:46 2009
New Revision: 150725

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150725
Log:
2009-08-13  Janus Weil  

PR fortran/40941
* gfortran.h (gfc_typespec): Put 'derived' and 'cl' into union.
* decl.c (build_struct): Make sure 'cl' is only used
if type is BT_CHARACTER.
* symbol.c (gfc_set_default_type): Ditto.
* resolve.c (resolve_symbol, resolve_fl_derived): Ditto.
(resolve_equivalence,resolve_equivalence_derived): Make sure 'derived'
is only used if type is BT_DERIVED.
* trans-io.c (transfer_expr): Make sure 'derived' is only used if type
is BT_DERIVED or BT_INTEGER (special case: C_PTR/C_FUNPTR).
* array.c: Mechanical replacements to accomodate union in gfc_typespec.
* check.c: Ditto.
* data.c: Ditto.
* decl.c: Ditto.
* dump-parse-tree.c: Ditto.
* expr.c: Ditto.
* interface.c: Ditto.
* iresolve.c: Ditto.
* match.c: Ditto.
* misc.c: Ditto.
* module.c: Ditto.
* openmp.c: Ditto.
* parse.c: Ditto.
* primary.c: Ditto.
* resolve.c: Ditto.
* simplify.c: Ditto.
* symbol.c: Ditto.
* target-memory.c: Ditto.
* trans-array.c: Ditto.
* trans-common.c: Ditto.
* trans-const.c: Ditto.
* trans-decl.c: Ditto.
* trans-expr.c: Ditto.
* trans-intrinsic.c: Ditto.
* trans-io.c: Ditto.
* trans-stmt.c: Ditto.
* trans-types.c: Ditto.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/fortran/check.c
trunk/gcc/fortran/data.c
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/dump-parse-tree.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/iresolve.c
trunk/gcc/fortran/match.c
trunk/gcc/fortran/misc.c
trunk/gcc/fortran/module.c
trunk/gcc/fortran/openmp.c
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/simplify.c
trunk/gcc/fortran/symbol.c
trunk/gcc/fortran/target-memory.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-common.c
trunk/gcc/fortran/trans-const.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/fortran/trans-io.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/fortran/trans-types.c

-- 

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

[Bug fortran/40941] gfc_typespec: put derived and cl into union

2009-08-13 Thread janus at gcc dot gnu dot org



--- Comment #3 from janus at gcc dot gnu dot org  2009-08-13 19:49 ---
Fixed with r150725. I don't think ts.interface can be incorporated into the
union easily. Therefore I'll close the PR.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

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

2009-08-13 Thread 3dw4rd at verizon dot net

I compiled my  busybox just to see if it works and got a bunch of
compile errors related to members being private.  All these member were being
used in the operator>> and operator<< for the distributions and all were
complaining about inserting or extracting state from another distribution
contained as private state in that distribution

e.g. in std::lognormal_distribution<...>:
--
...
private:
  std::normal_distribution _M_nd;

The global operator>> and operator<< failed with _M_nd is private.

The answer is to scoot these inserters and extrctors into the class scope as
friends.

Ed


-- 
   Summary: Compile of program using std random fails.
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: 3dw4rd at verizon dot net
  GCC host triplet: x86_64-redhat-linux


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

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

2009-08-13 Thread 3dw4rd at verizon dot net



--- Comment #1 from 3dw4rd at verizon dot net  2009-08-13 20:27 ---
Created an attachment (id=18357)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18357&action=view)
Here is my busybox which is mainly an amalgamation of the tests I wrote when I
built the random patch.


-- 


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

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

2009-08-13 Thread 3dw4rd at verizon dot net



--- Comment #2 from 3dw4rd at verizon dot net  2009-08-13 20:28 ---
Created an attachment (id=18358)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18358&action=view)
This is te original error message stream.


-- 


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

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

2009-08-13 Thread 3dw4rd at verizon dot net



--- Comment #3 from 3dw4rd at verizon dot net  2009-08-13 20:29 ---
Created an attachment (id=18359)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18359&action=view)
This is a patch.


-- 


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

[Bug fortran/41062] New: internal compiler error

2009-08-13 Thread clerman at fuse dot net

Hello to everyone at the gfortran development team:

  I am trying to build my lens design program with the latest trunk version of
gfortran:

n...@oxford:~/design/gfortran/bug7/test> gfortran --version
GNU Fortran (GCC) 4.5.0 20090808 (experimental) [trunk revision 150581]

  The build stops when I compile a file named cmndtypeM.f90. Here is the error
message gfortran prints:

cmndtypeM.f90:127:0: internal compiler error: in gfc_trans_use_stmts, at
fortran/trans-decl.c:3438
Please submit a full bug report,
with preprocessed source if appropriate.

  I have successfully compiled this code with the nag compiler, version 5.2 (on
Linux) and with version 10.1 of the Intel compiler (on Windows).

  I will send a zipped tar archive file to gcc-bugzi...@gcc.gnu.org that will
contain all the source code and a shell script that should allow you to
reproduce the problem. The file's name will be bug7.tar.gz. To reproduce the
problem, unzip the file and unpack all its contents. The invoke the shell
script bug7.sh.

  Let me know if there are any problems or if you are missing anything.

  Thank you for your attention.

Yours truly,

Norm Clerman


-- 
   Summary: internal compiler error
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: clerman at fuse dot net


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

[Bug fortran/41062] internal compiler error

2009-08-13 Thread clerman at fuse dot net



--- Comment #1 from clerman at fuse dot net  2009-08-13 20:52 ---
Subject: Bug 41062 has been added to the database

Hello everyone:

  gfortran bug 41062.

  Attached is a file that will allow you to reproduce bug 41062. Unzip the
file, extract its contents, and invoke shell scipt bug7.sh. gfortran is
reporting an internal compiler error when it tries to compile file
cmndtypeM.f90.

  Thank you for your attention.

Norm Clerman


--- Comment #2 from clerman at fuse dot net  2009-08-13 20:52 ---
Created an attachment (id=18360)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18360&action=view)


-- 


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

[Bug debug/41063] New: ICE in output_die

2009-08-13 Thread ccoutant at gcc dot gnu dot org

Compile the following with -g for a DWARF target:

$ cat test.cc
struct A {
  virtual void run();
};

void test() {
  struct B : public A {
void run() {
  struct C : public A {
C() { }
B *b_;
  };
  C c;
}
  };
  B b;
}

$ gcc -v
Reading specs from /home/ccoutant/opensource/gcc-trunk/build-native/gcc/specs
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++ --disable-bootstrap
: (reconfigured) ../gcc/configure --disable-bootstrap --enable-languages=c,c++
--no-create --no-recursion
Thread model: posix
gcc version 4.5.0 20090727 (experimental) (GCC) 

$ gcc -g -c test.cc
test.cc:16:1: internal compiler error: in output_die, at dwarf2out.c:8845
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


By the time we get to dwarf2out_finish(), the DIE graph has a cycle in it:

 struct B -> subprogram run -> struct C -> struct B -> ...

It seems to have put the DIE for struct B as a child of struct C instead of the
DIE for "pointer to B".

Because of the cycle, none of the DIEs involved are placed in the main compunit
tree. The DIE for the type "pointer to B" (which did make it into the main
tree) tries to reference the DIE for the type B, which is part of the cycle,
and triggers the assertion.

When the vtable for struct C is output from note_debug_info_needed(), a DIE for
struct B has not been built yet. When gen_type_die_with_usage() sees the
pointer to B, it then calls itself recursively to generate the DIE for B, but
it passes the same context that it was given, which is the lexical block inside
B::run(), and struct B is then created as a child of that lexical block, thus
forming the cycle.


-- 
   Summary: ICE in output_die
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ccoutant at gcc dot gnu dot org
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

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

2009-08-13 Thread howarth at nitro dot med dot uc dot edu



--- Comment #18 from howarth at nitro dot med dot uc dot edu  2009-08-13 
23:29 ---
Current gcc trunk with 1677_max.diff applied still shows the bug. I'll run the
complete make check on ppl 0.10.2 for x86_64-apple-darwin tonight to make sure
the issue isn't revealed in the ppl testsuite.


-- 


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

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

2009-08-13 Thread Tobias Schlüter



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

tkoenig at gcc dot gnu dot org wrote:
> --- Comment #13 from tkoenig at gcc dot gnu dot org  2009-08-13 18:55 
> ---
> (In reply to comment #12)
> 
>> That's exactly what Thomas is achieving by adding parentheses.  Thomas, If 
>> you
>> want to tackle something more difficult, I'm willing to do this over the
>> weekend in order to warm up my knowledge of gfortran's internals.
> 
> I'm glad if you take this on.
> 
> Will you do this for scalar actual arguments corresponding to intent(in)
> dummy arguments, and for scalar writes as well?

I'll start with the latter, and see if I can achieve the former afterwards.


-- 


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

[Bug debug/41063] ICE in output_die

2009-08-13 Thread ccoutant at gcc dot gnu dot org



--- Comment #1 from ccoutant at gcc dot gnu dot org  2009-08-13 23:40 
---
Created an attachment (id=18361)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18361&action=view)
Proposed patch to dwarf2out.c

   * dwarf2out.c (gen_type_die_with_usage): Set context_die for
   basis type of reference or pointer type.


-- 

ccoutant at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ccoutant at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED


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

[Bug fortran/41062] internal compiler error

2009-08-13 Thread dominiq at lps dot ens dot fr



--- Comment #3 from dominiq at lps dot ens dot fr  2009-08-14 00:14 ---
Reduced test case:

module SysKinds

  INTEGER, PARAMETER :: DefaultInteger = kind (1)
  INTEGER (DefaultInteger), PARAMETER :: ASCIICharacterKind = KIND ("A")
  integer(DefaultInteger), parameter :: SmallInteger = selected_int_kind (4)

end module SysKinds

module Parser

   use SysKinds

   interface PutALine
 module procedure Line_from_string
   end interface

   integer (SmallInteger), parameter :: LINE_LENGTH = 200

   type, public :: TStringBlock
 private
 character (LINE_LENGTH, ASCIICharacterKind) :: theLine = " "
 integer (SmallInteger) :: CurrentIndex, LastIndex = 0, NextIndex
   end type TStringBlock

contains

   subroutine Line_from_string

   end subroutine Line_from_string

end module Parser

module CmndType

  use SysKinds
  use Parser, only : PutALine, TstringBlock

  implicit none

  type, public :: Tcommand
type (TstringBlock) :: commandLine
  end type Tcommand

contains

  subroutine Dump_cmd (this, tag)

type (TCommand), intent (IN) :: this
character (*, ASCIICharacterKind), intent (IN), optional :: tag

call PutALine ()
  contains

subroutine PutALine (user_Line)

  character (*, ASCIICharacterKind), intent (IN), optional :: user_Line

end subroutine PutALine

  end subroutine Dump_cmd

end module CmndType

gives an ICE with trunk and 4.4.1:

[ibook-dhum] bug/bug7% gfc cmndtypeM_red.f90
cmndtypeM_red.f90:36:0: internal compiler error: in gfc_trans_use_stmts, at
fortran/trans-decl.c:3438
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

compiles with 4.3.4, hence a regression.


-- 


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

[Bug fortran/41062] [4.4, 4.5 Regression] internal compiler error

2009-08-13 Thread jvdelisle at gcc dot gnu dot org



--- Comment #4 from jvdelisle at gcc dot gnu dot org  2009-08-14 00:29 
---
Severity is never considered a blocker with gfortran.  Marking as a regression.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|blocker |normal
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-14 00:29:56
   date||
Summary|internal compiler error |[4.4, 4.5 Regression]
   ||internal compiler error


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

[Bug rtl-optimization/41064] New: [4.5 Regression]: build breakage for cris-elf building newlib, ICE in extract_insn, from r150726

2009-08-13 Thread hp at gcc dot gnu dot org

This bug was hidden at the time of its introduction by PR41031.

With revision 150725 plus the patch at
 a build was
successful with reasonable test-results.
>From revision 150726 plus the same patch a build failed as follows.
The build failure was fully exposed (no local patches needed) from revision
150702 and on (when the equivalent patch was committed):

/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/xgcc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/ -nostdinc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/v32/newlib/ -isystem
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/v32/newlib/targ-include -isystem
/tmp/hpautotest-gcc1/gcc/newlib/libc/include
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/v32/libgloss/cris
-L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/v32/libgloss/libnosys
-L/tmp/hpautotest-gcc1/gcc/libgloss/cris
-B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/bin/
-B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/lib/ -isystem
/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/include -isystem
/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/sys-include  -march=v32
-mbest-lib-options -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"1.17.0\" -DPACKAGE_STRING=\"newlib\ 1.17.0\"
-DPACKAGE_BUGREPORT=\"\"  -I. -I/tmp/hpautotest-gcc1/gcc/newlib/libc/search -O2
-DHAVE_RENAME -D_USE_WRITE -DCOMPACT_CTYPE -fno-builtin  -g -O2  -march=v32
-mbest-lib-options -c -o lib_a-hash_bigkey.o `test -f 'hash_bigkey.c' || echo
'/tmp/hpautotest-gcc1/gcc/newlib/libc/search/'`hash_bigkey.c
/tmp/hpautotest-gcc1/gcc/newlib/libc/search/hash_bigkey.c: In function
'__big_insert':
/tmp/hpautotest-gcc1/gcc/newlib/libc/search/hash_bigkey.c:175:1: error:
unrecognizable insn:
(insn 22 392 25 2 /tmp/hpautotest-gcc1/gcc/newlib/libc/search/hash_bigkey.c:105
(set (reg/v/f:SI 8 r8 [orig:41 val_data ] [41])
(mem/s/f:SI (post_inc:SI (reg:SI 15 acr)) [15 val_30(D)->data+0 S4
A8])) -1 (expr_list:REG_INC (reg:SI 15 acr)
(nil)))
/tmp/hpautotest-gcc1/gcc/newlib/libc/search/hash_bigkey.c:175:1: internal
compiler error: in extract_insn, at recog.c:2089
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[8]: *** [lib_a-hash_bigkey.o] Error 1
make[8]: Leaving directory
`/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/v32/newlib/libc/search'

Author of patch CC:ed.  The invalidity is the post_inc on R15, a register which
cannot be post-incremented.

A brief look with gdb reveals the immediate cause of the ICE is the
extract_insn call in the context of the change of revision 150726. Applying it
to a non-recognizable insn, a no-no. I don't quite understand why this didn't
also happen before revision 150726 as the same call was there then too, but
I'll have another look.

Preprocessed code to be attached.


-- 
   Summary: [4.5 Regression]: build breakage for cris-elf building
newlib, ICE in extract_insn, from r150726
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, build
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf


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

[Bug rtl-optimization/41064] [4.5 Regression]: build breakage for cris-elf building newlib, ICE in extract_insn, from r150726

2009-08-13 Thread hp at gcc dot gnu dot org



--- Comment #1 from hp at gcc dot gnu dot org  2009-08-14 01:22 ---
Created an attachment (id=18362)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18362&action=view)
preprocessed, non-reduced test-case

Compile with -march=v32 -O2


-- 


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

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

2009-08-13 Thread howarth at nitro dot med dot uc dot edu



--- Comment #19 from howarth at nitro dot med dot uc dot edu  2009-08-14 
01:45 ---
Actually the error in gdb has changed with 1677_max.diff...

(gdb) r  -O2 -fgraphite-identity -floop-strip-mine air.f90 -o air
Starting program:
/sw/src/fink.build/gcc45-4.4.999-20090813/darwin_objdir/gcc/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
air.f90: In function state:
air.f90:1034:0: internal compiler error: in ppl_max_for_le, at
graphite-ppl.c:637
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

Program exited with code 04.
(gdb) bt
No stack.

so I am no longer able to get a back trace.


-- 


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

[Bug rtl-optimization/41064] [4.5 Regression]: build breakage for cris-elf building newlib, ICE in extract_insn, from r150726

2009-08-13 Thread hp at gcc dot gnu dot org



--- Comment #2 from hp at gcc dot gnu dot org  2009-08-14 02:19 ---
(In reply to comment #0)
> A brief look with gdb reveals the immediate cause of the ICE is the
> extract_insn call in the context of the change of revision 150726. Applying it
> to a non-recognizable insn, a no-no. I don't quite understand why this didn't
> also happen before revision 150726 as the same call was there then too,

A major difference between validate_replace_rtx (r150725) and
validate_replace_rtx_group (r150726) that's called just before extract_insn for
both revisions is that validate_replace_rtx restores replacements if they are
seen as invalid, so the extract_insn only happens for a this-far-known valid
and recognizable insn.  So, assuming that r150726 is otherwise correct, it
needs to be adjusted with this patch (moving the extract_insn call to inside
the truth-arm of the validity-test that follows plus a warning comment):

Index: reload1.c
===
--- reload1.c   (revision 150626)
+++ reload1.c   (working copy)
@@ -4312,10 +4312,15 @@
  n = verify_changes (0);

  /* We must also verify that the constraints
-are met after the replacement.  */
- extract_insn (p);
+are met after the replacement.  Make sure
+extract_insn is only called for an insn
+where the replacements were found to be
+valid so far. */
  if (n)
-   n = constrain_operands (1);
+   {
+ extract_insn (p);
+ n = constrain_operands (1);
+   }

  /* If the constraints were not met, then
 undo the replacement, else confirm it.  */

I'm going to test this and submit it.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hp at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-14 02:19:34
   date||


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

[Bug fortran/40955] STDCALL attributes are not saved in the .MOD files

2009-08-13 Thread jvdelisle at gcc dot gnu dot org



--- Comment #6 from jvdelisle at gcc dot gnu dot org  2009-08-14 02:35 
---
Subject: Bug 40955

Author: jvdelisle
Date: Fri Aug 14 02:35:32 2009
New Revision: 150733

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150733
Log:
2009-08-13  Jerry DeLisle 

PR fortran/40955
* gfortran.dg/winapi.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/winapi.f90
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

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

2009-08-13 Thread howarth at nitro dot med dot uc dot edu



--- Comment #20 from howarth at nitro dot med dot uc dot edu  2009-08-14 
04:29 ---
Both gmp 4.3.1 and ppl 0.10.2 pass all of their testsuites on
x86_64-apple-darwin10. I'll also try to find the smallest code fragment which
will trigger this bug.


-- 


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

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

2009-08-13 Thread coppro at users dot sf dot net



--- Comment #5 from coppro at users dot sf dot net  2009-08-14 05:41 ---
Jonathan Wakely appears to be correct. My apologies!


-- 

coppro at users dot sf dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/41062] [4.4/4.5 Regression] ICE in gfc_trans_use_stmts, at fortran/trans-decl.c:3438

2009-08-13 Thread burnus at gcc dot gnu dot org



-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to fail||4.4.1 4.5.0
  Known to work||4.3.3
Summary|[4.4, 4.5 Regression]   |[4.4/4.5 Regression] ICE in
   |internal compiler error |gfc_trans_use_stmts, at
   ||fortran/trans-decl.c:3438
   Target Milestone|--- |4.4.2


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

[Bug middle-end/30789] complex folding inexact

2009-08-13 Thread ghazi at gcc dot gnu dot org



--- Comment #5 from ghazi at gcc dot gnu dot org  2009-08-14 05:58 ---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00728.html


-- 


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

86 matches

Mail list logo