[Bug tree-optimization/49140] [4.6 regression] wrong code with -O2 and -O3, not with -O3 -no-inline

[grokbrsm at free dot fr]

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

--- Comment #14 from Sébastien Kunz-Jacques  
2011-07-20 07:09:53 UTC ---
Created attachment 24796
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24796
full testcase source with required files from Crypto++ 5.6.1 and build command

the (slightly modified) testcase with Crypto++ 5.6.1, this time self-contained.
All files except gcc_pr49140.cpp are unmodified form Crypto++.
build command is in build.sh, with option -save-temps.

[Bug c/49779] Wrong code generated for while loop with guard containing continue

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  2011-07-20 
07:09:56 UTC ---
The break/continue/goto out of the condition in the do/while/for condition (or
for increment or for init) might very well be considered undefined behavior,
the statement expression extension isn't specified precisely enough to say what
exactly happens.

[Bug c++/45930] AIX: c++ -static-libgcc cores on throw/catch

[cvolkm...@orga-systems.com]

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

Christian Volkmann  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Christian Volkmann  2011-07-20 
07:51:57 UTC ---
The problem does not happen with gcc-4.5.3 and gcc 4.6.1 on AIX 7.1.
I exepct it's fixed in newer g++ versions.

Christian

[Bug bootstrap/49787] [4.7 Regression] --enable-languages=c doesn't work

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug libfortran/49791] New: [4.6 Regression] Formatted namelist reads of arrays don't work

[quantum.analyst at gmail dot com]

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

   Summary: [4.6 Regression] Formatted namelist reads of arrays
don't work
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: quantum.anal...@gmail.com


Created attachment 24797
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24797
Code to reproduce problem

I have some old code that performs a namelist read on a file of formatted form.
There's an array in the namelist. With 4.5.1, reading works just fine, and I
get the following output:

 xpos   0.   0.10001   0.20001 
 0.2   0.400020.   
0.0.0. 
  0.  ypos  0.5   0.59998  
0.69996   0.80004   0.90002
   0.0.0.  
 0.0. 


But with 4.6.0, I get the following error:

At line 15 of file gf-namelist.f (unit = 4, file = 'geometry.in')
Fortran runtime error: Cannot match namelist object name 0.60



gfortran -v for working version:
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.5.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) 

gfortran -v for non-working version:
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.6.0/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.6.0 20110530 (Red Hat 4.6.0-9) (GCC)

[Bug tree-optimization/49140] [4.6 regression] wrong code with -O2 and -O3, not with -O3 -no-inline

[rguenther at suse dot de]

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

--- Comment #15 from rguenther at suse dot de  
2011-07-20 08:44:33 UTC ---
On Tue, 19 Jul 2011, grokbrsm at free dot fr wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49140
> 
> --- Comment #12 from Sébastien Kunz-Jacques  
> 2011-07-19 16:14:29 UTC ---
> Created attachment 24794
>   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24794
> the preprocessed source of Salsa20 from Crypto++, with gcc 4.6.0, option -O2

Hm, unfortunately these don't seem to be self-contained (they fail to
link).

[Bug tree-optimization/49140] [4.6 regression] wrong code with -O2 and -O3, not with -O3 -no-inline

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|WAITING |NEW
  Known to fail||4.6.1

--- Comment #16 from Richard Guenther  2011-07-20 
09:22:45 UTC ---
Confirmed.  Works with -O0, fails with -O[12] at least.  Still fails on the
4.6 branch.

Compiling salsa.cpp with -O1 is enough to trigger the error, compiling
salsa.cpp with -O0 is enough to mitigate it.

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
   Last reconfirmed||2011.07.20 09:30:41
 CC||burnus at gcc dot gnu.org,
   ||jvdelisle at gcc dot
   ||gnu.org
 Ever Confirmed|0   |1
Summary|[4.6 Regression] Formatted  |[4.4/4.5/4.6/4.7
   |namelist reads of arrays|Regression] Formatted
   |don't work  |namelist reads fails with:
   ||Cannot match namelist
   ||object
   Target Milestone|--- |4.4.7

--- Comment #1 from Tobias Burnus  2011-07-20 
09:30:41 UTC ---
CONFIRMED.

 * * *

Note: The format is not standard conform. Issues: "$" vs "&", "$end" vs "/".
However, the real problem is:
 xpos(1)= 0.00, 0.10, 0.20, 0.30, 0.40,
instead of (working)
 xpos(1:5)= 0.00, 0.10, 0.20, 0.30, 0.40,
or
 xpos= 0.00, 0.10, 0.20, 0.30, 0.40,
or
 xpos(:)= 0.00, 0.10, 0.20, 0.30, 0.40,
or
 xpos(1:)= 0.00, 0.10, 0.20, 0.30, 0.40,
or ...

Thus, the workaround is to fix the array bounds in the namelist file.

Note: The program works with ifort, g95, pathf95, openf95, pgf90; it fails with
the pedantic NAG - and (this PR) with the current gfortran versions.

 * * *

Working: (4.6 trunk) 2010-09-28-r164677
 gcc-4.5-2010-07-23-r162436
Failing:
 4.7 trunk: current, 2011-05-10, 2011-05-28-r174379
  gcc-4.5-x86_64-2010-11-13-r166693

Combining the 4.6/4.7 and the 4.5 data, I think the following patch is the
culprit. As it has been back-ported to 4.4/4.5, I have now adapted the summary.
When we know how obvious the patch is, we can still adjust the target milestone
- currently it is 4.4.7.


Author: jvdelisle
Date: Tue Oct 26 19:05:08 2010
New Revision: 165979

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165979
Log:
2010-10-26  Jerry DeLisle  

PR libgfortran/46010
* io/list_read.c (nml_parse_qualifier): Add additional conditions for
setting the end index for loop specification. Fix some whitespace.
* io/write.c (write_default_char4): Const-ify the source argument.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/list_read.c
trunk/libgfortran/io/write.c

[Bug fortran/49792] New: OpenMP workshare: Wrong result with array assignment

[burnus at gcc dot gnu.org]

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

   Summary: OpenMP workshare: Wrong result with array assignment
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: openmp, wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: pk...@dcs.gla.ac.uk


Based on the thread at http://gcc.gnu.org/ml/fortran/2011-07/msg00194.html

OpenMP 3.1 has in "2.5.4 workshare Construct" (normative text):

"An implementation of the workshare construct must insert any synchronization
that is required to maintain standard Fortran semantics. For example, the
effects of one statement within the structured block must appear to occur
before the execution of succeeding statements, and the evaluation of the right
hand side of an assignment must appear to complete prior to the effects of
assigning to the left hand side."


That seems to fail for:

!$omp parallel workshare
a(:) = a(n:1:-1)
!$omp end parallel workshare

which cannot be run in parallel as the element access on the RHS cannot be done
in arbitrary order.

Possible solution: Make use of gfortran's dependency.c machinery but only look
for GFC_DEP_EQUAL and GFC_DEP_NODEP - and ignore, e.g., GFC_DEP_BACKWARD or
GFC_DEP_FORWARD, which indicate that the loop order is important.

[Bug tree-optimization/49140] [4.6 regression] wrong code with -O2 and -O3, not with -O3 -no-inline

[grokbrsm at free dot fr]

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

