[Bug rtl-optimization/64616] Redundant ldr when accessing var inside and outside a loop

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64616

--- Comment #4 from Thomas Preud'homme  ---
Author: thopre01
Date: Wed May 13 05:39:14 2015
New Revision: 223113

URL: https://gcc.gnu.org/viewcvs?rev=223113&root=gcc&view=rev
Log:
2015-05-13  Thomas Preud'homme  

gcc/
PR rtl-optimization/64616
* loop-invariant.c (can_move_invariant_reg): New.
(move_invariant_reg): Call above new function to decide whether
instruction can just be moved, skipping creation of temporary
register.

gcc/testsuite/
PR rtl-optimization/64616
* gcc.dg/loop-8.c: New test.
* gcc.dg/loop-9.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/loop-8.c
trunk/gcc/testsuite/gcc.dg/loop-9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/loop-invariant.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/65873] [5/6 Regression] Failure to inline always_inline memcpy

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65873

--- Comment #8 from Jan Hubicka  ---
Author: hubicka
Date: Wed May 13 02:57:27 2015
New Revision: 223108

URL: https://gcc.gnu.org/viewcvs?rev=223108&root=gcc&view=rev
Log:

PR ipa/65873
* ipa-inline.c (can_inline_edge_p): Allow early inlining of always
inlines across optimization boundary.
* testsuite/gcc.c-torture/compile/pr65873.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr65873.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug ipa/65873] [5/6 Regression] Failure to inline always_inline memcpy

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65873

--- Comment #7 from Jan Hubicka  ---
Author: hubicka
Date: Wed May 13 02:54:50 2015
New Revision: 223107

URL: https://gcc.gnu.org/viewcvs?rev=223107&root=gcc&view=rev
Log:

PR ipa/65873
* ipa-inline.c (can_inline_edge_p): Allow early inlining of always
inlines across optimization boundary.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline.c

[Bug ipa/65873] [5/6 Regression] Failure to inline always_inline memcpy

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65873

--- Comment #6 from Jan Hubicka  ---
Patch posted https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01167.html

[Bug target/66047] [5/6 Regression] vlc compilation failure with target attribute

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66047

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org

--- Comment #2 from Jan Hubicka  ---
Mine.

[Bug fortran/66111] [6 regression] ICE with matmul and vector subscripts

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66111

--- Comment #3 from Thomas Koenig  ---
Author: tkoenig
Date: Tue May 12 21:12:55 2015
New Revision: 223099

URL: https://gcc.gnu.org/viewcvs?rev=223099&root=gcc&view=rev
Log:
2015-05-12  Thomas Koenig  

PR fortran/66111
* frontend-passes.c (has_dimen_vector_ref):  New function.
(inline_matmul_assign):  Use it to return early in case
of unhandled vector subscripts.

2015-05-12  Thomas Koenig  

PR fortran/66111
* gfortran.dg/inline_matmul_10.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/inline_matmul_10.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/66111] [6 regression] ICE with matmul and vector subscripts

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66111

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Thomas Koenig  ---
Fixed, closing.

[Bug debug/54114] VTA compile-time performance could be improved

[dsl at dsl dot pp.ua]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54114

Eliot  changed:

   What|Removed |Added

 CC||dsl at dsl dot pp.ua

--- Comment #14 from Eliot  ---
Comment on attachment 27894
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=27894
XPatch.cpp preprocessed source from xalanc

http://legup.eecg.utoronto.ca

[Bug other/55375] libsanitizer license incomplete

[dsl at dsl dot pp.ua]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55375

Eliot  changed:

   What|Removed |Added

 CC||dsl at dsl dot pp.ua

--- Comment #5 from Eliot  ---
Created attachment 35535
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35535&action=edit
http://legup.eecg.utoronto.ca

http://legup.eecg.utoronto.ca

[Bug c++/66130] "invalid use of non-static member function" message could be clearer

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66130

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||easyhack
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-12
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
Confirmed. A small testcase would help. Perhaps it would be even clearer if it
said something like: "non-static member function can be used only as the
operand for the function call operator()"

[Bug rtl-optimization/65862] [MIPS] IRA/LRA issue: integers spilled to floating-point registers

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862

--- Comment #11 from Vladimir Makarov  ---
(In reply to Robert Suchanek from comment #10)
> Hi Vlad,
> 
> I'm pleased with the results so far. In the larger codebase, it behaves as
> the original
> patch reverted and I haven't seen a missed case. 
> 
> The code size doesn't seem to be hurt either. I see ~0.5% improvement on
> average case which is good. Thanks a lot for the patch. I've thrown it
> against standard regression and it will take some time to complete but I'm
> confident it will pass. Initially it failed because of a missing declaration
> of the new_class variable though.

Thanks, Robert.

If it is ok, I will commit it into the trunk this week.  I am going to commit
it without the mips hook.  So I hope mips maintainers will add the hook by
themselves.

[Bug c++/66091] [c++-concepts] Overloading of member operators based on constraints rejected; regression from r211591

[tom at honermann dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66091

Tom Honermann  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Tom Honermann  ---
Thanks!  Confirmed fixed in r223061.

[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins

[amacleod at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697

--- Comment #57 from Andrew Macleod  ---
Author: amacleod
Date: Tue May 12 20:01:47 2015
New Revision: 223096

URL: https://gcc.gnu.org/viewcvs?rev=223096&root=gcc&view=rev
Log:
2015-05-12  Andrew MacLeod  

PR target/65697
* coretypes.h (MEMMODEL_SYNC, MEMMODEL_BASE_MASK): New macros.
(enum memmodel): Add SYNC_{ACQUIRE,RELEASE,SEQ_CST}.
* tree.h (memmodel_from_int, memmodel_base, is_mm_relaxed,
is_mm_consume,is_mm_acquire, is_mm_release, is_mm_acq_rel,
is_mm_seq_cst, is_mm_sync): New accessor functions.
* builtins.c (expand_builtin_sync_operation,
expand_builtin_compare_and_swap): Use MEMMODEL_SYNC_SEQ_CST.
(expand_builtin_sync_lock_release): Use MEMMODEL_SYNC_RELEASE.
(get_memmodel,  expand_builtin_atomic_compare_exchange,
expand_builtin_atomic_load, expand_builtin_atomic_store,
expand_builtin_atomic_clear): Use new accessor routines.
(expand_builtin_sync_synchronize): Use MEMMODEL_SYNC_SEQ_CST.
* optabs.c (expand_compare_and_swap_loop): Use MEMMODEL_SYNC_SEQ_CST.
(maybe_emit_sync_lock_test_and_set): Use new accessors and
MEMMODEL_SYNC_ACQUIRE.
(expand_sync_lock_test_and_set): Use MEMMODEL_SYNC_ACQUIRE.
(expand_mem_thread_fence, expand_mem_signal_fence, expand_atomic_load,
expand_atomic_store): Use new accessors.
* emit-rtl.c (need_atomic_barrier_p): Add additional enum cases.
* tsan.c (instrument_builtin_call): Update check for memory model
beyond
final enum to use MEMMODEL_LAST.
* c-family/c-common.c: Use new accessor for memmodel_base.
* config/aarch64/aarch64.c (aarch64_expand_compare_and_swap): Use new
accessors.
* config/aarch64/atomics.md (atomic_load,atomic_store,
arch64_load_exclusive, aarch64_store_exclusive,
mem_thread_fence, *dmb): Likewise.
* config/alpha/alpha.c (alpha_split_compare_and_swap,
alpha_split_compare_and_swap_12): Likewise.
* config/arm/arm.c (arm_expand_compare_and_swap,
arm_split_compare_and_swap, arm_split_atomic_op): Likewise.
* config/arm/sync.md (atomic_load, atomic_store,
atomic_loaddi): Likewise.
* config/i386/i386.c (ix86_destroy_cost_data, ix86_memmodel_check):
Likewise.
* config/i386/sync.md (mem_thread_fence, atomic_store): Likewise.
* config/ia64/ia64.c (ia64_expand_atomic_op): Add new memmodel cases
and
use new accessors.
* config/ia64/sync.md (mem_thread_fence, atomic_load,
atomic_store, atomic_compare_and_swap,
atomic_exchange): Use new accessors.
* config/mips/mips.c (mips_process_sync_loop): Likewise.
* config/pa/pa.md (atomic_loaddi, atomic_storedi): Likewise.
* config/rs6000/rs6000.c (rs6000_pre_atomic_barrier,
rs6000_post_atomic_barrier): Add new cases.
(rs6000_expand_atomic_compare_and_swap): Use new accessors.
* config/rs6000/sync.md (mem_thread_fence): Add new cases.
(atomic_load): Add new cases and use new accessors.
(store_quadpti): Add new cases.
* config/s390/s390.md (mem_thread_fence, atomic_store): Use new
accessors.
* config/sparc/sparc.c (sparc_emit_membar_for_model): Use new
accessors.
* doc/extend.texi: Update docs to indicate 16 bits are used for memory
model, not 8.



Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/c-family/c-common.c
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/config/aarch64/atomics.md
trunk/gcc/config/alpha/alpha.c
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/sync.md
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/sync.md
trunk/gcc/config/ia64/ia64.c
trunk/gcc/config/ia64/sync.md
trunk/gcc/config/mips/mips.c
trunk/gcc/config/pa/pa.md
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/sync.md
trunk/gcc/config/s390/s390.md
trunk/gcc/config/sparc/sparc.c
trunk/gcc/coretypes.h
trunk/gcc/doc/extend.texi
trunk/gcc/emit-rtl.c
trunk/gcc/optabs.c
trunk/gcc/tree.h
trunk/gcc/tsan.c

[Bug c/66090] Wrong loop code generation with -O2 on ARM

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66090

Richard Earnshaw  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 CC||rguenth at gcc dot gnu.org
 Resolution|INVALID |---

--- Comment #3 from Richard Earnshaw  ---
(In reply to Andrew Pinski from comment #2)
> Since the pointer is wrapping to null, you need to use
> -fno-delete-null-pointer-checks to disable removing of checks of null
> pointers or rather it enables allowing pointers to wrap to become null.
> In C, once a pointer is non-null, it can't become null by adding a value to
> it.  So GCC enables an optimization around that case (and
> fno-delete-null-pointer-checks disables that optimization).
> 
> So no GCC bug, just wrongly assuming pointers can't become null pointers if
> they were not null pointers.

I'm inclined to disagree.  

Firstly, the code does not check for a null pointer, it checks a loop iterator
variable.

Secondly, although the pointer value wraps to zero, that value is never
dereferenced; the last memory access is at 0xfffc.

So I think the compiler is incorrectly removing a valid termination check.

Richi, I'd like your opinion on this one.

[Bug ipa/65908] [5/6 Regression] ICE: in expand_thunk, at cgraphunit.c:1700

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65908

--- Comment #8 from Jan Hubicka  ---
I think pushing TYPE_CANONICAL is a bug: we do check ODR properties of the
parameter and TYPE_CANONICAL is not guaranteed to be the same. Just remove the
TYPE_CANONICAL wrap here.

The patch seems OK with this change both for mainline and branch. We will match
the types of DECL_ARGUMENTS when verifying the body here:

  for (arg1 = DECL_ARGUMENTS (decl),
   arg2 = DECL_ARGUMENTS (m_compared_func->decl);
   arg1; arg1 = DECL_CHAIN (arg1), arg2 = DECL_CHAIN (arg2))
if (!m_checker->compare_decl (arg1, arg2))
  return return_false ();

However I think there is one extra case to deal with. For functions that are
!prototype_p, we get empty ARG_TYPES and only have ARGUMENTS. Such functions
will bypass the checks:

  if (POINTER_TYPE_P (arg_types[i])
  && (TYPE_RESTRICT (arg_types[i]) 
  != TYPE_RESTRICT (m_compared_func->arg_types[i])))
return return_false_with_msg ("argument restrict flag mismatch");
  /* nonnull_arg_p implies non-zero range to REFERENCE types.  */
  if (POINTER_TYPE_P (arg_types[i])
  && TREE_CODE (arg_types[i])
 != TREE_CODE (m_compared_func->arg_types[i])
  && opt_for_fn (decl, flag_delete_null_pointer_checks))
return return_false_with_msg ("pointer wrt reference mismatch");

Please factor out this code to a function compatible_parm_types_p and call it
both from sem_function::equals_wpa and the loop above.

Honza

[Bug inline-asm/65897] GAS(asm) "named variable" of extended asm (type ::"m" or "g") generated in wrong code style, variable stays still in ".att_syntax" -32(%ebp) not ".intel_syntax noprefix" DWORD P

[sstsoft at wp dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65897

stanley  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #2 from stanley  ---
#include 
using namespace std;
int i asm("i");
int main() {
i = 0;
cout << "!!!Hello World!!!" << endl; // prints !!!Hello World!!!
cout << "i=" << i << endl;
asm(".intel_syntax noprefix\n mov eax,13\n mov [i],eax\n");
cout << "i=" << i << endl;

i = 0;
cout << "i=" << i << endl;
asm(".intel_syntax noprefix\n mov eax,14\n mov %[named_var],eax\n" :
[named_var] "=g" (i));
cout << "i=" << i << endl;
return 0;
}

Gives output like this:
"!!!Hello World!!!
i=0
i=13
i=0
i=14"

1. I have checked LLVM/Clang + Eclipse CDC. 
It can do this ^^ trick without a single problem(.att_syntax switched globally
but it compiles as a charm) It's only possible with Clang(compatible with GAS),
and I don't even need to end asm() block switched to correct ".att_syntax". 
With GCC compiler if I don't do this, the linker would be confused for first
line of code after my asm(".intel") block (wrong syntax of gcc "product"). As
You mentioned GCC is blind to local switches into asm block. Why? Because it's
his nature ofc :)

2. Simple "mov i,eax" wouldn't work with gcc/gas, neither "mov [i],eax", "mov
DWORD PTR[i],eax" because gcc ignores [] and it doesn't matter in the output.
This is different than written in manual - for me it's a bug. But..
since I know "i" it's address located in ds:blabla and gcc delete all of [] if
I want to access "i" I should "mov edi,i" then "mov [edi],eax" or something
like that. Again..GCC is not buggy? Huh? :)
For references or pointers it's the same so it's very confusing. GAS doesn't
recognizes "&" "*". The only way to force is named variable but as I mentioned
in previous comment - it doesn't working properly.

3. Indexes also not working[1] properly for pointers. If i pass:
char  bla[10]; //and then 
char *bla_ptr = (char*)&bla; //and then, into asm "mov bla_ptr[2],al" it
wouldn't copy al into 3rd byte of bla?! but into 3rd hihgest byte(little
indian) of bla_ptr val. After that it wouldnt be correct pointer anymore
(pointing somewhere but not there). It could be very confuseing. Rather than
everytime copy variables into some register and then [edi],eax global named
variables would be the best way.. but not working correctly in .intel_syntax  

4. The only way to do write into "i" without named variables in extended asm
inline is copy it's adress into register eq. mov edi,i; then mov [edi],somedata
When i switch -masm=intel it could be okey but... what if i want to compile
someone else code + my code in same project? But with different syntaxes?
Those guys know's how GCC works so they wrote .att_syntax or end their asm's.
Then.. linker is confused again but now with intel syntaxed gcc output rather
than .att :)

But, Andrew said - it's not a bug, it's a? Feature?
I know global variables are bad, very bad especially in multi-threaded program,
i know why ;) I know the __bulitin, i know .s "offline" assembly. I know it
would be easier to access and manipulate some local "i" by simple define it as
"int i asm("eax");" or :  "=r" (i) : "eax") and just manipulate them without
wasteing processor time(accessing memmory) and wasteing stack space for
storeing it. But hey... instead of helping GCC  compicates it :)
For ATT syntax everything(almost) works as it should but hey.. why bother
people for intel if it's not working correctly! 

