[Bug tree-optimization/56478] [4.8 Regression] ICE: Floating point exception in tree_estimate_probability

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||dehao at gcc dot gnu.org



--- Comment #2 from Jakub Jelinek  2013-02-28 
08:05:03 UTC ---

loop_bound = compare_bound = 0

base = -9223372036854775808

so

HOST_WIDE_INT loop_count = (loop_bound - base) / compare_step;

first invokes undefined behavior (loop_bound - base) computation and then

-LONG_LONG_MIN / -1 SIGFPEs.

That and the following code is just full of many potential undefined behaviors.

Even the compare_count++ or loop_count++ could trigger that.

[Bug tree-optimization/56478] [4.8 Regression] ICE: Floating point exception in tree_estimate_probability

[jakub at gcc dot gnu.org]

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



--- Comment #3 from Jakub Jelinek  2013-02-28 
08:15:19 UTC ---

There are other issues, like e.g. using int type to store step, with:

  if (host_integerp (iv0.step, 0))

step = tree_low_cst (iv0.step, 0);

guard for that.  host_integerp checks if the value fits into singed

HOST_WIDE_INT, not int, so if the step will be 0x123ULL, you'll happily

set step to 0, then divide by zero, etc.

I'd say safest would be to store step as tree (just verify it is INTEGER_CST),

and do all the arithmetics on trees, then look if we could fold it into a

non-TREE_OVERFLOW constant.

[Bug c++/56480] New: Explicit specialization in a namespace enclosing the specialized template

[zeratul976 at hotmail dot com]

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



 Bug #: 56480

   Summary: Explicit specialization in a namespace enclosing the

specialized template

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: zeratul...@hotmail.com





The following code:





namespace Foo 

{

template 

struct Meow

{

};

}



template <>

struct Foo::Meow

{

};





fails to compile with gcc 4.8 (tested with 20130224 snapshot). 



I believe this code should be accepted in C++11 mode as per [temp.expl.spec]

p2: "An explicit specialization shall be declared in a namespace enclosing the

specialized template." This is a relaxation of the C++03 wording: "An explicit

specialization shall be declared in the namespace of which the template is a

member".



Recent versions of clang and MSVC compile the above code in C++11 mode.

[Bug libstdc++/56475] Incorrect result of configure test for /dev/random (_GLIBCXX_USE_RANDOM_TR1) for MinGW platform (and others?)

[ktietz at gcc dot gnu.org]

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



--- Comment #6 from Kai Tietz  2013-02-28 08:43:30 
UTC ---

