[Bug c/21461] New: [ia64] miscompilation at -O2 in 3.4.x, 4.x

2005-05-09 Thread duraid at octopus dot com dot au
The SPASS theorem prover (see below) is miscompiled at -O2 by:

gcc version 3.4.3
gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)
gcc version 4.0.0 (release)
gcc version 4.1.0 20050509 (experimental)

it is compiled correctly by:

gcc version 3.3.6 (Debian 1:3.3.6-3)
gcc version 3.3.5
Intel(R) C Itanium(R) Compiler for Itanium(R)-based applications Version 8.1
LLVM

and the problematic compilers mentioned above at -O1.

TO REPRODUCE:

1) find yourself an ia64 box
2) unpack http://kinoko.c.u-tokyo.ac.jp/~duraid/spassbug.tgz (sorry)
3) make (you'll want to change the gcc-3.4 -O2 that appears in the Makefile)
4) ./a.out bug_trigger  (this segfaults fairly rapidly, it should run to
completion in ~20s on an itanium 2 system)

-- 
   Summary: [ia64] miscompilation at -O2 in 3.4.x, 4.x
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: duraid at octopus dot com dot au
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: ia64-linux-unknown
  GCC host triplet: ia64-linux-unknown
GCC target triplet: ia64-linux-unknown


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


[Bug c/21461] miscompilation at -O2 in 3.4.x, 4.x

2005-05-09 Thread duraid at octopus dot com dot au

--- Additional Comments From duraid at octopus dot com dot au  2005-05-09 
06:44 ---
oops, my mistake. this bug appears on x86 too, at least:

gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)
fails (at -O2), but:

gcc version 3.3.6 (Debian 1:3.3.6-3)
works. Perhaps this is a bug in SPASS, but the program does
appear to behave as far as valgrind is concerned. Not sure what
sort of legal optimization could break a program in this way. I'm pretty
sure there's no floating-point code affecting control flow here.


-- 
   What|Removed |Added

  GCC build triplet|ia64-linux-unknown  |
   GCC host triplet|ia64-linux-unknown  |
 GCC target triplet|ia64-linux-unknown  |
Summary|[ia64] miscompilation at -O2|miscompilation at -O2 in
   |in 3.4.x, 4.x   |3.4.x, 4.x


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


[Bug target/19087] Overflowed address in dwarf debug line information

2005-05-09 Thread tsandnes at norway dot atmel dot com

--- Additional Comments From tsandnes at norway dot atmel dot com  
2005-05-09 07:01 ---
Subject: Re:  Overflowed address in dwarf debug line information

bjoern dot m dot haase at web dot de wrote:
 --- Additional Comments From bjoern dot m dot haase at web dot de  
 2005-05-06 14:12 ---
 Hi Torleif, 
  
 I have just had a look at PR19885 and I am having one additional question: 
 IIUC, the lable references, that eventually cause the overflow problems refer 
 to memory in form of byte addresses and not word addresses: I.e. the 
 offsets and address information you are finding in the elf files all are 
 byte 
 addresses. Am I right? 

Yes. This is what I have observed.
avr-readelf with the -w switch is very useful for viewing the debug information.

 In the asm outputs I have investigated so far, I realized that for the lable 
 references in the dwarf sections avr-gcc is allocating two bytes only. So in 
 case that these two bytes are filled with byte addresses instead of word 
 addresses, it is obvious that an overflow could not be avoided. The cleanest 
 solution then would be to redefine the debugging format such that within the 
 debugging sections for the dwarf symbols, gcc allocates four bytes for the 
 pointers. I fear, however, that this would be a major challenge since one 
 would 
 probably need to rewrite a considerable portion of the 
 dwarf-output-genenerator 
 in a target-specific fashion. 
 If I'm not too wrong, we probably won't have a short term solution for this 
 PR. 

I think your explanation makes sense.

But how can target specific code be added to the dwarf output generator?
AFAIK everything AVR related must be put in the avr.c, avr.h or avr.md in the 
gcc/config directory. Must it not rather be rewritten to work for all targets 
*and* the AVR port?

Thanks for taking the time to look into this.

Torleif



-- 


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


[Bug target/21397] -march selects wrong arm_tune flags

2005-05-09 Thread trauscher at loytec dot com

--- Additional Comments From trauscher at loytec dot com  2005-05-09 07:04 
---
The problem is that -march=xxx -mtune=yyy doesn't work.
The arm_override_option function scans the options
in the order -mtune, -march, -mcpu. So when -mtune is
given, 'arm_tune' first set by -mtune and then
overwritten with the wrong tune settings from -march.

I think, this problem was introduced between gcc-3.4.3 and
gcc-4.0.0. In 3.4.3 only -mtune sets 'arm_tune' where in
4.0.0 all three flags affect 'arm_tune'.

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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


[Bug c/16676] [3.4 Regression] ICE with nested functions and -g1, blocks glibc

2005-05-09 Thread giovannibajo at libero dot it

--- Additional Comments From giovannibajo at libero dot it  2005-05-09 
07:07 ---
Zack, this is a regression of part of your c-decl stuff. Can you possibly give 
it a look? It breaks builds of glibc on primary platforms.

-- 


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


[Bug c/16676] [3.4 Regression] ICE with nested functions and -g1, blocks glibc

2005-05-09 Thread benh at kernel dot crashing dot org

--- Additional Comments From benh at kernel dot crashing dot org  
2005-05-09 07:11 ---
Ben Elliston just produced a patch for it that I tested. It fixed building of
glibc on debian powerpc with -g1 (used by debian rules for nptl).

The patch is on it's way to the patch list (which didn't catch up yet it seems).
The patch is very simple, it just causes gcc to emit more debug infos in the
case of nested functions (like the -g2 case) instead of trying to be smart.

-- 


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


[Bug c++/18604] [3.4/4.0/4.1 Regression] Strong using lookup conflicts

2005-05-09 Thread giovannibajo at libero dot it

--- Additional Comments From giovannibajo at libero dot it  2005-05-09 
07:25 ---
I analyzed this PR again. The problem seems not related to attribute strong 
itself, but rather the way v3 namespaces work. Basically, without debug 
support, the failing code looks like:

-
namespace std {
   struct A {};
};

struct A;

namespace std {
   A a;// std::A, OK!
};
-

Instead, with debug support, we end up with code like this:

-
namespace std {
   struct A {};
};

namespace __gnu_norm {
   using namespace std;
};

struct A;

namespace __gnu_norm {
   A a;// ambiguous!
};
-

hence the failure. There are at least two ways to fix this in v3:

- Fully qualify all references to std names from code within namespace 
_GLIBCXX_STD (which expands to __gnu_norm in debug mode). This is hard because 
it's impossible to fully check it, and it's pervasive. E.g. bits/stl_set.h:69, 
use std::less instead of less.

- Define namespace __gnu_norm within namespace std. This could be easier 
because you probably have to touch *only* namespace definitions.

Comments?

-- 
   What|Removed |Added

 CC||bkoz at gcc dot gnu dot org,
   ||mmitchel at gcc dot gnu dot
   ||org, pcarlini at suse dot de


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


[Bug tree-optimization/21462] New: if statement not converted to MIN_EXPR

2005-05-09 Thread micis at gmx dot de
Consider the following short program:

#include algorithm

void Tst1(short* __restrict__ SrcP, short* __restrict__ MinP, int Len)
{
for (int x=0; xLen; x++)
MinP[x] = SrcP[x] ? MinP[x];
}

void Tst2(short* __restrict__ SrcP, short* __restrict__ MinP, int Len)
{
for (int x=0; xLen; x++)
MinP[x] = (SrcP[x]MinP[x]) ? SrcP[x] : MinP[x];
}

void Tst3(short* __restrict__ SrcP, short* __restrict__ MinP, int Len)
{
for (int x=0; xLen; x++)
MinP[x] = (SrcP[x]MinP[x]) ? (short)SrcP[x] : MinP[x];
}

void Tst4(short* __restrict__ SrcP, short* __restrict__ MinP, int Len)
{
for (int x=0; xLen; x++)
MinP[x] = std::min(SrcP[x], MinP[x]);
}

void Tst5(short* __restrict__ SrcP, short* __restrict__ MinP, int Len)
{
for (int x=0; xLen; x++)
if (SrcP[x]MinP[x])  MinP[x]=SrcP[x];
}

If I compile it with
gcc41 -O2 -ftree-vectorize -ftree-vectorizer-verbose=5
function Tst1/Tst2/Tst3 gets vectorized but Tst4/Tst5 not.

The reason for this is the first three funtions result in a MIN_EXPR while 
std::min and the if statement generate conditional code which the vectorizer 
does not recognize.


Michael Cieslinski

-- 
   Summary: if statement not converted to MIN_EXPR
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: micis at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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


[Bug tree-optimization/19716] Segfault with -ftree-vectorize

2005-05-09 Thread micis at gmx dot de

--- Additional Comments From micis at gmx dot de  2005-05-09 08:24 ---
I cannot reproduce this bug any longer. Maybe the fix for pr20122 also helps 
here.

Michael Cieslinski


-- 


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


[Bug regression/21463] New: min/max and references

2005-05-09 Thread tbptbp at gmail dot com
I don't quite know how to characterize this one, so i'll let it up to those in
the know to fix the summary/description.
Primo, AFAIK, gcc has always struggled to get this right but 4.1 is setting a
new record; so i'll qualify that as a regression vs 3.3/3.4.
Secundo, i haven't found any related bugreports but one about PPC.
So here we go.

Consider this testcase:
#include algorithm

templateclass T static inline T max(const T a, const T b) { return ab ? b : 
a; }
templateclass T static inline T min(const T a, const T b) { return ab ? a : 
b; }

