[Bug tree-optimization/55281] [4.8 Regression] ICE in build_int_cst_wide, at tree.c:1217 (with Ofast, ok with O3)

2012-11-13 Thread vincenzo.innocente at cern dot ch


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



--- Comment #10 from vincenzo Innocente vincenzo.innocente at cern dot ch 
2012-11-13 08:04:35 UTC ---

confirmed fixed in

gcc version 4.8.0 20121113 (experimental) [trunk revision 193471] (GCC)


[Bug bootstrap/55293] bootstrap failure: invalid conversion from 'char**' to 'const char**' [-fpermissive]

2012-11-13 Thread ebotcazou at gcc dot gnu.org


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



Eric Botcazou ebotcazou at gcc dot gnu.org changed:



   What|Removed |Added



  Component|c   |bootstrap



--- Comment #13 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-13 
08:06:54 UTC ---

 I have gcc 4.7.2 bootstrapping on a few Solaris 8 servers, flawlessly. 

 At least thus far. Every attempt and incantation of attempts on Solaris 10,

 within or without the documented approach has failed. So, go easy on me. 

 I have in fact, done this before. Just never on Solaris 10.



Solaris 10 has been there for almost a decade so people have bootstrapped GCC

on it for almost as long.  That's essentially the same as with previous

releases.



And, please, stop changing back the Component of the PR, that's pretty

annoying.


[Bug target/54791] AIX-only: Constructors are not called in main program.

2012-11-13 Thread adivilceanu at yahoo dot com


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



--- Comment #20 from Adi adivilceanu at yahoo dot com 2012-11-13 08:21:12 UTC 
---

Created attachment 28672

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28672

the error while building gcc



the error while building gcc 4.7.2


[Bug target/54791] AIX-only: Constructors are not called in main program.

2012-11-13 Thread adivilceanu at yahoo dot com


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



--- Comment #21 from Adi adivilceanu at yahoo dot com 2012-11-13 08:29:51 UTC 
---

I am trying to build gcc 4.7.2 in order to apply the patch you suggested.

I did the following:

-download the gcc 4.7.2

-unzip and untar to to the root directory.

mkdir /gcc-build

cd /gcc-build

../gcc-4.7.2/configure --enable-languages=c,c++

make



When making I get the errors from the attachment I put on Comment 20.



I am using:

AIX (oslevel -s = 6100-06-09-1228)

make-3.80-1

mpfr-3.1.0-1

libmpc-0.9-1

mpfr-devel-3.1.1-1

gmp-5.0.5-1

gmp-devel-5.0.5-1

libmpc-devel-1.0.1-2



Do you know why I am getting this ?


[Bug c++/55287] GCC crashes and asks to file bug report

2012-11-13 Thread gordoncichon at gmail dot com


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



--- Comment #4 from Gordon Cichon gordoncichon at gmail dot com 2012-11-13 
08:33:01 UTC ---

Why is GCC comsuming so much memory?



The program has 6.4MB source code, it is a single function. All optimizations

are turned off. And there is 2GB memory in the system.



Well, shouldn't it be possible to compile this program?


[Bug target/54429] [SH] SImode values get ferried through FPUL and FP regs for -O0

2012-11-13 Thread olegendo at gcc dot gnu.org


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



--- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org 2012-11-13 08:44:43 
UTC ---

I've tested this:



Index: gcc/config/sh/sh.c

===

--- gcc/config/sh/sh.c(revision 193423)

+++ gcc/config/sh/sh.c(working copy)

@@ -12113,6 +12113,11 @@

   if (FP_REGISTER_P (regno)  mode == SFmode)

 return true;



+  if (FP_REGISTER_P (regno)

+   !(GET_MODE_CLASS (mode) == MODE_FLOAT

+   || GET_MODE_CLASS (mode) == MODE_VECTOR_FLOAT))

+return false;

