[Bug c++/47453] Various non-conforming behaviors with braced-init-list initialization

2011-07-29 Thread d.v.a at ngs dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453

__vic d.v.a at ngs dot ru changed:

   What|Removed |Added

 CC||d.v.a at ngs dot ru

--- Comment #4 from __vic d.v.a at ngs dot ru 2011-07-29 06:08:29 UTC ---
struct A { int a[2]; A():a({1, 2}) { } };

Should be valid. Example:

class cond_variable
{
::pthread_cond_t cond;
public:
constexpr cond_variable() : cond(PTHREAD_COND_INITIALIZER) {}
};

What is pthread_cond_t? Struct? Array? Scalar? How I can be sure this code is
accepted in any case? Uniform initialization initially address this issue.

Out of constructor one can use =:

::pthread_cond_t cond = PTHREAD_COND_INITIALIZER;

In constructor init-list = is prohibited therefore () must play a same
role.


[Bug c++/49894] New: Uniform initialization in constructor (C++0x)

2011-07-29 Thread d.v.a at ngs dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49894

   Summary: Uniform initialization in constructor (C++0x)
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d@ngs.ru


#includepthread.h

class cond_variable
{
::pthread_cond_t cond;
public:
constexpr cond_variable() : cond(PTHREAD_COND_INITIALIZER) {}
};
int main() {}

test.cpp: In constructor 'constexpr cond_variable::cond_variable()':
test.cpp:7:84: error: could not convert '{{0, 0}, 0, , 0}' from
'brace-enclosed initializer list' to 'pthread_cond_t'

Variant
constexpr cond_variable() : cond((::pthread_cond_t)PTHREAD_COND_INITIALIZER) {}
is Ok.


[Bug c++/49894] Uniform initialization in constructor (C++0x)

2011-07-29 Thread d.v.a at ngs dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49894

--- Comment #1 from __vic d.v.a at ngs dot ru 2011-07-29 06:28:47 UTC ---
class mutex
{
::pthread_mutex_t mtx;
public:
constexpr mutex() : mtx(PTHREAD_MUTEX_INITIALIZER) {}
};

Compiles fine... What is the difference?


[Bug c++/49808] GCC adds an address-of somewhere!

2011-07-29 Thread jason at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49808

--- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-07-29 
07:10:25 UTC ---
Author: jason
Date: Fri Jul 29 07:10:21 2011
New Revision: 176916

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176916
Log:
PR c++/49808
* pt.c (tsubst) [TEMPLATE_PARM_INDEX]: Call convert_from_reference.
(convert_nontype_argument, tsubst_template_arg): Handle its output.

Added:
trunk/gcc/testsuite/g++.dg/template/nontype24.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)

2011-07-29 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067