--- Comment #17 from Sébastien Kunz-Jacques  
2011-07-20 10:09:54 UTC ---
(In reply to comment #16)
> Confirmed.  Works with -O0, fails with -O[12] at least.  Still fails on the
> 4.6 branch.
> 
> Compiling salsa.cpp with -O1 is enough to trigger the error, compiling
> salsa.cpp with -O0 is enough to mitigate it.

yes, the wrong code is most probably generated in method
Salsa20_Policy::OperateKeystream of salsa.cpp.

[Bug c++/49793] New: Narrowing conversion from int to double with -std=c++0x

[bugzilla.gcc.gnu.com at sklep dot czarko.net]

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

   Summary: Narrowing conversion from int to double with
-std=c++0x
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bugzilla.gcc.gnu@sklep.czarko.net


This code compiles fine with -ansi but fails with -std=c++0x:

struct Size
{
double w;
double h;
};

int foo( const int a )
{
return a;
}

int main()
{
const intleft= foo( 12 );
const intright   = foo( 33 );
const intbottom  = foo( 11 );
const inttop = foo( 99 );
const intwidth   = right - left;
const intheight  = top - bottom;
const intl   = 12;
const intr   = 33;
const intb   = 11;
const intt   = 99;
const intw   = r - l;
const inth   = t - b;
const double wd  = right - left;
const double ht  = top - bottom;

Size size1;
size1.w = right - left;
size1.h = top - bottom;

const Size size2 = { r - l, t - b };

const Size size3 = { w, h };

const Size size4 = { wd, ht };

const Size size5 = { width, height };

const Size size6 = { right - left, top - bottom };

return 0;
}

g++ -std=c++0x -o a a.cpp
a.cpp: In function ‘int main()’:
a.cpp:39:40: error: narrowing conversion of ‘width’ from ‘const int’ to
‘double’ inside { } [-fpermissive]
a.cpp:39:40: error: narrowing conversion of ‘height’ from ‘const int’ to
‘double’ inside { } [-fpermissive]
a.cpp:41:53: error: narrowing conversion of ‘(((int)right) - ((int)left))’ from
‘int’ to ‘double’ inside { } [-fpermissive]
a.cpp:41:53: error: narrowing conversion of ‘(((int)top) - ((int)bottom))’ from
‘int’ to ‘double’ inside { } [-fpermissive]


It looks like compiler accepts some conversions from int to double as valid but
it complains about others at the same time.

If const is removed from the code then additional two errors are reported:

a.cpp:33:39: error: narrowing conversion of ‘(r - l)’ from ‘int’ to ‘double’
inside { } [-fpermissive]
a.cpp:33:39: error: narrowing conversion of ‘(t - b)’ from ‘int’ to ‘double’
inside { } [-fpermissive]
a.cpp:35:31: error: narrowing conversion of ‘w’ from ‘int’ to ‘double’ inside {
} [-fpermissive]
a.cpp:35:31: error: narrowing conversion of ‘h’ from ‘int’ to ‘double’ inside {
} [-fpermissive]


If I replace int with short then the errors which are reported are:

a.cpp:39:40: error: narrowing conversion of ‘width’ from ‘const short int’ to
‘double’ inside { } [-fpermissive]
a.cpp:39:40: error: narrowing conversion of ‘height’ from ‘const short int’ to
‘double’ inside { } [-fpermissive]
a.cpp:41:53: error: narrowing conversion of ‘(((int)right) - ((int)left))’ from
‘int’ to ‘double’ inside { } [-fpermissive]
a.cpp:41:53: error: narrowing conversion of ‘(((int)top) - ((int)bottom))’ from
‘int’ to ‘double’ inside { } [-fpermissive]

and with char instead of int:

a.cpp:39:40: error: narrowing conversion of ‘width’ from ‘const char’ to
‘double’ inside { } [-fpermissive]
a.cpp:39:40: error: narrowing conversion of ‘height’ from ‘const char’ to
‘double’ inside { } [-fpermissive]
a.cpp:41:53: error: narrowing conversion of ‘(((int)right) - ((int)left))’ from
‘int’ to ‘double’ inside { } [-fpermissive]
a.cpp:41:53: error: narrowing conversion of ‘(((int)top) - ((int)bottom))’ from
‘int’ to ‘double’ inside { } [-fpermissive]

[Bug c++/49793] Narrowing conversion from int/short/char to double with -std=c++0x

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Paolo Carlini  2011-07-20 
11:01:04 UTC ---
Jason, can you double check this? Thanks in advance.

[Bug bootstrap/49794] New: [4.7 regression] Solaris 10/x86 bootstrap broken by C++ build

[ro at gcc dot gnu.org]

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

   Summary: [4.7 regression] Solaris 10/x86 bootstrap broken by
C++ build
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: i...@airs.com
  Host: i386-pc-solaris2.10
Target: i386-pc-solaris2.10
 Build: i386-pc-solaris2.10


Solaris 10/x86 bootstrap is broken as of r176500: there are two failures in
stage2 libcpp:

/vol/gcc/src/hg/trunk/local/libcpp/charset.c: In function 'bool
convert_using_iconv(iconv_t, const uchar*, size_t, _cpp_strbuf*)':
/vol/gcc/src/hg/trunk/local/libcpp/charset.c:579:62: error: invalid conversion
from 'const char**' to 'char**' [-fpermissive]

The problem is that  has two variant iconv() declarations:

#ifdef _XPG6
extern size_ticonv(iconv_t, char **_RESTRICT_KYWD,
size_t *_RESTRICT_KYWD, char **_RESTRICT_KYWD,
size_t *_RESTRICT_KYWD);
#else
extern size_ticonv(iconv_t, const char **_RESTRICT_KYWD,
size_t *_RESTRICT_KYWD, char **_RESTRICT_KYWD,
size_t *_RESTRICT_KYWD);
#endif

libcpp configure is run with xgcc, which doesn't define _XOPEN_SOURCE 600, but
g++, which is used to compile libcpp, does, so the value of ICONV_CONST is
wrong.

The next failures is in init.c:

/vol/gcc/src/hg/trunk/local/libcpp/init.c:61:3: error: expected identifier
before '='
/vol/gcc/src/hg/trunk/local/libcpp/init.c:61:3: error: type '' with no
linkage used to declare function 'void::operator()() const' with
linkage [-fpermissive]
/vol/gcc/src/hg/trunk/local/libcpp/init.c: In lambda function:
/vol/gcc/src/hg/trunk/local/libcpp/init.c:61:3: error: expected '{' before '='
token
/vol/gcc/src/hg/trunk/local/libcpp/init.c: At global scope:
/vol/gcc/src/hg/trunk/local/libcpp/init.c:61:3: error: lambda expressions only
available with -std=c++0x or -std=gnu++0x [-Werror]
/vol/gcc/src/hg/trunk/local/libcpp/init.c:61:3: error: no match for 'operator='
in '{} = '#''
/vol/gcc/src/hg/trunk/local/libcpp/init.c:61:3: note: candidate is:
/vol/gcc/src/hg/trunk/local/libcpp/init.c:61:3: note:
&::operator=(const&)
/vol/gcc/src/hg/trunk/local/libcpp/init.c:61:3: note:   no known conversion for
argument 1 from 'char' to 'const&'

And many more errors.  The relevant section in the -g3 -save-temps outputis

__extension__ const uchar _cpp_trigraph_map[(127 * 2 + 1) + 1] = {
  ['='] = '#', [')'] = ']', ['!'] = '|',
  ['('] = '[', ['\''] = '^', ['>'] = '}',
  ['/'] = '\\', ['<'] = '{', ['-'] = '~',
};

[Bug tree-optimization/49795] New: vectorization of conditional code happens only on local variables

[vincenzo.innocente at cern dot ch]

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

   Summary: vectorization of conditional code happens only on
local variables
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch


in this example loop1 does not vectorize, loop2 does 
const int N=64;
float c[N];
float d[N];

void loop1() {
  for (int i=0; i!=N; ++i) {
if (c[i]<0) d[i] = -d[i];
  }
}

void loop2() {
  for (int i=0; i!=N; ++i) {
float tmp = d[i];
if (c[i]<0) tmp = -tmp;
d[i]=tmp;
  }
}

[Bug tree-optimization/49795] vectorization of conditional code happens only on local variables

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  2011-07-20 
11:57:56 UTC ---
At least from C++0x memory model or OpenMP POV that's highly desirable.
In loop1 d[i] isn't written unconditionally, in loop2 it is, so transforming
loop1 code into loop2 might introduce data races.

[Bug tree-optimization/49795] vectorization of conditional code happens only on local variables

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  2011-07-20 
12:00:32 UTC ---
Interesting. Then I would be curious to know what other respected compilers vs
OpenMP do in this area, eg, Intel..

[Bug tree-optimization/49795] vectorization of conditional code happens only on local variables

[vincenzo.innocente at cern dot ch]

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

--- Comment #3 from vincenzo Innocente  
2011-07-20 12:32:21 UTC ---
my actual code looks more like this
void loop() {
  for (int i=0; i!=N; ++i) {
d[i]=a[i]+b[i];
if (c[i]<0) d[i] = -d[i];
  }
}
where d[i] IS written unconditionally (and does not vectorize either)

[Bug target/49423] [arm] internal compiler error: in push_minipool_fix

[mikpe at it dot uu.se]

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

--- Comment #7 from Mikael Pettersson  2011-07-20 
12:35:53 UTC ---
gcc-4.6-20110715 still ICEs on this test case, so unfortunately the PR49094 fix
didn't solve this problem.

[Bug tree-optimization/49795] vectorization of conditional code happens only on local variables

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2011-07-20 
12:41:07 UTC ---
That is something different, yeah, in that case the transformation doesn't
introduce new data races and is desirable as well, not just for vectorization.

[Bug target/49780] [x32] internal compiler error: in create_mem_ref, at tree-ssa-address.c:806

[uros at gcc dot gnu.org]

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

--- Comment #1 from uros at gcc dot gnu.org 2011-07-20 12:58:31 UTC ---
Author: uros
Date: Wed Jul 20 12:58:28 2011
New Revision: 176506

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176506
Log:
PR target/49780
* config/i386/predicates.md (no_seg_addres_operand): No more special.
* config/i386/i386.c (ix86_decompose_address): Allow only subregs
of DImode hard registers in base.
(ix86_legitimate_address_p): Allow SImode and DImode base and index
registers.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/predicates.md

[Bug target/49780] [x32] internal compiler error: in create_mem_ref, at tree-ssa-address.c:806

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Target||x32
 Status|UNCONFIRMED |RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-07/msg01555.htm
   ||l
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #2 from Uros Bizjak  2011-07-20 13:04:16 
UTC ---
Fixed.

[Bug bootstrap/49786] [4.7 Regression] bootstrap failed with bootstrap-profiled

[ian at airs dot com]

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

--- Comment #2 from Ian Lance Taylor  2011-07-20 13:25:32 
UTC ---
I'm using an x86_64 Ubuntu Lucid system.  I'm using unmodified revision 176479
of mainline.  I used ppl-0.11 and cloog-0.16.2 from
ftp://gcc.gnu.org/pub/gcc/infrastructure.  I configured like this:

../trunk/configure --enable-clocale=gnu --with-system-zlib --enable-shared
--with-demangler-in-ld --enable-cloog-backend=isl
--with-ppl=/home/iant/gnu/ppl-0.11-install
--with-cloog=/home/iant/gnu/cloog-0.16.2-install
--with-build-config=bootstrap-lto --with-fpmath=sse
--enable-languages=c,c++,fortran,java,lto,objc

I ran "make profiledbootstrap".  The bootstrap completed successfully.

How can I recreate the problem?

[Bug bootstrap/49786] [4.7 Regression] bootstrap failed with bootstrap-profiled

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  2011-07-20 13:31:09 
UTC ---
(In reply to comment #2)
> I'm using an x86_64 Ubuntu Lucid system.  I'm using unmodified revision 176479
> of mainline.  I used ppl-0.11 and cloog-0.16.2 from
> ftp://gcc.gnu.org/pub/gcc/infrastructure.  I configured like this:
> 
> ../trunk/configure --enable-clocale=gnu --with-system-zlib --enable-shared
> --with-demangler-in-ld --enable-cloog-backend=isl
> --with-ppl=/home/iant/gnu/ppl-0.11-install
> --with-cloog=/home/iant/gnu/cloog-0.16.2-install
> --with-build-config=bootstrap-lto --with-fpmath=sse
> --enable-languages=c,c++,fortran,java,lto,objc
> 
> I ran "make profiledbootstrap".  The bootstrap completed successfully.
> 
> How can I recreate the problem?

I saw it on a 8-core machine with "make -j8 profiledbootstrap".

[Bug middle-end/18908] Missed folding opportunities with bools

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Guenther  2011-07-20 
13:35:27 UTC ---
Author: rguenth
Date: Wed Jul 20 13:35:20 2011
New Revision: 176508

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176508
Log:
2011-07-20  Richard Guenther  

PR middle-end/18908
* tree.c (integer_all_onesp): Use TYPE_PRECISION, not mode precision.
* tree-ssa-forwprop.c (simplify_bitwise_binary): Remove bogus
ADDR_EXPR folding.  Canonicalize X ^ ~0 as ~X.

* gcc.dg/tree-ssa/pr18908.c: New testcase.
* gcc.dg/tree-ssa/bitwise-sink.c: Adjust.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr18908.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/bitwise-sink.c
trunk/gcc/tree-ssa-forwprop.c

[Bug middle-end/18908] Missed folding opportunities with bools

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Guenther  2011-07-20 
13:36:33 UTC ---
Author: rguenth
Date: Wed Jul 20 13:36:30 2011
New Revision: 176510

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176510
Log:
2011-07-20  Richard Guenther  

PR middle-end/18908
* tree.c (integer_all_onesp): Use TYPE_PRECISION, not mode precision.
* tree-ssa-forwprop.c (simplify_bitwise_binary): Remove bogus
ADDR_EXPR folding.  Canonicalize X ^ ~0 as ~X.

* gcc.dg/tree-ssa/pr18908.c: New testcase.
* gcc.dg/tree-ssa/bitwise-sink.c: Adjust.

Modified:
trunk/gcc/tree.c

[Bug bootstrap/49787] [4.7 Regression] --enable-languages=c doesn't work

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Ian Lance Taylor  2011-07-20 14:09:05 
UTC ---
Fixed.

[Bug bootstrap/49787] [4.7 Regression] --enable-languages=c doesn't work

[ian at gcc dot gnu.org]

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

--- Comment #4 from ian at gcc dot gnu.org  2011-07-20 
14:08:44 UTC ---
Author: ian
Date: Wed Jul 20 14:08:42 2011
New Revision: 176512

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176512
Log:
PR bootstrap/49787
* configure.ac: Move --enable-bootstrap handling earlier in file.
If --enable-bootstrap and either --enable-build-with-cxx or
--enable-build-poststage1-with-cxx, enable C++ automatically.
* configure: Rebuild.

Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac

[Bug bootstrap/49786] [4.7 Regression] bootstrap failed with bootstrap-profiled

[ian at airs dot com]

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

--- Comment #4 from Ian Lance Taylor  2011-07-20 14:11:55 
UTC ---
Is it repeatable for you?  I don't know how to investigate this if I can't
repeat it myself.  I also don't see how this could be related to the change to
building with C++, though of course anything is possible.  I was using "make
-j6" but I think it's only a dual-core system.

[Bug bootstrap/49786] [4.7 Regression] bootstrap failed with bootstrap-profiled

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  2011-07-20 14:16:47 
UTC ---
(In reply to comment #4)
> Is it repeatable for you?  I don't know how to investigate this if I can't
> repeat it myself.  I also don't see how this could be related to the change to
> building with C++, though of course anything is possible.  I was using "make
> -j6" but I think it's only a dual-core system.

Please see "Gcc [trunk revision XXX] failed to profiledbootstrap on x86_64!":

http://gcc.gnu.org/ml/gcc-regression/2011-07/

[Bug c++/42603] [C++0x] decltype not supported for parent class specifier

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  2011-07-20 
14:21:09 UTC ---
Author: jason
Date: Wed Jul 20 14:21:05 2011
New Revision: 176513

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176513
Log:
PR c++/6709 (DR 743)
PR c++/42603 (DR 950)
gcc/cp/
* parser.c (token_is_decltype, cp_lexer_next_token_is_decltype): New.
(cp_parser_nested_name_specifier_opt): Allow decltype.
(cp_parser_qualifying_entity): Likewise.
(cp_parser_decltype): Replace source tokens with CPP_DECLTYPE.
(cp_parser_simple_type_specifier): Handle decltype as scope.
(cp_parser_base_specifier): Allow decltype.
(cp_parser_base_clause): Don't crash on null base.
* parser.h (CPP_KEYWORD, CPP_TEMPLATE_ID): Move to c-common.h.
(CPP_NESTED_NAME_SPECIFIER, N_CP_TTYPES): Likewise.
gcc/c-family/
* c-common.h (CPP_KEYWORD, CPP_TEMPLATE_ID): Move from cp/parser.h.
(CPP_NESTED_NAME_SPECIFIER, N_CP_TTYPES): Likewise.
(CPP_DECLTYPE): New.
* c-common.c (c_parse_error): Handle CPP_DECLTYPE.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/decltype21.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/cp/parser.h
trunk/gcc/testsuite/ChangeLog

[Bug c++/6709] [DR743] decltype cannot be used with the :: operator

[jason at gcc dot gnu.org]

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

--- Comment #19 from Jason Merrill  2011-07-20 
14:21:09 UTC ---
Author: jason
Date: Wed Jul 20 14:21:05 2011
New Revision: 176513

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176513
Log:
PR c++/6709 (DR 743)
PR c++/42603 (DR 950)
gcc/cp/
* parser.c (token_is_decltype, cp_lexer_next_token_is_decltype): New.
(cp_parser_nested_name_specifier_opt): Allow decltype.
(cp_parser_qualifying_entity): Likewise.
(cp_parser_decltype): Replace source tokens with CPP_DECLTYPE.
(cp_parser_simple_type_specifier): Handle decltype as scope.
(cp_parser_base_specifier): Allow decltype.
(cp_parser_base_clause): Don't crash on null base.
* parser.h (CPP_KEYWORD, CPP_TEMPLATE_ID): Move to c-common.h.
(CPP_NESTED_NAME_SPECIFIER, N_CP_TTYPES): Likewise.
gcc/c-family/
* c-common.h (CPP_KEYWORD, CPP_TEMPLATE_ID): Move from cp/parser.h.
(CPP_NESTED_NAME_SPECIFIER, N_CP_TTYPES): Likewise.
(CPP_DECLTYPE): New.
* c-common.c (c_parse_error): Handle CPP_DECLTYPE.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/decltype21.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/cp/parser.h
trunk/gcc/testsuite/ChangeLog

[Bug lto/49796] New: [4.7 Regression] 483.xalancbmk/447.dealII in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

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

   Summary: [4.7 Regression] 483.xalancbmk/447.dealII in SPEC CPU
2006 failed to build
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86-64, revision 176460 gave

g++  -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver
-fuse-linker-plugin  -DSPEC_CPU_LP64 
...
lto1: error: edge points to wrong declaration:
 >
QI
size 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x2b8492a42540 method
basetype 
arg-types 
chain 
chain 
public external QI file XalanDOMString.cpp line 68 col 1 align 16 context

arguments 
readonly unsigned DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x2b8492213540
reference_to_this >
readonly unsigned DI file XalanDOMString.cpp line 70 col 25 size
 unit size 
align 64 context  arg-type

chain 
used unsigned DI file XalanDOMString.cpp line 69 col 25 size
 unit size 
align 64 context 
arg-type  chain >>
result 
ignored VOID file XalanDOMString.cpp line 80 col 1
align 8 context >>
 Instead of: >
QI
size 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x2b849283 method
basetype 
arg-types 
chain 
chain 
chain 
pointer_to_this >
addressable used public external QI file XalanDOMString.cpp line 68 col 1
align 16 context 
arguments 
readonly unsigned DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x2b8492213540
reference_to_this >
readonly used unsigned DI file XalanDOMString.cpp line 70 col 25 size
 unit size 
align 64 context  arg-type

chain 
used unsigned DI file XalanDOMString.cpp line 69 col 25 size
 unit size 
align 64 context 
arg-type  chain >>
result 
ignored VOID file XalanDOMString.cpp line 80 col 1
align 8 context >>
problem/1733 @0x2b84923a4a20 (asm:
_ZNK10xalanc_1_814XSLTEngineImpl7problemERKNS_14XalanDOMStringENS_15ProblemListener15eClassificationERKN11xercesc_2_57LocatorEPKNS_9XalanNodeE.13971)
availability:local analyzed body local prevailing_def_ironly finalized
  called by: error/1732 (1.00 per call) (can throw external) warn/254 (0.78 per
call) (can throw external) 
  calls: __cxa_free_exception/2559 __comp_dtor /2539 __comp_dtor /2539
__cxa_throw/2560 (can throw external) __comp_dtor /2539 __comp_dtor /2539
__comp_ctor /1735 _ZN10xalanc_1_814XalanDOMStringC2EPKtj.constprop.15198/778
_ZN10xalanc_1_814XalanDOMStringC2EPKcj.constprop.15237/2562
__cxa_allocate_exception/2563 
  References:  var:theDummy (addr)
var:_ZTIN10xalanc_1_822XSLTProcessorExceptionE (addr) fn:__comp_dtor /257
(addr)
  Refering this function: 
  has 4 outgoing edges for indirect calls.
lto1: internal compiler error: verify_cgraph_node failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[4]: *** [/tmp/ccQtX8la.ltrans6.ltrans.o] Error 1
lto-wrapper: make returned 2 exit status
/usr/local/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
specmake[3]: *** [Xalan] Error 1

g++  -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver
-fuse-linker-plugin  -DSPEC_CPU_LP64 ...
...
lto1: error: edge points to wrong declaration:
 >
QI
size 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x2abd3c08f0a8 method
basetype 
arg-types 
chain 
chain 
chain >
public external autoinline QI defer-output file
/export/gnu/import/svn/gcc-test-spec-lto/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_vector.h
line 289 col 7 align 16 context 
arguments 
readonly unsigned DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x2abd3c083498>
readonly unsigned DI file
/export/gnu/import/svn/gcc-test-spec-lto/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_vector.h
line 290 col 51 size  unit size 
align 64 context  arg-type

chain 
used unsigned DI file
/export/gnu/import/svn/gcc-test-spec-lto/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_vector.h
line 289 col 24 size  unit size 
align 64 context 
arg-type  chain >>
result 
ignored VOID file
/export/gnu/import/svn/gcc-test-spec-lto/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../..

[Bug lto/49796] [4.7 Regression] 483.xalancbmk/447.dealII in SPEC CPU 2006 failed to build

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug bootstrap/49794] [4.7 regression] Solaris 10/x86 bootstrap broken by C++ build

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug tree-optimization/49795] vectorization of conditional code happens only on local variables

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.20 14:53:41
 CC||rguenth at gcc dot gnu.org,
   ||spop at gcc dot gnu.org
 Ever Confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #5 from Richard Guenther  2011-07-20 
14:53:41 UTC ---
I think you at least need -ftree-loop-if-convert-stores to vectorize
conditional stores, but it doens't seem to work in this case.

[Bug bootstrap/49786] [4.7 Regression] bootstrap failed with bootstrap-profiled

[ian at airs dot com]

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

--- Comment #6 from Ian Lance Taylor  2011-07-20 15:29:58 
UTC ---
I'm sorry, I can't see any useful information in that link.  It seems to simply
repeat the information that is already in this bug report.  Am I missing
something?

[Bug bootstrap/49786] [4.7 Regression] bootstrap failed with bootstrap-profiled

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther  2011-07-20 
15:34:59 UTC ---
I think you need to make sure that a / the linker plugin works.  IIRC HJ
uses his own binutils branch and GNU ld.

So in case you are using gold (and configury correctly detects that and
enables linker plugin use by default) try using GNU ld instead.

[Bug bootstrap/49786] [4.7 Regression] bootstrap failed with bootstrap-profiled

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #8 from Richard Guenther  2011-07-20 
15:36:56 UTC ---
Btw, I think we're running into a bug in the new IPA-CP code (see the SPEC 2k6
LTO build fails HJ also reported).  Thus, CCing martin.