templateclass T static inline const T ref_max(const T a, const T b) {
return ab ? b : a; }
templateclass T static inline const T ref_min(const T a, const T b) {
return ab ? a : b; }

templateclass T struct foo_t {
T a0, a1;
T bar(const T b, const T c) {
return max(min(a0, c), min(max(a1, c), b));
}
T bar_ref(const T b, const T c) {
return ref_max(ref_min(a0, c), ref_min(ref_max(a1, c), b));
}
T bar_stl(const T b, const T c) {
return std::max(std::min(a0, c), std::min(std::max(a1, c), b));
}
};
template struct foo_tint;
template struct foo_tfloat;

int main() { return 0; }

With g++-4120050501 -O3 i get such creative  entertaining code as:
00400610 foo_tfloat::bar_ref(float, float):
  400610:   ucomiss 0x4(%rdi),%xmm1
  400614:   lea0x4(%rdi),%rax
  400618:   lea0xfff8(%rsp),%rdx
  40061d:   movss  %xmm0,0xfffc(%rsp)
  400623:   movss  %xmm1,0xfff8(%rsp)
  400629:   movaps %xmm1,%xmm2
  40062c:   cmova  %rdx,%rax
  400630:   movss  (%rax),%xmm1
  400634:   ucomiss %xmm1,%xmm0
  400637:   ja 400641 foo_tfloat::bar_ref(float, float)+0x31
  400639:   lea0xfffc(%rsp),%rax
  40063e:   movaps %xmm0,%xmm1
  400641:   ucomiss (%rdi),%xmm2
  400644:   cmova  %rdi,%rdx
  400648:   movss  (%rdx),%xmm0
  40064c:   ucomiss %xmm0,%xmm1
  40064f:   jbe400655 foo_tfloat::bar_ref(float, float)+0x45
  400651:   movss  (%rax),%xmm0
  400655:   repz retq

Compare that to what g++-3.4.4-20050314 gives (g++ 3.3.6 is similar):
00400610 foo_tfloat::bar_ref(float, float):
  400610:   ucomiss (%rdi),%xmm1
  400613:   lea0xfffc(%rsp),%rsi
  400618:   mov%rdi,%rcx
  40061b:   lea0x4(%rdi),%rdx
  40061f:   movss  %xmm0,0xfff8(%rsp)
  400625:   lea0xfff8(%rsp),%rax
  40062a:   movss  %xmm1,0xfffc(%rsp)
  400630:   cmovbe %rsi,%rcx
  400634:   ucomiss 0x4(%rdi),%xmm1
  400638:   cmova  %rsi,%rdx
  40063c:   ucomiss (%rdx),%xmm0
  40063f:   cmova  %rdx,%rax
  400643:   movss  (%rax),%xmm0
  400647:   ucomiss (%rcx),%xmm0
  40064a:   cmovbe %rcx,%rax
  40064e:   movss  (%rax),%xmm0
  400652:   retq
Certainly not optimal, and in fact quite ugly, but at least there's no branch.

Happens as soon as references are used and enough min/max are piled up, and that
means that unless you use your own min/max instead of the STL version, you're
doomed.

-- 
   Summary: min/max and references
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: x86*


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


[Bug rtl-optimization/19680] sub-optimial register allocation with sse

2005-05-09 Thread tbptbp at gmail dot com

--- Additional Comments From tbptbp at gmail dot com  2005-05-09 08:46 
---
I'm going to ping this bugreport because there's still some very bad interaction
with gcse in current gcc.
Just compile the 'packet_intersection.cpp' testcase with ie g++-4.1-4120050501
for ia32 to convince yourself (x86-64 is apparently immune, thanks to the lower
register pressure).

It takes a bit of luck, or the use of -fno-gcse, to dodge that issue which
really kills performance.


-- 


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


[Bug regression/21463] min/max and references

2005-05-09 Thread tbptbp at gmail dot com

--- Additional Comments From tbptbp at gmail dot com  2005-05-09 08:50 
---
I forgot to say that using ternary operators or if/else while changing the
codegen slightly doesn't make much difference.


-- 


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


[Bug c++/18604] [3.4/4.0/4.1 Regression] Strong using lookup conflicts

2005-05-09 Thread pcarlini at suse dot de

--- Additional Comments From pcarlini at suse dot de  2005-05-09 09:04 
---
 - Fully qualify all references to std names from code within namespace 
 _GLIBCXX_STD (which expands to __gnu_norm in debug mode). This is hard 
 because 
 it's impossible to fully check it, and it's pervasive. E.g. 
 bits/stl_set.h:69, 
 use std::less instead of less.

Actually, this is already the case (modulo mistakes): we did this work a lot
of time ago, *before* the strong using work. The only remaining occurrences of 
unqualified names are fixed as we find them (Jonathan is doing a great job
here, and in fact he uses debug mode) or are there for a reason: if I remember 
correctly, this is the case of less. I'm pretty sure Gaby said something.
Gaby? In case fixing that would be trivial, of course.

-- 
   What|Removed |Added

 CC||gdr at integrable-solutions
   ||dot net


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


[Bug c++/18604] [3.4/4.0/4.1 Regression] Strong using lookup conflicts

2005-05-09 Thread pcarlini at suse dot de

--- Additional Comments From pcarlini at suse dot de  2005-05-09 09:16 
---
I found something in the archive:

  http://gcc.gnu.org/ml/libstdc++/2002-12/msg9.html

That's why we didn't qualify less  co... In mainline (vs v7-branch), where we
still don't have anything special for those function objects, maybe we should
add the qualifications?

-- 


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


[Bug c/21464] New: assembler code is not generated for uint64_t comparison with -O

2005-05-09 Thread moonz at kaist dot ac dot kr
input:
== a.c =
#include stdio.h
#include inttypes.h

int main() {
uint64_t pos = 1;

pos = 1;

if (pos  1 || pos  0xULL) {
printf(fail\n);
return 1;
}

printf(ok\n);
return 0;
}
= end of a.c =

command lines:

$ gcc a.c
$ ./a.out
ok

$ gcc -O a.c
$ ./a.out
fail

assembler code for comparison of pos is not generated correctly.

it should test, at least, pos  1, 
but generated code act like if the condition was true.

if pos  0xUL is not present, it runs successfully.
definitely, optimization bug while preevaluating the condition at compile time.

my gcc version information is:

$ gcc -v   
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.3-20050110/specs
Configured with: /var/tmp/portage/gcc-3.4.3.20050110-r2/work/gcc-3.4.3/configure
--enable-version-specific-runtime-libs --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.4.3-20050110
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.3-20050110/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.3-20050110
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.3-20050110/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.3-20050110/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.3-20050110/include/g++-v3
--host=i686-pc-linux-gnu --disable-altivec --enable-nls
--without-included-gettext --with-system-zlib --disable-checking
--disable-werror --disable-libunwind-exceptions --disable-multilib
--disable-libgcj --enable-languages=c,c++,f77 --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110-r2,
ssp-3.4.3.20050110-0, pie-8.7.7)

-- 
   Summary: assembler code is not generated for uint64_t comparison
with -O
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: moonz at kaist dot ac dot kr
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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


[Bug java/21442] problem with imports and multifile builds

2005-05-09 Thread bonzini at gcc dot gnu dot org


-- 
   What|Removed |Added

OtherBugsDependingO||21418
  nThis||


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


[Bug java/21442] problem with imports and multifile builds

2005-05-09 Thread bonzini at gcc dot gnu dot org

--- Additional Comments From bonzini at gcc dot gnu dot org  2005-05-09 
10:03 ---
The problem is that, while looking for AbstractInterruptibleChannel (a
superclass of SelectableChannel), we do not look into the imports of
SelectableChannel.

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

-- 
   What|Removed |Added

  BugsThisDependsOn|21436   |
 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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


[Bug java/21436] imports not remembered for previously compiled files

2005-05-09 Thread bonzini at gcc dot gnu dot org

--- Additional Comments From bonzini at gcc dot gnu dot org  2005-05-09 
10:03 ---
*** Bug 21442 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

OtherBugsDependingO|21442   |
  nThis||


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


[Bug java/21418] Order of source files matters when compiling

2005-05-09 Thread bonzini at gcc dot gnu dot org


-- 
Bug 21418 depends on bug 21442, which changed state.

Bug 21442 Summary: problem with imports and multifile builds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21442

   What|Old Value   |New Value

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

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


[Bug tree-optimization/21465] New: autovectorisation conflicts with -ffast-math

2005-05-09 Thread micis at gmx dot de
Consider the following short function:

void Tst1(float* __restrict__ SrcP, float* __restrict__ DstP, int Len)
{
for (int x=0; xLen; x++)
{
DstP[x] = SrcP[x] * SrcP[x];
}
}

If this function is compiled with:
g++41 -O -S TstPow.cpp -ftree-vectorizer-verbose=5  -ftree-vectorize
it is vectorized, but if you compile with:
g++41 -O -ffast-math -S TstPow.cpp -ftree-vectorizer-verbose=5
-ftree-vectorize
it is not with the following output:

note: Vectorizing an unaligned access.
note: Alignment of access forced using peeling.
note: not vectorized: stmt not supported: D.2052_15 = __builtin_powf 
(D.2051_14, 2.0e+0)
note: vectorized 0 loops in function.


Michael Cieslinski

-- 
   Summary: autovectorisation conflicts with -ffast-math
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: micis at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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


[Bug libgcj/21414] thread lib posix = runtime gij segfaults on Debian G/L Woody

2005-05-09 Thread vaclav dot ovsik at i dot cz

--- Additional Comments From vaclav dot ovsik at i dot cz  2005-05-09 10:47 
---
Subject: Re:  thread lib posix = runtime  gij segfaults on Debian G/L Woody

