[Bug c++/35117] New: Vectorization on power PC

[eyal at geomage dot com]

Hello,
  I am unable to see the expected performance gain using vectorizatio on
powerPC using Linux Suse.
  I've prepared a simple test and compiled it once with vectorization and once
without the vectorization flags. I'd appriciate if someone could point me as to
what Im doing wrong here.Bellow are the results of the test runs:
   time ./TestNoVec 92200 8 89720 1000
   real0m23.549s

   time ./TestVec 92200 8 89720 1000
   real0m22.845s

Here is the code:
#include 
#include 
#include 

typedef float ARRTYPE;
int main ( int argc, char *argv[] )
{
int m_nSamples = atoi( argv[1] );
int itBegin = atoi( argv[2] );
int itEnd = atoi( argv[3] );
int iSizeMain = atoi( argv[ 4 ] );
ARRTYPE *pSum1 = new ARRTYPE[ 10 ];
ARRTYPE *pSum = new ARRTYPE[ 10 ];
for ( int it = 0; it < m_nSamples; it++ )
{
pSum[ it ] = it / itBegin;
pSum1[ it ] = itBegin / ( it + 1 );
}
ARRTYPE *pVec1 = (ARRTYPE*) malloc (sizeof(ARRTYPE) *m_nSamples);
ARRTYPE *pVec2 = (ARRTYPE*) malloc (sizeof(ARRTYPE) *m_nSamples);
for ( int i = 0, j = 0; i < m_nSamples - 5; i++ )
{
for( int it = itBegin; it < itEnd; it++ )
pVec1[ it ] += pSum[ it ] + pSum1[ it ];
}
free( pVec1 );
free( pVec2 );
}

Compilation flag for No vectorization:
gcc  -DTIXML_USE_STL -I /home/build/build -I /home/build/build -I. -I
/usr/local/include -I /usr/include -O3 -fomit-frame-pointer -mtune=powerpc
-falign-functions=16 -fprefetch-loop-arrays -fpeel-loops -funswitch-loops 
-fPIC -mcpu=powerpc  -m64 -fargument-noalias -funroll-loops
-ftree-vectorizer-verbose=7 -fdump-tree-vect-details  -c -o Test.o Test.cpp
gcc -lpthread -lz -lm -lstdc++ -DTIXML_USE_STL -I /home/build/build -I
/home/build/build -I. -I /usr/local/include -I /usr/include -O3
-fomit-frame-pointer -mtune=powerpc -falign-functions=16 -fprefetch-loop-arrays
-fpeel-loops -funswitch-loops  -fPIC -mcpu=powerpc  -m64 -fargument-noalias
-funroll-loops -ftree-vectorizer-verbose=7 -fdump-tree-vect-details
-L/usr/local/lib64 -DTIXML_USE_STL -pthread -L. -L /home/build/build/lib64 -L
/home/build/build/lib64 -L /usr/lib64 -L /lib64 -L /opt/gnome/lib64 -o
TestNoVec Test.o

Compilation of vectorized code:
gcc  -DTIXML_USE_STL -I /home/build/build -I /home/build/build -I. -I
/usr/local/include -I /usr/include -O3 -fomit-frame-pointer -mtune=powerpc
-falign-functions=16 -fprefetch-loop-arrays -fpeel-loops -funswitch-loops
-ftree-vectorize -fPIC -mcpu=powerpc -maltivec -mabi=altivec -m64
-fargument-noalias -funroll-loops -ftree-vectorizer-verbose=7
-fdump-tree-vect-details  -c -o Test.o Test.cpp
gcc -lpthread -lz -lm -lstdc++ -DTIXML_USE_STL -I /home/build/build -I
/home/build/build -I. -I /usr/local/include -I /usr/include -O3
-fomit-frame-pointer -mtune=powerpc -falign-functions=16 -fprefetch-loop-arrays
-fpeel-loops -funswitch-loops -ftree-vectorize -fPIC -mcpu=powerpc -maltivec
-mabi=altivec -m64 -fargument-noalias -funroll-loops
-ftree-vectorizer-verbose=7 -fdump-tree-vect-details -L/usr/local/lib64
-DTIXML_USE_STL -pthread -L. -L /home/build/build/lib64 -L
/home/build/build/lib64 -L /usr/lib64 -L /lib64 -L /opt/gnome/lib64 -o TestVec
Test.o


-- 
   Summary: Vectorization on power PC
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eyal at geomage dot com
 GCC build triplet: gcc (GCC) 4.3.0 20071124 (experimental)
  GCC host triplet: PowerPC
GCC target triplet: PowerPC


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

[Bug c++/35116] [4.3 Regression]: Fail to compile valid code

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug tree-optimization/35085] [4.3 Regression] gcc.dg/vect/vect-iv-9.c fails

[ismail at pardus dot org dot tr]

--- Comment #21 from ismail at pardus dot org dot tr  2008-02-07 09:05 
---
 -fno-tree-reassoc fixes the problem here,

With  -fno-tree-reassoc :

vect-iv-9.c:15: note: === vect_mark_stmts_to_be_vectorized ===
vect-iv-9.c:10: note: vectorized 1 loops in function.
vect-iv-9.c:26: note: === vect_mark_stmts_to_be_vectorized ===
vect/vect-iv-9.c:22: note: vectorized 1 loops in function.

Without it :

vect-iv-9.c:15: note: === vect_mark_stmts_to_be_vectorized ===
vect-iv-9.c:15: note: not vectorized: unsupported use in stmt.
vect-iv-9.c:10: note: vectorized 0 loops in function.
vect-iv-9.c:26: note: === vect_mark_stmts_to_be_vectorized ===
vect-iv-9.c:22: note: vectorized 1 loops in function.


-- 


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

[Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP

[jpr at csc dot fi]

--- Comment #16 from jpr at csc dot fi  2008-02-07 09:19 ---
Subject: Re:  [Regression wrt g77] I/O leaks handles/memory
 on Windows XP


Well, the internal write case is anyway a regression introduced by this 
patch

http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00717.html


>
>
> --- Comment #15 from kargl at gcc dot gnu dot org  2008-02-07 06:26 
> ---
> (In reply to comment #14)
>> Yes this is a regression wrt g77 and I have noted this in the summary.  I 
>> have
>> attempted to insert a mutex_unlock in the right place and it has no effect.  
>> I
>> think jpr's assessment is correct, there needs to be a close_handle call
>> somewhere in the code path.  There is no close_handle call in gthr-win32.c
>>
>
> It's not a regression wrt to g77 because g77 isn't thread safe.
> In fact, if comment #11 is accurate, this isn't a libgfortran
> bug. It's a target bug.
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


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

[Bug tree-optimization/35085] [4.3 Regression] gcc.dg/vect/vect-iv-9.c fails

[ubizjak at gmail dot com]

--- Comment #20 from ubizjak at gmail dot com  2008-02-07 09:01 ---
>From the logs:

tree-reassoc in failed case transforms:

  D.2020_7 = a[i_17];
  D.2021_8 = D.2020_7 + i_17;
  s_9 = D.2021_8 + s_18;

to:

  D.2020_7 = a[i_17];
  D.2021_8 = s_18 + i_17;
  s_9 = D.2021_8 + D.2020_7;


In my case, it transforms:

  D.2002_7 = a[i_18];
  D.2003_8 = D.2002_7 + i_18;
  s_9 = D.2003_8 + s_17;

to

  D.2002_7 = a[i_18];
  D.2003_8 = i_18 + D.2002_7;
  s_9 = D.2003_8 + s_17;
  i_10 = i_18 + 1;

What happens if you add -fno-tree-reassoc to your compile flags? In my case it
still vectorizes both loops.


-- 


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

[Bug tree-optimization/35085] [4.3 Regression] gcc.dg/vect/vect-iv-9.c fails

[ubizjak at gmail dot com]

--- Comment #22 from ubizjak at gmail dot com  2008-02-07 09:37 ---
(In reply to comment #21)
>  -fno-tree-reassoc fixes the problem here,

So, what happens to reassociation that sometimes produce (working case):

Rank for D.2002_7 is 327681
Transforming D.2002_7 + i_18 into i_18 + D.2002_7;
Reassociation stats:
Linearized: 0
Constants eliminated: 0
Ops eliminated: 0
Statements rewritten: 0

and the other time (non-working case):

Rank for D.2020_7 is 327681
Transforming D.2021_8 + s_18 into D.2021_8 + D.2020_7;
Transforming D.2020_7 + i_17 into s_18 + i_17;
Reassociation stats:
Linearized: 0
Constants eliminated: 0
Ops eliminated: 0
Statements rewritten: 0


-- 


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

[Bug c++/35113] g++.dg/ext/vector13.C doesn't work

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2008-02-07 09:50 ---
Confirmed on i686-apple-darwin9:

[ibook-dhum] /Users/dominiq% /opt/gcc/gcc4.3w/bin/g++
/opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/ext/vector13.C
/opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/ext/vector13.C:6: internal compiler
error: canonical types differ for identical types const int __vector__ [] and
const int __vector__ []


-- 


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

[Bug tree-optimization/35085] [4.3 Regression] gcc.dg/vect/vect-iv-9.c fails

[rguenth at gcc dot gnu dot org]

--- Comment #23 from rguenth at gcc dot gnu dot org  2008-02-07 10:20 
---
qsort with sort_by_operand_rank is unstable, as it may return zero.  But, IMHO
the vectorizer should simply recognize the other pattern as well.


-- 


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

[Bug c/35118] ICE in mem_loc_descriptor, at dwarf2out.c:8974

[tim at klingt dot org]

--- Comment #1 from tim at klingt dot org  2008-02-07 10:22 ---
Created an attachment (id=15113)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15113&action=view)
preprocessed source file


-- 


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

[Bug target/35119] New: FAIL: g++.dg/template/spec35.C scan-assembler

[dominiq at lps dot ens dot fr]

On i686-apple-darwin9, g++.dg/template/spec35.C fails for

FAIL: g++.dg/template/spec35.C scan-assembler .glob(a|)l[\t ]*_Z2f2IfEvT_
FAIL: g++.dg/template/spec35.C scan-assembler .weak[\t ]*_Z2f2IiEvT_

A quick look to the assembly shows that the regular expressions should be
something like ".glob(a|)l[\t ]*_?_Z2f2IfEvT_" and ".weak(_definition)?[\t
]*__Z2f2IiEvT_".

If needed, I can do the change in the test and regtest it on Darwin9
(ppc/intel).


-- 
   Summary: FAIL: g++.dg/template/spec35.C scan-assembler
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9


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

[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605

[olga at gcc dot gnu dot org]

--- Comment #67 from olga at gcc dot gnu dot org  2008-02-07 10:26 ---
(In reply to comment #66)

> I looked wo_prof_global_var.c.  The test passes with the above options.
> The floating point convert operations look similar to those with
> -fipa-struct-reorg.  However, there's just one malloc call and the
> values allocated for b are all zero.

I see your point. Indeed, struct-reorg generates two additional mallocs, one
additional for each structure field, so that original malloc is not used any
more. (I hoped compiler optimizes it out, but it does not happen.) Your
investigation implies that original malloc was initialized to zero, while
mallocs generated by this optimization are not, that cause the failure. 

I looked into assembly you send and see the following difference:
for original malloc there is additional instruction 

stwm %r4,64(%r30)

before malloc call, while for first artificial malloc (field a, I suppose)
there is similar instruction

stw %r3,-60(%r30)

but for the second artificial malloc there isn't. ("Copy" instructions are to
carry results of the malloc).

As I am not familiar with hp assembler, can you please explain what is the
meaning of this instruction? Probably my suspicion is wrong.

Olga 


-- 


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

[Bug c/35118] New: ICE in mem_loc_descriptor, at dwarf2out.c:8974

[tim at klingt dot org]

gcc crashes with an ICE, when generating code with debugging information. if
the flag -g is omitted, the code compiles fine ...

gcc is invoked like this:
gcc-4.2 -v  -save-temps -DNDEBUG -D_PTHREADS -D_THREAD_SAFE -D_REENTRANT
-D_POSIX_SOURCE -march=i686 -O -Wfatal-errors -I../../Demo -I../../Source -g 
-c ../../Demo/TestHashTable.cpp
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
--disable-libmudflap --enable-targets=all --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.3 20080114 (prerelease) (Debian 4.2.2-7)
 /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus -E -quiet -v -I../../Demo
-I../../Source -D_GNU_SOURCE -DNDEBUG -D_PTHREADS -D_THREAD_SAFE -D_REENTRANT
-D_POSIX_SOURCE ../../Demo/TestHashTable.cpp -march=i686 -Wfatal-errors
-fworking-directory -O -fpch-preprocess -o TestHashTable.ii
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 ../../Demo
 ../../Source
 /usr/include/c++/4.2
 /usr/include/c++/4.2/i486-linux-gnu
 /usr/include/c++/4.2/backward
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.2.3/include
 /usr/include
End of search list.
 /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus -fpreprocessed TestHashTable.ii
-quiet -dumpbase TestHashTable.cpp -march=i686 -auxbase TestHashTable -g -O
-Wfatal-errors -version -o TestHashTable.s
GNU C++ version 4.2.3 20080114 (prerelease) (Debian 4.2.2-7) (i486-linux-gnu)
compiled by GNU C version 4.2.3 20080114 (prerelease) (Debian 4.2.2-7).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: f406bbb58e12163da4726a4b8abbe4e4
../../Demo/TestHashTable.cpp: In static member function ‘static void
CTestHashTable::TestHashTableRandomly(time_t&)’:
../../Demo/TestHashTable.cpp:130: internal compiler error: in
mem_loc_descriptor, at dwarf2out.c:8974
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .

the preprocessed file is attached. gcc-4.3 seems to work fine ...


-- 
   Summary: ICE in mem_loc_descriptor, at dwarf2out.c:8974
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tim at klingt dot org


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

[Bug c++/35049] [4.3 Regression] g++.dg/conversion/simd3.C:12: error: invalid operands to binary + (have 'float __vector__' and 'int __vector__')

[bonzini at gnu dot org]

--- Comment #13 from bonzini at gnu dot org  2008-02-07 10:09 ---
when was this approved?  I think I have a better patch.


-- 


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

[Bug c/35120] New: vect-64.c failing on power

[razya at il dot ibm dot com]

I see the following failure while compiling vect-64.con power:

unrecognizable insn:
(insn 129 337 130 5
/home/razya/mainline_r131741/gcc/gcc/testsuite/gcc.dg/vect/vect-64.c:23
(parallel [
(set (reg:V4SI 241 [ vect_cst_.61 ])
(reg:V4SI 315))
(unspec [
(const_int 0 [0x0])
] 196)
]) -1 (nil))


The dump file  vect-64.c.136r.unshare
still shows a the correct insn:

(insn 129 128 130 5
/home/razya/mainline_r131741/gcc/gcc/testsuite/gcc.dg/vect/vect-64.c:23
(parallel [
(set (reg:V4SI 241 [ vect_cst_.61 ])
(mem/c/i:V4SI (plus:SI (reg/f:SI 115 virtual-stack-vars)
(const_int 60696 [0xed18])) [6 S16 A128]))
(unspec [
(const_int 0 [0x0])
] 196)
]) -1 (nil))


but then it gets messed somehow, and the expected memory reference is replaced
by a register.
I've also located the revision where this failure started, r131741:


r131741 | dje | 2008-01-22 23:12:05 +0200 (Tue, 22 Jan 2008) | 4 lines

PR target/34529
* config/rs6000/rs6000.c (rs6000_legitimate_offset_address_p):
Offset addresses are not valid for Altivec or paired float modes.


-- 
   Summary: vect-64.c failing on power
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: razya at il dot ibm dot com


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

[Bug c++/35116] [4.3 Regression]: Fail to compile valid code

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Severity|normal  |blocker


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

[Bug c++/35117] Vectorization on power PC

[eyal at geomage dot com]

--- Comment #2 from eyal at geomage dot com  2008-02-07 10:36 ---
Yes the loop is vectorized. What do you mean by memory bound? dont you think
that vectorization can help here? I see around 20% performance gain in the real
application.

Bellow is the compiler output:
Eyal.cpp:34: note: dependence distance  = 0.
Eyal.cpp:34: note: accesses have the same alignment.
Eyal.cpp:34: note: dependence distance modulo vf == 0 between *D.22353_81 and
*D.22353_81
Eyal.cpp:34: note: versioning for alias required: can't determine dependence
between *D.22353_81 and *D.22365_101
Eyal.cpp:34: note: mark for run-time aliasing test between *D.22353_81 and
*D.22365_101
Eyal.cpp:34: note: versioning for alias required: can't determine dependence
between *D.22355_85 and *D.22353_81
Eyal.cpp:34: note: mark for run-time aliasing test between *D.22355_85 and
*D.22353_81
Eyal.cpp:34: note: versioning for alias required: can't determine dependence
between *D.22355_85 and *D.22365_101
Eyal.cpp:34: note: mark for run-time aliasing test between *D.22355_85 and
*D.22365_101
Eyal.cpp:34: note: versioning for alias required: can't determine dependence
between *D.22361_92 and *D.22353_81
Eyal.cpp:34: note: mark for run-time aliasing test between *D.22361_92 and
*D.22353_81
Eyal.cpp:34: note: versioning for alias required: can't determine dependence
between *D.22361_92 and *D.22365_101
Eyal.cpp:34: note: mark for run-time aliasing test between *D.22361_92 and
*D.22365_101
Eyal.cpp:34: note: versioning for alias required: can't determine dependence
between *D.22353_81 and *D.22365_101
Eyal.cpp:34: note: mark for run-time aliasing test between *D.22353_81 and
*D.22365_101
Eyal.cpp:34: note: versioning for alias required: can't determine dependence
between *D.22353_81 and *D.22367_105
Eyal.cpp:34: note: mark for run-time aliasing test between *D.22353_81 and
*D.22367_105
Eyal.cpp:34: note: versioning for alias required: can't determine dependence
between *D.22353_81 and *D.22371_112
Eyal.cpp:34: note: mark for run-time aliasing test between *D.22353_81 and
*D.22371_112
Eyal.cpp:34: note: versioning for alias required: can't determine dependence
between *D.22353_81 and *D.22365_101
Eyal.cpp:34: note: mark for run-time aliasing test between *D.22353_81 and
*D.22365_101
Eyal.cpp:34: note: dependence distance  = 0.
Eyal.cpp:34: note: accesses have the same alignment.
Eyal.cpp:34: note: dependence distance modulo vf == 0 between *D.22365_101 and
*D.22365_101
Eyal.cpp:34: note: versioning for alias required: can't determine dependence
between *D.22367_105 and *D.22365_101
Eyal.cpp:34: note: mark for run-time aliasing test between *D.22367_105 and
*D.22365_101
Eyal.cpp:34: note: versioning for alias required: can't determine dependence
between *D.22371_112 and *D.22365_101
Eyal.cpp:34: note: mark for run-time aliasing test between *D.22371_112 and
*D.22365_101
Eyal.cpp:34: note: found equal ranges *D.22353_81, *D.22365_101 and
*D.22353_81, *D.22365_101
Eyal.cpp:34: note: found equal ranges *D.22353_81, *D.22365_101 and
*D.22353_81, *D.22365_101
Eyal.cpp:34: note: === vect_analyze_slp ===
Eyal.cpp:34: note: === vect_make_slp_decision ===
Eyal.cpp:34: note: === vect_detect_hybrid_slp ===
Eyal.cpp:34: note: Alignment of access forced using versioning.
Eyal.cpp:34: note: Alignment of access forced using versioning.
Eyal.cpp:34: note: Vectorizing an unaligned access.
Eyal.cpp:34: note: Vectorizing an unaligned access.
Eyal.cpp:34: note: Vectorizing an unaligned access.
Eyal.cpp:34: note: Vectorizing an unaligned access.
Eyal.cpp:34: note: Vectorizing an unaligned access.
Eyal.cpp:34: note: Vectorizing an unaligned access.
Eyal.cpp:34: note: === vect_update_slp_costs_according_to_vf
===(analyze_scalar_evolution 
Eyal.cpp:34: note: create runtime check for data references *D.22353_81 and
*D.22365_101
Eyal.cpp:34: note: create runtime check for data references *D.22355_85 and
*D.22353_81
Eyal.cpp:34: note: create runtime check for data references *D.22355_85 and
*D.22365_101
Eyal.cpp:34: note: create runtime check for data references *D.22361_92 and
*D.22353_81
Eyal.cpp:34: note: create runtime check for data references *D.22361_92 and
*D.22365_101
Eyal.cpp:34: note: create runtime check for data references *D.22353_81 and
*D.22367_105
Eyal.cpp:34: note: create runtime check for data references *D.22353_81 and
*D.22371_112
Eyal.cpp:34: note: create runtime check for data references *D.22367_105 and
*D.22365_101
Eyal.cpp:34: note: create runtime check for data references *D.22371_112 and
*D.22365_101
Eyal.cpp:34: note: created 9 versioning for alias checks.
Eyal.cpp:34: note: LOOP VECTORIZED.(get_loop_exit_condition 


-- 


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

[Bug c++/35117] Vectorization on power PC

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-02-07 10:40 ---
That is PR 23383.


-- 


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

[Bug c++/35117] Vectorization on power PC

[eyal at geomage dot com]

--- Comment #5 from eyal at geomage dot com  2008-02-07 10:43 ---
(In reply to comment #3)
> I think this is a dup of another bug I filed with respect of the builtin
> operator new that getting the malloc attribute.

Are you refering to using malloc instead of new? 
using malloc didnt make any difference performance wise.


-- 


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

[Bug middle-end/35120] vect-64.c failing on power

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-07 10:43 ---
PR 34930#3  has the best information on what is going wrong.  As I mentioned in
that, I think it is really a bug in instantiate_virtual_regs_in_insn which is
seperating the memory load from the other instruction.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/34930] [4.3 Regression] ICE in instantiate_virtual_regs_in_insn with vector splat load

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2008-02-07 10:43 ---
*** Bug 35120 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||razya at il dot ibm dot com


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

[Bug c++/35117] Vectorization on power PC

[irar at il dot ibm dot com]

--- Comment #6 from irar at il dot ibm dot com  2008-02-07 10:53 ---
(In reply to comment #2)
> Yes the loop is vectorized. 
...
> Eyal.cpp:34: note: created 9 versioning for alias checks.
> Eyal.cpp:34: note: LOOP VECTORIZED.(get_loop_exit_condition 

The vectorizer created runtime checks to verify that there is no data
dependence in the loop, i.e., if the data references do alias, the vector
version is skipped and the scalar version of the loop is performed.


-- 


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

[Bug c++/35117] Vectorization on power PC

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-02-07 10:37 ---
I think this is a dup of another bug I filed with respect of the builtin
operator new that getting the malloc attribute.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal


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

[Bug c++/35117] Vectorization on power PC

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-07 10:29 ---
The testcase looks completely memory bound.  Does the compiler tell you it
does vectorization at all?  Have you tried without -fprefetch-loop-arrays
(with todays HW prefetchers and the simple access patterns it's probably not
a win here).


-- 


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

[Bug c++/35121] New: Misleading linker messages - ld: Error: Overflow detected in relocation value;

[MikeWelsen at hotmail dot com]

ld reports this problem when finds undefined sysmbols. 

This has been reported in 2006. Please see the link below:
http://arc-linux.org/pipermail/arc-gnu-tools/2006q2/000202.html

Is there a fix for that ? Can you suggest a workaround if not.


-- 
   Summary: Misleading linker messages - ld: Error: Overflow
detected in relocation value;
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: MikeWelsen at hotmail dot com


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

[Bug target/35119] FAIL: g++.dg/template/spec35.C scan-assembler

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-07 11:00 ---
If that is what other testcases do, then yes, this would be appreciated.


-- 


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

[Bug c++/35121] Misleading linker messages - ld: Error: Overflow detected in relocation value;

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-07 11:03 ---
Well ld is not part of GCC but rather the binutils project or is provided with
your OS.  So you should be reporting it to them.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/35117] Vectorization on power PC

[eyal at geomage dot com]

--- Comment #7 from eyal at geomage dot com  2008-02-07 11:06 ---
(In reply to comment #6)
> (In reply to comment #2)
> > Yes the loop is vectorized. 
> ...
> > Eyal.cpp:34: note: created 9 versioning for alias checks.
> > Eyal.cpp:34: note: LOOP VECTORIZED.(get_loop_exit_condition 
> The vectorizer created runtime checks to verify that there is no data
> dependence in the loop, i.e., if the data references do alias, the vector
> version is skipped and the scalar version of the loop is performed.

Hi,
 That is what I suspected. Anyway I can identify from the log what causes
those runtime checks and resolve it in code, so I can be 100% sure that
the code is fully vectorized?

thanks


-- 


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

[Bug c/35122] New: gcc segfaults when compiling code with pointers to vector float

[hanappe at csl dot sony dot fr]

GCC version:
$ ppu-gcc -v
Using built-in specs.
Target: ppu
Configured with: ../toolchain/gcc/configure --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info --with-as=/usr/bin/ppu-as
--with-ld=/usr/bin/ppu-ld --enable-threads --with-system-zlib
--disable-checking --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-languages=c,c++,fortran,ada --disable-nls --enable-clocale=gnu
--enable-version-specific-runtime-libs --with-long-double-128
--program-prefix=ppu- --disable-bootstrap --host=ppu
--build=powerpc64-unknown-linux-gnu --target=ppu
Thread model: posix
gcc version 4.1.1

Platform: ppc64, PS3, Linux 2.6.21-1.3194.fc7

Code: 
#include 
#include 

int main(int argc, char** argv)
{
vector float v =  { 1, 1, 1, 1 };
vector float* vp = &v;
fprintf(stderr, "%f\n",v[0]);   // OK
fprintf(stderr, "%f\n",vp[0][0]);   // internal compiler error:
Segmentation fault
return 0;
}

or:

#include 
#include 

int main(int argc, char** argv)
{
vector float v =  { 1, 1, 1, 1 };
vector float* vp = &v;
fprintf(stderr, "%f\n",v[0]);   // OK
fprintf(stderr, "%f\n",(*vp)[0]);   // internal compiler error:
Segmentation fault
return 0;
}


Command line: ppu-gcc -g -c -maltivec bug.c -o bug.o 

Command output:
bug.c: In function 'main':
bug.c:9: internal compiler error: Segmentation fault


-- 
   Summary: gcc segfaults when compiling code with pointers to
vector float
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hanappe at csl dot sony dot fr


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

[Bug rtl-optimization/33410] [4.2/4.3 regression] ICE in iv_analyze_expr, at loop-iv.c:934

[belyshev at depni dot sinp dot msu dot ru]

--- Comment #22 from belyshev at depni dot sinp dot msu dot ru  2008-02-07 
11:36 ---
(In reply to comment #21)
No new failures with this patch and two tests failed previously
(gcc.c-torture/compile/pr33855.c and gcc.dg/torture/fp-int-convert-timode.c)
did PASS:

http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00454.html


-- 


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

[Bug fortran/35123] New: ICE in fold_convert, at fold-const.c:2248

[sfilippone at uniroma2 dot it]

The test case produces the following output on both 4.2.3 and 4.2.2; works fine
under 4.3-20080201
---
[EMAIL PROTECTED] bugtest]$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2.3/configure --prefix=/usr/local/gcc42
--with-mpfr=/usr/local/mpfr --with-gmp=/usr/local/gmp
Thread model: posix
gcc version 4.2.3
[EMAIL PROTECTED] bugtest]$ gfortran -c foo_bug.f90 
foo_bug.f90: In function 'foo_cdall':
foo_bug.f90:56: internal compiler error: in fold_convert, at fold-const.c:2248
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


-- 
   Summary: ICE in fold_convert, at fold-const.c:2248
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sfilippone at uniroma2 dot it
 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=35123

[Bug fortran/35123] ICE in fold_convert, at fold-const.c:2248

[sfilippone at uniroma2 dot it]

--- Comment #1 from sfilippone at uniroma2 dot it  2008-02-07 12:02 ---
Created an attachment (id=15114)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15114&action=view)
test case


-- 


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

[Bug libstdc++/35104] cmath do not undef log2

[pcarlini at suse dot de]

--- Comment #2 from pcarlini at suse dot de  2008-02-07 12:07 ---
Just wanted to add that we are also providing a , conforming to the
TR1 specifications, which indeed makes available std::tr1::log2, and also, in
the forthcoming 4.3.0, std::log2, as part of , enabled in the
experimental C++0x mode, -std=c++0x: in fact the next C++0x standard will know
about all the C99 math functions.


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[ian dot rogers at manchester dot ac dot uk]

--- Comment #4 from ian dot rogers at manchester dot ac dot uk  2008-02-07 
12:10 ---
There are two improvements described here:

1) avoid synchronization by the use of StringBuilder rather than StringBuffer

this is some what trivial and has largely been carried out in the Classpath
code base

2) switch to using a GCJ style string buffer that avoids copies

this is still awaiting action


-- 


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

[Bug c++/35117] Vectorization on power PC

[eyal at geomage dot com]

--- Comment #8 from eyal at geomage dot com  2008-02-07 12:16 ---
Hi Ira,
  Here is the compiler output for the real code.
Crs/CEE_CRE_2DSearch.cpp:1285: note: create runtime check for data references
*D.86651_134 and *D.8_160
Crs/CEE_CRE_2DSearch.cpp:1285: note: create runtime check for data references
*D.86651_134 and *D.86669_168
Crs/CEE_CRE_2DSearch.cpp:1285: note: create runtime check for data references
*D.86655_139 and *D.8_160
Crs/CEE_CRE_2DSearch.cpp:1285: note: create runtime check for data references
*D.86655_139 and *D.86669_168
Crs/CEE_CRE_2DSearch.cpp:1285: note: create runtime check for data references
*D.86658_145 and *D.8_160
Crs/CEE_CRE_2DSearch.cpp:1285: note: create runtime check for data references
*D.86658_145 and *D.86669_168
Crs/CEE_CRE_2DSearch.cpp:1285: note: create runtime check for data references
*D.86661_151 and *D.8_160
Crs/CEE_CRE_2DSearch.cpp:1285: note: create runtime check for data references
*D.86661_151 and *D.86669_168
Crs/CEE_CRE_2DSearch.cpp:1285: note: created 8 versioning for alias checks.

I looked further in the output log and found the following:
D.8_160 = pTempSumPhase_Temp_cre_angle_27 + D.86665_159;
D.86669_168 = pTempSum2Phase_Temp_cre_angle_32 + D.86665_159;
D.86651_134 = pSum_78 + D.86650_133;
D.86655_139 = pSum_78 + D.86654_138;
D.86658_145 = pSum_G_106 + D.86650_133;
D.86661_151 = pSum_G_106 + D.86654_138;

D.86650_133 = D.86649_132 * 4
D.86649_132 = (long unsigned int) ittt_855;

D.86654_138 = D.86653_137 * 4;
D.86653_137 = (long unsigned int) ittt1_856;


It seems it complaints about some relationship between
pTempSum2Phase_Temp_cre_angle_32 and pTempSumPhase_Temp_cre_angle_27 and
pSum_78 and pSum_G_106
Those vectors have nothing in common in the code. How do I make the compiler
see there's no relationship? Here's the C++ code:

 void GCEE_CRE_2DSearch::Find( int i_rCee )
{
float *pTempSumPhase_Temp_cre_angle = (float*) malloc (sizeof(float)
*m_nSamples);
float *pTempSum2Phase_Temp_cre_angle = (float*) malloc (sizeof(float)
*m_nSamples);

memset(pTempSumPhase_Temp_cre_angle,0,sizeof(float)* m_nSamples);
memset(pTempSum2Phase_Temp_cre_angle,0,sizeof(float)* m_nSamples);

float *  pSum, *pSum_G;
.
.
pSum  = m_hiSearchQueue[i_trace];
pSum_G   = m_hiSearchQueue[i_trace];
.
.
for( int it = itBegin, ittt  = itBegin + sample_int, ittt1 = itBegin +
sample_int + 1; it < itEnd; it++, ittt++, ittt1++ )   
{
float fSumValue = pSum[ ittt ] * w11;
fSumValue += pSum[ ittt1 ] * w21;
fSumValue += pSum_G[ ittt ] * w12;
fSumValue += pSum_G[ ittt1 ] * w22;
pTempSumPhase_Temp_cre_angle[ it ] += fSumValue;
pTempSum2Phase_Temp_cre_angle[ it ] += fSumValue * fSumValue;
}


Thanks
Eyal 


-- 


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

[Bug target/35119] FAIL: g++.dg/template/spec35.C scan-assembler

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2008-02-07 12:21 ---
> If that is what other testcases do, then yes, this would be appreciated.

I am not sure to understand the sentence.  What I can do is test the proposed
regular expressions on Darwin9and see if the failures disappear. What I cannot
do is test if the proposed regular expressions do not break the test on other
platforms.


-- 


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

[Bug tree-optimization/33761] non-optimal inlining heuristics pessimizes gzip SPEC score at -O3

[hubicka at gcc dot gnu dot org]

--- Comment #23 from hubicka at gcc dot gnu dot org  2008-02-07 12:30 
---
Created an attachment (id=15115)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15115&action=view)
Annotated profile

I am attaching dump with profile read in.  It shows the hot spots in
longest_match at least:

(this is first conditional of the continue guard)
  # BLOCK 27 freq:1 count:1346119696
  # PRED: 6 [100.0%]  count:112241556 (fallthru) 25 [99.5%]  count:1233878140
(true,exec)
  # scan_end_13 = PHI 
  # scan_end1_11 = PHI 
  # best_len_8 = PHI 
  # scan_3 = PHI 
  # chain_length_2 = PHI 
  # cur_match_1 = PHI 
  match_40 = &window + cur_match_1;
  best_len.31_41 = (unsigned int) best_len_8;
  D.2379_42 = match_40 + best_len.31_41;
  D.2380_43 = *D.2379_42;
  if (D.2380_43 != scan_end_13)
goto ;
  else
goto ;

  # SUCC: 10 [0.1%]  count:33977 (true,exec) 11 [99.9%]  count:48979565
(false,exec)

  # BLOCK 10 freq:9636 count:1297140131
  # PRED: 27 [87.5%]  count:1177665163 (true,exec) 7 [55.2%]  count:93018627
(true,exec) 8 [35.0%]  count:26422364 (true,exec) 9 [0.1%]  count:33977
(true,exec)
  goto ;

(this is the continue statement)

  D.2391_102 = cur_match_1 & 32767;
  D.2392_103 = prev[D.2391_102];
  cur_match_104 = (IPos) D.2392_103;
  if (limit_15 >= cur_match_104)
goto ;
  else
goto ;
  # SUCC: 26 [7.7%]  count:104056913 (true,exec) 25 [92.3%]  count:1240391903
(false,exec)

  # BLOCK 25 freq:9215 count:1240391903
  # PRED: 24 [92.3%]  count:1240391903 (false,exec)
  chain_length_105 = chain_length_2 + 0x0;
  if (chain_length_105 != 0)
goto ;
  else
goto ;


(this is end of outer loop)


-- 


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

[Bug target/35124] New: Method _alloca is defined different by MSVCRT as by gcc.

[ktietz at gcc dot gnu dot org]

The method _alloca assemble implementation is written that way, that it does
not return the stack pointer. I just reserves and probes the stack space.
The MSVCRT variant declares it as a synonym for POSIX alloca().
Here are three problems by the gcc variant:
1) The stack pointer isn't returned in (eax/rax).
2) If the _alloca function is called by a value not equal to the stack
boundary,
  the stack pointer (esp/rsp) gets unaligned and OS will raise an exception for
  the next instruction pushing to the stack.
3) For target x86_64-pc-mingw32 the calling convention is treated correctly.
  For ms abi, the argument gets reserved room on stack, too. Like for the 32
  bit variant.

For the x86_64-pc-mingw32 target I attached a patch for this.
Index: gcc/gcc/config/i386/cygwin.asm
===
--- gcc.orig/gcc/config/i386/cygwin.asm
+++ gcc/gcc/config/i386/cygwin.asm
@@ -72,15 +72,44 @@ Ldone:
pushl   %eax
ret
 #else
-/* __alloca is a normal function call, which uses %rcx as the argument.  */
+/* __alloca is a normal function call, which uses %rcx as the argument.  And
stack space
+   for the argument is saved.  */
 __alloca:
movq%rcx, %rax
-   /* FALLTHRU */
+   addq$0x7, %rax
+   andq$0xfff8, %rax
+   popq%rcx/* pop return address */
+   popq%r10/* Pop the reserved stack space.  */
+   movq%rsp, %r10  /* get sp */
+   cmpq$0x1000, %rax   /* > 4k ?*/
+   jb  Ldone_alloca
+
+Lprobe_alloca:
+   subq$0x1000, %r10   /* yes, move pointer down 4k*/
+   orq $0x0, (%r10)/* probe there */
+   subq$0x1000, %rax   /* decrement count */
+   cmpq$0x1000, %rax
+   ja  Lprobe_alloca   /* and do it again */
+
+Ldone_alloca:
+   subq%rax, %r10
+   orq $0x0, (%r10)/* less than 4k, just peek here */
+   movq%r10, %rax
+   subq$0x8, %r10  /* Reserve argument stack space.  */
+   movq%r10, %rsp  /* decrement stack */
+
+   /* Push the return value back.  Doing this instead of just
+  jumping to %rcx preserves the cached call-return stack
+  used by most modern processors.  */
+   pushq   %rcx
+   ret

 /* ___chkstk is a *special* function call, which uses %rax as the argument.
We avoid clobbering the 4 integer argument registers, %rcx, %rdx, 
%r8 and %r9, which leaves us with %rax, %r10, and %r11 to use.  */
 ___chkstk:
+   addq$0x7, %rax  /* Make sure stack is on alignment of 8.  */
+   andq$0xfff8, %rax
popq%r11/* pop return address */
movq%rsp, %r10  /* get sp */
cmpq$0x1000, %rax   /* > 4k ?*/


-- 
   Summary: Method _alloca is defined different by MSVCRT as by gcc.
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ktietz at gcc dot gnu dot org
 GCC build triplet: *-*-mingw32
  GCC host triplet: *-*-mingw32
GCC target triplet: *-*-mingw32


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

[Bug tree-optimization/35085] [4.3 Regression] gcc.dg/vect/vect-iv-9.c fails

[ubizjak at gmail dot com]

--- Comment #24 from ubizjak at gmail dot com  2008-02-07 12:39 ---
It happens that we already have specialization to detect reduction in
rewrite_expr_tree:

--cut here--
 The alternative we try is to see if this is a destructive
 update style statement, which is like:
 b = phi (a, ...)
 a = c + b;
 In that case, we want to use the destructive update form to
 expose the possible vectorizer sum reduction opportunity.
 In that case, the third operand will be the phi node.
--cut here--

We have analysed operands in working and failed case:

(working):

+++ OP1: D.2002_7
op1 rank: 327681
->not phi for stmt
+++ OP2: i_18
op2 rank: 327680
not phi for stmt
+++ OP3: s_17
op3 rank: 327680
 phi for stmt

(failed):
+++ OP1: D.2020_7
op1 rank: 327681
->not phi for stmt
+++ OP2: s_18
op2 rank: 327680
 phi for stmt
+++ OP3: i_17
op3 rank: 327680
not phi for stmt

So, according to this data, following patch should (IMO) solve this mistery:

Index: tree-ssa-reassoc.c
===
--- tree-ssa-reassoc.c  (revision 132166)
+++ tree-ssa-reassoc.c  (working copy)
@@ -857,6 +857,18 @@ rewrite_expr_tree (tree stmt, unsigned i
  oe1->op = temp.op;
  oe1->rank= temp.rank;
}
+  else if ((oe1->rank == oe3->rank
+   && oe2->rank != oe3->rank)
+  || (is_phi_for_stmt (stmt, oe2->op)
+  && !is_phi_for_stmt (stmt, oe1->op)
+  && !is_phi_for_stmt (stmt, oe3->op)))
+   {
+ struct operand_entry temp = *oe2;
+ oe2->op = oe1->op;
+ oe2->rank = oe1->rank;
+ oe1->op = temp.op;
+ oe1->rank= temp.rank;
+   }
 }

   /* The final recursion case for this function is that you have


-- 


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

[Bug c++/35117] Vectorization on power PC

[eyal at geomage dot com]

--- Comment #10 from eyal at geomage dot com  2008-02-07 12:58 ---
(In reply to comment #9)
> (In reply to comment #8)
> > {
> > float *pTempSumPhase_Temp_cre_angle = (float*) malloc (sizeof(float)
> > *m_nSamples);
> > float *pTempSum2Phase_Temp_cre_angle = (float*) malloc 
> > (sizeof(float)
> > *m_nSamples);
> > 
> > memset(pTempSumPhase_Temp_cre_angle,0,sizeof(float)* m_nSamples);
> > memset(pTempSum2Phase_Temp_cre_angle,0,sizeof(float)* m_nSamples);
> Maybe the problem is that they escape (call to memset)...
> The alias analysis fails to distinguish between these two pointers and the
> vectorizer has to create runtime checks.

I've commented the memset operation and still get the 
"created 8 versioning for alias checks." message.

Is there some pragma or a coding convention I can use to make the compiler
understant those pointers have nothing to do with each other?


-- 


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

[Bug tree-optimization/35085] [4.3 Regression] gcc.dg/vect/vect-iv-9.c fails

[ismail at pardus dot org dot tr]

--- Comment #25 from ismail at pardus dot org dot tr  2008-02-07 12:43 
---
Uros you rock! That patch fixes the problem for me, thank you!


-- 


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

[Bug c++/35117] Vectorization on power PC

[irar at il dot ibm dot com]

--- Comment #9 from irar at il dot ibm dot com  2008-02-07 12:54 ---
(In reply to comment #8)
> {
> float *pTempSumPhase_Temp_cre_angle = (float*) malloc (sizeof(float)
> *m_nSamples);
> float *pTempSum2Phase_Temp_cre_angle = (float*) malloc (sizeof(float)
> *m_nSamples);
> 
> memset(pTempSumPhase_Temp_cre_angle,0,sizeof(float)* m_nSamples);
> memset(pTempSum2Phase_Temp_cre_angle,0,sizeof(float)* m_nSamples);

Maybe the problem is that they escape (call to memset)...
The alias analysis fails to distinguish between these two pointers and the
vectorizer has to create runtime checks.


-- 


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

[Bug tree-optimization/35085] [4.3 Regression] gcc.dg/vect/vect-iv-9.c fails

[ubizjak at gmail dot com]

--- Comment #26 from ubizjak at gmail dot com  2008-02-07 12:56 ---
Testing the patch.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-07 12:56:34
   date||


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

[Bug c++/35117] Vectorization on power PC

[irar at il dot ibm dot com]

--- Comment #11 from irar at il dot ibm dot com  2008-02-07 13:04 ---
(In reply to comment #10)
> Is there some pragma or a coding convention I can use to make the compiler
> understant those pointers have nothing to do with each other?

There is __restrict__, but it is useful only for function arguments. 


-- 


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

[Bug c++/35117] Vectorization on power PC

[eyal at geomage dot com]

--- Comment #12 from eyal at geomage dot com  2008-02-07 13:07 ---
(In reply to comment #11)
> (In reply to comment #10)
> > Is there some pragma or a coding convention I can use to make the compiler
> > understant those pointers have nothing to do with each other?
> There is __restrict__, but it is useful only for function arguments. 

Ira, any suggestions as to how to solve this issue? I'd realy appriciate any
help here as Im lost and we're close to giving up on PPC and vectorization all
together.

thanks
 eyal


-- 


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

[Bug c++/35049] [4.3 Regression] g++.dg/conversion/simd3.C:12: error: invalid operands to binary + (have 'float __vector__' and 'int __vector__')

[bonzini at gnu dot org]

--- Comment #14 from bonzini at gnu dot org  2008-02-07 13:11 ---
posted at http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00212.html


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

URL|http://gcc.gnu.org/ml/gcc-  |http://gcc.gnu.org/ml/gcc-
   |patches/2008-   |patches/2008-
   |02/msg00146.html|02/msg00212.html


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

[Bug c++/35125] New: Violating standards

[amitondemand at gmail dot com]

i compiled the following code on  
"Red Hat Linux Enterprise AS Realease 4
 Kernel 2.6.9-5 Elsmp"
and the code was compiled successfully and was running.


//I dont know how this code is working.

#include
using namespace std;

int main()
{
int size;
int arr[size];

cout<<"Enter size of array: ";
cin>>size;


cout<<"Enter values: \n";
for(int i=0; i< size; i++)
cin>>arr[i];

cout<<"Outputting values: \n";
for(int i=0; i< size; i++)
cout

[Bug c++/35117] Vectorization on power PC

[irar at il dot ibm dot com]

--- Comment #13 from irar at il dot ibm dot com  2008-02-07 13:22 ---
CC'ing Daniel and Diego, maybe they can help with the alias analysis issues.


-- 

irar at il dot ibm dot com changed:

   What|Removed |Added

 CC||dnovillo at google dot com


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

[Bug testsuite/35126] New: dg-options in gcc.c-torture/execute ignored

[hjl dot tools at gmail dot com]

[EMAIL PROTECTED] testsuite]$ grep dg-options gcc.c-torture/execute/*.c
gcc.c-torture/execute/pr7284-1.c:/* { dg-options "-std=c89" } */
gcc.c-torture/execute/wchar_t-1.c:/* { dg-options "-finput-charset=utf-8" } */
[EMAIL PROTECTED] testsuite]$