[Bug target/34888] Stack patterns for AVR not optimal

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |RESOLVED
 CC||gjl at gcc dot gnu.org
 Resolution||FIXED
   Target Milestone|--- |4.5.3

--- Comment #1 from Georg-Johann Lay  2011-07-20 
15:36:44 UTC ---
Closed: This was fixed by Anatoly long ago:
http://gcc.gnu.org/viewcvs?view=revision&revision=124854

[Bug lto/49796] [4.7 Regression] 483.xalancbmk/447.dealII in SPEC CPU 2006 failed to build

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #1 from Richard Guenther  2011-07-20 
15:38:17 UTC ---
Likely caused by the IPA-CP rewrite.

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org 2011-07-20 15:42:23 UTC ---
(In reply to comment #1)
> CONFIRMED.
> 
>  * * *
> 
> Note: The format is not standard conform. Issues: "$" vs "&", "$end" vs "/".
>
> However, the real problem is:
>  xpos(1)= 0.00, 0.10, 0.20, 0.30, 0.40,

> 
> Thus, the workaround is to fix the array bounds in the namelist file.
>

Why are you calling this a workaround.  It looks like it is fixing
a bug in the user's program.

> 
> Note: The program works with ifort, g95, pathf95, openf95, pgf90; it fails 
> with
> the pedantic NAG - and (this PR) with the current gfortran versions.
> 
>  * * *
> 
> Working: (4.6 trunk) 2010-09-28-r164677
>  gcc-4.5-2010-07-23-r162436
> Failing:
>  4.7 trunk: current, 2011-05-10, 2011-05-28-r174379
>   gcc-4.5-x86_64-2010-11-13-r166693
> 

I'm also not sure why you call this a regression.  The user
appears to use on a nonconforming namelist, which depends on
undefined behavior.  The behavior has change.

-- 
steve

[Bug bootstrap/49786] [4.7 Regression] bootstrap failed with bootstrap-profiled

[jamborm at gcc dot gnu.org]

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

--- Comment #9 from Martin Jambor  2011-07-20 
15:47:54 UTC ---
(In reply to comment #8)
> Btw, I think we're running into a bug in the new IPA-CP code (see the SPEC 2k6
> LTO build fails HJ also reported).  Thus, CCing martin.

I understand this is LTO profiled bootstrap.  I did not try that
before committing (as opposed to one without LTO).  I will try doing
that with and without the patch.

[Bug target/49473] [arm] poor scheduling of loads

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.20 15:59:59
 CC||ramana at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Ramana Radhakrishnan  2011-07-20 
15:59:59 UTC ---

> - the add at .LPIC0 will stall for two cycles because the preceding load has a
> result latency of three.  The two subsequent MOVs could have been scheduled in
> these slots since they don't have any data dependency on the ADD;

This looks like it might be to do with the latency of the call instruction at
least for the LPIC0 case. The scheduler thinks that r0 isn't ready really till
cycle 34 or so and hence the compiler can't hoist the mov r5, r0 above the add
r4, pc, r4 . 


The case around LPIC1 doesn't seem to show up in a recent build of trunk I have
: 

.L5:
ldr r1, .L7+24  @ 135   pic_load_addr_32bit [length = 4]
add r2, r5, #32768  @ 25*arm_addsi3/1   [length = 4]
mov r0, r7  @ 27*arm_movsi_insn/1   [length = 4]
.LPIC1:
add r1, pc, r1  @ 28pic_add_dot_plus_eight  [length = 4]
add r2, r2, #180@ 29*arm_addsi3/1   [length = 4]
bl  gst_structure_get_int(PLT)  @ 30*call_value_symbol


This is the bit I see with a more recent version of trunk and that looks better
than what was shown in this case. 

We need to dig further into the 1136 TRM for the other comments in this report. 


Ramana

[Bug c++/42603] [C++0x] decltype not supported for parent class specifier

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0
   Severity|normal  |enhancement

--- Comment #6 from Jason Merrill  2011-07-20 
16:15:05 UTC ---
Implemented for 4.7.

[Bug bootstrap/49797] New: CLooG use of LANGUAGE_C conflicts with MIPS compilers

[ro at gcc dot gnu.org]

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

   Summary: CLooG use of LANGUAGE_C conflicts with MIPS compilers
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: s...@gcc.gnu.org
  Host: mips-sgi-irix6.5
Target: mips-sgi-irix6.5
 Build: mips-sgi-irix6.5


When trying a mips-sgi-irix6.5 bootstrap with C++ in stages 2 and 3, I failed
due to an issue that had been hidden previously: I'm building with ppl/cloog.
Building ClooG initially failed since gcc (or any compiler on MIPS) predefines
LANGUAGE_C, which is also used by .  As a hack, I renamed those
defines to CLOOG_LANGUAGE_C and CLOOG_LANGUAGE_FORTRAN, not noticing that
graphite-clast-to-gimple.c has a use of LANGUAGE_C and now got the wrong value.

When compiling with g++, LANGUAGE_C isn't defined any longer and the build
breaks:

/vol/gcc/src/hg/trunk/local/gcc/graphite-clast-to-gimple.c: In function
'CloogOptions* set_cloog_options()':
/vol/gcc/src/hg/trunk/local/gcc/graphite-clast-to-gimple.c:1309:23: error:
'LANGUAGE_C' was not declared in this scope
make[3]: *** [graphite-clast-to-gimple.o] Error 1

The question is how best to fix this?  One might change upstream CLooG to use
CLOOG_LANGUAGE_C instead to avoid the clash, test for that in
graphite-clast-to-gimple.c
and require MIPS users to upgrade or fix their local copies?

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2011-07-20 
16:16:43 UTC ---
(In reply to comment #2)
> Why are you calling this a workaround.  It looks like it is fixing
> a bug in the user's program.

In an ideal world, all code would use only standard Fortran and fixing the code
would be trivial. However, in a real world, we live with more or less common
vendor extensions which are used by real programs, even if there is now a
better standard-conform replacement. I am sure that version of namelist
predates Fortran 90.

If the bug reporter can, I think he should convert all the input files to the
Fortran 90 syntax of namelists. However, one needs to be careful to not
inadvertently to change the meaning (e.g. remove the wrong "(1)") and it might
affect many files.


> I'm also not sure why you call this a regression.

That's simple: It worked before, now it stopped. As the vendor extension is
very common - it works at least with PGI, Intel, g95, gfortran (before the
2010-10), Sun, Open64, Pathf95 and crayftn, it makes sense to regard this as
supported vendor extension. (I am sure more compiler support it, but I don't
have access to them.)

A different example would be:
  &nml tag = string /
which is only supported by ifort. All other compilers fail as "string" is not
quoted. If gfortran had supported such a feature as only compiler or as one of
very few compilers, I would agree that breaking it, would probably fall into
the WONTFIX category.

[Bug tree-optimization/49749] Reassociation rank algorithm does not include all non-NULL operands

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |wschmidt at gcc dot gnu.org
   |gnu.org |

--- Comment #9 from William J. Schmidt  2011-07-20 
16:28:49 UTC ---
Created attachment 24798
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24798
Proposed patch

I'm attaching a patch that solves this issue.  The patch was produced against
the ibm/gcc-4_6-branch, but should apply OK to trunk -- I'll verify that later
if the direction of this patch is acceptable.  This regains the 20% performance
loss we had experienced in 410.bwaves, and also gives a 5% boost to 444.namd. 
No significant degradations were observed on SPEC cpu2006.

In addition to fixing the operand access problems, the patch looks for
loop-carried dependencies in innermost loops, and biases the reassociation so
that the phi target is summed last.  The purpose of this is to identify
accumulator variables in inner loops and make each iteration of their
accumulations independent.  When these loops are unrolled, multiple independent
iterations can be interleaved for improved performance.

The optimization is restricted to innermost loops to avoid unnecessarily
raising register pressure.

There may be a better way to achieve the bias than what I've chosen here, so
please comment.  If the general approach is acceptable, I'll apply comments and
submit the patch for approval.

[Bug bootstrap/49786] [4.7 Regression] bootstrap failed with bootstrap-profiled

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||markus at trippelsdorf dot
   ||de

--- Comment #10 from Markus Trippelsdorf  
2011-07-20 16:38:38 UTC ---
Also happens with gold:

/var/tmp/gcc_build_dir/./prev-gcc/xgcc -B/var/tmp/gcc_build_dir/./prev-gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/bin/
-B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include
-isystem /usr/x86_64-pc-linux-gnu/sys-include  -march=native -O2 -pipe
-flto=jobserver -frandom-seed=1 -fprofile-use -DIN_GCC   -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common 
-DHAVE_CONFIG_H -DGENERATOR_FILE
-Wl,-O1,--hash-style=gnu,--as-needed,--gc-sections,--icf=all,--icf-iterations=3
 -o build/genautomata \
build/genautomata.o build/rtl.o build/read-rtl.o build/ggc-none.o
build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o
build/read-md.o build/errors.o .././libiberty/libiberty.a -lm
lto1: error: caller edge count is negative
vec_heap_p_reserve.constprop.79/580 @0x7fc29b280480 (asm:
vec_heap_p_reserve.constprop.79) (clone of vec_heap_p_reserve/537)
availability:local analyzed executed 16253965x reachable local finalized
  called by: VEC_alt_state_t_heap_reserve/146 VEC_ainsn_t_heap_reserve/140
VEC_state_t_heap_reserve/133 (13343217x) (0.00 per call)
VEC_decl_t_heap_reserve/124 (0.01 per call) VEC_reserv_sets_t_heap_reserve/118
(1.00 per call) VEC_unit_usage_t_heap_reserve/110 (0.05 per call)
VEC_alt_state_t_heap_reserve.3046.constprop.49/451
VEC_ainsn_t_heap_reserve.3003.constprop.55/523
VEC_state_t_heap_reserve.2975.constprop.59/534 (-6021287x) (0.00 per call)
VEC_decl_t_heap_reserve.2922.constprop.65/545 (179900x) (0.01 per call)
VEC_reserv_sets_t_heap_reserve.2884.constprop.70/550 (1.00 per call)
VEC_unit_usage_t_heap_reserve.2828.constprop.78/578 (8752135x) (0.05 per call)
  calls: vec_heap_o_reserve_1.4977.constprop.80/581 (850115x) (1.00 per call)
  References:
  Refering this function:
lto1: internal compiler error: verify_cgraph_node failed

[Bug tree-optimization/49749] Reassociation rank algorithm does not include all non-NULL operands

[wschmidt at gcc dot gnu.org]

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

--- Comment #10 from William J. Schmidt  
2011-07-20 16:39:26 UTC ---
Created attachment 24799
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24799
The real proposed patch

Oh, for Pete's sake.  I attached the wrong patch.  Here's the right one.

[Bug lto/49796] [4.7 Regression] 483.xalancbmk/447.dealII in SPEC CPU 2006 failed to build

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.07.20 16:39:51
 AssignedTo|unassigned at gcc dot   |jamborm at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Martin Jambor  2011-07-20 
16:39:51 UTC ---
Indeed.  It is strange I did not hit this bug when I was examining the impact
of IPA-CP on SPEC.  However, it is most probably a bug in the verifier. Anyway,
mine.

[Bug bootstrap/49794] [4.7 regression] Solaris 10/x86 bootstrap broken by C++ build

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-07/msg01646.htm
   ||l
   Last reconfirmed||2011.07.20 16:39:43
 AssignedTo|unassigned at gcc dot   |ro at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Rainer Orth  2011-07-20 16:39:43 UTC 
---
Mine, initial patch posted.

[Bug tree-optimization/49795] vectorization of conditional code happens only on local variables

[vincenzo.innocente at cern dot ch]

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

--- Comment #6 from vincenzo Innocente  
2011-07-20 16:59:20 UTC ---
actually  -ftree-loop-if-convert-stores does the "trick" with -Ofast

things are not fully consistent though
of these four loop I get the following
notice how the combination -ftree-loop-if-convert-stores -03 vectorize the
first BUT not the second!


const int N=1024;
float __attribute__ ((aligned(16))) a[N];
float __attribute__ ((aligned(16))) b[N];
float __attribute__ ((aligned(16))) c[N];
float __attribute__ ((aligned(16))) d[N];

void loop1() {
  for (int i=0; i!=N; ++i) {
d[i]=a[i]+b[i];
if (c[i]<0) d[i] = -d[i];
  }
}

void loop2() {
  for (int i=0; i!=N; ++i) {
float tmp = a[i]+b[i];
if (c[i]<0) tmp = -tmp;
d[i]=tmp;
  }
}

void loop3() {
  for (int i=0; i!=N; ++i) {
d[i] = (c[i]>0) ? a[i]+b[i] : -a[i]-b[i];
  }
}

void loop4() {
  for (int i=0; i!=N; ++i) {
float tmp = a[i]+b[i];
tmp = (c[i]>0) ? tmp : -tmp;
d[i] = tmp;
  }
}




c++ -Wall -O3  -ftree-vectorizer-verbose=2  -c test/testBug.cpp -o bha.o

test/testBug.cpp:9: note: vectorized 0 loops in function.

test/testBug.cpp:17: note: LOOP VECTORIZED.
test/testBug.cpp:16: note: vectorized 1 loops in function.

test/testBug.cpp:24: note: vectorized 0 loops in function.

test/testBug.cpp:31: note: not vectorized: unsupported data-type bool
test/testBug.cpp:30: note: vectorized 0 loops in function.
pb-d-128-141-131-10:Octave innocent$ c++ -Wall -O3  -ftree-vectorizer-verbose=2
 -c test/testBug.cpp -o bha.o -ftree-loop-if-convert-stores

test/testBug.cpp:10: note: LOOP VECTORIZED.
test/testBug.cpp:9: note: vectorized 1 loops in function.

test/testBug.cpp:16: note: vectorized 0 loops in function.

test/testBug.cpp:24: note: vectorized 0 loops in function.

test/testBug.cpp:30: note: vectorized 0 loops in function.
pb-d-128-141-131-10:Octave innocent$ c++ -Wall -Ofast 
-ftree-vectorizer-verbose=2  -c test/testBug.cpp -o bha.o
-ftree-loop-if-convert-stores

test/testBug.cpp:10: note: LOOP VECTORIZED.
test/testBug.cpp:9: note: vectorized 1 loops in function.

test/testBug.cpp:17: note: LOOP VECTORIZED.
test/testBug.cpp:16: note: vectorized 1 loops in function.

test/testBug.cpp:25: note: LOOP VECTORIZED.
test/testBug.cpp:24: note: vectorized 1 loops in function.

test/testBug.cpp:31: note: LOOP VECTORIZED.
test/testBug.cpp:30: note: vectorized 1 loops in function.

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  
2011-07-20 17:15:19 UTC ---
On Wed, Jul 20, 2011 at 04:18:01PM +, burnus at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791
> 
> --- Comment #3 from Tobias Burnus  2011-07-20 
> 16:16:43 UTC ---
> 
> > I'm also not sure why you call this a regression.
> 
> That's simple: It worked before, now it stopped. As the vendor extension is
> very common - it works at least with PGI, Intel, g95, gfortran (before the
> 2010-10), Sun, Open64, Pathf95 and crayftn, it makes sense to regard this as
> supported vendor extension. (I am sure more compiler support it, but I don't
> have access to them.)
> 

It's an undocumented bug^H^H^H extension.

The undocumented extension cannot be flagged by any combination of
-Wall, -Wextra, -fcheck=all, -Wsurprising and/or -std=f95,f2003,f2008.

[Bug target/36467] [avr] Missed optimization with pointer arithmetic and mul*

[gjl at gcc dot gnu.org]

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

--- Comment #6 from Georg-Johann Lay  2011-07-20 
17:23:31 UTC ---
Author: gjl
Date: Wed Jul 20 17:23:28 2011
New Revision: 176527

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176527
Log:

PR target/36467
PR target/49687
* config/avr/avr.md (mulhi3): Use register_or_s9_operand for
operand2 and expand appropriately if there is a CONST_INT in
operand2.
(usmulqihi3): New insn.
(*sumulqihi3): New insn.
(*osmulqihi3): New insn.
(*oumulqihi3): New insn.
(*muluqihi3.uconst): New insn_and_split.
(*muluqihi3.sconst): New insn_and_split.
(*mulsqihi3.sconst): New insn_and_split.
(*mulsqihi3.uconst): New insn_and_split.
(*mulsqihi3.oconst): New insn_and_split.
(*ashifthi3.signx.const): New insn_and_split.
(*ashifthi3.signx.const7): New insn_and_split.
(*ashifthi3.zerox.const): New insn_and_split.
(mulsqihi3): New insn.
(muluqihi3): New insn.
(muloqihi3): New insn.
* config/avr/predicates.md (const_2_to_7_operand): New.
(const_2_to_6_operand): New.
(u8_operand): New.
(s8_operand): New.
(o8_operand): New.
(s9_operand): New.
(register_or_s9_operand): New.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.c
trunk/gcc/config/avr/avr.md
trunk/gcc/config/avr/predicates.md

[Bug target/49687] [4.6 Regression][avr] Missed optimization for widening MUL

[gjl at gcc dot gnu.org]

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

--- Comment #4 from Georg-Johann Lay  2011-07-20 
17:23:31 UTC ---
Author: gjl
Date: Wed Jul 20 17:23:28 2011
New Revision: 176527

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176527
Log:

PR target/36467
PR target/49687
* config/avr/avr.md (mulhi3): Use register_or_s9_operand for
operand2 and expand appropriately if there is a CONST_INT in
operand2.
(usmulqihi3): New insn.
(*sumulqihi3): New insn.
(*osmulqihi3): New insn.
(*oumulqihi3): New insn.
(*muluqihi3.uconst): New insn_and_split.
(*muluqihi3.sconst): New insn_and_split.
(*mulsqihi3.sconst): New insn_and_split.
(*mulsqihi3.uconst): New insn_and_split.
(*mulsqihi3.oconst): New insn_and_split.
(*ashifthi3.signx.const): New insn_and_split.
(*ashifthi3.signx.const7): New insn_and_split.
(*ashifthi3.zerox.const): New insn_and_split.
(mulsqihi3): New insn.
(muluqihi3): New insn.
(muloqihi3): New insn.
* config/avr/predicates.md (const_2_to_7_operand): New.
(const_2_to_6_operand): New.
(u8_operand): New.
(s8_operand): New.
(o8_operand): New.
(s9_operand): New.
(register_or_s9_operand): New.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.c
trunk/gcc/config/avr/avr.md
trunk/gcc/config/avr/predicates.md

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  2011-07-20 
17:24:47 UTC ---
(In reply to comment #4)
> The undocumented extension cannot be flagged by any combination of
> -Wall, -Wextra, -fcheck=all, -Wsurprising and/or -std=f95,f2003,f2008.

Different run-time behaviors can never be diagnosed at compile time. One could
argue whether libgfortran should behave differently, depending on flags (such
as -std=* or -f*), but that's something different. (And some flags *do* change
what libgfortran accepts)

> It's an undocumented bug^H^H^H extension.

I would love to have a complete documentation of the language including the
vendor extensions - as some major vendors have. However, unless someone
actually does, one has to live with an incomplete documentation. I think most
users prefer fixed bugs and new features to a better documentation.

[Bug target/36467] [avr] Missed optimization with pointer arithmetic and mul*

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #7 from Georg-Johann Lay  2011-07-20 
17:26:03 UTC ---
Closed as FIXED: Reworked (widening) 16-bit multiply.

[Bug tree-optimization/49140] [4.6 regression] wrong code with -O2 and -O3, not with -O3 -no-inline

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #18 from Jakub Jelinek  2011-07-20 
17:26:11 UTC ---
The inline asm in that function is invalid:
   :
   : "r" (m_rounds), "r" (input), "r" (iterationCount), "r" (m_state.data()),
"r" (output), "r" (workspace.m_ptr)
   : "%eax", "%edx", "memory", "cc", "%xmm0", "%xmm1", "%xmm2", "%xmm3",
"%xmm4", "%xmm5", "%xmm6", "%xmm7", "%xmm8", "%xmm9", "%xmm10", "%xmm11",

It tells the compiler that it only uses the 6 input registers, while it
modifies 3 of them, e.g. the asm string contains:
"add %1" ", " "1*16" ";"
"sub %2" ", " "4" ";"
"add %4" ", " "1*16" ";"

GCC can assume that it will find the old content in the register after the
inline asm and will find there something completely different.
For the inputs that are clobbered, the pattern should use something like:
void *dummy1;
... asm volatile ("..." : "=r" (dummy1) : "0" (input_value));
to say that it can't be used.

[Bug ada/49783] GCC must bring ads and adb files after installation

[ludo...@ludovic-brenta.org]

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

Ludovic Brenta  changed:

   What|Removed |Added

 CC||ludo...@ludovic-brenta.org

--- Comment #1 from Ludovic Brenta  2011-07-20 
17:30:55 UTC ---
I have resolved this problem in Debian by creating two additional libraries
from the GCC sources: libgnatvsn (GNAT Version Library under GPL3 with Runtime
Library Exception) and libgnatprj (Project File parser under pure GPL).  For
full details, see:

* Debian Ada Policy
  http://people.debian.org/~lbrenta/debian-ada-policy.html
* my presentation at FOSDEM 2011
  http://www.youtube.com/watch?v=-3HvUH4fJPM
* the stack of Debian patches that implement the idea:
  ada-link-lib.diff, ada-libgnatvsn.diff, ada-libgnatprj.diff in this order.

I am willing to submit these patches upstream to GCC; however they do introduce
a potential problem: they make libgnat necessary on the host as well as on the
target.   Indeed, with these patches, all GNAT tools (gnatmake and friends) are
now linked dynamically against libgnat-$V.so and the two new libraries
libgnatvsn.so.$V and libgnatprj.so.$V (for V in 4.1 .. 4.6).

[Bug tree-optimization/49140] [4.6 regression] wrong code with -O2 and -O3, not with -O3 -no-inline

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #19 from Jakub Jelinek  2011-07-20 
17:39:11 UTC ---
And that isn't the only bug in it, the inline asm also performs calls (which
modify the bytes right below the stack), but when this function is compiled
with -O1 and above (and not without -fno-inline), the function makes no
function calls, therefore it happily uses red-zone and the embedded calls in
the inline asm clobber the red-zone.  Adding "sub rsp, 128;" and "add rsp,
128;" around the
whole inline asm content well, inside of the intel syntax, fixes the testcase
(of course, as written in the previous comment, it is still broken).

[Bug tree-optimization/49140] [4.6 regression] wrong code with -O2 and -O3, not with -O3 -no-inline

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |

--- Comment #20 from Jakub Jelinek  2011-07-20 
17:43:36 UTC ---
Ah, the crypto++ comments were just hijacking an unrelated bug for which no
details have been provided.  Please don't do this.

[Bug middle-end/33970] Missed optimization using unsigned char loop variable

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||gjl at gcc dot gnu.org
 Resolution||WORKSFORME
   Target Milestone|--- |4.7.0
  Known to fail||

--- Comment #13 from Georg-Johann Lay  2011-07-20 
17:47:44 UTC ---
Cloased as WORKS FOR ME.

Using the following test case:


volatile unsigned char bar;

void foo(void)
{
unsigned char x;
for(x=0;x<128; x++)
{
bar = x;
}
}

int sub2 (unsigned char);

void foo2 (void)
{
unsigned char x;
for(x=0;x<128; x++)
{
sub2 (x);
}
}

void foo21 (void)
{
unsigned char x;
for(x=0;x<128; x++)
{
sub2 (x+1);
}
}

And with avr-gcc 4.7 r176517 I get the following result (-Os -mmcu=atmega8).
In no case there is a 16-bit loop variable used.

foo:
ldi r24,lo8(0)
.L5:
sts bar,r24
subi r24,lo8(-(1))
cpi r24,lo8(-128)
brne .L5
ret

foo2:
push r28
ldi r28,lo8(0)
.L8:
mov r24,r28
rcall sub2
subi r28,lo8(-(1))
cpi r28,lo8(-128)
brne .L8
pop r28
ret

foo21:
push r28
ldi r28,lo8(0)
.L11:
subi r28,lo8(-(1))
mov r24,r28
rcall sub2
cpi r28,lo8(-128)
brne .L11
pop r28
ret

.ident"GCC: (GNU) 4.7.0 20110720 (experimental)"

[Bug bootstrap/49786] [4.7 Regression] bootstrap failed with bootstrap-profiled

[markus at trippelsdorf dot de]

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

--- Comment #11 from Markus Trippelsdorf  
2011-07-20 17:48:34 UTC ---
And it's indeed caused by the new IPA-CP code (Revision 176424,
commit 821d0e0f73d79232eb827c3988c34d5a1fbeb422).
Reverting the commit "solves" the issue.