On Fri, May 06, 2005 at 01:45:49PM -, pinskia at gcc dot gnu dot org wrote:
 This sounds like recursive mutexes are not working on your machine.
 
 Also you need a newer binutils, from
 http://gcc.gnu.org/install/specific.html: As of GCC 3.3, binutils
 2.13.1 or later is required for this platform. See bug 10877 for more
 information.
 
 
 Can you first try with a newer binutils?

I compiled and installed binutils-2.16 and rebuild gcc-4.0.0 (default
thread file posix). There are no segfaults anymore.

Please, excuse my ignorance in reading
http://gcc.gnu.org/install/specific.html, I overlooked requirement of
binutils ver. = 2.13.1.

Problem can be closed.

Best Regards


-- 


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


[Bug tree-optimization/21466] New: sqrt() function not vectorised

2005-05-09 Thread micis at gmx dot de
The following function is not vectorised while there is a sqrt vector function 
available.


#include math.h

void Tst1(float* __restrict__ SrcP, float* __restrict__ DstP, int Len)
{
for (int x=0; xLen; x++)
DstP[x] = sqrt(SrcP[x]);
}


Compiled with
g++41 -O -ffast-math -S TstSqrt.cpp -ftree-vectorizer-verbose=5
-ftree-vectorize -march=opteron
gives following output:

TstSqrt.cpp:5: note: Vectorizing an unaligned access.
TstSqrt.cpp:5: note: Alignment of access forced using peeling.
TstSqrt.cpp:5: note: not vectorized: stmt not supported: D.3171_15 = 
__builtin_sqrtf (D.3170_14)
TstSqrt.cpp:3: note: vectorized 0 loops in function.


Michael Cieslinski

-- 
   Summary: sqrt() function not vectorised
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: micis at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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


[Bug libfortran/21459] strings of different length in a single character(len=*) declaration

2005-05-09 Thread fxcoudert at gcc dot gnu dot org

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-05-09 
11:15 ---
Reduced testcase is following. The root of the problem is that when we declare
strings of different length in the same character(len=*) declaration, all
strings are truncated to the length of the first one. Example:

$ cat pr21459.f90
  character(len=*) :: c1='12345', c2='123456789'
  print *, c1
  print *, c2
  end
$ gfortran pr21459.f90  ./a.out
 12345
 12345

-- 
   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
OtherBugsDependingO||19276
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-09 11:15:34
   date||
Summary|Fortran runtime error:  |strings of different length
   |Unexpected end of format|in a single character(len=*)
   |string  |declaration


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


[Bug target/21397] arm: -march overrides -mtune

2005-05-09 Thread rearnsha at gcc dot gnu dot org

--- Additional Comments From rearnsha at gcc dot gnu dot org  2005-05-09 
11:18 ---
Ah! I understand now.  Sorry, your initial report wasn't clear.  Yes, I agree
this is incorrect.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-09 11:18:37
   date||
Summary|-march selects wrong|arm: -march overrides -mtune
   |arm_tune flags  |


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


[Bug libfortran/19155] blanks not treated as zeros in 'E' format read (NIST FM110.FOR)

2005-05-09 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-09 
11:27 ---
Subject: Bug 19155

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-09 11:21:02

Modified files:
libgfortran/io : unix.c 
libgfortran: ChangeLog 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gfortran.dg: pr19155.f 

Log message:
PR libfortran/19155
* io/read.c (read_f): Accept 'e', 'E', 'd' and 'D' as first
non-blank characters of a real number.
* gfortran.dg/pr19155.f: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unix.c.diff?cvsroot=gccr1=1.22r2=1.23
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gccr1=1.208r2=1.209
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5448r2=1.5449
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr19155.f.diff?cvsroot=gccr1=NONEr2=1.1



-- 


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


[Bug libfortran/21376] libfortran E output format causes FPE

2005-05-09 Thread fxcoudert at gcc dot gnu dot org


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
  GCC build triplet|i686-pc-linux-gnu   |
   GCC host triplet|i686-pc-linux-gnu   |
 GCC target triplet|i686-pc-linux-gnu   |
   Last reconfirmed|-00-00 00:00:00 |2005-05-09 11:29:26
   date||


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


[Bug rtl-optimization/21461] [3.4/4.0 regression] miscompilation at -O2 in 3.4.x, 4.x

2005-05-09 Thread belyshev at depni dot sinp dot msu dot ru

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-05-09 11:30 ---
Could you please post backtrace of segfault? with both gcc-4.0 and gcc-3.4 if it
is different.

-- 
   What|Removed |Added

  Component|c   |rtl-optimization
   Keywords||wrong-code
  Known to work||3.3.6
Summary|miscompilation at -O2 in|[3.4/4.0 regression]
   |3.4.x, 4.x  |miscompilation at -O2 in
   ||3.4.x, 4.x


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


[Bug libfortran/19155] blanks not treated as zeros in 'E' format read (NIST FM110.FOR)

2005-05-09 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-09 
11:31 ---
Subject: Bug 19155

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-09 11:27:06

Modified files:
gcc/testsuite  : ChangeLog 
libgfortran: ChangeLog 
libgfortran/io : read.c 
Added files:
gcc/testsuite/gfortran.dg: pr19155.f 

Log message:
PR libfortran/19155
* io/read.c (read_f): Accept 'e', 'E', 'd' and 'D' as first
non-blank characters of a real number.
* gfortran.dg/pr19155.f: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.166r2=1.5084.2.167
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr19155.f.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.163.2.24r2=1.163.2.25
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/read.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.8r2=1.8.10.1



-- 


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


[Bug libfortran/19155] blanks not treated as zeros in 'E' format read (NIST FM110.FOR)

2005-05-09 Thread fxcoudert at gcc dot gnu dot org

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-05-09 
11:37 ---
I don't close this one since NIST test FM110 is not fixed with this patch.

-- 


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


[Bug c++/21427] [3.4/4.0 only] Failure in make_thunk, cp/method.c:145 when compiling with multiply-inherited members

2005-05-09 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-09 
11:53 ---
Subject: Bug 21427

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]   2005-05-09 11:48:12

Modified files:
gcc/cp : ChangeLog class.c cp-tree.h method.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/inherit: covariant12.C covariant13.C 

Log message:
cp:
PR c++/21427
Backport 2005-03-01  Nathan Sidwell  [EMAIL PROTECTED]
* class.c (update_vtable_entry_for_fn): Don't crash on invalid
covariancy.

* cp-tree.h (THUNK_TARGET): Expand comment.
* method.c (use_thunk): Make sure we also use the target, if that
is a thunk.

Backport 2005-02-11  Nathan Sidwell  [EMAIL PROTECTED]
* class.c (update_vtable_entry_for_fn): Walk the covariant's binfo
chain rather than using lookup_base.
testsuite:
PR c++/21427
* g++.dg/inherit/covariant13.C: New.
Backport 2005-03-01  Nathan Sidwell  [EMAIL PROTECTED]
* g++.dg/inherit/covariant12.C: New.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3892.2.217r2=1.3892.2.218
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.595.4.10r2=1.595.4.11
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.946.4.19r2=1.946.4.20
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/method.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.275.4.5r2=1.275.4.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.391r2=1.3389.2.392
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/covariant12.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.20.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/covariant13.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.2.1



-- 


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


[Bug c++/21427] [3.4/4.0 only] Failure in make_thunk, cp/method.c:145 when compiling with multiply-inherited members

2005-05-09 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-09 
11:56 ---
Subject: Bug 21427

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-09 11:52:45

Modified files:
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/inherit: covariant13.C 

Log message:
PR c++/21427
* g++.dg/inherit/covariant13.C: New.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5449r2=1.5450
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/covariant13.C.diff?cvsroot=gccr1=1.1r2=1.2



-- 


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


[Bug rtl-optimization/21461] [3.4/4.0 regression] miscompilation at -O2 in 3.4.x, 4.x

2005-05-09 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-09 
12:01 ---
Does -fno-strict-aliasing fix the problem?

Also is there any warnings from -Wstrict-aliasing?

If so this might not be a bug in gcc.

-- 


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


[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)

2005-05-09 Thread tobi at gcc dot gnu dot org

--- Additional Comments From tobi at gcc dot gnu dot org  2005-05-09 12:05 
---
Are you going to review that patch, Paul?  I don't think anybody else is 
qualified.

-- 
   What|Removed |Added

 CC||tobi at gcc dot gnu dot org


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


[Bug libfortran/15160] Generated files don't regenerate

2005-05-09 Thread tobi at gcc dot gnu dot org

--- Additional Comments From tobi at gcc dot gnu dot org  2005-05-09 12:06 
---
I don't think so.  Several people have used it, and noone complained about weird
things happening.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME


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


[Bug c++/18604] [3.4/4.0/4.1 Regression] Strong using lookup conflicts

2005-05-09 Thread giovannibajo at libero dot it

--- Additional Comments From giovannibajo at libero dot it  2005-05-09 
12:18 ---
There are others unqualified names as default template parmaters, for 
instance allocator. A good testcase would be something like:

--
struct less;
struct allocator;
struct vector;
struct set;
struct pair;
struct map;

/**/

#include set
#include vector
#include map
#include functional

/**/
--

which should compile without errors.

-- 


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


[Bug libgcj/21414] thread lib posix = runtime gij segfaults on Debian G/L Woody

2005-05-09 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-09 
12:20 ---
Closing as works for me.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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


[Bug rtl-optimization/21461] [3.4/4.0 regression] miscompilation at -O2 in 3.4.x, 4.x

2005-05-09 Thread duraid at octopus dot com dot au