But those dg-options are ignored since gcc.c-torture/execute/execute.exp
doesn't load gcc-dg.exp.


-- 
   Summary: dg-options in gcc.c-torture/execute ignored
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug c++/35125] Violating standards

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-02-07 15:22 ---
VLA in C++ is an extension, if you use -pedantic, you will get an error.

Also VLA uses the value at the time at definition and no other value after
wards.


-- 


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

[Bug c++/35113] [4.3 Regression] g++.dg/ext/vector13.C doesn't work

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-02-07 15:16 ---
I can also confirm that

http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00212.html

does _not_ fix the problem.  We still ICE with

/space/rguenther/src/svn/trunk/gcc/testsuite/g++.dg/ext/vector13.C:6: internal
compiler error: canonical types differ for identical types const int __vector__
[] and const int __vector__ []^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See  for instructions.^M

FAIL: g++.dg/ext/vector13.C (internal compiler error)
FAIL: g++.dg/ext/vector13.C (test for excess errors)


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org


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

[Bug fortran/35123] ICE in fold_convert, at fold-const.c:2248

[sfilippone at uniroma2 dot it]

--- Comment #3 from sfilippone at uniroma2 dot it  2008-02-07 14:54 ---
(In reply to comment #2)
> gfortran 4.1 errors with
> 
>  In file t.f90:3
> 
> integer, allocatable :: md(:), g2l(:)
>1
> Error: Attribute at (1) is not allowed in a TYPE definition
>

The failure in 4.1 is due to the support of language extension TR 15581, which
was only added in 4.2.0. 
Salvatore


-- 


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

[Bug c++/33887] [4.1/4.2 Regression] Reference to bitfield gets wrong value when optimizing

[rguenth at gcc dot gnu dot org]

--- Comment #39 from rguenth at gcc dot gnu dot org  2008-02-07 18:03 
---
*** Bug 33205 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||xk-corpse at hotmail dot com


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

[Bug target/33205] optimization bug: unsigned bitfield expands with non-zero padding bits

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-02-07 18:03 ---
Ok, that's quite likely.

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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

[janis at gcc dot gnu dot org]

--- Comment #9 from janis at gcc dot gnu dot org  2008-02-07 18:21 ---
I talked to Steve Munroe about the ABI issues.  We determined that for
powerpc*-linux, vector types that cannot be passed in vector registers should
be passed as aggregates according to the relevant ABI (32-bit or 64-bit PowerPC
ELF).  I'll re-enable -mabi=no-altivec in a way that doesn't break SPE, fix the
argument/result passing mess, and then switch the default to -mabi=altivec for
-m32, as separate patches.


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||amodra at gcc dot gnu dot
   ||org


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

[Bug c/35129] -pedantic changes code-generation for unsigned enumerators

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2008-02-07 19:56 ---
Created an attachment (id=15117)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15117&action=view)
Patch