[Bug tree-optimization/49749] Reassociation rank algorithm does not include all non-NULL operands

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from William J. Schmidt  
2011-07-20 19:01:30 UTC ---
I forgot to mention some justification for the value of PHI_LOOP_BIAS, and I
notice it has a misleading comment by it at the moment.  The value is a
constant that should be larger than the depth of the largest expected
reassociation tree, but generally smaller than twice the rank of the basic
block.  The intent is to limit the effect to single-block loops for now.  One
of the questions I have is whether the bias should be allowed for more complex
innermost loops.

PHI_LOOP_BIAS is a crude method and something more refined is probably needed,
but it serves to demonstrate the viability of the general approach.

[Bug target/47997] gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString"

[tobias.netzel at googlemail dot com]

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

--- Comment #15 from Tobias Netzel  
2011-07-20 20:51:12 UTC ---
Created attachment 24800
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24800
sample objective-c code that still causes the warning

Said warning does still occur when linking many Objective-C and Objective-C++
files from the mozilla codebase.
The attached sample code and playing a little with it reveals the following
behaviour of gcc:
(to be compiled as follows: "gcc main.m -framework Foundation")
- the strings "Me", "Myself", "I", "Three", "a", "b", "c", "d", "e", "f" and ""
are put into (__TEXT,__const) -> warning
- the strings "One", "Two", "You" and "foo" are put into (__TEXT,__cstring) ->
no warning
- when adding more strings to "NSMutableArray *mutable" or to the
initialization of "NSArray *arr", all strings that have a length other than
three characters are put into (__TEXT,__const) (-> warning) and all strings of
exactly three characters are put into (__TEXT,__cstring) (-> no warning)
- when there's only one string in (__TEXT,__const) there is no warning!