--- Additional Comments From duraid at octopus dot com dot au  2005-05-09 
12:20 ---
(In reply to comment #3)
 Does -fno-strict-aliasing fix the problem?

Yes, oops.
 
 Also is there any warnings from -Wstrict-aliasing?

No.
 
 If so this might not be a bug in gcc.

Indeed. Sorry!


-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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


[Bug c++/21427] [3.4/4.0 only] Failure in make_thunk, cp/method.c:145 when compiling with multiply-inherited members

2005-05-09 Thread nathan at gcc dot gnu dot org

--- Additional Comments From nathan at gcc dot gnu dot org  2005-05-09 
12:21 ---
2005-05-08  Nathan Sidwell  [EMAIL PROTECTED]

PR c++/21427
Backport 2005-03-01  Nathan Sidwell  [EMAIL PROTECTED]
* class.c (update_vtable_entry_for_fn): Don't crash on invalid
covariancy. 

* cp-tree.h (THUNK_TARGET): Expand comment.
* method.c (use_thunk): Make sure we also use the target, if that
is a thunk.

Backport 2005-02-11  Nathan Sidwell  [EMAIL PROTECTED]
* class.c (update_vtable_entry_for_fn): Walk the covariant's binfo
chain rather than using lookup_base.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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


[Bug tree-optimization/21466] sqrt() function not vectorized

2005-05-09 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-09 
12:21 ---
Confirmed.

-- 
   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2005-05-09 12:21:28
   date||
Summary|sqrt() function not |sqrt() function not
   |vectorised  |vectorized


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


[Bug tree-optimization/21465] autovectorisation conflicts with -ffast-math

2005-05-09 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-09 
12:21 ---
Confirmed.

-- 
   What|Removed |Added

   Severity|normal  |minor
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2005-05-09 12:21:51
   date||


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


[Bug rtl-optimization/21461] [3.4/4.0 regression] miscompilation at -O2 in 3.4.x, 4.x

2005-05-09 Thread duraid at octopus dot com dot au

--- Additional Comments From duraid at octopus dot com dot au  2005-05-09 
12:24 ---
Actually, I shouldn't have closed this so hastily. The code _is_ pretty dirty
but I'm not sure GCC is really doing something legal at -O2.


-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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


[Bug libstdc++/18604] [3.4/4.0/4.1 Regression] Use of unqualified names conflict with names in global namespace

2005-05-09 Thread pcarlini at suse dot de

--- Additional Comments From pcarlini at suse dot de  2005-05-09 12:29 
---
I see, thanks. Indeed, I don't remember having paid attention to default 
template
arguments. Let's wait a bit for Gaby's opinion on the whole issue, and, in case,
let's quickly fix those problems.

-- 


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


[Bug c++/21467] New: ICE for template function if missing required default argument

2005-05-09 Thread sylvain dot joyeux at m4x dot org
The following code makes g++ 3.4.4 and g++ 3.3.6 (Debian) crash on my system. 
Adding the missing default argument for arg1 fixes the crash 
 
templatetypename F 
void test(F function, bool arg0 = false, bool arg1) 
{ 
} 
 
int main() 
{ 
test(main); 
} 
 
Detailed G++ versions: 
 
g++-3.3 (GCC) 3.3.6 (Debian 1:3.3.6-3) 
Reading specs from /usr/lib/gcc-lib/powerpc-linux/3.3.6/specs 
Configured with: ../src/configure -v 
--enable-languages=c,c++,java,f77,pascal,objc,ada --prefix=/usr 
--mandir=/usr/share/man --infodir=/usr/share/info 
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared 
--enable-__cxa_atexit --with-system-zlib --enable-nls 
--without-included-gettext --enable-clocale=gnu --enable-debug 
--enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc 
--disable-multilib powerpc-linux 
Thread model: posix 
gcc version 3.3.6 (Debian 1:3.3.6-3) 
 
g++-3.4 (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-13) 
Reading specs from /usr/lib/gcc/powerpc-linux/3.4.4/specs 
Configured with: ../src/configure -v 
--enable-languages=c,c++,java,f77,pascal,objc,ada --prefix=/usr 
--libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4 
--enable-shared --with-system-zlib --enable-nls --without-included-gettext 
--program-suffix=-3.4 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm 
--enable-java-awt=gtk --disable-multilib --disable-softfloat powerpc-linux 
Thread model: posix 
gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)

-- 
   Summary: ICE for template function if missing required default
argument
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sylvain dot joyeux at m4x dot org
CC: gcc-bugs at gcc dot gnu dot org


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


[Bug c++/21467] ICE for template function if missing required default argument

2005-05-09 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-09 
12:53 ---
Confirmed and not a regression.
Here is the backtrace:
#0  convert_default_arg (type=0xb7bf9804, arg=0x0, fn=0xb7c8c948, parmnum=2)
at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/call.c:4513
#1  0x0810a7c0 in build_function_call (function=0xb7c8c948, params=0x0)
at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/typeck.c:2618
#2  0x0805c8b9 in build_new_function_call (fn=0xb7c68e40, args=0xb7c68f30)
at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/call.c:2763
#3  0x08131ea0 in finish_call_expr (fn=0xb7c68e40, args=0xb7c68f30, 
disallow_virtual=0 '\0', 
koenig_p=1 '\001')
at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/semantics.c:1846
#4  0x080ef725 in cp_parser_unary_expression (parser=0xb7c8b2d8, address_p=0 
'\0', cast_p=0 '\0')
at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/parser.c:4158
#5  0x080f0192 in cp_parser_assignment_expression (parser=0xb7c8b2d8, cast_p=0 
'\0')
at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/parser.c:5413
#6  0x080f1939 in cp_parser_expression (parser=0xb7c8b2d8, cast_p=Variable 
cast_p is not 
available.
)


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||ice-on-invalid-code
  Known to fail||2.95.3 3.0.4 3.2.3 3.3.3
   ||3.4.0 4.0.0
   Last reconfirmed|-00-00 00:00:00 |2005-05-09 12:53:37
   date||
Summary|ICE for template function if|ICE for template function if
   |missing required default|missing required default
   |argument|argument


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


[Bug ada/14997] ncurses build fails with Ada

2005-05-09 Thread ebotcazou at gcc dot gnu dot org

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-05-09 
13:00 ---
Looking into it for AdaCore.


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-02-23 23:42:44 |2005-05-09 13:00:15
   date||


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


[Bug rtl-optimization/21461] [3.4/4.0 regression] miscompilation at -O2 in 3.4.x, 4.x

2005-05-09 Thread belyshev at depni dot sinp dot msu dot ru

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-05-09 13:23 ---
yes, please do not close this bug as i can reproduce it even with
-fno-strict-aliasing, but it seems it breaks at least in four files
(dfgparser.c, list.c, sharing.c, subst.c) so it could take some time to reduce.

I'd like to see your backtrace of segfault to compare with.
(compile it with -O2 -g, and do gdb --args ./a.out bug_trigger and then 'run'
and 'bt')


-- 


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


[Bug fortran/16939] Pointers not passed as subroutine arguments

2005-05-09 Thread tobi at gcc dot gnu dot org

--- Additional Comments From tobi at gcc dot gnu dot org  2005-05-09 13:40 
---
What is wrong is this from the .t02.original dump:
create (temp_ptr, _temp_ptr)
{
  char[1:15] * new_item;

  {
void * * ptr.0;

ptr.0 = (void * *) new_item;
_gfortran_allocate (ptr.0, 15, 0);
  }
  _gfortran_copy_string (15, new_item, 14,  A NEW STRING );
  temp_ptr = (char[1:15] * ) new_item;
  ^
  _gfortran_filename = pr16939.f90;
  _gfortran_line = 19;
  _gfortran_ioparm.unit = 6;
  _gfortran_ioparm.list_format = 1;
  _gfortran_st_write ();
  _gfortran_transfer_character (temp_ptr, 15);
  _gfortran_st_write_done ();
  goto __return_create;
  __return_create:;
}

The underlined line should be 
   temp_ptr = new_item
unless I misread something.  temp_ptr should point to the same character string
new_item points to.  The underlined statement makes it point to new_item 
instead.

-- 


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


[Bug rtl-optimization/21461] [3.4/4.0 regression] miscompilation at -O2 in 3.4.x, 4.x

2005-05-09 Thread duraid at octopus dot com dot au

--- Additional Comments From duraid at octopus dot com dot au  2005-05-09 
13:41 ---
Building on ia64 with the 3.4.4 compiler mentioned above, I get:
 
#0  red_ReduceInput (Search=0x600ac338, ClauseList=0x60112e18)
at clause.h:525
#1  0x4010dd90 in top_ProofSearch (Search=0x600ac338,
ProblemClauses=0x60123f68, InputFlags=0x600cd948,
UserPrecedence=0x0, BoundApplied=0x6fcf3768) at top.c:913
#2  0x40111350 in main (argc=2, argv=0x0) at top.c:1457



-- 


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


[Bug java/19285] Interfaces not initialized by static field access

2005-05-09 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-09 
13:41 ---
Subject: Bug 19285

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-09 13:32:30

Modified files:
libjava: ChangeLog prims.cc link.cc 
libjava/include: jvm.h 

Log message:
2005-04-27  Andrew Haley  [EMAIL PROTECTED]

PR java/19285
* prims.cc (_Jv_ResolvePoolEntry): New function.
* include/jvm.h (_Jv_Linker::find_field): New arg: found_class.
* link.cc (_Jv_Linker::find_field): New arg: found_class.
(resolve_pool_entry): Initialize the class in which a field is
found.
(link_symbol_table): Pass new arg to found_class.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.3391.2.59r2=1.3391.2.60
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/prims.cc.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.104.2.3r2=1.104.2.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/link.cc.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.10.2.2r2=1.10.2.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/include/jvm.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.77.2.3r2=1.77.2.4



-- 


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


[Bug libffi/21285] gij fails to handle NullPointerException exception