Bootstrapped with --enable-languages=all and regression tested on
x86_64-unknown-linux-gnu


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c/35129] New: -pedantic changes code-generation for unsigned enumerators

[manu at gcc dot gnu dot org]

-pedantic converts enumerators to 'int', while without -pedantic they are
handled as-is.


-- 
   Summary: -pedantic changes code-generation for unsigned
enumerators
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
 BugsThisDependsOn: 33702


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

[Bug c++/19159] [4.0/4.1/4.2/4.3 Regression] Undefined symbol: vtable for __cxxabiv1::__vmi_class_type_info

[dave at genussoft dot com]

--- Comment #40 from dave at genussoft dot com  2008-02-07 19:39 ---
I am trying to use g++ 4.0.0 on AIX 5.3 and have run into this problem and also
the problem reported in bug 18257.  What recommendation do you have for using
g++ on AIX? Should I go back to an earlier version, or has this problem been
resolved in the 4.2.2 version?


-- 

dave at genussoft dot com changed:

   What|Removed |Added

 CC||dave at genussoft dot com


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

[Bug bootstrap/35115] [4.3 Regression] ../../gcc-4.3-work/gcc/objcp/objcp-decl.c:98: error: implicit declaration of function 'comptypes'

[dgregor at gcc dot gnu dot org]

