[Bug tree-optimization/55334] mgrid regression (ipa-cp disables vectorization)

[vincenzo.innocente at cern dot ch]

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



vincenzo Innocente  changed:



   What|Removed |Added



 CC||vincenzo.innocente at cern

   ||dot ch



--- Comment #1 from vincenzo Innocente  
2012-11-15 07:11:08 UTC ---

try

--param vect-max-version-for-alias-checks=100  o similar

it helps to vectorize most of my C++ code that suffers for gcc not handling

"restrict" properly

[Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed

[tejohnson at google dot com]

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



--- Comment #23 from Teresa Johnson  2012-11-15 
06:44:00 UTC ---

On Wed, Nov 14, 2012 at 5:17 PM, hubicka at gcc dot gnu.org

 wrote:

>

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

>

> --- Comment #16 from Jan Hubicka  2012-11-15 
> 01:17:43 UTC ---

> Theresa: I am using gcc10 from compilation farm, but I think it is fairly

> universal problem.

> Also I think that gcc_assert should not be assert, but an user readable error

> about gcov file corruption.



I took a look at this some more this evening, printing out the values

being compared. Note that the modification I made to this code was to

ignore the histogram when comparing the gcov_ctr_summary, since the

order of update can affect the merged histogram values as they are

prorated. So essentially we are doing the same comparison here that we

did before the histogram was added.



I found that the gcov_ctr_summary fields being compared are identical

except for the sum_all, which is different, leading to the error

message. The number of counters, run_max and sum_max are the same. I'm

not sure how that can happen given that locking is on and the sum_all

should be the same regardless of the merging order.



Note though that this is not an assert. It just emits a message to

stderr. Do you think a better error message is appropriate? I'm not

sure the "some data files may have been removed" is an accurate

description of the issue. Perhaps something like "Profile data file

mismatch may indicate corrupt profile data"?



Teresa



>

> --

> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email

> --- You are receiving this mail because: ---

> You are on the CC list for the bug.







--

Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[kl4yfd at gmail dot com]

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



--- Comment #4 from kl4yfd at gmail dot com 2012-11-15 06:39:23 UTC ---

Created attachment 28695

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

mmX global register no emms



Added example C source file showing the issue mentioned in comment 3

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[kl4yfd at gmail dot com]

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



kl4yfd at gmail dot com changed:



   What|Removed |Added



 CC||kl4yfd at gmail dot com



--- Comment #3 from kl4yfd at gmail dot com 2012-11-15 06:36:17 UTC ---

Additional way to cause this bug discovered.



By using global mmX register variables, reads & writes to/from these locations

incur mmX operands automatically.



Even when compiled _without_ -mmmx flag, these MMX operands are generated by

gcc!



As the bug name states, no emms opcode is generated to leave MMX state/mode and

return the FPU to working order. 





  1) why does gcc _not_ place the emms opcode at the end of all binaries

compiled with -mmmx for safety-sake?

  2) Why does gcc generate MMX opcodes even without the -mmmx compile flag?



---



Using built-in specs.

COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper

Target: x86_64-linux-gnu

Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro

4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs

--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr

--program-suffix=-4.6 --enable-shared --enable-linker-build-id

--with-system-zlib --libexecdir=/usr/lib --without-included-gettext

--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6

--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu

--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object

--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686

--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu

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

Thread model: posix

gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)

[Bug c++/55335] New: [DR 5] cv-qualifiers of destination type in copy-initialization

[ai.azuma at gmail dot com]

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



 Bug #: 55335

   Summary: [DR 5] cv-qualifiers of destination type in

copy-initialization

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: ai.az...@gmail.com





Created attachment 28694

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

Output of -v option and preprocessed file with GCC 4.8.0 2012



The following valid code is rejected by GCC 4.6.4 20121109, 4.7.3 20121110 and

4.8.0 2012.



/

struct C{};



struct A {

  A(const A&){};

  A(const C&){};

};



int main()

{

  C c;

  const volatile A a = c;

}

/



For the above code, GCC 4.8.0 2012 complains as follows;



main.cpp: In function 'int main()':

main.cpp:11:24: error: no matching function for call to 'A::A(const volatile

A)'

   const volatile A a = c;

^

main.cpp:11:24: note: candidates are:

main.cpp:5:3: note: A::A(const C&)

   A(const C&){};

   ^

main.cpp:5:3: note:   no known conversion for argument 1 from 'const volatile

A' to 'const C&'

main.cpp:4:3: note: A::A(const A&)

   A(const A&){};

   ^

main.cpp:4:3: note:   no known conversion for argument 1 from 'const volatile

A' to 'const A&'



As far as I can guess from the error message, GCC does not seem to implement

the proposed resolution of DR 5.

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#5

[Bug other/54279] [4.8 Regression] first stage build with g++ fails with "." as the first component of $PATH

[pinskia at gcc dot gnu.org]

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



--- Comment #5 from Andrew Pinski  2012-11-15 
04:31:44 UTC ---

libmudflap has the similar issue.

[Bug other/54279] [4.8 Regression] first stage build with g++ fails with "." as the first component of $PATH

[pinskia at gcc dot gnu.org]

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



--- Comment #4 from Andrew Pinski  2012-11-15 
03:40:18 UTC ---