2005-05-09 Thread rth at gcc dot gnu dot org

--- Additional Comments From rth at gcc dot gnu dot org  2005-05-09 13:44 
---
Fixed.

-- 
   What|Removed |Added

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


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


[Bug target/21412] ICE loading TLS address

2005-05-09 Thread rth at gcc dot gnu dot org

--- Additional Comments From rth at gcc dot gnu dot org  2005-05-09 13:46 
---
Powerpc fixed; ia64 still broken.

-- 
   What|Removed |Added

Summary|[PowerPC] ICE loading TLS   |ICE loading TLS address
   |address |


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


[Bug java/19285] Interfaces not initialized by static field access

2005-05-09 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-09 
13:48 ---
Subject: Bug 19285

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-09 13:34:33

Modified files:
libjava/java/lang: Class.h 

Log message:
2005-04-27  Andrew Haley  [EMAIL PROTECTED]

PR java/19285
* prims.cc (_Jv_ResolvePoolEntry): New function.
* include/jvm.h (_Jv_Linker::find_field): New arg: found_class.
* link.cc (_Jv_Linker::find_field): New arg: found_class.
(resolve_pool_entry): Initialize the class in which a field is
found.
(link_symbol_table): Pass new arg to found_class.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/Class.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.78.2.1r2=1.78.2.2



-- 


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


[Bug libffi/21285] gij fails to handle NullPointerException exception

2005-05-09 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-09 
13:54 ---
Subject: Bug 21285

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-09 13:39:35

Modified files:
libffi : ChangeLog 
libffi/src/alpha: osf.S 

Log message:
PR libffi/21285
* src/alpha/osf.S: Update unwind into to match code.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.222.2.1r2=1.222.2.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/src/alpha/osf.S.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.9r2=1.9.72.1



-- 


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


[Bug libffi/21285] gij fails to handle NullPointerException exception

2005-05-09 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-09 
13:55 ---
Subject: Bug 21285

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]   2005-05-09 13:40:16

Modified files:
libffi : ChangeLog 
libffi/src/alpha: osf.S 

Log message:
PR libffi/21285
* src/alpha/osf.S: Update unwind into to match code.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.153.4.12r2=1.153.4.13
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/src/alpha/osf.S.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.9r2=1.9.10.1



-- 


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


[Bug tree-optimization/21407] [4.1 Regression] wrong code with upcast in C++

2005-05-09 Thread dberlin at gcc dot gnu dot org

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-05-09 
13:58 ---
This is a call clobbering bug.
We don't pass the address of c to the call, we pass the address of some
substructure.
As a result, we don't think foo can touch c.b, when it can beause of the upcast.
Whee.

I'd imagine the following will fix it, though i haven't tested it yet