--- Comment #4 from dgregor at gcc dot gnu dot org  2008-02-07 19:06 ---
Fixed. 


-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/35115] [4.3 Regression] ../../gcc-4.3-work/gcc/objcp/objcp-decl.c:98: error: implicit declaration of function 'comptypes'

[dgregor at gcc dot gnu dot org]

--- Comment #3 from dgregor at gcc dot gnu dot org  2008-02-07 19:04 ---
Subject: Bug 35115

Author: dgregor
Date: Thu Feb  7 19:03:40 2008
New Revision: 132173

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132173
Log:
2008-02-06  Douglas Gregor  <[EMAIL PROTECTED]>

* g++.dg/ext/vector13.C: Fix for compilation under -pedantic.
2008-02-07  Andreas Tobler  <[EMAIL PROTECTED]>
Douglas Gregor  <[EMAIL PROTECTED]>

PR bootstrap/35115
* objcp-decl.c (objcp_comptypes): Call cp_comptypes, not comptypes.


Modified:
trunk/gcc/objcp/ChangeLog
trunk/gcc/objcp/objcp-decl.c


-- 


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

[Bug other/32754] The opt?-gen.awk file generators produce incorrect credits

[manu at gcc dot gnu dot org]

--- Comment #3 from manu at gcc dot gnu dot org  2008-02-07 20:50 ---
Fixed in GCC 4.2.4 and GCC 4.3. I don't think it is worth to fix this in
earlier versions.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.2.4


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