(In reply to comment #3)

> Created attachment 28693 [details]

> Patch which I am testing right now

> 

> Once my testing finishes (including installing), I will submit this.



It had an issue while doing libstdc++ testing.  So fixing up that testsuite.

[Bug other/55333] [x32] StackTrace::FastUnwindStack wrong x32

[hjl.tools at gmail dot com]

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



H.J. Lu  changed:



   What|Removed |Added



Summary|[x32] 8 asan test failures  |[x32]

   ||StackTrace::FastUnwindStack

   ||wrong x32



--- Comment #1 from H.J. Lu  2012-11-15 03:38:05 
UTC ---

For x32, hardware frame pointer size is 64-bit, not 32-bit.

[Bug bootstrap/53866] [4.8 Regression] lto-bootstrap failed at -O3

[pinskia at gcc dot gnu.org]

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



--- Comment #6 from Andrew Pinski  2012-11-15 
03:20:16 UTC ---

Does this still happen?

[Bug bootstrap/53300] [4.8 Regression] AIX bootstrap related to varpool patch

[pinskia at gcc dot gnu.org]

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



--- Comment #18 from Andrew Pinski  2012-11-15 
03:18:18 UTC ---

Does this still happen?

[Bug c++/55325] [4.8 Regression]: g++.dg/cpp0x/constexpr-complex.C excess errors

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 CC||jason at gcc dot gnu.org

 Resolution||FIXED



--- Comment #12 from Jason Merrill  2012-11-15 
02:57:01 UTC ---

(In reply to comment #5)

> If you ask me, I have I slight preference for the latter, because isn't always

> obvious what gnu++* includes beyond c++*. But Jason will tell you, and the fix

> is straightforward anyway.



gnu++ is mostly extra keywords.  I've fixed the testcases.

[Bug other/54279] [4.8 Regression] first stage build with g++ fails with "." as the first component of $PATH

[pinskia at gcc dot gnu.org]

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



--- Comment #3 from Andrew Pinski  2012-11-15 
02:51:15 UTC ---

Created attachment 28693

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

Patch which I am testing right now



Once my testing finishes (including installing), I will submit this.

[Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed

[tejohnson at google dot com]

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



--- Comment #22 from Teresa Johnson  2012-11-15 
02:46:20 UTC ---

Ok, will see if I can submit that one tomorrow then, after double

checking the performance.



Teresa



On Wed, Nov 14, 2012 at 6:01 PM, hubicka at ucw dot cz

 wrote:

>

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

>

> --- Comment #21 from Jan Hubicka  2012-11-15 02:01:01 
> UTC ---

>> Ok, I can do that. I had tried that but didn't see any gain yet (need

>> to take a look at my results again). I have been playing with teasing

>> apart the various uses of this cutoff (inlining vs instruction

>> selection vs etc) too, but can do that in a later release once the

>> appropriate individual cutoffs are tuned. I also have a loop unroller

>> patch on the google branch that uses this that needs to be ported to

>> trunk. It was in the original working set patch I sent for review,

>> that ended up being split out and revised heavily. Shall I resubmit

>> this part for 4.8 or is it too late?

>

> I can't review the unroller change, so you should ask one of the maintainers

> of the area.  For the hot/cold change, I would really like to see it in.

> (and yes, I also plan to use it for more aggressive inlining in known to

> be hot areas).

>

> Honza

>

> --

> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email

> --- You are receiving this mail because: ---

> You are on the CC list for the bug.

[Bug c++/55325] [4.8 Regression]: g++.dg/cpp0x/constexpr-complex.C excess errors

[hp at gcc dot gnu.org]

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



--- Comment #11 from Hans-Peter Nilsson  2012-11-15 
02:39:57 UTC ---

(In reply to comment #7)

> (In reply to comment #3)

> > Excess errors:

> > /tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/cpp0x/gnu_fext-numeric-literals.C:94:3:

> > ...

> > maybe related, maybe material for a new PR.

> 

> I'm not getting this on x86_64-linux at least.  What target are you on?



I guess it's no longer interesting seeing the later comments, in particular

comment #10, but it's cris-axis-elf (obvious by elimination, see listed

targets).



Since TARGET_C_MODE_FOR_SUFFIX doesn't have a sane default, this part of the

test should IMHO be parametrized by say an testsuite "effective-target".



Or should the default for TARGET_C_MODE_FOR_SUFFIX changed to something sane?

By "sane" I mean the mode for "long double", (i.e. DFmode by default) for 'q'

and 'w'.  (BTW, I hate that I can't grep for TARGET_C_MODE_FOR_SUFFIX in the

sources and get sane results other than the target hits.)

[Bug fortran/48636] Enable more inlining with -O2 and higher

[hubicka at gcc dot gnu.org]

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



--- Comment #41 from Jan Hubicka  2012-11-15 
02:28:26 UTC ---

mgrid regression is now PR55334

[Bug c++/47343] incorrect location for declaration of class template partial specialization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  2012-11-15 
02:28:15 UTC ---
Fixed by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193524

pt.cc:21:16: error: invalid use of incomplete type ‘struct X >’
   X< Y >::f()// xxx
^
pt.cc:17:10: error: declaration of ‘struct X >’
   struct X< Y >;  // here
  ^

[Bug tree-optimization/55334] New: mgrid regression (ipa-cp disables vectorization)

[hubicka at gcc dot gnu.org]

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



 Bug #: 55334

   Summary: mgrid regression (ipa-cp disables vectorization)

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

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

ReportedBy: hubi...@gcc.gnu.org





mgrid has regressed noticeably

http://gcc.opensuse.org/SPEC/CFP/sb-frescobaldi.suse.de-head-64/172_mgrid_big.png



This seems to be related to function resid_ that we now clone

  Creating a specialized node of resid/1.

replacing param u with const &x.u

replacing param v with const &x.v

replacing param r with const &x.r

replacing param a with const &x.a



Both variants stays in the code. When compiling resid vectorizer succeeds.



The difference seems to be:

191: vect_compute_data_ref_alignment:

191: Unknown alignment for access: *v_41(D)

191: vect_compute_data_ref_alignment:

191: Unknown alignment for access: *u_45(D)

191: vect_compute_data_ref_alignment:

191: Unknown alignment for access: *u_45(D)

191: vect_compute_data_ref_alignment:

191: Unknown alignment for access: *u_45(D)

191: vect_compute_data_ref_alignment:

191: Unknown alignment for access: *u_45(D)

191: vect_compute_data_ref_alignment:

191: Unknown alignment for access: *u_45(D)

191: vect_compute_data_ref_alignment:

191: Unknown alignment for access: *u_45(D)

191: vect_compute_data_ref_alignment:

191: Unknown alignment for access: *u_45(D)

191: vect_compute_data_ref_alignment:

191: Unknown alignment for access: *u_45(D)

191: vect_compute_data_ref_alignment:

191: Unknown alignment for access: *u_45(D)



being changed to

191: vect_compute_data_ref_alignment:

191: Unknown alignment for access: x

191: vect_compute_data_ref_alignment:

191: misalign = 0 bytes of ref MEM[(real(kind=8)[4] *)&x + 58071104B][0]

191: vect_compute_data_ref_alignment:

191: Unknown alignment for access: x

191: vect_compute_data_ref_alignment:

191: misalign = 8 bytes of ref MEM[(real(kind=8)[4] *)&x + 58071104B][1]

191: vect_compute_data_ref_alignment:

191: Unknown alignment for access: x

191: vect_compute_data_ref_alignment:

191: Unknown alignment for access: x

191: vect_compute_data_ref_alignment:

191: Unknown alignment for access: x

191: vect_compute_data_ref_alignment:

191: Unknown alignment for access: x

191: vect_compute_data_ref_alignment:

191: Unknown alignment for access: x



that ultimately leads to

191: === vect_prune_runtime_alias_test_list ===

191: disable versioning for alias - max number of generated checks exceeded.

191: too long list of versioning for alias run-time tests.



So it seems that specializing for particular static array = good thing leads to

vectorizer giving up.

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

[howarth at nitro dot med.uc.edu]

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



--- Comment #38 from Jack Howarth  2012-11-15 
02:10:33 UTC ---

(In reply to comment #35)

> >> Is that certain to be soon enough 

> Not 100%. I am just warning you.



Considering that the release schedule for llvm 3.2 is close to that of gcc 4.8,

it seems unrealistic to expect to be able to replace mach_override in time for

the gcc 4.8.0 release. If the existing mach_override is sufficient for llvm

3.2, I suspect we can also live with it (at least until gcc 4.8.1).



> 

> >> Will the replacement of mach_override also depend on the Core Foundation 
> >> framework?

> 

> That's the question to Alex.

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

[howarth at nitro dot med.uc.edu]

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



--- Comment #37 from Jack Howarth  2012-11-15 
02:06:45 UTC ---

Created attachment 28692

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

revised patch with regenerated files and proposed darwin.h link spec change

[Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed

[hubicka at ucw dot cz]

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



--- Comment #21 from Jan Hubicka  2012-11-15 02:01:01 
UTC ---

> Ok, I can do that. I had tried that but didn't see any gain yet (need

> to take a look at my results again). I have been playing with teasing

> apart the various uses of this cutoff (inlining vs instruction

> selection vs etc) too, but can do that in a later release once the

> appropriate individual cutoffs are tuned. I also have a loop unroller

> patch on the google branch that uses this that needs to be ported to

> trunk. It was in the original working set patch I sent for review,

> that ended up being split out and revised heavily. Shall I resubmit

> this part for 4.8 or is it too late?



I can't review the unroller change, so you should ask one of the maintainers

of the area.  For the hot/cold change, I would really like to see it in.

(and yes, I also plan to use it for more aggressive inlining in known to

be hot areas).



Honza

[Bug libstdc++/53841] [C++11] condition_variable::wait_until() fails with high resolution clocks

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.7.3

  Known to fail||4.6.3, 4.7.2



--- Comment #7 from Jonathan Wakely  2012-11-15 
01:58:01 UTC ---

Fixed for 4.7.3 and 4.8.0



Thanks for prodding me to fix this, I'd forgotten all about it!

[Bug libstdc++/53841] [C++11] condition_variable::wait_until() fails with high resolution clocks

[redi at gcc dot gnu.org]

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



--- Comment #6 from Jonathan Wakely  2012-11-15 
01:56:13 UTC ---

Author: redi

Date: Thu Nov 15 01:56:05 2012

New Revision: 193528



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

Log:

PR libstdc++/53841

* include/std/condition_variable (condition_variable::wait_until):

Handle clocks with higher resolution than __clock_t.

* testsuite/30_threads/condition_variable/members/53841.cc: New.



Added:

   

branches/gcc-4_7-branch/libstdc++-v3/testsuite/30_threads/condition_variable/members/53841.cc

Modified:

branches/gcc-4_7-branch/libstdc++-v3/ChangeLog

branches/gcc-4_7-branch/libstdc++-v3/include/std/condition_variable

[Bug c++/37276] Trouble with some (C99?) math builtins and namespace std

[jason at gcc dot gnu.org]

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



--- Comment #14 from Jason Merrill  2012-11-15 
01:53:55 UTC ---

Author: jason

Date: Thu Nov 15 01:53:48 2012

New Revision: 193526



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

Log:

PR c++/37276

* decl.c (decls_match): Remove #ifdef around earlier fix.



Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/decl.c

[Bug c++/55275] abi_tag attribute doesn't work on explicit specializations of class templates

[jason at gcc dot gnu.org]

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



--- Comment #3 from Jason Merrill  2012-11-15 
01:53:34 UTC ---

Author: jason

Date: Thu Nov 15 01:53:23 2012

New Revision: 193524



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

Log:

PR c++/55275

* pt.c (maybe_process_partial_specialization): Update

DECL_SOURCE_LOCATION for new specializations.



Added:

trunk/gcc/testsuite/g++.dg/abi/abi-tag3.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/pt.c

trunk/gcc/testsuite/g++.dg/cpp0x/pr31439.C

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

trunk/libstdc++-v3/testsuite/ext/type_traits/add_unsigned_integer_neg.cc

trunk/libstdc++-v3/testsuite/ext/type_traits/remove_unsigned_integer_neg.cc

[Bug other/55333] New: [x32] 8 asan test failures

[hjl.tools at gmail dot com]

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



 Bug #: 55333

   Summary: [x32] 8 asan test failures

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: other

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

ReportedBy: hjl.to...@gmail.com





Schedule of variations:

unix/-mx32



Running target unix/-mx32

Using /usr/share/dejagnu/baseboards/unix.exp as board description file for

target.

Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.

Using /export/gnu/import/git/gcc/gcc/testsuite/config/default.exp as

tool-and-target-specific interface file.

Running /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/asan/asan.exp ...

FAIL: c-c++-common/asan/memcmp-1.c  -O0  output pattern test, is

=

==3035== ERROR: AddressSanitizer stack-buffer-overflow on address 0xffe91e45 at

pc 0xf5b1e798 bp 0xffe91df0 sp 0xffe91d90

READ of size 1 at 0xffe91e45 thread T0

#0 0xf5b1e797 in __interceptor_memcmp

/export/gnu/import/git/gcc/libsanitizer/asan/asan_interceptors.cc:218

(discriminator 1)

Address 0xffe91e45 is located at offset 37 in frame  of T0's stack:

  This frame has 2 object(s):

[32, 36) 'a1'

[96, 100) 'a2'

HINT: this may be a false positive if your program uses some custom stack

unwind mechanism

  (longjmp and C++ exceptions *are* supported)

Shadow byte and word:

  0x3ffd23c8: 4

  0x3ffd23c8: 04 f4 f4 f4

More shadow bytes:

  0x3ffd23b8: 00 00 00 00

  0x3ffd23bc: 00 00 00 00

  0x3ffd23c0: 00 00 00 00

  0x3ffd23c4: f1 f1 f1 f1

=>0x3ffd23c8: 04 f4 f4 f4

  0x3ffd23cc: f2 f2 f2 f2

  0x3ffd23d0: 04 f4 f4 f4

  0x3ffd23d4: f3 f3 f3 f3

  0x3ffd23d8: 00 00 00 00

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

Stats: 0M realloced by 0 calls

Stats: 0M freed by 0 calls

Stats: 0M really freed by 0 calls

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

  mmaps   by size class: 

  mallocs by size class: 

  frees   by size class: 

  rfrees  by size class: 

Stats: malloc large: 0 small slow: 0

==3035== ABORTING

, should match ERROR: AddressSanitizer stack-buffer-overflow.*(

|

)#0 0x[0-9a-f]+ (in _*(interceptor_|)memcmp |[(])[^

]*(

|

)#1 0x[0-9a-f]+ (in _*main|[(])[^

]*(

|

)

FAIL: c-c++-common/asan/memcmp-1.c  -O1  output pattern test, is

=

==3135== ERROR: AddressSanitizer stack-buffer-overflow on address 0xffe3c135 at

pc 0xf5b81798 bp 0xffe3c100 sp 0xffe3c0a0

READ of size 1 at 0xffe3c135 thread T0

#0 0xf5b81797 in __interceptor_memcmp

/export/gnu/import/git/gcc/libsanitizer/asan/asan_interceptors.cc:218

(discriminator 1)

Address 0xffe3c135 is located at offset 37 in frame  of T0's stack:

  This frame has 2 object(s):

[32, 36) 'a1'

[96, 100) 'a2'

HINT: this may be a false positive if your program uses some custom stack

unwind mechanism

  (longjmp and C++ exceptions *are* supported)

Shadow byte and word:

  0x3ffc7826: 4

  0x3ffc7824: f1 f1 04 f4

More shadow bytes:

  0x3ffc7814: 00 00 00 00

  0x3ffc7818: 00 00 00 00

  0x3ffc781c: 00 00 00 00

  0x3ffc7820: 00 00 f1 f1

=>0x3ffc7824: f1 f1 04 f4

  0x3ffc7828: f4 f4 f2 f2

  0x3ffc782c: f2 f2 04 f4

  0x3ffc7830: f4 f4 f3 f3

  0x3ffc7834: f3 f3 00 00

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

Stats: 0M realloced by 0 calls

Stats: 0M freed by 0 calls

Stats: 0M really freed by 0 calls

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

  mmaps   by size class: 

  mallocs by size class: 

  frees   by size class: 

  rfrees  by size class: 

Stats: malloc large: 0 small slow: 0

==3135== ABORTING

, should match ERROR: AddressSanitizer stack-buffer-overflow.*(

|

)#0 0x[0-9a-f]+ (in _*(interceptor_|)memcmp |[(])[^

]*(

|

)#1 0x[0-9a-f]+ (in _*main|[(])[^

]*(

|

)

FAIL: c-c++-common/asan/memcmp-1.c  -O2  output pattern test, is

=

==3220== ERROR: AddressSanitizer stack-buffer-overflow on address 0xffa93f15 at

pc 0xf5b6d798 bp 0xffa93ee0 sp 0xffa93e80

READ of size 1 at 0xffa93f15 thread T0

#0 0xf5b6d797 in __interceptor_memcmp

/export/gnu/import/git/gcc/libsanitizer/asan/asan_interceptors.cc:218

(discriminator 1)

Address 0xffa93f15 is located at offset 37 in frame  of T0's stack:

  This frame has 2 object(s):