--- Comment #46 from Tobias Burnus burnus at gcc dot gnu.org 2011-07-29 
07:12:47 UTC ---
(In reply to comment #45)
[Commit to inline MINLOC/MAXLOC for a rank-1 array, which returns a
single-element rank-1 array.]


On my ~5 year old Athlon64 x2, I get with -Ofast -march=native (and with or
without -fwhole-program) a performance improvement of 3% (10.72s - 10.41s).


The performance should further improve, if one fuses the loops (cf. comment 42,
but also comment 34 ff.) - and if one could move the memory allocation/freeing
of the automatic-array DTEMP out of the loop (after inlining). (Recall that
with -fstack-arrays/-Ofast, automatic arrays are allocated on the stack.)


As already mentioned indirectly in comment 0 (via PR31066): If one uses
reciprocal
approximation instructions and a Newton-Rhapson step (namely: -mrecip), the
performance improves a lot: 6.895s. By comparison, with ifort (11.1) -xHost -O3
the run time is 7.319s.


[Bug c++/49808] GCC adds an address-of somewhere!

2011-07-29 Thread jason at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49808

Jason Merrill jason at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-07-29 
07:23:26 UTC ---
Fixed for 4.7.


[Bug c++/49896] New: undefined reference to static const integral member whose address is not used, for some values of the constant

2011-07-29 Thread matthieu.imb...@ens-lyon.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49896

   Summary: undefined reference to static const integral member
whose address is not used, for some values of the
constant
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: matthieu.imb...@ens-lyon.fr


A static const int member is declared and initialized in a template class.
Its value (not its address) is used in a method of the class.
If the value of the constant has its most significant bit set (int is 32 bits),
then there is an undefined reference to the member at link.

Here is a code snippet to reproduce this:

 snippet test.cpp 

templateclass C
class test {
 protected:
  static const int version = 0x8000;
  //static const int version = 0x0fff;
 public:
  int getVersion();
};

templateclass C
int testC::getVersion() {
  return version;
}

class dummy_class {};

int main() {
  testdummy_class t;
  return t.getVersion();
}

 end of snippet 

compilation:

$ gcc -Wall -Wextra -Wstrict-aliasing test2.cpp
/tmp/cc4duaE3.o: In function `testdummy_class::getVersion()':
test2.cpp:(.text._ZN4testI11dummy_classE10getVersionEv[testdummy_class::getVersion()]+0xa):
undefined reference to `testdummy_class::version'
collect2: ld returned 1 exit status

if the constant value is 0x0fff instead of 0x8000 it compiles fine.

i get this issue on this version of gcc (the default version currently on
debian testing):

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.1-4'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-multiarch
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib/x86_64-linux-gnu
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc
--with-arch-32=i586 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.1 (Debian 4.6.1-4)

I checked with gcc 4.5.3-3 and i don't have the link error.


[Bug c/49897] New: nesting lastprivate gives incorrect result

2011-07-29 Thread markflorisson88 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49897

   Summary: nesting lastprivate gives incorrect result
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: markflorisso...@gmail.com


Nesting lastprivate doesn't work in gcc 4.5: the inner loop has a lastprivate
variable that is then also declared lastprivate on the outer loop (otherwise
there would be a race), but the result after the loop is always 0. It works
fine in gcc 4.2 to 4.4.



SSH [1] [10:13] ~  ➤ gcc-4.5 -v
Using built-in specs.
COLLECT_GCC=gcc-4.5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.5.1/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.5.1-7ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.5 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-gold
--with-plugin-ld=ld.gold --enable-objc-gc --enable-targets=all --disable-werror
--with-arch-32=i686 --with-tune=generic --enable-checking=release
--build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.5.1 (Ubuntu/Linaro 4.5.1-7ubuntu2) 
SSH [0] [10:13] ~  ➤ gcc-4.5 -g -Wall -fopenmp -lgomp testomp.c
SSH [0] [10:14] ~  ➤ ./a.out
x=9, y=0, sum = 450
SSH [0] [10:14] ~  ➤ cat testomp.c
#include stdio.h

int main(void) {
int i = 0, j = 0, x, y, sum = 0;
x = 0;


#pragma omp parallel reduction(+:sum)
{
#pragma omp for firstprivate(x) lastprivate(x, y)
for (i = 0; i  10; i++) {
x = i;

y = 0;
#pragma omp parallel reduction(+:sum)
{

#pragma omp for firstprivate(y) lastprivate(y)
for (j = 0; j  10; j++) {
y = j;
sum += y;
}
}
}
}
printf(x=%d, y=%d, sum = %d\n, x, y, sum);
return 0;
}


SSH [0] [10:15] ~  ➤ gcc-4.4 -g -Wall -fopenmp -lgomp testomp.c
SSH [0] [10:15] ~  ➤ ./a.out
x=9, y=9, sum = 450


[Bug c/49898] New: nested reduction on #pragma omp for gives incorrect result

2011-07-29 Thread markflorisson88 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49898

   Summary: nested reduction on #pragma omp for gives incorrect
result
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: markflorisso...@gmail.com


The following example fails in gcc 4.5 but works in gcc 4.4. The inner loops
has a reduction that is again a reduction in the outer loop. The result should
be 450, but is always 0. If you put the reduction() clauses on the #pragma omp
parallel it does work.

# The code

SSH [0] [10:23] ~  ➤ gcc-4.5 -g -Wall -fopenmp -lgomp testomp.c
SSH [0] [10:24] ~  ➤ ./a.out
sum = 0
SSH [0] [10:24] ~  ➤ gcc-4.4 -g -Wall -fopenmp -lgomp testomp.c 
SSH [0] [10:24] ~  ➤ ./a.out   
sum = 450
SSH [0] [10:24] ~  ➤ cat testomp.c 
#include stdio.h

int main(void) {
int i, j, sum = 0;

#pragma omp parallel
{
#pragma omp for reduction(+:sum)
for (i = 0; i  10; i++) {
#pragma omp parallel
{
#pragma omp for reduction(+:sum)
for (j = 0; j  10; j++) {
sum += j;
}
}
}
}
printf(sum = %d\n, sum);
return 0;
}


[Bug rtl-optimization/49799] gcc arm generates illegal sbfx instruction

2011-07-29 Thread carrot at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49799

--- Comment #10 from carrot at gcc dot gnu.org 2011-07-29 08:36:11 UTC ---
Author: carrot
Date: Fri Jul 29 08:35:59 2011
New Revision: 176917

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176917
Log:
PR rtl-optimization/49799

* combine.c (make_compound_operation): Check if the bit field is valid
before change it to bit field extraction.

* gcc.dg/pr49799.c: New test case.


Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr49799.c
  - copied unchanged from r176911, trunk/gcc/testsuite/gcc.dg/pr49799.c
Modified:
branches/gcc-4_6-branch/   (props changed)
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/combine.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-4_6-branch/
('svn:mergeinfo' modified)


[Bug tree-optimization/47407] gcc.dg/tree-ssa/pr42585.c FAILs on Tru64 UNIX V5.1B

2011-07-29 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47407

--- Comment #4 from Rainer Orth ro at gcc dot gnu.org 2011-07-29 09:29:14 UTC 
---
Author: ro
Date: Fri Jul 29 09:29:10 2011
New Revision: 176919

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176919
Log:
PR tree-optimization/47407
* gcc.dg/tree-ssa/pr42585.c: XFAIL scan-tree-dump-times on
alpha*-dec-osf*.
Sort target list.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr42585.c


[Bug target/49313] Inefficient libgcc implementations for avr

2011-07-29 Thread gjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49313

--- Comment #9 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-07-29 
09:33:58 UTC ---
Author: gjl
Date: Fri Jul 29 09:33:54 2011
New Revision: 176920

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176920
Log:

PR target/49313
* config/avr/libgcc.S (__ffshi2): Don't skip 2-word instruction.
(__ctzsi2): Result for 0 may be undefined.
(__ctzhi2): Result for 0 may be undefined.
(__popcounthi2): Don't clobber r30. Use __popcounthi2_tail.
(__popcountsi2): Ditto. And don't clobber r26.
(__popcountdi2): Ditto. And don't clobber r27.
* config/avr/avr.md (UNSPEC_COPYSIGN): New c_enum.
(parityhi2): New expand.
(paritysi2): New expand.
(popcounthi2): New expand.
(popcountsi2): New expand.
(clzhi2): New expand.
(clzsi2): New expand.
(ctzhi2): New expand.
(ctzsi2): New expand.
(ffshi2): New expand.
(ffssi2): New expand.
(copysignsf3): New insn.
(bswapsi2): New expand.
(*parityhi2.libgcc): New insn.
(*parityqihi2.libgcc): New insn.
(*paritysihi2.libgcc): New insn.
(*popcounthi2.libgcc): New insn.
(*popcountsi2.libgcc): New insn.
(*popcountqi2.libgcc): New insn.
(*popcountqihi2.libgcc): New insn-and-split.
(*clzhi2.libgcc): New insn.
(*clzsihi2.libgcc): New insn.
(*ctzhi2.libgcc): New insn.
(*ctzsihi2.libgcc): New insn.
(*ffshi2.libgcc): New insn.
(*ffssihi2.libgcc): New insn.
(*bswapsi2.libgcc): New insn.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.md
trunk/gcc/config/avr/libgcc.S


[Bug tree-optimization/47407] gcc.dg/tree-ssa/pr42585.c FAILs on Tru64 UNIX V5.1B

2011-07-29 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47407

Rainer Orth ro at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-07/msg02635.htm
   ||l
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |ro at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0

--- Comment #5 from Rainer Orth ro at gcc dot gnu.org 2011-07-29 09:35:15 UTC 
---
Fixed for 4.7.0.


[Bug target/49313] Inefficient libgcc implementations for avr

2011-07-29 Thread gjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49313

Georg-Johann Lay gjl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #10 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-07-29 
09:53:35 UTC ---
Fixed with the adapted patch.


[Bug middle-end/49893] [4.7 Regression] -O3 generates wrong code for volatile

2011-07-29 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49893

--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-29 
09:54:29 UTC ---
Author: rguenth
Date: Fri Jul 29 09:54:23 2011
New Revision: 176921

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176921
Log:
2011-07-29  Richard Guenther  rguent...@suse.de

PR tree-optimization/49893
* tree-predcom.c (suitable_reference_p): Volatile references
are not suitable.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-predcom.c


[Bug middle-end/49893] [4.7 Regression] -O3 generates wrong code for volatile

2011-07-29 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49893

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-29 
09:58:22 UTC ---
Fixed.


[Bug c++/49896] undefined reference to static const integral member whose address is not used, for some values of the constant

2011-07-29 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49896

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-29 
10:05:49 UTC ---
You lack a definition of testC::version.


[Bug c++/49894] Uniform initialization in constructor (C++0x)

2011-07-29 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49894

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.07.29 10:08:10
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-29 
10:08:10 UTC ---
That your libc does not provide a C++ compatible initializer for
pthread_cond_t?

Without preprocessed source we can't tell.   Please attach that.


[Bug rtl-optimization/49891] [4.7 regression] ICE in redirect_jump_1

2011-07-29 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49891

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-29 
10:10:15 UTC ---
Fixed.


[Bug c++/49894] Uniform initialization in constructor (C++0x)

2011-07-29 Thread d.v.a at ngs dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49894

--- Comment #3 from __vic d.v.a at ngs dot ru 2011-07-29 10:13:16 UTC ---
 test.cpp:7:84: error: could not convert '{{0, 0}, 0, , 0}' from
 'brace-enclosed initializer list' to 'pthread_cond_t'
 

Initializer is:

{{0, 0}, 0, , 0}


[Bug c++/49894] Uniform initialization in constructor (C++0x)

2011-07-29 Thread d.v.a at ngs dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49894

--- Comment #4 from __vic d.v.a at ngs dot ru 2011-07-29 10:17:35 UTC ---
Created attachment 24861
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24861
Preprocessor output


[Bug middle-end/49899] New: ICE when redeclaring a static function as weak

2011-07-29 Thread nickc at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49899

   Summary: ICE when redeclaring a static function as weak
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ni...@redhat.com


Created attachment 24862
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24862
Proposed patch and new testcase

If an already defined static function is redefined as being both public and
weak, the compiler generates an ICE:

% cat test.c
static long foo (void) { return 0; }
long foo (void)  __attribute__((weak));

% gcc test.c
test.c:1:12: internal compiler error: in function_and_variable_visibility,
at ipa.c:408

The uploaded patch is an attempt to fix this by adding a check into
varasm.c:merge_weak().  I was not sure however whether the redeclaration is an
error, or if it should be honoured and the function made non-static.


[Bug c++/49896] undefined reference to static const integral member whose address is not used, for some values of the constant

2011-07-29 Thread matthieu.imb...@ens-lyon.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49896

--- Comment #2 from Matthieu Imbert matthieu.imb...@ens-lyon.fr 2011-07-29 
10:37:33 UTC ---
(In reply to comment #1)
 You lack a definition of testC::version.

C++ standard section 9.4.2 states:

  If a 'static' data member is of 'const' integral or 'const' enumeral type,
  its declaration in the class definition can specify a 'constant-initializer'
  which shall be an integral constant expression (5.19).  In that case, the
  member can appear in integral constant expressions.  The member shall still
  be defined in a namespace scope if it is used in the program and the
  namespace scope definition shall not contain an 'initializer'.

The notion of used is defined in section 3.2:

  An object or non-overloaded function whose name appears as a potentially-
  evaluated expression is used unless it is an object that satisfies the
  requirements for appearing in a constant expression (5.19 [expr.const]) and
the
  lvalue-to-rvalue conversion (4.1 [conv.lval]) is immediately applied.

I am not a C++ expert but various sources (for example: stroustrup C++ faq:
http://www2.research.att.com/~bs/bs_faq2.html#in-class) seem to say that the
code snippet i sent is valid since the address of testC::version is not
taken. Stroustrup says: You can take the address of a static member if (and
only if) it has an out-of-class definition, which i interpret as: no need for
a definition if address not taken.

So in brief, i think there is no need to define testC::version to be correct.


[Bug rtl-optimization/47958] [x32] reload generates invalid address reference

2011-07-29 Thread ubizjak at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47958

Uros Bizjak ubizjak at gmail dot com changed:

   What|Removed |Added

 Target||x32
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #6 from Uros Bizjak ubizjak at gmail dot com 2011-07-29 10:39:58 
UTC ---
.


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

2011-07-29 Thread gjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49687

--- Comment #6 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-07-29 
11:27:45 UTC ---
Author: gjl
Date: Fri Jul 29 11:27:39 2011
New Revision: 176923

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176923
Log:

PR target/49687
* config/avr/avr.md (mulsi3, *mulsi3, mulumodesi3,
mulsmodesi3, mulohisi3, mulhisi3, umulhisi3, usmulhisi3,
   
*any_extend:extend_prefixany_extend2:extend_prefixmulQIHI:modeQIHI2:modesi3):
Add X to register footprint: Clobber r26/r27.


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


[Bug target/47908] attribute((optimize(2))) causes ICE in m68k_sched_issue_rate

2011-07-29 Thread mikpe at it dot uu.se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47908

--- Comment #7 from Mikael Pettersson mikpe at it dot uu.se 2011-07-29 
11:44:34 UTC ---
Created attachment 24863
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24863
fix for gcc-4.5.3 and gcc-4.4.6

A patch for trunk and gcc-4.6.1 has been posted:
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02514.html

I'm attaching the corresponding patch for gcc-4.5.3 and gcc-4.4.6 here, in case
anyone needs the fix for those branches.


[Bug rtl-optimization/49900] New: [4.7 regression] ICE in advance_target_bb, at sched-ebb.c:691

2011-07-29 Thread sch...@linux-m68k.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49900

   Summary: [4.7 regression] ICE in advance_target_bb, at
sched-ebb.c:691
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sch...@linux-m68k.org
CC: ber...@codesourcery.com
Target: ia64-*-*


/bin/sh ./libtool --tag=GCJ   --mode=compile
/usr/local/gcc/gcc-20110729/Build/./gcc/gcj
-B/usr/local/gcc/gcc-20110729/Build/ia64-suse-linux/libjava/
-B/usr/local/gcc/gcc-20110729/Build/./gcc/ -B/usr/ia64-suse-linux/bin/
-B/usr/ia64-suse-linux/lib/ -isystem /usr/ia64-suse-linux/include -isystem
/usr/ia64-suse-linux/sys-include-funwind-tables -fclasspath=
-fbootclasspath=../../../libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated
-fbootstrap-classes -g -O2  -c -o java/lang/ref.lo
-fsource-filename=/usr/local/gcc/gcc-20110729/Build/ia64-suse-linux/libjava/classpath/lib/classes
-MT java/lang/ref.lo -MD -MP -MF java/lang/ref.deps @java/lang/ref.list
libtool: compile:  /usr/local/gcc/gcc-20110729/Build/./gcc/gcj
-B/usr/local/gcc/gcc-20110729/Build/ia64-suse-linux/libjava/
-B/usr/local/gcc/gcc-20110729/Build/./gcc/ -B/usr/ia64-suse-linux/bin/
-B/usr/ia64-suse-linux/lib/ -isystem /usr/ia64-suse-linux/include -isystem
/usr/ia64-suse-linux/sys-include -funwind-tables -fclasspath=
-fbootclasspath=../../../libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated
-fbootstrap-classes -g -O2 -c
-fsource-filename=/usr/local/gcc/gcc-20110729/Build/ia64-suse-linux/libjava/classpath/lib/classes
-MT java/lang/ref.lo -MD -MP -MF java/lang/ref.deps @java/lang/ref.list  -fPIC
-o java/lang/.libs/ref.o
/usr/local/gcc/gcc-20110729/libjava/classpath/java/lang/ref/ReferenceQueue.java:
In class 'java.lang.ref.ReferenceQueue':
/usr/local/gcc/gcc-20110729/libjava/classpath/java/lang/ref/ReferenceQueue.java:
In method 'java.lang.ref.ReferenceQueue.enqueue(java.lang.ref.Reference)':
In file included from
/usr/local/gcc/gcc-20110729/libjava/java/lang/ref/Reference.java:202:0,
 from
/usr/local/gcc/gcc-20110729/libjava/classpath/java/lang/ref/PhantomReference.java:75,
 from built-in:6:
/usr/local/gcc/gcc-20110729/libjava/classpath/java/lang/ref/ReferenceQueue.java:97:0:
internal compiler error: in advance_target_bb, at sched-ebb.c:691


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

2011-07-29 Thread gjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49687

--- Comment #7 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-07-29 
11:49:30 UTC ---
With this milestone the work for better support for widening multiplication is
finished -- fir the case when MUL instruction is available.

Similar work for the case when no hardware multiplier is available needs still
to be done.

The preferred approach in that case is to do the extension explicitely in
libgcc prior to the multiplication.  Respective code was already included in
libgcc but dead because no one calls it up to now.


[Bug rtl-optimization/49900] [4.7 regression] ICE in advance_target_bb, at sched-ebb.c:691

2011-07-29 Thread bernds at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49900

Bernd Schmidt bernds at gcc dot gnu.org changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #1 from Bernd Schmidt bernds at gcc dot gnu.org 2011-07-29 
11:50:09 UTC ---
Did you test the patch that was posted?


[Bug middle-end/49806] [4.7 Regression] FAIL: gcc.dg/tree-ssa/vrp47.c

2011-07-29 Thread ktietz at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49806

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org 2011-07-29 11:50:40 
UTC ---
This is mine


[Bug rtl-optimization/49900] [4.7 regression] ICE in advance_target_bb, at sched-ebb.c:691

2011-07-29 Thread sch...@linux-m68k.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49900

--- Comment #2 from Andreas Schwab sch...@linux-m68k.org 2011-07-29 12:21:12 
UTC ---
I was waiting for an update.


[Bug c++/47453] Various non-conforming behaviors with braced-init-list initialization

2011-07-29 Thread schaub.johannes at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453

--- Comment #5 from Johannes Schaub schaub.johannes at googlemail dot com 
2011-07-29 12:23:35 UTC ---
(In reply to comment #4)
 struct A { int a[2]; A():a({1, 2}) { } };
 
 Should be valid. Example:
 
 class cond_variable
 {
 ::pthread_cond_t cond;
 public:
 constexpr cond_variable() : cond(PTHREAD_COND_INITIALIZER) {}
 };
 
 What is pthread_cond_t? Struct? Array? Scalar? How I can be sure this code is
 accepted in any case? Uniform initialization initially address this issue.
 

Why not say

constexpr cond_variable() : cond PTHREAD_COND_INITIALIZER { }


 Out of constructor one can use =:
 
 ::pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
 

You can define it as follows to make it work in both cases

#define PTHREAD_COND_INITIALIZER {}


[Bug other/49892] Error in configure test xgcc in x86_64-apple-darwin11.0.0/libgcc

2011-07-29 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49892

Jack Howarth howarth at nitro dot med.uc.edu changed:

   What|Removed |Added

 CC||howarth at nitro dot
   ||med.uc.edu

--- Comment #1 from Jack Howarth howarth at nitro dot med.uc.edu 2011-07-29 
12:43:41 UTC ---
You are trying to compile FSF gcc with Apple's llvm-gcc from Xcode 4.1. This
llvm-gcc suffers from http://llvm.org/bugs/show_bug.cgi?id=9571 whose fix from
llvm-gcc 2.9 hasn't been backported into Apple's llvm-gcc yet. Use clang or
gcc-4.2 to bootstrap instead.


[Bug rtl-optimization/49900] [4.7 regression] ICE in advance_target_bb, at sched-ebb.c:691

2011-07-29 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49900

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0


[Bug c++/49896] undefined reference to static const integral member whose address is not used, for some values of the constant

2011-07-29 Thread matthieu.imb...@ens-lyon.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49896

Matthieu Imbert matthieu.imb...@ens-lyon.fr changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |

--- Comment #3 from Matthieu Imbert matthieu.imb...@ens-lyon.fr 2011-07-29 
12:49:46 UTC ---
forgot to change bug state


[Bug fortran/49901] New: gfortran.dg/debug/[pr35154-dwarf2.f/pr37738.f] failures on darwin

2011-07-29 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49901

   Summary: gfortran.dg/debug/[pr35154-dwarf2.f/pr37738.f]
failures on darwin
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu


The new failures...

FAIL: gfortran.dg/debug/pr35154-dwarf2.f -gdwarf-2 -g3 (internal compiler
error)
FAIL: gfortran.dg/debug/pr35154-dwarf2.f -gdwarf-2 -g3 (test for excess errors)
UNRESOLVED: gfortran.dg/debug/pr35154-dwarf2.f scan-assembler
DIE[^\\n]*DW_TAG_common_block
UNRESOLVED: gfortran.dg/debug/pr35154-dwarf2.f scan-assembler (DW_AT_name:
__BLNK__|__BLNK__[^\\n]*[^\\n]*DW_AT_name)
UNRESOLVED: gfortran.dg/debug/pr35154-dwarf2.f scan-assembler
DIE[^\\n]*DW_TAG_variable
UNRESOLVED: gfortran.dg/debug/pr35154-dwarf2.f scan-assembler
i[^\\n]*[^\\n]*DW_AT_name
UNRESOLVED: gfortran.dg/debug/pr35154-dwarf2.f scan-assembler
j[^\\n]*[^\\n]*DW_AT_name
UNRESOLVED: gfortran.dg/debug/pr35154-dwarf2.f scan-assembler
DIE[^\\n]*DW_TAG_common_block
UNRESOLVED: gfortran.dg/debug/pr35154-dwarf2.f scan-assembler (DW_AT_name:
label|label[^\\n]*[^\\n]*DW_AT_name)
UNRESOLVED: gfortran.dg/debug/pr35154-dwarf2.f scan-assembler
DIE[^\\n]*DW_TAG_variable
UNRESOLVED: gfortran.dg/debug/pr35154-dwarf2.f scan-assembler
l[^\\n]*[^\\n]*DW_AT_name
UNRESOLVED: gfortran.dg/debug/pr35154-dwarf2.f scan-assembler
m[^\\n]*[^\\n]*DW_AT_name
FAIL: gfortran.dg/debug/pr37738.f -gdwarf-2 -g3 (internal compiler error)
FAIL: gfortran.dg/debug/pr37738.f -gdwarf-2 -g3 (test for excess errors)
UNRESOLVED: gfortran.dg/debug/pr37738.f scan-assembler-times
DIE[^\\n]*DW_TAG_common_block 3

appear in the regress server logs for powerpc-apple-darwin after revision
176629 but before or on revision 176671. I suspect this could be failout
from...

Author: jakub
Date: Fri Jul 22 20:06:09 2011
New Revision: 176653

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176653
Log:
* dwarf2.h (DW_AT_GNU_macros): New.
(enum dwarf_macro_record_type): New enum.  Add DW_MACRO_GNU_*.

* dwarf2out.c (struct macinfo_struct): Change code to unsigned char.
(DEBUG_MACRO_SECTION, DEBUG_MACRO_SECTION_LABEL): Define.
(dwarf_attr_name): Handle DW_AT_GNU_macros.
(dwarf2out_define): If the vector is empty and
lineno is 0, emit a dummy entry first.
(dwarf2out_undef): Likewise.  Remove redundant semicolon.
(htab_macinfo_hash, htab_macinfo_eq, output_macinfo_op,
optimize_macinfo_range): New functions.
(output_macinfo): Use them.  If !dwarf_strict and .debug_str is
mergeable, optimize longer strings using
DW_MACRO_GNU_{define,undef}_indirect and if HAVE_COMDAT_GROUP,
optimize longer sequences of define/undef ops from headers
using DW_MACRO_GNU_transparent_include.  For !dwarf_strict
emit a section headers.
(dwarf2out_init): For !dwarf_strict set debug_macinfo_section
and macinfo_section_label to DEBUG_MACRO_SECTION
resp. DEBUG_MACRO_SECTION_LABEL.
(dwarf2out_finish): For !dwarf_strict emit DW_AT_GNU_macros
instead of DW_AT_macro_info.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/include/ChangeLog
trunk/include/dwarf2.h

The failure is also observed on x86_64-apple-darwin11.


[Bug debug/49887] [4.7 regression] .debug_macro breaks many Solaris/SPARC tests

2011-07-29 Thread ro at CeBiTec dot Uni-Bielefeld.DE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49887

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot 
Uni-Bielefeld.DE 2011-07-29 12:58:25 UTC ---
 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot 
 Uni-Bielefeld.DE 2011-07-28 14:52:35 UTC ---
 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-28 
 14:45:11 UTC ---
 So, how are the group signature symbols supposed to be emitted on
 SPARC/Solaris?  A dummy symbol of that name somewhere in the section?  Can it
 be local, or must it be global symbol?

 This is usually handled in gcc/config/sol2.c
 (solaris_elf_asm_comdat_section, solaris_define_comdat_signature,
 solaris_code_end).  I haven't yet checked why this doesn't trigger here.

I see now what's going on: output_macinfo is run from toplev.c (compile_file):

(*debug_hooks-finish) (main_input_filename);

which runs *after*

targetm.asm_out.code_end ();

I've no idea what's a good way to resolve this.

Rainer


[Bug fortran/49901] gfortran.dg/debug/[pr35154-dwarf2.f/pr37738.f] failures on darwin

2011-07-29 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49901

--- Comment #1 from Jack Howarth howarth at nitro dot med.uc.edu 2011-07-29 
13:05:08 UTC ---
The first failure, which is an ICE,...

FAIL: gfortran.dg/debug/pr35154-dwarf2.f -gdwarf-2 -g3 (internal compiler
error)

appears as...

[MacPro:gcc/testsuite/gfortran] root#
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/testsuite/gfortran/../../gfortran
-B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/testsuite/gfortran/../../
-B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.0.0/i386/libgfortran/
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20110728/gcc/testsuite/gfortran.dg/debug/pr35154-dwarf2.f
-gdwarf-2 -g3 -dA -gno-strict-dwarf -S -m32 -o pr35154-dwarf2.s -v
Reading specs from
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/testsuite/gfortran/../../specs
COLLECT_GCC=/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/testsuite/gfortran/../../gfortran
COLLECT_LTO_WRAPPER=/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/testsuite/gfortran/../../lto-wrapper
Target: x86_64-apple-darwin11.0.0
Configured with: ../gcc-4.7-20110728/configure --prefix=/sw
--prefix=/sw/lib/gcc4.7 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.7/info
--with-build-config=bootstrap-lto --enable-stage1-languages=c,lto
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-4.7 --enable-checking=yes --enable-cloog-backend=isl
--enable-build-with-cxx
Thread model: posix
gcc version 4.7.0 20110728 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.7.0' '-B'
'/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/testsuite/gfortran/../../'
'-B'
'/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.0.0/i386/libgfortran/'
'-gdwarf-2' '-g3' '-dA' '-gno-strict-dwarf' '-S' '-m32' '-o' 'pr35154-dwarf2.s'
'-v' '-mtune=core2'

/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/testsuite/gfortran/../../f951
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20110728/gcc/testsuite/gfortran.dg/debug/pr35154-dwarf2.f
-ffixed-form -fPIC -quiet -dumpbase pr35154-dwarf2.f -dA
-mmacosx-version-min=10.7.0 -m32 -mtune=core2 -auxbase-strip pr35154-dwarf2.s
-gdwarf-2 -g3 -gno-strict-dwarf -version -o pr35154-dwarf2.s
-fintrinsic-modules-path finclude
GNU Fortran (GCC) version 4.7.0 20110728 (experimental)
(x86_64-apple-darwin11.0.0)
compiled by GNU C version 4.7.0 20110728 (experimental), GMP version 5.0.2,
MPFR version 3.0.1, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) version 4.7.0 20110728 (experimental)
(x86_64-apple-darwin11.0.0)
compiled by GNU C version 4.7.0 20110728 (experimental), GMP version 5.0.2,
MPFR version 3.0.1, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20110728/gcc/testsuite/gfortran.dg/debug/pr35154-dwarf2.f:14:0:
internal compiler error: in darwin_asm_output_dwarf_offset, at
config/darwin.c:2739
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.


[Bug debug/49887] [4.7 regression] .debug_macro breaks many Solaris/SPARC tests

2011-07-29 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49887

--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-29 
13:06:13 UTC ---
Emit that in targetm.asm_out.file_end () instead?


[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

2011-07-29 Thread daniel.marjamaki at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

Daniel Marjamäki daniel.marjamaki at gmail dot com changed:

   What|Removed |Added

 CC||daniel.marjamaki at gmail
   ||dot com

--- Comment #7 from Daniel Marjamäki daniel.marjamaki at gmail dot com 
2011-07-29 13:28:41 UTC ---
In my experience this type of check is really noisy if there is a warning for
every fall through.

I recommend that the warning is written only if the fall through cause
redundant or bad behaviour. such as:

switch (foo) {
case 1: x = y;   // - redundant assignment
case 2: x = z;
};

Or:

switch (foo) {
case 1: p = NULL;
case 2: *p = 2;// fall through = NULL pointer dereference
};


[Bug c++/49902] New: [C++0x] ICE in gimple_expand_cfg when initializer_list constructed using constructor parameters.

2011-07-29 Thread fuchsia.groan at virgin dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49902

   Summary: [C++0x] ICE in gimple_expand_cfg when initializer_list
constructed using constructor parameters.
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fuchsia.gr...@virgin.net


/*
compiling this with

   g++ --std=c++0x -c initializer_list.cpp

produces

   initializer_list.cpp: In constructor 'T::T(bool)':
   initializer_list.cpp:20:1: internal compiler error: in gimple_expand_cfg, at
cfgexpand.c:4058

on the equation gcc 4.6 port
[http://www.equation.com/servlet/equation.cmd?fa=fortran]
*/
#include initializer_list

struct T
{
T( bool );
};

T::T( bool b )
{
std::initializer_listint a
{
b ? 4 : 5
};
}


x86_64: undefined reference to `typeinfo for __int128'

2011-07-29 Thread Ryszard Kabatek

Hello,
a compilation of the code below succeeds, but the linking fails with the 
message:

undefined reference to `typeinfo for __int128'

Tested with (I got the same error with older versions of GCC):
gcc version 4.4.5 (Debian 4.4.5-8)

Regards,
RK

// x.cxx
#include iostream
#include typeinfo

using namespace std;

int main()
{
  cout  typeid(__int128_t).name()  endl;

  return 0;
}


[Bug target/47715] [x32] TLS doesn't work

2011-07-29 Thread uros at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47715

--- Comment #16 from uros at gcc dot gnu.org 2011-07-29 13:48:45 UTC ---
Author: uros
Date: Fri Jul 29 13:48:40 2011
New Revision: 176924

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176924
Log:
PR target/47715
* config/i386/i386.md (*load_tp_x32): New.
(*load_tp_x32_zext): Ditto.
(*add_tp_x32): Ditto.
(*add_tp_x32_zext): Ditto.
(*load_tp_mode): Disable for TARGET_X32 targets.
(*add_tp_mode): Ditto.
* config/i386/i386.c (get_thread_pointer): Load thread pointer in
ptr_mode and convert to Pmode if needed.


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


[Bug target/47715] [x32] TLS doesn't work

2011-07-29 Thread ubizjak at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47715

Uros Bizjak ubizjak at gmail dot com changed:

   What|Removed |Added

 Target||x32
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #17 from Uros Bizjak ubizjak at gmail dot com 2011-07-29 13:52:37 
UTC ---
Fixed.


[Bug c++/49902] [C++0x] ICE in gimple_expand_cfg when initializer_list constructed using constructor parameters.

2011-07-29 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49902

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.6.1, 4.7.0
 Resolution||WORKSFORME
  Known to fail||4.6.0

--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-07-29 
13:59:50 UTC ---
Works with current mainline and 4_6-branch.


[Bug target/49881] [AVR] Inefficient stack manipulation around calls

2011-07-29 Thread gjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49881

--- Comment #7 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-07-29 
14:39:31 UTC ---
(In reply to comment #4)

 Would one of you be so kind as to do a full test run?
 I don't have avr-libc et al set up on this machine...

Just running tests without regenerating libs:

gcc.c-torture/compile/20030903-1.c:23:1: error: unrecognizable insn:

(insn 43 42 44 3 (set (mem:HI (post_dec:HI (reg/f:HI 32 __SP_L__)) [0 S2 A8])

(reg:HI 68))
/mnt/nfs/home/georg/gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/20030903-1.c:15
-1

 (nil))


FAIL: gcc.c-torture/compile/20030903-1.c  -O0
FAIL: gcc.c-torture/compile/20030903-1.c  -O1
FAIL: gcc.c-torture/compile/20030903-1.c  -O2
FAIL: gcc.c-torture/compile/20030903-1.c  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/compile/20030903-1.c  -O3 -g
FAIL: gcc.c-torture/compile/20030903-1.c  -Os

gcc.c-torture/execute/complex-7.c:56:1: error: unrecognizable insn:

(insn 15 14 16 3 (set (mem:SF (post_dec:HI (reg/f:HI 32 __SP_L__)) [0 S4 A8])

(reg:SF 43 [ f5.0+4 ]))

FAIL: gcc.c-torture/execute/complex-7.c compilation,  -O0
FAIL: gcc.c-torture/execute/complex-7.c compilation,  -O1
FAIL: gcc.c-torture/execute/complex-7.c compilation,  -O2
FAIL: gcc.c-torture/execute/complex-7.c compilation,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/complex-7.c compilation,  -O3 -g
FAIL: gcc.c-torture/execute/complex-7.c compilation,  -Os

There are many other FAILs that go into the same direction.

-

The good news is that the following known FAILs, aka. PR49629, pass with your
patch:

gcc.c-torture/compile/pr34448.c: In function 'build_attr_cert':

gcc.c-torture/compile/pr34448.c:31:1: internal compiler error: in
df_refs_verify, at df-scan.c:4268

Please submit a full bug report,

with preprocessed source if appropriate.

See http://gcc.gnu.org/bugs.html for instructions.


FAIL: gcc.c-torture/compile/pr34448.c  -O2  (internal compiler error)
FAIL: gcc.c-torture/compile/pr34448.c  -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr34448.c  -O3 -fomit-frame-pointer  (internal
compiler error)
FAIL: gcc.c-torture/compile/pr34448.c  -O3 -fomit-frame-pointer  (test for
excess errors)
FAIL: gcc.c-torture/compile/pr34448.c  -O3 -g  (internal compiler error)
FAIL: gcc.c-torture/compile/pr34448.c  -O3 -g  (test for excess errors)

FAIL: gcc.c-torture/compile/pr39928-1.c  -O2  (internal compiler error)
FAIL: gcc.c-torture/compile/pr39928-1.c  -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr39928-1.c  -O3 -fomit-frame-pointer  (internal
compiler error)
FAIL: gcc.c-torture/compile/pr39928-1.c  -O3 -fomit-frame-pointer  (test for
excess errors)
FAIL: gcc.c-torture/compile/pr39928-1.c  -O3 -g  (internal compiler error)
FAIL: gcc.c-torture/compile/pr39928-1.c  -O3 -g  (test for excess errors)
P


[Bug middle-end/49629] [4.7 Regression] ICE: in df_refs_verify, at df-scan.c

2011-07-29 Thread gjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49629

Georg-Johann Lay gjl at gcc dot gnu.org changed:

   What|Removed |Added

 Target|avr |avr, powerpc

--- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-07-29 
14:46:07 UTC ---
(In reply to comment #3)
 I'm seeing the same error on PowerPC trying to build cpu2006 benchmark
 435.gromacs. Testcase attatched in prior comment.
 
 temp/delta /home/pthaugen/install/gcc/trunk/bin/gcc -c -m64 -O2 -mcpu=power7
 pdbio.c
 pdbio.c: In function ‘write_pdbfile_indexed’:
 pdbio.c:64:1: internal compiler error: in df_refs_verify, at df-scan.c:4268
 Please submit a full bug report,

Would you please add the output of the compiler together with -v so that we can
see how the compiler was configured? Thanks.

http://gcc.gnu.org/bugs/#need


[Bug target/49903] New: AVR: Redundant comparisons in binary-seach switch/case expansion

2011-07-29 Thread gjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49903

   Summary: AVR: Redundant comparisons in binary-seach switch/case
expansion
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
CC: eric.wedding...@atmel.com
Target: avr


Created attachment 24864
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24864
cswitch.c: C test case

avr-gcc emits redundant comparisons like these:

cpi r24,lo8(55) ;  22*cmpqi/3[length = 1]
breq .L10 ;  23branch[length = 1]
cpi r24,lo8(56) ;  24*cmpqi/3[length = 1]
brge .L19 ;  25branch[length = 1]

which could just as well be

cpi r24,lo8(55) ;  22*cmpqi/3[length = 1]
breq .L10 ;  23branch[length = 1]
brge .L19 ;  25branch[length = 1]

or these:

cpi r24,lo8(100) ;  61*cmpqi/3[length = 1]
breq .L16 ;  62branch[length = 1]
cpi r24,lo8(100) ;  63*cmpqi/3[length = 1]
brlt .L15 ;  64branch[length = 1]

which could just as well be

cpi r24,lo8(100) ;  61*cmpqi/3[length = 1]
breq .L16 ;  62branch[length = 1]
brlt .L15 ;  64branch[length = 1]

This concernes signed/unsigned comparisons for QI/HI/SI

-- command line --

avr-gcc cswitch.c -dp -S -Os

-- configure -

../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/home/john/gnu/install/gcc-4.7 --disable-nls --disable-shared
--enable-languages=c,c++ --with-dwarf2 --disable-lto

-- GCC  -

as of 4.7.0 trunk, r176818 from 2011-07-27


[Bug target/49903] [avr] Redundant comparisons in binary-search switch/case expansion

2011-07-29 Thread eric.weddington at atmel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49903

Eric Weddington eric.weddington at atmel dot com changed:

   What|Removed |Added

Summary|AVR: Redundant comparisons  |[avr] Redundant comparisons
   |in binary-seach switch/case |in binary-search
   |expansion   |switch/case expansion
   Severity|normal  |enhancement

--- Comment #1 from Eric Weddington eric.weddington at atmel dot com 
2011-07-29 15:07:52 UTC ---
Johann,
Would some type of peephole optimization help out on this?


[Bug middle-end/49897] nesting lastprivate gives incorrect result

2011-07-29 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49897

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
  Known to work||4.4.6
   Keywords||openmp, wrong-code
   Last reconfirmed||2011.07.29 15:38:18
  Component|c   |middle-end
 CC||jakub at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1
   Target Milestone|--- |4.5.4
  Known to fail||4.5.3

--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-29 
15:38:18 UTC ---
Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=145338
I have a fix.


[Bug middle-end/49898] [4.5/4.6/4.7 Regression] nested reduction on #pragma omp for gives incorrect result

2011-07-29 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49898

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.4.6
   Keywords||openmp
  Component|c   |middle-end
 CC||jakub at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Resolution||DUPLICATE
Summary|nested reduction on #pragma |[4.5/4.6/4.7 Regression]
   |omp for gives incorrect |nested reduction on #pragma
   |result  |omp for gives incorrect
   ||result
   Target Milestone|--- |4.5.4
  Known to fail||4.5.3

--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-29 
15:40:20 UTC ---
Dup of PR49897, fixed by the same patch.

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


[Bug middle-end/49897] [4.5/4.6/4.7 Regression] nesting lastprivate gives incorrect result

2011-07-29 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49897

--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-29 
15:40:20 UTC ---
*** Bug 49898 has been marked as a duplicate of this bug. ***


[Bug middle-end/49897] [4.5/4.6/4.7 Regression] nesting lastprivate gives incorrect result

2011-07-29 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49897

--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-29 
15:41:36 UTC ---
Created attachment 24865
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24865
gcc47-pr49897.patch

Fix.


[Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode

2011-07-29 Thread hjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49860

--- Comment #10 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-07-29 
15:56:38 UTC ---
Author: hjl
Date: Fri Jul 29 15:56:36 2011
New Revision: 176928

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176928
Log:
Rename gcc.target/i386/pr47446-3.c to gcc.target/i386/pr49860-1.c.

2011-07-26  H.J. Lu  hongjiu...@intel.com

PR target/49860
* gcc.target/i386/pr47446-3.c: Renamed to ...
* gcc.target/i386/pr49860-1.c: This.

Added:
branches/x32/gcc/testsuite/gcc.target/i386/pr49860-1.c
  - copied unchanged from r176926,
branches/x32/gcc/testsuite/gcc.target/i386/pr47446-3.c
Removed:
branches/x32/gcc/testsuite/gcc.target/i386/pr47446-3.c
Modified:
branches/x32/gcc/testsuite/ChangeLog.x32


[Bug target/49832] [x32] too many memory references for `lea'

2011-07-29 Thread hjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49832

--- Comment #4 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-07-29 
16:00:48 UTC ---
Author: hjl
Date: Fri Jul 29 16:00:41 2011
New Revision: 176932

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176932
Log:
Rewrite x86 lea support for x32.

2011-07-26  Uros Bizjak  ubiz...@gmail.com
   H.J. Lu  hongjiu...@intel.com

PR target/47381
PR target/49832
PR target/49833
* config/i386/i386.md (i): Change SImode attribute to e.
(g): Change SImode attribute to rme.
(di): Change SImode attribute to nF.
(general_operand): Change SImode attribute to x86_64_general_operand.
(general_szext_operand): Change SImode attribute to
x86_64_szext_general_operand.
(immediate_operand): Change SImode attribute to
x86_64_immediate_operand.
(nonmemory_operand): Change SImode attribute to
x86_64_nonmemory_operand.
(*movdi_internal_rex64): Remove mode from pic_32bit_operand check.
(*movsi_internal): Ditto.  Use e constraint in alternative 2.
(*lea_1): Use SWI48 mode iterator.
(*lea_1_zext): New insn pattern.
(testsi_ccno_1): Use x86_64_nonmemory_operand predicate for operand 2.
(*btmode): Ditto.
(*addmode1): Use x86_64_general_operand predicate for operand 2.
Update operand constraints.
(addsi_1_zext): Ditto.
(*addmode2): Ditto.
(*addsi_3_zext): Ditto.
(*subsi_1_zext): Ditto.
(*subsi_2_zext): Ditto.
(*subsi_3_zext): Ditto.
(*addsi3_carry_zext): Ditto.
(*plusminus_insnsi3_zext_cc_overflow): Ditto.
(*mulsi3_1_zext): Ditto.
(*andsi_1): Ditto.
(*andsi_1_zext): Ditto.
(*andsi_2_zext): Ditto.
(*any_or:codesi_1_zext): Ditto.
(*any_or:codesi_2_zext): Ditto.
(*testmode_1): Use general_operand predicate for operand 1.
(*andmode_2): Ditto.
(movmodecc): Use  general_operand predicate for operands 1 and 2.
(add-lea splitter): Check operand modes in insn constraint.  Extend
operands less than SImode wide to SImode.
(add-lea zext splitter): Do not extend input operands to DImode.
(*lea_general_1): Handle only QImode and HImode operands.
(*lea_general_2): Ditto.
(*lea_general_3): Ditto.
(*lea_general_1_zext): Remove.
(*lea_general_2_zext): Ditto.
(*lea_general_3_zext): Ditto.
(*lea_general_4): Check operand modes in insn constraint.  Extend
operands less than SImode wide to SImode.
(ashift-lea splitter): Ditto.
* config/i386/i386.c (ix86_print_operand_address): Print address
registers with 'q' modifier on 64bit targets.
* config/i386/predicates.md (pic_32bit_opreand): Define as special
predicate.  Reject non-SI and non-DI modes.

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


[Bug target/49833] [x32] PIC doesn't work

2011-07-29 Thread hjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49833

--- Comment #22 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-07-29 
16:00:48 UTC ---
Author: hjl
Date: Fri Jul 29 16:00:41 2011
New Revision: 176932

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176932
Log:
Rewrite x86 lea support for x32.

2011-07-26  Uros Bizjak  ubiz...@gmail.com
   H.J. Lu  hongjiu...@intel.com

PR target/47381
PR target/49832
PR target/49833
* config/i386/i386.md (i): Change SImode attribute to e.
(g): Change SImode attribute to rme.
(di): Change SImode attribute to nF.
(general_operand): Change SImode attribute to x86_64_general_operand.
(general_szext_operand): Change SImode attribute to
x86_64_szext_general_operand.
(immediate_operand): Change SImode attribute to
x86_64_immediate_operand.
(nonmemory_operand): Change SImode attribute to
x86_64_nonmemory_operand.
(*movdi_internal_rex64): Remove mode from pic_32bit_operand check.
(*movsi_internal): Ditto.  Use e constraint in alternative 2.
(*lea_1): Use SWI48 mode iterator.
(*lea_1_zext): New insn pattern.
(testsi_ccno_1): Use x86_64_nonmemory_operand predicate for operand 2.
(*btmode): Ditto.
(*addmode1): Use x86_64_general_operand predicate for operand 2.
Update operand constraints.
(addsi_1_zext): Ditto.
(*addmode2): Ditto.
(*addsi_3_zext): Ditto.
(*subsi_1_zext): Ditto.
(*subsi_2_zext): Ditto.
(*subsi_3_zext): Ditto.
(*addsi3_carry_zext): Ditto.
(*plusminus_insnsi3_zext_cc_overflow): Ditto.
(*mulsi3_1_zext): Ditto.
(*andsi_1): Ditto.
(*andsi_1_zext): Ditto.
(*andsi_2_zext): Ditto.
(*any_or:codesi_1_zext): Ditto.
(*any_or:codesi_2_zext): Ditto.
(*testmode_1): Use general_operand predicate for operand 1.
(*andmode_2): Ditto.
(movmodecc): Use  general_operand predicate for operands 1 and 2.
(add-lea splitter): Check operand modes in insn constraint.  Extend
operands less than SImode wide to SImode.
(add-lea zext splitter): Do not extend input operands to DImode.
(*lea_general_1): Handle only QImode and HImode operands.
(*lea_general_2): Ditto.
(*lea_general_3): Ditto.
(*lea_general_1_zext): Remove.
(*lea_general_2_zext): Ditto.
(*lea_general_3_zext): Ditto.
(*lea_general_4): Check operand modes in insn constraint.  Extend
operands less than SImode wide to SImode.
(ashift-lea splitter): Ditto.
* config/i386/i386.c (ix86_print_operand_address): Print address
registers with 'q' modifier on 64bit targets.
* config/i386/predicates.md (pic_32bit_opreand): Define as special
predicate.  Reject non-SI and non-DI modes.

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


[Bug target/47381] [x32] internal compiler error: in gen_lowpart_general, at rtlhooks.c:59

2011-07-29 Thread hjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47381

--- Comment #6 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-07-29 
16:00:45 UTC ---
Author: hjl
Date: Fri Jul 29 16:00:41 2011
New Revision: 176932

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176932
Log:
Rewrite x86 lea support for x32.

2011-07-26  Uros Bizjak  ubiz...@gmail.com
   H.J. Lu  hongjiu...@intel.com

PR target/47381
PR target/49832
PR target/49833
* config/i386/i386.md (i): Change SImode attribute to e.
(g): Change SImode attribute to rme.
(di): Change SImode attribute to nF.
(general_operand): Change SImode attribute to x86_64_general_operand.
(general_szext_operand): Change SImode attribute to
x86_64_szext_general_operand.
(immediate_operand): Change SImode attribute to
x86_64_immediate_operand.
(nonmemory_operand): Change SImode attribute to
x86_64_nonmemory_operand.
(*movdi_internal_rex64): Remove mode from pic_32bit_operand check.
(*movsi_internal): Ditto.  Use e constraint in alternative 2.
(*lea_1): Use SWI48 mode iterator.
(*lea_1_zext): New insn pattern.
(testsi_ccno_1): Use x86_64_nonmemory_operand predicate for operand 2.
(*btmode): Ditto.
(*addmode1): Use x86_64_general_operand predicate for operand 2.
Update operand constraints.
(addsi_1_zext): Ditto.
(*addmode2): Ditto.
(*addsi_3_zext): Ditto.
(*subsi_1_zext): Ditto.
(*subsi_2_zext): Ditto.
(*subsi_3_zext): Ditto.
(*addsi3_carry_zext): Ditto.
(*plusminus_insnsi3_zext_cc_overflow): Ditto.
(*mulsi3_1_zext): Ditto.
(*andsi_1): Ditto.
(*andsi_1_zext): Ditto.
(*andsi_2_zext): Ditto.
(*any_or:codesi_1_zext): Ditto.
(*any_or:codesi_2_zext): Ditto.
(*testmode_1): Use general_operand predicate for operand 1.
(*andmode_2): Ditto.
(movmodecc): Use  general_operand predicate for operands 1 and 2.
(add-lea splitter): Check operand modes in insn constraint.  Extend
operands less than SImode wide to SImode.
(add-lea zext splitter): Do not extend input operands to DImode.
(*lea_general_1): Handle only QImode and HImode operands.
(*lea_general_2): Ditto.
(*lea_general_3): Ditto.
(*lea_general_1_zext): Remove.
(*lea_general_2_zext): Ditto.
(*lea_general_3_zext): Ditto.
(*lea_general_4): Check operand modes in insn constraint.  Extend
operands less than SImode wide to SImode.
(ashift-lea splitter): Ditto.
* config/i386/i386.c (ix86_print_operand_address): Print address
registers with 'q' modifier on 64bit targets.
* config/i386/predicates.md (pic_32bit_opreand): Define as special
predicate.  Reject non-SI and non-DI modes.

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


[Bug middle-end/49897] [4.5/4.6/4.7 Regression] nesting lastprivate gives incorrect result

2011-07-29 Thread markflorisson88 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49897

--- Comment #4 from markflorisson88 markflorisson88 at gmail dot com 
2011-07-29 16:05:50 UTC ---
(In reply to comment #3)
 Created attachment 24865 [details]
 gcc47-pr49897.patch
 
 Fix.

Wow, thanks a lot for the quick fix!


[Bug debug/49901] gfortran.dg/debug/[pr35154-dwarf2.f/pr37738.f] failures on darwin

2011-07-29 Thread kargl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49901

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
  Component|fortran |debug

--- Comment #2 from kargl at gcc dot gnu.org 2011-07-29 16:07:27 UTC ---
Not a Fortran problem.  Change the component to 'debug'.


[Bug debug/49887] [4.7 regression] .debug_macro breaks many Solaris/SPARC tests

2011-07-29 Thread ro at CeBiTec dot Uni-Bielefeld.DE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49887

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot 
Uni-Bielefeld.DE 2011-07-29 16:10:04 UTC ---
 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-29 
 13:06:13 UTC ---
 Emit that in targetm.asm_out.file_end () instead?

Seems to work according to a quick test running gcc.dg/debug/debug.exp.
I'll run it through a full bootstrap cycle on both sparc and x86, as and
gas over the weekend.

I think I had some reason not to use TARGET_ASM_FILE_END for the
COMDAT-with-as patch, but cannot remember what it was.

Thanks.
Rainer


[Bug target/49903] [avr] Redundant comparisons in binary-search switch/case expansion

2011-07-29 Thread gjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49903

--- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-07-29 
16:11:12 UTC ---
(In reply to comment #1)
 Johann,
 Would some type of peephole optimization help out on this?

RTL peephole won't work because they operate just inside basic blocks.

Don't know the retionale behind that limitation, appears that it's just for
technical and implementational reasons.  RTL peep need not to be confused by
BBs, just code_labels etc. would bother.

Text peepholes match but it might be tedious and error prone to work out
instructions lengths or the correct instructions if jump offsets don't match.

Maybe a way is in avr_reorg, but it would be quite tedious to work out all
QI/HI/SI signed and unsigned combinations.  And it must ensure that no other
transformation takes place.  There's bunch of special treatment in md and c and
cc0 handling.  E.g. I don't quite understand why jumps clobber cc0; btw not
clobbering cc0 will not fix this PR.


[Bug target/47372] [x32] internal compiler error: in simplify_subreg, at simplify-rtx.c:5222

2011-07-29 Thread hjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47372

--- Comment #8 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-07-29 
16:43:28 UTC ---
Author: hjl
Date: Fri Jul 29 16:43:25 2011
New Revision: 176937

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176937
Log:
Call simplify_gen_subreg with mode of x.

2011-07-26  H.J. Lu  hongjiu...@intel.com

PR target/47372
* config/i386/i386.c (ix86_delegitimize_address): Call
simplify_gen_subreg for PIC with mode of x only if modes of
x and orig_x are different.

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


[Bug target/47715] [x32] TLS doesn't work

2011-07-29 Thread hjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47715

--- Comment #18 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-07-29 
16:44:11 UTC ---
Author: hjl
Date: Fri Jul 29 16:44:07 2011
New Revision: 176938

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176938
Log:
Remove PTR64.

2011-07-28  H.J. Lu  hongjiu...@intel.com

PR target/47715
* config/i386/i386.md (PTR64): Removed.
(*tls_global_dynamic_64_mode): Rename to ...
(*tls_global_dynamic_64): This.  Remove PTR64 on operand 1.
(tls_global_dynamic_64_mode): Rename to ...
(tls_global_dynamic_64): This.  Remove PTR64 on operand 1.
* config/i386/i386.c (legitimize_tls_address): Updated.

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


[Bug target/47715] [x32] TLS doesn't work

2011-07-29 Thread hjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47715

--- Comment #19 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-07-29 
16:56:03 UTC ---
Author: hjl
Date: Fri Jul 29 16:55:59 2011
New Revision: 176940

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176940
Log:
Revert Use ptr_mode instead of Pmode with UNSPEC_TP.

2011-07-28  H.J. Lu  hongjiu...@intel.com

Revert
PR target/47715
* config/i386/i386.c (get_thread_pointer): Use ptr_mode
instead of Pmode with UNSPEC_TP.

* config/i386/i386.md (tp_seg): Removed.
(*load_tp_mode): Replace :P with :PTR.
(*add_tp_mode): Likewise.
(*load_tp_x32): New.

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


[Bug fortran/49885] [4.6/4.7 Regression] Segmentation fault when writing to an automatic character array

2011-07-29 Thread domob at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49885

--- Comment #6 from Daniel Kraft domob at gcc dot gnu.org 2011-07-29 17:00:12 
UTC ---
For the record, with the original test case and -fdump-tree-original, I get:

s (integer(kind=4)  restrict nb)
{
  character(kind=1) bad_rec[1][1:.bad_rec];
  integer(kind=4) .bad_rec;
  bitsizetype D.1567;
  sizetype D.1568;
  bitsizetype D.1569;
  sizetype D.1570;

  {
integer(kind=4) D.1566;
integer(kind=4) M.2;

M.2 = 80;
D.1566 = *nb;
if (D.1566  M.2)
  {
M.2 = D.1566;
  }
.bad_rec = MAX_EXPR M.2, 0;
D.1567 = (bitsizetype) (sizetype) NON_LVALUE_EXPR .bad_rec * 8;
D.1568 = (sizetype) NON_LVALUE_EXPR .bad_rec;
D.1569 = NON_LVALUE_EXPR SAVE_EXPR D.1567 + 7  -8;
D.1570 = NON_LVALUE_EXPR SAVE_EXPR D.1568;
character(kind=1) bad_rec[1][1:.bad_rec];
  }
...some code that does the write...

.bad_rec has the correct value (80) later on in the print-statement.  However,
the code above (last line before }) looks to me as if bad_rec was created just
inside the shown block -- and is later no more available on the stack or
something, thus crashing the program.

So it seems that evaluating the max(...) creates the block shown above, and the
allocation of the automatic array is accidentally placed inside that block. 
This seems like a plausible cause for this bug.

Now I'll try to find out how to fix it.


[Bug middle-end/49898] [4.5/4.6/4.7 Regression] nested reduction on #pragma omp for gives incorrect result

2011-07-29 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49898

--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-29 
17:45:46 UTC ---
Author: jakub
Date: Fri Jul 29 17:45:42 2011
New Revision: 176945

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176945
Log:
PR middle-end/49897
PR middle-end/49898
* omp-low.c (use_pointer_for_field): If disallowing copy-in/out
in nested parallel and outer is a gimple_reg, mark it as addressable
and set its bit in task_shared_vars bitmap too.

* testsuite/libgomp.c/pr49897-1.c: New test.
* testsuite/libgomp.c/pr49897-2.c: New test.
* testsuite/libgomp.c/pr49898-1.c: New test.
* testsuite/libgomp.c/pr49898-2.c: New test.

Added:
trunk/libgomp/testsuite/libgomp.c/pr49897-1.c
trunk/libgomp/testsuite/libgomp.c/pr49897-2.c
trunk/libgomp/testsuite/libgomp.c/pr49898-1.c
trunk/libgomp/testsuite/libgomp.c/pr49898-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c
trunk/libgomp/ChangeLog


[Bug middle-end/49897] [4.5/4.6/4.7 Regression] nesting lastprivate gives incorrect result

2011-07-29 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49897

--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-29 
17:45:46 UTC ---
Author: jakub
Date: Fri Jul 29 17:45:42 2011
New Revision: 176945

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176945
Log:
PR middle-end/49897
PR middle-end/49898
* omp-low.c (use_pointer_for_field): If disallowing copy-in/out
in nested parallel and outer is a gimple_reg, mark it as addressable
and set its bit in task_shared_vars bitmap too.

* testsuite/libgomp.c/pr49897-1.c: New test.
* testsuite/libgomp.c/pr49897-2.c: New test.
* testsuite/libgomp.c/pr49898-1.c: New test.
* testsuite/libgomp.c/pr49898-2.c: New test.

Added:
trunk/libgomp/testsuite/libgomp.c/pr49897-1.c
trunk/libgomp/testsuite/libgomp.c/pr49897-2.c
trunk/libgomp/testsuite/libgomp.c/pr49898-1.c
trunk/libgomp/testsuite/libgomp.c/pr49898-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c
trunk/libgomp/ChangeLog


[Bug middle-end/49898] [4.5/4.6/4.7 Regression] nested reduction on #pragma omp for gives incorrect result

2011-07-29 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49898

--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-29 
17:48:46 UTC ---
Author: jakub
Date: Fri Jul 29 17:48:42 2011
New Revision: 176946

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176946
Log:
PR middle-end/49897
PR middle-end/49898
* omp-low.c (use_pointer_for_field): If disallowing copy-in/out
in nested parallel and outer is a gimple_reg, mark it as addressable
and set its bit in task_shared_vars bitmap too.

* testsuite/libgomp.c/pr49897-1.c: New test.
* testsuite/libgomp.c/pr49897-2.c: New test.
* testsuite/libgomp.c/pr49898-1.c: New test.
* testsuite/libgomp.c/pr49898-2.c: New test.

Added:
branches/gcc-4_6-branch/libgomp/testsuite/libgomp.c/pr49897-1.c
branches/gcc-4_6-branch/libgomp/testsuite/libgomp.c/pr49897-2.c
branches/gcc-4_6-branch/libgomp/testsuite/libgomp.c/pr49898-1.c
branches/gcc-4_6-branch/libgomp/testsuite/libgomp.c/pr49898-2.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/omp-low.c
branches/gcc-4_6-branch/libgomp/ChangeLog


[Bug middle-end/49897] [4.5/4.6/4.7 Regression] nesting lastprivate gives incorrect result

2011-07-29 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49897

--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-29 
17:48:45 UTC ---
Author: jakub
Date: Fri Jul 29 17:48:42 2011
New Revision: 176946

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176946
Log:
PR middle-end/49897
PR middle-end/49898
* omp-low.c (use_pointer_for_field): If disallowing copy-in/out
in nested parallel and outer is a gimple_reg, mark it as addressable
and set its bit in task_shared_vars bitmap too.

* testsuite/libgomp.c/pr49897-1.c: New test.
* testsuite/libgomp.c/pr49897-2.c: New test.
* testsuite/libgomp.c/pr49898-1.c: New test.
* testsuite/libgomp.c/pr49898-2.c: New test.

Added:
branches/gcc-4_6-branch/libgomp/testsuite/libgomp.c/pr49897-1.c
branches/gcc-4_6-branch/libgomp/testsuite/libgomp.c/pr49897-2.c
branches/gcc-4_6-branch/libgomp/testsuite/libgomp.c/pr49898-1.c
branches/gcc-4_6-branch/libgomp/testsuite/libgomp.c/pr49898-2.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/omp-low.c
branches/gcc-4_6-branch/libgomp/ChangeLog


[Bug c++/49896] undefined reference to static const integral member whose address is not used, for some values of the constant

2011-07-29 Thread harald at gigawatt dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49896

Harald van Dijk harald at gigawatt dot nl changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

--- Comment #4 from Harald van Dijk harald at gigawatt dot nl 2011-07-29 
17:55:21 UTC ---
0x8000 is (possibly wrongly) rejected as an integer constant expression,
because it is not within int's range. It is accepted with an explicit cast.
With a slight modification, it triggers an ICE:

templateclass C 
class test {
 protected:
  static const int versionConst = 0x8000;
  enum { versionEnum = versionConst }; 
 public:
  int getVersion();
};

templateclass C 
int testC::getVersion() {
  return versionEnum;
}

class dummy_class {};

int main() {
  testdummy_class t; 
  return t.getVersion();
}
$ g++ -c test.cc
test.cc: In instantiation of ‘testdummy_class’:
test.cc:18:21:   instantiated from here
test.cc:5:8: error: the value of ‘testdummy_class::versionConst’ is not
usable in a constant expression
test.cc:5:8: internal compiler error: in non_const_var_error, at
cp/semantics.c:6852
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/pkgbuild/sys-devel/gcc-4.6.1/work/gcc-4.6.1/configure
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --prefix=/usr
--enable-languages=c,c++,ada --enable-checking
Thread model: posix
gcc version 4.6.1 (GCC)


[Bug middle-end/49897] [4.5 Regression] nesting lastprivate gives incorrect result

2011-07-29 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49897

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||4.6.2, 4.7.0
Summary|[4.5/4.6/4.7 Regression]|[4.5 Regression] nesting
   |nesting lastprivate gives   |lastprivate gives incorrect
   |incorrect result|result

--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-29 
17:57:48 UTC ---
Fixed for 4.6+ so far, 4.5 backport scheduled for later on.


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

2011-07-29 Thread wschmidt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49749

--- Comment #15 from William J. Schmidt wschmidt at gcc dot gnu.org 
2011-07-29 18:40:26 UTC ---
Author: wschmidt
Date: Fri Jul 29 18:40:21 2011
New Revision: 176948

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176948
Log:
2011-07-29  Bill Schmidt  wschm...@linux.vnet.ibm.com

PR tree-optimization/49749
* tree-ssa-reassoc.c (get_rank): New forward declaration.
(PHI_LOOP_BIAS): Changed value.
(phi_loop_bias): Replaced with...
(phi_rank): ...this new function.
(loop_carried_phi): New function.
(propagate_rank): Likewise.
(get_rank): Replace loop-biasing expression with call to phi_rank;
remove variable maxrank; replace propagation logic with calls to
propagate_rank.


Modified:
branches/ibm/gcc-4_6-branch/gcc/ChangeLog.ibm
branches/ibm/gcc-4_6-branch/gcc/tree-ssa-reassoc.c


[Bug target/49904] New: Internal error with multiplication and -msoft-float

2011-07-29 Thread mikulas at artax dot karlin.mff.cuni.cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49904

   Summary: Internal error with multiplication and -msoft-float
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: miku...@artax.karlin.mff.cuni.cz
  Host: hppa-linux-gnu
Target: hppa64-linux-gnu
 Build: hppa-linux-gnu


Gcc 4.6.1 compiled for hppa64 target will crash with unrecognizable insn when
this program is compiled with -msoft-float. If multiplication is replaced with
division, gcc crashes as well.

int mul(int x, int y)
{
return x * y;
}

.LEVEL 2.0w
mul.c: In function 'mul':
mul.c:4:1: error: unrecognizable insn:
(insn 13 12 14 3 (set (reg:DI 69 [ retval+-4 ])
(reg:DI 75)) mul.c:3 -1
 (nil))
mul.c:4:1: internal compiler error: in extract_insn, at recog.c:2109
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

$ hppa64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=hppa64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc64/libexec/gcc/hppa64-linux-gnu/4.6.1/lto-wrapper
Target: hppa64-linux-gnu
Configured with: ../gcc-4.6.1/configure --prefix=/usr/local/gcc64
--enable-languages=c --disable-lto --disable-shared --disable-threads
--disable-libgomp --disable-libmudflap --disable-libssp --disable-libquadmath
--includedir=/usr/hppa64-linux-gnu/include
--with-as=/usr/local/bin/hppa64-linux-gnu-as
--with-ld=/usr/local/bin/hppa64-linux-gnu-ld --with-system-zlib --disable-nls
--without-included-gettext --build=hppa-linux-gnu --host=hppa-linux-gnu
--target=hppa64-linux-gnu
Thread model: single
gcc version 4.6.1 (GCC)


[Bug target/46468] enabling -fomit-frame-pointer by default breaks Wine

2011-07-29 Thread jacek at codeweavers dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46468

Jacek Caban jacek at codeweavers dot com changed:

   What|Removed |Added

 CC||jacek at codeweavers dot
   ||com

--- Comment #21 from Jacek Caban jacek at codeweavers dot com 2011-07-29 
18:55:54 UTC ---
FWIW mutation.c was a Wine bug that is already fixed in Wine.


[Bug target/49821] [4.6 regression] ICE in dwarf2out_cfi_begin_epilogue, at dwarf2out.c:3015

2011-07-29 Thread aurelien at aurel32 dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49821

--- Comment #1 from Aurelien Jarno aurelien at aurel32 dot net 2011-07-29 
19:15:19 UTC ---
Created attachment 24866
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24866
Testcase

Here is a reduced testcase, the bug can be reproduced with:

g++ -c -fvisibility=hidden -g -Os testcase-min.ii


[Bug c/49905] New: Better sanity checking on sprintf src dest to produce warning for dodgy code ?

2011-07-29 Thread dcb314 at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49905

   Summary: Better sanity checking on sprintf src  dest to
produce warning for dodgy code ?
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dcb...@hotmail.com


I just tried to compile the following C++ code with the latest trunk
snapshot 20110723 on an AMD x86_64 box.

# include stdio.h

void f()
{
char * p = new char [4];
char q[4];

sprintf(p, ian);  // Legal
sprintf(q, ian);

sprintf(p, bert); // One over
sprintf(q, bert);

sprintf(p, harry);// definately wrong.
sprintf(q, harry);

sprintf(p, %s, harry);  // more subtle.
sprintf(q, %s, harry);

sprintf(p, %s %s, ab, cd);// more subtle still.
sprintf(q, %s %s, ab, cd);

sprintf(p, %s %d, ab, 1000);// overpoints.
sprintf(q, %s %d, ab, 1000);
}

Much to my surprise, the compiler, even with lots of flags, said not much

bash-4.2$ ~/gcc/20110723/results/bin/g++ -c -O2 -Wall -Wextra -pedantic
bug29.cc
bash-4.2$

I'd have expected a few warnings, at very least.

Surely something in the compiler could be done to check that sprintf is
called, the destination buffer size is known, the minimum source buffer
size is known, and compare the two to make sure the source fits inside
the destination ?

Such a warning will in my experience find plenty of bugs in application code.


[Bug tree-optimization/23286] missed fully redundant expression

2011-07-29 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286

--- Comment #33 from Andrew Pinski pinskia at gcc dot gnu.org 2011-07-29 
20:11:29 UTC ---
(In reply to comment #26)
 Created attachment 19634 [details]
 updated patch
This patch fails on the trunk now with:
/data/src/gcc-cavium/gcc-4.6-upgrade/src/libstdc++-v3/src/strstream.cc: In
destructor ‘virtual std::strstream::~strstream()’:
/data/src/gcc-cavium/gcc-4.6-upgrade/src/libstdc++-v3/src/strstream.cc:399:3:
error: statement marked for throw in middle of block
# .MEM_23 = VDEF .MEM_22
std::strstreambuf::~strstreambuf (D.20970_7);


[Bug debug/49906] New: wrong .debug_line for -O0 -g prologue skip

2011-07-29 Thread jan.kratochvil at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49906

   Summary: wrong .debug_line for -O0 -g prologue skip
   Product: gcc
   Version: 4.4.7
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jan.kratoch...@redhat.com
Target: x86_64-unknown-linux-gnu


FAIL: gcc (GCC) 4.4.7 20110729 (prerelease)
FAIL: gcc (GCC) 4.5.4 20110729 (prerelease)
FAIL: gcc (GCC) 4.6.2 20110729 (prerelease)
FAIL: gcc (GCC) 4.7.0 20110728 (experimental)
-g
---
static int i;
static void
f (void)
{
  for (;;)
if (i++)
  break;
}
int main (void) { f (); return 0; }
---
(gdb) break f
Breakpoint 1 at 0x40045a: file src12932.c, line 8.
(gdb) run
Breakpoint 1, f () at src12932.c:8
8}
(gdb) print i
Actual:
$1 = 1
Expected:
$1 = 0
---
Original GDB bugreport:
http://sourceware.org/bugzilla/show_bug.cgi?id=12932
---
 Line Number Statements:
  Extended opcode 2: set Address to 0x400454
  Special opcode 8: advance Address by 0 to 0x400454 and Line by 3 to 4
  Special opcode 93: advance Address by 6 to 0x40045a and Line by 4 to 8
  Special opcode 17: advance Address by 1 to 0x40045b and Line by -2 to 6
---
00400454 f:
f():
/home/jkratoch/t/src12932.c:4
  400454:   55  push   %rbp
  400455:   48 89 e5mov%rsp,%rbp
  400458:   eb 01   jmp40045b f+0x7
/home/jkratoch/t/src12932.c:8
  40045a:   90  nop
/home/jkratoch/t/src12932.c:6
  40045b:   8b 05 17 04 20 00   mov0x200417(%rip),%eax#
600878 i
  400461:   85 c0   test   %eax,%eax
  400463:   0f 95 c2setne  %dl
  400466:   83 c0 01add$0x1,%eax
  400469:   89 05 09 04 20 00   mov%eax,0x200409(%rip)#
600878 i
  40046f:   84 d2   test   %dl,%dl
  400471:   74 e7   je 40045a f+0x6
/home/jkratoch/t/src12932.c:7
  400473:   90  nop
/home/jkratoch/t/src12932.c:8
  400474:   5d  pop%rbp
  400475:   c3  retq


[Bug middle-end/49905] Better sanity checking on sprintf src dest to produce warning for dodgy code ?

2011-07-29 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49905

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-29 
21:10:06 UTC ---
Just use also -D_FORTIFY_SOURCE=1 -O2 or -D_FORTIFY_SOURCE=2 -O2.
For the first three overflows on q you'll get compile time warnings, and for
all overflows on q you'll get the program killed at runtime.
If you use char * p = (char *) malloc (4);
instead of char * p = new char [4];
you'll get protection for the p overflows too, I'll see if
__builtin_object_size could be taught about C++ new, at least some forms
thereof.


[Bug bootstrap/49907] New: lto-plugin -Wall in stage1

2011-07-29 Thread marc.glisse at normalesup dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49907

   Summary: lto-plugin -Wall in stage1
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org


Hello,

lto-plugin/Makefile.am has -Wall -Werror. It is built in stage1, meaning with a
compiler that is not gcc, which causes it to fail.


[Bug bootstrap/49908] New: -lm missing after -lmpc

2011-07-29 Thread marc.glisse at normalesup dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49908

   Summary: -lm missing after -lmpc
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org
  Host: i386-pc-solaris2.11


Hello,

I am using a not-gcc (sunpro) compiler to initiate a bootstrap. I let gcc build
gmp/mpfr/mpc. When linking cc1 in stage1, I see:

cc   -g -DIN_GCC-DHAVE_CONFIG_H  -o cc1 c-lang.o c-family/stub-objc.o
attribs.o c-errors.o c-decl.o c-typeck.o c-convert.o c-aux-info.o
c-objc-common.o c-parser.o tree-mudflap.o c-family/c-common.o
c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o
c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o
c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o
c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o i386-c.o
sol2-c.o default-c.o \
  cc1-checksum.o main.o tree-browser.o libbackend.a libcommon-target.a
libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a   ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a   
-L/home/oracle/build/./gmp/.libs -L/home/oracle/build/./mpfr/.libs
-L/home/oracle/build/./mpc/src/.libs -lmpc -lmpfr -lgmp   -L../zlib -lz
Undefined   first referenced
 symbol in file
cimag  
/home/oracle/build/./mpc/src/.libs/libmpc.a(set_x.o)
creal  
/home/oracle/build/./mpc/src/.libs/libmpc.a(set_x.o)
cimagl 
/home/oracle/build/./mpc/src/.libs/libmpc.a(set_x.o)
creall 
/home/oracle/build/./mpc/src/.libs/libmpc.a(set_x.o)
ld: fatal: symbol referencing errors. No output written to cc1

The missing symbols are all available in libm, as specified in libmpc.la.

(solaris comes with an older gcc-3.4 but mpc doesn't build with it, hence my
use of suncc)


[Bug bootstrap/49908] -lm missing after -lmpc

2011-07-29 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49908

--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-07-29 
21:59:32 UTC ---
Normally most compilers inline cimag and creal.  Seems weird that Sun's
compiler does not.


[Bug bootstrap/49908] -lm missing after -lmpc

2011-07-29 Thread marc.glisse at normalesup dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49908

--- Comment #2 from Marc Glisse marc.glisse at normalesup dot org 2011-07-29 
22:09:21 UTC ---
(In reply to comment #1)
 Normally most compilers inline cimag and creal.  Seems weird that Sun's
 compiler does not.

It does on a trivial testcase. I'll try to see why it doesn't in mpc.


[Bug bootstrap/49908] -lm missing after -lmpc

2011-07-29 Thread marc.glisse at normalesup dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49908

--- Comment #3 from Marc Glisse marc.glisse at normalesup dot org 2011-07-29 
22:18:52 UTC ---
(In reply to comment #2)
  Normally most compilers inline cimag and creal.  Seems weird that Sun's
  compiler does not.
 It does on a trivial testcase. I'll try to see why it doesn't in mpc.

Er, forget that, different PATH in this terminal :-(
Even with -fast (which implies -xbuiltin=%all), oracle solaris studio 12.3
never inlines cimag...


[Bug c++/49867] [C++0x] ICE on lambda inside switch with case labels in the lambda

2011-07-29 Thread jason at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49867

Jason Merrill jason at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.07.29 22:32:10
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1


[Bug other/49892] Error in configure test xgcc in x86_64-apple-darwin11.0.0/libgcc

2011-07-29 Thread danp57 at optonline dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49892

--- Comment #2 from Daniel E. Platt danp57 at optonline dot net 2011-07-29 
23:09:26 UTC ---
Thanks!  This works.

Best,
Dan




On Jul 29, 2011, at 8:44 AM, howarth at nitro dot med.uc.edu wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49892
 
 Jack Howarth howarth at nitro dot med.uc.edu changed:
 
   What|Removed |Added
 
 CC||howarth at nitro dot
   ||med.uc.edu
 
 --- Comment #1 from Jack Howarth howarth at nitro dot med.uc.edu 2011-07-29 
 12:43:41 UTC ---
 You are trying to compile FSF gcc with Apple's llvm-gcc from Xcode 4.1. This
 llvm-gcc suffers from http://llvm.org/bugs/show_bug.cgi?id=9571 whose fix from
 llvm-gcc 2.9 hasn't been backported into Apple's llvm-gcc yet. Use clang or
 gcc-4.2 to bootstrap instead.
 
 -- 
 Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
 --- You are receiving this mail because: ---
 You reported the bug.


[Bug target/49909] New: FSF gcc 4.6.1 fails to bootstrap on Core Solo/Core Duo

2011-07-29 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49909

   Summary: FSF gcc 4.6.1 fails to bootstrap on Core Solo/Core Duo
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu


The bootstrap of FSF gcc 4.6.1 fails on Core Solo/Core Duo processors when
configure is executed within the x86_64 multilib and attempts to execute x86_64
code on a non-EMT64 processor. This failure in the config.log from the x86_64
multilib of libquadmath is...

configure:3307: checking for C compiler default output file name
configure:3329: /sw/src/fink.build/gcc46-4.6.1-1000/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc46-4.6.1-1000/darwin_objdir/./gcc/
-B/sw/lib/gcc4.6/i386-apple-darwin10.8.0/bin/
-B/sw/lib/gcc4.6/i386-apple-darwin10.8.0/lib/ -isystem
/sw/lib/gcc4.6/i386-apple-darwin10.8.0/include -isystem
/sw/lib/gcc4.6/i386-apple-darwin10.8.0/sys-include  -m64 -g -O2   conftest.c 
5
configure:: $? = 0
configure:3370: result: a.out
configure:3386: checking whether the C compiler works
configure:3395: ./a.out
../../../../gcc-4.6.1/libquadmath/configure: line 3397: ./a.out: Bad CPU type
in executable
configure:3399: $? = 126
configure:3406: error: in
`/sw/src/fink.build/gcc46-4.6.1-1000/darwin_objdir/i386-apple-darwin10.8.0/x86_64/libquadmath':
configure:3410: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.


[Bug target/49909] FSF gcc 4.6.1 fails to bootstrap on Core Solo/Core Duo

2011-07-29 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49909

--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-07-29 
23:35:13 UTC ---
Use --disable-multilib.


[Bug target/49909] FSF gcc 4.6.1 fails to bootstrap on Core Solo/Core Duo

2011-07-29 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49909

--- Comment #2 from Jack Howarth howarth at nitro dot med.uc.edu 2011-07-29 
23:35:46 UTC ---
Created attachment 24867
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24867
config.log file from x86_64 multilib directory on Core Duo (non-EMT64)


[Bug target/49909] FSF gcc 4.6.1 fails to bootstrap on Core Solo/Core Duo

2011-07-29 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49909

--- Comment #3 from Jack Howarth howarth at nitro dot med.uc.edu 2011-07-29 
23:43:12 UTC ---
This section of configure appears unprepared for the possibility of compiling
on i386-apple-darwin* with a multilib that can't be executed on the non-EMT64
cpu...


# Check that the compiler produces executables we can run.  If not, either
# the compiler is broken, or we cross compile.
{ $as_echo $as_me:${as_lineno-$LINENO}: checking whether the C compiler works
5
$as_echo_n checking whether the C compiler works...  6; }
# If not cross compiling, check that we can run a simple program.
if test $cross_compiling != yes; then
  if { ac_try='./$ac_file'
  { { case (($ac_try in
  *\* | *\`* | *\\*) ac_try_echo=\$ac_try;;
  *) ac_try_echo=$ac_try;;
esac
eval ac_try_echo=\\$as_me:${as_lineno-$LINENO}: $ac_try_echo\
$as_echo $ac_try_echo; } 5
  (eval $ac_try) 25
  ac_status=$?
  $as_echo $as_me:${as_lineno-$LINENO}: \$? = $ac_status 5
  test $ac_status = 0; }; }; then
cross_compiling=no
  else
if test $cross_compiling = maybe; then
cross_compiling=yes
else
{ { $as_echo $as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd': 5
$as_echo $as_me: error: in \`$ac_pwd': 2;}
as_fn_error cannot run C compiled programs.
If you meant to cross compile, use \`--host'.

See \`config.log' for more details. $LINENO 5; }
fi
  fi
fi
{ $as_echo $as_me:${as_lineno-$LINENO}: result: yes 5
$as_echo yes 6; }

rm -f -r a.out a.out.dSYM a.exe conftest$ac_cv_exeext b.out conftest.out
ac_clean_files=$ac_clean_files_save
# Check that the compiler produces executables we can run.  If not, either
# the compiler is broken, or we cross compile.
{ $as_echo $as_me:${as_lineno-$LINENO}: checking whether we are cross
compiling 5
$as_echo_n checking whether we are cross compiling...  6; }
{ $as_echo $as_me:${as_lineno-$LINENO}: result: $cross_compiling 5
$as_echo $cross_compiling 6; }


[Bug c++/49910] New: internal compiler error: in redirect_jump, at jump.c:1485 when build ppl-0.11.2

2011-07-29 Thread i.nixman at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49910

   Summary: internal compiler error: in redirect_jump, at
jump.c:1485 when build ppl-0.11.2
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: i.nix...@gmail.com


Created attachment 24868
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24868
temporaries files and log


[Bug target/49909] FSF gcc 4.6.1 fails to bootstrap on Core Solo/Core Duo

2011-07-29 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49909

--- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu 2011-07-30 
02:58:20 UTC ---
(In reply to comment #1)
 Use --disable-multilib.

Not an option for us on fink since the same packaging script has to both list
the built shared libraries
and run on both non-EMT64 and EMT64 processors. For now, I am forced to just
short circuit the
test locally with the hack...

--- gcc-4.6.1/libquadmath/configure.orig2011-07-29 21:31:51.0
-0400
+++ gcc-4.6.1/libquadmath/configure 2011-07-29 21:32:36.0 -0400
@@ -3395,7 +3395,7 @@
 eval ac_try_echo=\\$as_me:${as_lineno-$LINENO}: $ac_try_echo\
 $as_echo $ac_try_echo; } 5
   (eval $ac_try) 25
-  ac_status=$?
+  ac_status=0
   $as_echo $as_me:${as_lineno-$LINENO}: \$? = $ac_status 5
   test $ac_status = 0; }; }; then
 cross_compiling=no

so that libquadmath can be built like all the other 64-bit binaries regardless
of EMT64 support.