[Bug other/32754] The opt?-gen.awk file generators produce incorrect credits

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2008-02-07 20:49 ---
Subject: Bug 32754

Author: manu
Date: Thu Feb  7 20:48:24 2008
New Revision: 132175

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132175
Log:
2008-02-07  Manuel Lopez-Ibanez  <[EMAIL PROTECTED]>

PR other/32754
* doc/options.texi (Options): Replace references to opts.sh with
optc-gen.awk.
* opts-common.c: Likewise.
* optc-gen.awk: Likewise.
* opth-gen.awk: Replace reference to opts.sh with
opth-gen.awk.

Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/doc/options.texi
branches/gcc-4_2-branch/gcc/optc-gen.awk
branches/gcc-4_2-branch/gcc/opth-gen.awk
branches/gcc-4_2-branch/gcc/opts-common.c


-- 


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

[Bug testsuite/20567] dg-options in gcc.c-torture

[jsm28 at gcc dot gnu dot org]

--- Comment #5 from jsm28 at gcc dot gnu dot org  2008-02-07 19:52 ---
*** Bug 35126 has been marked as a duplicate of this bug. ***


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com


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

[Bug c/35129] -pedantic changes code-generation for unsigned enumerators

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-02-07 20:34 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE


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

[Bug c/15236] pedantic switch modifies treatment of non-ISO compliant enumerations

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-02-07 20:34 ---
*** Bug 35129 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


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

[Bug target/32918] segmentation fault

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2008-02-07 20:19 ---
Sorry for the delay, this seems to have fallend through bugzilla's cracks.

GCC 3.3.1 is not supported anymore. Can you reproduce the bug in a recent
release like GCC 4.2.3 or preferably in GCC 4.3?

Thanks for the report anyway.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |WAITING


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

[Bug debug/28834] [4.0/4.1/4.2/4.3 Regression] -g crashes sometimes when using may_alias and structs (ICE in splice_child_die)

[ghazi at gcc dot gnu dot org]

--- Comment #32 from ghazi at gcc dot gnu dot org  2008-02-07 19:14 ---
Jason - Should the fix for PR28834 (AKA PR29436) be backported to 4.2/4.1?

I still see errors from mayalias-2.c on 4.2.  (4.1 doesn't have the testcase,
but I suspect it still has the bug.)


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi at gcc dot gnu dot org


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

[Bug bootstrap/35115] [4.3 Regression] ../../gcc-4.3-work/gcc/objcp/objcp-decl.c:98: error: implicit declaration of function 'comptypes'

[dgregor at gcc dot gnu dot org]

--- Comment #2 from dgregor at gcc dot gnu dot org  2008-02-07 18:59 ---
This is fallout from my comptypes patch. 


-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||02/msg00195.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-02-06 23:01:33 |2008-02-07 18:59:57
   date||


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

[Bug testsuite/35127] Ineffective dg-options in gcc.c-torture/compile

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-07 18:05 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-07 18:05:55
   date||


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

[Bug rtl-optimization/33410] [4.2/4.3 regression] ICE in iv_analyze_expr, at loop-iv.c:934

[rth at gcc dot gnu dot org]

--- Comment #23 from rth at gcc dot gnu dot org  2008-02-07 17:46 ---
Subject: Bug 33410

Author: rth
Date: Thu Feb  7 17:45:24 2008
New Revision: 132171

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132171
Log:
PR rtl-opt/33410
* config/alpha/alpha.c (alpha_emit_xfloating_compare): Use an
EXPR_LIST for the REG_EQUAL instead of a comparison with a
funny mode.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/alpha/alpha.c


-- 


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

[Bug target/33205] optimization bug: unsigned bitfield expands with non-zero padding bits

[janis at gcc dot gnu dot org]

--- Comment #6 from janis at gcc dot gnu dot org  2008-02-07 17:32 ---
A regression hunt on powerpc-linux showed that the test starts passing with:

http://gcc.gnu.org/viewcvs?view=rev&rev=131823
r131823 | rguenth | 2008-01-25 12:06:31 + (Fri, 25 Jan 2008)

That's a fix for 33887.


-- 


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

[Bug fortran/32795] allocatable components are nullified prematurely

[dfranke at gcc dot gnu dot org]

--- Comment #8 from dfranke at gcc dot gnu dot org  2008-02-07 17:24 ---
> Could somebody check the memory leakage for me, please?

  type :: a
integer, allocatable :: i(:)
  end type a
  type(a) :: x, y

  x = a ((/ 1,2,3 /))
! y = a (x%i(1:3))   ! ok
! y = a (x%i(1:))! ok
! y = a (x%i(:3))! ok
! y = a (x%i(:)) ! ok
! y = a (x%i)! ok
! y = x  ! ok
end

Test in comment #2 works on i686-pc-linux-gnu as well.
Thanks for fixing this!


-- 


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

[Bug c++/35004] Adding 4 more tree codes causes a crash in building libstdc++ pre-compiled headers

[michael dot meissner at amd dot com]

--- Comment #6 from michael dot meissner at amd dot com  2008-02-07 17:22 
---
Subject: RE:  Adding 4 more tree codes causes a crash in
 building libstdc++ pre-compiled headers

The problem is there are two different vector shifts.  There is vector
shift by a scalar amount (each element gets shifted the same amount),
and vector shift by a vector (each element gets shifted by the
corresponding element in the vector).

Right now, GCC in tree-vect-transform.c looks at the shift optab and
sees if the second operand is a scalar mode, it believes the machine
only supports the vector shift by scalar mode, and assumes that if the
type is vector mode, that the machine supports vector/vector shifts.

The SSE2 instruction set extension on the x86 has vector/scalar shift
instructions, and the SSE5 instruction set extension adds vector/vector
shifts and rotates.  I want to be able to add support for a machine that
has both types of vector shift, but with the current framework, this was
impossible.

--
Michael Meissner
AMD, MS 83-29
90 Central Street
Boxborough, MA 01719

> -Original Message-
> From: bonzini at gnu dot org [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 07, 2008 12:11 PM
> To: Meissner, Michael
> Subject: [Bug c++/35004] Adding 4 more tree codes causes a crash in
> building libstdc++ pre-compiled headers
> 
> 
> 
> --- Comment #5 from bonzini at gnu dot org  2008-02-07 17:10
---
> Unrelated, but why couldn''t vector/vector shifts/rotates overload
> LSHIFT_EXPR
> instead? :-)
> 
> 
> --
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35004
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
> 


-- 


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

[Bug rtl-optimization/31704] x86_64 poor floating point register allocation across function call

[hubicka at gcc dot gnu dot org]

--- Comment #1 from hubicka at gcc dot gnu dot org  2008-02-07 16:36 ---
This is fixed by the call frequency patch on mainline.
.L2:
cvtsi2ss(%ebx,%eax,4), %xmm0
addl$1, %eax
cmpl$1000, %eax
mulss   %xmm2, %xmm0
addss   %xmm0, %xmm1
jne .L2

(on i386, but x86-64 behaves same way)

Honza


-- 

hubicka at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug testsuite/35126] dg-options in gcc.c-torture/execute ignored

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2008-02-07 15:55 ---
Can we move them into gcc.dg/torture?


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WONTFIX |


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

[Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP

[Jerry_V_DeLisle at rl dot gov]

--- Comment #19 from Jerry_V_DeLisle at rl dot gov  2008-02-07 15:54 ---
Writing to an internal unit is nothing more than a fancy (formatted)
assignment.  Each thread allocates its own unit structure.  Its not like file
I/O where threads are accessing a common shared resource.

I should mention that Danny Smith has sent me a potential patch that I will
test tonight or tomorrow.  I would not mind seeing a threaded example where
this could be tested and that confirms we need to lock internal units. :)


-- 


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

[Bug testsuite/35126] dg-options in gcc.c-torture/execute ignored

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2008-02-07 15:53 ---
My point is those dg-options aren't applied to the testcases. We should
either remove them or make sure that they are used.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Last reconfirmed|-00-00 00:00:00 |2008-02-07 15:53:56
   date||


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

[Bug testsuite/35127] New: Ineffective dg-options in gcc.c-torture/compile

[hjl dot tools at gmail dot com]

[EMAIL PROTECTED] testsuite]$ grep dg-options gcc.c-torture/compile/*.c | grep O
gcc.c-torture/compile/20031125-1.c:/* { dg-options "-O2" } */
gcc.c-torture/compile/20031125-2.c:/* { dg-options "-O2" } */
gcc.c-torture/compile/20031203-1.c:/* { dg-options "-O2" } */
gcc.c-torture/compile/acc1.c:/* { dg-options "-O2 -ffast-math" } */
gcc.c-torture/compile/builtin_constant_p.c:/* { dg-options "-O2" } */
gcc.c-torture/compile/pr21562.c:/* { dg-options "-O3 -fno-inline" } */
gcc.c-torture/compile/pr25483.c:/* { dg-options "-O -fmove-loop-invariants" }
*/
gcc.c-torture/compile/pr32349.c:/* { dg-options "-O2 -fmodulo-sched" } */
gcc.c-torture/compile/pr32355.c:/* { dg-options "-O3" } */
gcc.c-torture/compile/pr34448.c:/* { dg-options "-O" } */
gcc.c-torture/compile/pr34648.c:/* { dg-options "-O2 -fexceptions" } */

Since dg-options overrides different optimization levels set by
c-torture, those different optimization levels aren't tested on those
files.


-- 
   Summary: Ineffective dg-options in gcc.c-torture/compile
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug c++/35113] [4.3 Regression] g++.dg/ext/vector13.C doesn't work

[bonzini at gnu dot org]

--- Comment #4 from bonzini at gnu dot org  2008-02-07 15:19 ---
Indeed.  I developed my 35049 patch in an old check-out (to avoid conflicts
with Doug's patch), but after updating the tree it fails for me too.


-- 


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

[Bug fortran/32795] allocatable components are nullified prematurely

[pault at gcc dot gnu dot org]

--- Comment #7 from pault at gcc dot gnu dot org  2008-02-07 15:19 ---
Created an attachment (id=15116)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15116&action=view)
A tentative patch for the PR

This is regtesting but all the allocatable component tests are OK.

Could somebody check the memory leakage for me, please?  The test of comment 2
is now OK in that it prints the right numbers.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug target/35100] [4.1/4.2/4.3 regression] internal compiler error: in extract_insn, at recog.c:1990

[debian-gcc at lists dot debian dot org]

--- Comment #4 from debian-gcc at lists dot debian dot org  2008-02-07 
15:15 ---
reproducible with 20080206, gcc is configured with

Configured with: ../src/configure -v --with-pkgversion='Debian 4.3-20080206-1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libffi --enable-objc-gc
--enable-mpfr --disable-softfloat --enable-secureplt
--enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32
--disable-werror --with-long-double-128 --enable-checking=release
--build=powerpc-linux-gnu --host=powerpc-linux-gnu --target=powerpc-linux-gnu
Thread model: posix
gcc version 4.3.0 20080206 (experimental) [trunk revision 132160] (Debian
4.3-20080206-1) 

  Matthias


-- 


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

[Bug libfortran/35063] [Regression wrt g77] I/O leaks handles/memory on Windows XP

[jvdelisle at gcc dot gnu dot org]

--- Comment #17 from jvdelisle at gcc dot gnu dot org  2008-02-07 15:01 
---
Once again, good detective work by jpr.  This then does make this a regression
wrt 4.1.  I do not have a 4.1 build on my windows machine to check.  Regardless
...

This begs a question.  Why do we even want locking on internal units?  The
string is local to the thread and allocated on the stack most likely.  I am not
sure that another thread can even see it.  The unit structure is created on a
per READ/WRITE basis and is freed after the operation is complete.  Anyone else
have any thoughts on this.


-- 


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

[Bug c++/35125] Violating standards

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-07 14:16 ---
This code doesn't work reliably.  Change it to

int main()
{
int size;


cout<<"Enter size of array: ";
cin>>size;

int arr[size];
...


-- 

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

[Bug target/35119] FAIL: g++.dg/template/spec35.C scan-assembler

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2008-02-07 14:16 ---
I get

[ibook-dhum] i686-darwin/gcc% make -k check-g++ 
RUNTESTFLAGS="dg.exp=template/spec35.C"
test -d testsuite || mkdir testsuite
test -d testsuite/g++ || mkdir testsuite/g++
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd ../../gcc-4.3-work/gcc; ${PWDCMD-pwd}` ; export srcdir ; \
cd testsuite/g++; \
rm -f tmp-site.exp; \
sed '/set tmpdir/ s|testsuite|testsuite/g++|' \
< ../../site.exp > tmp-site.exp; \
/bin/sh ${srcdir}/../move-if-change tmp-site.exp site.exp; \
EXPECT=`if [ -f ${rootme}/../expect/expect ] ; then echo
${rootme}/../expect/expect ; else echo expect ; fi` ; export EXPECT ; \
if [ -f ${rootme}/../expect/expect ] ; then  \
   TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWDCMD-pwd}` ;
\
export TCL_LIBRARY ; fi ; \
GCC_EXEC_PREFIX="/opt/gcc/gcc4.3w/lib/gcc/" ; export GCC_EXEC_PREFIX ;
\
`if [ -f ${srcdir}/../dejagnu/runtest ] ; then echo
${srcdir}/../dejagnu/runtest ; else echo runtest; fi` --tool g++
dg.exp=template/spec35.C)
WARNING: Couldn't find the global config file.
Test Run By dominiq on Thu Feb  7 14:57:41 2008
Native configuration is i686-apple-darwin9

=== g++ tests ===

Schedule of variations:
unix

Running target unix
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /sw/share/dejagnu/config/unix.exp as generic interface file for target.
Using /opt/gcc/gcc-4.3-work/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /opt/gcc/gcc-4.3-work/gcc/testsuite/g++.dg/dg.exp ...

=== g++ Summary ===

# of expected passes5
/opt/gcc/i686-darwin/gcc/testsuite/g++/../../g++  version 4.3.0 20080206
(experimental) (GCC) 

with the following patch:

[ibook-dhum] gcc/gcc-4.3-work% diff -u
../_gcc_clean/gcc/testsuite/g++.dg/template/spec35.C
gcc/testsuite/g++.dg/template/spec35.C
--- ../_gcc_clean/gcc/testsuite/g++.dg/template/spec35.C2007-11-15
13:25:04.0 +0100
+++ gcc/testsuite/g++.dg/template/spec35.C  2008-02-07 14:56:12.0
+0100
@@ -8,22 +8,22 @@
 template
 static void f1 (T) { }

-// { dg-final { scan-assembler-not ".glob(a|)l\[\t \]*_Z2f1IfEvT_" } }
+// { dg-final { scan-assembler-not ".glob(a|)l\[\t \]*_?_Z2f1IfEvT_" } }
 template<>
 void f1 (float) { }  // Expected to have static linkage

 template
 void f2 (T) { }

-// { dg-final { scan-assembler ".glob(a|)l\[\t \]*_Z2f2IfEvT_" } }
+// { dg-final { scan-assembler ".glob(a|)l\[\t \]*_?_Z2f2IfEvT_" } }
 template<>
 void f2 (float) { }  // Expected to have global linkage

 void instantiator ()
 {
-  // { dg-final { scan-assembler-not ".glob(a|)l\[\t \]*_Z2f1IiEvT_" } }
+  // { dg-final { scan-assembler-not ".glob(a|)l\[\t \]*_?_Z2f1IiEvT_" } }
   f1(0);  // Expected to have static linkage

-  // { dg-final { scan-assembler ".weak\[\t \]*_Z2f2IiEvT_" } }
+  // { dg-final { scan-assembler ".weak(_definition)?\[\t \]*_?_Z2f2IiEvT_" }
}
   f2(0);  // Expected to have weak global linkage
 }


-- 


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

[Bug tree-optimization/35085] [4.3 Regression] gcc.dg/vect/vect-iv-9.c fails

[ubizjak at gmail dot com]

--- Comment #28 from ubizjak at gmail dot com  2008-02-07 14:15 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||02/msg00215.html
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/35119] FAIL: g++.dg/template/spec35.C scan-assembler

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-02-07 14:13 ---
I mean that other testcases should be using similar patterns, and if they do
the second underscore is probably there.  A quick grep only finds

rtti/tinfo1.C:// { dg-final { scan-assembler-not "(.globl|.global)\[   
\]+_ZTIP9CTemplateIhE" } }

abi/key2.C:// { dg-final { scan-assembler ".globl __ZTI1f\\n   
.weak_definition __ZTI1f\\n .section __DATA,__const_coal,coalesced" } }

where the first one looks incomplete (it will not fail on darwin if there is
__ZTI...), but no other scan-assembler testcase with global symbols are
appearantly there.


-- 


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