+

   if (mode == V2SFmode)

 {

   if (((FP_REGISTER_P (regno)  (regno - FIRST_FP_REG) % 2 == 0)





on rev 193423.  There are a few failures on targets with HW FPU:



FAIL: gcc.c-torture/execute/20080502-1.c compilation

FAIL: gcc.c-torture/execute/ieee/copysign1.c compilation

FAIL: gcc.dg/builtins-32.c (internal compiler error)

FAIL: gcc.dg/builtins-50.c (internal compiler error)

FAIL: gcc.dg/pr48335-7.c (internal compiler error)



I'll check out the details.


[Bug libstdc++/55308] New: /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol __emutls_v._ThreadRuneLocale

2012-11-13 Thread mexas at bristol dot ac.uk


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



 Bug #: 55308

   Summary: /usr/ports/lang/gcc48/work/build/sparc64-portbld-freeb

sd10.0/libstdc++-v3/src/.libs/libstdc++.so.6:

Undefined symbol __emutls_v._ThreadRuneLocale

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libstdc++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: me...@bristol.ac.uk





FreeBSD 10.0-CURRENT #9 r239940 sparc64



Building gcc48



/bin/sh ../.././../gcc-4.8-20121014/libgcc/../mkinstalldirs 

/usr/ports/lang/gcc48/work/build/./gcc/xgcc

-B/usr/ports/lang/gcc48/work/build/./gcc/

-B/usr/local/sparc64-portbld-freebsd10.0/bin/

-B/usr/local/sparc64-portbld-freebsd10.0/lib/ -isystem

/usr/local/sparc64-portbld-freebsd10.0/include -isystem

/usr/local/sparc64-portbld-freebsd10.0/sys-include-O2  -g -O2 -pipe

-I/usr/local/include -fno-strict-aliasing -DIN_GCC   -W -Wall -Wwrite-strings

-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 

-isystem ./include   -fPIC -pthread -g -DIN_LIBGCC2 -fbuilding-libgcc

-fno-stack-protector  -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1

-Wl,--version-script=libgcc.map -o /libgcc_s.so.1.tmp -g -O2 -pipe

-I/usr/local/include -fno-strict-aliasing -B./ _muldi3_s.o _negdi2_s.o

_lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o

_clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o

_addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o

_negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o

_clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o

_popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o

_powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o

_multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o

_bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o

_fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixtfdi_s.o

_fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o

_floatdidf_s.o _floatdixf_s.o _floatditf_s.o _floatundisf_s.o _floatundidf_s.o

_floatundixf_s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o

_umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o enable-execute-stack_s.o

unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o

-lc  rm -f /libgcc_s.so  if [ -f /libgcc_s.so.1 ]; then mv -f

/libgcc_s.so.1 /libgcc_s.so.1.backup; else true; fi  mv /libgcc_s.so.1.tmp

/libgcc_s.so.1  ln -s libgcc_s.so.1 /libgcc_s.so

/usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6:

Undefined symbol __emutls_v._ThreadRuneLocale

gmake[3]: *** [libgcc_s.so] Error 1

gmake[3]: Leaving directory

`/usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libgcc'

gmake[2]: *** [all-stage1-target-libgcc] Error 2

gmake[2]: Leaving directory `/usr/ports/lang/gcc48/work/build'

gmake[1]: *** [stage1-bubble] Error 2

gmake[1]: Leaving directory `/usr/ports/lang/gcc48/work/build'

gmake: *** [bootstrap-lean] Error 2

*** [do-build] Error code 1


[Bug middle-end/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)

2012-11-13 Thread jakub at gcc dot gnu.org


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



Jakub Jelinek jakub at gcc dot gnu.org changed:



   What|Removed |Added



 Status|NEW |WAITING

 CC||jakub at gcc dot gnu.org



--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-13 
09:01:37 UTC ---

So, which exact testcase still fails on which target with what options?

Tried gcc.dg/torture/20090618-1.c with -O1 -m32 with sparc-linux cross and

can't reproduce - foo contains

add %sp, -96, %sp

mov 1, %o0

jmp %o7+8

 add%sp, 96, %sp

which is correct.


[Bug bootstrap/55293] bootstrap failure: invalid conversion from 'char**' to 'const char**' [-fpermissive]

2012-11-13 Thread redi at gcc dot gnu.org


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



--- Comment #14 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-13 
09:42:41 UTC ---

(In reply to comment #10)

 

 The end result of the long long experiment is that there is something wrong in

 gcc 4.7.2 that make it near impossible to bootstrap.  



No, it means you haven't been able to bootstrap with the unconventional

configuration you are using.



From other people's reports if you stop trying to build 64-bit only or

bootstrap with the system compiler it works, but you've said you don't want to

do that.  I hardly think that qualifies as impossible to bootstrap.


[Bug c++/55287] GCC crashes and asks to file bug report

2012-11-13 Thread redi at gcc dot gnu.org


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



--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-13 
09:44:26 UTC ---

6.4MB in a single function is the problem.



The compiler has to process that entire function at once.



And 2GB is not a great amount.


[Bug other/55309] New: gcc's address-sanitizer 66% slower than clang's

2012-11-13 Thread markus at trippelsdorf dot de


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



 Bug #: 55309

   Summary: gcc's address-sanitizer 66% slower than clang's

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: enhancement

  Priority: P3

 Component: other

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: mar...@trippelsdorf.de





Comparing gcc build times:

CC=clang -fsanitize=address -w CXX=clang++ -fsanitize=address -w

~/gcc/configure --disable-bootstrap --disable-werror --disable-multilib

--enable-languages=c,c++

with

CC=gcc -faddress-sanitizer CXX=g++ -faddress-sanitizer ...

and

CC=gcc -fno-var-tracking -faddress-sanitizer CXX=g++ -fno-var-tracking

-faddress-sanitizer ...



Clang : nice -n 19 make -j4  1173.74s user 104.73s system 325% cpu 6:32.18

total

gcc   : nice -n 19 make -j4  3653.30s user 122.27s system 369% cpu 17:00.77

total

gcc_no: nice -n 19 make -j4  2925.20s user 116.42s system 357% cpu 14:11.52

total



perf top shows references_value_p() and value_member() on top.


[Bug middle-end/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)

2012-11-13 Thread ebotcazou at gcc dot gnu.org


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



Eric Botcazou ebotcazou at gcc dot gnu.org changed:



   What|Removed |Added



 Status|WAITING |NEW

 CC||ebotcazou at gcc dot

   ||gnu.org



--- Comment #12 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-13 
10:10:21 UTC ---

 So, which exact testcase still fails on which target with what options?

 Tried gcc.dg/torture/20090618-1.c with -O1 -m32 with sparc-linux cross and

 can't reproduce - foo contains

 add %sp, -96, %sp

 mov 1, %o0

 jmp %o7+8

  add%sp, 96, %sp

 which is correct.



There are no more execution failures on SPARC (modulo

gcc.dg/builtin-object-size-8.c).  The only remaining failures are:



FAIL: gcc.dg/torture/pr51106-2.c  -O0  (internal compiler error)

FAIL: gcc.dg/torture/pr51106-2.c  -O0  (test for excess errors)

FAIL: gcc.dg/torture/pr51106-2.c  -O1  (internal compiler error)

FAIL: gcc.dg/torture/pr51106-2.c  -O1  (test for excess errors)

FAIL: gcc.dg/torture/pr51106-2.c  -O2  (internal compiler error)

FAIL: gcc.dg/torture/pr51106-2.c  -O2  (test for excess errors)

FAIL: gcc.dg/torture/pr51106-2.c  -O3 -fomit-frame-pointer  (internal compiler

error)

FAIL: gcc.dg/torture/pr51106-2.c  -O3 -fomit-frame-pointer  (test for excess

errors)

FAIL: gcc.dg/torture/pr51106-2.c  -O3 -g  (internal compiler error)

FAIL: gcc.dg/torture/pr51106-2.c  -O3 -g  (test for excess errors)

FAIL: gcc.dg/torture/pr51106-2.c  -Os  (internal compiler error)

FAIL: gcc.dg/torture/pr51106-2.c  -Os  (test for excess errors)

FAIL: gcc.dg/torture/pr51106-2.c  -O2 -flto -flto-partition=none  (internal

compiler error)

FAIL: gcc.dg/torture/pr51106-2.c  -O2 -flto -flto-partition=none  (test for

excess errors)

FAIL: gcc.dg/torture/pr51106-2.c  -O2 -flto  (internal compiler error)

FAIL: gcc.dg/torture/pr51106-2.c  -O2 -flto  (test for excess errors)



like everywhere else.


[Bug rtl-optimization/55270] ICE in get_loop_body, at cfgloop.c:823

2012-11-13 Thread mpolacek at gcc dot gnu.org


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



Marek Polacek mpolacek at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-13

 CC||mpolacek at gcc dot gnu.org

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2012-11-13 
10:20:43 UTC ---

Confirmed.


[Bug middle-end/55266] vector expansion: 36 movs for 4 adds

2012-11-13 Thread glisse at gcc dot gnu.org


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



--- Comment #1 from Marc Glisse glisse at gcc dot gnu.org 2012-11-13 10:23:03 
UTC ---

The first copy is PR 52436.



The second copy has a patch posted here:

http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00900.html



The last copy would require turning:



  gimple_assign constructor, _5, {_15, _18}, NULL, NULL

  gimple_assign ssa_name, *x_2(D), _5, NULL, NULL



into:



  gimple_assign ssa_name, *x_2(D), _15, NULL, NULL

  gimple_assign ssa_name, MEM[(vec *)x_2(D) + 16B], _18, NULL, NULL



(not sure if endianness matters here)



which could maybe more easily be done by splitting the memory write (when the

vector type is not supported) into a suitable number of bit_field_ref

extractions and memory writes and relying on forwprop4 to simplify the

bit_field_refs of the constructor.


[Bug middle-end/52285] [4.7/4.8 Regression] libgcrypt _gcry_burn_stack slowdown

2012-11-13 Thread steven at gcc dot gnu.org


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



Steven Bosscher steven at gcc dot gnu.org changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 CC|steven at gcc dot gnu.org   |

 AssignedTo|unassigned at gcc dot   |steven at gcc dot gnu.org

   |gnu.org |



--- Comment #10 from Steven Bosscher steven at gcc dot gnu.org 2012-11-13 
10:30:27 UTC ---

There are several reasons why RTL LIM cannot currently hoist the (frame) rtx.





The first is that in general it stays away from any HARD_REGISTER_P reg with

a 10-foot pole.  For most hard registers this is probably a good strategy:

Anything that's in a real hard register at this point is there for a reason

(function return, global reg, whatever) and almost certainly not invariant in

a loop.





Second, RTL LIM only hoists expression that can be assigned to the original

SET_DEST of a single set. In the case of this PR, the insn in case is:



;;   UD chains for insn luid 2 uid 15

;;  reg 20 { }

;;  reg 63 { d2(bb 4 insn 12) }

(insn 15 12 16 4 (set (reg:CCZ 17 flags)

(compare:CCZ (reg/v/f:DI 63 [ p ])

(reg/f:DI 20 frame))) PR52285.c:10 8 {*cmpdi_1}

 (nil))



This fails in may_assign_reg_p because (reg:CCZ 17) can't be assigned to (it

is a hard register, and I suppose it has class NO_REGS), so the SET_SRC is

not even considered by find_invariant_insn as a potential invariant.  I think

this condition can be relaxed with something like,



Index: loop-invariant.c

===

--- loop-invariant.c(revision 193454)

+++ loop-invariant.c(working copy)

@@ -874,11 +874,11 @@

   dest = SET_DEST (set);



   if (!REG_P (dest)

-  || HARD_REGISTER_P (dest))

+  || HARD_REGISTER_P (dest)

+  || !may_assign_reg_p (dest))

 simple = false;



-  if (!may_assign_reg_p (SET_DEST (set))

-  || !check_maybe_invariant (SET_SRC (set)))

+  if (!check_maybe_invariant (SET_SRC (set)))

 return;



   /* If the insn can throw exception, ...





Finally, RTL LIM cannot hoist parts of expressions.  It only hoists the

SET_SRC as a whole, or nothing at all.  I have patches for that, originally

developed to hoist addresses out of MEMs.  I'll dust them off and see if

I can make it handle (reg:frame + CONST_INT) and other expressions that 

involve eliminable regs.


[Bug middle-end/52285] [4.7/4.8 Regression] libgcrypt _gcry_burn_stack slowdown

2012-11-13 Thread jakub at gcc dot gnu.org


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



--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-13 
10:43:58 UTC ---

I think (plus (frame) (const_int)) is likely not an issue (at least in the

common case, could be only problem if eliminated into something that needs much

bigger offset that doesn't fit into the instruction anymore), the problem is an

eliminable register alone used somewhere where (plus (eliminate_to) (const_int

small_int)) wouldn't be handled and thus would need to be reloaded.

If loops are still around at LRA time, perhaps LRA should consider putting it

before loop if register pressure is low, or LIM could just have extra code for

this (first handle normal IV motions and just record if there are any

eliminable regs not used inside of plus with const_int, and at the end if

register pressure still isn't too high consider just creating a new insn that

sets a pseudo to (frame) or other eliminable register before loop and replacing

all uses of (frame) in the loop with that.  I'm not saying it must be LIM, I'm

just looking for suggestions where to perform this.


[Bug fortran/55282] [OOP] openmp directive and classes

2012-11-13 Thread burnus at gcc dot gnu.org


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



Tobias Burnus burnus at gcc dot gnu.org changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-13 
10:44:14 UTC ---

(In reply to comment #1)

 Note that Fortran 2003 is not supported in OpenMP 3.1. This may change with

 OpenMP 4, but I'm not sure of that.



The OpenMP ARB wasn't as active as I had hoped for, cf. Fortran 2003 in 1.6

Normative References in the OpenMP 4.0 RC, available at

http://openmp.org/wp/openmp-specifications/  At a glance, it looks as if almost

none of the Fortran 2003 features have been taken care of.


[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

2012-11-13 Thread jakub at gcc dot gnu.org


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



--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-13 
10:50:17 UTC ---

Created attachment 28673

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28673

gcc48-pr43631.patch



Is this what you meant?  make check-gcc RUNTESTFLAGS=guality.exp doesn't ICE

with it anymore with verify_flow_info (); at the beginning as well as end of

variable_tracking_main.

The notes are intentionally in between bbs, and it is assumed that the cfg

doesn't change after var-tracking pass, otherwise targets should disable

var-tracking at its standard spot and perform it at the end of machine reorg

pass (as e.g. ia64 and a few other targets do).


[Bug fortran/55297] [4.8 Regression] type-bound operator clashes with abstract interface

2012-11-13 Thread burnus at gcc dot gnu.org


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



Tobias Burnus burnus at gcc dot gnu.org changed:



   What|Removed |Added



   Keywords||rejects-valid

 CC||burnus at gcc dot gnu.org

   Target Milestone|--- |4.8.0



--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-13 
11:19:24 UTC ---

Seems to be due to http://gcc.gnu.org/viewcvs?root=gccview=revrev=189022

for PR fortran/41951 and PR fortran/49591.



In the resolve.c's resolve_typebound_intrinsic_op:



11546 if (gfc_check_new_interface (derived-ns-op[op],

target_proc,

11547  p-where) == FAILURE)



Here target_proc-name == negative and target_proc-ns-proc_name-name

== athlete_module



The symbol (i.e. derived type) is resolved twice: Once for the module

athlete_module (= gfc_current_ns-proc_name) and then again for the abstract

interface procedure sum_interface (= gfc_current_ns-proc_name).



In either case, one has derived-ns-proc_name-name == athlete_module, which

causes the symbol be added twice added to the same namespace.



The question is whether it should be fixed by adding

   if (derived-ns != gfc_current_ns)

 return;

Or using gfc_current_ns instead of derived-ns. Or what's the most

appropriate fix.


[Bug c++/50012] [4.6 Regression] C++ front end misses -Wsign-compare warnings when extraneous parentheses are present

2012-11-13 Thread paolo.carlini at oracle dot com


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



Paolo Carlini paolo.carlini at oracle dot com changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 CC|ian at airs dot com, ian at |

   |gcc dot gnu.org |

 Resolution||FIXED



--- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-13 
11:23:58 UTC ---

Fixed.


[Bug other/55304] libsanitizer can't be used with GCC autoconf

2012-11-13 Thread hjl.tools at gmail dot com


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



--- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-11-13 11:27:39 
UTC ---

One problem is AM_PROG_LIBTOOL, which is the part of libtool.

GCC autoconf doesn't use libtool since we have in-tree

libtool.  To use GCC autoconf, we need also use the rest of

libtool support in GCC source tree. That means it will make

libsanitizer depends on GCC source tree.


[Bug c++/54091] internal compiler error in class method with many string objects

2012-11-13 Thread paolo.carlini at oracle dot com


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



Paolo Carlini paolo.carlini at oracle dot com changed:



   What|Removed |Added



 Status|WAITING |RESOLVED

 Resolution||INVALID



--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-13 
11:28:28 UTC ---

Feedback not forthcoming.


[Bug objc/55291] libsanitizer doesn't build multilib

2012-11-13 Thread burnus at gcc dot gnu.org


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



Tobias Burnus burnus at gcc dot gnu.org changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-13 
11:57:13 UTC ---

See also http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00766.html


[Bug c++/55287] GCC crashes and asks to file bug report

2012-11-13 Thread manu at gcc dot gnu.org

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

Manuel López-Ibáñez manu at gcc dot gnu.org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-11-13 
11:59:48 UTC ---
(In reply to comment #4)
 Why is GCC comsuming so much memory?
 
 The program has 6.4MB source code, it is a single function. All optimizations
 are turned off. And there is 2GB memory in the system.
 
 Well, shouldn't it be possible to compile this program?

That depends on the program, where the memory goes, possible bugs, etc.

To start investigating this, GCC devs would need the info requested here:

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

That said, even if you provided that info, it is unlikely that anyone will look
into this bug, since it is a unusual case. If adding 2 or 4 more GBs of memory
(or splitting the function into many small pieces) solves the issue, then it is
simpler to just do that, and focus on fixing other bugs.

Of course, nothing prevents you from investigating the issue yourself. Perhaps
you are able to uncover a clear bug, memory leak or potential improvement. See:

http://gcc.gnu.org/wiki/Speedup_areas

http://gcc.gnu.org/wiki/Memory_management

http://gcc.gnu.org/wiki/PerformanceTesting


[Bug tree-optimization/54073] [4.7/4.8 Regression] SciMark Monte Carlo test performance has seriously decreased in recent GCC releases

2012-11-13 Thread jakub at gcc dot gnu.org


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



--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-13 
13:04:28 UTC ---

Created attachment 28674

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28674

gcc48-pr54073.patch



On x86_64-linux on SandyBridge CPU with -O3 -march=corei7-avx I've tracked it

down to the 

http://gcc.gnu.org/viewcvs?root=gccview=revrev=171341

change, in particular emit_conditional_move part of the changes.

Before the change emit_conditional_move would completely ignore the predicate

on the comparison operand (operands[1]), starting with r171341 it honors it.

And the movsicc's ordered_comparison_operator would give up on the UNLT

comparison in the MonteCarlo testcase, while ix86_expand_int_movcc expands it

just fine and at least on that loop it is beneficial to use

vucomisd%xmm0, %xmm1

cmovae  %eax, %ebp

instead of:

.L4:

addl$1, %ebx

...

vucomisd%xmm0, %xmm2

jb  .L4



The attached proof of concept patch attempts to just restore the 4.6 and

earlier behavior by allowing in all comparisons.  Of course perhaps it might be

possible it needs better tuning than that, I meant it just as a start for

discussions.



vanilla trunk:



**  **

** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **

** for details. (Results can be submitted to p...@nist.gov) **

**  **

Using   2.00 seconds min time per kenel.

Composite Score: 1886.79

FFT Mflops:  1726.97(N=1024)

SOR Mflops:  1239.20(100 x 100)

MonteCarlo: Mflops:   374.13

Sparse matmult  Mflops:  1956.30(N=1000, nz=5000)

LU  Mflops:  4137.37(M=100, N=100)



patched trunk:



**  **

** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **

** for details. (Results can be submitted to p...@nist.gov) **

**  **

Using   2.00 seconds min time per kenel.

Composite Score: 1910.08

FFT Mflops:  1726.97(N=1024)

SOR Mflops:  1239.20(100 x 100)

MonteCarlo: Mflops:   528.94

Sparse matmult  Mflops:  1949.03(N=1000, nz=5000)

LU  Mflops:  4106.27(M=100, N=100)


[Bug other/55310] New: libsanitizer con't be complier use gcc on windows

2012-11-13 Thread squallatf at gmail dot com


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



 Bug #: 55310

   Summary: libsanitizer con't be complier use gcc on windows

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: other

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: squall...@gmail.com





../../../../libsanitizer/asan/asan_win.cc:31:0: warning: ignoring #pragma

comment  [-Wunknown-pragmas]

 #pragma comment(lib, dbghelp.lib)

 ^

../../../../libsanitizer/asan/asan_win.cc:119:2: error: #error Please build the

runtime with a non-debug CRT: /MD or /MT

 #error Please build the runtime with a non-debug CRT: /MD or /MT

  ^


[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files

2012-11-13 Thread dominiq at lps dot ens.fr


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



--- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-11-13 
13:23:28 UTC ---

 You can find these files in..



 http://llvm.org/svn/llvm-project/compiler-rt/branches/release_32/lib/interception/mach_override/



With this files I have been able to do a clean bootstrap at revision 193472 on

x86_64-apple-darwin10. However, first, I have to supply the lib path for

libasan when using -faddress-sanitizer: -L/opt/gcc/gcc4.8w/lib -lasan; second,

the executable fails to run with:



dyld: Symbol not found: _CFStringCreateCopy

  Referenced from: /opt/gcc/gcc4.8w/lib/libasan.0.dylib

  Expected in: flat namespace

 in /opt/gcc/gcc4.8w/lib/libasan.0.dylib

Trace/BPT trap



Looking at the web, it seems to be a known issue with darwin, but I have been

unable to understand how it can be fixed.



Indeed I also see pr55291.


[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files

2012-11-13 Thread iains at gcc dot gnu.org


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



--- Comment #4 from Iain Sandoe iains at gcc dot gnu.org 2012-11-13 13:54:52 
UTC ---

(In reply to comment #3)

  You can find these files in..

 

  http://llvm.org/svn/llvm-project/compiler-rt/branches/release_32/lib/interception/mach_override/

 

 With this files I have been able to do a clean bootstrap at revision 193472 on

 x86_64-apple-darwin10. However, first, I have to supply the lib path for

 libasan when using -faddress-sanitizer: -L/opt/gcc/gcc4.8w/lib -lasan; second,

 the executable fails to run with:

 

 dyld: Symbol not found: _CFStringCreateCopy



this is found in the CoreFoundation framework (CFx is a good hint).



what you need is to have -framework CoreFoundation on the link line - and I

guess the configury  c. needs to arrange this.





 Looking at the web, it seems to be a known issue with darwin, but I have been

 unable to understand how it can be fixed.

 

 Indeed I also see pr55291.


[Bug target/54791] AIX-only: Constructors are not called in main program.

2012-11-13 Thread dje at gcc dot gnu.org


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



--- Comment #22 from David Edelsohn dje at gcc dot gnu.org 2012-11-13 
14:02:48 UTC ---

The patch in PR 33704 makes no changes to libstdc++ or to any GCC , so I have

no idea why you are seeing C++ errors compiling c-lang.c. Something else was

modified.


[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files

2012-11-13 Thread howarth at nitro dot med.uc.edu


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



--- Comment #5 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-13 
14:06:46 UTC ---

(In reply to comment #4)

 (In reply to comment #3)



  dyld: Symbol not found: _CFStringCreateCopy

 

 this is found in the CoreFoundation framework (CFx is a good hint).

 

 what you need is to have -framework CoreFoundation on the link line - and I

 guess the configury  c. needs to arrange this.

 



The bootstrap completes without any other changes. What we need in

gcc/config/darwin.h is a LINK_SPEC entry for %faddress-sanitizer which passes

-framework CoreFoundation -lasan to the linker.


[Bug target/54791] AIX-only: Constructors are not called in main program.

2012-11-13 Thread adivilceanu at yahoo dot com


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



--- Comment #23 from Adi adivilceanu at yahoo dot com 2012-11-13 14:08:42 UTC 
---

I did not put the patch yet.

This is just gcc 4.7.2 original sources. Why would they not compile?


[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files

2012-11-13 Thread dominiq at lps dot ens.fr


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



--- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-11-13 
14:10:36 UTC ---

 what you need is to have -framework CoreFoundation on the link line - and I

 guess the configury  c. needs to arrange this.



When compiled with -faddress-sanitizer -framework CoreFoundation -lasan, the

executable fails to run with



dyld: lazy symbol binding failed: Symbol not found:

___asan_mach_override_ptr_custom

  Referenced from: /opt/gcc/gcc4.8w/lib/libasan.0.dylib

  Expected in: flat namespace



dyld: Symbol not found: ___asan_mach_override_ptr_custom

  Referenced from: /opt/gcc/gcc4.8w/lib/libasan.0.dylib

  Expected in: flat namespace



Trace/BPT trap


[Bug c++/55311] New: Cannot specialize template parameter of type 'const char *const' in 'using' alias

2012-11-13 Thread niels at penneman dot org

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

 Bug #: 55311
   Summary: Cannot specialize template parameter of type 'const
char *const' in 'using' alias
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ni...@penneman.org


When providing arguments for a template class in a 'using' alias, specifying
arguments of type 'const char *const' doesn't work. It does work for an 'int'
pointer.

==

GCC version:

$ gcc -###
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-alpha2012/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0-alpha2012/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.8.0_alpha2012/work/gcc-4.8-2012/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-alpha2012
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha2012/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-alpha2012
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-alpha2012/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-alpha2012/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha2012/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check
--with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls
--without-included-gettext --with-system-zlib --enable-obsolete
--disable-werror --enable-secureplt --enable-multilib
--with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp
--enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-alpha2012/python
--enable-checking=release --disable-libgcj --disable-libquadmath
--enable-languages=c,c++ --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo
4.8.0_alpha2012'
Thread model: posix
gcc version 4.8.0-alpha2012 2012 (experimental) (Gentoo
4.8.0_alpha2012)

==

Code that fails to compile:

==

template const char *const C, typename T
struct A
{};

extern constexpr char HELLO_WORLD[] = hello world;

template typename T
using PartiallySpecialized = AHELLO_WORLD, T;

int main(int, char **)
{
AHELLO_WORLD, int original;
PartiallySpecializedint ps;
}

==

Compiler invocation/output:

$ g++ -std=c++11 -Wall -Wextra strbug.cxx 
strbug.cxx:8:46: error: ‘hello world’ is not a valid template argument of
type ‘const char*’ because ‘hello world’ is not a variable
 using PartiallySpecialized = AHELLO_WORLD, T;
  ^
strbug.cxx: In function ‘int main(int, char**)’:
strbug.cxx:12:22: warning: unused variable ‘original’ [-Wunused-variable]
  AHELLO_WORLD, int original;
  ^
strbug.cxx:13:28: warning: unused variable ‘ps’ [-Wunused-variable]
  PartiallySpecializedint ps;
^

==

Notice the first instantiation ('original') does not generate any errors or
warnings. The second instantiation ('ps') should be identical to the second.
Above code compiles without warnings and without errors on Clang 3.1.


[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88

2012-11-13 Thread ebotcazou at gcc dot gnu.org


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



--- Comment #33 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-13 
14:17:03 UTC ---

 Can we limit

 

 (zero_extend:DI (plus:SI (FOO:SI) (const_int Y)))

 

 to

 

 (plus:DI (zero_extend:DI (FOO:SI)) (const_int Y))

 

 transformation to Y  TARGET SPECIFIC VALUE? For x86-64, it is -16*1023*1024.



That would really be hackish...  I think that the (slightly less hackish)

change in ix86_print_operand_address would be preferable.


[Bug other/55312] New: libbacktrace doesn't honor --disable-werror

2012-11-13 Thread markus at trippelsdorf dot de

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

 Bug #: 55312
   Summary: libbacktrace doesn't honor --disable-werror
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@trippelsdorf.de


When gcc is configured with --disable-werror and then build with:

% make -j4 BOOT_CFLAGS=-march=native -O3 -pipe STAGE1_CFLAGS=-march=native
-O3 -pipe CFLAGS_FOR_TARGET=-march=native -O3 -pipe
CXXFLAGS_FOR_TARGET=-march=native -O3 -pipe profiledbootstrap

One gets:
...
/home/markus/gcc/libbacktrace/dwarf.c: In function ‘build_address_map’:
/home/markus/gcc/libbacktrace/dwarf.c:1387:13: error: ‘val.u.string’ may be
used uninitialized in this function [-Werror=maybe-uninitialized]
 lineoff = val.u.uint;
...
/home/markus/gcc/libbacktrace/dwarf.c: In function ‘read_referenced_name’:
/home/markus/gcc/libbacktrace/dwarf.c:2078:36: error: ‘val.u.string’ may be
used uninitialized in this function [-Werror=maybe-uninitialized]
name = read_referenced_name (ddata, u, val.u.uint,
...
checking ctype.h usability... /home/markus/gcc/libbacktrace/dwarf.c: In
function ‘read_function_entry’:
/home/markus/gcc/libbacktrace/dwarf.c:2329:22: error: ‘val.u.string’ may be
used uninitialized in this function [-Werror=maybe-uninitialized]
   function-name = val.u.string;


[Bug tree-optimization/55253] [4.8 Regression] Revision 193298 miscompiles sqlite with -Os

2012-11-13 Thread jamborm at gcc dot gnu.org


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



Martin Jambor jamborm at gcc dot gnu.org changed:



   What|Removed |Added



 CC||ian at airs dot com



--- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org 2012-11-13 
14:26:51 UTC ---

*** Bug 55305 has been marked as a duplicate of this bug. ***


[Bug tree-optimization/55305] invalid aggregate constprop

2012-11-13 Thread jamborm at gcc dot gnu.org


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



Martin Jambor jamborm at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #2 from Martin Jambor jamborm at gcc dot gnu.org 2012-11-13 
14:26:51 UTC ---

This is a duplicate of PR 55253, I'm testing a fix.



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


[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files

2012-11-13 Thread howarth at nitro dot med.uc.edu


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



--- Comment #7 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-13 
14:29:57 UTC ---

(In reply to comment #6)

  what you need is to have -framework CoreFoundation on the link line - and 
  I

  guess the configury  c. needs to arrange this.

 

 When compiled with -faddress-sanitizer -framework CoreFoundation -lasan, the

 executable fails to run with

 

 dyld: lazy symbol binding failed: Symbol not found:

 ___asan_mach_override_ptr_custom

   Referenced from: /opt/gcc/gcc4.8w/lib/libasan.0.dylib

   Expected in: flat namespace

 

 dyld: Symbol not found: ___asan_mach_override_ptr_custom

   Referenced from: /opt/gcc/gcc4.8w/lib/libasan.0.dylib

   Expected in: flat namespace

 

 Trace/BPT trap



This symbol is contained in mach_override.c which we currently don't build in

the Makefiles. Note that llvm's cmake files show mach_override.c is compiled

with -std=c99.



# Custom flags:

projects/compiler-rt/lib/interception/CMakeFiles/RTInterception.osx.dir/mach_override/mach_override.c.o_FLAGS

= -std=c99 



The interception/mach_override/mach_override.c.o object file will need to be

linked into both libasan.dylib and libasan.a.


[Bug debug/55094] [4.7/4.8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2224

2012-11-13 Thread jakub at gcc dot gnu.org


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



Jakub Jelinek jakub at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-13

 CC||jakub at gcc dot gnu.org,

   ||rth at gcc dot gnu.org,

   ||vmakarov at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-13 
14:31:11 UTC ---

Doesn't ICE on the trunk anymore since LRA merge, apparently because LRA

decides for some reason to use frame pointer anyway, despite

-fomit-frame-pointer -Os.

CCing Vlad to see why.  Apparently it happens in:

665  if (ep-from_rtx == XEXP (x, 0)

666  || (ep-to_rtx == XEXP (x, 0)

667   ep-to_rtx != hard_frame_pointer_rtx))

668setup_can_eliminate (ep, false);

where ep-from_rtx is (frame), ep-to_rtx is (sp) and x is (pre_dec:SI

(reg/f:SI 7 sp)).

Is that intentional?



Anyway, testcase that also ICEs on 4.7 branch is e.g.

extern int puts (const char *);

int x;



int

main (int argc, char **argv)

{

  if (argc)

{

  puts (argv[0]);

  x = 1;

  __builtin_unreachable ();

}

  x = 1;

  __builtin_unreachable ();

}

with the same options - similar reason, crossjumping during jump2 crossjumps

bbs with different ARGS_SIZE final depth.  For noreturn calls we've handled it

by adding REG_ARGS_SIZE note on the noreturn call I think, for unconditional

TRAP_IF we perhaps could do the same, but not sure what we can do for

__builtin_unreachable which expands to nothing..., with no outgoing edge from

the bb at all.


[Bug tree-optimization/55253] [4.8 Regression] Revision 193298 miscompiles sqlite with -Os

2012-11-13 Thread jamborm at gcc dot gnu.org


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



--- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org 2012-11-13 
14:31:23 UTC ---

Created attachment 28675

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28675

Fix



I am currently bootstrapping this fix.  I'll submit it to the mailing list if

all goes fine.


[Bug target/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88

2012-11-13 Thread hjl.tools at gmail dot com


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



H.J. Lu hjl.tools at gmail dot com changed:



   What|Removed |Added



URL||http://gcc.gnu.org/ml/gcc-p

   ||atches/2012-11/msg00991.htm

   ||l

  Component|middle-end  |target



--- Comment #34 from H.J. Lu hjl.tools at gmail dot com 2012-11-13 14:32:23 
UTC ---

A patch is posted at



http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00991.html


[Bug other/55313] New: libsanitizer cannot be installed

2012-11-13 Thread ebotcazou at gcc dot gnu.org


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



 Bug #: 55313

   Summary: libsanitizer cannot be installed

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: build

  Severity: normal

  Priority: P3

 Component: other

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: ebotca...@gcc.gnu.org





This is on x86-64/Linux:



Making install in asan

make[3]: Entering directory

`/red.a/gnatmail/gcc-x/build-red/x86_64-linux/gnat/obj/x86_64-pc-linux-gnu/libsanitizer/asan'

make[4]: Entering directory

`/red.a/gnatmail/gcc-x/build-red/x86_64-linux/gnat/obj/x86_64-pc-linux-gnu/libsanitizer/asan'

test -z /red.a/gnatmail/gcc-x/build-red/x86_64-linux/gnat/gnat-bin/lib ||

/bin/mkdir -p /red.a/gnatmail/gcc-x/build-red/x86_64-linux/gnat/gnat-bin/lib

 /bin/bash ../libtool   --mode=install /usr/bin/install -c   libasan.la

'/red.a/gnatmail/gcc-x/build-red/x86_64-linux/gnat/gnat-bin/lib'

libtool: install: error: cannot install `libasan.la' to a directory not ending

in /usr/gnat/lib

make[4]: *** [install-toolexeclibLTLIBRARIES] Error 1

make[4]: Leaving directory

`/red.a/gnatmail/gcc-x/build-red/x86_64-linux/gnat/obj/x86_64-pc-linux-gnu/libsanitizer/asan'

make[3]: *** [install-am] Error 2

make[3]: Leaving directory

`/red.a/gnatmail/gcc-x/build-red/x86_64-linux/gnat/obj/x86_64-pc-linux-gnu/libsanitizer/asan'

make[2]: *** [install-recursive] Error 1

make[2]: Leaving directory

`/red.a/gnatmail/gcc-x/build-red/x86_64-linux/gnat/obj/x86_64-pc-linux-gnu/libsanitizer'

make[1]: *** [install-target-libsanitizer] Error 2

make[1]: Leaving directory

`/red.a/gnatmail/gcc-x/build-red/x86_64-linux/gnat/obj'

make: *** [install] Error 2


[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files

2012-11-13 Thread howarth at nitro dot med.uc.edu


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



--- Comment #8 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-13 
14:39:00 UTC ---

Iain,

This brings up the sticky situation of having to modify the Makefile.am

file in libsanitizer/interception to add mach_override/mach_override.c to the

interception_files source list and the Makefile.am file in libsanitizer/asan to

link in the resulting interception/mach_override/mach_override.o object code to

libasan. Any ideas on how to do this in a target specific manner cleanly?


[Bug objc/55291] libsanitizer doesn't build multilib

2012-11-13 Thread hjl.tools at gmail dot com


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



H.J. Lu hjl.tools at gmail dot com changed:



   What|Removed |Added



 CC||ebotcazou at gcc dot

   ||gnu.org



--- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2012-11-13 14:44:35 
UTC ---

*** Bug 55313 has been marked as a duplicate of this bug. ***


[Bug other/55313] libsanitizer cannot be installed

2012-11-13 Thread hjl.tools at gmail dot com


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



H.J. Lu hjl.tools at gmail dot com changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-11-13 14:44:35 
UTC ---

Dup.



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


[Bug target/55307] libgcc's __cpu_indicator_init does not check for avx correctly

2012-11-13 Thread hjl.tools at gmail dot com


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



H.J. Lu hjl.tools at gmail dot com changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-13

  Component|other   |target

 CC||areg.melikadamyan at gmail

   ||dot com, hjl.tools at gmail

   ||dot com

 Ever Confirmed|0   |1

   Target Milestone|--- |4.8.0


[Bug c/55299] missed optimization: ASR idiom

2012-11-13 Thread hjl.tools at gmail dot com


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



H.J. Lu hjl.tools at gmail dot com changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-13

 CC||areg.melikadamyan at gmail

   ||dot com, hjl.tools at gmail

   ||dot com

 Ever Confirmed|0   |1



--- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-11-13 14:58:03 
UTC ---

clang generates:



movb%sil, %cl

sarl%cl, %edi

movl%edi, %eax

ret


[Bug tree-optimization/54073] [4.7/4.8 Regression] SciMark Monte Carlo test performance has seriously decreased in recent GCC releases

2012-11-13 Thread t.artem at mailcity dot com


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



--- Comment #9 from Artem S. Tashkinov t.artem at mailcity dot com 2012-11-13 
15:06:25 UTC ---

(In reply to comment #8)

 The attached proof of concept patch attempts to just restore the 4.6 and

 earlier behavior by allowing in all comparisons.  Of course perhaps it might 
 be

 possible it needs better tuning than that, I meant it just as a start for

 discussions.



The results look terrific, I hope this patch will be merged ASAP.


[Bug tree-optimization/54073] [4.7/4.8 Regression] SciMark Monte Carlo test performance has seriously decreased in recent GCC releases

2012-11-13 Thread ubizjak at gmail dot com


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



--- Comment #10 from Uros Bizjak ubizjak at gmail dot com 2012-11-13 15:13:56 
UTC ---

(In reply to comment #8)



 The attached proof of concept patch attempts to just restore the 4.6 and

 earlier behavior by allowing in all comparisons.  Of course perhaps it might 
 be

 possible it needs better tuning than that, I meant it just as a start for

 discussions.



Please see PR53346, from comment 14 onwards, especially H.J.'s comment:



-quote-

I was told that cmov wins if branch is mispredicted, otherwise

cmov loses.  We will investigate if we can improve cmov in GCC.

-/quote-


[Bug tree-optimization/54073] [4.7/4.8 Regression] SciMark Monte Carlo test performance has seriously decreased in recent GCC releases

2012-11-13 Thread jakub at gcc dot gnu.org


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



--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-13 
15:24:19 UTC ---

(In reply to comment #10)

 Please see PR53346, from comment 14 onwards, especially H.J.'s comment:

 

 -quote-

 I was told that cmov wins if branch is mispredicted, otherwise

 cmov loses.  We will investigate if we can improve cmov in GCC.

 -/quote-



Possibly.  But then still movsicc etc. isn't automatically the right thing if

the comparison is ordered and wrong otherwise, but desirable/undesirable

depending on whether the compiler can guess if the condition can be predicated

well or not.

Guess in MonteCarlo the x*x + y*y = 1.0 condition can't be predicted well and

that is why it helps so much.


[Bug fortran/54818] [4.7/4.8 Regression] error: type mismatch in binary expression

2012-11-13 Thread jakub at gcc dot gnu.org


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



Jakub Jelinek jakub at gcc dot gnu.org changed:



   What|Removed |Added



   Priority|P3  |P4

 CC||jakub at gcc dot gnu.org


[Bug tree-optimization/54073] [4.7/4.8 Regression] SciMark Monte Carlo test performance has seriously decreased in recent GCC releases

2012-11-13 Thread hubicka at gcc dot gnu.org


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



Jan Hubicka hubicka at gcc dot gnu.org changed:



   What|Removed |Added



 CC||hubicka at gcc dot gnu.org



--- Comment #12 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-13 
15:54:22 UTC ---

The decision on whether to use cmov or jmp was always tricky on x86

architectures. Cmov increase dependency chains, register pressure (both values

needs to be loaded in) and has long opcode. So jump sequence, if well

predicted, flows better through the out-of-order core. If badly predicted it

is, of course, a disaster. I think more modern CPUs solved the problems with

long latency of cmov, but the dependency chains are still there.



This patch fixes a bug in a pattern rather than tweaks heuristic on

predictability. As such I think it is OK for mainline. 



We should do something about rnflow. I will look into that.

The usual wisdom is that lacking profile feedback one should handle non-loop

branhces as inpredctable and loop branches as predictable, so all handled by

ifconvert fals to the first category. With profile feedback one can see branch

probability and if it is close to 0 or REG_BR_PROB_BASE tread the branch as

predictable. We handle this with predictable_edge_p parameter passed to

BRANCH_COST (that by itself is a gross, but for years we was not able to come

with something saner)



Honza


[Bug c++/54466] [C++11] Recursive Type Alias, Member Function Pointer, Segmentation Fault

2012-11-13 Thread dodji at gcc dot gnu.org


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



--- Comment #10 from Dodji Seketeli dodji at gcc dot gnu.org 2012-11-13 
16:07:50 UTC ---

Author: dodji

Date: Tue Nov 13 16:07:39 2012

New Revision: 193479



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

Log:

PR c++/54466 - ICE with alias template which type-id is const qualified



Consider this short example:



templatetypename T

  struct X { };



templatetypename T

  using Y = const XT;



using Z = Yint;



G++ crashes in lookup_class_template_1 while trying to build the alias

template instantiation Yint.



I think this is indirectly due to the fact that that

lookup_class_template_1 can now yield a const qualified type like

'const XT'.



As a consequence, the code in lookup_template_class_1 that was trying

to access the TYPE_STUB_DECL field of the result of

lookup_template_class_1 should now be adjusted to access the

TYPE_STUB_DECL of the main variant of the resulting type instead (and

that is TYPE_MAIN_DECL); because qualified types (constructed with

build_qualified_type) have their TYPE_STUB_DECL set to NULL.



Fixed thus and tested on x86_64-unknown-linux-gnu against trunk.



gcc/cp



PR c++/54466

* pt.c (lookup_template_class_1): TYPE_STUB_DECL should be

accessed on the main variant of the type.



gcc/testsuite/



* g++.dg/cpp0x/alias-decl-26.C: New test file.



In the example of this patch, g++ crashes when trying to build the

alias template Yint



Added:

trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-26.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/pt.c

trunk/gcc/testsuite/ChangeLog


[Bug c++/54466] [C++11] Recursive Type Alias, Member Function Pointer, Segmentation Fault

2012-11-13 Thread dodji at gcc dot gnu.org


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



Dodji Seketeli dodji at gcc dot gnu.org changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #11 from Dodji Seketeli dodji at gcc dot gnu.org 2012-11-13 
16:09:27 UTC ---

Fixed in trunk (4.8).


[Bug other/55304] libsanitizer can't be used with GCC autoconf

2012-11-13 Thread hjl.tools at gmail dot com


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



H.J. Lu hjl.tools at gmail dot com changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

URL||http://gcc.gnu.org/ml/gcc-p

   ||atches/2012-11/msg01003.htm

   ||l

   Last reconfirmed||2012-11-13

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-11-13 16:54:21 
UTC ---

This patch



http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01003.html



fixes it.


[Bug fortran/55282] [OOP] openmp directive and classes

2012-11-13 Thread valeryweber at hotmail dot com


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



--- Comment #6 from Valery Weber valeryweber at hotmail dot com 2012-11-13 
16:57:28 UTC ---

Dear All 

I posted a comment on the openmp forum about the f2003 features. Complaining

there may help, who knows?

Valery


[Bug target/41993] [sh] ICE in create_pre_exit, at mode-switching.c:399

2012-11-13 Thread uros at gcc dot gnu.org


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



--- Comment #14 from uros at gcc dot gnu.org 2012-11-13 16:59:44 UTC ---

Author: uros

Date: Tue Nov 13 16:59:37 2012

New Revision: 193480



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

Log:

PR target/41993

* mode-switching.c (create_pre_exit): Set return_copy to last_insn

when copy_start is a function return regno instead of pseudo.

Skip debug instructions in instruction scan loop.





Modified:

trunk/gcc/ChangeLog

trunk/gcc/mode-switching.c


[Bug tree-optimization/55253] [4.8 Regression] Revision 193298 miscompiles sqlite with -Os

2012-11-13 Thread jamborm at gcc dot gnu.org


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



Martin Jambor jamborm at gcc dot gnu.org changed:



   What|Removed |Added



URL||http://gcc.gnu.org/ml/gcc-p

   ||atches/2012-11/msg01008.htm

   ||l



--- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org 2012-11-13 
17:05:06 UTC ---

I have submitted a fix to the mailing list:



http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01008.html


[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics

2012-11-13 Thread juno.krahn at nih dot gov


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



Juno Krahn juno.krahn at nih dot gov changed:



   What|Removed |Added



 CC||juno.krahn at nih dot gov



--- Comment #13 from Juno Krahn juno.krahn at nih dot gov 2012-11-13 18:14:43 
UTC ---

I just came across this issue, using code that used to compile under gfortran.



The standards reference in the previous comment is in reference to program

units, which includes binding labels. It asserts that global identifiers are

unique entities, but interface definitions are not program units. Multiple

interfaces can refer to the same unique. I don't have a reference, but I

remember this specific issue being discussed at one point with the Fortran

Standards committee, and the consensus was that multiple interfaces to a single

BIND(C) name is both valid and useful.


[Bug target/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88

2012-11-13 Thread hjl.tools at gmail dot com


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



--- Comment #35 from H.J. Lu hjl.tools at gmail dot com 2012-11-13 18:21:30 
UTC ---

This regression is triggered by revision 188008:



http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00038.html



aka the un-sign-extension of sizetype constants.


[Bug other/55312] libbacktrace doesn't honor --disable-werror

2012-11-13 Thread markus at trippelsdorf dot de


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



Markus Trippelsdorf markus at trippelsdorf dot de changed:



   What|Removed |Added



 CC||hjl.tools at gmail dot com,

   ||iant at google dot com,

   ||markus at trippelsdorf dot

   ||de



--- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de 
2012-11-13 18:24:50 UTC ---

See also:

http://gcc.gnu.org/ml/gcc-regression/2012-11/msg00279.html


[Bug rtl-optimization/19398] secondary reloads don't consider m alternatives

2012-11-13 Thread ubizjak at gmail dot com


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



Uros Bizjak ubizjak at gmail dot com changed:



   What|Removed |Added



 CC||vmakarov at gcc dot gnu.org



--- Comment #13 from Uros Bizjak ubizjak at gmail dot com 2012-11-13 18:33:55 
UTC ---

CC LRA masters.


[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88

2012-11-13 Thread hjl at gcc dot gnu.org


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



--- Comment #36 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-11-13 
18:35:42 UTC ---

Author: hjl

Date: Tue Nov 13 18:35:32 2012

New Revision: 193483



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

Log:

Workaround PR middle-end/55142



gcc/



2012-11-13  Eric Botcazou  ebotca...@adacore.com

H.J. Lu  hongjiu...@intel.com



PR middle-end/55142

* config/i386/i386.c (legitimize_pic_address): Properly handle

REG + CONST.

(ix86_print_operand_address): Set code to 'k' when forcing

addr32 prefix.  For x32, zero-extend negative displacement if

it  -16*1024*1024.



gcc/testsuite/



2012-11-13  H.J. Lu  hongjiu...@intel.com



PR middle-end/55142

* gcc.target/i386/pr55142-1.c: New file.

* gcc.target/i386/pr55142-2.c: Likewise.



Added:

trunk/gcc/testsuite/gcc.target/i386/pr55142-1.c

trunk/gcc/testsuite/gcc.target/i386/pr55142-2.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/i386/i386.c

trunk/gcc/testsuite/ChangeLog


[Bug tree-optimization/54717] [4.8 Regression] Runtime regression: polyhedron test rnflow degraded

2012-11-13 Thread ubizjak at gmail dot com


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



--- Comment #10 from Uros Bizjak ubizjak at gmail dot com 2012-11-13 18:39:28 
UTC ---

(In reply to comment #8)



 This shows that the file cptrf2_inl_1.f90 compiled with -ftree-loop-if-convert

 gives a slow executable without involving inlining or vectorization.



Dup of PR53346 ?


[Bug middle-end/41115] Tree-vectorizer: VecCost tuning for X2: Without vectorization 30% faster

2012-11-13 Thread ubizjak at gmail dot com


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



Uros Bizjak ubizjak at gmail dot com changed:



   What|Removed |Added



 CC||venkataramanan.kumar at amd

   ||dot com



--- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2012-11-13 18:44:22 
UTC ---

Adding CC.


[Bug tree-optimization/53342] [4.8 Regression] rnflow.f90 is ~5% slower after revision 187340

2012-11-13 Thread ubizjak at gmail dot com


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



--- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2012-11-13 18:46:13 
UTC ---

(In reply to comment #2)

 Yeah.



Is there any progress on this issue?


[Bug tree-optimization/54717] [4.8 Regression] Runtime regression: polyhedron test rnflow degraded

2012-11-13 Thread dominiq at lps dot ens.fr


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



--- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr 
2012-11-13 18:54:40 UTC ---

 Dup of PR53346 ?



May be! Both PRs seem also related to pr54073.


[Bug tree-optimization/55253] [4.8 Regression] Revision 193298 miscompiles sqlite with -Os

2012-11-13 Thread jamborm at gcc dot gnu.org


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



--- Comment #6 from Martin Jambor jamborm at gcc dot gnu.org 2012-11-13 
18:56:27 UTC ---

Author: jamborm

Date: Tue Nov 13 18:56:24 2012

New Revision: 193484



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

Log:

2012-11-13  Martin Jambor  mjam...@suse.cz



PR tree-optimization/55253

* ipa-cp.c (merge_aggregate_lattices): Propagate aggs_contain_variable

flag.



* testsuite/gcc.dg/torture/pr55253.c: New test.

* testsuite/gcc.dg/torture/pr55305.c: Likewise.





Added:

trunk/gcc/testsuite/gcc.dg/torture/pr55253.c

trunk/gcc/testsuite/gcc.dg/torture/pr55305.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/ipa-cp.c

trunk/gcc/testsuite/ChangeLog


[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88

2012-11-13 Thread ebotcazou at gcc dot gnu.org


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



Eric Botcazou ebotcazou at gcc dot gnu.org changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #37 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-13 
19:36:47 UTC ---

Hopefully.


[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files

2012-11-13 Thread howarth at nitro dot med.uc.edu


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



--- Comment #9 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-13 
19:50:20 UTC ---

Created attachment 28676

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28676

hack to build asan support


[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files

2012-11-13 Thread howarth at nitro dot med.uc.edu


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



--- Comment #10 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-13 
19:52:35 UTC ---

The attached patch (with configure and Makefile.in regenerated) allows the asan

support to build on x86_64-apple-darwin12. It still isn't functional yet as

test cases compiled with...



g++-fsf-4.8 -faddress-sanitizer -framework CoreFoundation hello.cc -lasan



produce...



# ./a.out

mach_override: some instructions unknown! Need to update mach_override.c

err = f801

../../../../gcc-4.8-20121113/libsanitizer/interception/mach_override/mach_override.c:308

err = f801

../../../../gcc-4.8-20121113/libsanitizer/interception/mach_override/mach_override.c:321

err = f801

../../../../gcc-4.8-20121113/libsanitizer/interception/mach_override/mach_override.c:327

err = f801

../../../../gcc-4.8-20121113/libsanitizer/interception/mach_override/mach_override.c:340

err = f801

../../../../gcc-4.8-20121113/libsanitizer/interception/mach_override/mach_override.c:345

Hello, world.


[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files

2012-11-13 Thread howarth at nitro dot med.uc.edu


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



--- Comment #11 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-13 
20:13:18 UTC ---

For the simple test case...



int main()

{

int i;

i=5;

}



compiled with 'g++-fsf-4.8 -faddress-sanitizer -O0 -framework CoreFoundation

test.cc -lasan'

using a mach_override.c with...



#define DEBUG_DISASM 1

// #undef DEBUG_DISASM



the errors appear late in the debug output at...



Replacing function at 0x11183d630

First 16 bytes of the function: 48 8d 5 11 4f b 0 53 48 8d 5f e0 48 89 77 90 

To disassemble, save the following function as disas.c and run:

  gcc -c disas.c  gobjdump -d disas.o

The first 16 bytes of the original function will start after four nop

instructions.



void foo() {

  asm volatile(nop;nop;nop;nop;);

  asm volatile(.byte 0x48, 0x8d, 0x5, 0x11, 0x4f, 0xb, 0x0, 0x53;);

  asm volatile(.byte 0x48, 0x8d, 0x5f, 0xe0, 0x48, 0x89, 0x77, 0x90;);

}



Matching: 48  FAIL

Matching: 48  FAIL

Matching: 48  FAIL

Matching: 48  FAIL

Matching: 48 8d  FAIL

Matching: 48 8d  FAIL

Matching: 48 8d  FAIL

Matching: 48 8d  FAIL

Matching: 48  FAIL

Matching: 48  FAIL

Matching: 48  FAIL

Matching: 48  FAIL

Matching: 48  FAIL

Matching: 48  FAIL

Matching: 48  FAIL

Matching: 48  FAIL

Matching: 48  FAIL

Matching: 48  FAIL

Matching: 48  FAIL

Matching: 48 8d  FAIL

Matching: 48 8d  FAIL

Matching: 48  FAIL

Matching: 48 8d  FAIL

Matching: 48  FAIL

Matching: 48  FAIL

Matching: 48  FAIL

Matching: 48  FAIL

Matching: 48  FAIL

Matching: 48  FAIL

Matching: 48  FAIL

Matching: 48  FAIL

Matching: 48  FAIL

Matching: 48 8d  FAIL

mach_override: some instructions unknown! Need to update mach_override.c

overridePossible = false @299

err = f801

../../../../gcc-4.8-20121113/libsanitizer/interception/mach_override/mach_override.c:308

err = f801

../../../../gcc-4.8-20121113/libsanitizer/interception/mach_override/mach_override.c:321

err = f801

../../../../gcc-4.8-20121113/libsanitizer/interception/mach_override/mach_override.c:327

err = f801

../../../../gcc-4.8-20121113/libsanitizer/interception/mach_override/mach_override.c:340

err = f801

../../../../gcc-4.8-20121113/libsanitizer/interception/mach_override/mach_override.c:345

First 16 bytes of the function after slicing: 48 8d 5 11 4f b 0 53 48 8d 5f e0

48 89 77 90 

Replacing function at 0x7fff94c23364


[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files

2012-11-13 Thread howarth at nitro dot med.uc.edu


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



--- Comment #12 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-13 
20:21:35 UTC ---

The disasembled testcase that is choking on shows...





test.o: file format mach-o-x86-64





Disassembly of section .text:



 _main:

   0:55   push   %rbp

   1:48 89 e5 mov%rsp,%rbp

   4:c7 45 fc 05 00 00 00 movl   $0x5,-0x4(%rbp)

   b:b8 00 00 00 00   mov$0x0,%eax

  10:5d   pop%rbp

  11:c3   retq   



0012 __GLOBAL__sub_I_00099_0_test.cc:

  12:55   push   %rbp

  13:48 89 e5 mov%rsp,%rbp

  16:e8 00 00 00 00   callq  1b

__GLOBAL__sub_I_00099_0_test.cc+0x9

  1b:5d   pop%rbp

  1c:c3   retq   



Disassembly of section __DATA.__mod_init_func:



0020 __DATA.__mod_init_func:

...


[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files

2012-11-13 Thread howarth at nitro dot med.uc.edu


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



--- Comment #13 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-13 
20:25:45 UTC ---

Also note the comment in mach_override.c...



#elif defined(__x86_64__)

// TODO(glider): disassembling the 0x48, 0x89 sequences is trickier than it's

done below.

// If it stops working, refer to

http://ref.x86asm.net/geek.html#modrm_byte_32_64 to do it

// more accurately.

// Note: 0x48 is in fact the REX.W prefix, but it might be wrong to treat it as

a separate

// instruction.



looks like we are bumping into this bug.


[Bug c/55299] missed optimization: ASR idiom

2012-11-13 Thread olly at survex dot com


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



--- Comment #2 from olly at survex dot com 2012-11-13 20:40:06 UTC ---

Interestingly clang (at least 3.0-6 from Debian testing) fails to optimise the

same testcase but shifting by a constant.  For that variant case clang

generates essentially the same code as GCC currently does.


[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files

2012-11-13 Thread howarth at nitro dot med.uc.edu


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



--- Comment #14 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-13 
20:50:37 UTC ---

Actually, this appears to be just noise on the output from a functional

libasan. If I use the testcase from

http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer of...



% cat tests/use-after-free.c

#include stdlib.h

int main() {

  char *x = (char*)malloc(10 * sizeof(char*));

  free(x);

  return x[5];

}



I get...



howarth% gcc-fsf-4.8 -faddress-sanitizer -framework CoreFoundation -O1

-fno-omit-frame-pointer -g use-after-free.c -lasan

howarth% ./a.out

mach_override: some instructions unknown! Need to update mach_override.c

err = f801

../../../../gcc-4.8-20121113/libsanitizer/interception/mach_override/mach_override.c:308

err = f801

../../../../gcc-4.8-20121113/libsanitizer/interception/mach_override/mach_override.c:321

err = f801

../../../../gcc-4.8-20121113/libsanitizer/interception/mach_override/mach_override.c:327

err = f801

../../../../gcc-4.8-20121113/libsanitizer/interception/mach_override/mach_override.c:340

err = f801

../../../../gcc-4.8-20121113/libsanitizer/interception/mach_override/mach_override.c:345

=

==88551== ERROR: AddressSanitizer heap-use-after-free on address 0x000105cbaf45

at pc 0x103001f12 bp 0x7fff5cbfe8f0 sp 0x7fff5cbfe8e8

READ of size 1 at 0x000105cbaf45 thread T0

#0 0x103001f11 (/Users/howarth/./a.out+0x10f11)

#1 0x7fff8bd827e0 (/usr/lib/system/libdyld.dylib+0x27e0)

#2 0x0

0x000105cbaf45 is located 5 bytes inside of 80-byte region

[0x000105cbaf40,0x000105cbaf90)

freed by thread T0 here:

#0 0x1030147a4 (/sw/lib/gcc4.8/lib/libasan.0.dylib+0xb7a4)

#1 0x10301492a (/sw/lib/gcc4.8/lib/libasan.0.dylib+0xb92a)

#2 0x103001ee5 (/Users/howarth/./a.out+0x10ee5)

#3 0x7fff8bd827e0 (/usr/lib/system/libdyld.dylib+0x27e0)

#4 0x0

previously allocated by thread T0 here:

#0 0x103014255 (/sw/lib/gcc4.8/lib/libasan.0.dylib+0xb255)

#1 0x7fff94c3b152 (/usr/lib/system/libsystem_c.dylib+0x2d152)

#2 0x7fff94c3bba6 (/usr/lib/system/libsystem_c.dylib+0x2dba6)

#3 0x103001eda (/Users/howarth/./a.out+0x10eda)

#4 0x7fff8bd827e0 (/usr/lib/system/libdyld.dylib+0x27e0)

Shadow byte and word:

  0x100020b975e8: fd

  0x100020b975e8: fd fd fd fd fd fd fd fd

More shadow bytes:

  0x100020b975c8: fa fa fa fa fa fa fa fa

  0x100020b975d0: fa fa fa fa fa fa fa fa

  0x100020b975d8: fa fa fa fa fa fa fa fa

  0x100020b975e0: fa fa fa fa fa fa fa fa

=0x100020b975e8: fd fd fd fd fd fd fd fd

  0x100020b975f0: fd fd fd fd fd fd fd fd

  0x100020b975f8: fa fa fa fa fa fa fa fa

  0x100020b97600: fa fa fa fa fa fa fa fa

  0x100020b97608: fa fa fa fa fa fa fa fa

Stats: 0M malloced (0M for red zones) by 1 calls

Stats: 0M realloced by 0 calls

Stats: 0M freed by 1 calls

Stats: 0M really freed by 0 calls

Stats: 0M (128 full pages) mmaped in 1 calls

  mmaps   by size class: 8:2047; 

  mallocs by size class: 8:1; 

  frees   by size class: 8:1; 

  rfrees  by size class: 

Stats: malloc large: 0 small slow: 1

==88551== ABORTING



compared to...



howarth% /sw/opt/llvm-3.2/bin/clang -fsanitize=address -O1

-fno-omit-frame-pointer -g use-after-free.c



howarth% ./a.out

=

==88537== ERROR: AddressSanitizer: heap-use-after-free on address

0x00010a0a2f45 at pc 0x107dcae54 bp 0x7fff57e358f0 sp 0x7fff57e358e8

READ of size 1 at 0x00010a0a2f45 thread T0

#0 0x107dcae53 (/Users/howarth/./a.out+0x10e53)

#1 0x7fff8bd827e0 (/usr/lib/system/libdyld.dylib+0x27e0)

#2 0x0

0x00010a0a2f45 is located 5 bytes inside of 80-byte region

[0x00010a0a2f40,0x00010a0a2f90)

freed by thread T0 here:

#0 0x107dd3878 (/Users/howarth/./a.out+0x19878)

#1 0x107dd2ef2 (/Users/howarth/./a.out+0x18ef2)

#2 0x107dcae1a (/Users/howarth/./a.out+0x10e1a)

#3 0x7fff8bd827e0 (/usr/lib/system/libdyld.dylib+0x27e0)

#4 0x0

previously allocated by thread T0 here:

#0 0x107dd3682 (/Users/howarth/./a.out+0x19682)

#1 0x7fff94c3b152 (/usr/lib/system/libsystem_c.dylib+0x2d152)

#2 0x7fff94c3bba6 (/usr/lib/system/libsystem_c.dylib+0x2dba6)

#3 0x107dcae0f (/Users/howarth/./a.out+0x10e0f)

#4 0x7fff8bd827e0 (/usr/lib/system/libdyld.dylib+0x27e0)

Shadow byte and word:

  0x1000214145e8: fd

  0x1000214145e8: fd fd fd fd fd fd fd fd

More shadow bytes:

  0x1000214145c8: fa fa fa fa fa fa fa fa

  0x1000214145d0: fa fa fa fa fa fa fa fa

  0x1000214145d8: fa fa fa fa fa fa fa fa

  0x1000214145e0: fa fa fa fa fa fa fa fa

=0x1000214145e8: fd fd fd fd fd fd fd fd

  0x1000214145f0: fd fd fd fd fd fd fd fd

  0x1000214145f8: fa fa fa fa fa fa fa fa

  0x100021414600: fa fa fa fa fa fa fa fa

  0x100021414608: fa fa fa fa fa fa fa fa

Stats: 0M malloced (0M for red zones) by 1

[Bug other/55309] gcc's address-sanitizer 66% slower than clang's

2012-11-13 Thread konstantin.s.serebryany at gmail dot com


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



Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed:



   What|Removed |Added



 CC||konstantin.s.serebryany at

   ||gmail dot com



--- Comment #1 from Konstantin Serebryany konstantin.s.serebryany at gmail dot 
com 2012-11-13 21:10:23 UTC ---

While this is an interesting comparison, I should note that 

the typical use of asan is with -O1 or -O2, 

so it might make more sense to  compare the asan implementations at -O1/-O2


[Bug other/55312] libbacktrace doesn't honor --disable-werror

2012-11-13 Thread ian at gcc dot gnu.org


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



--- Comment #2 from ian at gcc dot gnu.org ian at gcc dot gnu.org 2012-11-13 
21:25:45 UTC ---

Author: ian

Date: Tue Nov 13 21:25:39 2012

New Revision: 193485



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

Log:

PR other/55312

* configure.ac: Only add -Werror if building a target library.



Modified:

trunk/libbacktrace/ChangeLog

trunk/libbacktrace/configure

trunk/libbacktrace/configure.ac


[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files

2012-11-13 Thread konstantin.s.serebryany at gmail dot com


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



Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed:



   What|Removed |Added



 CC||konstantin.s.serebryany at

   ||gmail dot com



--- Comment #15 from Konstantin Serebryany konstantin.s.serebryany at gmail 
dot com 2012-11-13 21:27:08 UTC ---

Please not that upstream asan is in the process of getting rid of mach_override

in favor of Mac's function interposition.


[Bug other/55312] libbacktrace doesn't honor --disable-werror

2012-11-13 Thread ian at airs dot com


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



Ian Lance Taylor ian at airs dot com changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||ian at airs dot com

 Resolution||FIXED



--- Comment #3 from Ian Lance Taylor ian at airs dot com 2012-11-13 21:28:29 
UTC ---

Fixed.


[Bug other/55309] gcc's address-sanitizer 66% slower than clang's

2012-11-13 Thread markus at trippelsdorf dot de


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



--- Comment #2 from Markus Trippelsdorf markus at trippelsdorf dot de 
2012-11-13 21:31:08 UTC ---

gcc uses -O2 -g by default for --disable-bootstrap.



Also ,to be fair, if one uses a profiledbootstrapped gcc configured with

--enable-checking=release to build it only takes 12:58.77 on the same machine.


[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files

2012-11-13 Thread howarth at nitro dot med.uc.edu


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



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



   What|Removed |Added



  Attachment #28676|0   |1

is obsolete||



--- Comment #16 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-13 
21:55:22 UTC ---

Created attachment 28677

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28677

prototype patch for adding darwin asan support


[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files

2012-11-13 Thread howarth at nitro dot med.uc.edu


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



--- Comment #17 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-13 
22:14:10 UTC ---

(In reply to comment #16)

 Created attachment 28677 [details]

 prototype patch for adding darwin asan support



Note that you need to run...



autoconf -I. -I./config

cd libsanitizer

autoreconf -I. -I../config

automake-1.11



after applying the prototype patch.


[Bug target/54429] [SH] SImode values get ferried through FPUL and FP regs for -O0

2012-11-13 Thread olegendo at gcc dot gnu.org


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



--- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org 2012-11-13 22:25:30 
UTC ---

(In reply to comment #3)

 I've tested this:

 

 Index: gcc/config/sh/sh.c

 ===

 --- gcc/config/sh/sh.c(revision 193423)

 +++ gcc/config/sh/sh.c(working copy)

 @@ -12113,6 +12113,11 @@

if (FP_REGISTER_P (regno)  mode == SFmode)

  return true;

 

 +  if (FP_REGISTER_P (regno)

 +   !(GET_MODE_CLASS (mode) == MODE_FLOAT

 +   || GET_MODE_CLASS (mode) == MODE_VECTOR_FLOAT))

 +return false;

 +

if (mode == V2SFmode)

  {

if (((FP_REGISTER_P (regno)  (regno - FIRST_FP_REG) % 2 == 0)

 

 

 on rev 193423.  There are a few failures on targets with HW FPU:

 



It seems these problems happen on big endian targets only.



 FAIL: gcc.c-torture/execute/20080502-1.c compilation



Reload failure.  Problematic insn:



(insn 12 44 13 2 (set (reg:SI 147 t)

(eq:SI (and:SI (reg:SI 1 r1 [166])

(subreg:SI (reg:DF 68 fr4 [ x ]) 0))

(const_int 0 [0]))) sh_tmp.cpp:110 1 {tstsi_t}

 (expr_list:REG_DEAD (reg:SI 1 r1 [166])

(expr_list:REG_DEAD (reg:DF 68 fr4 [ x ])

(nil



 FAIL: gcc.c-torture/execute/ieee/copysign1.c compilation



Reload failure.  Problematic insn:



(insn 10 41 11 2 (set (reg:SI 147 t)

(eq:SI (and:SI (reg:SI 1 r1 [165])

(subreg:SI (reg:DF 70 fr6 [ y ]) 0))

(const_int 0 [0]))) sh_tmp.cpp:67 1 {tstsi_t}

 (expr_list:REG_DEAD (reg:SI 1 r1 [165])

(expr_list:REG_DEAD (reg:DF 70 fr6 [ y ])

(nil



 FAIL: gcc.dg/builtins-32.c (internal compiler error)



Reload failure.  Problematic insn:



(insn 8 7 21 2 (set (reg:SI 0 r0 [164])

(and:SI (reg:SI 0 r0 [164])

(subreg:SI (reg:DF 68 fr4 [ x ]) 0))) sh_tmp.cpp:30 111

{*andsi_compact}

 (expr_list:REG_DEAD (reg:DF 68 fr4 [ x ])

(nil)))



 FAIL: gcc.dg/builtins-50.c (internal compiler error)



Reload failure.  Problematic insn:



(insn 10 43 11 2 (set (reg:SI 147 t)

(eq:SI (and:SI (reg:SI 1 r1 [165])

(subreg:SI (reg:DF 70 fr6 [ y ]) 0))

(const_int 0 [0]))) sh_tmp.cpp:24 1 {tstsi_t}

 (expr_list:REG_DEAD (reg:SI 1 r1 [165])

(expr_list:REG_DEAD (reg:DF 70 fr6 [ y ])

(nil





 FAIL: gcc.dg/pr48335-7.c (internal compiler error)



Reload failure.  Problematic insn:



(insn 9 3 10 2 (set (reg:SI 0 r0 [167])

(ashift:SI (subreg:SI (reg:DF 68 fr4 [ x ]) 0)

(const_int 8 [0x8]))) sh_tmp.cpp:28 149 {ashlsi3_k}

 (expr_list:REG_DEAD (reg:DF 68 fr4 [ x ])

(nil)))





The problem is that 'arith_reg_operand' matches subregs of FP modes and so, for

example, combine folds insn sequences such as



(insn 8 7 9 2 (set (reg:SI 166)

(subreg:SI (reg:DI 165) 0)) sh_tmp.cpp:33 -1

 (nil))



(insn 9 8 10 2 (set (reg:SI 167)

(ashift:SI (reg:SI 166)

(const_int 8 [0x8]))) sh_tmp.cpp:33 -1

 (nil))





Adding this:



Index: gcc/config/sh/predicates.md

===

--- gcc/config/sh/predicates.md(revision 193423)

+++ gcc/config/sh/predicates.md(working copy)

@@ -156,7 +156,12 @@

   if (REG_P (op))

 regno = REGNO (op);

   else if (GET_CODE (op) == SUBREG  REG_P (SUBREG_REG (op)))

-regno = REGNO (SUBREG_REG (op));

+{

+  regno = REGNO (SUBREG_REG (op));

+  if (!(GET_MODE_CLASS (GET_MODE (SUBREG_REG (op))) == MODE_INT

+|| GET_MODE_CLASS (GET_MODE (SUBREG_REG (op))) ==

MODE_VECTOR_INT))

+return false;

+} 

   else

 return 1;





makes the unwanted subreg propagation go away, but ends up in another reload

trouble:



sh_tmp.cpp:92:1: error: unable to find a register to spill in class

'TARGET_REGS'

 }

 ^

sh_tmp.cpp:92:1: error: this is the insn:

(insn 7 4 8 2 (set (reg:SI 1 r1 [165])

(subreg:SI (reg:DF 70 fr6 [ y ]) 0)) sh_tmp.cpp:91 244 {movsi_ie}

 (expr_list:REG_DEAD (reg:DF 70 fr6 [ y ])

(nil)))



On little endian this problem does not happen and the same insn right before

the reload pass looks like:



(insn 7 4 8 2 (set (reg:SI 165)

(subreg:SI (reg/v:DF 163 [ y ]) 4)) sh_tmp.cpp:91 244 {movsi_ie}

 (expr_list:REG_DEAD (reg/v:DF 163 [ y ])

(nil)))



Notice that on big endian the insn contains hard regs.

I've tried tapping sh_secondary_reload and there are some weird things

happening such as:



in = 1  rlcass = 8  mode = SI  x = (reg:DF 70 fr6 [ y ])



 -- rclass = 5



This is caused by the way sh_cannot_change_mode_class handles stuff on big

endian.  Adding this to 'sh_cannot_change_mode_class':



  if (from == DFmode  to == SImode)

return true;



fixes at least one of the test cases, but I'm totally unaware of the


[Bug fortran/55314] New: [4.6/4.7/4.8 Regression] Rejects some valid ALLOCATE statements

2012-11-13 Thread tkoenig at gcc dot gnu.org


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



 Bug #: 55314

   Summary: [4.6/4.7/4.8 Regression] Rejects some valid ALLOCATE

statements

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: tkoe...@gcc.gnu.org





Test case by Jacob Weisman Poulsen:



jwp@wrapcrap:~$ cat test.f90 

program main

  implicit none

  integer :: max_nb

  type comm_mask

integer(4), pointer :: mask(:)

  end type comm_mask

  type (comm_mask), allocatable, save :: encode(:,:)

  max_nb=2

  allocate( encode(1:1,1:max_nb))

  allocate( encode(1,1)%mask(1),encode(1,2)%mask(1))

end program main



jwp@wrapcrap:~$ gfortran test.f90 

test.f90:10.12-32:



  allocate( encode(1,1)%mask(1),encode(1,2)%mask(1))

1   2

Error: Allocate-object at (1) also appears at (2)


[Bug fortran/55314] [4.6/4.7/4.8 Regression] Rejects some valid ALLOCATE statements

2012-11-13 Thread tkoenig at gcc dot gnu.org


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



Thomas Koenig tkoenig at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2012-11-13

 AssignedTo|unassigned at gcc dot   |tkoenig at gcc dot gnu.org

   |gnu.org |

   Target Milestone|--- |4.6.4

 Ever Confirmed|0   |1


[Bug rtl-optimization/55315] New: comparing address to constant is folded in cse

2012-11-13 Thread vries at gcc dot gnu.org


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



 Bug #: 55315

   Summary: comparing address to constant is folded in cse

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: rtl-optimization

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: vr...@gcc.gnu.org





Consider test.c:

...

int data[4096];



int

f (void)

{

  return ((unsigned int) data[0]) == 0xdeadbea0U;

}

...



Although the address is not available at compile time, the compiler (mips

target) concludes it's not equal to the constant:

...

$ gcc test.c -O2 -o- -S

...

f:

j   $31

move$2,$0

...



The comparison:

  ((unsigned int) data[0]) == 0xdeadbea0U

is transformed into this by expand:

  ((unsigned int) data[0]) + (~0xdeadbea0U + 1) == 0



Then cse uses this part of nonzero_address_p:

...

case PLUS:

  if (CONST_INT_P (XEXP (x, 1)))

return nonzero_address_p (XEXP (x, 0));

...

to determine that ((unsigned int) data[0]) + (~0xdeadbea0U + 1) is non-null,

while there is no evidence that the PLUS is an address.



This is similar to PR29519, and the test-case of this PR is mentioned in

comment 5.



configure line:

...

Target: mipsisa32r2-sde-elf

Configured with: src/gcc-mainline/configure --build=i686-pc-linux-gnu

--host=i686-pc-linux-gnu --target=mipsisa32r2-sde-elf --enable-threads

--disable-libmudflap --disable-libssp --disable-libstdcxx-pch --with-gnu-as

--with-gnu-ld --enable-languages=c,c++ --disable-shared --enable-lto

--with-newlib --disable-nls --disable-shared --disable-threads --disable-libssp

--disable-libgomp --without-headers --with-newlib --disable-decimal-float

--disable-libffi --disable-libquadmath --disable-libitm --disable-libatomic

--enable-languages=c --with-build-sysroot=install/mipsisa32r2-sde-elf

--with-gmp=obj/pkg-mainline-0-mipsisa32r2-sde-elf/fsf-mainline-0-mipsisa32r2-sde-elf.extras/host-libs-i686-pc-linux-gnu/usr

--with-mpfr=obj/pkg-mainline-0-mipsisa32r2-sde-elf/fsf-mainline-0-mipsisa32r2-sde-elf.extras/host-libs-i686-pc-linux-gnu/usr

--with-mpc=obj/pkg-mainline-0-mipsisa32r2-sde-elf/fsf-mainline-0-mipsisa32r2-sde-elf.extras/host-libs-i686-pc-linux-gnu/usr

--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'

--with-isl=obj/pkg-mainline-0-mipsisa32r2-sde-elf/fsf-mainline-0-mipsisa32r2-sde-elf.extras/host-libs-i686-pc-linux-gnu/usr

--with-cloog=obj/pkg-mainline-0-mipsisa32r2-sde-elf/fsf-mainline-0-mipsisa32r2-sde-elf.extras/host-libs-i686-pc-linux-gnu/usr

--with-libelf=obj/pkg-mainline-0-mipsisa32r2-sde-elf/fsf-mainline-0-mipsisa32r2-sde-elf.extras/host-libs-i686-pc-linux-gnu/usr

--disable-libgomp --disable-libitm --enable-poison-system-directories

--with-build-time-tools=install/mipsisa32r2-sde-elf/bin

Thread model: single

gcc version 4.8.0 20121113 (experimental) (GCC) 

...


[Bug fortran/55314] [4.6/4.7/4.8 Regression] Rejects some valid ALLOCATE statements

2012-11-13 Thread tkoenig at gcc dot gnu.org


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



--- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-13 
22:59:22 UTC ---

Here's a tentative patch:



Index: resolve.c

===

--- resolve.c   (Revision 192894)

+++ resolve.c   (Arbeitskopie)

@@ -7618,12 +7618,18 @@ resolve_allocate_deallocate (gfc_code *code, const



  if (pr-next  qr-next)

{

+ int i;

  gfc_array_ref *par = (pr-u.ar);

  gfc_array_ref *qar = (qr-u.ar);

- if ((par-start[0] != NULL || qar-start[0] != NULL)

-  gfc_dep_compare_expr (par-start[0],

-  qar-start[0]) != 0)

-   break;

+

+ for (i=0; ipar-dimen; i++)

+   {

+ if ((par-start[i] != NULL

+  || qar-start[i] != NULL)

+  gfc_dep_compare_expr (par-start[i],

+  qar-start[i]) != 0)

+   goto break_label;

+   }

}

}

  else

@@ -7635,6 +7641,8 @@ resolve_allocate_deallocate (gfc_code *code, const

  pr = pr-next;

  qr = qr-next;

}

+   break_label:

+ ;

}

}

 }


[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files

2012-11-13 Thread dominiq at lps dot ens.fr


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



--- Comment #18 from Dominique d'Humieres dominiq at lps dot ens.fr 
2012-11-13 23:21:35 UTC ---

 prototype patch for adding darwin asan support



Already updated;-(





-  x86_64-*-linux-* | i?86-*-linux-*)

+  x86_64-*-linux-* | i?86-*-linux-* | *-*-darwin*)



should now go to libsanitizer/configure.tgt and not to configure.ac.


[Bug middle-end/52285] [4.7/4.8 Regression] libgcrypt _gcry_burn_stack slowdown

2012-11-13 Thread steven at gcc dot gnu.org


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



--- Comment #12 from Steven Bosscher steven at gcc dot gnu.org 2012-11-13 
23:37:52 UTC ---

Created attachment 28678

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28678

Gross hack



(In reply to comment #11)

 If loops are still around at LRA time, perhaps LRA should consider putting

 it before loop if register pressure is low, or LIM could just have extra

 code for this



Unfortunately, loop are destroyed _just_ before LRA, at the end of IRA.

IRA has its own loop tree but that is destroyed before LRA, too.





 I'm not saying it must be LIM, I'm

 just looking for suggestions where to perform this.



LIM may be too early. I've experimented with the attached patch (based off

some other patch for invariant addresses that was bit-rotting on a shelf)

and I had to resort to some crude hacks to make loop-invariant even just

consider moving the bare frame_pointer_rtx, like manually setting the cost

to something high because set_src_cost(frame_pointer_rtx)==0.  The result

is this code:



foo:

leaq-72(%rsp), %rcx

leaq-8(%rsp), %rdx // A Pyrrhic victory...

.p2align 4,,10

.p2align 3

.L5:

movq%rcx, %rax

.p2align 4,,10

.p2align 3

.L3:

movb$0, (%rax)

addq$1, %rax

cmpq%rdx, %rax

jne .L3

subl$64, %edi

testl   %edi, %edi

jg  .L5

rep ret





Need to think about this a bit more, perhaps postreload-gcse can be used

for this instead of LIM...


[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

2012-11-13 Thread steven at gcc dot gnu.org


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



--- Comment #6 from Steven Bosscher steven at gcc dot gnu.org 2012-11-13 
23:38:55 UTC ---

(In reply to comment #5)

 Created attachment 28673 [details]

 gcc48-pr43631.patch

 

 Is this what you meant?



Yes, that's exactly what I meant, thanks!


[Bug target/55316] New: gcc/libsanitizer/asan/asan_linux.cc:70:3: error: #error Unsupported arch

2012-11-13 Thread danglin at gcc dot gnu.org


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



 Bug #: 55316

   Summary: gcc/libsanitizer/asan/asan_linux.cc:70:3: error:

#error Unsupported  arch

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: dang...@gcc.gnu.org

  Host: hppa-unknown-linux-gnu

Target: hppa-unknown-linux-gnu

 Build: hppa-unknown-linux-gnu





libtool: compile:  /home/dave/gnu/gcc/objdir/./gcc/g++ -

B/home/dave/gnu/gcc/objdir/./gcc/ -nostdinc++ -nostdinc++

-I/home/dave/gnu/gcc/o

bjdir/hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu

-I/home/dave/gnu/gcc/ob

jdir/hppa-linux-gnu/libstdc++-v3/include

-I/home/dave/gnu/gcc/gcc/libstdc++-v3/l

ibsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward

-I/home/dave/gnu

/gcc/gcc/libstdc++-v3/testsuite/util

-L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/

libstdc++-v3/src

-L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.li

bs -B/home/dave/opt/gnu/gcc/gcc-4.8.0/hppa-linux-gnu/bin/

-B/home/dave/opt/gnu/g

cc/gcc-4.8.0/hppa-linux-gnu/lib/ -isystem

/home/dave/opt/gnu/gcc/gcc-4.8.0/hppa-

linux-gnu/include -isystem

/home/dave/opt/gnu/gcc/gcc-4.8.0/hppa-linux-gnu/sys-i

nclude -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS

-D

__STDC_LIMIT_MACROS -DASAN_HAS_EXCEPTIONS=1

-DASAN_FLEXIBLE_MAPPING_AND_OFFSET=0

 -DASAN_NEEDS_SEGV=1 -I. -I../../../../gcc/libsanitizer/asan -I

../../../../gcc/

libsanitizer/include -I ../../../../gcc/libsanitizer -Wall -W

-Wno-unused-parame

ter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions 

-fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros

-W

no-c99-extensions -g -O2 -D_GNU_SOURCE -MT asan_linux.lo -MD -MP -MF

.deps/asan_

linux.Tpo -c ../../../../gcc/libsanitizer/asan/asan_linux.cc  -fPIC -DPIC -o

.li

bs/asan_linux.o

../../../../gcc/libsanitizer/asan/asan_linux.cc:70:3: error: #error

Unsupported arch

 # error Unsupported arch

   ^

cc1plus: warning: unrecognized command line option -Wno-c99-extensions

[enabled by default]

make[3]: *** [asan_linux.lo] Error 1


[Bug ada/55243] STAMP variable is not defined in t-avr

2012-11-13 Thread gjl at gcc dot gnu.org


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



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



   What|Removed |Added



  Component|target  |ada



--- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-11-14 
00:00:24 UTC ---

t-avr is the wrong place to set STAMP, it should be set in some Makefile(.in),

presumable in the ada part, somewhere around



./gcc/ada/gcc-interface/Makefile.in



You see STAMP being mentioned in repsective config.log?


[Bug other/55304] libsanitizer can't be used with GCC autoconf

2012-11-13 Thread hjl at gcc dot gnu.org


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



--- Comment #5 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-11-14 
00:02:16 UTC ---

Author: hjl

Date: Wed Nov 14 00:02:12 2012

New Revision: 193491



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

Log:

Update configure.ac for GCC tree and remove unused files



PR other/55304

* acinclude.m4: New file.

* Makefile.am (ACLOCAL_AMFLAGS): New.

* configure.ac (AC_PREREQ): Set to 2.64.

(AC_CONFIG_AUX_DIR): Set to ...

* Makefile.in: Regenerated.

* aclocal.m4: Likewise.

* configure: Likewise.

* asan/Makefile.in: Likewise.

* interception/Makefile.in: Likewise.

* sanitizer_common/Makefile.in: Likewise.



* config.guess: Removed.

* config.sub: Likewise.

* depcomp: Likewise.

* install-sh: Likewise.

* ltmain.sh: Likewise.

* missing: Likewise.



Added:

trunk/libsanitizer/acinclude.m4

Removed:

trunk/libsanitizer/config.guess

trunk/libsanitizer/config.sub

trunk/libsanitizer/depcomp

trunk/libsanitizer/install-sh

trunk/libsanitizer/ltmain.sh

trunk/libsanitizer/missing

Modified:

trunk/libsanitizer/ChangeLog.asan

trunk/libsanitizer/Makefile.am

trunk/libsanitizer/Makefile.in

trunk/libsanitizer/aclocal.m4

trunk/libsanitizer/asan/Makefile.in

trunk/libsanitizer/configure

trunk/libsanitizer/configure.ac

trunk/libsanitizer/interception/Makefile.in

trunk/libsanitizer/sanitizer_common/Makefile.in


[Bug other/55304] libsanitizer can't be used with GCC autoconf

2012-11-13 Thread hjl.tools at gmail dot com


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



H.J. Lu hjl.tools at gmail dot com changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2012-11-14 00:02:55 
UTC ---

Fixed.


[Bug target/55317] New: [i386-regression] just don't strip stdcall suffix in gcc

2012-11-13 Thread jojelino at gmail dot com


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



 Bug #: 55317

   Summary: [i386-regression] just don't strip stdcall suffix in

gcc

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: blocker

  Priority: P3

 Component: target

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: jojel...@gmail.com





Created attachment 28679

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28679

testcase



It resulted in link error while building libgcc.



$ /tmp/gcc/host-i686-pc-cygwin/gcc/xgcc -B/tmp/gcc/host-i686-pc-cygwin/gcc/

-B/usr/i686-pc-cygwin/bin/ -B/usr/i686-pc-cygwin/lib/ -isystem

/usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin/sys-include -v

Reading specs from /tmp/gcc/host-i686-pc-cygwin/gcc/specs

COLLECT_GCC=/tmp/gcc/host-i686-pc-cygwin/gcc/xgcc

COLLECT_LTO_WRAPPER=/tmp/gcc/host-i686-pc-cygwin/gcc/lto-wrapper.exe

Target: i686-pc-cygwin

Configured with: ./configure --config-cache --enable-plugin --prefix=/usr

--disable-win32-registry --enable-threads=win32

--enable-languages=c,c++,lto,fortran --with-win32-nlsapi=unicode --enable-tls

--disable-bootstrap --enable-shared --disable-sjlj-exceptions --enable-gomp

--enable-cloog-backend=isl LTLDFLAGS=-no-undefined

lt_cv_deplibs_check_method=pass_all : (reconfigured) ./configure --config-cache

--enable-plugin --prefix=/usr --disable-win32-registry --enable-threads=win32

--enable-languages=c,c++,lto,fortran --with-win32-nlsapi=unicode --enable-tls

--disable-bootstrap --enable-shared --disable-sjlj-exceptions --enable-gomp

--enable-cloog-backend=isl LTLDFLAGS=-no-undefined

lt_cv_deplibs_check_method=pass_all : (reconfigured) ./configure --config-cache

--prefix=/usr --disable-win32-registry --enable-threads=win32

--enable-languages=c,c++,lto,fortran --with-win32-nlsapi=unicode --enable-tls

--disable-bootstrap --enable-shared --disable-sjlj-exceptions --enable-gomp

--enable-cloog-backend=isl LTLDFLAGS=-no-undefined

lt_cv_deplibs_check_method=pass_all

Thread model: win32

gcc version 4.8.0 20121113 (experimental) (GCC)



Use --enable-stdcall-fixup to disable these warnings

Use --disable-stdcall-fixup to disable these fixups

/tmp/gcc/host-i686-pc-cygwin/gcc/crtbegin.o:cygming-crtbegin.c:(.text+0x2f):

undefined reference to `__imp__GetProcAddress'

/tmp/gcc/host-i686-pc-cygwin/gcc/crtbegin.o:cygming-crtbegin.c:(.text+0x78):

undefined reference to `__imp__GetProcAddress'

/tmp/gcc/host-i686-pc-cygwin/gcc/crtbegin.o:cygming-crtbegin.c:(.text+0xcc):

undefined reference to `__imp__GetProcAddress'

/usr/i686-pc-cygwin/bin/ld: /tmp/gcc/host-i686-pc-cygwin/gcc/crtbegin.o: bad

reloc address 0x20 in section `.eh_frame'

collect2: error: ld returned 1 exit status

Makefile:921: recipe for target `libgcc_s.dll' failed



And there is no such __imp__GetProcAddress symbol defined in libkernel32.a



$ nm -sn /lib/w32api/libkernel32.a |grep GetProcAddress

_GetProcAddress@8 in degqcs00553.o

__imp__GetProcAddress@8 in degqcs00553.o

 I __imp__GetProcAddress@8

 T _GetProcAddress@8



i confirmed that 4.8.0 20121002 has no problem like this

$ gcc -v test.c

Using built-in specs.

COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-cygwin/4.8.0/lto-wrapper.exe

Target: i686-pc-cygwin

Configured with: ./configure --config-cache --prefix=/usr

--disable-win32-registry --enable-threads=win32

--enable-languages=c,c++,lto,fortran --with-win32-nlsapi=unicode --enable-tls

--disable-bootstrap --enable-shared --disable-sjlj-exceptions --enable-gomp

--enable-cloog-backend=isl LTLDFLAGS=-no-undefined

lt_cv_deplibs_check_method=pass_all

Thread model: win32

gcc version 4.8.0 20121002 (experimental) (GCC)

COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=pentiumpro'

 /usr/libexec/gcc/i686-pc-cygwin/4.8.0/cc1.exe -quiet -v -D__CYGWIN32__

-D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter

/usr/lib/gcc/i686-pc-cygwin/4.8.0/../../../../i686-pc-cygwin/lib/../include/w32api

-idirafter

/usr/lib/gcc/i686-pc-cygwin/4.8.0/../../../../i686-pc-cygwin/lib/../../include/w32api

test.c -quiet -dumpbase test.c -mtune=generic -march=pentiumpro -auxbase test

-version -o /tmp/ccI4wcdv.s

GNU C (GCC) version 4.8.0 20121002 (experimental) (i686-pc-cygwin)

compiled by GNU C version 4.8.0 20120821 (experimental), GMP version

5.0.2, MPFR version 3.2.0-dev, MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

ignoring duplicate directory /usr/include

ignoring duplicate directory

/usr/lib/gcc/i686-pc-cygwin/4.8.0/../../../../i686-pc-cygwin/lib/../../include/w32api

#include ... search starts here:

#include ... search starts here:

 /usr/lib/gcc/i686-pc-cygwin/4.8.0/include

 /usr/local/include

 /usr/lib/gcc/i686-pc-cygwin/4.8.0/include-fixed

 /usr/lib/gcc/i686-pc-cygwin/4.8.0/../../../../i686-pc-cygwin/include



/usr/lib/gcc

[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files

2012-11-13 Thread howarth at nitro dot med.uc.edu


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



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



   What|Removed |Added



  Attachment #28677|0   |1

is obsolete||



--- Comment #19 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-14 
01:28:44 UTC ---

Created attachment 28680

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28680

revised prototype patch for adding darwin asan support


[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files

2012-11-13 Thread howarth at nitro dot med.uc.edu


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



--- Comment #20 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-14 
01:30:13 UTC ---

Revised patch builds at r193494 after...



cd libsanitizer

autoconf -I. -I../config

automake-1.11



[Bug c++/55318] New: Missing uninitialized warning

2012-11-13 Thread brunonery+bugzilla at brunonery dot com


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



 Bug #: 55318

   Summary: Missing uninitialized warning

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: brunonery+bugzi...@brunonery.com





The following piece of code:



=== snip ===

#include iostream



struct warnme

{

bool member_;

warnme(bool member) : member_(member_) {}

};



int main()

{

warnme wm(true);

std::cout  wm.member_  std::endl;

return 0;

}

=== end snip ===



when compiled with g++ 4.7, gives me no warnings - even with

-Wuninitialized (clang++ 3.1 works fine).


[Bug c++/55319] New: Using -fwhole-program inhibits optimization

2012-11-13 Thread m101010a at gmail dot com


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



 Bug #: 55319

   Summary: Using -fwhole-program inhibits optimization

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: m1010...@gmail.com





Created attachment 28681

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28681

The preprocessed source



The attached code is a template-based brainfuck interpreter, and the brainfuck

code in it prints Hello world!.  When the attached code is compiled with g++

-std=c++11 -O2 bf.ii, it produces a series of calls to _IO_putc which directly

print Hello World!.  However, when compiled with g++ -std=c++11 -O2

-fwhole-program bf.ii, it produces a more direct and less optimized

interpretation of the associated brainfuck.



$ gcc -v

Using built-in specs.

COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: /build/src/gcc-4.7.2/configure --prefix=/usr --libdir=/usr/lib

--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info

--with-bugurl=https://bugs.archlinux.org/

--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared

--enable-threads=posix --with-system-zlib --enable-__cxa_atexit

--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch

--enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id

--with-ppl --enable-cloog-backend=isl --disable-ppl-version-check

--disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default

--enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu

--enable-multilib --disable-libssp --disable-build-with-cxx

--disable-build-poststage1-with-cxx --enable-checking=release

Thread model: posix

gcc version 4.7.2 (GCC)


  1   2   >