END. Clang follows "local" asm() switches and gives correct .s output for it's
own compiled C code after them. It now suport for Microsoft asm{} - smart
enought to discover what registers dev use. Smart enought to move data into
memory adress not complain. Linker is not confused when i compile units from
other developers whose wrote them for GCC without -masm=intel so end's up with
.att_syntax by default. They could end up whatever they like. I could do
whatever i like - what should be as much intuitive as it could in SSE,AVX era
when good C code is not enought. 

In GCC this is very serious problem, gcc stuck in 70's .ATT era
If gas have "no way" it shouldn't support for "g" "m" type variables then! Or
someone should make them see each other. Lack of GAS - GCC communication
whatever... this is not in my worries list, but on gcc commiters. Maybe someone
should open way for it!? 
huh? Andrew?

[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66066

--- Comment #15 from Marek Polacek  ---
Created attachment 35534
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35534&action=edit
gcc6-pr66066

Untested patch without a test

[Bug c++/66130] New: "invalid use of non-static member function" message could be clearer

[tromey at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66130

Bug ID: 66130
   Summary: "invalid use of non-static member function" message
could be clearer
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

Today g++ gave me "invalid use of non-static member function".
However, from the context it was unclear exactly which thing
on the line was the invalid use.  (Mostly due to bug 61940 giving
an imprecise location).

I think this warning would be more useful if it mentioned the name
of the member function in question.  In my case this would have
made the problem immediately clear.

[Bug tree-optimization/66129] New: [6 Regression] FAIL: gcc.dg/vect/vect-strided-*c execution test

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66129

Bug ID: 66129
   Summary: [6 Regression] FAIL: gcc.dg/vect/vect-strided-*c
execution test
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: rguenther at suse dot de
  Target Milestone: ---

On x86, r223059 caused:

FAIL: gcc.dg/vect/vect-strided-a-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-a-mult.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-strided-a-u16-i2.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u16-i2.c -flto -ffat-lto-objects execution
test
FAIL: gcc.dg/vect/vect-strided-a-u16-i4.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u16-i4.c -flto -ffat-lto-objects execution
test
FAIL: gcc.dg/vect/vect-strided-a-u16-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u16-mult.c -flto -ffat-lto-objects execution
test
FAIL: gcc.dg/vect/vect-strided-a-u32-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u32-mult.c -flto -ffat-lto-objects execution
test
FAIL: gcc.dg/vect/vect-strided-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-mult.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-strided-mult-char-ls.c execution test
FAIL: gcc.dg/vect/vect-strided-mult-char-ls.c -flto -ffat-lto-objects execution
test
FAIL: gcc.dg/vect/vect-strided-u16-i2.c execution test
FAIL: gcc.dg/vect/vect-strided-u16-i2.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-strided-u16-i4.c execution test
FAIL: gcc.dg/vect/vect-strided-u16-i4.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-strided-u32-i4.c execution test
FAIL: gcc.dg/vect/vect-strided-u32-i4.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-strided-u32-i8.c execution test
FAIL: gcc.dg/vect/vect-strided-u32-i8.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-strided-u32-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-u32-mult.c -flto -ffat-lto-objects execution
test
FAIL: gcc.dg/vect/vect-strided-u8-i2.c execution test
FAIL: gcc.dg/vect/vect-strided-u8-i2.c -flto -ffat-lto-objects execution test

with

make check-gcc RUNTESTFLAGS="vect.exp=vect-strided*.c
--target_board='unix{-march=corei7}'"

[Bug middle-end/66127] Division by zero gets folded away

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66127

--- Comment #3 from Marek Polacek  ---
I suppose this particular issue might be even relevant to e.g.
-mcheck-zero-division on MIPS, i.e. everywhere where we're expect to trap on
integer division by zero.

(ubsan's -fsanitize=integer-divide-by-zero isn't affected by this, because we
add the instrumentation very early, before the division is lost.  Otherwise
we'd miss a diagnostic.)

[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66066

--- Comment #14 from Manuel López-Ibáñez  ---
(In reply to Marek Polacek from comment #13)
> I expect to have a proper fix (additional folding in c_fully_fold_internal)
> today or tomorrow, depends on how many issues I hit along the way (see e.g.
> PR66127).  The tzdata issue seems to be being worked on, so I think the
> "pedantic" stopgap isn't needed right now.

OK, great. That seems a step in the right direction. Thanks for fixing this!

[Bug fortran/66128] ICE for some intrinsics with zero sized array parameter

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66128

--- Comment #1 from Gerhard Steinmetz  
---
Some more examples with other error messages.

This one ...
   program p
  integer, parameter :: z(0) = 0
  print *, count(z > 0)
   end

yields :
internal compiler error: in gfc_conv_intrinsic_count, at
fortran/trans-intrinsic.c:3233

This one ...
   program p
  integer, parameter :: z(0) = 0
  print *, iall(z, z > 0)
  print *, iany(z, z > 0)
  print *, iparity(z, z > 0)
  print *, parity(z > 0)
  print *, product(z, z > 0)
  print *, sum(z, z > 0)
   end

yields :
internal compiler error: in gfc_conv_intrinsic_arith, at
fortran/trans-intrinsic.c:3357

This one ...
   program p
  integer, parameter :: z(0) = 0
  print *, minval(z, z > 0)
  print *, maxval(z, z > 0)
   end

yields :
internal compiler error: in gfc_conv_intrinsic_minmaxval, at
fortran/trans-intrinsic.c:4253

[Bug fortran/66128] New: ICE for some intrinsics with zero sized array parameter

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66128

Bug ID: 66128
   Summary: ICE for some intrinsics with zero sized array
parameter
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

This simplified code snippet with a zero sized array parameter z ...
   program p
  integer, parameter :: z(0) = 0
  print *, any(z > 0)
  print *, all(z > 0)
   end

or this variation ...
   program p
  integer, parameter :: z(1:0) = 0
  print *, any(z > 0)
  print *, all(z > 0)
   end

prints (with gfortran 5.1.1 on SUSE Linux 13.2, 64 bit)
internal compiler error: in gfc_conv_intrinsic_anyall, at
fortran/trans-intrinsic.c:3149

Whereas, without declaring z as a parameter it works, e.g.
   program p
  integer :: z(0) = 0
  print *, any(z > 0)
  print *, all(z > 0)
   end

Kind regards.

[Bug c++/61940] Wrong error location for error in initialization list

[tromey at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61940

Tom Tromey  changed:

   What|Removed |Added

 CC||jan.kratochvil at redhat dot 
com

--- Comment #4 from Tom Tromey  ---
*** Bug 59621 has been marked as a duplicate of this bug. ***

[Bug c++/59621] wrong caret / lineno for wrong ctor field initializer

[tromey at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59621

Tom Tromey  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||tromey at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Tom Tromey  ---
Dup; preferring the other bug since it is assigned.

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

[Bug c++/61940] Wrong error location for error in initialization list

[tromey at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61940

Tom Tromey  changed:

   What|Removed |Added

 CC||akim.demaille at gmail dot com

--- Comment #3 from Tom Tromey  ---
*** Bug 53553 has been marked as a duplicate of this bug. ***

[Bug c++/53553] misleading locations for error in initializers

[tromey at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53553

Tom Tromey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||tromey at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Tom Tromey  ---
Dup; preferring the other bug since it is assigned.

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

[Bug middle-end/66127] Division by zero gets folded away

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66127

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to jos...@codesourcery.com from comment #1)
> Ideally the front-end folding of expressions-of-constants might avoid 
> folding-for-optimization such as this (instead just folding cases where 
> the evaluated operands are actually constants, so not folding anything 
> where 1 / 0 is an evaluated operand).

I understand that Marek is saying that currently: "1 / 0" is not folded, but "0
* (1 / 0)" is folded into 0.

The answer is that we really need to separate the FE folding from the ME one,
and do only FE folding for language conformance purposes, while we can do ME
folding for warnings and when the FE is finished.  Isn't this what you explain
in text quoted at A.5 at https://gcc.gnu.org/wiki/Better_Diagnostics?

This will also liberate the ME to do optimizations that before could not do
because we wanted to reject invalid programs with -pedantic-errors.

I seem to remember there has been further discussion about this after or while
match.pd was implemented, discussing whether it was worth it that the FE saves
the GIMPLE generated when doing FE folding (or ME folding in case of FE
warnings requesting it), but I cannot find a link now.

[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66066

--- Comment #13 from Marek Polacek  ---
I expect to have a proper fix (additional folding in c_fully_fold_internal)
today or tomorrow, depends on how many issues I hit along the way (see e.g.
PR66127).  The tzdata issue seems to be being worked on, so I think the
"pedantic" stopgap isn't needed right now.

[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66066

--- Comment #12 from joseph at codesourcery dot com  ---
On Tue, 12 May 2015, manu at gcc dot gnu.org wrote:

> > Working on this, but it isn't a simple matter of adding "pedantic".
> 
> Joseph, would testing global_dc->pedantic_errors be an acceptable work-around
> (with a big ??? note) while a better solution is found?

If you want a workaround, a test for "pedantic" would be the natural 
workaround, but I think the proper fix is folding as I described at 
 to allow these 
cases to reach the existing pedwarn-if-pedantic logic.

[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66066

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #11 from Manuel López-Ibáñez  ---
(In reply to Marek Polacek from comment #10)
> Working on this, but it isn't a simple matter of adding "pedantic".

Joseph, would testing global_dc->pedantic_errors be an acceptable work-around
(with a big ??? note) while a better solution is found?

[Bug middle-end/66127] Division by zero gets folded away

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66127

--- Comment #1 from joseph at codesourcery dot com  ---
Ideally the front-end folding of expressions-of-constants might avoid 
folding-for-optimization such as this (instead just folding cases where 
the evaluated operands are actually constants, so not folding anything 
where 1 / 0 is an evaluated operand).

[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66066

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-05-12
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #10 from Marek Polacek  ---
Working on this, but it isn't a simple matter of adding "pedantic".

[Bug middle-end/66127] New: Division by zero gets folded away

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66127

Bug ID: 66127
   Summary: Division by zero gets folded away
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

In match.pd, we have

(simplify
 (mult @0 integer_zerop@1)
 @1)

so anything * 0 -> 0.  That seems to be undesirable in case "anything" contains
a division by zero.  And a few lines below we have

/* Make sure to preserve divisions by zero.  This is the reason why
   we don't simplify x / x to 1 or 0 / x to 0.  */
(for op (mult trunc_div ceil_div floor_div round_div exact_div)
  (simplify
(op @0 integer_onep)
(non_lvalue @0)))

This means that
int
main (void)
{
  int z = 0;
  int a = 0 * (1 / z);
  return a;
}
$ xgcc f.c; ./a.out
is "ok", but e.g.
int
main (void)
{
  int z = 0;
  int a = 1 * (1 / z);
  return a;
}
naturally results in SIGFPE.

Yes, I know that division by zero is UB and there are no guarantees whatsoever,
but this folding is causing me a grief in the C FE because while fold doesn't
fold away "1 / 0", it folds "0 * (1 / 0)" into 0.  That's bad when we find
ourselves in a situation where a constant integer expression is required.

[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant

[vp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66066

--- Comment #9 from Vidya Praveen  ---
glibc's tz code (which causes this error) will get fixed  eventually:
https://sourceware.org/bugzilla/show_bug.cgi?id=18396

However if it's justifiable, it's good to move this error under -pedantic.

[Bug target/66126] 2-float SSE vector with vector_size(8) is passed incorrectly to functions on x86

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66126

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #1)
> i?86 passes it in %mm0 (oops) (with -msse2), even if the function is
> externally visible.
> 
> I think -msse shouldn't change the ABI.

8-byte vectors are passed to functions in mmx registers. This is part of 32bit
ABI. The 64bit ABI is different, 8-byte vectors are passed in sse registers.

The problem is that when mmx register is referenced, shared x87/mmx register
stack switches into mmx mode until emms is executed. When in mmx mode, all x87
registers show nan.

This is not a gcc bug.

[Bug rtl-optimization/56766] Fails to combine (vec_select (vec_concat ...)) to (vec_merge ...)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56766

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-12
 CC||uros at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
The vectorizer patch is now in (I added a testcase for addsubps because for
that
it happens to work).

We still need to fixup the sse3_addsubv2df3 pattern or fix combine to try
multiple "canonical" forms of vec_merge vs. (vec_select (vec_concat ...)).
Or decide which one is canonical (I'd prefer simply dropping vec_merge - with
AVX512 we've run out of bits for the CONST_INT selector)

One issue with the vec_select form is that it requires an intermediate mode of
double-size while vec_merge avoids this.

Eventually one can also teach combine that certain (vec_select (vec_concat ..))
can be treated as (vec_merge ...).

void testd (double * __restrict__ p, double * __restrict q)
{
  p[0] = p[0] - q[0];
  p[1] = p[1] + q[1];
}

should vectorize to addsubpd with -msse3.

[Bug fortran/66089] [6 Regression] elemental dependency mishandling when derived types are involved

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089

--- Comment #4 from Mikael Morin  ---
(In reply to Dominique d'Humieres from comment #3)
> The code in comment 0 does not abort at run time up to revision r222352
> (2015-04-23), but does so at r222398 (2015-04-24), likely r222361.

Yes, probably the change in gfc_add_loop_ss_code (which comment #1 removes).

[Bug ipa/65908] [5/6 Regression] ICE: in expand_thunk, at cgraphunit.c:1700

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65908

--- Comment #7 from Martin Liška  ---
Created attachment 35533
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35533&action=edit
Suggested fix

I've been testing following patch for 5.1.0 branch. I'm wondering if comparison
of just TYPE_ARG_TYPES is sufficient?

[Bug c++/66124] greg_month.cpp from boost date_time shows internal compiler error: Segmentation fault

[wilkinson.bob at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66124

--- Comment #1 from wilkinson.bob at gmail dot com ---
More succinctly my failing compilation can be reduced to :

g++ -v -save-temps -Wall -Wextra -c
-I/home/bob/work/trunk/3rdparty/boost_1_49_0
3rdparty/boost_1_49_0/libs/date_time/src/gregorian/greg_month.cpp

which exhibits the same failure.

[Bug target/66126] 2-float SSE vector with vector_size(8) is passed incorrectly to functions on x86

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66126

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-12
  Component|c   |target
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
i?86 passes it in %mm0 (oops) (with -msse2), even if the function is externally
visible.

I think -msse shouldn't change the ABI.

[Bug c/66126] New: 2-float SSE vector with vector_size(8) is passed incorrectly to functions on x86

[tanel.kriik at outlook dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66126

Bug ID: 66126
   Summary: 2-float SSE vector with vector_size(8) is passed
incorrectly to functions on x86
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tanel.kriik at outlook dot com
  Target Milestone: ---

Created attachment 35532
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35532&action=edit
Preprocessed source code of the original program

GCC version: 4.8.4
System type: i386-unknown-openbsd5.7
Configured with: /usr/obj/ports/gcc-4.8.4/gcc-4.8.4/configure --enable-libgcj
--without-jar --verbose --program-transform-name='s,^,e,' --disable-nls
--with-system-zlib --disable-libmudflap --disable-libgomp --disable-tls
--with-as=/usr/bin/as --with-ld=/usr/bin/ld --with-gnu-ld --with-gnu-as
--enable-threads=posix --enable-wchar_t --with-gmp=/usr/local
--enable-languages=c,c++,fortran,objc,java,ada --disable-libstdcxx-pch
--enable-cpp --enable-shared --prefix=/usr/local --sysconfdir=/etc
--mandir=/usr/local/man --infodir=/usr/local/info --localstatedir=/var
--disable-silent-rules --disable-gtk-doc

Defining a 2D float vector with vector_size(8) produces a type that doesn't
seem to be passed correctly to functions.


#include 

typedef float vec2f __attribute__ ((vector_size(8)));

static void vec2f_print(vec2f v)
{
printf("%f %f\n", v[0], v[1]);
}

int main(void)
{
vec2f v = {1, 3};
vec2f_print(v);
printf("%f %f\n", v[0], v[1]);

return 0;
}


Compiling the code above with 'gcc -msse' and running it produces the following
output:

-nan -nan
1.00 3.00

The first line should be same as the second line because the vector is just
passed to a function that prints the first and second float in the vector while
the second output line is the result of printing the 2 floats directly without
a function call. If I apply optimization when compiling, the result is correct,
probably due to eliminating the simple function call.

I get similar behaviour on my 64-bit Ubuntu machine when the same program is
compiled in 32-bit mode (-m32).

This bug doesn't appear on x86-64, otherwise.

[Bug lto/66125] lto1: code model kernel does not support PIC mode

[dimhen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66125

Dmitry G. Dyachenko  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Dmitry G. Dyachenko  ---
(In reply to Richard Biener from comment #1)
> Testcase?  The fix makes options from archive members visible to lto-wrapper,
> so you likely have a mismatch between -fPIC / -fno-PIC somehwere.

Yes, you are right : I have mismatch between -fPIC / -fno-PIC.

[Bug lto/66125] lto1: code model kernel does not support PIC mode

[dimhen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66125

--- Comment #2 from Dmitry G. Dyachenko  ---
(In reply to Richard Biener from comment #1)
> Testcase?  The fix makes options from archive members visible to lto-wrapper,
> so you likely have a mismatch between -fPIC / -fno-PIC somehwere.

After reading PR65559 sounds like my FAIL

[Bug lto/66125] lto1: code model kernel does not support PIC mode

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66125

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Testcase?  The fix makes options from archive members visible to lto-wrapper,
so you likely have a mismatch between -fPIC / -fno-PIC somehwere.

[Bug target/66115] When using -O0 with -mavx the compiler uses aligned loads for possibly unaligned function parameters

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66115

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #10 from Jakub Jelinek  ---
(In reply to carloscastro10 from comment #9)
> __alignof__(__m128i) is 16, just like __alignof__(long) is 8 and
> __alignof__(int) is 4. However, if I have a pointer to long or a pointer to
> int, the memory addresses pointed at by those pointers can be aligned to any
> byte boundary.

That is not the case, please read the C or C++ standards.

> Assuming that the address pointed at by a pointer to __m128i
> is aligned to a 16-byte boundary is not a correct assumption, especially
> when compiling with -mavx. It prevents proper modeling in debug mode of
> access to unaligned operands in memory. This problem is also present with
> the __m256i type. In AVX, aligned memory load operations (_mm256_load_si256
> and similar) are the exceptions in that they require pointers to aligned
> memory addresses. Most AVX operations accept unaligned addresses.

One thing is how the HW instructions look like, another is the language you're
writing this in (C/C++), that isn't necessarily the same thing.
As I said, you really shouldn't add *(__m128i*) or similar (other __m128*,
__m256*, custom vector_size attribute defined types, etc.) dereferences if the
pointer isn't suitably aligned.  Use the unaligned loads and the compiler for
-mavx will when optimizing combine them where possible with the actual vector
arithmetics etc. instructions.

[Bug target/66120] __builtin_add/sub_overflow for int32_t emit poor code on ARM

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66120

--- Comment #4 from Richard Earnshaw  ---
Mul doesn't produce useful overflow bits when the flags are set.  We could do
negv3.

[Bug tree-optimization/66101] [5 Regression] internal compiler error: in verify_loop_structure, at cfgloop.c:1662

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66101

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.0
Summary|[5/6 Regression] internal   |[5 Regression] internal
   |compiler error: in  |compiler error: in
   |verify_loop_structure, at   |verify_loop_structure, at
   |cfgloop.c:1662  |cfgloop.c:1662
  Known to fail||5.1.0

--- Comment #4 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/66101] [5 Regression] internal compiler error: in verify_loop_structure, at cfgloop.c:1662

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66101

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue May 12 13:28:33 2015
New Revision: 223065

URL: https://gcc.gnu.org/viewcvs?rev=223065&root=gcc&view=rev
Log:
2015-05-12  Richard Biener  

PR tree-optimization/66101
* tree-ssa-dce.c (remove_dead_stmt): Properly mark loops for
fixup if we turn a loop exit edge to a fallthru edge.

* gcc.dg/torture/pr66101.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr66101.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dce.c

[Bug c++/66096] Unexpected __gnu_cxx::__concurrence_lock_error with _GLIBCXX_DEBUG

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66096

Jonathan Wakely  changed:

   What|Removed |Added

 Target|32 bit  |x86_64-w64-mingw32
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-05-12
   Host|Windows 7 x64   |x86_64-w64-mingw32
 Ever confirmed|0   |1
  Build|g++.EXE (tdm-1) 4.9.2   |
   |Copyright (C) 2014 Free |
   |Software Foundation, Inc.   |

--- Comment #3 from Jonathan Wakely  ---
This report is not very useful without a stack trace showing where the
exception is thrown. I suspect it's a mingw-w64 problem as it doesn't happen on
other targets, so there may be nothing to fix in the upstream libstdc++ code.

As requested at https://gcc.gnu.org/bugs/ please provide the output of 'gcc -v'
not just the version number.

[Bug target/66120] __builtin_add/sub_overflow for int32_t emit poor code on ARM

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66120

--- Comment #3 from Richard Earnshaw  ---
That's what I meant.  Still can't find any info on them in md.texi, though!

[Bug c/66122] Bad uninlining decisions

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122

--- Comment #5 from Markus Trippelsdorf  ---
The last time I looked at the kernel build with -Os, all cases
were simply caused by:

ipa-inline.c:
 820   /* If call is cold, do not inline when function body would grow. */  
 821   else if (!e->maybe_hot_p ()  
 822&& (growth >= MAX_INLINE_INSNS_SINGLE   
 823|| growth_likely_positive (callee, growth)))
 824 {  
 825   e->inline_failed = CIF_UNLIKELY_CALL;
 826   want_inline = false; 
 827 }  
 828 }

[Bug lto/66125] New: lto1: code model kernel does not support PIC mode

[dimhen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66125

Bug ID: 66125
   Summary: lto1: code model kernel does not support PIC mode
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
  Target Milestone: ---

r222758 PASS
r222759 FAIL

Alas, I had no compact testcase.

But 'argv[i] --> filename' change is not clear for me.
At least, it"s not mentioned in ChangeLog :)

$ svn diff -c222759 gcc/lto-wrapper.c
Index: gcc/lto-wrapper.c
===
--- gcc/lto-wrapper.c   (revision 222758)
+++ gcc/lto-wrapper.c   (revision 222759)
@@ -934,7 +934,7 @@
  filename[p - argv[i]] = '\0';
  file_offset = (off_t) loffset;
}
-  fd = open (argv[i], O_RDONLY);
+  fd = open (filename, O_RDONLY | O_BINARY);
   if (fd == -1)
{
  lto_argv[lto_argc++] = argv[i];

[Bug target/66115] When using -O0 with -mavx the compiler uses aligned loads for possibly unaligned function parameters

[carloscastro10 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66115

carloscastro10 at hotmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #9 from carloscastro10 at hotmail dot com ---
__alignof__(__m128i) is 16, just like __alignof__(long) is 8 and
__alignof__(int) is 4. However, if I have a pointer to long or a pointer to
int, the memory addresses pointed at by those pointers can be aligned to any
byte boundary. Assuming that the address pointed at by a pointer to __m128i is
aligned to a 16-byte boundary is not a correct assumption, especially when
compiling with -mavx. It prevents proper modeling in debug mode of access to
unaligned operands in memory. This problem is also present with the __m256i
type. In AVX, aligned memory load operations (_mm256_load_si256 and similar)
are the exceptions in that they require pointers to aligned memory addresses.
Most AVX operations accept unaligned addresses.

[Bug c/66122] Bad uninlining decisions

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
gcc 4.7 is not supported anymore, so there is no point reporting issues against
it.
As for #c3, that got fixed (well, improved, inline unlike always_inline
attribute is just an optimization hint) by r219108, which is certainly not
backportable to 4.9 branch.

[Bug c++/66124] New: greg_month.cpp from boost date_time shows internal compiler error: Segmentation fault

[wilkinson.bob at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66124

Bug ID: 66124
   Summary: greg_month.cpp from boost date_time shows internal
compiler error: Segmentation fault
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilkinson.bob at gmail dot com
  Target Milestone: ---

Created attachment 35531
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35531&action=edit
gzipped version of grep_month.ii

I use the most recently packaged version of gcc for AIX 5.3 packaged by IBM and
available from
ftp://public.dhe.ibm.com/aix/freeSoftware/aixtoolbox/RPMS/ppc/gcc/

The version I used is :

bash-4.2# csum *.rpm
0a0ad6f0228d2ebba18d6632f946f15f  gcc-4.2.0-3.aix5.3.ppc.rpm
01757ef0a46f062a9a5dcf487b809a3e  gcc-cplusplus-4.2.0-3.aix5.3.ppc.rpm
69a0cdd26b841db4401cc96a238c31bf  gcc-locale-4.2.0-3.aix5.3.ppc.rpm
1e6665b79e21e87a2664a510c04dbf48  libffi-4.2.0-3.aix5.3.ppc.rpm
9579df6d8c21fa74827604c6be336685  libffi-devel-4.2.0-3.aix5.3.ppc.rpm
1f23e47835f96d9a48074c7e29e2f625  libgcc-4.2.0-3.aix5.3.ppc.rpm
ba0044da1a5a45fde81ea80fa9bbd984  libgomp-4.2.0-3.aix5.3.ppc.rpm
59a82bf0df8087b549a3c1a66501ada6  libstdcplusplus-4.2.0-3.aix5.3.ppc.rpm
4e390df393af6fde78d2f36017d0de07  libstdcplusplus-devel-4.2.0-3.aix5.3.ppc.rpm
bash-4.2# oslevel -s
5300-12-04-1119
bash-4.2# 

I try to compile my (large) software project but see 

internal compiler error: Segmentation fault while compiling greg_month.cpp from
boost date_time.

Details suggested on https://gcc.gnu.org/bugs/ follow and the file
greg_month.ii is attached (though I had to compress it with gzip so that it was
under the file size limit).

bash-4.2# cat gmbuild 
g++ -v -save-temps -Wall -Wextra -c -mminimal-toc -maix32 -fPIC -O0 -g1
-fvisibility=default -fPIC -I/home/bob/work/trunk/3rdparty/boost_1_49_0 -shared
-I /home/bob/work/trunk/common/basic/cppunit/include -D_REENTRANT=1
-DBOOST_DATE_TIME_DYN_LINK=1 -DBOOST_TEST_DYN_LINK=1 -Daix=1 -Dbigendian=1
-Dunix=1
-I3rdparty/boost_1_49_0/libs/date_time/wspace/powerpc-ibm-aix5.3.0.0/release32/include
-I3rdparty/boost_1_49_0/libs/date_time/include
-I3rdparty/boost_1_49_0/libs/date_time/wspace/powerpc-ibm-aix5.3.0.0/release32/res
-I3rdparty/boost_1_49_0/libs/date_time/res -Icommon/include -Icommon/basic
-Iunix/common/include
3rdparty/boost_1_49_0/libs/date_time/src/gregorian/greg_month.cpp

bash-4.2# bash gmbuild
Using built-in specs.
Target: powerpc-ibm-aix5.3.0.0
Configured with: ../configure --with-as=/usr/bin/as --with-ld=/usr/bin/ld
--enable-languages=c,c++,java --prefix=/opt/freeware --enable-threads
--enable-version-specific-runtime-libs --host=powerpc-ibm-aix5.3.0.0
--target=powerpc-ibm-aix5.3.0.0 --build=powerpc-ibm-aix5.3.0.0
--disable-libjava-multilib
Thread model: aix
gcc version 4.2.0
 /opt/freeware/libexec/gcc/powerpc-ibm-aix5.3.0.0/4.2.0/cc1plus -E -quiet -v
-I/home/bob/work/trunk/3rdparty/boost_1_49_0 -I
/home/bob/work/trunk/common/basic/cppunit/include
-I3rdparty/boost_1_49_0/libs/date_time/wspace/powerpc-ibm-aix5.3.0.0/release32/include
-I3rdparty/boost_1_49_0/libs/date_time/include
-I3rdparty/boost_1_49_0/libs/date_time/wspace/powerpc-ibm-aix5.3.0.0/release32/res
-I3rdparty/boost_1_49_0/libs/date_time/res -Icommon/include -Icommon/basic
-Iunix/common/include -D_ALL_SOURCE -D_REENTRANT=1 -DBOOST_DATE_TIME_DYN_LINK=1
-DBOOST_TEST_DYN_LINK=1 -Daix=1 -Dbigendian=1 -Dunix=1
3rdparty/boost_1_49_0/libs/date_time/src/gregorian/greg_month.cpp -mminimal-toc
-maix32 -Wall -Wextra -fvisibility=default -fPIC -fworking-directory -O0
-fpch-preprocess -o greg_month.ii
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.0/../../../../powerpc-ibm-aix5.3.0.0/include"
ignoring nonexistent directory
"3rdparty/boost_1_49_0/libs/date_time/wspace/powerpc-ibm-aix5.3.0.0/release32/include"
ignoring nonexistent directory "3rdparty/boost_1_49_0/libs/date_time/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/bob/work/trunk/3rdparty/boost_1_49_0
 /home/bob/work/trunk/common/basic/cppunit/include

3rdparty/boost_1_49_0/libs/date_time/wspace/powerpc-ibm-aix5.3.0.0/release32/res
 3rdparty/boost_1_49_0/libs/date_time/res
 common/include
 common/basic
 unix/common/include
 /opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.0/include/c++

/opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.0/include/c++/powerpc-ibm-aix5.3.0.0
 /opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.0/include/c++/backward
 /opt/freeware/include
 /opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.0/include
 /usr/include
End of search list.
 /opt/freeware/libexec/gcc/powerpc-ibm-aix5.3.0.0/4.2.0/cc1plus -fpreprocessed
greg_month.ii -quiet -dumpbase greg_month.cpp -mminimal-toc -maix32 -auxbase
greg_month -g1 -O0 -Wall -Wextra -version -fvisibility=de

[Bug middle-end/66110] uint8_t memory access not optimized

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #5 from Richard Biener  ---
Bootstrapped / tested on x86_64 with --disable-werror

Running target unix/
FAIL: gcc.dg/alias-2.c  (test for warnings, line 14)
FAIL: gcc.dg/alias-2.c (test for excess errors)

Running target unix//-m32
FAIL: gcc.dg/alias-2.c  (test for warnings, line 14)
FAIL: gcc.dg/alias-2.c (test for excess errors)

[Bug ipa/65740] spectacularly bad inlinining decisions with -Os

[vda.linux at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65740

Denis Vlasenko  changed:

   What|Removed |Added

 CC||vda.linux at googlemail dot com

--- Comment #3 from Denis Vlasenko  ---
Bug 66122 contains more information, and a recipe how to find many examples
using linux kernel build.

For one, this is not limited to -Os (it does happen with -Os way more easily).

[Bug target/66081] Invalid ARM ldrb instruction offset

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66081

Richard Earnshaw  changed:

   What|Removed |Added

 Target||arm
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Richard Earnshaw  ---
There's nothing invalid about that instruction.  The Thumb-2 ISA has a 4-byte
LDRB opcode that supports larger offsets.

[Bug c/66122] Bad uninlining decisions

[vda.linux at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122

--- Comment #3 from Denis Vlasenko  ---
Created attachment 35530
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35530&action=edit
Preprocessed example exhibiting a bug on gcc -4.9.2

This is a preprocessed kernel/pid.c file from kernel source.
When built with -O2, it wrongly deinlines hweight_long.

$ gcc -O2 -c pid.preprocessed.c -o kernel.pid.o
$ objdump -dr kernel.pid.o | grep -A3 hweight_long
 :
   0:   e8 00 00 00 00  callq  5 
1: R_X86_64_PC32__sw_hweight64-0x4
   5:   c3  retq
$ gcc -v 2>&1 | tail -1
gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC)

[Bug target/66120] __builtin_add/sub_overflow for int32_t emit poor code on ARM

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66120

--- Comment #2 from Jakub Jelinek  ---
Not those, but addv4 and subv4 instead (perhaps {,u}mulv4 if
the ISA detects multiplication overflows, also there is negv3).

[Bug fortran/66102] dependency mishandling with reallocation on assignment

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66102

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-12
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
The code segfault at run time when compiled with 4.5 to 4.7 and aborts with 4.8
and above.

[Bug c/66000] Suggestion: more than one "not declared in this scope" per line

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66000

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #1 from Eric Gallager  ---
(In reply to Michael Darling from comment #0)
> With the code
>nonExistantClass varName = nonExistantFunction();
> 
> gcc 5.1.0 gives
>error: `nonExistantClass' was not declared in this scope
>   nonExistantClass varName = nonExistantFunction();
>   ^
> 
> It might be better if it ALSO gave:
>error: `nonExistantFunction' was not declared in this scope
>   nonExistantClass varName = nonExistantFunction();
>  ^

idk, this might lengthen the error output considerably for files with a lot of
undeclared identifiers in them...

[Bug target/66120] __builtin_add/sub_overflow for int32_t emit poor code on ARM

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66120

Richard Earnshaw  changed:

   What|Removed |Added

 Target|arm*-*gnueabi   |arm
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-12
 Ever confirmed|0   |1

--- Comment #1 from Richard Earnshaw  ---
Confirmed.  Looks like the ARM port needs to implement the addv3 and
subv3 patterns; although those do not appear to be documented in the
internals manual.

[Bug c/66122] Bad uninlining decisions

[vda.linux at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122

--- Comment #2 from Denis Vlasenko  ---
Tested with gcc-4.9.2. The attached testcase doesn't exhibit the bug, but
compiling the same kernel tree, with the same .config, and then running

nm --size-sort vmlinux | grep -iF ' t ' | uniq -c | grep -v '^ *1 ' | sort -rn

reveals that now other functions get wrongly deinlined:

  8 0028 t acpi_os_allocate_zeroed
  7 0011 t dst_output_sk
  7 000b t hweight_long
  5 0023 t umask_show
  5 000f t init_once
  4 0047 t uni2char
  4 0028 t cmask_show
  4 0025 t inv_show
  4 0025 t edge_show
  4 0020 t char2uni
  4 001f t event_show
  4 001d t acpi_node
  4 0012 t t_stop
  4 0012 t dst_discard
  4 0011 t kzalloc
  4 000b t udp_lib_close
  4 0006 t udp_lib_hash
  3 0059 t get_expiry
  3 0025 t __uncore_inv_show
  3 0025 t __uncore_edge_show
  3 0023 t __uncore_umask_show
  3 0023 t name_show
  3 0022 t acpi_os_allocate
  3 001f t __uncore_event_show
  3 000d t cpumask_set_cpu
  3 000a t nofill
...
...

For example, hweight_long:

static inline unsigned long hweight_long(unsigned long w)
{
return sizeof(w) == 4 ? hweight32(w) : hweight64(w);
}

wasn't expected by programmer to be deinlined. But it was:

81009c40 :
81009c40:   55  push   %rbp
81009c41:   e8 da eb 31 00  callq  81328820
<__sw_hweight64>
81009c46:   48 89 e5mov%rsp,%rbp
81009c49:   5d  pop%rbp
81009c4a:   c3  retq   
81009c4b:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)

I'm going to find and attach a file which deinlines hweight_long.

[Bug tree-optimization/66123] Array of labels as values + ternary operator + pointer arithmetic = internal compiler error

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66123

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

[Bug tree-optimization/66123] Array of labels as values + ternary operator + pointer arithmetic = internal compiler error

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66123

--- Comment #4 from Richard Biener  ---
Or rather

Index: tree-ssa-dom.c
===
--- tree-ssa-dom.c  (revision 223044)
+++ tree-ssa-dom.c  (working copy)
@@ -2918,6 +2918,8 @@ propagate_rhs_into_lhs (gimple stmt, tre
{
  basic_block bb = gimple_bb (use_stmt);
  edge te = find_taken_edge (bb, val);
+ if (te)
+   {
  edge_iterator ei;
  edge e;
  gimple_stmt_iterator gsi;
@@ -2961,6 +2963,7 @@ propagate_rhs_into_lhs (gimple stmt, tre
  te->flags |= EDGE_FALLTHRU;
  if (te->probability > REG_BR_PROB_BASE)
te->probability = REG_BR_PROB_BASE;
+   }
}
}
}

if computed goto removal should work.

[Bug tree-optimization/66123] Array of labels as values + ternary operator + pointer arithmetic = internal compiler error

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66123

--- Comment #3 from Richard Biener  ---
Index: tree-ssa-dom.c
===
--- tree-ssa-dom.c  (revision 223044)
+++ tree-ssa-dom.c  (working copy)
@@ -2914,7 +2914,7 @@ propagate_rhs_into_lhs (gimple stmt, tre
  else
val = gimple_goto_dest  (use_stmt);

- if (val && is_gimple_min_invariant (val))
+ if (val && TREE_CODE (val) == INTEGER_CST)
{
  basic_block bb = gimple_bb (use_stmt);
  edge te = find_taken_edge (bb, val);

[Bug fortran/66089] [6 Regression] elemental dependency mishandling when derived types are involved

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-12
 CC||vehre at gcc dot gnu.org
Summary|elemental dependency|[6 Regression] elemental
   |mishandling when derived|dependency mishandling when
   |types are involved  |derived types are involved
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
The code in comment 0 does not abort at run time up to revision r222352
(2015-04-23), but does so at r222398 (2015-04-24), likely r222361.

[Bug tree-optimization/66123] Array of labels as values + ternary operator + pointer arithmetic = internal compiler error

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66123

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-12
 CC||mpolacek at gcc dot gnu.org
  Component|c   |tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed, ICEs since gcc 4.6.

int
test (int foo)
{
  static void *dummy[] = { &&a, &&b };
  goto *((char *) &&b - 2 * (foo < 0));
a:
b:
  return 0;
}

[Bug tree-optimization/66123] Array of labels as values + ternary operator + pointer arithmetic = internal compiler error

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66123

--- Comment #2 from Marek Polacek  ---
$ ./cc1 -quiet x.c -O
x.c: In function ‘test’:
x.c:2:1: internal compiler error: Segmentation fault
 test (int foo)
 ^
0xd7129c crash_signal
/home/marek/src/gcc/gcc/toplev.c:380
0xecc3e3 propagate_rhs_into_lhs
/home/marek/src/gcc/gcc/tree-ssa-dom.c:2945
0xecc660 eliminate_const_or_copy
/home/marek/src/gcc/gcc/tree-ssa-dom.c:3017
0xecc7c4 eliminate_degenerate_phis_1
/home/marek/src/gcc/gcc/tree-ssa-dom.c:3054
0xecc817 eliminate_degenerate_phis_1
/home/marek/src/gcc/gcc/tree-ssa-dom.c:3061
0xecc817 eliminate_degenerate_phis_1
/home/marek/src/gcc/gcc/tree-ssa-dom.c:3061
0xecc921 execute
/home/marek/src/gcc/gcc/tree-ssa-dom.c:3155
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/66123] New: Array of labels as values + ternary operator + pointer arithmetic = internal compiler error

[SztfG at yandex dot ru]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66123

Bug ID: 66123
   Summary: Array of labels as values + ternary operator + pointer
arithmetic = internal compiler error
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: SztfG at yandex dot ru
  Target Milestone: ---

Created attachment 35529
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35529&action=edit
Preprocessed source

bug.c: In function ‘test’:
bug.c:1:5: internal compiler error: Segmentation fault

Target: x86_64-linux-gnu
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)

Code in attachment

It also produces internal compiler error for ARM and ARM64 target

[Bug c++/66091] [c++-concepts] Overloading of member operators based on constraints rejected; regression from r211591

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66091

--- Comment #1 from Andrew Sutton  ---

Confirmed. Fixed in r223061.

When a function declaration started with a non-function declarator, the
requires-clause wasn't being attached to the right declarator object so it
wasn't being added to the declaration.

[Bug c/66122] Bad uninlining decisions

[vda.linux at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122

--- Comment #1 from Denis Vlasenko  ---
Created attachment 35528
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35528&action=edit
Preprocessed example exhibiting a bug

This is a preprocessed kernel/locking/mutex.c file from kernel source.
When built with either -O2 or -Os, it wrongly deinlines spin_lock() and
spin_unlock():

$ gcc -O2 -c mutex.preprocessed.c -o mutex.preprocessed.o
$ objdump -dr mutex.preprocessed.o
mutex.preprocessed.o: file format elf64-x86-64
Disassembly of section .text:
 :
   0:   80 07 01addb   $0x1,(%rdi)
   3:   c3  retq
   4:   66 66 66 2e 0f 1f 84data32 data32 nopw %cs:0x0(%rax,%rax,1)
   b:   00 00 00 00 00
0010 <__mutex_init>:
...
0040 :
  40:   e9 00 00 00 00  jmpq   45 
41: R_X86_64_PC32   _raw_spin_lock-0x4
  45:   66 66 2e 0f 1f 84 00data32 nopw %cs:0x0(%rax,%rax,1)
  4c:   00 00 00 00

These functions are defined as:

static inline __attribute__((no_instrument_function)) void
spin_unlock(spinlock_t *lock)
{
 __raw_spin_unlock(&lock->rlock);
}

static inline __attribute__((no_instrument_function)) void spin_lock(spinlock_t
*lock)
{
 _raw_spin_lock(&lock->rlock);
}

and programmer's intent was that they will always be inlined.

This is with gcc-4.7.2

[Bug c/66122] New: Bad uninlining decisions

[vda.linux at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122

Bug ID: 66122
   Summary: Bad uninlining decisions
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vda.linux at googlemail dot com
  Target Milestone: ---

On linux kernel build, I found thousands of cases where functions which are
expected (by programmer) to be inlined, aren't actually inlined.

The following script is used to find them:

nm --size-sort vmlinux | grep -iF ' t ' | uniq -c | grep -v '^ *1 ' | sort -rn

It caltually finds functions which have same name, size, and occur more than
once. There are a few false positives, but vast majority of them are functions
which were supposed to be inlined, but weren't:

(Count) (size) (name)
473 000b t spin_unlock_irqrestore
449 005f t rcu_read_unlock
355 0009 t atomic_inc
353 006e t rcu_read_lock
350 0075 t rcu_read_lock_sched_held
291 000b t spin_unlock
266 0019 t arch_local_irq_restore
215 000b t spin_lock
180 0011 t kzalloc
165 0012 t list_add_tail
161 0019 t arch_local_save_flags
153 0016 t test_and_set_bit
134 000b t spin_unlock_irq
134 0009 t atomic_dec
130 000b t spin_unlock_bh
122 0010 t brelse
120 0016 t test_and_clear_bit
120 000b t spin_lock_irq
119 001e t get_dma_ops
117 0053 t cpumask_next
116 0036 t kref_get
114 001a t schedule_work
106 000b t spin_lock_bh
103 0019 t arch_local_irq_disable
 98 0014 t atomic_dec_and_test
 83 0020 t sg_page
 81 0037 t cpumask_check
 79 0036 t pskb_may_pull
 72 0044 t perf_fetch_caller_regs
 70 002f t cpumask_next
 68 0036 t clk_prepare_enable
 65 0018 t pci_write_config_byte
 65 0013 t tasklet_schedule
 61 0023 t init_completion
 60 002b t trace_handle_return
 59 0043 t nlmsg_trim
 59 0019 t pci_read_config_dword
 59 000c t slow_down_io
...
...

Note tiny sizes of some functions. Let's take a look at atomic_inc:

static inline void atomic_inc(atomic_t *v)
{
asm volatile(LOCK_PREFIX "incl %0"
 : "+m" (v->counter));
}

You would imagine that this won't ever be deinlined, right? It's one assembly
instruction. Well, it isn't always inlined. Here's the disassembly of vmlinux:

81003000 :
81003000:   55  push   %rbp
81003001:   48 89 e5mov%rsp,%rbp
81003004:   f0 ff 07lock incl (%rdi)
81003007:   5d  pop%rbp
81003008:   c3  retq

This can be fixed using __always_inline, but kernel developers hesitate to slap
thousands of __always_inline everywhere, the mood is that this is a compiler's
fault and it should not be accomodated for, but fixed.

This happens quite easily with -Os (IOW: with CC_OPTIMIZE_FOR_SIZE=y kernel
build), but -O2 is not immune either.

I found a file which exhibits an example of bad deinlining for both -O2 and -Os
and I'm going to attach it.

[Bug sanitizer/64839] libsanitizer shouldn't require

[geoff at geoff dot codes]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64839

--- Comment #18 from Geoff Nixon  ---
Ok thanks, for other idiots like myself who can't seem to figure out how to get
viewvc to generate a diff for a specific rev, a -p1 patch is:

svn diff -c 223032 svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch

Or if you don't have subversion installed, here:
http://gist.github.com/anonymous/7f239960c46240d83a67/raw

[Bug tree-optimization/37021] Fortran Complex reduction / multiplication not vectorized

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37021

--- Comment #18 from Richard Biener  ---
Author: rguenth
Date: Tue May 12 11:55:40 2015
New Revision: 223059

URL: https://gcc.gnu.org/viewcvs?rev=223059&root=gcc&view=rev
Log:
2015-05-12  Richard Biener  

PR tree-optimization/37021
* tree-vectorizer.h (struct _slp_tree): Add two_operators flag.
(SLP_TREE_TWO_OPERATORS): New define.
* tree-vect-slp.c (vect_create_new_slp_node): Initialize
SLP_TREE_TWO_OPERATORS.
(vect_build_slp_tree_1): Allow two mixing plus/minus in an
SLP node.
(vect_build_slp_tree): Adjust.
(vect_analyze_slp_cost_1): Likewise.
(vect_schedule_slp_instance): Vectorize mixing plus/minus by
emitting two vector stmts and mixing the results.

* gcc.target/i386/vect-addsub.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/vect-addsub.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c
trunk/gcc/tree-vectorizer.h

[Bug middle-end/66084] ICE:internal compiler error: in fold_convert_loc, at fold-const.c:1974

[zhongyunde at huawei dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66084

--- Comment #4 from vfdff  ---
ok, it is ok based on gcc 4.9.2, thanks.
$GCC492/gcc ticket_1634.c -O2

[Bug sanitizer/64839] libsanitizer shouldn't require

[y.gribov at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64839

--- Comment #17 from Yury Gribov  ---
(In reply to Geoff Nixon from comment #16)
> what I should use to patch against the release?
> Or is there a different set of changes
> specific to the 5.1 branch backport?

For 5.1 you'd better use the patch in gcc-5-branch:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=223032

[Bug c++/66121] New: internal compiler error: in strip_typedefs, at cp/tree.c:1369

[dennis.demidov at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66121

Bug ID: 66121
   Summary: internal compiler error: in strip_typedefs, at
cp/tree.c:1369
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dennis.demidov at gmail dot com
  Target Milestone: ---

Created attachment 35527
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35527&action=edit
The preprocessed code stripped with the delta tool.

The following code (reduced from [vexcl](https://github.com/ddemidov/vexcl)
library) leads to an internal compiler error:

$ cat strip_typedefs_ice.cpp
#include 
typedef int32_t cl_int __attribute__((aligned(4)));
struct buffer_unmapper {
void operator()(cl_int* ptr) const {
}
};
typedef std::unique_ptr mapped_array;

$ g++ -c -std=c++11 strip_typedefs_ice.cpp  
strip_typedefs_ice.cpp:7:50: internal compiler error: in strip_typedefs, at
cp/tree.c:1369
 typedef std::unique_ptr mapped_array;
  ^

[Bug sanitizer/64839] libsanitizer shouldn't require

[geoff at geoff dot codes]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64839

Geoff Nixon  changed:

   What|Removed |Added

 CC||geoff at geoff dot codes

--- Comment #16 from Geoff Nixon  ---
Sorry to be an idiot, but I just ran into this building from the 5.1 release
tarball. Is the patch attached to this bug (dated 2015-04-10) what I should use
to patch against the release? Or is there a different set of changes specific
to the 5.1 branch backport?

[Bug c++/59224] [4.7/4.8/4.9 Regression] std::uncaught_exception returns true while constructing exception.

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59224

--- Comment #9 from Jonathan Wakely  ---
(In reply to li xin from comment #8)
> It will lead to the lsb test caes
> /libstdcxx-t2c/tests/LanguageSupport/LanguageSupport FAIL.
> So I want to know the right return value of std::uncaught_exception()
> (inside exception-constructor).

What isn't clear about the bug report? The right value is the one G++ gives
now.

The LSB test is wrong.

[Bug sanitizer/64839] libsanitizer shouldn't require

[y.gribov at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64839

--- Comment #15 from Yury Gribov  ---
(In reply to Thierry Reding from comment #14)
> Thanks Yury.

Np, you are welcome.

@Harald: could you close the bug if it works for you?

[Bug tree-optimization/66119] [5/6 Regression] in optimization of avx-code

[jgreenhalgh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66119

--- Comment #7 from James Greenhalgh  ---
(In reply to Richard Biener from comment #5)
> DEFPARAM (PARAM_SRA_MAX_SCALARIZATION_SIZE_SPEED,
>   "sra-max-scalarization-size-Ospeed",
>   "Maximum size, in storage units, 
> 
> storage units!  But the value seems to be in bits?  It gets used as
> 
> if (tree_to_uhwi (TYPE_SIZE (TREE_TYPE (var)))
> <= max_scalarization_size)
> 

Well, that part should have been covered by:

+  unsigned max_scalarization_size
+= (optimize_function_for_size_p (cfun)
+   ? PARAM_VALUE (PARAM_SRA_MAX_SCALARIZATION_SIZE_SIZE)
+   : PARAM_VALUE (PARAM_SRA_MAX_SCALARIZATION_SIZE_SPEED))
+  * BITS_PER_UNIT;

>From the original patch, 

> Looks like get_move_ratio returns different things at SRA time (if I re-call
> it)
> and the time it gets invoked in toplev.c.

But, yes these parameters will cause a difference in code generation if
previously MOVE_RATIO could return different values at different times, as it
might well have if target_option_override set up a structure used by
MOVE_RATIO.

The patch I applied carries the hidden assumption that MOVE_RATIO is constant.
Clearly there are a number of situations we might not want that to be true
(say, for switchable targets - which I don't think your patch will help).

[Bug sanitizer/64839] libsanitizer shouldn't require

[thierry.reding at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64839

--- Comment #14 from Thierry Reding  ---
Thanks Yury.

[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO

[steffen at hauihau dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394

--- Comment #31 from Steffen Hau  ---
Just a short update.

With LTO enabled, configure thinks I have a buggy GCC:
checking if gcc has a visibility bug with class-level attributes (GCC bug
26905)... yes
configure: WARNING: Your gcc is not -fvisibility=hidden safe. Disabling
visibility

I've then added -ffat-lto-objects to my ${C,CXX,Ld}FLAGS and the warning
disappeared.

The build failes at the same place, but instead of a segmentation fault I now
get a illegal instruction error:
/bin/sh: line 1: 10795 Illegal instruction SAL_USE_VCLPLUGIN=svp
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/ure/lib:$I/program"
$I/program/gengal.bin "-env:BRAND_BASE_DIR=file://$S/instdir"
"-env:CONFIGURATION_LAYERS=xcsxcu:file://$I/share/registry"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb 
file://$W/ComponentTarget/comphelper/util/comphelp.component 
file://$W/ComponentTarget/configmgr/source/configmgr.component 
file://$W/ComponentTarget/drawinglayer/drawinglayer.component 
file://$W/ComponentTarget/framework/util/fwk.component 
file://$W/ComponentTarget/i18npool/util/i18npool.component 
file://$W/ComponentTarget/package/source/xstor/xstor.component 
file://$W/ComponentTarget/package/util/package2.component 
file://$W/ComponentTarget/sax/source/expatwrap/expwrap.component 
file://$W/ComponentTarget/sfx2/util/sfx.component 
file://$W/ComponentTarget/svgio/svgio.component 
file://$W/ComponentTarget/svx/util/svx.component 
file://$W/ComponentTarget/svx/util/svxcore.component 
file://$W/ComponentTarget/ucb/source/core/ucb1.component 
file://$W/ComponentTarget/ucb/source/ucp/file/ucpfile1.component 
file://$W/ComponentTarget/unoxml/source/service/unoxml.component"
"-env:UNO_TYPES= file://$I/program/types/offapi.rdb 
file://$I/ure/share/misc/types.rdb" -env:URE_INTERNAL_LIB_DIR=file://$I/ure/lib
-env:LO_LIB_DIR=file://$I/program --build-tree --destdir
file://$S/extras/source/gallery --name "arrows" --path $W/Gallery/arrows
--filenames file://$RESPONSEFILE
/home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/solenv/gbuild/Gallery.mk:72:
recipe for target
'/home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/workdir/Gallery/arrows.done'
failed
make[1]: ***
[/home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/workdir/Gallery/arrows.done]
Error 132
make[1]: *** Waiting for unfinished jobs

[Bug tree-optimization/66119] [5/6 Regression] in optimization of avx-code

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66119

--- Comment #6 from Richard Biener  ---
Fixed by

Index: toplev.c
===
--- toplev.c(revision 223044)
+++ toplev.c(working copy)
@@ -1311,6 +1311,9 @@ process_options (void)
  so we can correctly initialize debug output.  */
   no_backend = lang_hooks.post_options (&main_input_filename);

+  /* Some machines may reject certain combinations of options.  */
+  targetm.target_option.override ();
+
   /* Set default values for parameters relation to the Scalar Reduction
  of Aggregates passes (SRA and IP-SRA).  We must do this here, rather
  than in opts.c:default_options_optimization as historically these
@@ -1325,9 +1328,6 @@ process_options (void)
  get_move_ratio (false) * UNITS_PER_WORD,
  global_options.x_param_values, global_options_set.x_param_values);

-  /* Some machines may reject certain combinations of options.  */
-  targetm.target_option.override ();
-
   /* Avoid any informative notes in the second run of -fcompare-debug.  */
   if (flag_compare_debug) 
 diagnostic_inhibit_notes (global_dc);

though not sure whether a 2nd maybe_set_param_value will still allow the
target to adjust this default...

[Bug tree-optimization/66119] [5/6 Regression] in optimization of avx-code

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66119

--- Comment #5 from Richard Biener  ---
DEFPARAM (PARAM_SRA_MAX_SCALARIZATION_SIZE_SPEED,
  "sra-max-scalarization-size-Ospeed",
  "Maximum size, in storage units, 

storage units!  But the value seems to be in bits?  It gets used as

if (tree_to_uhwi (TYPE_SIZE (TREE_TYPE (var)))
<= max_scalarization_size)

max_scalarization_size is 384, the aggregate size is 512.

Looks like get_move_ratio returns different things at SRA time (if I re-call
it)
and the time it gets invoked in toplev.c.

[Bug target/66112] __builtin_mul_overflow for int16_t emits poor code

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66112

--- Comment #8 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 35524 [details]
> gcc6-pr66112-2.patch
> 
> And i386 mulvhi4 and umulvhi4 support.  For umulvhi4, I haven't found
> corresponding i386.md instruction that would emit mul{w}, so just changed
> SWI48 to SWI248 iterator in that case.

No, mulw outputs to %ax:%dx pair of HImode registers! Please see [1]

[1] http://x86.renejeschke.de/html/file_module_x86_id_210.html

[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66066

--- Comment #8 from clyon at gcc dot gnu.org ---
Can we consider moving this to -pedantic as suggested by Richard in comment #4?

Full compiler builds are broken because of this.

Thanks

[Bug tree-optimization/66119] [5/6 Regression] in optimization of avx-code

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66119

--- Comment #4 from Richard Biener  ---
And we indeed rely on SRA to copy propagate aggregates.

[Bug tree-optimization/66119] [5/6 Regression] in optimization of avx-code

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66119

--- Comment #3 from Richard Biener  ---
Ah, it's parameter b assigned to local decl b.

[Bug c++/66119] [5/6 Regression] in optimization of avx-code

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66119

--- Comment #2 from Richard Biener  ---
Confirmed.  We expand from

  :
  a$data_13 = MEM[(struct Vec2 *)&a];
  a$32$data_14 = MEM[(struct Vec2 *)&a + 32B];
  b = b;
  v2_15 = MEM[(struct Vec2 *)&b];
  v2$32_16 = MEM[(struct Vec2 *)&b + 32B];
  _7 = a$32$data_14 + v2$32_16;
  _10 = a$data_13 + v2_15;
  MEM[(struct Vec2 *)&] = _10;
  MEM[(struct Vec2 *)& + 32B] = _7;
  return ;

in GCC 5 (note the b = b assignment) while 4.9 sees

  :
  a$data_4 = MEM[(struct Vec2 *)&a];
  a$32$data_13 = MEM[(struct Vec2 *)&a + 32B];
  v2_14 = MEM[(struct Vec2 *)&b];
  v2$32_15 = MEM[(struct Vec2 *)&b + 32B];
  _7 = a$32$data_13 + v2$32_15;
  _10 = a$data_4 + v2_14;
  MEM[(struct Vec2 *)&] = _10;
  MEM[(struct Vec2 *)& + 32B] = _7;
  return ;

[Bug c++/66119] [5/6 Regression] in optimization of avx-code

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66119

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-12
 CC||jakub at gcc dot gnu.org,
   ||jgreenhalgh at gcc dot gnu.org
   Target Milestone|--- |5.2
Summary|Regression in optimization  |[5/6 Regression] in
   |of avx-code |optimization of avx-code
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Broken by r217191.

[Bug target/66112] __builtin_mul_overflow for int16_t emits poor code

[gcc.hall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66112

--- Comment #7 from Jeremy  ---
Comment on attachment 35522
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35522
gcc5-pr66112.patch

Done, PR66120

[Bug target/66120] New: __builtin_add/sub_overflow for int32_t emit poor code on ARM

[gcc.hall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66120

Bug ID: 66120
   Summary: __builtin_add/sub_overflow for int32_t emit poor code
on ARM
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc.hall at gmail dot com
  Target Milestone: ---

Please see related PR66112 for x86
---
#include 
#include 
int
main( int argc, const char *argv[] )
{
  int32_t result, a = (int32_t)atoi(argv[1]), b = (int32_t)atoi( argv[2] );
  if( __builtin_add_overflow( a, b, &result ) )
printf( "Overflow\n");
 else
printf( "Sum is %d\n", result );
}
--
Few instructions on ARM set the overflow flag.  Two that do are 32-bit add and
subtract.  For these two, GCC could just emit "adds" or "subs" followed by
"bvs".
Instead (from the last atoi() down) it produces:-

bl  atoi@
add r1, r4, r0  @ tmp121, a, b
cmp r0, #0  @ b,
blt .L4 @,
cmp r1, r4  @ tmp121, a
bge .L5 @,
b   .L3 @
.L4:
cmp r1, r4  @ tmp121, a
ble .L5 @,

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038

Richard Biener  changed:

   What|Removed |Added

 CC||mikestump at comcast dot net
   Target Milestone|--- |5.2
Summary|[5.1.0 regression] (stage   |[5 regression] (stage 2)
   |2) build/genmatch segfaults |build/genmatch segfaults in
   |in operand::gen_transform   |operand::gen_transform
   |(gcc/hash-table.h:223)  |(gcc/hash-table.h:223)

--- Comment #6 from Richard Biener  ---
(In reply to Douglas Mencken from comment #5)
> (In reply to rguent...@suse.de from comment #4)
> > Can you build stage2 with debuginfo?  (--without-build-config at 
> > configure)
> > 
> > That should imrpove the backtrace.
> > 
> > Thanks,
> > Richard.
> 
> Sure I can. Here you go:
> 
> (gdb) bt
> #0  0xe208 in operand::gen_transform () at
> ../../gcc-5.1.0/gcc/hash-table.h:223
> #1  0x8530 in get_operator (id=0x808bec "tcc_comparison") at
> ../../gcc-5.1.0/gcc/genmatch.c:1495
> #2  0x9ef8 in parser::parse_operator_list (this=0xb698) at
> ../../gcc-5.1.0/gcc/genmatch.c:2941
> #3  0xd190 in parser::parse_pattern (this=0xb698) at
> ../../gcc-5.1.0/gcc/hash-table.h:223
> #4  0xe19c in parser::parser (this=0xb698, r_=0xb4f8) at
> ../../gcc-5.1.0/gcc/hash-table.h:223
> #5  0x0005f3ac in main (argc=3146720, argv=0xb4f8) at
> ../../gcc-5.1.0/gcc/genmatch.c:3711
> Current language:  auto; currently c++

Huh, the line numbers don't make any sense.

I wonder what

ld warning: atom sorting error for operand::gen_transform(__sFILE*, char
const*, bool, int, char const*, capture_info*, dt_operand**, bool) and
hash_table::find_with_hash(id_base const*,
unsigned int) in build/genmatch.o

means and if that explains things?  Like it ends up calling the wrong
function because of a linker bug?  Can you paste the linker command for
linking stage2 build/genmatch and the output when -v -Wl,-v -Wl,-debug is
appended?

As far as I understand ld on ppc-darwin is a GNU ld variant, correct?
I can't find anything in current binutils though.  Mike?

[Bug target/64691] Suboptimal register allocation for bytes comparison on i386

[ysrumyan at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64691

--- Comment #2 from Yuri Rumyantsev  ---
Created attachment 35526
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35526&action=edit
tset-case to reproduce and assembly file.

[Bug c++/66119] New: Regression in optimization of avx-code

[joachim.schoeberl at tuwien dot ac.at]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66119

Bug ID: 66119
   Summary: Regression in optimization of avx-code
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joachim.schoeberl at tuwien dot ac.at
  Target Milestone: ---

Created attachment 35525
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35525&action=edit
testcode

gcc 5.1 produces a lot of scalar moves for the attached vector-class code. 
gcc 4.9 generates compact code (see below).

compiled using:
gcc -O3 -mavx -S -std=c++11 testgcc.cpp

compiler version:
gcc (GCC) 5.1.1 20150505



gcc 5.1 works fine in any of the cases:

- we use a manual copy constructor instead of '= default' (line 37):
MyTSIMD (const MyTSIMD & s2) : data(s2.data) { ; } 

- we use the concrete vector-class instead of the template (line 45):
using MyVec = MyAVX;

- we do not use  
  __attribute__ ((__always_inline__)) 
for ComputeSomething  (line 58)



Cheers, Joachim




code generated by gcc5.1:

.globl  _Z12TestFunction4Vec2S_
.type   _Z12TestFunction4Vec2S_, @function
_Z12TestFunction4Vec2S_:
.LFB4604:
.cfi_startproc
movq72(%rsp), %rdx
vmovapd 40(%rsp), %ymm0
movq%rdi, %rax
vmovapd 8(%rsp), %ymm1
movq%rdx, -88(%rsp)
movq80(%rsp), %rdx
movq%rdx, -80(%rsp)
movq88(%rsp), %rdx
movq%rdx, -72(%rsp)
movq96(%rsp), %rdx
movq%rdx, -64(%rsp)
movq104(%rsp), %rdx
vaddpd  -88(%rsp), %ymm1, %ymm1
movq%rdx, -56(%rsp)
movq112(%rsp), %rdx
movq%rdx, -48(%rsp)
movq120(%rsp), %rdx
vmovapd %ymm1, (%rdi)
movq%rdx, -40(%rsp)
movq128(%rsp), %rdx
movq%rdx, -32(%rsp)
vaddpd  -56(%rsp), %ymm0, %ymm0
vmovapd %ymm0, 32(%rdi)
vzeroupper
ret
.cfi_endproc




code generated by gcc 4.9.2:

.type   _Z12TestFunction4Vec2S_, @function
_Z12TestFunction4Vec2S_:
.LFB2234:
.cfi_startproc
vmovapd 40(%rsp), %ymm0
movq%rdi, %rax
vmovapd 8(%rsp), %ymm1
vaddpd  104(%rsp), %ymm0, %ymm0
vaddpd  72(%rsp), %ymm1, %ymm1
vmovapd %ymm0, 32(%rdi)
vmovapd %ymm1, (%rdi)
vzeroupper
ret
.cfi_endproc

[Bug target/64691] Suboptimal register allocation for bytes comparison on i386

[ysrumyan at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64691

Yuri Rumyantsev  changed:

   What|Removed |Added

 CC||ysrumyan at gmail dot com

--- Comment #1 from Yuri Rumyantsev  ---
I found another register allocation deficiency which can be exhibited at the
attached test-case extracted from important benchmark. If we look at inner loop
for(i = 0; i < size; i++) {
byte xr, xg, xb, t1;
sbyte t2, t3;
x1 = read[0];
x2 = read[1];
x3 = read[2];
t1 = (byte) (((C1 * x1) + (C2 * x2) + (C3 * x3) +
(1 << (SCALE - 1))) >> SCALE);
t2 = (sbyte) (((C4 * x1) + (C5 * x2) + (C6 * x3) +
(1 << (SCALE - 1))) >> SCALE);
t3 = (sbyte) (((C7 * x1) + (C8 * x2) + (C9 * x3) +
(1 << (SCALE - 1))) >> SCALE);
write[0] = t1;
write[1] = (byte) t2;
write[2] = (byte) t3;
read += 3;
write += 3;
}
we can see that 7 registers is enough to keep all variable (except for upper
loop bound): 3 registers for x1,x2,x3, 2 registers for read and write pointers
and 2 registers for computation one for t1,t2,t3  computations and one scratch
register for multiplications (but since consumers of t1,t2,t3 is byte store
this register must belong also to Q_REQS subset, i.e. AREG,BREG,CREG or DREG).
But LRA does not perform such allocation and this leads to redundant
spill/fills and results in performance degradation. Assembly file produced 6.0
compiler with "-O2 -m32 -march=slm" options is attached too.