[Bug other/32754] The opt?-gen.awk file generators produce incorrect credits

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2008-02-07 20:41 ---
Subject: Bug 32754

Author: manu
Date: Thu Feb  7 20:40:19 2008
New Revision: 132174

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132174
Log:
2008-02-07  Manuel Lopez-Ibanez  <[EMAIL PROTECTED]>

PR other/32754
* doc/options.texi (Options): Replace references to opts.sh with
optc-gen.awk.
* opts-common.c: Likewise.
* optc-gen.awk: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/options.texi
trunk/gcc/optc-gen.awk
trunk/gcc/opts-common.c


-- 


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

[Bug c/35129] -pedantic changes code-generation for unsigned enumerators

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2008-02-07 19:57 ---
Got the blocks/depends thing wrong, sorry.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn|33702   |
OtherBugsDependingO||33702
  nThis||


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

[Bug testsuite/35126] dg-options in gcc.c-torture/execute ignored

[jsm28 at gcc dot gnu dot org]

--- Comment #6 from jsm28 at gcc dot gnu dot org  2008-02-07 19:52 ---


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


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/35113] [4.3 Regression] g++.dg/ext/vector13.C doesn't work

[dgregor at gcc dot gnu dot org]

--- Comment #5 from dgregor at gcc dot gnu dot org  2008-02-07 18:56 ---
This is definitely a canonical-types bug. 


-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||02/msg00230.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-02-07 15:13:39 |2008-02-07 18:56:38
   date||


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

[Bug libfortran/35132] Formatted stream I/O write should truncate

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2008-02-07 22:52 ---
See:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/9e38ff2694bfdab1/

If I understand it correctly, the right solution is do the same as NAG f95 does
and print the following:

123456
ASDFef
End of file on unit 20
Program terminated by I/O error on unit 20 (File="foo.txt",Formatted,Stream)

With the file "foo.txt" containing two lines.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-07 22:52:03
   date||


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

[Bug c/34720] ICE in real_to_decimal, at real.c:1656

[ubizjak at gmail dot com]

--- Comment #9 from ubizjak at gmail dot com  2008-02-07 20:52 ---
Related to PR33992 ?


-- 


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

[Bug bootstrap/33992] [4.3 Regression] profiledbootstrap is broken

[ubizjak at gmail dot com]

--- Comment #18 from ubizjak at gmail dot com  2008-02-07 20:47 ---
(In reply to comment #17)
> P2 - this should not block the release (it's not that profiledbootstrap was
> never
> broken in released compilers).  It's also hard to analyze (no, I'm not on it,
> volunteers welcome).

It looks that ten_to_ptwo() returns wrong result for argumens >= 7.

Try this debug session:

< non-profiled (correct) cc1>:

(gdb) set args -E -quiet /dev/null
(gdb) break real_to_decimal
Breakpoint 3 at 0x599580: file ../../gcc-svn/trunk/gcc/real.c, line 1453.
(gdb) run
Breakpoint ...

(gdb) p *ten_to_ptwo (7)
$1 = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0, 
  uexp = 426, sig = {159020156881263929, 14298703881791668535, 
10644899600020376799}}
---

:



(gdb) p *ten_to_ptwo (7)
$1 = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0, 
  uexp = 423, sig = {5021769561911101971, 862341187440057448, 
11372220470965069550}}

You can see that the results are different.

Suprisingly, result when passing 6 as an argument differs only for one LSB.

(correct):
(gdb) p *ten_to_ptwo (6)
$2 = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0, 
  uexp = 213, sig = {5834422113351499776, 4377335499248575995, 
14012984643248170709}}

(wrong):
(gdb) p *ten_to_ptwo (6)
$2 = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0, 
  uexp = 213, sig = {5834422113351499776, 4377335499248575995, 
14012984643248170708}}

Luckily, ten_to_ptwo() from real.c has only ~20 lines.


-- 


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

[Bug c++/35117] Vectorization on power PC

[irar at il dot ibm dot com]

--- Comment #14 from irar at il dot ibm dot com  2008-02-07 20:44 ---
Giving it another thought, this is not necessary an alias analysis issue, even
that it fails to tell that the pointers not alias. Since in this case the
pointers do differ, the runtime test should take the flow to the vectorized
loop. Maybe the test is too strict. I'll look into this on Sunday.


-- 


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

[Bug testsuite/35126] dg-options in gcc.c-torture/execute ignored

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-02-07 18:06 ---
Sure.  Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|2008-02-07 15:53:56 |2008-02-07 18:06:30
   date||


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

[Bug fortran/35130] OpenMP: Private variable passed to subroutine

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-02-07 22:44 ---
*** Bug 35133 has been marked as a duplicate of this bug. ***


-- 


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

[Bug fortran/35133] OpenMP: Private variable passed to subroutine

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-02-07 22:44 ---


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


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug libgcj/33085] liblt_prog_compiler_pic_GCJ='-DDLL_EXPORT' is wrong

[rondesot at yahoo dot com]

--- Comment #1 from rondesot at yahoo dot com  2008-02-07 17:15 ---
I would like to confirm this bug and discuss a work around that I used.

This bug seems to be the only thing that keeps gcc 4.3 with java from
completing a native build under mingw.

With the two patches below, I was able to build snapshot gcc-4.3-20080118.

The gcj.exe created with this change works a little, about what you would
expect from an early snapshot of a new revision. Simple .java files that have
already been converted into .class files can be compiled into Windows
executables. On the other hand, .java files cannot be compiled directly into
executables because the ecj1.exe program does not seem to work.

Using Sun's javac to compile a simple HelloWorld.java into a .class file then
using gcj to get an .exe. created a working executable.

I could also compile .java files directly by replacing the ecj1.exe file
created by my native build with ecj1.exe from Mohan Embar's GCC/GCJ 4.3
(gcj-eclipse-merge-branch).

More complex programs, i.e. the building an Eclipse SWT Library, do not work.

PATCHES

In gcc\java\jvspec.c, I changed the test for arguments beginning with 'D'

FROM

else if (argv[i][1] == 'D')
  saw_D = 1;

TO

else if (argv[i][1] == 'D' && strcmp (argv[i], "-DDLL_EXPORT") != 0) 
   saw_D = 1;



In gcc\java\jvgenmain.c, I changed the handling of arguments 
beginning with 'D' to treat "-DDL_EXPORT" as it would a non "-D" argument.

FROM

for (i = 1; i < argc; ++i)
  {
if (! strncmp (argv[i], "-D", 2))
  {
/* Handled later.  */
  }
else
  break;
  }


TO

for (i = 1; i < argc; ++i)
  {
if (! strncmp (argv[i], "-D", 2) || strcmp (argv[i], "-DDLL_EXPORT") == 0)
  {
/* Handled later.  */
  }
else
  break;
  }

The second patch may not be doing exactly what is needed. There are several
places within gcc\java\jvgenmain.c where the test for -DDLL_EXPORT can be done.
As this directive should be handled like a non "-D' would be, I guessed that
the test for it should be made as early in the program as possible.

I welcome any help that I can get to improve on this.


-- 

rondesot at yahoo dot com changed:

   What|Removed |Added

Summary|liblt_prog_compiler_pic_GCJ=|liblt_prog_compiler_pic_GCJ=
   |'-DDLL_EXPORT'  is wrong|'-DDLL_EXPORT'  is wrong


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

[Bug c++/35004] Adding 4 more tree codes causes a crash in building libstdc++ pre-compiled headers

[bonzini at gnu dot org]

--- Comment #5 from bonzini at gnu dot org  2008-02-07 17:10 ---
Unrelated, but why couldn''t vector/vector shifts/rotates overload LSHIFT_EXPR
instead? :-)


-- 


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

[Bug fortran/35133] New: OpenMP: Private variable passed to subroutine

[burnus at gcc dot gnu dot org]

As reported by Ignacio Fernández Galván, the following program prints with
"gfortran -fopenmp" 0.0 instead of 42.0. Without -fopenmp or using, e.g., ifort
or sunf95 42.0 is printed.

See also http://gcc.gnu.org/ml/fortran/2008-02/msg00058.html

I believe the program is valid, compare also
http://www.openmp.org/pipermail/omp/2006/000532.html

PROGRAM Outer
 IMPLICIT NONE
 REAL, DIMENSION(20) :: A
 INTEGER :: k
 A = 0.0
!$OMP PARALLEL DO PRIVATE(k)
 DO k=1,SIZE(A)
   CALL Inner(k)
 END DO
!$OMP END PARALLEL DO
 print *, A
CONTAINS
 SUBROUTINE Inner(i)
   IMPLICIT NONE
   INTEGER :: i
   A(i) = 42
 END SUBROUTINE Inner
END PROGRAM Outer


-- 
   Summary: OpenMP: Private variable passed to subroutine
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code, openmp
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/35131] New: OpenMP: Private variable passed to subroutine

[burnus at gcc dot gnu dot org]

As reported by Ignacio Fernández Galván, the following program prints with
"gfortran -fopenmp" 0.0 instead of 42.0. Without -fopenmp or using, e.g., ifort
or sunf95 42.0 is printed.

See also http://gcc.gnu.org/ml/fortran/2008-02/msg00058.html

I believe the program is valid, compare also
http://www.openmp.org/pipermail/omp/2006/000532.html

PROGRAM Outer
 IMPLICIT NONE
 REAL, DIMENSION(20) :: A
 INTEGER :: k
 A = 0.0
!$OMP PARALLEL DO PRIVATE(k)
 DO k=1,SIZE(A)
   CALL Inner(k)
 END DO
!$OMP END PARALLEL DO
 print *, A
CONTAINS
 SUBROUTINE Inner(i)
   IMPLICIT NONE
   INTEGER :: i
   A(i) = 42
 END SUBROUTINE Inner
END PROGRAM Outer


-- 
   Summary: OpenMP: Private variable passed to subroutine
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code, openmp
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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