[32, 36) 'a1'

[96, 100) 'a2'

HINT: this may be a false positive if your program uses some custom stack

unwind mechanism

  (longjmp and C++ exceptions *are* supported)

Shadow byte and word:

  0x3ff527e2: 4

  0x3ff527e0: f1 f1 04 f4

More shadow bytes:

  0x3ff527d0: 00 00 00 00

  0x3ff527d4: 00 00 00 00

  0x3ff527d8: 00 00 00 00

  0x3ff527dc: 00 00 f1 f1

=>0x3ff527e0: f1 f1 04 f4

  0x3ff527e4: f4 f4 f2 f2

  0x3ff527e8: f2 f2 04 f4

  0x3ff5

[Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed

[tejohnson at google dot com]

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



--- Comment #20 from Teresa Johnson  2012-11-15 
01:52:45 UTC ---

On Wed, Nov 14, 2012 at 5:42 PM, hubicka at ucw dot cz

 wrote:

>

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

>

> --- Comment #19 from Jan Hubicka  2012-11-15 01:42:55 
> UTC ---

>> Oh got it - it is this one, right?:

>>

>> profiling:/home/tejohnson/extra/gcc_trunk_3_obj/libcpp/files.gcda:Invocation

>> mismatch - some data files may have been removed

>

> Yes, it is this one.

>>

>> I think this one was there before, but I had to modify it after my

>> histogram change. I will take a look.

>

> Also could you please make a patch to make maybe_hot_count_p to use

> hitogram driven cutoff? Otherwise the histograms would be completely

> unused for 4.8 and it would be stupid to carry all the extra data

> for no use.  I would like this to be done soon, since I plan to base

> some of inliner re-tunning to be based on this.



Ok, I can do that. I had tried that but didn't see any gain yet (need

to take a look at my results again). I have been playing with teasing

apart the various uses of this cutoff (inlining vs instruction

selection vs etc) too, but can do that in a later release once the

appropriate individual cutoffs are tuned. I also have a loop unroller

patch on the google branch that uses this that needs to be ported to

trunk. It was in the original working set patch I sent for review,

that ended up being split out and revised heavily. Shall I resubmit

this part for 4.8 or is it too late?



Thanks,

Teresa



>

> The mismatch is independent problem, yes.

>

> Honza

>

> --

> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email

> --- You are receiving this mail because: ---

> You are on the CC list for the bug.







--

Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

[Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed

[hubicka at ucw dot cz]

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



--- Comment #19 from Jan Hubicka  2012-11-15 01:42:55 
UTC ---

> Oh got it - it is this one, right?:

> 

> profiling:/home/tejohnson/extra/gcc_trunk_3_obj/libcpp/files.gcda:Invocation

> mismatch - some data files may have been removed



Yes, it is this one.

> 

> I think this one was there before, but I had to modify it after my

> histogram change. I will take a look.



Also could you please make a patch to make maybe_hot_count_p to use

hitogram driven cutoff? Otherwise the histograms would be completely

unused for 4.8 and it would be stupid to carry all the extra data

for no use.  I would like this to be done soon, since I plan to base

some of inliner re-tunning to be based on this.



The mismatch is independent problem, yes.



Honza

Re: [Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed

[Jan Hubicka]

> Oh got it - it is this one, right?:
> 
> profiling:/home/tejohnson/extra/gcc_trunk_3_obj/libcpp/files.gcda:Invocation
> mismatch - some data files may have been removed

Yes, it is this one.
> 
> I think this one was there before, but I had to modify it after my
> histogram change. I will take a look.

Also could you please make a patch to make maybe_hot_count_p to use
hitogram driven cutoff? Otherwise the histograms would be completely
unused for 4.8 and it would be stupid to carry all the extra data
for no use.  I would like this to be done soon, since I plan to base
some of inliner re-tunning to be based on this.

The mismatch is independent problem, yes.

Honza

[Bug libstdc++/53841] [C++11] condition_variable::wait_until() fails with high resolution clocks

[redi at gcc dot gnu.org]

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



--- Comment #5 from Jonathan Wakely  2012-11-15 
01:38:23 UTC ---

Author: redi

Date: Thu Nov 15 01:38:17 2012

New Revision: 193523



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

Log:

PR libstdc++/53841

* include/std/condition_variable (condition_variable::wait_until):

Handle clocks with higher resolution than __clock_t.

(condition_variable::__wait_until_impl): Remove unnecessary _Clock

parameter.

* testsuite/30_threads/condition_variable/members/53841.cc: New.



Added:

trunk/libstdc++-v3/testsuite/30_threads/condition_variable/members/53841.cc

Modified:

trunk/libstdc++-v3/ChangeLog

trunk/libstdc++-v3/include/std/condition_variable

[Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed

[tejohnson at google dot com]

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



--- Comment #18 from Teresa Johnson  2012-11-15 
01:33:43 UTC ---

On Wed, Nov 14, 2012 at 5:28 PM, Teresa Johnson  wrote:

>

>

>

>

> On Wed, Nov 14, 2012 at 5:17 PM, hubicka at gcc dot gnu.org 
>  wrote:

>>

>>

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

>>

>> --- Comment #16 from Jan Hubicka  2012-11-15 
>> 01:17:43 UTC ---

>> Theresa: I am using gcc10 from compilation farm, but I think it is fairly

>> universal problem.

>

>

> Ok, I am doing a profiledbootstrap  -j24 with trunk on linux x86_64 to see if 
> I can reproduce it.

>

>>

>> Also I think that gcc_assert should not be assert, but an user readable error

>> about gcov file corruption.

>

>

> Are we talking about the coverage mismatch error, i.e.:

>

>  ../../libiberty/cp-demangle.c: In function 'd_print_cast.isra.8':

> ../../libiberty/cp-demangle.c:5642:1: error: the control flow of function

> 'd_print_cast.isra.8' does not match its profile data (counter 'arcs')

> [-Werror=coverage-mismatch]

>  }

>  ^

> ../../libiberty/cp-demangle.c:5642:1: note: use -Wno-error=coverage-mismatch 
> to

> tolerate the mismatch but performance may drop if the function is hot

>

> I don't think this was introduced by my changes. Or are we talking about a 
> different error?





Oh got it - it is this one, right?:



profiling:/home/tejohnson/extra/gcc_trunk_3_obj/libcpp/files.gcda:Invocation

mismatch - some data files may have been removed



I think this one was there before, but I had to modify it after my

histogram change. I will take a look.



Teresa



>

>

> Thanks,

> Teresa

>>

>>

>> --

>> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email

>> --- You are receiving this mail because: ---

>> You are on the CC list for the bug.

>

>

>

>

> --

> Teresa Johnson | Software Engineer |  tejohn...@google.com |  408-460-2413

>







--

Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

[Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed

[tejohnson at google dot com]

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



--- Comment #17 from Teresa Johnson  2012-11-15 
01:28:47 UTC ---

On Wed, Nov 14, 2012 at 5:17 PM, hubicka at gcc dot gnu.org <

gcc-bugzi...@gcc.gnu.org> wrote:



>

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

>

> --- Comment #16 from Jan Hubicka  2012-11-15

> 01:17:43 UTC ---

> Theresa: I am using gcc10 from compilation farm, but I think it is fairly

> universal problem.

>



Ok, I am doing a profiledbootstrap  -j24 with trunk on linux x86_64 to see

if I can reproduce it.





> Also I think that gcc_assert should not be assert, but an user readable

> error

> about gcov file corruption.

>



Are we talking about the coverage mismatch error, i.e.:



 ../../libiberty/cp-demangle.c: In function 'd_print_cast.isra.8':

../../libiberty/cp-demangle.c:5642:1: error: the control flow of function

'd_print_cast.isra.8' does not match its profile data (counter 'arcs')

[-Werror=coverage-mismatch]

 }

 ^

../../libiberty/cp-demangle.c:5642:1: note: use

-Wno-error=coverage-mismatch to

tolerate the mismatch but performance may drop if the function is hot



I don't think this was introduced by my changes. Or are we talking about a

different error?



Thanks,

Teresa



>

> --

> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email

> --- You are receiving this mail because: ---

> You are on the CC list for the bug.

>

[Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed

[hubicka at gcc dot gnu.org]

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



--- Comment #16 from Jan Hubicka  2012-11-15 
01:17:43 UTC ---

Theresa: I am using gcc10 from compilation farm, but I think it is fairly

universal problem.

Also I think that gcc_assert should not be assert, but an user readable error

about gcov file corruption.

[Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed

[hubicka at gcc dot gnu.org]

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



--- Comment #15 from Jan Hubicka  2012-11-15 
01:10:29 UTC ---

Note that profiledbootstrap still dies for me on

config.status: creating tests/rand/Makefile

../../libiberty/cp-demangle.c: In function 'd_print_cast.isra.8':

../../libiberty/cp-demangle.c:5642:1: error: the control flow of function

'd_print_cast.isra.8' does not match its profile data (counter 'arcs')

[-Werror=coverage-mismatch]

 }

 ^

../../libiberty/cp-demangle.c:5642:1: note: use -Wno-error=coverage-mismatch to

tolerate the mismatch but performance may drop if the function is hot

../../libiberty/cp-demangle.c: In function 'd_print_function_type.isra.7':

../../libiberty/cp-demangle.c:5642:1: error: the control flow of function

'd_print_function_type.isra.7' does not match its profile data (counter 'arcs')

[-Werror=coverage-mismatch]

../../libiberty/cp-demangle.c:5642:1: note: use -Wno-error=coverage-mismatch to

tolerate the mismatch but performance may drop if the function is hot

../../libiberty/cp-demangle.c: In function 'd_print_array_type.isra.6':

../../libiberty/cp-demangle.c:5642:1: error: the control flow of function

'd_print_array_type.isra.6' does not match its profile data (counter 'arcs')

[-Werror=coverage-mismatch]

../../libiberty/cp-demangle.c:5642:1: note: use -Wno-error=coverage-mismatch to

tolerate the mismatch but performance may drop if the function is hot

../../libiberty/cp-demangle.c: In function 'd_lookup_template_argument.isra.5':

../../libiberty/cp-demangle.c:5642:1: error: the control flow of function

'd_lookup_template_argument.isra.5' does not match its profile data (counter

'arcs') [-Werror=coverage-mismatch]

../../libiberty/cp-demangle.c:5642:1: note: use -Wno-error=coverage-mismatch to

tolerate the mismatch but performance may drop if the function is hot

../../libiberty/cp-demangle.c: In function 'd_number.isra.0':





I am unsure if this is bug in profile code or different configuration of

libberty...

[Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed

[hubicka at gcc dot gnu.org]

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



--- Comment #14 from Jan Hubicka  2012-11-15 
01:07:04 UTC ---

Author: hubicka

Date: Thu Nov 15 01:07:01 2012

New Revision: 193522



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

Log:

PR bootstrap/55051

* gcov-io.c (gcov_read_summary): Fix array bound check.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/gcov-io.c

[Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed

[hubicka at gcc dot gnu.org]

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



--- Comment #13 from Jan Hubicka  2012-11-15 
01:03:09 UTC ---

OK, the false positive is on quite sloppy code in gcov-io.c. I attached

testcase to PR55079 and will fix the gcc_assert specifying the loop bounds to

not allow out-of-bound read.

[Bug tree-optimization/55079] [4.8 regression] false positive -Warray-bounds (also seen at -O3 bootstrap)

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka  2012-11-15 
01:01:30 UTC ---
This is reduced testcase from gcov.c
int a[8];
int
t (void)
{
  int ix = 0;
  int k;
  int b = 0;
  int curr = 0;
  for (k = 0; k < 2; k++)
{
  b = ix * 32;
  curr = a[ix++];
  if (!(ix <= 8))
abort ();

  while (curr)
{
  b = ix * 32;
  curr = a[ix++];
  if (!(ix <= 8))
abort ();
}
}
  return curr + b;
}

jan@linux-e0ml:~/trunk/build/gcc> ./xgcc -B ./ -O2 -fprofile-use t.c
-Warray-bounds -S -S -fdump-tree-cunroll-details  -fdump-tree-all-details  
t.c: In function ‘t’:
t.c:14:2: warning: incompatible implicit declaration of built-in function
‘abort’ [enabled by default]
  abort ();
  ^
t.c:25:1: note: file /home/jan/trunk/build/gcc/t.gcda not found, execution
counts estimated
 }
 ^
t.c:19:15: warning: array subscript is above array bounds [-Warray-bounds]
   curr = a[ix++];
   ^
t.c:19:15: warning: array subscript is above array bounds [-Warray-bounds]

Obivously here unroller does not know that bv_ix is at least 1

[Bug libstdc++/53841] [C++11] condition_variable::wait_until() fails with high resolution clocks

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |

[Bug c/45317] struct union misalignment

[sherpya at netfarm dot it]

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



--- Comment #4 from Gianluigi Tiesi  2012-11-15 
00:36:10 UTC ---

sorry my comment are for another bug, please ignore them

[Bug debug/55231] ICE in output_addr_table_entry, at dwarf2out.c:21782 with -gsplit-dwarf

[ccoutant at gcc dot gnu.org]

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



--- Comment #3 from Cary Coutant  2012-11-15 
00:34:56 UTC ---

(In reply to comment #1)

> Another issue:

> markus@x4 ~ % c++ -c -O0 -gsplit-dwarf test.ii -o /dev/null

> /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../x86_64-pc-linux-gnu/bin/objcopy:

> Warning: '/dev/null' is not an ordinary file



I'm not sure what the right thing to do about this would be -- is there a

portable way to check whether the -o option names a real filename or not? Is

your intent that neither .o nor .dwo is generated? Why use -gsplit-dwarf in

that case? I'm inclined to document this away. If you care, please clone this

into a new bug report.

[Bug other/54279] [4.8 Regression] first stage build with g++ fails with "." as the first component of $PATH

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #2 from Andrew Pinski  2012-11-15 
00:31:45 UTC ---

I am going to take a stab at fixing this.

[Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed

[hjl.tools at gmail dot com]

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



--- Comment #12 from H.J. Lu  2012-11-15 00:30:51 
UTC ---

Revision 193513 gave:



../../src-trunk/gcc/common/common-targhooks.c: In function

'default_target_handle_option(gcc_options*, gcc_options*, cl_decoded_option

const*, unsigned int)':

../../src-trunk/gcc/common/common-targhooks.c:85:4: note: file

/export/gnu/import/git/gcc-test-profile/bld/gcc/common/common-targhooks.gcda

not found, execution counts estimated

   };



In file included from ../../src-trunk/gcc/gcov.c:47:0:

../../src-trunk/gcc/gcov.c: In function 'read_count_file(function_info*)':

../../src-trunk/gcc/gcov-io.c:555:54: error: array subscript is above array

bounds [-Werror=array-bounds]

   cur_bitvector = histo_bitvector[bv_ix++];

  ^

In file included from ../../src-trunk/gcc/gcov-dump.c:30:0:

../../src-trunk/gcc/gcov-io.c:555:54: error: array subscript is above array

bounds [-Werror=array-bounds]

   cur_bitvector = histo_bitvector[bv_ix++];

  ^

cc1plus: all warnings being treated as errors

make[6]: *** [gcov-dump.o] Error 1

make[6]: *** Waiting for unfinished jobs

cc1plus: all warnings being treated as errors

make[6]: *** [gcov.o] Error 1

rm gcj-dbtool.pod jcf-dump.pod jv-convert.pod grmic.pod gc

[Bug debug/53145] [4.8 Regression] gcc.dg/pch/save-temps-1.c

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #6 from Andrew Pinski  2012-11-15 
00:28:06 UTC ---

Fixed.

[Bug libstdc++/55320] Invalid delete with throwing copy-c'tor passed to std::function

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #7 from Jonathan Wakely  2012-11-15 
00:23:09 UTC ---

fixed

[Bug c/45317] struct union misalignment

[sherpya at netfarm dot it]

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



--- Comment #3 from Gianluigi Tiesi  2012-11-15 
00:21:58 UTC ---

I've also tested with -malign-double and nothing changes, I don't need mingw32

abi on linux, I need mingw abi on mingw, somehow changed with 4.7.0, I'm not

sure if it's a bug or not

[Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed

[tejohnson at google dot com]

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

--- Comment #11 from Teresa Johnson  2012-11-15 
00:21:36 UTC ---
Sure, I will see if I can reproduce it.
Teresa


On Wed, Nov 14, 2012 at 4:07 PM, hubicka at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051
>
> Jan Hubicka  changed:
>
>What|Removed |Added
>
> 
>  CC||tejohnson at google dot
> com
>
> --- Comment #10 from Jan Hubicka  2012-11-15
> 00:07:12 UTC ---
> With make -j24 I also get tons of Invocation mismatch messages Theresa
> introduced。 Theresa, can you look into it?
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are on the CC list for the bug.
>

[Bug libstdc++/55320] Invalid delete with throwing copy-c'tor passed to std::function

[redi at gcc dot gnu.org]

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



--- Comment #6 from Jonathan Wakely  2012-11-15 
00:21:16 UTC ---

Author: redi

Date: Thu Nov 15 00:21:09 2012

New Revision: 193520



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

Log:

PR libstdc++/55320

* include/std/functional (function::function(F)): Set _M_manager after

operations that could throw.

(_Function_base::_Ref_manager::_M_init_functor): Use addressof.

* include/tr1/functional

(_Function_base::_Ref_manager::_M_init_functor): Use addressof.

(_Function_base::_Base_manager::_M_get_pointer): Likewise.

* testsuite/20_util/function/cons/55320.cc: New.

* testsuite/20_util/function/cons/addressof.cc: New.

* testsuite/20_util/bind/ref_neg.cc: Adjust dg-error line numbers.

* testsuite/tr1/3_function_objects/function/10.cc: New.



Added:

   

branches/gcc-4_7-branch/libstdc++-v3/testsuite/20_util/function/cons/55320.cc

   

branches/gcc-4_7-branch/libstdc++-v3/testsuite/20_util/function/cons/addressof.cc

   

branches/gcc-4_7-branch/libstdc++-v3/testsuite/tr1/3_function_objects/function/10.cc

Modified:

branches/gcc-4_7-branch/libstdc++-v3/ChangeLog

branches/gcc-4_7-branch/libstdc++-v3/include/std/functional

branches/gcc-4_7-branch/libstdc++-v3/include/tr1/functional

branches/gcc-4_7-branch/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc

[Bug debug/55328] ICE: in output_addr_table_entry, at dwarf2out.c:21780 with -gsplit-dwarf

[ccoutant at gcc dot gnu.org]

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



Cary Coutant  changed:



   What|Removed |Added



 CC||markus at trippelsdorf dot

   ||de



--- Comment #2 from Cary Coutant  2012-11-15 
00:18:37 UTC ---

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

[Bug debug/55231] ICE in output_addr_table_entry, at dwarf2out.c:21782 with -gsplit-dwarf

[ccoutant at gcc dot gnu.org]

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



Cary Coutant  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #2 from Cary Coutant  2012-11-15 
00:18:37 UTC ---

Duplicate of PR debug/55328, fixed at r193515.



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

[Bug c/45317] struct union misalignment

[sherpya at netfarm dot it]

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



--- Comment #2 from Gianluigi Tiesi  2012-11-15 
00:13:28 UTC ---

so mingw < 4.7.0 has same packing behavior of linux gcc, why in _mingw_ >=

4.7.0 should I add -malign-double to be compatible with mingw < 4.7.0 and msvc

abi?

[Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||tejohnson at google dot com

--- Comment #10 from Jan Hubicka  2012-11-15 
00:07:12 UTC ---
With make -j24 I also get tons of Invocation mismatch messages Theresa
introduced。 Theresa, can you look into it?

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

[hjl.tools at gmail dot com]

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



H.J. Lu  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #7 from H.J. Lu  2012-11-15 00:04:31 
UTC ---

Fixed.

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

[hjl at gcc dot gnu.org]

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



--- Comment #6 from hjl at gcc dot gnu.org  2012-11-15 
00:03:41 UTC ---

Author: hjl

Date: Thu Nov 15 00:03:37 2012

New Revision: 193516



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

Log:

Add support for multilib run-time libraries



PR other/55291

* configure.ac (--enable-version-specific-runtime-libs): New option.

(AC_CANONICAL_SYSTEM): New.

(AM_ENABLE_MULTILIB): Moved right after AM_INIT_AUTOMAKE.

(toolexecdir): Support multilib.

(toolexeclibdir): Likewise.

(multilib_arg): New.

* Makefile.in: Regenerated.

* aclocal.m4: Likewise.

* configure: Likewise.

* asan/Makefile.in: Likewise.

* interception/Makefile.in: Likewise.

* sanitizer_common/Makefile.in: Likewise.



Modified:

trunk/libsanitizer/ChangeLog

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 fortran/48636] Enable more inlining with -O2 and higher

[hubicka at ucw dot cz]

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



--- Comment #40 from Jan Hubicka  2012-11-14 23:54:44 
UTC ---

mgrid do not seem to be sensitive to --param min-inline-speedup, so it seems

independent regression of this change.

No idea what goes wrong.



Honza

Re: [Bug fortran/48636] Enable more inlining with -O2 and higher

[Jan Hubicka]

mgrid do not seem to be sensitive to --param min-inline-speedup, so it seems 
independent regression of this change.
No idea what goes wrong.

Honza

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

[dominiq at lps dot ens.fr]

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



--- Comment #36 from Dominique d'Humieres  
2012-11-14 23:49:25 UTC ---

Jack,



Could you please post a patch with the regenerated files. I have lost my

struggle with the auto* versions and I am giving up.



TIA

[Bug debug/55328] ICE: in output_addr_table_entry, at dwarf2out.c:21780 with -gsplit-dwarf

[sterling at gcc dot gnu.org]

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



--- Comment #1 from sterling at gcc dot gnu.org 2012-11-14 23:36:54 UTC ---

Author: sterling

Date: Wed Nov 14 23:36:50 2012

New Revision: 193515



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

Log:

2012-11-14  Sterling Augustine  



PR debug/55328

* dwarf2out.c (index_address_table_entry): Check a node's refcount.







Modified:

trunk/gcc/ChangeLog

trunk/gcc/dwarf2out.c

[Bug target/55332] New: [4.8 Regression] libsanitizer breaks build on hpux

[danglin at gcc dot gnu.org]

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



 Bug #: 55332

   Summary: [4.8 Regression] libsanitizer breaks build on hpux

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: hppa64-hp-hpux11.11

Target: hppa64-hp-hpux11.11

 Build: hppa64-hp-hpux11.11





libtool: compile:  /test/gnu/gcc/objdir/./gcc/g++ -B/test/gnu/gcc/objdir/./gcc/ 

-nostdinc++ -nostdinc++

-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/

include/hppa64-hp-hpux11.11

-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++

-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++

-I/test/gnu/gcc/gcc/libstdc++-v3/include/backward

-I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util -L/test

/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src

-L/test/gnu/gcc/objdir/hppa

64-hp-hpux11.11/libstdc++-v3/src/.libs

-B/opt/gnu64/gcc/gcc-4.8/hppa64-hp-hpux11

.11/bin/ -B/opt/gnu64/gcc/gcc-4.8/hppa64-hp-hpux11.11/lib/ -isystem

/opt/gnu64/gcc/gcc-4.8/hppa64-hp-hpux11.11/include -isystem

/opt/gnu64/gcc/gcc-4.8/hppa64-hp

-hpux11.11/sys-include -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS

-D__STDC_

FORMAT_MACROS -D__STDC_LIMIT_MACROS -DASAN_HAS_EXCEPTIONS=1

-DASAN_FLEXIBLE_MAPP

ING_AND_OFFSET=0 -DASAN_NEEDS_SEGV=1 -I. -I../../../../gcc/libsanitizer/asan -I

../../../../gcc/libsanitizer/include -I ../../../../gcc/libsanitizer -Wall -W

-W

no-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin 

-fno-exceptions -fomit-frame-pointer -funwind-tables -fvisibility=hidden

-Wno-variadic-macros -Wno-c99-extensions -g -O2 -MT asan_allocator.lo -MD -MP

-MF .deps

/asan_allocator.Tpo -c ../../../../gcc/libsanitizer/asan/asan_allocator.cc 

-DPI

C -o .libs/asan_allocator.oIn file included from

../../../../gcc/libsanitizer/asan/asan_allocator.h:16:0,

 from ../../../../gcc/libsanitizer/asan/asan_allocator.cc:26:

../../../../gcc/libsanitizer/asan/asan_internal.h:22:3: error: #error "This

oper

ating system is not supported by AddressSanitizer"

 # error "This operating system is not supported by AddressSanitizer"



There doesn't seem any way to disable libsanitizer.



Whether it can be supported is TBD.

[Bug libstdc++/55320] Invalid delete with throwing copy-c'tor passed to std::function

[redi at gcc dot gnu.org]

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



--- Comment #5 from Jonathan Wakely  2012-11-14 
23:33:08 UTC ---

Author: redi

Date: Wed Nov 14 23:33:01 2012

New Revision: 193514



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

Log:

PR libstdc++/55320

* include/std/functional (function::function(F)): Set _M_manager after

operations that could throw.

(_Function_base::_Ref_manager::_M_init_functor): Use addressof.

* include/tr1/functional

(_Function_base::_Ref_manager::_M_init_functor): Use addressof.

(_Function_base::_Base_manager::_M_get_pointer): Likewise.

* testsuite/20_util/function/cons/55320.cc: New.

* testsuite/20_util/function/cons/addressof.cc: New.

* testsuite/20_util/function/cons/callable.cc: Remove header.

* testsuite/20_util/bind/ref_neg.cc: Adjust dg-error line numbers.

* testsuite/tr1/3_function_objects/function/10.cc: New.



Added:

trunk/libstdc++-v3/testsuite/20_util/function/cons/55320.cc

  - copied, changed from r193513,

trunk/libstdc++-v3/testsuite/20_util/function/cons/callable.cc

trunk/libstdc++-v3/testsuite/20_util/function/cons/addressof.cc

  - copied, changed from r193513,

trunk/libstdc++-v3/testsuite/20_util/function/cons/callable.cc

trunk/libstdc++-v3/testsuite/tr1/3_function_objects/function/10.cc

  - copied, changed from r193513,

trunk/libstdc++-v3/testsuite/20_util/function/cons/callable.cc

Modified:

trunk/libstdc++-v3/ChangeLog

trunk/libstdc++-v3/include/std/functional

trunk/libstdc++-v3/include/tr1/functional

trunk/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc

trunk/libstdc++-v3/testsuite/20_util/function/cons/callable.cc

[Bug fortran/48636] Enable more inlining with -O2 and higher

[hubicka at gcc dot gnu.org]

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



--- Comment #39 from Jan Hubicka  2012-11-14 
23:22:40 UTC ---

Hmm, indeed. Good catch. I will look into it.

[Bug libstdc++/53841] [C++11] condition_variable::wait_until() fails with high resolution clocks

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-14

 Ever Confirmed|0   |1



--- Comment #4 from Jonathan Wakely  2012-11-14 
23:14:22 UTC ---

(In reply to comment #3)

> -const chrono::nanoseconds __delta = __atime - __c_entry;

> -const __clock_t::time_point __s_atime = __s_entry + __delta;

> +const auto __delta = __atime - __c_entry;

> +const auto __s_atime = __s_entry + __delta;



Thanks for this.



> Clang trunk currently rejects this code (prior to instantiation, even) due to

> this invalid conversion if _GLIBCXX_USE_CLOCK_REALTIME is not defined (as 
> seems

> to be the case on several popular linux distributions).



That's not defined on GNU/Linux unless you build GCC with

--enable-libstdcxx-time=rt, which has performance implications.

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

[konstantin.s.serebryany at gmail dot com]

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



--- Comment #35 from Konstantin Serebryany  2012-11-14 23:10:00 UTC ---

>> Is that certain to be soon enough 

Not 100%. I am just warning you.



>> Will the replacement of mach_override also depend on the Core Foundation 
>> framework?



That's the question to Alex.

[Bug libstdc++/53841] [C++11] condition_variable::wait_until() fails with high resolution clocks

[richard-gccbugzilla at metafoo dot co.uk]

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



Richard Smith  changed:



   What|Removed |Added



 CC||richard-gccbugzilla at

   ||metafoo dot co.uk



--- Comment #3 from Richard Smith  
2012-11-14 23:06:07 UTC ---

This code has more problems with duration conversions:



// DR 887 - Sync unknown clock to known clock.

const typename _Clock::time_point __c_entry = _Clock::now();

const __clock_t::time_point __s_entry = __clock_t::now();

const chrono::nanoseconds __delta = __atime - __c_entry;

const __clock_t::time_point __s_atime = __s_entry + __delta;



The last line attempts to implicitly convert from time_point<[...],

nanoseconds> to system_clock::time_point, which may be in microseconds or even

in seconds.



Suggested fix:



-const chrono::nanoseconds __delta = __atime - __c_entry;

-const __clock_t::time_point __s_atime = __s_entry + __delta;

+const auto __delta = __atime - __c_entry;

+const auto __s_atime = __s_entry + __delta;



Clang trunk currently rejects this code (prior to instantiation, even) due to

this invalid conversion if _GLIBCXX_USE_CLOCK_REALTIME is not defined (as seems

to be the case on several popular linux distributions).

[Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed

[hubicka at gcc dot gnu.org]

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



--- Comment #9 from Jan Hubicka  2012-11-14 
23:03:27 UTC ---

Author: hubicka

Date: Wed Nov 14 23:03:22 2012

New Revision: 193512



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

Log:



PR bootstrap/55051

* ipa-inline.c (edge_badness): Improve dumping; fix overflow.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/ipa-inline.c

[Bug c++/55325] [4.8 Regression]: g++.dg/cpp0x/constexpr-complex.C excess errors

[ubizjak at gmail dot com]

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



--- Comment #10 from Uros Bizjak  2012-11-14 22:42:45 
UTC ---

(In reply to comment #7)

> > Right, thanks, I was just about to analyze that one.  Speaking of that 
> > commit,

> > some of the new tests fail for me:

> > FAIL: g++.dg/cpp0x/gnu_fext-numeric-literals.C (test for excess errors)

> > FAIL: g++.dg/cpp0x/std_fext-numeric-literals.C (test for excess errors)

> > 

> > and in g++.log:

> > Excess errors:

> > /tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/cpp0x/gnu_fext-numeric-literals.C:94:3:

> > ...

> > maybe related, maybe material for a new PR.

> 

> I'm not getting this on x86_64-linux at least.  What target are you on?



Probably due to the fact that x86_64 defines TARGET_C_MODE_FOR_SUFFIX that

declares support for non-standard 'q' and 'w' suffixes. There is a small group

of targets that declare this define:



config/aarch64/aarch64.c:#undef TARGET_C_MODE_FOR_SUFFIX

config/aarch64/aarch64.c:#define TARGET_C_MODE_FOR_SUFFIX

aarch64_c_mode_for_suffix

config/ia64/ia64.c:#undef TARGET_C_MODE_FOR_SUFFIX

config/ia64/ia64.c:#define TARGET_C_MODE_FOR_SUFFIX ia64_c_mode_for_suffix

config/i386/i386.c.orig:#undef TARGET_C_MODE_FOR_SUFFIX

config/i386/i386.c.orig:#define TARGET_C_MODE_FOR_SUFFIX ix86_c_mode_for_suffix

config/i386/i386.c:#undef TARGET_C_MODE_FOR_SUFFIX

config/i386/i386.c:#define TARGET_C_MODE_FOR_SUFFIX ix86_c_mode_for_suffix

config/pa/pa.c:#undef TARGET_C_MODE_FOR_SUFFIX

config/pa/pa.c:#define TARGET_C_MODE_FOR_SUFFIX pa_c_mode_for_suffix



Others are out of luck with 'q' and 'w' suffixes.

[Bug target/53346] [4.6/4.7/4.8 Regression] Bad vectorization in the proc cptrf2 of rnflow.f90

[hubicka at gcc dot gnu.org]

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



--- Comment #22 from Jan Hubicka  2012-11-14 
22:38:19 UTC ---

OK, similar loop in C looks like:

float a[1];

float b[1];

t()

{

  int mi = 0,i;

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

if (a[i]")))

(set (pc) (if_then_else

-  (match_operator 0 "ordered_comparison_operator"

+  (match_operator 0 "comparison_operator"

[(reg:CC FLAGS_REG) (const_int 0)])

   (label_ref (match_operand 3))

   (pc)))]

@@ -982,7 +982,7 @@

(compare:CC (match_operand:SWIM 2 "nonimmediate_operand")

(match_operand:SWIM 3 "")))

(set (match_operand:QI 0 "register_operand")

-   (match_operator 1 "ordered_comparison_operator"

+   (match_operator 1 "comparison_operator"

  [(reg:CC FLAGS_REG) (const_int 0)]))]

   ""

 {

@@ -16120,7 +16120,7 @@



 (define_expand "movcc"

   [(set (match_operand:SWIM 0 "register_operand")

-   (if_then_else:SWIM (match_operand 1 "ordered_comparison_operator")

+   (if_then_else:SWIM (match_operand 1 "comparison_operator")

   (match_operand:SWIM 2 "")

   (match_operand:SWIM 3 "")))]

   ""

[Bug c++/55325] [4.8 Regression]: g++.dg/cpp0x/constexpr-complex.C excess errors

[paolo.carlini at oracle dot com]

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



--- Comment #9 from Paolo Carlini  2012-11-14 
22:30:51 UTC ---

In fact, however, a Linux target like s390x is also affected:



  http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg01187.html

[Bug c++/55325] [4.8 Regression]: g++.dg/cpp0x/constexpr-complex.C excess errors

[paolo.carlini at oracle dot com]

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



--- Comment #8 from Paolo Carlini  2012-11-14 
22:28:19 UTC ---

The latter seems indeed a target issue, as you can read here Hans-Peter

reported it for cris-elf, but have a look to the testresults mailing list to

double check. Personally, I would recommend applying asap the (obvious, IMHO)

fixes for the first two regression to remove noise from the results of, eg,

people testing on Linux.

[Bug target/53346] [4.6/4.7/4.8 Regression] Bad vectorization in the proc cptrf2 of rnflow.f90

[hubicka at gcc dot gnu.org]

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



Jan Hubicka  changed:



   What|Removed |Added



 CC||hubicka at gcc dot gnu.org



--- Comment #21 from Jan Hubicka  2012-11-14 
22:18:53 UTC ---

Well, as I wrote to the other PR, the main problem of cmov is extension of

dependency chain.  For well predicted sequence with conditional jump there is

no update of rbs so the loop executes faster, because the

loads/stores/comparisons executes "in parallel". The load in the next iteration

can then happen speculatively before the condition from previous iteration is

resolved. With cmov in it, there is dependence on rbx for all the other

computations in the loop.



I guess there is no localy available information suggesting suggesting that the

particular branch is well predictable, at least without profile feedback (where

we won't disable the conversion anyway).



I wonder

 1) why the conversion to cmov do not happen on RTL if conversion pass

 2) whether we can do something to detect similar patterns and possibly disable

cmovs on them...

[Bug c++/55325] [4.8 Regression]: g++.dg/cpp0x/constexpr-complex.C excess errors

[3dw4rd at verizon dot net]

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



--- Comment #7 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2012-11-14 
22:18:09 UTC ---

(In reply to comment #3)

> (In reply to comment #1)

> > I also see failing g++.dg/parse/template23.C and for this one too the 
> > problem

> > seems related to the recent changes for PR54413.

> 

> Right, thanks, I was just about to analyze that one.  Speaking of that commit,

> some of the new tests fail for me:

> FAIL: g++.dg/cpp0x/gnu_fext-numeric-literals.C (test for excess errors)

> FAIL: g++.dg/cpp0x/std_fext-numeric-literals.C (test for excess errors)

> 

> and in g++.log:

> Excess errors:

> /tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/cpp0x/gnu_fext-numeric-literals.C:94:3:

> ...

> maybe related, maybe material for a new PR.



I'm not getting this on x86_64-linux at least.  What target are you on?



Ed

[Bug middle-end/55331] [4.6/4.7/4.8 Regression] ICE: SIGSEGV in substitute_and_fold with -O2 -fno-tree-fre

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-14

 Ever Confirmed|0   |1



--- Comment #1 from Dominique d'Humieres  2012-11-14 
22:16:00 UTC ---

Confirmed:

4.6.0 2011-01-20 revision 169049 is OK

4.7.0 2011-04-14 revision 172429 gives an ICE.

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

[howarth at nitro dot med.uc.edu]

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



--- Comment #34 from Jack Howarth  2012-11-14 
22:09:37 UTC ---

(In reply to comment #32)

> Just want to repeat, that any work on mach_override may end up being wasted

> time

> because we plan to get rid of mach_override *really* soon.



One other question. Will the replacement of mach_override also depend on the

Core Foundation framework?

[Bug middle-end/55331] New: [4.6/4.7/4.8 Regression] ICE: SIGSEGV in substitute_and_fold with -O2 -fno-tree-fre

[zsojka at seznam dot cz]

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



 Bug #: 55331

   Summary: [4.6/4.7/4.8 Regression] ICE: SIGSEGV in

substitute_and_fold with -O2 -fno-tree-fre

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

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

ReportedBy: zso...@seznam.cz





Created attachment 28691

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

autoreduced testcase



Compiler output:

$ gcc -O2 -fno-tree-fre testcase-min7.ii -wrapper

valgrind,-q,--num-callers=40,--track-origins=yes -w

==4620== Invalid read of size 1

==4620==at 0xCEBDBD: substitute_and_fold(tree_node* (*)(tree_node*), bool

(*)(gimple_stmt_iterator*), bool) (gimple.h:1146)

==4620==by 0xC857C2: execute_copy_prop() (tree-ssa-copy.c:772)

==4620==by 0xADBB7A: execute_one_pass(opt_pass*) (passes.c:2339)

==4620==by 0xADBF94: execute_pass_list(opt_pass*) (passes.c:2400)

==4620==by 0xADBFA6: execute_pass_list(opt_pass*) (passes.c:2401)

==4620==by 0xADBFA6: execute_pass_list(opt_pass*) (passes.c:2401)

==4620==by 0x85E4F1: expand_function(cgraph_node*) (cgraphunit.c:1643)

==4620==by 0x8602A6: compile() (cgraphunit.c:1747)

==4620==by 0x860949: finalize_compilation_unit() (cgraphunit.c:2122)

==4620==by 0x67717E: cp_write_global_declarations() (decl2.c:4287)

==4620==by 0xBC527C: compile_file() (toplev.c:559)

==4620==by 0xBC7139: toplev_main(int, char**) (toplev.c:1881)

==4620==by 0x5A364BC: (below main) (in /lib64/libc-2.15.so)

==4620==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

==4620== 

testcase-min7.ii: In function 'void test01()':

testcase-min7.ii:253:1: internal compiler error: Segmentation fault

 test01 ()

 ^

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.





Tested revisions:

r193495 - crash

4.7 r191640 - crash

4.6 r191640 - crash

4.5 r191640 - OK

[Bug c++/55325] [4.8 Regression]: g++.dg/cpp0x/constexpr-complex.C excess errors

[3dw4rd at verizon dot net]

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



--- Comment #6 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2012-11-14 
21:52:14 UTC ---

(In reply to comment #4)

> 

> Invoke with gnu++0x:

> // { dg-options -std=gnu++0x }

> 

> Invoke with new flag:

> // { dg-options -std=c++0x -fext-numeric-literals }

> 

> I'll look at the other fails.



Similarly for template23.C.  We'll just set the correct flag in the testcase.



I'm still looking at the errors in comment 3.

[Bug rtl-optimization/55330] [4.8 Regression] ICE: Maximum number of LRA constraint passes is achieved (15) on gfortran.dg/actual_array_constructor_1.f90

[dominiq at lps dot ens.fr]

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



--- Comment #1 from Dominique d'Humieres  2012-11-14 
21:43:28 UTC ---

I don't see it on x86_64-apple-darwin10 (revisions 193495+patches and 193329).

[Bug tree-optimization/55329] [4.8 Regression] ICE: internal compiler error: in operator[], at vec.h:487 with -O -fno-guess-branch-probability -fnon-call-exceptions --param=early-inlining-insns=111

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-14

 Ever Confirmed|0   |1



--- Comment #1 from Dominique d'Humieres  2012-11-14 
21:22:02 UTC ---

Confirmed: 

revision 192891 (2012-10-28) is OK;

revision 193261 (2012-11-06) gives the ICE.

[Bug rtl-optimization/55330] New: [4.8 Regression] ICE: Maximum number of LRA constraint passes is achieved (15) on gfortran.dg/actual_array_constructor_1.f90

[zsojka at seznam dot cz]

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



 Bug #: 55330

   Summary: [4.8 Regression] ICE: Maximum number of LRA constraint

passes is achieved (15) on

gfortran.dg/actual_array_constructor_1.f90

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: rtl-optimization

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

ReportedBy: zso...@seznam.cz





Created attachment 28690

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

gfortran.dg/actual_array_constructor_1.f90



Compiler output:

$ gcc -O -fPIC -fno-dse -fno-guess-branch-probability

actual_array_constructor_1.f90

actual_array_constructor_1.f90: In function 'p':

actual_array_constructor_1.f90:20:0: internal compiler error: Maximum number of

LRA constraint passes is achieved (15)



   end subroutine

 ^

0x95f97e lra_constraints(bool)

/mnt/svn/gcc-trunk/gcc/lra-constraints.c:3284

0x94ec3c lra(_IO_FILE*)

/mnt/svn/gcc-trunk/gcc/lra.c:2274

0x906456 do_reload

/mnt/svn/gcc-trunk/gcc/ira.c:4624

0x906456 rest_of_handle_reload

/mnt/svn/gcc-trunk/gcc/ira.c:4737

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.





Another set of compiler flags with the same result:

$ gcc -O -fPIC -fstack-protector -fno-guess-branch-probability

actual_array_constructor_1.f90

actual_array_constructor_1.f90: In function 'p':

actual_array_constructor_1.f90:20:0: internal compiler error: Maximum number of

LRA constraint passes is achieved (15)



   end subroutine

 ^

0x95f97e lra_constraints(bool)

/mnt/svn/gcc-trunk/gcc/lra-constraints.c:3284

0x94ec3c lra(_IO_FILE*)

/mnt/svn/gcc-trunk/gcc/lra.c:2274

0x906456 do_reload

/mnt/svn/gcc-trunk/gcc/ira.c:4624

0x906456 rest_of_handle_reload

/mnt/svn/gcc-trunk/gcc/ira.c:4737

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.



Tested revisions:

r193495 - crash

[Bug bootstrap/55321] [4.8 regression] Ada bootstrap failure on armv5tel-linux-gnueabi

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2012-11-14

 AssignedTo|unassigned at gcc dot   |ebotcazou at gcc dot

   |gnu.org |gnu.org

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #1 from Eric Botcazou  2012-11-14 
20:56:53 UTC ---

This occurs with just -gnatpg -O.  Investigating...

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

[howarth at nitro dot med.uc.edu]

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



--- Comment #33 from Jack Howarth  2012-11-14 
20:56:50 UTC ---

(In reply to comment #32)

> Just want to repeat, that any work on mach_override may end up being wasted

> time

> because we plan to get rid of mach_override *really* soon.



Is that certain to be soon enough to insure that darwin has usable asan support

for gcc 4.8?

I would rather have the option of continuing to be able to test libsanitizer on

darwin than having no support at all.

[Bug tree-optimization/55329] New: [4.8 Regression] ICE: internal compiler error: in operator[], at vec.h:487 with -O -fno-guess-branch-probability -fnon-call-exceptions --param=early-inlining-insns=1

[zsojka at seznam dot cz]

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



 Bug #: 55329

   Summary: [4.8 Regression] ICE: internal compiler error: in

operator[], at vec.h:487 with -O

-fno-guess-branch-probability -fnon-call-exceptions

--param=early-inlining-insns=111

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

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

ReportedBy: zso...@seznam.cz





Created attachment 28689

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

preprocessed source; can't be significantly reduced



Compiler output:

$ gcc -O -fno-guess-branch-probability -fnon-call-exceptions

--param=early-inlining-insns=111

/mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/torture/pr48271.C -save-temps

/mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/torture/pr48271.C: In function 'void

stCheckReverseTrain()': 

/mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/torture/pr48271.C:116:6: internal

compiler error: in operator[], at vec.h:487

 void stCheckReverseTrain ()

  ^ 

0xc8fecb vec_t::operator[](unsigned int)  

/mnt/svn/gcc-trunk/gcc/vec.h:487

0xc8fecb tree_ssa_dominator_optimize

/mnt/svn/gcc-trunk/gcc/tree-ssa-dom.c:807

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.



Tested revisions:

r193495 - crash

4.7 r191640 - OK

[Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed

[markus at trippelsdorf dot de]

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



--- Comment #8 from Markus Trippelsdorf  
2012-11-14 20:48:21 UTC ---

Created attachment 28688

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

testcase



The testcase is only reduced to 97K, but it gets reduced very slowly

and I'm giving up.



 $ g++ -w -c -O2 -fprofile-generate test.ii

...

badness 0

badness 0

badness 1

test.ii:784:42: internal compiler error: in edge_badness, at ipa-inline.c:921

[Bug debug/55328] New: ICE: in output_addr_table_entry, at dwarf2out.c:21780 with -gsplit-dwarf

[zsojka at seznam dot cz]

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



 Bug #: 55328

   Summary: ICE: in output_addr_table_entry, at dwarf2out.c:21780

with -gsplit-dwarf

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: debug

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

ReportedBy: zso...@seznam.cz





Created attachment 28687

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

reduced testcase



Compiler output:

$ gcc -O -gsplit-dwarf testcase.c

testcase.c:5:1: internal compiler error: in output_addr_table_entry, at

dwarf2out.c:21780

 }

 ^

0x709e9b output_addr_table_entry

/mnt/svn/gcc-trunk/gcc/dwarf2out.c:21779

0x11d23b7 htab_traverse_noresize

/mnt/svn/gcc-trunk/libiberty/hashtab.c:784

0x746329 output_addr_table

/mnt/svn/gcc-trunk/gcc/dwarf2out.c:21820

0x746329 dwarf2out_finish

/mnt/svn/gcc-trunk/gcc/dwarf2out.c:23528

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.



Tested revisions:

r193495 - crash

[Bug c++/55323] ICE in expand_aggr_init_1, at cp/init.c:1718

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED

 AssignedTo|paolo.carlini at oracle dot |unassigned at gcc dot

   |com |gnu.org



--- Comment #4 from Paolo Carlini  2012-11-14 
20:37:16 UTC ---

Fixed for 4.8.0.

[Bug c++/55325] [4.8 Regression]: g++.dg/cpp0x/constexpr-complex.C excess errors

[paolo.carlini at oracle dot com]

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



--- Comment #5 from Paolo Carlini  2012-11-14 
20:36:37 UTC ---

If you ask me, I have I slight preference for the latter, because isn't always

obvious what gnu++* includes beyond c++*. But Jason will tell you, and the fix

is straightforward anyway.

[Bug c++/55323] ICE in expand_aggr_init_1, at cp/init.c:1718

[paolo at gcc dot gnu.org]

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



--- Comment #3 from paolo at gcc dot gnu.org  
2012-11-14 20:29:26 UTC ---

Author: paolo

Date: Wed Nov 14 20:29:07 2012

New Revision: 193505



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

Log:

/cp

2012-11-14  Paolo Carlini  



PR c++/55323

* init.c (emit_mem_initializers): Skip arguments == error_mark_node.



/testsuite

2012-11-14  Paolo Carlini  



PR c++/55323

* g++.dg/cpp0x/vt-55323.C: New.



Added:

trunk/gcc/testsuite/g++.dg/cpp0x/vt-55323.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/init.c

trunk/gcc/testsuite/ChangeLog

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

[konstantin.s.serebryany at gmail dot com]

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



--- Comment #32 from Konstantin Serebryany  2012-11-14 20:21:19 UTC ---

Just want to repeat, that any work on mach_override may end up being wasted

time

because we plan to get rid of mach_override *really* soon.

[Bug c++/55325] [4.8 Regression]: g++.dg/cpp0x/constexpr-complex.C excess errors

[3dw4rd at verizon dot net]

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



--- Comment #4 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2012-11-14 
20:20:27 UTC ---

OK, g++.dg/cpp0x/constexpr-complex.C will fail with the patch to control GNU

literal parsing.  i.e.  this behavior in intended.



The purpose of the test is to check that constexpr works with C99 complex

literals.  So we could fix the test in either one of two equivalent ways:



Invoke with gnu++0x:

// { dg-options -std=gnu++0x }



Invoke with new flag:

// { dg-options -std=c++0x -fext-numeric-literals }



Any preference on which one?



I'll look at the other fails.

[Bug c++/11750] class scope using-declaration lookup not implemented

[fabien at gcc dot gnu.org]

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



fabien at gcc dot gnu.org changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.8.0



--- Comment #10 from fabien at gcc dot gnu.org 2012-11-14 20:20:21 UTC ---

Fixed in 4.8.

[Bug c++/11750] class scope using-declaration lookup not implemented

[fabien at gcc dot gnu.org]

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

--- Comment #9 from fabien at gcc dot gnu.org 2012-11-14 20:12:56 UTC ---
Author: fabien
Date: Wed Nov 14 20:12:47 2012
New Revision: 193504

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

2012-11-14  Fabien Chêne  

PR c++/11750
* g++.dg/inherit/vitual9.C: New.

gcc/cp/ChangeLog

2012-11-14  Fabien Chêne  

PR c++/11750
* call.c (build_new_method_call_1): Check that the instance type
and the function context are the same before setting the flag
LOOKUP_NONVIRTUAL.

Added:
trunk/gcc/testsuite/g++.dg/inherit/virtual9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

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

[hubicka at gcc dot gnu.org]

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



Jan Hubicka  changed:



   What|Removed |Added



 CC||hubicka at gcc dot gnu.org



--- Comment #14 from Jan Hubicka  2012-11-14 
20:11:17 UTC ---

Hmm, the optimize_edge_for_speed never returns false here. The problem is that

patch assumes that interesting successors of block with partial anticipance are

blocks with partial anticipance. The anticipance however could be full and it

seems that full anticipance do not imply partial one

Index: tree-ssa-pre.c

===

*** tree-ssa-pre.c  (revision 193503)

--- tree-ssa-pre.c  (working copy)

*** do_partial_partial_insertion (basic_bloc

*** 3525,3531 

 may cause regressions on the speed path.  */

  FOR_EACH_EDGE (succ, ei, block->succs)

{

! if (bitmap_set_contains_value (PA_IN (succ->dest), val))

{

  if (optimize_edge_for_speed_p (succ))

do_insertion = true;

--- 3525,3532 

 may cause regressions on the speed path.  */

  FOR_EACH_EDGE (succ, ei, block->succs)

{

! if (bitmap_set_contains_value (PA_IN (succ->dest), val)

! || bitmap_set_contains_value (ANTIC_IN (succ->dest),

val))

{

  if (optimize_edge_for_speed_p (succ))

do_insertion = true;

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

[hubicka at ucw dot cz]

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



--- Comment #13 from Jan Hubicka  2012-11-14 19:43:00 
UTC ---

> So for the loop that starting at bb 28 you can see the xxtrt_46 access was not

> put into pretemp. Possible reason is exactly as it was mentioned by Richard -

> there were extra candidates collected and this one become less anticipatable

> 

> Skipping partial partial redundancy for expression

> {array_ref,mem_ref<0B>,xxtrt_46(D)}@.MEM_30(D) (0165)   

>not partially anticipated on any to be optimized for speed edges

>   ---

> Found partial partial redundancy for expression

>  {array_ref,mem_ref<0B>,xxtrt_46(D)}@.MEM_30(D) (0165)

> Created phi prephitmp_237 = PHI <_88(90), _85(29)>

>  in block 30



Hmm, interesting, what is the edge resonsible?

I would expect it to be the loopback edge and its frequency is:

;;   basic block 28, loop depth 0, count 0, freq 1998, maybe hot

;;prev block 92, next block 94, flags: (NEW, REACHABLE)

;;pred:   92 [100.0%, 180]  (FALLTHRU)

;;96 [100.0%, 1818]  (FALLTHRU,DFS_BACK)

  # ival2_136 = PHI 

  # ival2_140 = PHI 

  _137 = (integer(kind=8)) ival2_136;

  _138 = _137 + -1;

  _139 = *xxtrt_25(D)[_138];

  _141 = (integer(kind=8)) ival2_140;

  _142 = _141 + -1;

  _143 = *xxtrt_25(D)[_142];

  if (_139 < _143)

goto ; 

  else

goto ;



1818 that should be still hot.  Or isn't the heuristic backwards? I.e. I would

expect

the partial anticipance to sit on edge 92->28 (with freq 180) where we need to

insert

the computation to get the other path hot.



Honza

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

[Jan Hubicka]

> So for the loop that starting at bb 28 you can see the xxtrt_46 access was not
> put into pretemp. Possible reason is exactly as it was mentioned by Richard -
> there were extra candidates collected and this one become less anticipatable
> 
> Skipping partial partial redundancy for expression
> {array_ref,mem_ref<0B>,xxtrt_46(D)}@.MEM_30(D) (0165)   
>not partially anticipated on any to be optimized for speed edges
>   ---
> Found partial partial redundancy for expression
>  {array_ref,mem_ref<0B>,xxtrt_46(D)}@.MEM_30(D) (0165)
> Created phi prephitmp_237 = PHI <_88(90), _85(29)>
>  in block 30

Hmm, interesting, what is the edge resonsible?
I would expect it to be the loopback edge and its frequency is:
;;   basic block 28, loop depth 0, count 0, freq 1998, maybe hot
;;prev block 92, next block 94, flags: (NEW, REACHABLE)
;;pred:   92 [100.0%, 180]  (FALLTHRU)
;;96 [100.0%, 1818]  (FALLTHRU,DFS_BACK)
  # ival2_136 = PHI 
  # ival2_140 = PHI 
  _137 = (integer(kind=8)) ival2_136;
  _138 = _137 + -1;
  _139 = *xxtrt_25(D)[_138];
  _141 = (integer(kind=8)) ival2_140;
  _142 = _141 + -1;
  _143 = *xxtrt_25(D)[_142];
  if (_139 < _143)
goto ; 
  else
goto ;

1818 that should be still hot.  Or isn't the heuristic backwards? I.e. I would 
expect
the partial anticipance to sit on edge 92->28 (with freq 180) where we need to 
insert
the computation to get the other path hot.

Honza

[Bug tree-optimization/55079] [4.8 regression] false positive -Warray-bounds (also seen at -O3 bootstrap)

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

Summary|[4.8 regression] false  |[4.8 regression] false
   |positive -Warray-bounds |positive -Warray-bounds
   ||(also seen at -O3
   ||bootstrap)

--- Comment #8 from Jan Hubicka  2012-11-14 
19:31:16 UTC ---
Hi,
at -O3 bootstrap we have false positive on simplify-rtx.c
../../gcc/simplify-rtx.c: In function ‘rtx_def* simplify_plus_minus(rtx_code,
machine_mode, rtx, rtx)’:
../../gcc/simplify-rtx.c:4285:63: warning: array subscript is below array
bounds [-Warray-bounds]
   while (j-- && simplify_plus_minus_op_data_cmp (ops[j].op, save.op));


the siplified testcase is as follows:

int a[8];

void
test(unsigned int n)
{
  unsigned int i;
  unsigned int j;
  if (n<8)
  for (j=0;j

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

[howarth at nitro dot med.uc.edu]

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



--- Comment #31 from Jack Howarth  2012-11-14 
19:10:15 UTC ---

Also fine on i386-apple-darwin10...



howarth% ./use-after-free

=

==82550== ERROR: AddressSanitizer heap-use-after-free on address 0x0207afc5 at

pc 0x1f0b bp 0xbfffe3a8 sp 0xbfffe39c

READ of size 1 at 0x0207afc5 thread T0

#0 0x1f0a (/Users/howarth/./use-after-free+0x1f0a)

#1 0x1ec0 (/Users/howarth/./use-after-free+0x1ec0)

#2 0x0 (/Users/howarth/./use-after-free+0x0)

0x0207afc5 is located 5 bytes inside of 40-byte region [0x0207afc0,0x0207afe8)

freed by thread T0 here:

#0 0x10b34 (/sw_i386/lib/gcc4.8/lib/libasan.0.dylib+0xcb34)

#1 0x10cdb (/sw_i386/lib/gcc4.8/lib/libasan.0.dylib+0xccdb)

#2 0x1ee6 (/Users/howarth/./use-after-free+0x1ee6)

#3 0x1ec0 (/Users/howarth/./use-after-free+0x1ec0)

#4 0x0 (/Users/howarth/./use-after-free+0x0)

previously allocated by thread T0 here:

#0 0x10515 (/sw_i386/lib/gcc4.8/lib/libasan.0.dylib+0xc515)

#1 0x99041ba7 (/usr/lib/libSystem.B.dylib+0x4ba7)

#2 0x9903fc77 (/usr/lib/libSystem.B.dylib+0x2c77)

#3 0x1edc (/Users/howarth/./use-after-free+0x1edc)

#4 0x1ec0 (/Users/howarth/./use-after-free+0x1ec0)

#5 0x0 (/Users/howarth/./use-after-free+0x0)

Shadow byte and word:

  0x2040f5f8: fd

  0x2040f5f8: fd fd fd fd

More shadow bytes:

  0x2040f5e8: fa fa fa fa

  0x2040f5ec: fa fa fa fa

  0x2040f5f0: fa fa fa fa

  0x2040f5f4: fa fa fa fa

=>0x2040f5f8: fd fd fd fd

  0x2040f5fc: fd fd fd fd

  0x2040f600: fa fa fa fa

  0x2040f604: fa fa fa fa

  0x2040f608: 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: 7:4095; 

  mallocs by size class: 7:1; 

  frees   by size class: 7:1; 

  rfrees  by size class: 

Stats: malloc large: 0 small slow: 1

==82550== ABORTING



Alexander, can you check in

libsanitizer/interception/mach_override/mach_override.c (patched as in comment

229) and libsanitizer/interception/mach_override/mach_override.h with the build

infrastructure patch from

http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01119.html? It would be nice to be

able to start testing libsanitizer on intel darwin.

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

[sergos.gnu at gmail dot com]

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



--- Comment #12 from Sergey Ostanevich  2012-11-14 
18:56:22 UTC ---

Actually, it is not. 

I found that PRE did not collected a memory access within the loop that caused

later missing vectorization. Here is dump before (good one) and after the

commit (bad one)



:

pretmp_263 = (integer(kind=8)) ival2_82;

pretmp_264 = pretmp_263 + -1;

pretmp_265 = *xxtrt_46(D)[pretmp_264];



:

# ival2_10 = PHI 

# ival2_14 = PHI 

# prephitmp_266 = PHI 

_83 = (integer(kind=8)) ival2_10;

_84 = _83 + -1;

_85 = *xxtrt_46(D)[_84];

_86 = (integer(kind=8)) ival2_14;

_87 = _86 + -1;

_88 = prephitmp_266;

if (_85 < _88)

  goto ;

else

  goto ;



:

goto ;



:



:

# ival2_15 = PHI 

# prephitmp_237 = PHI <_88(90), _85(29)>

ival2_89 = ival2_10 + -1;

if (ival2_10 == ipos1_12)

  goto ;

else

  goto ;



   :

   goto ;

-

:



:

# ival2_10 = PHI 

   # ival2_14 = PHI 

_83 = (integer(kind=8)) ival2_10;

_84 = _83 + -1;

_85 = *xxtrt_46(D)[_84];

_86 = (integer(kind=8)) ival2_14;

_87 = _86 + -1;

_88 = *xxtrt_46(D)[_87];

if (_85 < _88)

  goto ;

else

  goto ;



:

goto ;



:



:

# ival2_15 = PHI 

ival2_89 = ival2_10 + -1;

if (ival2_10 == ipos1_12)

  goto ;

else

  goto ;



   :

   goto ;

-



So for the loop that starting at bb 28 you can see the xxtrt_46 access was not

put into pretemp. Possible reason is exactly as it was mentioned by Richard -

there were extra candidates collected and this one become less anticipatable



Skipping partial partial redundancy for expression

{array_ref,mem_ref<0B>,xxtrt_46(D)}@.MEM_30(D) (0165)   

   not partially anticipated on any to be optimized for speed edges

  ---

Found partial partial redundancy for expression

 {array_ref,mem_ref<0B>,xxtrt_46(D)}@.MEM_30(D) (0165)

Created phi prephitmp_237 = PHI <_88(90), _85(29)>

 in block 30

[Bug regression/55327] New: FAIL: gcc.dg/vect/slp-perm-8.c scan-tree-dump-times vect "vectorized 1 loops" 2

[gretay at gcc dot gnu.org]

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



 Bug #: 55327

   Summary: FAIL: gcc.dg/vect/slp-perm-8.c scan-tree-dump-times

vect "vectorized 1 loops" 2

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: regression

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

ReportedBy: gre...@gcc.gnu.org

CC: rguent...@suse.de

Target: arm-none-eabi





After r192987, the following tests started failing on arm-none-eabi:



FAIL: gcc.dg/vect/slp-perm-8.c scan-tree-dump-times vect "vectorized 1 loops" 2

FAIL: gcc.dg/vect/slp-perm-8.c scan-tree-dump-times vect "vectorizing stmts

using SLP" 1



One more loop is now vectorized using SLP.  



Similarly, the following test started failing:

FAIL: gcc.dg/vect/slp-perm-9.c scan-tree-dump-times vect "permutation requires

at least three vectors" 1



This message appears twice in the dump file, instead of just once, as expected.

[Bug c++/55254] Warn for implicit conversion from int to char

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



   Keywords||diagnostic



--- Comment #1 from Jonathan Wakely  2012-11-14 
17:12:23 UTC ---

An alternative would be to warn for conversion from the char literal '=' to an

integer type.  If you said '=' chances are you meant it to be a char, not

int('='). That wouldn't help if using a non-literal char though.



Or, when calling a function with two or more arguments, if all arguments

require an implicit conversion and re-ordering the arguments would require

fewer implicit conversions, suggest the arguments might be ordered incorrectly.

 That would be more work (to implement, at on every compilation)

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

[markus at trippelsdorf dot de]

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



--- Comment #5 from Markus Trippelsdorf  
2012-11-14 17:02:54 UTC ---

(In reply to comment #4)

> Also, this comparison doesn't have numbers for pure clang without

> -fsanitize=address and gcc without -faddress-sanitizer, so likely most of the

> speed differences can't be attributed just to asan.



Yes. It was meant as a rough estimate.



Here is a more complete result (clang trunk build with Release mode,

gcc trunk with --enable-checking=release and lto/profiledbootstraped):



  clang (with-without):  1278.47-662.47 = 616

  gcc   (with-without):  2733.02-1168.07= 1564.95



That's still a 60.64% slowdown.

[Bug c++/55325] [4.8 Regression]: g++.dg/cpp0x/constexpr-complex.C excess errors

[hp at gcc dot gnu.org]

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



--- Comment #3 from Hans-Peter Nilsson  2012-11-14 
16:59:29 UTC ---

(In reply to comment #1)

> I also see failing g++.dg/parse/template23.C and for this one too the problem

> seems related to the recent changes for PR54413.



Right, thanks, I was just about to analyze that one.  Speaking of that commit,

some of the new tests fail for me:

FAIL: g++.dg/cpp0x/gnu_fext-numeric-literals.C (test for excess errors)

FAIL: g++.dg/cpp0x/std_fext-numeric-literals.C (test for excess errors)



and in g++.log:

Excess errors:

/tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/cpp0x/gnu_fext-numeric-literals.C:94:3:

error: unsupported non-standard suffix on floating constant

/tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/cpp0x/gnu_fext-numeric-literals.C:95:3:

error: unsupported non-standard suffix on floating constant

/tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/cpp0x/gnu_fext-numeric-literals.C:96:3:

error: unsupported non-standard suffix on floating constant

/tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/cpp0x/gnu_fext-numeric-literals.C:97:3:

error: unsupported non-standard sufffix on floating constant

maybe related, maybe material for a new PR.

[Bug c++/55318] Missing uninitialized warning

[brunonery+bugzilla at brunonery dot com]

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



--- Comment #2 from brunonery+bugzilla at brunonery dot com 2012-11-14 16:55:36 
UTC ---

Not -Winit-self alone, but together with -Wuninitialized.

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

[howarth at nitro dot med.uc.edu]

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



--- Comment #30 from Jack Howarth  2012-11-14 
16:54:06 UTC ---

(In reply to comment #29)

Thanks with the patch applied from comment 29, now the use-after-free testcase

works without errors...



howarth% ./use-after-free

=

==30656== ERROR: AddressSanitizer heap-use-after-free on address 0x000108843f45

at pc 0x105b8bf12 bp 0x7fff5a0748e0 sp 0x7fff5a0748d8

READ of size 1 at 0x000108843f45 thread T0

#0 0x105b8bf11 (/Users/howarth/./use-after-free+0x10f11)

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

#2 0x0

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

[0x000108843f40,0x000108843f90)

freed by thread T0 here:

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

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

#2 0x105b8bee5 (/Users/howarth/./use-after-free+0x10ee5)

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

#4 0x0

previously allocated by thread T0 here:

#0 0x105b9a255 (/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 0x105b8beda (/Users/howarth/./use-after-free+0x10eda)

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

Shadow byte and word:

  0x1000211087e8: fd

  0x1000211087e8: fd fd fd fd fd fd fd fd

More shadow bytes:

  0x1000211087c8: fa fa fa fa fa fa fa fa

  0x1000211087d0: fa fa fa fa fa fa fa fa

  0x1000211087d8: fa fa fa fa fa fa fa fa

  0x1000211087e0: fa fa fa fa fa fa fa fa

=>0x1000211087e8: fd fd fd fd fd fd fd fd

  0x1000211087f0: fd fd fd fd fd fd fd fd

  0x1000211087f8: fa fa fa fa fa fa fa fa

  0x100021108800: fa fa fa fa fa fa fa fa

  0x100021108808: 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

==30656== ABORTING



I'll try to test a i386-apple-darwin10 build of gcc trunk later today (unless

the multilib for libsanitizer gets fixed first and I can test -m32 on a

x86_64-apple-darwin12 build).