Index: tree-ssa-operands.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-operands.c,v
retrieving revision 2.78
diff -u -p -r2.78 tree-ssa-operands.c
--- tree-ssa-operands.c 21 Apr 2005 18:05:26 -  2.78
+++ tree-ssa-operands.c 9 May 2005 13:57:44 -
@@ -1936,7 +1936,7 @@ note_addressable (tree var, stmt_ann_t s
  Otherwise, we take the address of all the subvariables, plus the real
  ones.  */

-  if (var  TREE_CODE (var) == COMPONENT_REF
+  if (0  var  TREE_CODE (var) == COMPONENT_REF
(ref = okay_component_ref_for_subvars (var, offset, size)))
 {
   subvar_t sv;

-- 


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


[Bug java/19285] Interfaces not initialized by static field access

2005-05-09 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-09 
14:00 ---
Subject: Bug 19285

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-09 13:50:01

Modified files:
gcc/java   : ChangeLog java-tree.h expr.c builtins.c decl.c 
 class.c constants.c 

Log message:
2005-04-28  Andrew Haley  [EMAIL PROTECTED]

PR java/19285
* java-tree.h (soft_resolvepoolentry_node): New.
(alloc_constant_fieldref): Declare.
* expr.c (expand_java_field_op): Don't call class_init for
accesses to static fields with indirect dispatch.
* builtins.c (initialize_builtins): Add __builtin_expect.
* decl.c (soft_resolvepoolentry_node): New variable.
(java_init_decl_processing): Create a decl for
_Jv_ResolvePoolEntry.
* class.c (build_fieldref_cache_entry): New function.
* class.c (build_static_field_ref): New function.
(build_static_field_ref): Rewrite for indirect dispatch.
* constants.c (find_name_and_type_constant_tree): New function.
(alloc_constant_fieldref): Likewise.
(build_constants_constructor): Handle CONSTANT_Fieldref and
CONSTANT_NameAndType.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.1556.2.18r2=1.1556.2.19
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/java-tree.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.226r2=1.226.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/expr.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.218.4.3r2=1.218.4.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/builtins.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.29r2=1.29.4.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/decl.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.209.4.2r2=1.209.4.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/class.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.220.8.1r2=1.220.8.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/constants.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.40r2=1.40.34.1



-- 


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


[Bug c++/21467] ICE for template function if missing required default argument

2005-05-09 Thread giovannibajo at libero dot it

--- Additional Comments From giovannibajo at libero dot it  2005-05-09 
14:03 ---
The real bug is this accepts-invalid:


templatetypename F 
void test(F function, bool arg0 = false, bool arg1) 
{} 


The ICE when you call the function is just a fallout of not having properly 
validated the parameter declarations.


-- 
   What|Removed |Added

   Keywords||accepts-invalid


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


[Bug target/21397] [4.0/4.1 regression] arm: -march overrides -mtune

2005-05-09 Thread rearnsha at gcc dot gnu dot org

--- Additional Comments From rearnsha at gcc dot gnu dot org  2005-05-09 
14:04 ---
This is, of course, a regression from 3.4.x



-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rearnsha at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
Summary|arm: -march overrides -mtune|[4.0/4.1 regression] arm: -
   ||march overrides -mtune


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


[Bug target/21397] [4.0/4.1 regression] arm: -march overrides -mtune

2005-05-09 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-09 
14:20 ---
Subject: Bug 21397

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-09 14:15:51

Modified files:
gcc: ChangeLog 
gcc/config/arm : arm.c 

Log message:
PR target/21397
* arm.c (ARM_OPT_SET_CPU, ARM_OPT_SET_ARCH, ARM_OPT_SET_TUNE): Define.
(arm_override_options): Use them instead of manifest constants.  Don't
allow -march to override the -mtune setting.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8670r2=2.8671
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/arm.c.diff?cvsroot=gccr1=1.451r2=1.452



-- 


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


[Bug c++/21467] ICE for template function if missing required default argument

2005-05-09 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-09 
14:22 ---


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

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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


[Bug c++/16829] default parameter can be not one of the last in template function

2005-05-09 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-09 
14:22 ---
*** Bug 21467 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||sylvain dot joyeux at m4x
   ||dot org


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


[Bug libfortran/21468] New: vectorizing libfortran

2005-05-09 Thread tkoenig at gcc dot gnu dot org
Libgfortran doesn't vectorize very well at the moment.

I added some vectorization options to the Makefile on
ia64-unknown-linux-gnu, ran make under script and grepped
for VECTORIZED.  This is what I got:

../../../gcc-4.1-20050508/libgfortran/intrinsics/date_and_time.c:235: note: 
LOOP VECTORIZED.

None of the matmul, dotprod, ... intrinsics were vectorized.

This would probably require further improvements in gcc's vectorization
capabilities, plus special-casing stride 1 in many cases.

-- 
   Summary: vectorizing libfortran
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P2
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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


[Bug rtl-optimization/21469] New: nternal compiler error: in spill_failure, at reload1.c:1897

2005-05-09 Thread pbrook at gcc dot gnu dot org
Compiling the following code with gcc -march=i386 -O2 gives and ICE.
-march=i686 doesn't have the same failure.
gcc version 4.1.0 20050507 (experimental)
3.3 and 3.4 both compile the code OK.

typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef union {
  uint8_t _b[8];
  uint16_t _w[2];
} MMXReg;
register MMXReg *env asm(ebp);
register long T0 asm(ebx);
register long T1 asm(esi);
register long T2 asm(edi);
void foo (int order) {
  MMXReg r;

  r._w[0] = env-_w[order];
  *env = r;
}



t2.c:16: error: unable to find a register to spill in class 'GENERAL_REGS'
t2.c:16: error: this is the insn:
(insn:HI 14 28 16 0 (set (strict_low_part (subreg:HI (reg/v:DI 59 [ r ]) 0))
(mem/s:HI (plus:SI (mult:SI (reg/v:SI 60 [ order ])
(const_int 2 [0x2]))
(reg:SI 58 [ env.0 ])) [0 variable._w S2 A16])) 42
{*movstricthi_1} (insn_list:REG_DEP_TRUE 12 (insn_list:REG_DEP_TRUE 6
(insn_list:REG_DEP_TRUE 26 (nil
(expr_list:REG_DEAD (reg/v:SI 60 [ order ])
(nil)))
t2.c:16: internal compiler error: in spill_failure, at reload1.c:1897

-- 
   Summary: nternal compiler error: in spill_failure, at
reload1.c:1897
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pbrook at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-pc-linux-gnu
  GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu


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


[Bug middle-end/21237] [4.0/4.1 Regression] unnecessary __cmpdi2 usage?

2005-05-09 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-09 
14:46 ---
Subject: Bug 21237

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-09 14:45:59

Modified files:
gcc: ChangeLog 

Log message:
PR middle-end/21237
* dojump.c (do_jump, MINUS_EXPR): Build NE_EXPR and fall through
to NE_EXPR case.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8673r2=2.8674



-- 


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


[Bug fortran/21470] New: mark subroutine arguments __restrict__

2005-05-09 Thread tkoenig at gcc dot gnu dot org
Fortran subroutine arguments should be marked as
__restrict__.  Currently, the following code isn't
vectorized:

$ cat loopsum.f90
subroutine foo(a,b,c,n)
  real, dimension(n), intent(in) :: a,b
  real, dimension(n), intent(out) :: c
  do i=1,n
c(i) = a(i)+b(i)
  end do
end
$ gfortran -O -S -ftree-vectorize -ftree-vectorizer-verbose=5 loopsum.f90

loopsum.f90:4: note: not vectorized: can't determine dependence between: (*a_18)
[D.527_17] and (*c_25)[D.527_17]
loopsum.f90:1: note: vectorized 0 loops in function.
$ gfortran -v
Using built-in specs.
Target: ia64-unknown-linux-gnu
Configured with: ../gcc-4.1-20050508/configure --prefix=/home/zfkts --enable-
languages=c,f95
Thread model: posix
gcc version 4.1.0 20050508 (experimental)

-- 
   Summary: mark subroutine arguments __restrict__
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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


[Bug fortran/21470] mark subroutine arguments __restrict__

2005-05-09 Thread tkoenig at gcc dot gnu dot org


-- 
   What|Removed |Added

   Severity|normal  |enhancement


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


[Bug fortran/21471] New: 'POSITION = APPEND' doesn't seem to work

2005-05-09 Thread P dot Schaffnit at access dot rwth-aachen dot de
Hi!

I am under the impression that the gfortran compiler doesn't (at least in some
cases) handle well the APPEND file access, and rather overwrites the contents
of the file...

Can you help me with that?

Thanks!

Philippe


PS: gfortran -vUsing built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/USER/philippe/Irix/Compilation/gcc/Sources/Release_4_0_0/gcc/configure
--prefix=/usr1/MICRESS/Philippe/Tools/Gcc
--with-mpfr=/usr1/MICRESS/Philippe/Tools/Mpfr
--with-gmp=/usr1/MICRESS/Philippe/Tools/Gmp
Thread model: posix
gcc version 4.1.0 20050503 (experimental)

PPS: the command I use to run this test:
gfortran --static -o Hello_World Hello_World.f90 ; rm -f File ; touch File ;
./Hello_World ; cat File

PPPS: a small example I put together: File should contains 13 times
Hello_World, but in fact only has the last one
!==!
! **
! **
! *T e s t *
! **
! **
!==!
!
!==!
! Declaration
!==!
!
  PROGRAM Test
!
  INTEGER::   Counter
!
  CHARACTER ( LEN = 250 ), PARAMETER::   String = Hello world!
!
!==!
! Begin
!==!
!
!
  WRITE ( 6, (/A) ) Beginning of screen output
  DO Counter = 1, 13
 OPEN ( UNIT = 13, FILE = File, FORM = FORMATTED,  
  POSITION = APPEND, STATUS = OLD )
 WRITE ( UNIT = 13, FMT = (A,I5) ) TRIM(String), Counter
 CLOSE ( UNIT = 13 )
 WRITE ( 6, (A,I3) ) TRIM(String), Counter
  END DO
  WRITE ( 6, (A/) ) End of screen output
!
!
!==!
! End
!==!
  END PROGRAM Test

-- 
   Summary: 'POSITION = APPEND' doesn't seem to work
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: P dot Schaffnit at access dot rwth-aachen dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu


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


[Bug rtl-optimization/13565] Register spill problem in x86_64 compiler

2005-05-09 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-09 
14:50 ---


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

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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


[Bug rtl-optimization/9085] Unable to find register to spill when optimizing

2005-05-09 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-09 
14:51 ---
*** Bug 13565 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||marc at mrousseau dot org


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


[Bug rtl-optimization/21469] nternal compiler error: in spill_failure, at reload1.c:1897

2005-05-09 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-09 
14:51 ---
Why do people use global registers :(.

-- 


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


[Bug target/21397] [4.0/4.1 regression] arm: -march overrides -mtune

2005-05-09 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-09 
14:53 ---
Subject: Bug 21397

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-09 14:53:20

Modified files:
gcc: ChangeLog 
gcc/config/arm : arm.c 

Log message:
PR target/21397
* arm.c (ARM_OPT_SET_CPU, ARM_OPT_SET_ARCH, ARM_OPT_SET_TUNE): Define.
(arm_override_options): Use them instead of manifest constants.  Don't
allow -march to override the -mtune setting.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.232r2=2.7592.2.233
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/arm.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.430.2.1r2=1.430.2.2



-- 


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


[Bug tree-optimization/21470] -fargument-noalias-global has no effect for the vectorizer

2005-05-09 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-09 
14:53 ---
Actually -fargument-noalias-global is set to true for fortran and should be 
respected instead of 
marking them as restrict.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|fortran |tree-optimization
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-09 14:53:51
   date||
Summary|mark subroutine arguments   |-fargument-noalias-global
   |__restrict__|has no effect for the
   ||vectorizer


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


[Bug target/21397] [4.0/4.1 regression] arm: -march overrides -mtune

2005-05-09 Thread rearnsha at gcc dot gnu dot org

--- Additional Comments From rearnsha at gcc dot gnu dot org  2005-05-09 
15:04 ---
fixed

-- 
   What|Removed |Added

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


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


[Bug c++/21308] [3.4/4.0/4.1 Regression] Very high compile time

2005-05-09 Thread jakub at gcc dot gnu dot org

--- Additional Comments From jakub at gcc dot gnu dot org  2005-05-09 15:26 
---
Do we really have to call walk_subobject_offsets on every single array element?
Couldn't we delay that to the time anybody would be looking at that info?
Say extend the offsets splay tree, so that there would not only be INTEGER_CST
key nodes representing particular offsets, but also nodes representing an
offset interval, with value a TREE_VEC that could then be used to recreate
that information (i.e. contain enough info to call walk_subobject_offsets
in a loop with record_subobject_offset fn).
Instead of calling walk_subobject_offsets here 1  21 times, we could e.g.
call it on the first and last array element only and represent the middle
of the array (if any) with an interval.

-- 


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


[Bug tree-optimization/21470] -fargument-noalias-global has no effect for the vectorizer

2005-05-09 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-09 
15:54 ---
If the aliasing information is correct on the VOPS, I would assume that the 
vectorizer would not have 
problems with it.

Note there is another bug about this option, see PR 17064.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  BugsThisDependsOn||17064
   Keywords||alias


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


[Bug fortran/16939] Pointers not passed as subroutine arguments

2005-05-09 Thread paulthomas2 at wanadoo dot fr

--- Additional Comments From paulthomas2 at wanadoo dot fr  2005-05-09 
16:06 ---
That's right Tobi

The patch that fixes this bug and regtests is:

Index: trans-expr.c
===
RCS file: /cvsroot/gcc/gcc/gcc/fortran/trans-expr.c,v
retrieving revision 1.42
diff -p -c -3 -r1.42 trans-expr.c
*** trans-expr.c29 Apr 2005 15:31:33 -  1.42
--- trans-expr.c9 May 2005 14:41:23 -
*** gfc_conv_variable (gfc_se * se, gfc_expr
*** 360,365 
--- 360,372 
if (sym-attr.dummy
   sym-ts.type != BT_CHARACTER
   !sym-attr.dimension)
+   se-expr = gfc_build_indirect_ref (se-expr);
+
+   /*Dereference dummy args that are character pointers. */
+   if (sym-attr.dummy
+   sym-attr.pointer
+  sym-ts.type == BT_CHARACTER
+  !sym-attr.dimension)
se-expr = gfc_build_indirect_ref (se-expr);

/* Dereference pointer variables.  */

I will do an update, bootstrap and regtest tonight before submitting this to 
the lists.  It should be posted tonight.

-- 


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


[Bug fortran/16939] Pointers not passed as subroutine arguments

2005-05-09 Thread paulthomas2 at wanadoo dot fr

--- Additional Comments From paulthomas2 at wanadoo dot fr  2005-05-09 
16:08 ---
Subject: Re:  Pointers not passed as subroutine arguments

The following fixes PR16939 and regtests.  I'll do a full synchronisatio, 
bootstrap and regtest before posting it on the lists:

Best regards

Paul

Index: trans-expr.c
===
RCS file: /cvsroot/gcc/gcc/gcc/fortran/trans-expr.c,v
retrieving revision 1.42
diff -p -c -3 -r1.42 trans-expr.c
*** trans-expr.c29 Apr 2005 15:31:33 -  1.42
--- trans-expr.c9 May 2005 14:41:23 -
*** gfc_conv_variable (gfc_se * se, gfc_expr
*** 360,365 
--- 360,372 
if (sym-attr.dummy
   sym-ts.type != BT_CHARACTER
   !sym-attr.dimension)
+   se-expr = gfc_build_indirect_ref (se-expr);
+
+   /*Dereference dummy args that are character pointers. */
+   if (sym-attr.dummy
+   sym-attr.pointer
+  sym-ts.type == BT_CHARACTER
+  !sym-attr.dimension)
se-expr = gfc_build_indirect_ref (se-expr);

/* Dereference pointer variables.  */




-- 


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


[Bug target/21472] New: Gcc generates CALL16 reloc that ld objects to

2005-05-09 Thread pkoning at equallogic dot com
Compiling lib/csu/common_elf/crtbegin.c in the NetBSD 1.6.2 source tree with gcc
4.0.0 and binutils 2.16, I get complaints from ld:
  crtbeginS.o: CALL16 reloc at 0xfc not against global symbol

The call16 is in the .s file generated by gcc, but I can't tell why it's any
different from the others.  Will attach .i and .s files (it would be nice if you
could do that when entering a bug...)

-- 
   Summary: Gcc generates CALL16 reloc that ld objects to
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pkoning at equallogic dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-netbsdelf
  GCC host triplet: i386-netbsdelf
GCC target triplet: mipsel-netbsdelf


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


[Bug target/21472] Gcc generates CALL16 reloc that ld objects to

2005-05-09 Thread pkoning at equallogic dot com

--- Additional Comments From pkoning at equallogic dot com  2005-05-09 
16:30 ---
Created an attachment (id=8845)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8845action=view)
Preprocessed source file of the code that shows the problem


-- 


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


[Bug target/21472] Gcc generates CALL16 reloc that ld objects to

2005-05-09 Thread pkoning at equallogic dot com

--- Additional Comments From pkoning at equallogic dot com  2005-05-09 
16:31 ---
Created an attachment (id=8846)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8846action=view)
Assembly file generated by gcc 4.0.0


-- 


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


warning and _Complex_I

2005-05-09 Thread Laurent Deniau
I have not found in the bug list of the GCC Bugzilla something about an 
invalid warning:

warning: imaginary constants are a GCC extension
when _Complex_I is used with -std=c99 -pedantic. Did I missed something?
	Laurent.


[Bug target/14981] [3.4 Regression] ICE in _mm_xor_pd for SSE2 with -O1

2005-05-09 Thread jakub at gcc dot gnu dot org

--- Additional Comments From jakub at gcc dot gnu dot org  2005-05-09 16:50 
---
This patch creates regressions on i?86:
FAIL: gcc.dg/20020523-1.c (test for excess errors)
WARNING: gcc.dg/20020523-1.c compilation failed to produce executable
FAIL: gcc.dg/20020523-2.c (test for excess errors)
WARNING: gcc.dg/20020523-2.c compilation failed to produce executable

./xgcc -B ./ -v -m32 -march=pentium3 -msse -ffast-math -O2 20020523-1.c
Reading specs from ./specs
Configured with: ../configure --enable-languages=c,c++
Thread model: posix
gcc version 3.4.4 20050509 (prerelease)
 ./cc1 -quiet -v -iprefix
/usr/src/gcc-3.4/obj/gcc/../lib/gcc/x86_64-unknown-linux-gnu/3.4.4/ -isystem
./include 20020523-1.c -quiet -dumpbase 20020523-1.c -m32 -march=pentium3 -msse
-auxbase 20020523-1 -O2 -version -ffast-math -o /tmp/ccwFAGHO.s
ignoring nonexistent directory
/usr/src/gcc-3.4/obj/gcc/../lib/gcc/x86_64-unknown-linux-gnu/3.4.4/include
ignoring nonexistent directory
/usr/src/gcc-3.4/obj/gcc/../lib/gcc/x86_64-unknown-linux-gnu/3.4.4/../../../../x86_64-unknown-linux-gnu/include
ignoring nonexistent directory NONE/include
ignoring nonexistent directory
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/3.4.4/include
ignoring nonexistent directory
/usr/local/lib/../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
 ./include
 /usr/local/include
 /usr/include
End of search list.
GNU C version 3.4.4 20050509 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 3.4.3 20050227 (Red Hat 3.4.3-22.fc3).
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128053
20020523-1.c: In function `main':
20020523-1.c:65: error: could not split insn
(insn:TI 108 123 112 (set (reg:SF 22 xmm1)
(if_then_else:SF (gt (reg:SF 22 xmm1)
(mem/u/f:SF (symbol_ref/u:SI (*.LC2) [flags 0x2]) [2 S4 A32]))
(reg:SF 21 xmm0 [76])
(const_double:SF 0.0 [0x0.0p+0]))) 663 {*sse_movsfcc_const0_1}
(insn_list 123 (insn_list 122 (insn_list:REG_DEP_ANTI 106 (nil
(expr_list:REG_DEAD (reg:SF 21 xmm0 [76])
(expr_list:REG_EQUIV (mem/f:SF (reg/f:SI 7 sp) [0 S4 A32])
(nil
20020523-1.c:65: internal compiler error: in final_scan_insn, at final.c:2429
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.

Reverting this patch fixes it.

-- 


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


[Bug c/21473] New: Number Representation - Octal

2005-05-09 Thread robert dot amodeo at ntlworld dot com
This bug was reported back in 1998/07/19 by Alexander Favorov msg00504.html . 
It is well described by him. The bug still exists as of gcc 3.3.3 . 
Its a simple parsing error. 
My understanding of C is: 
'\10' is ten (decimal) 
'\010' is eight (octal) 
'\0x10' is sixteen (hexadecimal) 
For a number to be octal, it must be preceeded by a zero, otherwise it is 
decimal. 
Book Reference: C: The Complete Reference 3rd Edition 
Author: Schildt, Herbert 
Page 37.

-- 
   Summary: Number Representation - Octal
   Product: gcc
   Version: 3.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: robert dot amodeo at ntlworld dot com
CC: gcc-bugs at gcc dot gnu dot org


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


[Bug c/21473] Number Representation - Octal

2005-05-09 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-09 
17:07 ---
Not in charactors. '/xx' is octal aways.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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


[Bug target/21472] Gcc generates CALL16 reloc that ld objects to

2005-05-09 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-09 
17:15 ---
lw  $25,%call16(fini_fallthru)($28)

I want to say the above is the problem and it is a local symbol but to GCC it 
is a global one.

-- 
   What|Removed |Added

   Keywords||build


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


[Bug libfortran/21471] 'POSITION = APPEND' doesn't seem to work

2005-05-09 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-09 
17:21 ---
It is a bug in the library as it is being passed correctly to it:
  _gfortran_ioparm.position = APPEND;
  _gfortran_ioparm.position_len = 6;

-- 
   What|Removed |Added

  Component|fortran |libfortran


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


[Bug c/21474] New: missed optimizations when comparing address to NULL

2005-05-09 Thread trt at acm dot org
The program below gives some expressions which gcc could, but does not, evaluate
to true.  E.g. gcc considers p-a true, even when a is the first element
of the struct (is this a bug?), but does not consider p-b[3] to be true.

struct foo {int a, b[10];};
 
int subr(int i, struct foo *p)
{
int x[10];
 
#if 0
// gcc folds this
if (p-a) return 1;
#else
// but not these
if (p-b[3]) return 1;
 
if (x[3] != 0) return 1;
if (x[i] != 0) return 1;  // not sure if this one is safe to fold
#endif
return 0;
}

-- 
   Summary: missed optimizations when comparing address to NULL
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: trt at acm dot org
CC: gcc-bugs at gcc dot gnu dot org


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


[Bug middle-end/21474] missed optimizations when comparing address to NULL

2005-05-09 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-09 
17:26 ---
Actually I don't think it is safe to fold any of these.

-- 
   What|Removed |Added

  Component|c   |middle-end


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


[Bug target/20695] sh64-*-* port deos not handle 32 / 64 bit conversions properly

2005-05-09 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-09 
17:44 ---
Subject: Bug 20695

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-09 17:42:56

Modified files:
gcc/doc: invoke.texi 
gcc/config/sh  : crt1.asm elf.h lib1funcs.asm libgcc-excl.ver 
 linux.h netbsd-elf.h sh-modes.def sh-protos.h 
 sh.c sh.h sh.md shmedia.md sshmedia.h t-linux 
 t-sh64 ushmedia.h 
gcc/testsuite  : ChangeLog 
gcc/testsuite/gcc.dg: 20021029-1.c pr15784-3.c 
Added files:
gcc/config/sh  : divtab.c newlib.h predicates.md superh.h 
 superh64.h t-superh 

Log message:
gcc:

2005-05-09  Jorn Rennecke [EMAIL PROTECTED]

* config/sh/sh.h (OVERRIDE_OPTIONS): Don't set flag_finite_math_only
if flag_signaling_nans is set.
For TARGET_SH2E, if flag_finite_math_only is not set, set IEEE_BIT.
* doc/invoke.texi (SH -mieee): Document relation to -ffinite-math-only.

2005-05-06  Jorn Rennecke [EMAIL PROTECTED]
Merge of sh-elf specific patches from sh-elf-4_1-branch:

2005-05-05  Kaz Kojima  [EMAIL PROTECTED]

* config/sh/sh.h (ASM_OUTPUT_REG_PUSH): Provide SHMEDIA version.
(ASM_OUTPUT_REG_POP): Likewise.

2005-05-05  Jorn Rennecke  [EMAIL PROTECTED]
Kaz Kojima  [EMAIL PROTECTED]

* config/sh/sh.c (sh_builtin_saveregs): Use copy_to_mode_reg
and plus_constant.

2005-05-04  Kaz Kojima  [EMAIL PROTECTED]

* config/sh/sh.c (sh_div_strategy): Initialize with
SH_DIV_STRATEGY_DEFAULT.
* config/sh/sh.c (SH_DIV_STR_FOR_SIZE): Define.
(SH_DIV_STRATEGY_DEFAULT): Likewise.
(OPTIMIZATION_OPTIONS): Set sh_div_str to SH_DIV_STR_FOR_SIZE
when optimized for size.
* config/sh/linux.h (SH_DIV_STRATEGY_DEFAULT): Redefine.
(SH_DIV_STR_FOR_SIZE): Likewise.
* config/sh/netbsd-elf.h (SH_DIV_STRATEGY_DEFAULT): Likewise.
(SH_DIV_STR_FOR_SIZE): Likewise.

2005-05-04  Jorn Rennecke [EMAIL PROTECTED]

* config/sh/sh-modes.def (PDImode): Add.
* config/sh/sh-protos.h (shmedia_prepare_call_address): Declare.
* config/sh/sh.c (print_operand): Handle IF_THEN_ELSE.
(target_reg_operand): Allow PDImode.
(sh_register_move_cost): If neither sh_gettrcost_str nor
TARGET_PT_FIXED is set, assume gettr costs 100.
(shmedia_prepare_call_address): New function.
(sh_gettrcost_str): Initialize to empty string.
(sh_divsi3_libfunc): New variable.
* config/sh/sh.h (PT_FIXED_BIT, TARGET_INVALID_SYMBOLS): Define.
(TARGET_SWITCH_SH5_32_ANY_EXTRA): Likewise.
(TARGET_SWITCH_SH5_MEDIA_ANY_EXTRA): Likewise.
(TARGET_SWITCHES): Use TARGET_SWITCH_SH5_32_ANY_EXTRA and
TARGET_SWITCH_SH5_MEDIA_ANY_EXTRA.
(TARGET_OPTIONS): Add -mdivsi3_libfunc.
(OVERRIDE_OPTIONS): Set sh_divsi3_libfunc if it hasn't been set
by the user.
Also set flag_no_function_cse for (TARGET_SHMEDIA  !TARGET_PT_FIXED).
(HARD_REGNO_MODE_OK): Allow TARGET_REGS in PDImode.
(CONSTRAINT_LEN): Remove debug version.
(SECONDARY_INOUT_RELOAD_CLASS:) Break out of
(SECONDARY_OUTPUT_RELOAD_CLASS).  Use EXTRA_CONSTRAINT_Csy for check
if a target register needs a secondary reload through GENERAL_REGS.
(SECONDARY_INPUT_RELOAD_CLASS): Use SECONDARY_INOUT_RELOAD_CLASS.
(sh_divsi3_libfunc): Declare.
(FUNCTION_PROFILER): Provide SHMEDIA version.
* config/sh/predicates.md: New file.
* config/sh/sh.md (predicates.md): Include.
(divsi_inv_call_combine, divsi3): Use sh_divsi3_libfunc.
(reload_insi): Fix predicates and constraints.
(ptabs): New expander.
(*extendsipdi_media, *truncdipdi_media): New insns.
(call, call_value, sibcall): Use shmedia_prepare_call_address.
* doc/invoke.texi (-multcost, -mdiv): Document new SH options.
(-mdivsi3_libfunc, -madjust-unroll, -mindexed-addressing): Likewise.
(-mgettrcost, -mpt-fixed, -minvalid-symbols): Likewise.

2005-04-11  Jorn Rennecke [EMAIL PROTECTED]

* sh.c (print_operand): Remove sh_rep_vec extraction.
(sh_output_mi_thunk): Make i unsigned.

* sh.c (TARGET_ADJUST_UNROLL_MAX): Only redefine if already defined.
(sh_adjust_unroll_max): Only define if TARGET_ADJUST_UNROLL_MAX
is defined.  Update label detection code and iteration lookup,
enable basic functionality, but without IV analysis.

2005-04-11  Jorn Rennecke [EMAIL PROTECTED]

* sh.h (OPTIMIZATION_OPTIONS): Don't make setting of

[Bug rtl-optimization/21461] [3.4/4.0 regression] miscompilation at -O2 in 3.4.x, 4.x

2005-05-09 Thread belyshev at depni dot sinp dot msu dot ru

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-05-09 17:45 ---
This code:

memory.h:413:
*(POINTER *)Freepointer  = memory_ARRAY[Size]-free;
memory_ARRAY[Size]-free = Freepointer;

is invalid, because you are changing object of some type via pointer of type
(void **). Either it should be rewritten using unions, or -fno-strict-aliasing
option should be used. More on this here:
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fstrict_002daliasing-524

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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


[Bug rtl-optimization/21138] wrong code in sixtrack for -fmodulo-sched

2005-05-09 Thread janis at gcc dot gnu dot org

--- Additional Comments From janis at gcc dot gnu dot org  2005-05-09 19:32 
---
sixtrack works fine for me with -m64 -O2 with both SPEC's test input and its
ref output, for all of my daily builds since 20050503, while with the addition
of -fmodulo-sched it gets miscompares.  lucas is now passing again, but apsi is
still gettting miscompares with -m64 -O2 -fmodulo-sched.

Every week or so I run SPEC CPU2000 with GCC mainline built the previous night
and run the tests using test input, for each of about 40 sets of GCC command
line options with -m32 and then with -m64.  This has found several regressions
(21272, 21155, 21054, 21048, 21030, 20813 in the last month).  Almost all of
the failures I see are ICEs; the ones reported here with -fmodulo-sched are
the only runtime failures I've seen for a long time.

I'm running the tests now with the 20050508 compiler (last night's build
failed) and will let you know if failures with other options look related
to this one.  The only known problem right now is PR 21155, intermittent
ICEs with -ftree-vectorize.

-- 


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


[Bug middle-end/21460] Internal compiler error in calc_dfs_tree on valid code

2005-05-09 Thread pinskia at gcc dot gnu dot org


-- 
   What|Removed |Added

  Component|tree-optimization   |middle-end
   Keywords||ice-on-valid-code


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


[Bug libstdc++/21238] conflicting typedef __numpunct_cache_CharT __cache_type; in std::numpunctCharT makes specialization impossible

2005-05-09 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-09 
19:59 ---
Subject: Bug 21238

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-09 19:59:17

Modified files:
libstdc++-v3   : ChangeLog 
libstdc++-v3/include/bits: locale_facets.tcc 
libstdc++-v3/testsuite: testsuite_character.h 
testsuite_character.cc 
Added files:
libstdc++-v3/testsuite/22_locale/num_get: 3.cc 
libstdc++-v3/testsuite/22_locale/num_put: 3.cc 
libstdc++-v3/testsuite/22_locale/money_get: 3.cc 
libstdc++-v3/testsuite/22_locale/money_put: 3.cc 

Log message:
2005-05-09  Paolo Carlini  [EMAIL PROTECTED]

PR libstdc++/21238
* include/bits/locale_facets.tcc (num_get::_M_extract_float,
num_get::_M_extract_int, num_get::do_get(bool),
num_put::_M_insert_int, num_put::_M_insert_float,
num_put::do_put(bool), money_get::_M_extract,
money_put::_M_insert): Adjust the __cache_type typedef not to
forward to a numpunct/moneypunct typedef.
* testsuite/testsuite_character.h: Add pod_uint and its numpunct
and moneypunct specializations.
* testsuite/testsuite_character.cc: Add numpunctpod_uint::id
and moneypunctpod_uint::id.
* testsuite/22_locale/num_get/3.cc: New.
* testsuite/22_locale/num_put/3.cc: Likewise.
* testsuite/22_locale/money_get/3.cc: Likewise.
* testsuite/22_locale/money_put/3.cc: Likewise.

* include/bits/locale_facets.tcc (money_put::_M_insert,
time_get::_M_extract_name): Prefer operator== to operator!=
on char_types.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.2917.2.43r2=1.2917.2.44
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/locale_facets.tcc.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.211.12.3r2=1.211.12.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/testsuite_character.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.2.54.2r2=1.2.54.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/testsuite_character.cc.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.3.4.2r2=1.3.4.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/22_locale/num_get/3.cc.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.4.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/22_locale/num_put/3.cc.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.4.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/22_locale/money_get/3.cc.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.4.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/22_locale/money_put/3.cc.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.4.1



-- 


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


[Bug libstdc++/21238] conflicting typedef __numpunct_cache_CharT __cache_type; in std::numpunctCharT makes specialization impossible

2005-05-09 Thread pcarlini at suse dot de

--- Additional Comments From pcarlini at suse dot de  2005-05-09 20:01 
---
Fixed for 4.0.1.

-- 
   What|Removed |Added

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


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


[Bug rtl-optimization/21469] nternal compiler error: in spill_failure, at reload1.c:1897

2005-05-09 Thread pbrook at gcc dot gnu dot org

--- Additional Comments From pbrook at gcc dot gnu dot org  2005-05-09 
20:04 ---
Annother testcase. This one fails at -O2 with gcc 4.1.0 20050507 and 4.0.1 
20050430.
This is a regression from 3.4.

typedef unsigned long long uint64_t;
register int *env asm (ebp);
register long T0 asm (ebx);
register long T1 asm (esi);
register long T2 asm (edi);

void foo(void);

void
bar (long physaddr, uint64_t v)
{
  if (*env)
{
  foo ();
  *(uint64_t *) (physaddr + *env) = v;
}
}


-- 


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


[Bug target/18655] Incorrect data in .debug_frame section for PowerPC

2005-05-09 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-09 
20:20 ---
Subject: Bug 18655

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-09 20:20:26

Modified files:
gcc: ChangeLog dwarf2out.c 

Log message:
PR 18655
* dwarf2out.c (output_call_frame_info): Use DWARF2_FRAME_REG_OUT
before outputting DWARF_FRAME_RETURN_COLUMN.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8692r2=2.8693
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dwarf2out.c.diff?cvsroot=gccr1=1.592r2=1.593



-- 


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


[Bug target/21351] internal compiler error with sse

2005-05-09 Thread js at jeannot dot org

--- Additional Comments From js at jeannot dot org  2005-05-09 20:21 ---
The bug is still present gcc version 3.4.4 20050506.

-- 


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


[Bug rtl-optimization/21469] nternal compiler error: in spill_failure, at reload1.c:1897

2005-05-09 Thread belyshev at depni dot sinp dot msu dot ru

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-05-09 20:28 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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


[Bug target/16185] ICE: in spill_failure, at reload1.c:1892, global registers and long long

2005-05-09 Thread belyshev at depni dot sinp dot msu dot ru

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-05-09 20:28 ---
*** Bug 21469 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||pbrook at gcc dot gnu dot
   ||org


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


[Bug rtl-optimization/21469] nternal compiler error: in spill_failure, at reload1.c:1897

2005-05-09 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-09 
20:30 ---
Hmm, I think only the second example is a dup.

-- 


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


  1   2   >