[Bug target/47997] gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString"

[tobias.netzel at googlemail dot com]

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

Tobias Netzel  changed:

   What|Removed |Added

 CC||tobias.netzel at googlemail
   ||dot com

--- Comment #16 from Tobias Netzel  
2011-07-20 20:53:38 UTC ---
Forgot to mention that there weren't any warnings with the 1st (unaccepted)
patch applied.

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[quantum.analyst at gmail dot com]

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

--- Comment #6 from Elliott Sales de Andrade  
2011-07-20 21:09:20 UTC ---
(In reply to comment #3)
> If the bug reporter can, I think he should convert all the input files to the
> Fortran 90 syntax of namelists. However, one needs to be careful to not
> inadvertently to change the meaning (e.g. remove the wrong "(1)") and it might
> affect many files.
> 

I can change the test suite, but since we also use the Intel and PGI compilers,
I wouldn't be able to guarantee other people won't get confused with this.

(In reply to comment #4)
> 
> It's an undocumented bug^H^H^H extension.
> 
> The undocumented extension cannot be flagged by any combination of
> -Wall, -Wextra, -fcheck=all, -Wsurprising and/or -std=f95,f2003,f2008.

Perhaps I am misreading it, but I thought it was actually documented at
http://gcc.gnu.org/onlinedocs/gfortran/Extensions-to-namelist.html

> Expanded namelist reads are permitted. This causes an error if -std=f95 is
> used. In the following example, the first element of the array will be given
> the value 0.00 and the two succeeding elements will be given the values 1.00
> and 2.00.
>
> &MYNML
>   X(1,1) = 0.00 , 1.00 , 2.00
> /
>

[Bug target/47997] gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString"

[mrs at gcc dot gnu.org]

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

m...@gcc.gnu.org  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|FIXED   |

--- Comment #17 from mrs at gcc dot gnu.org  2011-07-20 
21:15:07 UTC ---
If your not happy, we're not happy.

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  
2011-07-20 21:22:36 UTC ---
> (In reply to comment #3)
>> If the bug reporter can, I think he should convert all the input
>> files to the Fortran 90 syntax of namelists. However, one needs
>> to be careful to not inadvertently to change the meaning (e.g.
>> remove the wrong "(1)") and it might
>> affect many files.
>> 
> 
> I can change the test suite, but since we also use the Intel and
> PGI compilers, I wouldn't be able to guarantee other people won't
> get confused with this.

Confused by using standard conforming syntax?

Perhaps, people should not use features of a language 
if they do not understand those features.

[Bug tree-optimization/49140] [4.6 regression] wrong code with -O2 and -O3, not with -O3 -no-inline

[grokbrsm at free dot fr]

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

--- Comment #21 from Sébastien Kunz-Jacques  
2011-07-20 21:23:42 UTC ---
(In reply to comment #20)
> Ah, the crypto++ comments were just hijacking an unrelated bug for which no
> details have been provided.  Please don't do this.

Well, the symptoms looked similar: the error also dissapears with -fno-inline,
so that it matches the bug report header pretty well. I'll file a bug report
for Crypto++.

[Bug target/47997] gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString"

[mrs at gcc dot gnu.org]

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

--- Comment #18 from mrs at gcc dot gnu.org  2011-07-20 
21:25:37 UTC ---
Iain, I'm thinking we should do your code unconditionally for darwin10 and
later.  In darwin10.h, we put:

#define LINKER_PEDANTICALLY_WANTS_CSTRING 1

and then in the code:

   if ((LINKER_PEDANTICALLY_WANTS_CSTRING
   || darwin_constant_cfstrings || flag_merge_constants)
   && TREE_CODE (exp) == STRING_CST
   && TREE_CODE (TREE_TYPE (exp)) == ARRAY_TYPE
   && align <= 256

Another possibility, is to just _always_ do this:

   if (TREE_CODE (exp) == STRING_CST
   && TREE_CODE (TREE_TYPE (exp)) == ARRAY_TYPE
   && align <= 256

thoughts?  Jack, if you do the testsuite run, I'll check it in if it works. 
I'm a little nervous about the release branch...  :-(  Linker, shut up, would
have been my preference, but, I don't know if we have that option.

[Bug target/47997] gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString"

[tobias.netzel at googlemail dot com]

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

--- Comment #19 from Tobias Netzel  
2011-07-20 21:53:16 UTC ---
(In reply to comment #18)
> Iain, I'm thinking we should do your code unconditionally for darwin10 and
> later.  In darwin10.h, we put:

To me it seems that specifying LINKER_PEDANTICALLY_WANTS_CSTRING would only do
the same thing as passing -mconstant-cfstrings to gcc. And passing
-mconstant-cfstrings doesn't change anything in my case.
The only thing that helps in my case is the first patch.
You should also be aware that one can build and use (I do) the linker from
darwin10 in earlier versions of the OS.

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus  2011-07-20 
21:53:42 UTC ---
(In reply to comment #1)
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165979
> PR libgfortran/46010

The problem is that "dtp->u.p.ionml->touched" becomes 0 (initially it is 1)
such that one stops the expanded_read.

It seems as if the issue of this PR is solved - without causing test-suite
regressions -, if one removes that check while keeping the line for BT_DERIVED.
(I am currently testing the whole test suite; however, all namelist*.* tests
already succeeded.)

Jerry what do you think? I have to admit that I have not the slightest idea
what ionml->touched does - thus, I cannot come up of a possibly failing
namelist.

--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -2213,7 +2213,6 @@ nml_parse_qualifier (st_parameter_dt *dtp,
descriptor_dimension *ad,
  do not allow excess data to be processed.  */
  if (is_array_section == 1
  || !(compile_options.allow_std & GFC_STD_GNU)
- || !dtp->u.p.ionml->touched
  || dtp->u.p.ionml->type == BT_DERIVED)
ls[dim].end = ls[dim].start;
  else

[Bug bootstrap/49786] [4.7 Regression] bootstrap failed with bootstrap-profiled

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.07.20 22:03:04
 AssignedTo|unassigned at gcc dot   |jamborm at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #12 from Ian Lance Taylor  2011-07-20 22:03:04 
UTC ---
I was able to recreate the problem.  The count is going negative at line 1926
of ipa-cp.c, the first line setting cs->count here:

  for (cs = new_node->callees; cs ; cs = cs->next_callee)
if (cs->frequency)
  cs->count = cs->count * new_sum / orig_node_count;
else
  cs->count = 0;

In the test case, cs->count, new_sum, and orig_node_count all == 3870557758. 
Computing 3870557758 * 3870557758 overflows to a negative number.  Dividing by
3870557758 leaves the number still negative.  This then leads to the failure.

For reference, profile_info->sum_max == 2619109064700.

I don't know if these numbers are plausible.

I think that this code probably needs to be written along the lines of
scale_bbs_frequencies_gcov_type.  I will leave this for Martin.

[Bug middle-end/49798] New: .quad instead of .long is used for address for x32

[hjl.tools at gmail dot com]

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

   Summary: .quad instead of .long is used for address for x32
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


---
union U
{
  int *m;
  double d;
};

extern int ;

int
foo (union U u)
{
  union U v = { &};
  return u.d == v.d;
}
---

I got

[hjl@gnu-6 gcc]$ ./xgcc -B./ -mx32 -O2 -S x.c 
[hjl@gnu-6 gcc]$ cat x.s
.file"x.c"
.text
.p2align 4,,15
.globlfoo
.typefoo, @function
foo:
.LFB0:
.cfi_startproc
movq%rdi, -8(%rsp)
movsd.LC0(%rip), %xmm1
movsd-8(%rsp), %xmm0
movl$1, %eax
ucomisd%xmm1, %xmm0
jp.L3
jne.L3
rep
ret
.p2align 4,,10
.p2align 3
.L3:
xorl%eax, %eax
.p2align 4,,9
ret
.cfi_endproc
.LFE0:
.sizefoo, .-foo
.section.rodata.cst8,"aM",@progbits,8
.align 8
.LC0:
.quad
.ident"GCC: (GNU) 4.7.0 20110720 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 gcc]$

[Bug target/49780] [x32] internal compiler error: in create_mem_ref, at tree-ssa-address.c:806

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  2011-07-20 
23:05:54 UTC ---
Author: hjl
Date: Wed Jul 20 23:05:52 2011
New Revision: 176541

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176541
Log:
Remove checks that base and index registers are in Pmode.

2011-07-19  Uros Bizjak  

PR target/49780
* config/i386/i386.c (ix86_legitimate_address_p): Remove checks
that base and index registers are in Pmode.

Modified:
branches/x32/gcc/ChangeLog.x32
branches/x32/gcc/config/i386/i386.c

[Bug target/49780] [x32] internal compiler error: in create_mem_ref, at tree-ssa-address.c:806

[hjl at gcc dot gnu.org]

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

--- Comment #4 from hjl at gcc dot gnu.org  2011-07-20 
23:07:00 UTC ---
Author: hjl
Date: Wed Jul 20 23:06:57 2011
New Revision: 176542

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176542
Log:
Allow only subregs of DImode hard regs.

2011-07-19  Uros Bizjak  

PR target/49780
* config/i386/i386.c (ix86_decompose_address): Allow only subregs
of DImode hard regs.

* config/i386/predicates.md (no_seg_address_operand): Use
define_predicate.

Modified:
branches/x32/gcc/ChangeLog.x32
branches/x32/gcc/config/i386/i386.c
branches/x32/gcc/config/i386/predicates.md

[Bug middle-end/49798] .quad instead of .long is used for address for x32

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  2011-07-21 00:56:19 
UTC ---
It comes from constant pool:

(gdb) bt
#0  integer_asm_op (size=8, aligned_p=1) at
/export/gnu/import/git/gcc-x32/gcc/varasm.c:2421
#1  0x00df1a96 in default_assemble_integer (x=0x7074fec0, size=8,
aligned_p=1)
at /export/gnu/import/git/gcc-x32/gcc/varasm.c:2461
#2  0x00df1b79 in assemble_integer (x=0x7074fec0, size=8, align=64,
force=1)
at /export/gnu/import/git/gcc-x32/gcc/varasm.c:2482
#3  0x00df8040 in output_constant_pool_2 (mode=DImode,
x=0x7074fec0, align=64)
at /export/gnu/import/git/gcc-x32/gcc/varasm.c:3654
#4  0x00df82a8 in output_constant_pool_1 (desc=0x707ae680,
align=64)
at /export/gnu/import/git/gcc-x32/gcc/varasm.c:3736
#5  0x00df874a in output_constant_pool_contents (pool=0x7084a360)
at /export/gnu/import/git/gcc-x32/gcc/varasm.c:3856
#6  0x00df87a3 in output_shared_constant_pool ()
at /export/gnu/import/git/gcc-x32/gcc/varasm.c:3891
#7  0x00af21de in compile_file () at
/export/gnu/import/git/gcc-x32/gcc/toplev.c:579
#8  0x00af4392 in do_compile () at
/export/gnu/import/git/gcc-x32/gcc/toplev.c:1886
#9  0x00af44f8 in toplev_main (argc=15, argv=0x7fffdf48)
at /export/gnu/import/git/gcc-x32/gcc/toplev.c:1958
#10 0x005ab9ec in main (argc=15, argv=0x7fffdf48)
at /export/gnu/import/git/gcc-x32/gcc/main.c:36
(gdb) f 2
#2  0x00df1b79 in assemble_integer (x=0x7074fec0, size=8, align=64,
force=1)
at /export/gnu/import/git/gcc-x32/gcc/varasm.c:2482
2482  if (targetm.asm_out.integer (x, size, aligned_p))
(gdb) call debug_rtx (x)
(symbol_ref:DI ("") [flags 0x40] )
(gdb) 

To get Pmode value out of symbol in ptr_mode, we have to do zero-extension
ourself.

[Bug target/49798] .quad instead of .long is used for address for x32

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Component|middle-end  |target

--- Comment #2 from H.J. Lu  2011-07-21 01:07:29 
UTC ---
We need to define TARGET_ASM_INTEGER for x32.