date:20111003

[Bug tree-optimization/50587] ICE init_range_entry, at tree-ssa-reassoc.c:1698 caused by recent change

2011-10-03 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-10-03
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Jakub Jelinek  2011-10-03 
07:57:27 UTC ---
Created attachment 25402
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25402
gcc47-pr50587.patch

Does this patch fix it?  I've reproduce it only on invalid code:
extern int c[64];

int
foo (int a)
{
  int x = a > 1;
  int y = &c[60] < (int *) 0x12345678UL;
  return x | y;
}

[Bug tree-optimization/50596] New: Problems in vectorization of condition expression

2011-10-03 Thread vincenzo.innocente at cern dot ch

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

 Bug #: 50596
   Summary: Problems in vectorization of condition expression
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch


I've the need to vectorize something like this
const int N=1024;
float a[1024];
float b[1024];
float c[1024];
float d[1024];
bool z[1024];
// not vectorized: control flow in loop
void ori() {
  for (int i=0; i!=N; ++i)
z[i] = a[i]

[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2

2011-10-03 Thread mikpe at it dot uu.se

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

--- Comment #10 from Mikael Pettersson  2011-10-03 
08:35:31 UTC ---
(In reply to comment #8)
> (In reply to comment #6)
> > So which libc was this originally compiled against?  Some things in
> > traceroute.i make me think it's glibc, but I don't see any indication of 
> > which
> > version it was.
> 
> The glibc version is 2.14 and is compiled with the attached patches.

Using the non-preprocessed traceroute.c I can reproduce the segfault with
gcc-4.6.1 and glibc-2.13 (Fedora 14) but not with glibc-2.12.2 (Fedora 13).

[Bug tree-optimization/50596] Problems in vectorization of condition expression

2011-10-03 Thread vincenzo.innocente at cern dot ch

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

--- Comment #1 from vincenzo Innocente  
2011-10-03 08:40:53 UTC ---
manage to vectorize this

int j[1024];
void foo5() {
  for (int i=0; i!=N; ++i)
j[i] = (a[i]

[Bug tree-optimization/50587] ICE init_range_entry, at tree-ssa-reassoc.c:1698 caused by recent change

2011-10-03 Thread markus at trippelsdorf dot de

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

--- Comment #3 from Markus Trippelsdorf  
2011-10-03 08:44:09 UTC ---
(In reply to comment #2)
> Created attachment 25402 [details]
> gcc47-pr50587.patch
> 
> Does this patch fix it?

Yes it fixes both the LTO kernel and Firefox builds.
Thanks.

[Bug c++/50593] improve attribute((format(printf)))

2011-10-03 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  2011-10-03 
08:53:27 UTC ---
const char[] not working in C++ is PR38980.

[Bug tree-optimization/50587] ICE init_range_entry, at tree-ssa-reassoc.c:1698 caused by recent change

2011-10-03 Thread jakub at gcc dot gnu.org

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

--- Comment #4 from Jakub Jelinek  2011-10-03 
09:06:43 UTC ---
Author: jakub
Date: Mon Oct  3 09:06:38 2011
New Revision: 179447

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179447
Log:
PR tree-optimization/50587
* tree-ssa-reassoc.c (init_range_entry): Stop iterating when
arg0 is not a SSA_NAME.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug target/50038] redundant zero extensions

2011-10-03 Thread ubizjak at gmail dot com

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

--- Comment #4 from Uros Bizjak  2011-10-03 09:19:16 
UTC ---
(In reply to comment #3)
> So assuming this approach (modify implicit-zee pass) is right, we'll have to
> enable this pass at least on x86 (32 bit). Is it ok ?
> 
> P. S.
> I forgot to mention that this patch bootstraps/passes ,make check.

Please post patches to gcc-patches mailing list.

[Bug other/50597] New: printf_fp.o: relocation R_X86_64_PC32 against `hack_digit.6607' can not be used when making a shared object; recompile with -fPIC

2011-10-03 Thread mustarddream at gmail dot com

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

 Bug #: 50597
   Summary: printf_fp.o: relocation R_X86_64_PC32 against
`hack_digit.6607' can not be used when making a shared
object; recompile with -fPIC
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mustarddr...@gmail.com



OS : CentOS 5.7
GCC to build GCC 4.6.1 : 4.1.2
MPC : 0.9
MPFR : 3.0.1
GMP : 5.0.2

With the above system configuration and the below configure options,
I was sucessful to build gcc 4.3.6, gcc 4.4.0, gcc 4.5.3.

However, I failed to build gcc 4.6.1.



In a directory named 'build',

../gcc-5.6.1/configure
--prefix=/home/dwlee/softwares/gcc/gcc46
--with-gmp=/home/dwlee/softwares/gcc/gmp
--with-mpfr=/home/dwlee/softwares/gcc/mpfr
--with-mpc=/home/dwlee/softwares/gcc/mpc
--enable-shared
--enable-threads=posix
--enable-checking=release
--with-system-zlib
--enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,d
--enable-java-awt=gtk
--disable-dssi
--disable-plugin
--with-java-home=/home/dwlee/softwares/java/jre1.6.0_27
--with-cpu=generic 

& make





The error below occurs during 'make' process.



... omitted  ...

make[3]: Entering directory
`/home/dwlee/softwares/gcc/gcc46/build/x86_64-unknown-linux-gnu/libquadmath'
/bin/sh ./libtool --tag=CC   --mode=link
/home/dwlee/softwares/gcc/gcc46/build/./gcc/xgcc
-B/home/dwlee/softwares/gcc/gcc46/build/./gcc/
-B/home/dwlee/softwares/gcc/gcc46/x86_64-unknown-linux-gnu/bin/
-B/home/dwlee/softwares/gcc/gcc46/x86_64-unknown-linux-gnu/lib/ -isystem
/home/dwlee/softwares/gcc/gcc46/x86_64-unknown-linux-gnu/include -isystem
/home/dwlee/softwares/gcc/gcc46/x86_64-unknown-linux-gnu/sys-include -g -O2
-version-info `grep -v '^#' ../../../gcc-4.6.1/libquadmath/libtool-version`
-Wl,--version-script=../../../gcc-4.6.1/libquadmath/quadmath.map  -lm  -o
libquadmath.la -rpath /home/dwlee/softwares/gcc/gcc46/lib/../lib64
math/acoshq.lo math/fmodq.lo math/acosq.lo math/frexpq.lo math/rem_pio2q.lo
math/asinhq.lo math/hypotq.lo math/remainderq.lo math/asinq.lo math/rintq.lo
math/atan2q.lo math/isinfq.lo math/roundq.lo math/atanhq.lo math/isnanq.lo
math/scalblnq.lo math/atanq.lo math/j0q.lo math/scalbnq.lo math/cbrtq.lo
math/j1q.lo math/signbitq.lo math/ceilq.lo math/jnq.lo math/sincos_table.lo
math/complex.lo math/ldexpq.lo math/sincosq.lo math/copysignq.lo
math/lgammaq.lo math/sincosq_kernel.lo math/coshq.lo math/llroundq.lo
math/sinhq.lo math/cosq.lo math/log10q.lo math/sinq.lo math/cosq_kernel.lo
math/log1pq.lo math/sinq_kernel.lo math/erfq.lo math/logq.lo math/sqrtq.lo
math/expm1q.lo math/lroundq.lo math/tanhq.lo math/expq.lo math/modfq.lo
math/tanq.lo math/fabsq.lo math/nanq.lo math/tgammaq.lo math/finiteq.lo
math/nextafterq.lo math/truncq.lo math/floorq.lo math/powq.lo math/fmaq.lo
math/cacoshq.lo math/cacosq.lo math/casinhq.lo math/casinq.lo math/catanhq.lo
math/catanq.lo math/cimagq.lo math/conjq.lo math/cprojq.lo math/crealq.lo
math/fdimq.lo math/fmaxq.lo math/fminq.lo math/ilogbq.lo math/llrintq.lo
math/log2q.lo math/lrintq.lo math/nearbyintq.lo math/remquoq.lo
printf/addmul_1.lo printf/add_n.lo printf/cmp.lo printf/divrem.lo
printf/flt1282mpn.lo printf/fpioconst.lo printf/lshift.lo printf/mul_1.lo
printf/mul_n.lo printf/mul.lo printf/printf_fphex.lo printf/printf_fp.lo
printf/quadmath-printf.lo printf/rshift.lo printf/submul_1.lo printf/sub_n.lo
strtod/strtoflt128.lo strtod/mpn2flt128.lo strtod/tens_in_limb.lo
libtool: link: /home/dwlee/softwares/gcc/gcc46/build/./gcc/xgcc
-B/home/dwlee/softwares/gcc/gcc46/build/./gcc/
-B/home/dwlee/softwares/gcc/gcc46/x86_64-unknown-linux-gnu/bin/
-B/home/dwlee/softwares/gcc/gcc46/x86_64-unknown-linux-gnu/lib/ -isystem
/home/dwlee/softwares/gcc/gcc46/x86_64-unknown-linux-gnu/include -isystem
/home/dwlee/softwares/gcc/gcc46/x86_64-unknown-linux-gnu/sys-include-shared
 math/.libs/acoshq.o math/.libs/fmodq.o math/.libs/acosq.o math/.libs/frexpq.o
math/.libs/rem_pio2q.o math/.libs/asinhq.o math/.libs/hypotq.o
math/.libs/remainderq.o math/.libs/asinq.o math/.libs/rintq.o
math/.libs/atan2q.o math/.libs/isinfq.o math/.libs/roundq.o math/.libs/atanhq.o
math/.libs/isnanq.o math/.libs/scalblnq.o math/.libs/atanq.o math/.libs/j0q.o
math/.libs/scalbnq.o math/.libs/cbrtq.o math/.libs/j1q.o math/.libs/signbitq.o
math/.libs/ceilq.o math/.libs/jnq.o math/.libs/sincos_table.o
math/.libs/complex.o math/.libs/ldexpq.o math/.libs/sincosq.o
math/.libs/copysignq.o math/.libs/lgammaq.o math/.libs/sincosq_kernel.o
math/.libs/coshq.o math/.libs/llroundq.o math/.libs/sinhq.o math/.libs/cosq.o
math/.libs/log10q.o math/.libs/sinq.o math/.libs/cosq_kernel.o
math/.libs/log1pq.o math/.libs/sinq_kernel.o math/.libs/erfq.o
math/.libs/logq.o math/.libs/sqrtq

[Bug c++/50595] template overload resolution insufficiently sensitive to name dependency?

2011-10-03 Thread paolo.carlini at oracle dot com

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

--- Comment #1 from Paolo Carlini  2011-10-03 
10:04:17 UTC ---
Without having looked at the code, ICC behaves exactly like GCC.

[Bug c++/39681] Compile error is not descriptive

2011-10-03 Thread manu at gcc dot gnu.org

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

--- Comment #3 from Manuel López-Ibáñez  2011-10-03 
10:07:49 UTC ---
(In reply to comment #2)
> Manuel, can I have your opinion about this one?

Since you ask, my opinion is that first there should be only 1 error and not
two, and bonus points if the error is something like "'foo' is not a type".
Clang says:

/tmp/webcompile/_9832_0.cc:4:18: error: expected a type
int* p = new foo;
 ^
1 error generated.

On the other hand, I understand that this may be difficult to fix with g++
tentative parser. The fix could be something like, once "new" is seen, then
commit to parse a new-expression. But I haven't looked at this code
specifically.

Interestingly, for:

int main()
{
int* p = delete foo;
}

g++ says:

test.cc:3:21: error: ‘foo’ was not declared in this scope

[Bug fortran/50570] [4.6/4.7 Regression] Incorrect error for assignment to intent(in) pointer

2011-10-03 Thread msteghofer at cistib dot upf.edu

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

--- Comment #2 from msteghofer at cistib dot upf.edu 2011-10-03 10:15:09 UTC ---
Created attachment 25403
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25403
Code to reproduce the behaviour

Subroutine POINTER_INTENT_IN_BUG_FAILING contains the failing code.
Subroutien POINTER_INTENT_IN_BUG_WORKING contains an alternative code that does
the same thing, but compiles (to show that the behaviour of gfortran doesn't
make sense as protection, either).

[Bug fortran/50570] [4.6/4.7 Regression] Incorrect error for assignment to intent(in) pointer

2011-10-03 Thread msteghofer at cistib dot upf.edu

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

msteghofer at cistib dot upf.edu changed:

   What|Removed |Added

 CC||msteghofer at cistib dot
   ||upf.edu

--- Comment #3 from msteghofer at cistib dot upf.edu 2011-10-03 10:16:51 UTC ---
I've got a very similar problem (attachment above). The difference is that I'm
not using assignments to write something inside the intent(in) pointer, but I'm
calling the function move_alloc with something inside the intent(in) pointer as
actual argument.

Please see the attached code above for details. The error message (gfortran
4.6.1) is the following:

bug.f90:22.20:
CALL MOVE_ALLOC(POINTER_INTENT_IN_VARIABLE%VALUE, LOCAL_VALUE)
1
Error: 'from' argument of 'move_alloc' intrinsic at (1) cannot be INTENT(IN)

As the error message is different from the one posted before, I'm not sure, if
this is the same bug, please check. If it's not, I will post a new report - I
just want to avoid duplicates.

Also I'm not sure about what the Fortran standard says, but I don't think that
giving this error is a desired behaviour because:
* According to documentation of other compilers the code should compile:
http://publib.boulder.ibm.com/infocenter/comphelp/v111v131/topic/com.ibm.xlf131.aix.doc/language_ref/intent.html
(section "Rules", subsection about pointer dummy arguments)
* If INTENT(IN) really tries to protect the *members* (not the pointer itself)
of the derived type from being changed (that's the only scenario in which this
behaviour would make sense), then it's not doing its job: Copying the pointer
to a local variable I'm able to change them, as the example
"POINTER_INTENT_IN_BUG_WORKING" in the attached code shows.

[Bug c/44854] Improve diagnostic for missing member name or ';' in a struct

2011-10-03 Thread manu at gcc dot gnu.org

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  2011-10-03 
10:23:57 UTC ---
(In reply to comment #1)
> identifier is the same as  member name.  In fact I say GCC's diagnostic is 
> more
> correct as ( can be there also.

I am sorry Andrew, but this way of reasoning is counter-intuitive. Can you
write?

struct foo { int (};

No, so talking about '(' doesn't make sense. And: "specifier-qualifier-list at
end of input" is equally bogus.

BTW, clang++ is neither perfect, and it makes a mess of error-recovery here.

/tmp/webcompile/_12636_0.cc:1:18: error: expected member name or ';' after
declaration specifiers
struct foo { int };
 ~~~ ^
/tmp/webcompile/_12636_0.cc:1:20: error: expected '}'
struct foo { int };
   ^
/tmp/webcompile/_12636_0.cc:1:12: note: to match this '{'
struct foo { int };
   ^
/tmp/webcompile/_12636_0.cc:1:20: error: expected ';' after struct
struct foo { int };
   ^
   ;
3 errors generated.

I guess it skips the '}' as the (invalid) member name, and consumes the ";" as
the end of the member declaration. Then, it notices that it needs a '}' and a
';'.

On the other hand, g++ is almost perfect:

test.cc:1:18: error: expected unqualified-id before ‘}’ token

except for the legalese-speak "unqualified-id".

[Bug c++/39681] Compile error is not descriptive

2011-10-03 Thread paolo.carlini at oracle dot com

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

--- Comment #4 from Paolo Carlini  2011-10-03 
11:08:39 UTC ---
Ok, thanks. Frankly I hadn't noticed the *second* error. The first one seemed
good enough to me, and quite similar to what I saw elsewhere modulo type
instead of type-specifier. So do you think it would be possible to get rid of
the stupid second error message within the current infrastructure?

[Bug c++/39681] Compile error is not descriptive

2011-10-03 Thread paolo.carlini at oracle dot com

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

--- Comment #5 from Paolo Carlini  2011-10-03 
11:13:52 UTC ---
Like, sorry about my naivete, by adding a cp_parser_skip_to_end_of_statement or
something right after the error message?!?

[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2

2011-10-03 Thread mikpe at it dot uu.se

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

--- Comment #11 from Mikael Pettersson  2011-10-03 
11:46:28 UTC ---
The failure seems to have disappeared on trunk starting with r179284:
http://gcc.gnu.org/ml/gcc-cvs/2011-09/msg00903.html

[Bug tree-optimization/50587] ICE init_range_entry, at tree-ssa-reassoc.c:1698 caused by recent change

2011-10-03 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Jakub Jelinek  2011-10-03 
11:55:30 UTC ---
Fixed.

[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2

2011-10-03 Thread mikpe at it dot uu.se

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

--- Comment #12 from Mikael Pettersson  2011-10-03 
12:56:10 UTC ---
Backporting r179284 to 4.6.1 (trivial except for the third ifcvt.c hunk which
required manual application due to a context diff) fixed the test case there
too.

[Bug preprocessor/36819] memleak in split_quote_chain

2011-10-03 Thread nightstrike at gmail dot com

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot
   ||com

--- Comment #4 from nightstrike  2011-10-03 
13:04:07 UTC ---
Can this be backported to all open branches?

[Bug boehm-gc/43682] libgcj don't support Win x64?

2011-10-03 Thread nightstrike at gmail dot com

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

--- Comment #3 from nightstrike  2011-10-03 
13:06:38 UTC ---
Who can update the in-tree boehm-gc?

[Bug boehm-gc/42304] found a resource leak

2011-10-03 Thread nightstrike at gmail dot com

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot
   ||com

--- Comment #3 from nightstrike  2011-10-03 
13:12:05 UTC ---
This problem is not fixed in upstream boehm-gc as of version 7.2a6

[Bug c++/50594] Option -fwhole-program discards replaced new operator for std::string

2011-10-03 Thread daniel.kruegler at googlemail dot com

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #5 from Daniel Krügler  
2011-10-03 13:17:11 UTC ---
I would have expected that the shown program works as expected. I'm quoting
ISO/IEC 14882:2003(E) (but N3290 seems to say the same):

1) [lib.replacement.functions] p2+3:

"2 - A C++ program may provide the definition for any of eight dynamic memory
allocation function signatures declared in header  (3.7.3, clause
18):[..]"

"3 - The program’s definitions are used instead of the default versions
supplied by the implementation (18.4). Such replacement occurs prior to program
startup (3.2, 3.6)."

[C++11 adds here: "The program’s definitions shall not be specified as inline."
But we have no inline problem here]

2) [lib.new.delete.single] p2 or p11:

"Replaceable: a C++ program may define a function with this function signature
that displaces the default version defined by the C++ Standard library."

Especially note that (2) says "this function signature", which does IMO not
allow to require the addition of export directives or anything else.

[Bug c++/50594] Option -fwhole-program discards replaced new operator for std::string

2011-10-03 Thread paolo.carlini at oracle dot com

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

--- Comment #6 from Paolo Carlini  2011-10-03 
13:22:23 UTC ---
I have no idea how this can be made to work with -fwhole-program, but other
people know better.

[Bug c++/50594] Option -fwhole-program discards replaced new operator for std::string

2011-10-03 Thread redi at gcc dot gnu.org

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

--- Comment #7 from Jonathan Wakely  2011-10-03 
13:41:50 UTC ---
(In reply to comment #3)
> Thank you for the replies. Is this behaviour standard-conforming?

The documentation for -fwhole-program says that all functions become static,
which I suspect makes your new and delete operators invalid for replacement
functions.  Andrew's suggestion works, just add these declarations:

void * operator new(std::size_t n) throw(std::bad_alloc)
__attribute__((externally_visible));
void operator delete(void * p) throw() __attribute__((externally_visible));

That prevents -fwhole-program from making them static.

[Bug c++/50594] Option -fwhole-program discards replaced new operator for std::string

2011-10-03 Thread redi at gcc dot gnu.org

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

--- Comment #8 from Jonathan Wakely  2011-10-03 
13:43:21 UTC ---
[basic.stc.dynamic.allocation] p1

"a program is ill-formed if an allocation function is declared in a namespace
scope other than global scope or declared static in global scope."

So using -fwhole-program and not making replacement functions
externally-visible produces an ill-formed program (which G++ should probably
reject)

[Bug c++/50594] Option -fwhole-program discards replaced new operator for std::string

2011-10-03 Thread paolo.carlini at oracle dot com

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

--- Comment #9 from Paolo Carlini  2011-10-03 
13:45:03 UTC ---
Oh, thanks Jon for testing that. Indeed, as far as I'm concerned, the issue is
resolved.

[Bug c++/50594] Option -fwhole-program discards replaced new operator for std::string

2011-10-03 Thread daniel.kruegler at googlemail dot com

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

--- Comment #10 from Daniel Krügler  
2011-10-03 13:49:01 UTC ---
(In reply to comment #8)

I agree that given the "make static" contract of -fwhole-program (which I was
not aware about) the compiler behaves accordingly. I wonder whether it would be
OK to consider the magic functions as special even for -fwhole-program, because
they do have a "magic-kind-of" specification in the standard.

[Bug middle-end/50598] New: [4.7 Regression] Undefined symbols: "___emutls_v.", ... on -apple-darwin*

2011-10-03 Thread dominiq at lps dot ens.fr

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

 Bug #: 50598
   Summary: [4.7 Regression] Undefined symbols: "___emutls_v.*",
... on *-apple-darwin*
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: hubi...@gcc.gnu.org
  Host: *-apple-darwin*
Target: *-apple-darwin*
 Build: *-apple-darwin*


Since revision 179430 (see
http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg00193.html r179421 is OK)
libgomp.c++/pr24455.C and libgomp.fortran/threadprivate4.f90 fail with

FAIL: libgomp.c++/pr24455.C  -O0  (test for excess errors)
Excess errors:
Undefined symbols:
  "___emutls_v.i", referenced from:
  ___emutls_v.i$non_lazy_ptr in ccB25Iow.o
 (maybe you meant: ___emutls_v.i$non_lazy_ptr)
ld: symbol(s) not found

[Bug tree-optimization/50599] New: -ftree-vectorize generating incorrect code

2011-10-03 Thread a5970694 at nepwk dot com

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

 Bug #: 50599
   Summary: -ftree-vectorize generating incorrect code
Classification: Unclassified
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a5970...@nepwk.com


MinGW x86 4.5.2
A loop:
while(total_out < decompressed_size)
{
printf("%X\n",p);
int chunk_size = *(int*)p;
if(chunk_size > 0)
{
int ret = params->decompressor(p+sizeof(int), chunk_size,
params->out+total_out, std::min(params->osize-total_out,params->bsize),
params->other);

int real_out = (ret / params->ssize) * params->ssize;
if(real_out != ret)
real_out += params->ssize;
if(total_out + real_out >= params->isize)
total_out += ret;
else
total_out += real_out;
p += chunk_size+sizeof(int);

}
else
{
if(params->verify)
{
memcpy(params->out+total_out, p+sizeof(int), -chunk_size);
p += -chunk_size;
}
total_out += -chunk_size;
p += sizeof(int);
}
}
Compiled with -O3 -fno-strict-aliasing works funny - the printf is called twice
with the same address. And on some data I'm getting crashes in
params->decompressor, which is a 3rd party code.
I added other printfs and I see that when running the loop for the 1st time,
the code enters the 1st branch, goes to p += chunk_size+sizeof(int), increases,
goes out of the if and iterates the loop again with unchanged p.

Adding -fno-tree-vectorize solves the problem.

[Bug c++/50594] Option -fwhole-program discards replaced new operator for std::string

2011-10-03 Thread redi at gcc dot gnu.org

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

--- Comment #11 from Jonathan Wakely  2011-10-03 
15:02:37 UTC ---
we could add __attribute__((externally_visible)) on the declarations in 

I don't know what other side effects that would have

[Bug c++/50594] Option -fwhole-program discards replaced new operator for std::string

2011-10-03 Thread paolo.carlini at oracle dot com

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

--- Comment #12 from Paolo Carlini  2011-10-03 
15:12:53 UTC ---
Yes, yesterday, a bit sleepy, I also wondered that, but I'm not knowledgeable
enough of these mechanisms to say whether it would be otherwise safe.

[Bug fortran/33814] Failure of gfortran n Mac Mini

2011-10-03 Thread mercergeoinfo at yahoo dot co.uk

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

mercergeoinfo at yahoo dot co.uk changed:

   What|Removed |Added

 CC||mercergeoinfo at yahoo dot
   ||co.uk

--- Comment #4 from mercergeoinfo at yahoo dot co.uk 2011-10-03 15:16:15 UTC ---
I followed the instructions in the 3rd comment, actually I installed the
suggested binary from the link in point 2 first but the problem persists.
Looking at the contents of 
/usr/local/libexec/gcc/i686-apple-darwin8/4.2.3/
may give an answer, it contains an empty folder called "install-tools".
Any other suggestions for getting gfortran to run on OSX (Lion)?

[Bug ada/50600] New: "Illegal instruction" when using pragma Profile (Restricted)

2011-10-03 Thread bauhaus at futureapps dot de

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

 Bug #: 50600
   Summary: "Illegal instruction" when using pragma Profile
(Restricted)
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bauh...@futureapps.de


The program below will fail as indicated (or not run
correctly, depending on platform) when pragma profile
(Restricted) is in effect. Failures vary a little.
On Mac OS X 10.6.8, GCC 4.7.0 x86_64-apple-darwin10.8.0
from 20111002:

$ ./rstr 
rsrt
Illegal instruction
$

A seemingly hanging program (Debian 6, GCC 4.7.0
i686-pc-linux-gnu from 20110610). Stack traces in the debugger
have varied a bit (on Mac), but mostly list subprograms to do
with PO entry calls (waiting) and (pthread) mutex locking,
judging by the names. Program receives SIGSEGV in debugger.

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/GCC-4.7/libexec/gcc/x86_64-apple-darwin10.8.0/4.7.0/lto-wrapper
Target: x86_64-apple-darwin10.8.0
Configured with: /Users/bauhaus/src/GCC/configure --enable-languages=c,ada
--disable-nls --prefix=/opt/GCC-4.7
Thread model: posix
gcc version 4.7.0 20111002 (experimental) (GCC)

If the program text is in file "rstr.ada", then

$ gnatchop -r -w rstr.ada && gnatmake rstr



pragma Profile (Restricted);
package Tsk is
   task Nop is
  pragma Priority (5);
   end Nop;
end Tsk;

with Report;
package body Tsk is
   task body Nop is
   begin
  Report.Put_Line ("Nop");
   end Nop;
end Tsk;

with Tsk;
with Report;
procedure Rstr is
begin
   Report.Put_Line ("rsrt");
end Rstr;

package Report is

   procedure Put_Line (Message : String);

private
   protected Output is
  entry Wait;
  procedure Release;
   private
  Available : Boolean := True;
   end Output;
end Report;

with Ada.Text_IO;

package body Report is
   procedure Put_Line (Message : String) is
   begin
  Output.Wait;
  Ada.Text_IO.Put_Line (Message);
  Ada.Text_IO.Flush;
  Output.Release;
   end Put_Line;

   protected body Output is
  entry Wait when Available is
  begin
 Available := False;
  end Wait;
  procedure Release is
  begin
 Available := True;
  end Release;
   end Output;
end Report;

[Bug c++/39164] [C++0x] defaulted dtor redefinition not caught

2011-10-03 Thread jason at gcc dot gnu.org

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-10-03
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug c++/50594] Option -fwhole-program discards replaced new operator for std::string

2011-10-03 Thread z0sh at sogetthis dot com

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

--- Comment #13 from Kerrek SB  2011-10-03 16:12:28 
UTC ---
Very interesting. I understand that making the function static makes the
program ill-formed, but it's still somewhat surprising that a compiler flag
should turn a perfectly valid program into an invalid one.

Perhaps adding those visibility specifiers to the  header would be a good
idea, since it'd be a pure-library solution.

Thanks in any case for clarifying this!

[Bug lto/50601] New: [4.7 Regression] New LTO failures

2011-10-03 Thread hjl.tools at gmail dot com

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

 Bug #: 50601
   Summary: [4.7 Regression] New LTO failures
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86-64, revision 179424 gave

FAIL: g++.dg/lto/20100302 cp_lto_20100302_0.o-cp_lto_20100302_1.o link, -flto
-fabi-version=2 (internal compiler error)
FAIL: gcc.dg/lto/pr47259 c_lto_pr47259_0.o-c_lto_pr47259_1.o link,  -O2 -flto
-w 

Revision 179421 is OK.

[Bug tree-optimization/50602] New: ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

2011-10-03 Thread andi-gcc at firstfloor dot org

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

 Bug #: 50602
   Summary: ICE in tree_nrv, at tree-nrv.c:155 during large LTO
build
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: andi-...@firstfloor.org


I get this at the end of a large 32bit LTO build. Cannot give you a small test
case unless you want the full builddir. Bisect is difficult because
the build relies on some recent other fixes.

But I have a core file:

#6  0x00b47eb4 in fancy_abort (file=Unhandled dwarf expression opcode
0xf3
) at ../../gcc/gcc/diagnostic.c:893
#7  0x0075ac05 in tree_nrv () at ../../gcc/gcc/tree-nrv.c:155
#8  0x0068d7ab in execute_one_pass (pass=0x10a9ac0) at
../../gcc/gcc/passes.c:2064
#9  0x0068dae5 in execute_pass_list (pass=0x10a9ac0) at
../../gcc/gcc/passes.c:2119
#10 0x0075df39 in tree_rest_of_compilation (fndecl=0x2b84d3ea6900) at
../../gcc/gcc/tree-optimize.c:420
#11 0x0051ad36 in cgraph_expand_function (node=0x2b84e28a7360) at
../../gcc/gcc/cgraphunit.c:1805
#12 0x0051c612 in cgraph_output_in_order () at
../../gcc/gcc/cgraphunit.c:1962
#13 cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:2136
#14 0x004cb7c5 in lto_main () at ../../gcc/gcc/lto/lto.c:2872


...

#7  0x0075ac05 in tree_nrv () at ../../gcc/gcc/tree-nrv.c:155
155 gcc_assert (ret_val == result);

(gdb) p ret_val
$3 = (tree_node *) 0x0

(gdb) pt result
type = union tree_node {
tree_base base;
tree_typed typed;
tree_common common;
tree_int_cst int_cst;
tree_real_cst real_cst;
tree_fixed_cst fixed_cst;
tree_vector vector;
tree_string string;
tree_complex complex;
tree_identifier identifier;
tree_decl_minimal decl_minimal;
tree_decl_common decl_common;
tree_decl_with_rtl decl_with_rtl;
tree_decl_non_common decl_non_common;
tree_parm_decl parm_decl;
tree_decl_with_vis decl_with_vis;
tree_var_decl var_decl;
tree_field_decl field_decl;
tree_label_decl label_decl;
tree_result_decl result_decl;
tree_const_decl const_decl;
tree_type_decl type_decl;
tree_function_decl function_decl;
tree_translation_unit_decl translation_unit_decl;
tree_type_common type_common;
tree_type_with_lang_specific type_with_lang_specific;
tree_type_non_common type_non_common;
tree_list list;
tree_vec vec;
tree_exp exp;
tree_ssa_name ssa_name;
tree_block block;
tree_binfo binfo;
tree_statement_list stmt_list;
tree_constructor constructor;
tree_omp_clause omp_clause;
tree_optimization_option optimization;
tree_target_option target_option;
} *

[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

2011-10-03 Thread andi-gcc at firstfloor dot org

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

Andi Kleen  changed:

   What|Removed |Added

Version|unknown |4.7.0

--- Comment #1 from Andi Kleen  2011-10-03 
16:40:47 UTC ---
Seen with 
gcc version 4.7.0 20111002 (experimental) (GCC)

[Bug lto/50601] [4.7 Regression] New LTO failures

2011-10-03 Thread hjl.tools at gmail dot com

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |4.7.0

--- Comment #1 from H.J. Lu  2011-10-03 16:42:10 
UTC ---
It is caused by revision 179424:

http://gcc.gnu.org/ml/gcc-cvs/2011-10/msg00017.html

[Bug target/50603] New: [x32] Unnecessary lea

2011-10-03 Thread hjl.tools at gmail dot com

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

 Bug #: 50603
   Summary: [x32] Unnecessary lea
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ubiz...@gmail.com


[hjl@gnu-6 ilp32-2]$ cat int.c
extern int *foo;

int bar (int x) { return foo[x]; }
[hjl@gnu-6 ilp32-2]$ make int.s
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -mx32  -O2 int.c
[hjl@gnu-6 ilp32-2]$ cat int.s
.file"int.c"
.text
.p2align 4,,15
.globlbar
.typebar, @function
bar:
.LFB0:
.cfi_startproc
movlfoo(%rip), %eax
leal(%rax,%rdi,4), %edi
movl(%edi), %eax
ret
.cfi_endproc
.LFE0:
.sizebar, .-bar
.ident"GCC: (GNU) 4.7.0 20110923 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 ilp32-2]$ 

We can generate

movlfoo(%rip), %eax
movl(%eax,%edi,4), %eax
ret

[Bug target/49967] The -static-libstdc++ does not work on HP-UX (IA64 B.11.23, probably others)

2011-10-03 Thread sje at gcc dot gnu.org

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

--- Comment #2 from Steve Ellcey  2011-10-03 17:57:44 
UTC ---
Author: sje
Date: Mon Oct  3 17:57:40 2011
New Revision: 179472

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179472
Log:
2011-10-03  Steve Ellcey  

PR target/49967
* configure.ac (gcc_cv_ld_static_dynamic): Define for *-*-hpux*.
(gcc_cv_ld_static_option): Ditto.
(gcc_cv_ld_dynamic_option): Ditto.
* configure: Regenerate.

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

[Bug target/50603] [x32] Unnecessary lea

2011-10-03 Thread ubizjak at gmail dot com

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-10-03
 Ever Confirmed|0   |1

--- Comment #1 from Uros Bizjak  2011-10-03 19:13:02 
UTC ---
This is the same issue as in:

FAIL: gcc.target/i386/pr45670.c scan-assembler-not lea[lq]

We expand to addsi_1 with memory operand:

(insn 7 6 9 2 (parallel [
(set (reg:SI 68)
(plus:SI (reg:SI 69)
(mem/f/c/i:SI (symbol_ref:DI ("foo") [flags 0x40] 
) [2 foo+0 S4 A32])))
(clobber (reg:CC 17 flags))
]) pr50603.c:3 253 {*addsi_1}
 (expr_list:REG_DEAD (reg:SI 69)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil

and then fail at combine with:

Trying 6, 7 -> 9:
Failed to match this instruction:
(set (reg:SI 70 [ *D.3235_5 ])
(mem:SI (zero_extend:DI (plus:SI (mult:SI (reg/v:SI 65 [ x ])
(const_int 4 [0x4]))
(mem/f/c/i:SI (symbol_ref:DI ("foo") [flags 0x40]  ) [2 foo+0 S4 A32]))) [3 *D.3235_5+0 S4 A32]))

[Bug c/50604] New: verify_gimple failed: type mismatch in binary expression

2011-10-03 Thread dimhen at gmail dot com

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

 Bug #: 50604
   Summary: verify_gimple failed: type mismatch in binary
expression
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dim...@gmail.com


$ gcc -O2 -Wall -Wextra -c ./verify_gimple_err.c 
./verify_gimple_err.c: In function '_is_same_atr':
./verify_gimple_err.c:6:6: error: type mismatch in binary expression
ssizetype

size_t

ssizetype

D.3197_15 = D.3184_1 + 20;

./verify_gimple_err.c:6:6: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


$ cat verify_gimple_err.c 
#include 
typedef char TCHAR;
typedef TCHAR TSupSysENickname[0x40 + 1];
extern const TCHAR MEDIA_BASE_PATH[];

void _is_same_atr( )
{
char *ptr;
TSupSysENickname nickname;

ptr = malloc(strlen(nickname));
strcpy( ptr, MEDIA_BASE_PATH );
strcat( ptr, nickname );
strcat( ptr, "/" );
}

const TCHAR MEDIA_BASE_PATH[] = "\\CONFIG\\KeyCarriers\\";


$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/dim/src/gcc-current/configure
--prefix=/usr/local/gcc_current --with-multilib-list=m64 --enable-__cxa_atexit
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=df,rtl,yes --with-system-zlib --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--enable-languages=c,c++,lto --enable-plugin --with-tune=generic
--enable-version-specific-runtime-libs
Thread model: posix
gcc version 4.7.0 20111003 (experimental) [trunk revision 179472] (GCC)

[Bug middle-end/50604] [4.7 Regression] verify_gimple failed: type mismatch in binary expression

2011-10-03 Thread pinskia at gcc dot gnu.org

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0
Summary|[4.7.0] verify_gimple   |[4.7 Regression]
   |failed: type mismatch in|verify_gimple failed: type
   |binary expression   |mismatch in binary
   ||expression

[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2

2011-10-03 Thread mikpe at it dot uu.se

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

--- Comment #13 from Mikael Pettersson  2011-10-03 
19:27:21 UTC ---
Created attachment 25404
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25404
reduced preprocessed test case

With this reduced test case I'm seeing gcc-4.6 ifcvt hoisting trapping insns
that depend on a NULL pointer check before that pointer check when
-mtune=athlon is in effect.

> cat pr50588.c
unsigned int __attribute__((noinline,noclone)) do_try(int *fd)
{
unsigned int bits[32];

bits[0] = 0;
asm("" : "=m"(bits) : "r"(bits) : "memory");

bits[(fd ? *fd : -1) / 32U] |= 1U << ((fd ? *fd : -1) % 32U);

return bits[0];
}

int main(void)
{
int fd = 3;
if (do_try(&fd) != (1U << 3))
__builtin_abort();
return 0;
}
> /tmp/objdir46/gcc/xgcc -B/tmp/objdir46/gcc/ -O2 -S pr50588.c ; cat pr50588.s
.file   "pr50588.c"
.text
.p2align 4,,15
.globl  do_try
.type   do_try, @function
do_try:
.LFB0:
.cfi_startproc
pushl   %ebx
.cfi_def_cfa_offset 8
.cfi_offset 3, -8
addl$-128, %esp
.cfi_def_cfa_offset 136
movl136(%esp), %eax
movl$0, (%esp)
testl   %eax, %eax
je  .L2

## This is OK, we're testing fd (eax) before doing anything that depends on its
value.

movl(%eax), %ecx
movl$1, %eax
movl%ecx, %edx
shrl$5, %edx
movl(%esp,%edx,4), %ebx
sall%cl, %eax
orl %ebx, %eax
movl%eax, (%esp,%edx,4)
movl(%esp), %eax
subl$-128, %esp
.cfi_remember_state
.cfi_def_cfa_offset 8
popl%ebx
.cfi_def_cfa_offset 4
.cfi_restore 3
ret
.p2align 4,,7
.p2align 3
.L2:
.cfi_restore_state
movl536870908(%esp), %ebx

### This would obviously fail at runtime, but as fd != NULL it won't be
executed.

movl$-2147483648, %eax
movl$134217727, %edx
orl %ebx, %eax
movl%eax, (%esp,%edx,4)
movl(%esp), %eax
...
> /tmp/objdir46/gcc/xgcc -B/tmp/objdir46/gcc/ -mtune=athlon -O2 -S pr50588.c ; 
> cat pr50588.s
.file   "pr50588.c"
.text
.p2align 4,,15
.globl  do_try
.type   do_try, @function
do_try:
.LFB0:
.cfi_startproc
pushl   %ebx
.cfi_def_cfa_offset 8
.cfi_offset 3, -8
movl$134217727, %edx
movl$-2147483648, %eax
addl$-128, %esp
.cfi_def_cfa_offset 136
movl136(%esp), %ecx
movl$0, (%esp)
movl536870908(%esp), %ebx

## This is broken.  Trapping insns from the fd == NULL case have been hoisted
above the fd == NULL check.  The movl above does segfault at runtime.

testl   %ecx, %ecx
je  .L3
movl(%ecx), %ecx
movl$1, %eax
movl%ecx, %edx
sall%cl, %eax
shrl$5, %edx
movl(%esp,%edx,4), %ebx
.L3:
orl %ebx, %eax
movl%eax, (%esp,%edx,4)
movl(%esp), %eax
subl$-128, %esp
.cfi_def_cfa_offset 8
popl%ebx
.cfi_def_cfa_offset 4
.cfi_restore 3
ret
.cfi_endproc

[Bug other/50283] [4.7 Regression] FAIL: g++.dg/eh/simd-1.C execution test

2011-10-03 Thread danglin at gcc dot gnu.org

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

--- Comment #3 from John David Anglin  2011-10-03 
19:43:40 UTC ---
Created attachment 25405
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25405
.final dump

[Bug fortran/35831] [F95] Shape mismatch check missing for dummy procedure argument

2011-10-03 Thread janus at gcc dot gnu.org

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug c++/50357] verify_cgraph_node failed with -O2

2011-10-03 Thread dcb314 at hotmail dot com

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

--- Comment #1 from dcb  2011-10-03 20:23:46 UTC ---
Seems fixed in gcc snapshot 20111001

[Bug c++/50357] verify_cgraph_node failed with -O2

2011-10-03 Thread dcb314 at hotmail dot com

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

dcb  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from dcb  2011-10-03 20:24:24 UTC ---
Seems fixed to me.

[Bug c++/50605] New: ice in ipa_get_jf_pass_through_result with -O3

2011-10-03 Thread dcb314 at hotmail dot com

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

 Bug #: 50605
   Summary: ice in ipa_get_jf_pass_through_result with -O3
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dcb...@hotmail.com


Created attachment 25406
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25406
C++ source code

I just tried to compile the package armacycles-ad-0.2.8.3.1 with the
latest trunk snapshot 20111001 on an AMD x86_64 box.

The compiler said

/home/dcb/rpmbuild/BUILD/armagetronad-0.2.8.3.1/bindist/../src/tools/tRecorderInternal.cpp:311:46:
internal compiler error: in ipa_get_jf_pass_through_result, at ipa-cp.c:641
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Preprocessed source code attached. Flag -O3 required.

[Bug c/50606] New: gcc fails to detect obvious use of NULL pointer

2011-10-03 Thread dcb314 at hotmail dot com

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

 Bug #: 50606
   Summary: gcc fails to detect obvious use of NULL pointer
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dcb...@hotmail.com


I just tried the following C code on latest trunk snapshot 20111001 on
an AMD x86_64 box.

# include 

void f( const char * p)
{
if (p == 0)
printf( "Hello world %s\n", p);
}

The compiler said nothing at all, which was a bit surprising.

$ ../results/bin/gcc -g -O2 -Wall -Wextra -pedantic -c bug34.c
$

OK, gcc isn't clairvoyant, but a little bit of NULL pointer tracking
might be useful, to print out a useful warning message or two.

[Bug target/50603] [x32] Unnecessary lea

2011-10-03 Thread hjl.tools at gmail dot com

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |UNCONFIRMED
 Ever Confirmed|1   |0

--- Comment #2 from H.J. Lu  2011-10-03 20:57:53 
UTC ---
I am testing this patch:

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 7e89dbd..612fcd2 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -15713,6 +15713,16 @@ ix86_fixup_binary_operands (enum rtx_code code, enum
ma
chine_mode mode,
   else
 src2 = force_reg (mode, src2);
 }
+  else
+{
+  /* Improve address combine in x32 mode.  */
+  if (TARGET_X32
+  && code == PLUS
+  && !MEM_P (dst)
+  && !MEM_P (src1)
+  && MEM_P (src2) )
+src2 = force_reg (mode, src2);
+}

   /* If the destination is memory, and we do not have matching source
  operands, do things in registers.  */

[Bug middle-end/50607] [4.7 Regression] FAIL: gcc.dg/bconstp-3.c

2011-10-03 Thread hp at gcc dot gnu.org

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

--- Comment #1 from Hans-Peter Nilsson  2011-10-03 
23:09:44 UTC ---
For cris-elf too (unsurprisingly as the error seems universal), plus I'm seeing
a:

FAIL: gcc.c-torture/execute/pr23135.c compilation,  -O2 -flto  (internal
compiler error)

gcc.log:
Executing on host: /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/xgcc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/pr23135.c   -w 
-O2 -flto -flto-partition=none-isystem
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem
/tmp/hpautotest-gcc1/gcc/newlib/libc/include
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris/
-L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris
-L/tmp/hpautotest-gcc1/gcc/libgloss/cris 
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/
-L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib -sim3  -lm   -o
/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/testsuite/gcc/pr23135.x6(timeout =
300)
In file included from :0:0:
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/pr23135.c: In
function 'main':
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/pr23135.c:31:1:
internal compiler error: Segmentation fault

(No SIMD thingies on this target; the test-case is vector-related so badness in
the generic-vector machinery.)

[Bug middle-end/50607] New: [4.7 Regression] FAIL: gcc.dg/bconstp-3.c

2011-10-03 Thread hjl.tools at gmail dot com

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

 Bug #: 50607
   Summary: [4.7 Regression] FAIL: gcc.dg/bconstp-3.c
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: artyom.shinkar...@gmail.com


On Linux/x86, revision 179463 gave

FAIL: gcc.dg/bconstp-3.c (test for excess errors)

Revision 179447 was OK.  I got

Executing on host: /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/
/export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/bconstp-3.c -ansi
-pedantic-errors -S  -o bconstp-3.s(timeout = 300)
spawn -ignore SIGHUP /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/
/export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/bconstp-3.c -ansi
-pedantic-errors -S -o bconstp-3.s^M
/export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/bconstp-3.c:23:3: error:
initializer element is not a constant expression^M
/export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/bconstp-3.c:23:3: error: (near
initialization for 'tests[4]')^M
/export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/bconstp-3.c:24:3: error:
initializer element is not a constant expression^M
/export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/bconstp-3.c:24:3: error: (near
initialization for 'tests[5]')^M
...

It is caused by revision 179462:

http://gcc.gnu.org/ml/gcc-cvs/2011-10/msg00055.html

[Bug middle-end/50607] [4.7 Regression] FAIL: gcc.dg/bconstp-3.c

2011-10-03 Thread artyom.shinkaroff at gmail dot com

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

--- Comment #2 from Artem Shinkarov  
2011-10-03 23:17:22 UTC ---
That seems to be the changes caused by the patch I have committed. However, may
be this is a test-case that needs adjustment. 

I'll have to consult with Joseph. He asked to change the behavior of both
functions.

[Bug middle-end/50607] [4.7 Regression] FAIL: gcc.dg/bconstp-3.c

2011-10-03 Thread artyom.shinkaroff at gmail dot com

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

--- Comment #3 from Artem Shinkarov  
2011-10-03 23:32:47 UTC ---
(In reply to comment #1)
> For cris-elf too (unsurprisingly as the error seems universal), plus I'm 
> seeing
> a:
> 
> FAIL: gcc.c-torture/execute/pr23135.c compilation,  -O2 -flto  (internal
> compiler error)

This is very unlikely that my patch caused this. The testcase as I can see uses
8-byte vectors and standard arithmetic operations. My patch introduces vector
shuffling on 16-byte vectors. The way the operations from pr23135.c are
performed didn't change.

On x86 linux the testcase does not cause segfaults, so may be you could
investigate via gdb which function cause segfault on cris-elf.


Thanks,
Artem.

[Bug c++/50608] New: cannot apply 'offsetof' to a non constant address

2011-10-03 Thread dberger at oubliette dot org

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

 Bug #: 50608
   Summary: cannot apply 'offsetof' to a non constant address
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dber...@oubliette.org


$ cat repro.ii

struct A {
int offset;
};

struct B: public A {
};

struct C {
A a;
B b;
};

/* error: cannot apply 'offsetof' to a non constant address */
int fails = __builtin_offsetof (C, b.offset);

int works = (int)(&(((C*)0)->b.offset));

$

looks like a dup of Bug 13648, which claims to be fixed.

[Bug c++/50608] cannot apply 'offsetof' to a non constant address

2011-10-03 Thread dberger at oubliette dot org

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

Dan Berger  changed:

   What|Removed |Added

   See Also||http://gcc.gnu.org/bugzilla
   ||/show_bug.cgi?id=13648

--- Comment #1 from Dan Berger  2011-10-03 
23:42:32 UTC ---
Oh, I should say, this code compiles with 4.5.3.

[Bug middle-end/50609] New: [4.7 Regression] FAIL: gcc.c-torture/execute/pr23135.c compilation, -O2 -flto (ICE)

2011-10-03 Thread hp at gcc dot gnu.org

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

 Bug #: 50609
   Summary: [4.7 Regression] FAIL: gcc.c-torture/execute/pr23135.c
compilation,  -O2 -flto (ICE)
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: h...@gcc.gnu.org
CC: artyom.shinkar...@gmail.com, hjl.to...@gmail.com,
h...@gcc.gnu.org
Depends on: 50607


+++ This bug was initially created as a clone of Bug #50607 +++

See PR50607#c1.

The SEGV happens in lto1. Here's a gdb backtrace (N.B. optimized code on a
x86_64 host) running lto1 with "-melf -quiet -dumpdir
/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/testsuite/gcc/ -dumpbase pr23135.x6
-auxbase-strip /tmp/ccSn7Zx5.lto.o -O2 -w -version -flto-partition=none
-fresolution=pr23135.res pr23135.o -o pr23135.s":

(gdb) r   
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/lto1 -melf -quiet
-dumpdir /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/testsuite/gcc/ -dumpbase
pr23135.x6 -auxbase-strip /tmp/ccSn7Zx5.lto.o -O2 -w -version
-flto-partition=none -fresolution=pr23135.res pr23135.o -o pr23135.s
GNU GIMPLE (GCC) version 4.7.0 20111003 (experimental) [trunk revision 179480]
(cris-elf)
compiled by GNU C version 4.4.3 20100127 (Red Hat 4.4.3-4), GMP version
4.3.0, MPFR version 2.4.1, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 4.7.0 20111003 (experimental) [trunk revision 179480]
(cris-elf)
compiled by GNU C version 4.4.3 20100127 (Red Hat 4.4.3-4), GMP version
4.3.0, MPFR version 2.4.1, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

Program received signal SIGSEGV, Segmentation fault.
fold_nonarray_ctor_reference (type=, ctor=, offset=, 
size=32) at /tmp/hpautotest-gcc1/gcc/gcc/gimple-fold.c:2834
2834  tree byte_offset = DECL_FIELD_OFFSET (cfield);
(gdb) bt
#0  fold_nonarray_ctor_reference (type=, ctor=, 
offset=, size=32) at
/tmp/hpautotest-gcc1/gcc/gcc/gimple-fold.c:2834
#1  fold_ctor_reference (type=, ctor=, offset=, size=32)
at /tmp/hpautotest-gcc1/gcc/gcc/gimple-fold.c:2923
#2  0x0062225c in fold_const_aggregate_ref_1 (t=0x77f7ca10,
valueize=0)
at /tmp/hpautotest-gcc1/gcc/gcc/gimple-fold.c:3017
#3  0x00627c10 in maybe_fold_reference (expr=0x77f7ca10, is_lhs=0
'\000')
at /tmp/hpautotest-gcc1/gcc/gcc/gimple-fold.c:232
#4  0x006292c1 in fold_stmt_1 (gsi=0x7fffdb00, inplace=0 '\000')
at /tmp/hpautotest-gcc1/gcc/gcc/gimple-fold.c:1168
#5  0x00833b1a in optimize_stmt (bb=0x77f85478, si=...) at
/tmp/hpautotest-gcc1/gcc/gcc/tree-ssa-dom.c:2133
#6  0x008347ad in dom_opt_enter_block (walk_data=,
bb=0x77f85478)
at /tmp/hpautotest-gcc1/gcc/gcc/tree-ssa-dom.c:1686
#7  0x009d7228 in walk_dominator_tree (walk_data=0x7fffdc50,
bb=0x77f85478)
at /tmp/hpautotest-gcc1/gcc/gcc/domwalk.c:188
#8  0x0082ed7d in tree_ssa_dominator_optimize () at
/tmp/hpautotest-gcc1/gcc/gcc/tree-ssa-dom.c:709
#9  0x006f5f82 in execute_one_pass (pass=0xee6160) at
/tmp/hpautotest-gcc1/gcc/gcc/passes.c:2064
#10 0x006f6295 in execute_pass_list (pass=0xee6160) at
/tmp/hpautotest-gcc1/gcc/gcc/passes.c:2119
#11 0x006f62a7 in execute_pass_list (pass=0xe606e0) at
/tmp/hpautotest-gcc1/gcc/gcc/passes.c:2120
#12 0x007d92f8 in tree_rest_of_compilation (fndecl=0x77f74800)
at /tmp/hpautotest-gcc1/gcc/gcc/tree-optimize.c:420
#13 0x004e836e in cgraph_expand_function (node=0x77f7f120)
at /tmp/hpautotest-gcc1/gcc/gcc/cgraphunit.c:1805
#14 0x004eb72a in cgraph_expand_all_functions () at
/tmp/hpautotest-gcc1/gcc/gcc/cgraphunit.c:1864
#15 cgraph_optimize () at /tmp/hpautotest-gcc1/gcc/gcc/cgraphunit.c:2141
#16 0x00475344 in lto_main () at
/tmp/hpautotest-gcc1/gcc/gcc/lto/lto.c:2868
#17 0x007776a1 in compile_file () at
/tmp/hpautotest-gcc1/gcc/gcc/toplev.c:565
#18 do_compile () at /tmp/hpautotest-gcc1/gcc/gcc/toplev.c:1925
#19 0x00778212 in toplev_main (argc=17, argv=0x7fffe008) at
/tmp/hpautotest-gcc1/gcc/gcc/toplev.c:2001
#20 0x0037d421eb1d in __libc_start_main () from /lib64/libc.so.6
#21 0x00459959 in _start ()

I'll re-run that with all *.o rebuilt with "-O0 -g3".

[Bug middle-end/50607] [4.7 Regression] FAIL: gcc.dg/bconstp-3.c

2011-10-03 Thread hp at gcc dot gnu.org

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

--- Comment #4 from Hans-Peter Nilsson  2011-10-04 
00:04:54 UTC ---
(In reply to comment #3)
> On x86 linux the testcase does not cause segfaults, so may be you could
> investigate via gdb which function cause segfault on cris-elf.

I cloned this PR, see PR50609.

[Bug middle-end/50609] [4.7 Regression] FAIL: gcc.c-torture/execute/pr23135.c compilation, -O2 -flto (ICE)

2011-10-03 Thread hp at gcc dot gnu.org

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

--- Comment #1 from Hans-Peter Nilsson  2011-10-04 
00:22:11 UTC ---
Last known working revision:first known failing 179447:179464, and 179462 is
the only related change in that range, so it's confirmed that's the revision
exposing or causing this regression.

[Bug middle-end/50609] [4.7 Regression] FAIL: gcc.c-torture/execute/pr23135.c compilation, -O2 -flto (ICE)

2011-10-03 Thread hp at gcc dot gnu.org

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

--- Comment #2 from Hans-Peter Nilsson  2011-10-04 
01:50:59 UTC ---
So, at r179480, I get, for lto1 and everything related rebuilt with CFLAGS=-g3:

(gdb) set args -melf -quiet -dumpdir
/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/testsuite/gcc/ -dumpbase pr23135.x6
-auxbase-strip /tmp/ccJhtPAy.lto.o -O2 -w -version -flto-partition=none
-fresolution=pr23135.res pr23135.o  -o pr23135.s
(gdb) r
Starting program: /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/lto1 -melf -quiet
-dumpdir /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/testsuite/gcc/ -dumpbase
pr23135.x6 -auxbase-strip /tmp/ccJhtPAy.lto.o -O2 -w -version
-flto-partition=none -fresolution=pr23135.res pr23135.o  -o pr23135.s
GNU GIMPLE (GCC) version 4.7.0 20111003 (experimental) [trunk revision 179480]
(cris-elf)
compiled by GNU C version 4.4.3 20100127 (Red Hat 4.4.3-4), GMP version
4.3.0, MPFR version 2.4.1, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 4.7.0 20111003 (experimental) [trunk revision 179480]
(cris-elf)
compiled by GNU C version 4.4.3 20100127 (Red Hat 4.4.3-4), GMP version
4.3.0, MPFR version 2.4.1, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

Program received signal SIGSEGV, Segmentation fault.
0x0078bae8 in fold_nonarray_ctor_reference (type=0x77ece5e8,
ctor=0x77f8dab0, offset=0, size=32)
at /tmp/hpautotest-gcc1/gcc/gcc/gimple-fold.c:2834
2834  tree byte_offset = DECL_FIELD_OFFSET (cfield);
Missing separate debuginfos, use: debuginfo-install glibc-2.11.1-1.x86_64
(gdb) p cfield
$1 = (tree) 0x0
(gdb) bt
#0  0x0078bae8 in fold_nonarray_ctor_reference (type=0x77ece5e8,
ctor=0x77f8dab0, offset=0, size=32)
at /tmp/hpautotest-gcc1/gcc/gcc/gimple-fold.c:2834
#1  0x0078c93d in fold_ctor_reference (type=0x77ece5e8,
ctor=0x77f8dab0, offset=0, size=32)
at /tmp/hpautotest-gcc1/gcc/gcc/gimple-fold.c:2923
#2  0x0078d210 in fold_const_aggregate_ref_1 (t=0x77f7ca10,
valueize=0)
at /tmp/hpautotest-gcc1/gcc/gcc/gimple-fold.c:3017
#3  0x0078d3dd in fold_const_aggregate_ref (t=0x77f7ca10)
at /tmp/hpautotest-gcc1/gcc/gcc/gimple-fold.c:3039
#4  0x0077e0ef in maybe_fold_reference (expr=0x77f7ca10, is_lhs=0
'\000')
at /tmp/hpautotest-gcc1/gcc/gcc/gimple-fold.c:232
#5  0x0077 in fold_gimple_assign (si=0x7fffdac0) at
/tmp/hpautotest-gcc1/gcc/gcc/gimple-fold.c:298
#6  0x00783a3e in fold_stmt_1 (gsi=0x7fffdac0, inplace=0 '\000')
at /tmp/hpautotest-gcc1/gcc/gcc/gimple-fold.c:1168
#7  0x007843cc in fold_stmt (gsi=0x7fffdac0) at
/tmp/hpautotest-gcc1/gcc/gcc/gimple-fold.c:1304
#8  0x00af258f in optimize_stmt (bb=0x77f85478, si=...) at
/tmp/hpautotest-gcc1/gcc/gcc/tree-ssa-dom.c:2133
#9  0x00af1254 in dom_opt_enter_block (walk_data=0x7fffdc70,
bb=0x77f85478)
at /tmp/hpautotest-gcc1/gcc/gcc/tree-ssa-dom.c:1686
#10 0x00d97b8c in walk_dominator_tree (walk_data=0x7fffdc70,
bb=0x77f85478)
at /tmp/hpautotest-gcc1/gcc/gcc/domwalk.c:188
#11 0x00aec22b in tree_ssa_dominator_optimize () at
/tmp/hpautotest-gcc1/gcc/gcc/tree-ssa-dom.c:709
#12 0x008dabbb in execute_one_pass (pass=0x1377160) at
/tmp/hpautotest-gcc1/gcc/gcc/passes.c:2064
#13 0x008dada9 in execute_pass_list (pass=0x1377160) at
/tmp/hpautotest-gcc1/gcc/gcc/passes.c:2119
#14 0x008dadca in execute_pass_list (pass=0x12f0ba0) at
/tmp/hpautotest-gcc1/gcc/gcc/passes.c:2120
#15 0x00a56d01 in tree_rest_of_compilation (fndecl=0x77f74800)
at /tmp/hpautotest-gcc1/gcc/gcc/tree-optimize.c:420
#16 0x00557390 in cgraph_expand_function (node=0x77f7f120)
at /tmp/hpautotest-gcc1/gcc/gcc/cgraphunit.c:1805
#17 0x0055754f in cgraph_expand_all_functions () at
/tmp/hpautotest-gcc1/gcc/gcc/cgraphunit.c:1864
#18 0x00557ca1 in cgraph_optimize () at
/tmp/hpautotest-gcc1/gcc/gcc/cgraphunit.c:2141
#19 0x0048e19a in lto_main () at
/tmp/hpautotest-gcc1/gcc/gcc/lto/lto.c:2868
#20 0x009b0ca9 in compile_file () at
/tmp/hpautotest-gcc1/gcc/gcc/toplev.c:565
#21 0x009b2fa3 in do_compile () at
/tmp/hpautotest-gcc1/gcc/gcc/toplev.c:1925
#22 0x009b311a in toplev_main (argc=17, argv=0x7fffe008) at
/tmp/hpautotest-gcc1/gcc/gcc/toplev.c:2001
#23 0x00490f90 in main (argc=17, argv=0x7fffe008) at
/tmp/hpautotest-gcc1/gcc/gcc/main.c:36

HTH!

[Bug middle-end/50609] [4.7 Regression] FAIL: gcc.c-torture/execute/pr23135.c compilation, -O2 -flto (ICE)

2011-10-03 Thread hp at gcc dot gnu.org

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Target||cris-axis-elf
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-10-04
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

[Bug other/50610] New: G++ 4.4.3: Incorrect code at -O2 (-fwrapv, SafeInt, c++ templates, template class files)

2011-10-03 Thread noloader at gmail dot com

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

 Bug #: 50610
   Summary: G++ 4.4.3: Incorrect code at -O2 (-fwrapv, SafeInt,
c++ templates, template class files)
Classification: Unclassified
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: noloa...@gmail.com


Created attachment 25407
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25407
Test case for bad code generation at -O2

Attached is a test program which uses a secure vector. The secure vector 'has
a' standard vector, and attempts to do a few extra things to help ensure safe
use (such as check for pointer wrap and zeroization). In addition, the secure
vector uses LeBlanc's SafeInt class to check for wraps and overflows. (SafeInt
uses unsigned, so no undefined behavior should be present).

The test program incorrectly rejects a valid input:

$ g++ -g -O2 -fwrapv -I. TestMain.cpp SecureArray.cpp -o TestMain.exe
$ ./TestMain.exe
Array pointer wrap
$

TestMain is as follows:

  try
  {
const int arr[] = { 1, 1, 1, 1 };
SecureIntArray vv(arr, COUNTOF(arr));
assert(vv.size() == 4);
  }
  catch(const std::exception& ex)
  {
cerr << ex.what() << endl;
  }

The SecureIntArray ctor calls into a helper function:

  template 
  typename SecureArray::SecureVector*
  SecureArray::create_secure_array(const T* ptr, size_t cnt)
  {
try
{
  const size_t base = (size_t)ptr;
  SafeInt si(cnt);
  si *= sizeof(T);
  si += base;
}
catch(const SafeIntException&)
{
  throw InvalidArgumentException("Array pointer wrap");
}

return new SecureVector(ptr /*first*/, ptr+cnt /*last*/);
  }

*If* I manually check for overflow (ie, no SafeInt use), I get expected
results:
$ g++ -g -O2 -DSECURE_ARRAY_NO_SAFE_INT=1 -I. TestMain.cpp SecureArray.cpp -o
TestMain.exe
$ ./TestMain.exe
$ 

Defining SECURE_ARRAY_NO_SAFE_INT uses the following rather than SafeInt
objects:

const size_t b = (size_t)ptr;
size_t p = cnt * sizeof(T) + b;
if(!(p >= b))
  throw InvalidArgumentException("Array pointer wrap");

Finally, the issue is not present on other versions of GCC. Other versions
include 4.5 from F14 and 4.6 from F15.

I was not able to reduce the test program to something smaller (though I
tried). For example, I know the following will not help the problem: removing
namespaces, removing throws, removing explicit template instantiations, moving
bodies into the header, and a few other items.

I do know that removing everything except the ctor, size(), max_size(), and
operator[] will fix it, but it does not help with a minimum test case.

[Bug other/50610] G++ 4.4.3: Incorrect code at -O2 (-fwrapv, SafeInt, c++ templates, template class files)

2011-10-03 Thread noloader at gmail dot com

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

--- Comment #1 from Jeffrey Walton  2011-10-04 
04:07:17 UTC ---
My bad:

jeffrey@studio:~/Desktop/safeint-opt-test$ gcc --version
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

jeffrey@studio:~/Desktop/safeint-opt-test$ uname -a
Linux studio 2.6.32-34-generic #77-Ubuntu SMP Tue Sep 13 19:39:17 UTC 2011
x86_64 GNU/Linux
jeffrey@studio:~/Desktop/safeint-opt-test$

[Bug other/50610] G++ 4.4.3: Incorrect code at -O2 (-fwrapv, SafeInt, c++ templates, template class files)

2011-10-03 Thread noloader at gmail dot com

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

--- Comment #2 from Jeffrey Walton  2011-10-04 
05:24:20 UTC ---
For this problem, the work around was:

   try
   {
 const T* base = ptr;
 base += SafeInt(cnt);
   }
   catch(const SafeIntException&)
   {
 throw InvalidArgumentException("Array pointer wrap");
   }

It seems LeBlanc had it all the time, but I was not using it. My apologies.

67 matches

Mail list logo