(In reply to comment #4)

> I agree. Care to send a patch for that?



Well, something like this should fix the issue:



Index: acinclude.m4

===

--- acinclude.m4(Revision 196329)

+++ acinclude.m4(Arbeitskopie)

@@ -1739,7 +1739,10 @@ AC_DEFUN([GLIBCXX_CHECK_RANDOM_TR1], [

   AC_MSG_CHECKING([for "/dev/random" and "/dev/urandom" for TR1

random_device])



   AC_CACHE_VAL(glibcxx_cv_random_tr1, [

 if test -r /dev/random && test -r /dev/urandom; then

-  glibcxx_cv_random_tr1=yes;

+  case ${target_os} in

+   *mingw*) glibcxx_cv_random_tr1=no ;;

+   *) glibcxx_cv_random_tr1=yes ;;

+  esac

 else

   glibcxx_cv_random_tr1=no;

 fi

[Bug target/56445] avr.c:11551:16: error: invoking macro FX_FTYPE_FX ar gument 1: empty macro arguments are undefined

[gjl at gcc dot gnu.org]

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



--- Comment #1 from Georg-Johann Lay  2013-02-28 
09:16:15 UTC ---

Author: gjl

Date: Thu Feb 28 09:16:08 2013

New Revision: 196332



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

Log:

PR target/56445

* config/avr/avr.c (avr_init_builtins): Use 'n' instead of empty

macro parameters with: FX_FTYPE_FX, FX_FTYPE_FX_INT, INT_FTYPE_FX,

INTX_FTYPE_FX, FX_FTYPE_INTX.

* config/avr/builtins.def: Adjust respective DEF_BUILTIN.





Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/avr/avr.c

trunk/gcc/config/avr/builtins.def

[Bug target/56445] avr.c:11551:16: error: invoking macro FX_FTYPE_FX ar gument 1: empty macro arguments are undefined

[gjl at gcc dot gnu.org]

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



Georg-Johann Lay  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||gjl at gcc dot gnu.org

 Resolution||FIXED



--- Comment #2 from Georg-Johann Lay  2013-02-28 
09:19:29 UTC ---

Fixed

[Bug target/54640] arm_adjust_block_mem: signed/unsigned comparison

[amylaar at gcc dot gnu.org]

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



Jorn Wolfgang Rennecke  changed:



   What|Removed |Added



   Last reconfirmed|2013-02-25 00:00:00 |2013-02-27 0:00



--- Comment #2 from Jorn Wolfgang Rennecke  
2013-02-28 09:33:49 UTC ---

I have reverted my patch because of an objection by Richard Earnshaw on the

gcc-patches mailing list:

>> -  HOST_WIDE_INT hi_val = (i >> 32) & 0x;

>> +  HOST_WIDE_INT hi_val = (i >> 16 >> 16) & 0x;



I'm not convinced this is obvious.  It's certainly ugly.



> I think the correct thing to do is to force all ARM targets to use a 64-bit 
> HOST_WIDE_INT.

[Bug libstdc++/56475] Incorrect result of configure test for /dev/random (_GLIBCXX_USE_RANDOM_TR1) for MinGW platform (and others?)

[paolo.carlini at oracle dot com]

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



--- Comment #7 from Paolo Carlini  2013-02-28 
09:45:50 UTC ---

Good. I would say, please add a one line comment mentioning the MSYS subsystem

issue, etc, test and commit at your ease. Thanks!

[Bug target/48901] lm32.md: ashlsi3: error: unused variable ‘one’

[amylaar at gcc dot gnu.org]

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



Jorn Wolfgang Rennecke  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #2 from Jorn Wolfgang Rennecke  
2013-02-28 09:46:00 UTC ---

insn-emit.o builds now without complaints.  However, we now hit PR55035.

[Bug target/54662] Wrong warning flags for building mep-pragma.o, fails to build

[amylaar at gcc dot gnu.org]

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



--- Comment #2 from Jorn Wolfgang Rennecke  
2013-02-28 09:49:36 UTC ---

mep-elf builds OK now.

[Bug c++/55813] Poorly named/documented option Wctor-dtor-privacy

[paolo at gcc dot gnu.org]

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



--- Comment #2 from paolo at gcc dot gnu.org  
2013-02-28 10:01:04 UTC ---

Author: paolo

Date: Thu Feb 28 10:00:54 2013

New Revision: 196334



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

Log:

2013-02-28  Paolo Carlini  



PR c++/55813

* doc/invoke.texi ([-Wctor-dtor-privacy]): Complete.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/doc/invoke.texi

[Bug other/49401] Warning regression for 'uninitialized' variable on non-existant code path (in mep-pragma.c)

[amylaar at gcc dot gnu.org]

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

--- Comment #1 from Jorn Wolfgang Rennecke  
2013-02-28 10:01:16 UTC ---
mep-elf builds OK now.
However, this is also a diagnostics issue, that has to be checked with
the preprocessed source from the attachment.
gcc (GCC) 4.8.0 20130225 on i686-pc-linux-gnu says now:
../../../gcc/gcc/tree.h:3225:11: error: identifier ‘thread_local’ conflicts
with C++ keyword [-Werror=c++-compat]
so I suppose that's OK.
However, the bug was reported for host x86_64-unknown-linux-gnu, so we need to
test with a recent compiler bootstrapped on that host to verify.
Our optimizers often behave differently with differently sized HOST_WIDE_INT.

[Bug c++/55813] Poorly named/documented option Wctor-dtor-privacy

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.8.0



--- Comment #3 from Paolo Carlini  2013-02-28 
10:03:03 UTC ---

Done.

[Bug target/52500] dwarf2cfi.c fails to build with -Werror for c6x

[amylaar at gcc dot gnu.org]

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



Jorn Wolfgang Rennecke  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #3 from Jorn Wolfgang Rennecke  
2013-02-28 10:04:28 UTC ---

c6x-elf / c6x-uclinux build OK now.

[Bug target/52550] tile*.c: unused variable ‘cfa_offset’

[amylaar at gcc dot gnu.org]

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



Jorn Wolfgang Rennecke  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #2 from Jorn Wolfgang Rennecke  
2013-02-28 10:07:51 UTC ---

tilegx-linux-gnu / tilepro-linux-gnu build OK now.

[Bug target/54639] mn10300_expand_epilogue: signed / unsigned comparison

[amylaar at gcc dot gnu.org]

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



--- Comment #2 from Jorn Wolfgang Rennecke  
2013-02-28 10:09:45 UTC ---

am33_2.0-linux / mn10300-elf build OK now.

[Bug target/52501] cr16-protos.h uses enum rtx_code outside #ifdef RTX_CODE guard

[amylaar at gcc dot gnu.org]

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



Jorn Wolfgang Rennecke  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #4 from Jorn Wolfgang Rennecke  
2013-02-28 10:12:34 UTC ---

See above.

[Bug target/54639] mn10300_expand_epilogue: signed / unsigned comparison

[amylaar at gcc dot gnu.org]

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



Jorn Wolfgang Rennecke  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #3 from Jorn Wolfgang Rennecke  
2013-02-28 10:13:50 UTC ---

See above.

[Bug rtl-optimization/56466] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1629 (loop with header n not in loop tree !)

[mpolacek at gcc dot gnu.org]

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



--- Comment #6 from Marek Polacek  2013-02-28 
10:13:53 UTC ---

Author: mpolacek

Date: Thu Feb 28 10:13:48 2013

New Revision: 196335



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

Log:

PR rtl-optimization/56466

* loop-unroll.c (unroll_and_peel_loops): Call fix_loop_structure

if we're changing a loop.

(peel_loops_completely): Likewise.





Added:

trunk/gcc/testsuite/gcc.dg/pr56466.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/loop-unroll.c

trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/56466] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1629 (loop with header n not in loop tree !)

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #7 from Marek Polacek  2013-02-28 
10:15:19 UTC ---

Fixed.

[Bug target/54662] Wrong warning flags for building mep-pragma.o, fails to build

[amylaar at gcc dot gnu.org]

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



Jorn Wolfgang Rennecke  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #3 from Jorn Wolfgang Rennecke  
2013-02-28 10:15:47 UTC ---

See above.(In reply to comment #2)

> mep-elf builds OK now.

[Bug c++/56481] New: [4.8 Regression] endless loop compiling a C++ file

[doko at gcc dot gnu.org]

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



 Bug #: 56481

   Summary: [4.8 Regression] endless loop compiling a C++ file

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: d...@gcc.gnu.org





Created attachment 29549

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

preprocessed source



seen with 4.8.0 20130223 (experimental) [trunk revision 196236]

seen as well with -g, -fopenmp, -O



$ g++ -c GuiFilesModified.ii



0  0x005e2a3e in ?? ()

#1  0x005e2f5d in ?? ()

#2  0x005e357f in ?? ()

#3  0x005e2b22 in ?? ()

#4  0x005e4ca7 in ?? ()

#5  0x005e5a4a in ?? ()

#6  0x005e4f2a in maybe_constant_value(tree_node*) ()

#7  0x005e5a4a in ?? ()

#8  0x005e4f2a in maybe_constant_value(tree_node*) ()

#9  0x005e5a4a in ?? ()

#10 0x005e5481 in ?? ()

#11 0x005e4f2a in maybe_constant_value(tree_node*) ()

#12 0x005e5a4a in ?? ()

#13 0x005e5481 in ?? ()

#14 0x005e5481 in ?? ()

#15 0x005e5481 in ?? ()

#16 0x005e4f2a in maybe_constant_value(tree_node*) ()

#17 0x005e5a4a in ?? ()

#18 0x005e4f2a in maybe_constant_value(tree_node*) ()

#19 0x005e5a4a in ?? ()

#20 0x005e4f2a in maybe_constant_value(tree_node*) ()

[Bug ada/56474] [4.8 regression] bogus Storage_Error raised for record containing empty zero-based array

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-28

 CC||ebotcazou at gcc dot

   ||gnu.org

   Target Milestone|--- |4.8.0

Summary|GNAT computes size of the   |[4.8 regression] bogus

   |object to be allocated  |Storage_Error raised for

   |incorrectly |record containing empty

   ||zero-based array

 Ever Confirmed|0   |1

   Severity|critical|normal



--- Comment #1 from Eric Botcazou  2013-02-28 
11:01:37 UTC ---

Strange, we would rather lose warnings than issue bogus ones here.



In any case, the workaround is easy: use 1-based arrays instead.

[Bug ada/56474] [4.8 regression] bogus Storage_Error raised for record containing empty zero-based array

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



 CC|ebotcazou at gcc dot|

   |gnu.org |

 AssignedTo|unassigned at gcc dot   |ebotcazou at gcc dot

   |gnu.org |gnu.org



--- Comment #2 from Eric Botcazou  2013-02-28 
11:03:22 UTC ---

Investigating.

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

[kcc at gcc dot gnu.org]

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



--- Comment #57 from Kostya Serebryany  2013-02-28 
11:31:54 UTC ---

I've created a page that describes how I run SPEC with asan. 

There is also a patch that works around the known SPEC bugs.



https://code.google.com/p/address-sanitizer/wiki/RunningSpecBenchmarks

https://code.google.com/p/address-sanitizer/source/browse/trunk/spec/spec2006-asan.patch

[Bug c++/56481] [4.8 Regression] endless loop compiling a C++ file

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-28

 CC||jakub at gcc dot gnu.org,

   ||jason at gcc dot gnu.org

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #1 from Jakub Jelinek  2013-02-28 
11:59:57 UTC ---

Reduced testcase:

struct S

{

  bool foo () const;

#define A(n) , f##n##0, f##n##1, f##n##2, f##n##3

#define B(n) A(n##0) A(n##1) A(n##2) A(n##3)

#define C B(0) B(1) B(2) B(3)

  bool f C;

};



bool

S::foo () const

{

#undef A

#define A(n) && f##n##0 && f##n##1 && f##n##2 && f##n##3

  const bool ret = f C;

  return ret;

}





Started with my http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192862

It actually isn't endless, just the compile time complexity is bad.



The problem is I think in:

if (!potential_constant_expression_1 (op, rval, flags))

  return false;

if (!processing_template_decl)

  op = maybe_constant_value (op);

in TRUTH_{AND,OR}*_EXPR handling in potential_constant_expression_1, because

maybe_constant_value calls potential_constant_expression (op) again.

They are called with different second/third argument (false, tf_none inside

maybe_constant_value, or true (== rval), flags above) though, so I think the

fix wouldn't be as easy as inlining maybe_constant_value by hand here and

avoiding the potential_constant_expression there.

Jason, any ideas?

For large && or || expressions perhaps we could just handle the cases where

op is the same code specially, still we wouldn't get rid of the large

complexity if say TRUTH_AND*_EXPR is only in every second code and there is

some other code in between.

[Bug libgcc/56482] New: missing -lpthread in configure when checking for pthreads_num_processors_np

[k2k at narod dot ru]

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



 Bug #: 56482

   Summary: missing -lpthread in configure when checking for

pthreads_num_processors_np

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libgcc

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

ReportedBy: k...@narod.ru

  Host: mingw32

Target: mingw32, mingw32-w64





>From configure.log:



configure:20205: checking for pthreads_num_processors_np

configure:20244:  /dvlp/packages/gcc/build/4.7.2-i686-w64-mingw32/./gcc/xgcc

-shared-libgcc -B/dvlp/packages/gcc/build/4.7.2-i686-w64-mingw32/./gcc

-nostdinc++

-L/dvlp/packages/gcc/build/4.7.2-i686-w64-mingw32/i686-w64-mingw32/libstdc++-v3/src

-L/dvlp/packages/gcc/build/4.7.2-i686-w64-mingw32/i686-w64-mingw32/libstdc++-v3/src/.libs

-L/dvlp/mingw-w64-i686/i686-w64-mingw32/lib -L/dvlp/mingw-w64-i686/mingw/lib

-isystem /dvlp/mingw-w64-i686/i686-w64-mingw32/include -isystem

/dvlp/mingw-w64-i686/mingw/include -B/dvlp/mingw-w64-i686/i686-w64-mingw32/bin/

-B/dvlp/mingw-w64-i686/i686-w64-mingw32/lib/ -isystem

/dvlp/mingw-w64-i686/i686-w64-mingw32/include -isystem

/dvlp/mingw-w64-i686/i686-w64-mingw32/sys-include

-L/dvlp/packages/gcc/build/4.7.2-i686-w64-mingw32/./ld-o conftest.exe -g

-O2 -fno-exceptions   conftest.cpp  >&5

C:\Users\Karlson\AppData\Local\Temp\ccd7ltCc.o: In function `main':

T:\dvlp\packages\gcc\build\4.7.2-i686-w64-mingw32\i686-w64-mingw32\libstdc++-v3/conftest.cpp:76:

undefined reference to `_imp__pthread_num_processors_np'

collect2.exe: error: ld returned 1 exit status

configure:20244: $? = 1

configure: failed program was:







Configure didn't try with '-lpthread' flag, so result can't be linked with

libpthread.

[Bug sanitizer/56454] need to rename attribute no_address_safety_analysis to no_sanitize_address

[kcc at gcc dot gnu.org]

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



--- Comment #11 from Kostya Serebryany  2013-02-28 
12:01:34 UTC ---

Created attachment 29550

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

rename no_address_safety_analysis to no_sanitize_address



How do we decide? When is the deadline for 4.8? 

I've attached a patch that implements the new attribute and renames it

in the tests and in the docs, but still understands the old name



(I will not be able to submit the patch until March 11)

[Bug sanitizer/56454] need to rename attribute no_address_safety_analysis to no_sanitize_address

[jakub at gcc dot gnu.org]

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



--- Comment #12 from Jakub Jelinek  2013-02-28 
12:13:42 UTC ---

(In reply to comment #11)

> Created attachment 29550 [details]

> rename no_address_safety_analysis to no_sanitize_address

> 

> How do we decide? When is the deadline for 4.8? 

> I've attached a patch that implements the new attribute and renames it

> in the tests and in the docs, but still understands the old name

> 

> (I will not be able to submit the patch until March 11)



This doesn't DTRT with the old attribute, because you lookup_attribute only the

new name.

Either you'd need to look up also the old name, or

handle_no_address_safety_attribute would need to add the new name of the

attribute manually (and perhaps don't add the old name).



I can take care of it (and perhaps also introduce no_sanitize_thread attribute

- what exactly should be done when it is set?  Instrument atomics always, and

not instrument anything else?).



OT, are you ok with incrementing the kMidMemEnd value (see my mail from Friday

last week)?

[Bug libstdc++/56482] missing -lpthread in configure when checking for pthreads_num_processors_np

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-28

 Ever Confirmed|0   |1



--- Comment #1 from Jonathan Wakely  2013-02-28 
12:27:09 UTC ---

Those tests possibly shouldn't be link tests anyway, just compile tests.



Note to self, the comment on GLIBCXX_CHECK_SYSCTL_HW_NCPU wrongly mentions

[Bug sanitizer/56454] need to rename attribute no_address_safety_analysis to no_sanitize_address

[kcc at gcc dot gnu.org]

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



--- Comment #13 from Kostya Serebryany  2013-02-28 
12:36:12 UTC ---

> This doesn't DTRT with the old attribute, because you lookup_attribute only 
> the

> new name.

> Either you'd need to look up also the old name, or

> handle_no_address_safety_attribute would need to add the new name of the

> attribute manually (and perhaps don't add the old name).

> 

> I can take care of it

That would be awesome!



>  (and perhaps also introduce no_sanitize_thread attribute

> - what exactly should be done when it is set?  Instrument atomics always, and

> not instrument anything else?).



no_sanitize_thread is actually not implemented in clang either yet

(i.e. clang understands this attribute, but the instrumentation ignores it)



The plan is to not instrument plain loads/stores when the attribute is set,

while still instrumenting atomics and function entry/exit. 



> 

> OT, are you ok with incrementing the kMidMemEnd value (see my mail from Friday

> last week)?



Sorry, I missed the message. replied there.

[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure

[jamborm at gcc dot gnu.org]

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



--- Comment #12 from Martin Jambor  2013-02-28 
12:43:42 UTC ---

Author: jamborm

Date: Thu Feb 28 12:43:33 2013

New Revision: 196340



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

Log:

2013-02-28  Martin Jambor  



PR tree-optimization/56294

* tree-sra.c (analyze_access_subtree): Create replacement declarations.

Adjust dumping.

(get_access_replacement): Do not call create_access_replacement.

Assert a replacement exists.

(get_repl_default_def_ssa_name): Create the replacement declaration

itself.



testsuite/

* g++.dg/debug/pr56294.C: New test.





Added:

trunk/gcc/testsuite/g++.dg/debug/pr56294.C

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-sra.c

[Bug tree-optimization/49234] [4.5/4.7/4.8/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning

[aldyh at gcc dot gnu.org]

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



Aldy Hernandez  changed:



   What|Removed |Added



 CC||aldyh at gcc dot gnu.org

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

   |gnu.org |



--- Comment #6 from Aldy Hernandez  2013-02-28 
13:51:36 UTC ---

I'll take a look.

[Bug tree-optimization/56478] [4.8 Regression] ICE: Floating point exception in tree_estimate_probability

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #4 from Marek Polacek  2013-02-28 
13:53:54 UTC ---

On it.

[Bug libstdc++/56482] missing -lpthread in configure when checking for pthreads_num_processors_np

[k2k at narod dot ru]

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



--- Comment #2 from Karlson2k  2013-02-28 14:08:02 UTC ---

If it'll be only compile test, how result can be linked when dependence on

libpthread will be unknown?

[Bug libstdc++/56482] missing -lpthread in configure when checking for pthreads_num_processors_np

[redi at gcc dot gnu.org]

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



--- Comment #3 from Jonathan Wakely  2013-02-28 
14:27:48 UTC ---

The function is only used in src/c++11/thread.cc which will already be linked

to libpthread.so if needed.

[Bug libstdc++/56482] missing -lpthread in configure when checking for pthreads_num_processors_np

[redi at gcc dot gnu.org]

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



--- Comment #4 from Jonathan Wakely  2013-02-28 
14:29:10 UTC ---

Actually that might not be true ... the other functions used in thread.cc could

be linked to weak symbols.

[Bug lto/56483] New: LTO issue with expanding GIMPLE_COND

[ysrumyan at gmail dot com]

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



 Bug #: 56483

   Summary: LTO issue with expanding GIMPLE_COND

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: lto

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

ReportedBy: ysrum...@gmail.com





If we compile attached simple test-case with -flto and -fno-inline we can see

the following sequence of rtl produced for or-ed condition:



;; if (_5 != 0)



(insn 18 17 19 (set (reg:CCZ 17 flags)

(compare:CCZ (reg/v:QI 59 [ c ])

(const_int 45 [0x2d]))) t1.c:12 -1

 (nil))



(insn 19 18 20 (set (reg:QI 66 [ D.2371 ])

(eq:QI (reg:CCZ 17 flags)

(const_int 0 [0]))) t1.c:12 -1

 (nil))



(insn 20 19 21 (set (reg:CCZ 17 flags)

(compare:CCZ (reg/v:QI 59 [ c ])

(const_int 43 [0x2b]))) t1.c:12 -1

 (nil))



(insn 21 20 22 (set (reg:QI 68 [ D.2371 ])

(eq:QI (reg:CCZ 17 flags)

(const_int 0 [0]))) t1.c:12 -1

 (nil))



(insn 22 21 23 (parallel [

(set (reg:QI 69 [ D.2371 ])

(ior:QI (reg:QI 66 [ D.2371 ])

(reg:QI 68 [ D.2371 ])))

(clobber (reg:CC 17 flags))

]) t1.c:12 -1

 (nil))



(insn 23 22 24 (set (reg:CCZ 17 flags)

(compare:CCZ (reg:QI 69 [ D.2371 ])

(const_int 0 [0]))) t1.c:12 -1

 (nil))



(jump_insn 24 23 0 (set (pc)

(if_then_else (eq (reg:CCZ 17 flags)

(const_int 0 [0]))

(label_ref 0)

(pc))) t1.c:12 -1

 (expr_list:REG_BR_PROB (const_int 5000 [0x1388])

(nil)))

i.e. or-ed conditions were not ;; if (_5 != 0)



(insn 18 17 19 (set (reg:CCZ 17 flags)

(compare:CCZ (reg/v:QI 59 [ c ])

(const_int 45 [0x2d]))) t1.c:12 -1

 (nil))



(insn 19 18 20 (set (reg:QI 66 [ D.2371 ])

(eq:QI (reg:CCZ 17 flags)

(const_int 0 [0]))) t1.c:12 -1

 (nil))



(insn 20 19 21 (set (reg:CCZ 17 flags)

(compare:CCZ (reg/v:QI 59 [ c ])

(const_int 43 [0x2b]))) t1.c:12 -1

 (nil))



(insn 21 20 22 (set (reg:QI 68 [ D.2371 ])

(eq:QI (reg:CCZ 17 flags)

(const_int 0 [0]))) t1.c:12 -1

 (nil))



(insn 22 21 23 (parallel [

(set (reg:QI 69 [ D.2371 ])

(ior:QI (reg:QI 66 [ D.2371 ])

(reg:QI 68 [ D.2371 ])))

(clobber (reg:CC 17 flags))

]) t1.c:12 -1

 (nil))



(insn 23 22 24 (set (reg:CCZ 17 flags)

(compare:CCZ (reg:QI 69 [ D.2371 ])

(const_int 0 [0]))) t1.c:12 -1

 (nil))



(jump_insn 24 23 0 (set (pc)

(if_then_else (eq (reg:CCZ 17 flags)

(const_int 0 [0]))

(label_ref 0)

(pc))) t1.c:12 -1

 (expr_list:REG_BR_PROB (const_int 5000 [0x1388])

(nil)))

i.e. condition was not splitted.



The problem is in gimple_cond_single_var_p (stmt) which return false since 0

(or 1) is not presented as boolean_false_node (boolean_true_node) but if we

change 

e.g.

gimple_cond_rhs (gs) == boolean_false_node

to

integer_zerop (gimple_cond_rhs (gs))



required splitting will happen.

Another way is to fix IR reader in lto.

[Bug lto/56483] LTO issue with expanding GIMPLE_COND

[ysrumyan at gmail dot com]

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



--- Comment #1 from Yuri Rumyantsev  2013-02-28 
14:43:22 UTC ---

Created attachment 29551

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

test-case to reproduce



Test must be compiled with -O2 -flto -fno-inline options

[Bug target/56484] New: ICE in assign_by_spills, at lra-assigns.c:1268

[mgretton at gcc dot gnu.org]

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

 Bug #: 56484
   Summary: ICE in assign_by_spills, at lra-assigns.c:1268
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mgret...@gcc.gnu.org


Created attachment 29552
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29552
Test case

The attached test case ICEs on trunk (svn revision: 196329) as follows:

$ x86_64-unknown-linux-gnu-gcc -O2 besttry.c
besttry.c: In function ‘output_spdif’:
besttry.c:26:1: internal compiler error: in assign_by_spills, at
lra-assigns.c:1268
 }
 ^
0x7f1cf8 assign_by_spills
/work/sources/gcc-fsf/master/gcc/lra-assigns.c:1268
0x7f29b3 lra_assign()
/work/sources/gcc-fsf/master/gcc/lra-assigns.c:1425
0x7eebe1 lra(_IO_FILE*)
/work/sources/gcc-fsf/master/gcc/lra.c:2307
0x7b6e18 do_reload
/work/sources/gcc-fsf/master/gcc/ira.c:4619
0x7b6e18 rest_of_handle_reload
/work/sources/gcc-fsf/master/gcc/ira.c:4731
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Believe this is a target issue as the original test case does not trigger the
failure for arm-none-linux-gnueabihf

[Bug target/56484] ICE in assign_by_spills, at lra-assigns.c:1268

[doko at gcc dot gnu.org]

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



Matthias Klose  changed:



   What|Removed |Added



 CC||doko at gcc dot gnu.org



--- Comment #1 from Matthias Klose  2013-02-28 
15:22:58 UTC ---

I can't reproduce this with r196236

[Bug c++/56485] New: internal compiler error: in cdtor_comdat_group, at cp/optimize.c:\ 186

[guyb at cs dot cmu.edu]

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



 Bug #: 56485

   Summary: internal compiler error: in cdtor_comdat_group, at

cp/optimize.c:\ 186

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: c++

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

ReportedBy: g...@cs.cmu.edu





Only happens when using the cilk flags, in particular using:

g++  -lcilkrts -fcilkplus

Attaching the .ii file.



g++ -v gives:



Using built-in specs. 

COLLECT_GCC=g++ 

COLLECT_LTO_WRAPPER=/opt/gcc-cilkplus-install/bin/../libexec/gcc/x86_64-unknown-lin\

ux-gnu/4.8.0/lto-wrapper 

Target: x86_64-unknown-linux-gnu 

Configured with: ../gcc-cilk-src/configure --prefix=/opt/gcc-cilkplus-install2

--wi\

th-gmp=/opt/gmp-5.0.5 --with-mpfr=/opt/mpfr-3.1.0 --with-mpc=/opt/mpc-0.8.2

--disab\

le-multilib --enable-languages=c,c++ 

Thread model: posix 

gcc version 4.8.0 20130127 (experimental) (GCC)

[Bug c++/56485] internal compiler error: in cdtor_comdat_group, at cp/optimize.c:\ 186

[guyb at cs dot cmu.edu]

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



--- Comment #1 from Guy Blelloch  2013-02-28 15:45:16 
UTC ---

Created attachment 29553

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

Full output of the compile

[Bug c++/56485] internal compiler error: in cdtor_comdat_group, at cp/optimize.c:\ 186

[guyb at cs dot cmu.edu]

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



--- Comment #2 from Guy Blelloch  2013-02-28 15:46:04 
UTC ---

Created attachment 29554

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

The .ii file

[Bug tree-optimization/49234] [4.5/4.7/4.8/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning

[aldyh at gcc dot gnu.org]

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



--- Comment #7 from Aldy Hernandez  2013-02-28 
15:49:34 UTC ---

Created attachment 29555

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

proof of concept: untested

[Bug c/56465] Strange warning about variable modified range

[ktietz at gcc dot gnu.org]

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



--- Comment #2 from Kai Tietz  2013-02-28 15:56:09 
UTC ---

(In reply to comment #1)

> >it is actual a constant.

> 

> I don't think it is a integer constant expression though as it contains a cast

> from a pointer type to an integer type.



Well, it isn't a integer scalar, but still a constant.

[Bug tree-optimization/49234] [4.5/4.6/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning

[aldyh at gcc dot gnu.org]

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



Aldy Hernandez  changed:



   What|Removed |Added



 CC||dnovillo at gcc dot

   ||gnu.org, rguenth at gcc dot

   ||gnu.org



--- Comment #8 from Aldy Hernandez  2013-02-28 
16:00:26 UTC ---

As Jakub explained in comment 3, this is a problem in the VRP code.



To avoid bouncing from max to max (or slowly increasing to +INF), we

immediately go to +INF(OVF), even if we have correct ranges.



One alternative that I show in the attached patch (comment 7: proof of concept

hack, untested), is to keep track of how many times we are iterating through an

SSA.  If we go past an arbitrary number (say 10), we can then go to +INF.



So basically, keep track of a few states, but if it starts getting ridiculous

step it up to INF.  Similarly for the cmp_min code.  The relevant part of my

patch is shown below.



Does this seem like an approach worth exploring (this silences the warning), or

does anyone have a better suggestion?



-  /* Similarly, if the new maximum is smaller or larger than

- the previous one, go all the way to +INF.  */

-  if (cmp_max < 0 || cmp_max > 0)

+  /* Adjust to a new maximum if it has changed.  For the first few

+ iterations, adjust the maximum accordingly.  However, if

+ we're iterating too much, go all the way to +INF to avoid

+ either bouncing around or iterating millions of times to

+ reach +INF.  */

+  if ((cmp_max < 0 || cmp_max > 0))

 {

-  if (!needs_overflow_infinity (TREE_TYPE (vr_result.max))

-  || !vrp_var_may_overflow (lhs, phi))

-vr_result.max = TYPE_MAX_VALUE (TREE_TYPE (vr_result.max));

-  else if (supports_overflow_infinity (TREE_TYPE (vr_result.max)))

-vr_result.max =

-positive_overflow_infinity (TREE_TYPE (vr_result.max));

+  lhs_vr->visited++;

+  if (lhs_vr->visited < 10) // Handle the first 10 iterations.

+vr_result.max = lhs_vr->max;

+  else

+{

+  if (!needs_overflow_infinity (TREE_TYPE (vr_result.max))

+  || !vrp_var_may_overflow (lhs, phi))

+vr_result.max = TYPE_MAX_VALUE (TREE_TYPE (vr_result.max));

+  else if (supports_overflow_infinity (TREE_TYPE (vr_result.max)))

+vr_result.max =

+  positive_overflow_infinity (TREE_TYPE (vr_result.max));

+}

 }

[Bug c++/56243] [4.8 regression] ICE in tree check: expected field_decl, have identifier_node in fixed_type_or_null, at cp/class.c:6645

[jason at gcc dot gnu.org]

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



--- Comment #9 from Jason Merrill  2013-02-28 
16:01:28 UTC ---

Author: jason

Date: Thu Feb 28 16:01:09 2013

New Revision: 196343



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

Log:

PR c++/56243

* call.c (build_over_call): Avoid virtual lookup in a template.



Added:

trunk/gcc/testsuite/g++.dg/template/virtual4.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/call.c

[Bug libstdc++/56468] Clang exposes bug with unexpected forward-declaration of type_info

[d.frey at gmx dot de]

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



--- Comment #4 from Daniel Frey  2013-02-28 16:14:41 UTC 
---

(In reply to comment #1)



I think the first line you added is enough, as evidenced by my "fix" referenced

in the Stack Overflow discussion (see link above). But the second line won't

hurt either.

[Bug target/56484] ICE in assign_by_spills, at lra-assigns.c:1268

[mgretton at gcc dot gnu.org]

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



mgretton at gcc dot gnu.org changed:



   What|Removed |Added



 Target||x86_64-none-linux-gnu

   Host||x86_64-none-linux-gnu



--- Comment #2 from mgretton at gcc dot gnu.org 2013-02-28 16:18:30 UTC ---

Forgot to add gcc -v output:

Using built-in specs.

COLLECT_GCC=/work/builds/gcc-fsf-master/tools/bin/x86_64-unknown-linux-gnu-gcc

COLLECT_LTO_WRAPPER=/work/builds/gcc-fsf-master/tools/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: /work/sources/gcc-fsf/master/configure

--target=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu

--build=x86_64-unknown-linux-gnu --prefix=/work/builds/gcc-fsf-master/tools

--enable-languages=c,c++,fortran

--with-ppl-include=/usr/include/x86_64-linux-gnu

Thread model: posix

gcc version 4.8.0 20130228 (experimental) (GCC)

[Bug tree-optimization/55796] Comparison with a negated number vs sum

[glisse at gcc dot gnu.org]

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



--- Comment #2 from Marc Glisse  2013-02-28 16:57:35 
UTC ---

(In reply to comment #1)

> DOM is the optimization that tries to optimize these cases.  It's probably

> overly careful for FP compares.



Note that the compiler doesn't optimize this any better if I replace double

with int.

[Bug c++/56481] [4.8 Regression] endless loop compiling a C++ file

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |

[Bug c/56465] Strange warning about variable modified range

[jasonwucj at gmail dot com]

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



Chung-Ju Wu  changed:



   What|Removed |Added



 CC||jasonwucj at gmail dot com



--- Comment #3 from Chung-Ju Wu  2013-02-28 
17:19:13 UTC ---

(In reply to comment #2)

> (In reply to comment #1)

> > >it is actual a constant.

> > 

> > I don't think it is a integer constant expression though as it contains a 
> > cast

> > from a pointer type to an integer type.

> 

> Well, it isn't a integer scalar, but still a constant.



To my understanding, it is not a constant.



For example, 



  int i;

  i = (int) ((int*)0 + 1);



Could you tell the value of i from C language point of view?



According to C99 6.5.6 Point 8, 

"When an expression that has integer type is added to or subtracted

 from a pointer, the result has the type of the pointer operand."



Hence, the result of "(int*)0 + 1" is a 'pointer to type T'.

So, no, you can't tell the value.

It depends on integer size of target machine.

[Bug c++/56481] [4.8 Regression] endless loop compiling a C++ file

[jakub at gcc dot gnu.org]

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



--- Comment #2 from Jakub Jelinek  2013-02-28 
17:35:47 UTC ---

With -std=c++11 this actually started already with

http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189851

when that code has been introduced in potential_constant_expression_1.

[Bug c/55830] inline and __attribute__((always_inline)) treated differently for unused-function warning

[colanderman at gmail dot com]

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



Chris King  changed:



   What|Removed |Added



 CC||colanderman at gmail dot

   ||com



--- Comment #5 from Chris King  2013-02-28 
18:18:37 UTC ---

This is good.  I like that I can specify __attribute__ ((always_inline)) on

local static functions and still be warned if they are unused.  IMHO the real

bug is that such usage triggers a "warning: always_inline function might not be

inlinable".



If this bug and/or the above warning behavior is valid, then what's the

"correct" way to say "I want my local static function to be always inlined, but

don't hide warnings if it's unused"?

[Bug c++/56312] Firefox 20.0a1 compilation with enabled LTO fails

[marxin.liska at gmail dot com]

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

--- Comment #1 from Martin Liška  2013-02-28 
18:31:05 UTC ---
I patched following two files with __attribute__ ((used)) which helped to go
further, having a new issue:

/home/marxin/Programming/firefox/xpcom/components/nsComponentManager.cpp: In
function ‘_ZN22nsComponentManagerImpl23InitializeStaticModulesEv.part.59’:
/home/marxin/Programming/firefox/xpcom/components/nsComponentManager.cpp:275:0:
internal compiler error: Segmentation fault
 nsComponentManagerImpl::InitializeStaticModules()
 ^
0x85049f crash_signal
../../gcc/toplev.c:332
0x6c0475 can_refer_decl_in_current_unit_p
../../gcc/gimple-fold.c:70
0x6c218a canonicalize_constructor_val(tree_node*, tree_node*)
../../gcc/gimple-fold.c:172
0x6c286c fold_ctor_reference
../../gcc/gimple-fold.c:2944
0x6c6882 fold_const_aggregate_ref_1(tree_node*, tree_node* (*)(tree_node*))
../../gcc/gimple-fold.c:3069
0x6c754c gimple_fold_stmt_to_constant_1(gimple_statement_d*, tree_node*
(*)(tree_node*))
../../gcc/gimple-fold.c:2520
0x992e0d try_to_simplify
../../gcc/tree-ssa-sccvn.c:3257
0x992e0d visit_use
../../gcc/tree-ssa-sccvn.c:3334
0x996e30 process_scc
../../gcc/tree-ssa-sccvn.c:3649
0x996e30 extract_and_process_scc_for_name
../../gcc/tree-ssa-sccvn.c:3706
0x996e30 DFS
../../gcc/tree-ssa-sccvn.c:3760
0x996e30 run_scc_vn(vn_lookup_kind)
../../gcc/tree-ssa-sccvn.c:4006
0x97971c do_pre
../../gcc/tree-ssa-pre.c:4700

Thanks

[Bug target/16458] PowerPC - redundant compare

[bergner at gcc dot gnu.org]

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



--- Comment #11 from Peter Bergner  2013-02-28 
20:21:05 UTC ---

Author: bergner

Date: Thu Feb 28 20:20:56 2013

New Revision: 196357



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

Log:

gcc/

Backport from mainline

2012-04-11  Peter Bergner  

Michael Matz  



PR target/16458

* rtlanal.c (unsigned_reg_p): New function.

Update copyright notice dates.

* rtl.h (unsigned_reg_p): Prototype it.

Update copyright notice dates.

* config/rs6000/rs6000.c (rs6000_generate_compare): Use it.

Update comment.

* expr.c (expand_expr_real_1): Set register attributes.

* stmt.c (expand_case): Likewise.



gcc/testsuite/

Backport from mainline

2012-04-11  Peter Bergner  



PR target/16458

* gcc.target/powerpc/pr16458-1.c: New test.

* gcc.target/powerpc/pr16458-2.c: Likewise.

* gcc.target/powerpc/pr16458-3.c: Likewise.

* gcc.target/powerpc/pr16458-4.c: Likewise.



Added:

branches/ibm/gcc-4_7-branch/gcc/testsuite/gcc.target/powerpc/pr16458-1.c

branches/ibm/gcc-4_7-branch/gcc/testsuite/gcc.target/powerpc/pr16458-2.c

branches/ibm/gcc-4_7-branch/gcc/testsuite/gcc.target/powerpc/pr16458-3.c

branches/ibm/gcc-4_7-branch/gcc/testsuite/gcc.target/powerpc/pr16458-4.c

Modified:

branches/ibm/gcc-4_7-branch/gcc/ChangeLog.ibm

branches/ibm/gcc-4_7-branch/gcc/config/rs6000/rs6000.c

branches/ibm/gcc-4_7-branch/gcc/expr.c

branches/ibm/gcc-4_7-branch/gcc/rtl.h

branches/ibm/gcc-4_7-branch/gcc/rtlanal.c

branches/ibm/gcc-4_7-branch/gcc/stmt.c

branches/ibm/gcc-4_7-branch/gcc/testsuite/ChangeLog.ibm

[Bug c++/56481] [4.8 Regression] endless loop compiling a C++ file

[jason at gcc dot gnu.org]

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



--- Comment #3 from Jason Merrill  2013-02-28 
20:21:36 UTC ---

Author: jason

Date: Thu Feb 28 20:21:23 2013

New Revision: 196358



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

Log:

PR c++/56481

* semantics.c (potential_constant_expression_1): Use

cxx_eval_outermost_constant_expr rather than maybe_constant_value.



Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/semantics.c

[Bug c++/56243] [4.8 regression] ICE in tree check: expected field_decl, have identifier_node in fixed_type_or_null, at cp/class.c:6645

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #10 from Jason Merrill  2013-02-28 
20:33:21 UTC ---

Fixed.

[Bug c++/56481] [4.8 Regression] endless loop compiling a C++ file

[jason at gcc dot gnu.org]

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



--- Comment #4 from Jason Merrill  2013-02-28 
20:36:54 UTC ---

Author: jason

Date: Thu Feb 28 20:36:47 2013

New Revision: 196359



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

Log:

PR c++/56481

* g++.dg/cpp0x/constexpr-and.C: New.



Added:

trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-and.C

Modified:

trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/49234] [4.5/4.6/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #9 from Manuel López-Ibáñez  2013-02-28 
20:40:55 UTC ---
(In reply to comment #3)
> We hit:
> 163724rguenth   /* Similarly, if the new maximum is smaller or larger
> than
> 163724rguenththe previous one, go all the way to +INF.  */
> 163724rguenth   if (cmp_max < 0 || cmp_max > 0)
> 163724rguenth   {
> 163724rguenth if (!needs_overflow_infinity (TREE_TYPE
> (vr_result.max))
> 163724rguenth || !vrp_var_may_overflow (lhs, phi))
> 163724rguenth   vr_result.max = TYPE_MAX_VALUE (TREE_TYPE
> (vr_result.max));
> 163724rguenth else if (supports_overflow_infinity (TREE_TYPE
> (vr_result.max)))
> 163724rguenth   vr_result.max =
> 163724rguenth   positive_overflow_infinity (TREE_TYPE
> (vr_result.max));
> 163724rguenth   }
> 

(In reply to comment #8)
> 
> Does this seem like an approach worth exploring (this silences the warning), 
> or
> does anyone have a better suggestion?

Isn't the problem that vrp_var_may_overflow returns true even though 'state'
cannot overflow? Jakub says:

> As the IV (i) might overflow, vrp_var_may_overflow returns true.
> In particular, chrec is SCEV_NOT_KNOWN.  Thus it just in case sets
> vr_result.max to +INF(OVF) and later on we warn about it.
> Before hitting this code, vr_result contains the right range [0, 2], but it
> doesn't know it can safely use that.

Couldn't be possible to detect this by the fact that 'state' does not depend on
anything variable?

Also, in such a case, the algorithm cannot iterate more than the number of phi
nodes in the loop (if I understand the VRP correctly, which I most likely
don't).

But I looked around and I honestly don't know how to implement this idea.

In any case, your patch would need to adjust the code for the minimum also, no?
Because the same behaviour can be triggered just by using negative numbers to
trigger a negative overflow infinity.

[Bug c++/56481] [4.8 Regression] endless loop compiling a C++ file

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #5 from Jakub Jelinek  2013-02-28 
20:45:26 UTC ---

Fixed, thanks.

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

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



--- Comment #16 from Jakub Jelinek  2013-02-28 
21:20:34 UTC ---

Author: jakub

Date: Thu Feb 28 21:20:26 2013

New Revision: 196360



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

Log:

PR middle-end/56461

* tree-vectorizer.h (vect_get_slp_defs): Change 3rd argument

type to vec > *.

* tree-vect-slp.c (vect_get_slp_defs): Likewise.  Change vec_defs

to be vec instead of vec *, set vec_defs

to vNULL and call vec_defs.create (number_of_vects), adjust other

uses of vec_defs.

* tree-vect-stmts.c (vect_get_vec_defs, vectorizable_call,

vectorizable_condition): Adjust vect_get_slp_defs callers.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/tree-vect-slp.c

trunk/gcc/tree-vect-stmts.c

trunk/gcc/tree-vectorizer.h

[Bug sanitizer/56454] need to rename attribute no_address_safety_analysis to no_sanitize_address

[jakub at gcc dot gnu.org]

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



--- Comment #14 from Jakub Jelinek  2013-02-28 
21:23:30 UTC ---

Author: jakub

Date: Thu Feb 28 21:23:23 2013

New Revision: 196361



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

Log:

PR sanitizer/56454

* asan.c (gate_asan): Lookup no_sanitize_address instead of

no_address_safety_analysis attribute.

* doc/extend.texi (no_address_safety_attribute): Rename to

no_sanitize_address attribute, mention no_address_safety_analysis

attribute as deprecated alias.



* c-common.c (handle_no_sanitize_address_attribute): New function.

(c_common_attribute_table): Add no_sanitize_address attribute.

(handle_no_address_safety_analysis_attribute): Add

no_sanitize_address attribute, not no_address_safety_analysis

attribute.



* g++.dg/asan/default-options-1.C (__asan_default_options): Use

no_sanitize_address attribute rather than no_address_safety_analysis.

* g++.dg/asan/sanitizer_test_utils.h

(ATTRIBUTE_NO_ADDRESS_SAFETY_ANALYSIS): Likewise.

* c-c++-common/asan/attrib-1.c: Test no_sanitize_address attribute

in addition to no_address_safety_analysis.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/asan.c

trunk/gcc/c-family/ChangeLog

trunk/gcc/c-family/c-common.c

trunk/gcc/doc/extend.texi

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/c-c++-common/asan/attrib-1.c

trunk/gcc/testsuite/g++.dg/asan/default-options-1.C

trunk/gcc/testsuite/g++.dg/asan/sanitizer_test_utils.h

[Bug tree-optimization/56486] New: infinite loop in cc1 at -O1 and above

[dhazeghi at yahoo dot com]

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



 Bug #: 56486

   Summary: infinite loop in cc1 at -O1 and above

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

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

ReportedBy: dhaze...@yahoo.com





The following code (generated by csmith) causes gcc 4.6.3 and 4.7.2 to go into

an infinite loop when compiled at -O1 or higher.  This does not occur with

current trunk or gcc 4.5.4 (although 4.5.4 does take about 10 seconds to

compile it), so technically this is a regression on 4.6 and 4.7.



An attempt to use creduce to reduce it failed as end-result no longer hangs (it

does take 10 seconds to compile though).



$ gcc-4.7 --version

gcc-4.7 (GCC) 4.7.2

$ gcc-4.5 -O1 crash.i

$ gcc-trunk -O1 crash.i

$ gcc-4.7 -O1 crash.i

[Bug tree-optimization/56486] infinite loop in cc1 at -O1 and above

[dhazeghi at yahoo dot com]

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



--- Comment #1 from Dara Hazeghi  2013-02-28 
22:37:44 UTC ---

Created attachment 29556

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

hanging testcase

[Bug c++/55135] Segfault of gcc on a big file

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed|2012-10-30 00:00:00 |2013-02-28

 CC||steven at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #9 from Steven Bosscher  2013-02-28 
22:49:16 UTC ---

I first tried at -O0, only to run into even worse compile time issues,

hitting quadratic behavior in the number of EH regions, and having a

huge number of them:



 void LHA::Load();; remove_queued_eh_handlers: # eh regions: 179972



The remove_queued_eh_handlers function is new, I'll attach a patch

here after proper testing. With that problem out of the way, the next

hurdle is IRA but I'm still trying to figure that one out.

[Bug c++/55135] Segfault of gcc on a big file

[steven at gcc dot gnu.org]

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



--- Comment #10 from Steven Bosscher  2013-02-28 
23:58:38 UTC ---

Created attachment 29557

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

Collected hacks to make the test case compile in reasonable time with -O0



Patch does 2 things:



- Queue up to-be-removed EH regions, instead of removing them one-by-one.

  Removing them one at a time results in walking the list of EH regions

  repeatedly, thus taking O(# of EH regions ** 2) time.



- Rewrite init_subregs_of_mode and subroutines to first collect the

  invalid mode change subregs in sbitmaps, and then converting the final

  sbitmap to a bitmap. This trades memory for time: the bitmap lookups are

  also potentially O(# of registers ** 2) and this test case has more than

  one million registers, many of them with invalid mode changes (to be fixed

  up by IRA/LRA).



Peak memory at -O0 is <4GB. Compile time on a "Quad-Core AMD Opteron(tm)

Processor 8354" at 2200MHz is 240s, half of it still taken up by IRA+LRA.



At -O1 the einline pass is consuming almost all compile time again.

-> Honza: Can we please have a proper permanent fix for this recurring

problem? What's there now just Does Not Work!

[Bug c++/55135] [4.8 Regression] Segfault of gcc on a big file

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



   Keywords||compile-time-hog,

   ||memory-hog

 CC|stevenb.gcc at gmail dot|hubicka at gcc dot gnu.org

   |com |

Summary|Segfault of gcc on a big|[4.8 Regression] Segfault

   |file|of gcc on a big file



--- Comment #11 from Steven Bosscher  2013-03-01 
00:01:47 UTC ---

This is a regression on various things from previous releases.



I will take care of the compile time explosion at -O0.



The -O1+ compile time explosion (and probably the memory explosion) are

due to the ever-changing inliner heuristics that still just don't scale.

[Bug target/56487] New: SSE2 code crashes when compiled at -O0 -m32 -msse2

[dhazeghi at yahoo dot com]

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



 Bug #: 56487

   Summary: SSE2 code crashes when compiled at -O0 -m32 -msse2

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

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

ReportedBy: dhaze...@yahoo.com





The following code (simplified from an SSE testcase0 crashes when compiled with

-m32 -msse2 -O0 on all gcc 4.x versions including mainline.  With optimization

enabled, or with gcc 3.x, it executes successfully.  Host/target is

x86_64-unknown-linux-gnu.



$ gcc-trunk --version

gcc-trunk (GCC) 4.8.0 20130228 (experimental) [trunk revision 196339]

$ gcc-trunk -m32 -msse2 -O1 sse-isamax.c 

$ ./a.out 

$ gcc-trunk -m32 -msse2 -O0 sse-isamax.c 

$ ./a.out 

Segmentation fault (core dumped)

$ cat sse-isamax.c 



typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));

typedef float __v4sf __attribute__ ((__vector_size__ (16)));

extern __inline __m128 __attribute__((__gnu_inline__, __always_inline__,

__artificial__))

_mm_load_ps (float const *__P)

{

  return (__m128) *(__v4sf *)__P;

}

void exit(int);



int isamax0(float *x)

{

  __m128 V0;



  V0 = _mm_load_ps(x);

  exit(0);



  return (int)(*x + 4);

}



int main()

{



  float x[4];

  int i;

  for(i=0;i<4;i++)

 x[i] = -2.0 + (float) i;



  return isamax0(x);

}

[Bug target/56487] SSE2 code crashes when compiled at -O0 -m32 -msse2

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #1 from Andrew Pinski  2013-03-01 
02:56:39 UTC ---

the array x does not have to be 16 byte aligned so it is crashing when it is

doing the load.  You are using the incorrect intrinsic for this load, you

should be using the unaligned load one instead.

[Bug c++/56428] [C++11] "is not a constant expression" when comparing non-type template argument to nullptr

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-03-01

 CC||jason at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Jason Merrill  2013-03-01 
03:04:25 UTC ---

Confirmed: "if only one is null, they compare unequal."



The internal issue here is that as a language extension, weak references mean

that the address of a weak declaration might resolve to null if the symbol

isn't defined at link time.  But we need that not to affect normal template

instantiations.



Note that nullptr isn't necessary to reproduce this bug, f<&f<&g> > and

comparing against 0 shows the same issue.

[Bug tree-optimization/56488] New: wrong code for loop at -O3

[dhazeghi at yahoo dot com]

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



 Bug #: 56488

   Summary: wrong code for loop at -O3

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

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

ReportedBy: dhaze...@yahoo.com





The following code (reduced from a larger testcase) when compiled at -O3 with

gcc 4.7.2 produces an executable that does not terminate.  Compiling with lower

optimizations, current gcc trunk or the older 4.6.3 release at -O3, the

executable terminates as expected.





$ gcc-4.7 --version

gcc-4.7 (GCC) 4.7.2

$ gcc-4.7 -O2 loop.c

$ ./a.out 

$ gcc-4.6 -O3 loop.c

$ ./a.out 

$ gcc-4.7 -O3 loop.c

$ ./a.out 

 ^C

$ cat loop.c



int a, c, d = 1;



struct

{

int f0;

} b, f;



short e;



void fn1 (p1)

{

int g[] = { };

e = 0;

for (; e != 1; e = e + 5)

{

int *h[] = {[0] & g[0] };

if (p1);

else

return;

f = b;

}

}



int main ()

{

int i, j;

i = 0;

for (; i < 6; i++)

{

j = 8;

for (; j; j--)

a = 0;

}

fn1 (d);

for (; c;);

}

[Bug c++/56489] New: [C++11] Member type lookup fails on dependent using-declarations

[hhhpppsss1 at hotmail dot com]

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

 Bug #: 56489
   Summary: [C++11] Member type lookup fails on dependent
using-declarations
Classification: Unclassified
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hhhppps...@hotmail.com


Created attachment 29558
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29558
test case

If a type alias to a template dependent type is introduced by a
using-declaration, gcc fails to lookup its member types. The following code can
be used to test this behavior:

template 
struct A
{
using type = void;

constexpr static int value = 0;
};

template 
void func()
{
typedef A A_typedef;
using   A_using = A;

int value_typedef = A_typedef::value;
int value_using   = A_using  ::value;

using type_typedef = typename A_typedef::type;
using type_using   = typename A_using  ::type;
}

template void func();

When compiled with gcc 4.7.2 (-c -std=gnu++11), it gives an error message:

test.cpp: In instantiation of ‘void func() [with T = int]’:
test.cpp:22:25:   required from here
test.cpp:19:50: error: no type named ‘type’ in ‘using A_using = struct A’

[Bug tree-optimization/56488] wrong code for loop at -O3

[pinskia at gcc dot gnu.org]

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



--- Comment #1 from Andrew Pinski  2013-03-01 
06:58:48 UTC ---

Works on the trunk.

[Bug target/56484] ICE in assign_by_spills, at lra-assigns.c:1268

[venkataramanan.kumar at amd dot com]

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



Venkataramanan  changed:



   What|Removed |Added



 CC||venkataramanan.kumar at amd

   ||dot com



--- Comment #3 from Venkataramanan  
2013-03-01 07:04:28 UTC ---

(In reply to comment #1)

> I can't reproduce this with r196236



I tried with some old revisions I had on a SLES 11 SP1 machine.



I am getting this issue with r193549 at lra-assigns.c.

reload.c spill failure when I use 190150 (does not have LRA). This seems to be

a long known issue in trunk. 



I am triaging further

[Bug c++/55135] [4.8 Regression] Segfault of gcc on a big file

[steven at gcc dot gnu.org]

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



--- Comment #12 from Steven Bosscher  2013-03-01 
07:50:43 UTC ---

Last night's compilation at -O1 with my hacks applied finished after

a whopping >6 hours. Top compile time consumers:



 early inlining heuristics: 12409.92 (55%) usr

 integration  :  1417.65 ( 6%) usr

 tree eh  :  1140.75 ( 5%) usr

 tree PTA :   309.46 ( 1%) usr

 tree SSA incremental :  6065.43 (27%) usr

 tree split crit edges:   515.67 ( 2%) usr

 TOTAL: 22448.04



Peak memory: 4294647808 (~4GB).

[Bug c++/55135] [4.8 Regression] Segfault of gcc on a big file

[steven at gcc dot gnu.org]

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



--- Comment #13 from Steven Bosscher  2013-03-01 
07:52:41 UTC ---

For reference, my numbers are for GCC 4.8 trunk r196182, configured

with release checking, on x86_64-unknown-linux-gnu, on AMD Opteron

Processor 8354 at 2200MHz.