[Bug libgomp/69555] libgomp.c++/target-6.C fails because of undefined behaviour

[vogt at linux dot vnet.ibm.com]

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

--- Comment #11 from Dominik Vogt  ---
Successfully bootstrapped and regression tested on s390x biarch.
Thanks.

[Bug tree-optimization/68659] [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)

[vogt at linux dot vnet.ibm.com]

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

--- Comment #22 from Dominik Vogt  ---
Successfully bootstrapped and regression tested on s390x biarch.
Thanks.

[Bug middle-end/69987] [6 Regression] internal compiler error: in verify_loop_structure, at cfgloop.c:1639

[vogt at linux dot vnet.ibm.com]

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

--- Comment #7 from Dominik Vogt  ---
Fixed on s390x.
Thanks.

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #11 from Alan Modra  ---
The first thing I noticed when looking at rtl dumps for this bug is
that -fno-dce makes a difference to the REG_EQUIV notes emitted by the
ira pass.

With -fno-dce we get this:
(insn 6 41 8 2 (set (reg:DI 173)
(mem/u/c:DI (reg/f:DI 172) [0  S8 A32])) /src/tmp/pr69195.c:15 549
{*movdi_internal64}
 (expr_list:REG_EQUIV (mem/u/c:DI (reg/f:DI 172) [0  S8 A32])
(nil)))

With -fdce we get:
(insn 6 41 8 2 (set (reg:DI 173)
(mem/u/c:DI (reg/f:DI 172) [0  S8 A32])) /src/tmp/pr69195.c:15 549
{*movdi_internal64}
 (expr_list:REG_EQUIV (mem/c:DI (plus:DI (reg/f:DI 113 sfp)
(const_int 96 [0x60])) [1 a+0 S8 A128])
(nil)))

I think the second note is invalid.  Reg 173 is *not* the same as the
stack location at this point.  (It is after the reg has been stored.)

The reason the notes are different is that in the -fno-dce case
ira.c:3566 call to validate_equiv_mem returns true, whereas when dce
is enabled it returns false due to hitting a REG_DEAD for reg 172
(ira.c:2992) before seeing REG_DEAD for reg 173.  This in turn leads
to ira.c:3677 setting the note.  It's interesting that ira.c:3679
correctly comments that the store is the insn making the equivalence,
not the load, but leaves the note of the load regardless..

Another curious fact is that ira with -fno-dce deletes the same dead
loads removed by -fdce, but in this case by the call to
delete_trivially_dead_insns in ira, *after* the update_equiv_regs call
that creates the reg notes.  Deleting those insns of course moves the
REG_DEAD note for reg 172 earlier, before the store that goes wrong.

[Bug target/70059] New: Invalid codegen on AVX-512 when using _mm512_inserti64x4(x, y, 0)

[povilas at radix dot lt]

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

Bug ID: 70059
   Summary: Invalid codegen on AVX-512 when using
_mm512_inserti64x4(x, y, 0)
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: povilas at radix dot lt
  Target Milestone: ---

Use of _mm512_inserti64x4 in certain scenario outlined below fails on GCC
5.3.1.

$ g++-5 --version
g++-5 (Ubuntu 5.3.1-9ubuntu3) 5.3.1 20160222

$ cat main.cc
#include "immintrin.h"

__m512i run(__m256i a, __m256i b)
{
__m512i r = _mm512_undefined_si512();
r = _mm512_inserti64x4(r, a, 0);
r = _mm512_inserti64x4(r, b, 1);
return r;
}

$ g++-5 -O1 -c main.cc --save-temps -o main.o -mavx512f

The following assembly is generated:
_Z3runDv4_xS_:
vinserti64x4$0x1, %ymm0, %zmm1, %zmm0
ret

As you can see, the first argument is inserted into the upper half of zmm0
register and the second into the lower. The intention is the other way round.

The problem can be worked around:

$ cat main.cc
#include "immintrin.h"

__m512i run(__m256i a, __m256i b)
{
__m512i r;
r = _mm512_castsi256_si512(a);
r = _mm512_inserti64x4(r, b, 1);
return r;
}

$ g++-5 -O1 -c main.cc --save-temps -o main.o -mavx512f

The resulting assembly is correct:
_Z3runDv4_xS_:
vinserti64x4$0x1, %ymm1, %zmm0, %zmm0
ret


Regards,
Povilas

[Bug tree-optimization/55936] [4.9/5/6 Regression] Missed VRP optimization

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
Author: rguenth
Date: Thu Mar  3 09:12:53 2016
New Revision: 233928

URL: https://gcc.gnu.org/viewcvs?rev=233928&root=gcc&view=rev
Log:
2016-03-03  Richard Biener  

PR tree-optimization/55936
* tree-vrp.c (compare_name_with_value): Add use_equiv_p
parameter and guard unsafe equivalence use.
(vrp_evaluate_conditional_warnv_with_ops): Always use
safe equivalences but not via the quadratic compare_names
helper.

* gcc.dg/tree-ssa/vrp06.c: Remove XFAIL.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp06.c
trunk/gcc/tree-vrp.c

[Bug tree-optimization/55936] [4.9/5/6 Regression] Missed VRP optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||6.0
 Resolution|--- |FIXED
   Target Milestone|4.9.4   |6.0
  Known to fail|4.8.0   |4.8.5, 4.9.4, 5.3.0

--- Comment #15 from Richard Biener  ---
Fixed for GCC 6.  I'm not planning to backport, thus FIXED.

[Bug rtl-optimization/70023] [4.9/5/6 Regression] ICE: in assign_by_spills, at lra-assigns.c:1417 with -fno-sched-critical-path-heuristic -fschedule-insns -m8bit-idiv

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||ysrumyan at gmail dot com

--- Comment #4 from Uroš Bizjak  ---
(In reply to Jeffrey A. Law from comment #3)
> In the past we've not supported the first instruction scheduling pass on the
> x86 because of the problems with extension of hard register lifetimes.
> 
> Is that still the case?  If so, what's the mechanism by which that happens
> these days (I didn't see if with some quick scanning).

The target-dependent scheduling fixups are based on work by Yuri Rumyantsev
(CCd) from 2012, e.g.:

2012-10-04  Yuri Rumyantsev  

* config/i386/i386.c (ix86_dep_by_shift_count_body) : Add
check on reload_completed since it can be invoked before
register allocation phase in pre-reload schedule.
(ia32_multipass_dfa_lookahead) : Do not use dfa_lookahead for
pre-reload schedule to save compile time.
(ix86_sched_reorder) : Do not perform ready list reordering for
pre-reload schedule to save compile time.
(insn_is_function_arg) : New function. Returns true if lhs of insn is
HW function argument register.
(add_parameter_dependencies) : New function. Add output dependencies
for chain of function adjacent arguments if only there is a move to
likely spilled HW registers. Return first argument if at least one
dependence was added or NULL otherwise.
(avoid_func_arg_motion) : New function. Add output or anti dependency
from insn to first_arg to restrict code motion.
(add_dependee_for_func_arg) : New function. Avoid cross block motion of
function argument through adding dependency from the first non-jump
insn in bb.
(ix86_dependencies_evaluation_hook) : New function. Hook for
pre-reload schedule: avoid motion of function arguments passed in
likely spilled HW registers.
(ix86_adjust_priority) : New function. Hook for pre-reload schedule:
set priority of moves from likely spilled HW registers to maximum to
schedule them as soon as possible.
(ix86_sched_init_global): Do not perform multipass scheduling for
pre-reload schedule to save compile time.

which introduced several scheduling helpers that try to rearrange insns to
decrease probability of running into spill failures. While these fixups and
some later RA significantly reduced spill failures, there are still some cases
(like the one in this PR), where allocation fails with severely constrainted
instructions.

[Bug target/70059] Invalid codegen on AVX-512 when using _mm512_inserti64x4(x, y, 0)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I'll have a look.

[Bug rtl-optimization/69904] [6 Regression] shrink-wrapping creates weird atomic compare exchange loop on arm

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #5)
> I'll propose a patch to disallow copying of load-exclusive insns

https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00211.html

[Bug tree-optimization/70046] [6 Regression] 410.bwaves regression on Haswell

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
I've confirmed the regression to be caused by r230647

  Estimated   Estimated
Base Base   BasePeak Peak   Peak
Benchmarks  Ref.   Run Time Ratio   Ref.   Run Time Ratio
-- --  -  ---  -  -
410.bwaves  13590180   75.7 *   13590198   68.6 *  

with BASE on r230646 and PEAK on r230647 using -Ofast -march=haswell on a
Intel(R) Core(TM) i5-4670T

I can even reproduce the difference w/o any -march thus with just -Ofast:

  Estimated   Estimated
Base Base   BasePeak Peak   Peak
Benchmarks  Ref.   Run Time Ratio   Ref.   Run Time Ratio
-- --  -  ---  -  -
410.bwaves  13590176   77.1 *   13590199   68.5 *  


As expected the difference is in mat_times_vec_

Samples: 1M of event 'cycles', Event count (approx.): 1280690858409 
 39.22%  bwaves_peak.amd  bwaves_peak.amd64-m64-gcc42-nn  [.] mat_times_vec_
 33.60%  bwaves_base.amd  bwaves_base.amd64-m64-gcc42-nn  [.] mat_times_vec_


IV differences are a mixed bag but number of IVs are different for the
nest, the slower case having much more IVs in the inner loop.

[Bug tree-optimization/70043] [6 Regression] The compiler hangs in a fortran test-case with -Ofast -g -march=haswell

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Author: marxin
Date: Thu Mar  3 10:08:09 2016
New Revision: 233934

URL: https://gcc.gnu.org/viewcvs?rev=233934&root=gcc&view=rev
Log:
Skip properly debug stmt in optimize_mask_stores (PR

PR tree-optimization/70043
* tree-vect-loop.c (optimize_mask_stores): Move iterator to
previous statement if we see a debug statement.
* gfortran.dg/vect/pr70043.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/vect/pr70043.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug target/70059] Invalid codegen on AVX-512 when using _mm512_inserti64x4(x, y, 0)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-03-03
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Preparing a patch.

[Bug tree-optimization/70046] [6 Regression] 410.bwaves regression on Haswell

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Ok, benchmark re-done with unmodified 410.bwave sources (eh ...)

  Estimated   Estimated
Base Base   BasePeak Peak   Peak
Benchmarks  Ref.   Run Time Ratio   Ref.   Run Time Ratio
-- --  -  ---  -  -
410.bwaves  13590196   69.2 *   13590188   72.2 *  

Thus - INVALID.

[Bug lto/70044] [5/6 Regression] -flto turns on -fomit-frame-pointer

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Doesn't seem to happen on arm or x86_64.
Who is responsible for recomputing the values of the optimisation options i.e.
flag_omit_frame_pointer during LTO?

[Bug bootstrap/60632] ICE in regcprop.c (copyprop_hardreg_forward_1)

[alalaw01 at gcc dot gnu.org]

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

alalaw01 at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||alalaw01 at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #2 from alalaw01 at gcc dot gnu.org ---
Sorry, no idea...

[Bug middle-end/70050] [6 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have vector_type in generic_simplify_162, at generic-mat

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Thu Mar  3 11:42:19 2016
New Revision: 233937

URL: https://gcc.gnu.org/viewcvs?rev=233937&root=gcc&view=rev
Log:
PR middle-end/70050
* match.pd (X % -Y): Add INTEGRAL_TYPE_P check.

* gcc.dg/pr70050.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr70050.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/70050] [6 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have vector_type in generic_simplify_162, at generic-mat

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Fixed.

[Bug c/70060] New: array initialization adds to executable size

[stsp at users dot sourceforge.net]

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

Bug ID: 70060
   Summary: array initialization adds to executable size
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stsp at users dot sourceforge.net
  Target Milestone: ---

Hello.

The following code:
---
int bigarr[1024*1024] = {1,};
int main()
{
return 0;
}
---

produces a 4Mb executable when compiled with -Os.
Shouldn't the trivial initialization be optimized?

[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops

[winter-...@bfw-online.de]

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

--- Comment #9 from Leon Winter  ---
> If you declare it outside the loop body, gcc generates exactly the same code
> for a 'for' and a 'do-while'.

You are right. When I did the testing, I mistakenly left out "-O1" or such so I
did not see the warning :/
Probably there is no way to hint to the compiler a code path is always visited
(similar to "likely()"/"unlikely()") so we will stick with gcc-4.9.x for the
time being.

[Bug tree-optimization/69196] [5/6 Regression] code size regression with jump threading at -O2

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 CC||thopre01 at gcc dot gnu.org

--- Comment #19 from Thomas Preud'homme  ---
Created attachment 37850
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37850&action=edit
vrp1 dump for arm-none-eabi targets

Same FAIL on arm-none-eabi targets. Please find attached vrp1 dump.

[Bug target/70049] [6 Regression] Error: operand size mismatch for `vpextrw' (wrong assembly generated) with -masm=intel

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug rtl-optimization/70061] New: [6 Regression] ICE: SIGSEGV in delete_insn_chain() with -mstringop-strategy=libcall

[zsojka at seznam dot cz]

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

Bug ID: 70061
   Summary: [6 Regression] ICE: SIGSEGV in delete_insn_chain()
with -mstringop-strategy=libcall
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
Target: i686-pc-linux-gnu

Created attachment 37851
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37851&action=edit
reduced testcase

Compiler output:
$ i686-pc-linux-gnu-gcc -Os -fno-tree-coalesce-vars -mstringop-strategy=libcall
testcase.c testcase.c: In function 'foo':
testcase.c:4:1: note: The ABI for passing parameters with 32-byte alignment has
changed in GCC 4.6
 foo(v8si c, v8si d)
 ^~~
testcase.c:4:1: warning: AVX vector argument without AVX enabled changes the
ABI [-Wpsabi]
testcase.c:10:1: internal compiler error: Segmentation fault
 }
 ^
0xbb842f crash_signal
/repo/gcc-trunk/gcc/toplev.c:335
0x72f55d safe_as_a
/repo/gcc-trunk/gcc/rtl.h:844
0x72f55d delete_insn_chain(rtx_def*, rtx_def*, bool)
/repo/gcc-trunk/gcc/cfgrtl.c:246
0x72fa9f rtl_merge_blocks
/repo/gcc-trunk/gcc/cfgrtl.c:885
0x7204d5 merge_blocks(basic_block_def*, basic_block_def*)
/repo/gcc-trunk/gcc/cfghooks.c:774
0x13d5df4 merge_blocks_move
/repo/gcc-trunk/gcc/cfgcleanup.c:774
0x13d5df4 try_optimize_cfg
/repo/gcc-trunk/gcc/cfgcleanup.c:2787
0x13d5df4 cleanup_cfg(int)
/repo/gcc-trunk/gcc/cfgcleanup.c:3028
0x71c0c2 execute
/repo/gcc-trunk/gcc/cfgexpand.c:6467
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ i686-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-i686/bin/i686-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-233911-checking-yes-rtl-df-nographite-i686/bin/../libexec/gcc/i686-pc-linux-gnu/6.0.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=i686-pc-linux-gnu --with-ld=/usr/bin/i686-pc-linux-gnu-ld
--with-as=/usr/bin/i686-pc-linux-gnu-as --with-sysroot=/usr/i686-pc-linux-gnu
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-233911-checking-yes-rtl-df-nographite-i686
Thread model: posix
gcc version 6.0.0 20160302 (experimental) (GCC) 


Tested revisions:
trunk r233911 - FAIL
trunk r233861 - FAIL
5-branch r233800 - OK

[Bug middle-end/70054] GCC 6 gives a strict-aliasing warning on use of std::aligned_storage

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
GCC 6 re-introduces type-based alias analysis for pointer objects and thus
if you do sth like

 *(int *)&x = A;
  ... = *(long *)&x;

then the compiler will now remove the store (because 'int *' does not
alias 'long *').

The warning is because std::aligned_storage::type
is a union:

struct aligned_storage
{
  union type
  {
unsigned char __data[_Len];
struct __attribute__((__aligned__((_Align { } __align;
  };
};

and this union does _not_ have alias-set zero!  In fact I think the improvement
on alias-set subsetting for structures/unions with an alias-set zero member
changed behavior here (PR66110).

The warning is somewhat bogus (well, the implementation is...) and relied on
that has_zero_child check.  It should instead use alias_set_subset_of, I will
test a patch.

[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops

[manu at gcc dot gnu.org]

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

--- Comment #10 from Manuel López-Ibáñez  ---
(In reply to Leon Winter from comment #9)
> > If you declare it outside the loop body, gcc generates exactly the same code
> > for a 'for' and a 'do-while'.
> 
> You are right. When I did the testing, I mistakenly left out "-O1" or such
> so I did not see the warning :/
> Probably there is no way to hint to the compiler a code path is always
> visited (similar to "likely()"/"unlikely()") so we will stick with gcc-4.9.x
> for the time being.

If you initialize buff that would silence the warning. If GCC is not able to
remove the initialization at -O2, -O3, -Os, that would be a missed optimization
worth reporting as a new PR. There are more devs working on optimizations than
on diagnostics (I guess the former is more important to paying customers than
the latter). Sometimes it just takes fixing the missed optimization to fix the
warning, but other times it takes more work.

Are you saying that GCC 4.9 does not warn? That would be surprising and a
regression. If you could find the revision that started warning, that would be
helpful.

[Bug target/70062] New: ICE: in decide_alg, at config/i386/i386.c:26173 with -mmemcpy-strategy=libcall

[zsojka at seznam dot cz]

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

Bug ID: 70062
   Summary: ICE: in decide_alg, at config/i386/i386.c:26173 with
-mmemcpy-strategy=libcall
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
Target: i686-pc-linux-gnu

Created attachment 37852
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37852&action=edit
reduced testcase

Compiler output:
$ i686-pc-linux-gnu-gcc -mtune=k6-2 -minline-all-stringops
-minline-stringops-dynamically -mmemcpy-strategy=libcall:-1:noalign testcase.c
-Wno-psabi
testcase.c: In function 'foo':
testcase.c:6:10: internal compiler error: in decide_alg, at
config/i386/i386.c:26173
   return (v8si){v32u64_0[0]};
  ^
0xecdf54 decide_alg
/repo/gcc-trunk/gcc/config/i386/i386.c:26173
0xf1454b ix86_expand_set_or_movmem(rtx_def*, rtx_def*, rtx_def*, rtx_def*,
rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, bool)
/repo/gcc-trunk/gcc/config/i386/i386.c:26433
0x10f7ede gen_movmemsi(rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*,
rtx_def*, rtx_def*, rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/config/i386/i386.md:16243
0xa8bfca insn_gen_fn::operator()(rtx_def*, rtx_def*, rtx_def*, rtx_def*,
rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*) const
/repo/gcc-trunk/gcc/recog.h:308
0xa8bfca maybe_gen_insn(insn_code, unsigned int, expand_operand*)
/repo/gcc-trunk/gcc/optabs.c:7020
0xa8c688 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
/repo/gcc-trunk/gcc/optabs.c:7032
0x8357de emit_block_move_via_movmem
/repo/gcc-trunk/gcc/expr.c:1301
0x8357de emit_block_move_hints(rtx_def*, rtx_def*, rtx_def*, block_op_methods,
unsigned int, long, unsigned long, unsigned long, unsigned long)
/repo/gcc-trunk/gcc/expr.c:1119
0x83624f emit_block_move(rtx_def*, rtx_def*, rtx_def*, block_op_methods)
/repo/gcc-trunk/gcc/expr.c:1157
0x83fbc4 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
/repo/gcc-trunk/gcc/expr.c:5573
0x841654 expand_assignment(tree_node*, tree_node*, bool)
/repo/gcc-trunk/gcc/expr.c:5175
0x713c7d expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.c:3618
0x713c7d expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.c:3714
0x716252 expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.c:5720
0x71b8b6 execute
/repo/gcc-trunk/gcc/cfgexpand.c:6335
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ i686-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-i686/bin/i686-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-233911-checking-yes-rtl-df-nographite-i686/bin/../libexec/gcc/i686-pc-linux-gnu/6.0.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=i686-pc-linux-gnu --with-ld=/usr/bin/i686-pc-linux-gnu-ld
--with-as=/usr/bin/i686-pc-linux-gnu-as --with-sysroot=/usr/i686-pc-linux-gnu
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-233911-checking-yes-rtl-df-nographite-i686
Thread model: posix
gcc version 6.0.0 20160302 (experimental) (GCC) 

Tested revisions:
Tested revisions:
trunk r233911 - FAIL
trunk r233861 - FAIL
5-branch r233800 - FAIL (endless recursion)
4_9-branch r233802 - FAIL (endless recursion)

[Bug target/70063] New: msp430 stack corruption for naked functions

[awygle at gmail dot com]

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

Bug ID: 70063
   Summary: msp430 stack corruption for naked functions
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: awygle at gmail dot com
  Target Milestone: ---

Created attachment 37853
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37853&action=edit
A nearly minimal example of code producing the bug

When compiling msp430 code including functions which have both arguments and
the naked attribute using -O0, the stack is corrupted and the return pointer is
lost.

This looks like an msp430-style retread of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54220 to me.

Code:

# 1 "bug.c"
# 1 ""
# 1 ""
# 1 "bug.c"

__attribute__((naked))
void buggy(int* arg1, int* arg2) {
  asm volatile("sub #4, r1");
  (*arg1) = 2;
  (*arg2) = 3;
  asm volatile ("nop");
  asm volatile ("nop");
  asm volatile ("nop");
  asm volatile ("nop");
  asm volatile ("nop");
  asm volatile ("ret");
}

int main() {

  int x, y;
  x = 0;
  y = 1;

  buggy(&x, &y);

  while(1) {}

}

Compiling:

[awygle %] msp430-elf-gcc -v -Wall -Wextra -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -mmcu=msp430fr5969 bug.c -o bug.elf
-save-temps

Using built-in specs.
COLLECT_GCC=msp430-elf-gcc
COLLECT_LTO_WRAPPER=/home/awygle/toolchain/install/libexec/gcc/msp430-elf/5.3.0/lto-wrapper
Target: msp430-elf
Configured with: ../gcc-5.3.0/configure
--prefix=/home/awygle/toolchain/install/ --target=msp430-elf --without-headers
--with-newlib --enable-languages=c,c++ --disable-multilib -v
Thread model: single
gcc version 5.3.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-Wall' '-Wextra' '-fno-strict-aliasing' '-fwrapv'
'-fno-aggressive-loop-optimizations' '-mmcu=msp430fr5969' '-o' 'bug.elf'
'-save-temps'
 /home/awygle/toolchain/install/libexec/gcc/msp430-elf/5.3.0/cc1 -E -quiet -v
bug.c -mmcu=msp430fr5969 -Wall -Wextra -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -fpch-preprocess -o bug.i
ignoring nonexistent directory
"/home/awygle/toolchain/install/lib/gcc/msp430-elf/5.3.0/../../../../msp430-elf/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /home/awygle/toolchain/install/lib/gcc/msp430-elf/5.3.0/include
 /home/awygle/toolchain/install/lib/gcc/msp430-elf/5.3.0/include-fixed

/home/awygle/toolchain/install/lib/gcc/msp430-elf/5.3.0/../../../../msp430-elf/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-Wall' '-Wextra' '-fno-strict-aliasing' '-fwrapv'
'-fno-aggressive-loop-optimizations' '-mmcu=msp430fr5969' '-o' 'bug.elf'
'-save-temps'
 /home/awygle/toolchain/install/libexec/gcc/msp430-elf/5.3.0/cc1 -fpreprocessed
bug.i -quiet -dumpbase bug.c -mmcu=msp430fr5969 -auxbase bug -Wall -Wextra
-version -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -o
bug.s
GNU C11 (GCC) version 5.3.0 (msp430-elf)
compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version
3.1.2-p11, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (GCC) version 5.3.0 (msp430-elf)
compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version
3.1.2-p11, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 4cbf41f67559bdb236a322a0045966e6
COLLECT_GCC_OPTIONS='-v' '-Wall' '-Wextra' '-fno-strict-aliasing' '-fwrapv'
'-fno-aggressive-loop-optimizations' '-mmcu=msp430fr5969' '-o' 'bug.elf'
'-save-temps'

/home/awygle/toolchain/install/lib/gcc/msp430-elf/5.3.0/../../../../msp430-elf/bin/as
--traditional-format -mP -mmcu=msp430fr5969 -md -o bug.o bug.s
COMPILER_PATH=/home/awygle/toolchain/install/libexec/gcc/msp430-elf/5.3.0/:/home/awygle/toolchain/install/libexec/gcc/msp430-elf/5.3.0/:/home/awygle/toolchain/install/libexec/gcc/msp430-elf/:/home/awygle/toolchain/install/lib/gcc/msp430-elf/5.3.0/:/home/awygle/toolchain/install/lib/gcc/msp430-elf/:/home/awygle/toolchain/install/lib/gcc/msp430-elf/5.3.0/../../../../msp430-elf/bin/
LIBRARY_PATH=/home/awygle/toolchain/install/lib/gcc/msp430-elf/5.3.0/:/home/awygle/toolchain/install/lib/gcc/msp430-elf/5.3.0/../../../../msp430-elf/lib/
COLLECT_GCC_OPTIONS='-v' '-Wall' '-Wextra' '-fno-strict-aliasing' '-fwrapv'
'-fno-aggressive-loop-optimizations' '-mmcu=msp430fr5969' '-o' 'bug.elf'
'-save-temps'
 /home/awygle/toolchain/install/libexec/gcc/msp430-elf/5.3.0/collect2 -plugin
/home/awygle/toolchain/install/libexec/gcc/msp430-elf/5.3.0/liblto_plugin.so
-plugin-opt=/home/awygle/toolchain/install/libexec/gcc/msp430-elf/5.3.0/lto-wrapper
-plugin-opt=-fresolution=bug.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lcrt -plugin-opt=-pass-through=-lgcc -o bug.elf
/home/awygle/toolchain/install/lib/gcc/msp430-elf/5.3.0/../

[Bug tree-optimization/70043] [6 Regression] The compiler hangs in a fortran test-case with -Ofast -g -march=haswell

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Jakub Jelinek  ---
Fixed.

[Bug lto/70044] [5/6 Regression] -flto turns on -fomit-frame-pointer

[rguenther at suse dot de]

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

--- Comment #2 from rguenther at suse dot de  ---
On Thu, 3 Mar 2016, ktkachov at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70044
> 
> ktkachov at gcc dot gnu.org changed:
> 
>What|Removed |Added
> 
>  CC||rguenth at gcc dot gnu.org
> 
> --- Comment #1 from ktkachov at gcc dot gnu.org ---
> Doesn't seem to happen on arm or x86_64.
> Who is responsible for recomputing the values of the optimisation options i.e.
> flag_omit_frame_pointer during LTO?

The backend is, LTO has the usual options langhooks and toplev calls
the corresponding target variants.

NOTE that -fomit-frame-pointer will appear in optimize attributes now
so setting/unsetting is expected to work.

[Bug c/70060] array initialization adds to executable size

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
It is.  If you omit it the zero initialization is done by emitting bigarr into
.bss, with the init you cause it to be emitted in .rodata.

[Bug rtl-optimization/70061] [6 Regression] ICE: SIGSEGV in delete_insn_chain() with unused label

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug target/70064] New: wrong code with custom flags and quite big testcase @ i686

[zsojka at seznam dot cz]

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

Bug ID: 70064
   Summary: wrong code with custom flags and quite big testcase @
i686
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
Target: i686-pc-linux-gnu

Created attachment 37854
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37854&action=edit
autoreduced testcase

The testcase is likely very fragile due to the set of compiler flags and quite
big testcase itself. Neither seems to be easily reducible.

Output:
$ i686-pc-linux-gnu-gcc -Os -march=athlon-tbird -fPIC -fsched-pressure
-fsched-stalled-insns -fschedule-insns -fno-tree-reassoc
-momit-leaf-frame-pointer -mpclmul -mred-zone -mno-stv -fira-algorithm=priority
--param=max-sched-ready-insns=0 testcase.c -Wno-psabi
$ ./a.out 
318f9e133048
Aborted
$ i686-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-i686/bin/i686-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-233911-checking-yes-rtl-df-nographite-i686/bin/../libexec/gcc/i686-pc-linux-gnu/6.0.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=i686-pc-linux-gnu --with-ld=/usr/bin/i686-pc-linux-gnu-ld
--with-as=/usr/bin/i686-pc-linux-gnu-as --with-sysroot=/usr/i686-pc-linux-gnu
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-233911-checking-yes-rtl-df-nographite-i686
Thread model: posix
gcc version 6.0.0 20160302 (experimental) (GCC)

[Bug target/70063] msp430 stack corruption for naked functions

[awygle at gmail dot com]

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

--- Comment #1 from Andrew Wygle  ---
A quick correction - as my example above accidentally shows, compiling with
optimizations isn't a guarantee of avoiding this problem, it just sometimes
helps if the arguments are unused, as the optimizer will remove the attempt to
save them.

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[alalaw01 at gcc dot gnu.org]

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

--- Comment #84 from alalaw01 at gcc dot gnu.org ---
Bah. Do you normally use -fno-aggressive-loop-optimizations? With
-funknown-commons, did you try with/out aggressive loop opts?
Powerpc{,64}{be,le} ?

The unknown-commons testcase I included in that patch looks to pass on
powerpc64le-unknown-linux-gnu.

Does HJ Lu's spec source-patching work on powerpc following r232559?

I am not a lawyer...but I don't think the SPEC2006 license allows me to upload
onto the GCC Compile Farm and runspec. So if you could narrow down to an object
file that's broken with a recent compiler and -funknown-commons, with the rest
compiled with a gcc prior to r232508, that'd be very helpful - then I could see
what assembly I'm changing (and what expressions equal_mem_array_ref is falsely
declaring equivalent)...?

[Bug target/70064] [6 Regression] wrong code with custom flags and quite big testcase @ i686

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-03
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|wrong code with custom  |[6 Regression] wrong code
   |flags and quite big |with custom flags and quite
   |testcase @ i686 |big testcase @ i686
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r233267.  But, as that is a tree change and it clearly depends on
lots of RTL flags, it just uncovered a latent bug.

[Bug c/70060] array initialization adds to executable size

[stsp at users dot sourceforge.net]

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

--- Comment #2 from Stas Sergeev  ---
The question is not what happens now, but rather
can't it be done differently?
Is there any reason why gcc can't but it into .bss
anyway, and initialize from the startup code?
I realize this is not a bug but a feature request,
can it be treated as such?

[Bug target/69979] ARM naked function attribute not handling structs bigger than 32 bits correctly

[andre.simoesdiasvieira at arm dot com]

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

--- Comment #1 from Andre Vieira  ---
I believe expand_function_start is responsible for this code. When it calls
assign_parms it will generate RTL to copy the incoming struct parameter onto
the stack.

[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops

[winter-...@bfw-online.de]

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

--- Comment #11 from Leon Winter  ---
Created attachment 37855
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37855&action=edit
Current test case

gcc version 4.9.3

$ gcc -std=gnu99 -O1 -Wall -Wextra -o foo main.c 
$ gcc -std=gnu99 -O2 -Wall -Wextra -o foo main.c 
main.c: In function 'foo':
main.c:19:3: warning: 'buf' may be used uninitialized in this function
[-Wmaybe-uninitialized]
   return buf;
   ^
$ gcc -std=gnu99 -O3 -Wall -Wextra -o foo main.c

gcc version 5.3.1 20160205 (Debian 5.3.1-8bfw1)

$ gcc-5 -O1 -Wall -Wextra -o foo main.c -std=gnu99
main.c: In function 'foo':
main.c:19:10: warning: 'buf' may be used uninitialized in this function
[-Wmaybe-uninitialized]
   return buf;
  ^
$ gcc-5 -O2 -Wall -Wextra -o foo main.c -std=gnu99
main.c: In function 'foo':
main.c:19:10: warning: 'buf' may be used uninitialized in this function
[-Wmaybe-uninitialized]
   return buf;
  ^
$ gcc-5 -O3 -Wall -Wextra -o foo main.c -std=gnu99
main.c: In function 'foo':
main.c:19:10: warning: 'buf' may be used uninitialized in this function
[-Wmaybe-uninitialized]
   return buf;
  ^

[Bug target/70063] msp430 stack corruption for naked functions

[andre.simoesdiasvieira at arm dot com]

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

Andre Vieira  changed:

   What|Removed |Added

 CC||andre.simoesdiasvieira@arm.
   ||com

--- Comment #2 from Andre Vieira  ---
I believe pr69979 reports a related issue with arm targets.

[Bug c/69824] [4.9/5/6 Regression] internal compiler error in unshare_body

[bernds at gcc dot gnu.org]

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

--- Comment #5 from Bernd Schmidt  ---
I've been playing with that for a while. If the continue is replaced with
gcc_unreachable, we find parm-impl-decl-[13].c testcases that trigger it. I
think your patch is probably fine, but I'm not 100% sure about the following:

int
h2 (int (*p)[sizeof(j())])
{
  return j();
}

int j () { return 2; }

Should we be getting one implicit declaration warning with -Wall, or two (i.e.,
should j go out of scope at the end of the arg list)? We get only one.

An alternative patch that does not even put FUNCTION_DECLs in the list would be

Index: c-decl.c
===
--- c-decl.c(revision 233451)
+++ c-decl.c(working copy)
@@ -7050,25 +7050,28 @@ get_parm_info (bool ellipsis, tree expr)
  vec_safe_push (tags, tag);
  break;

+   case FUNCTION_DECL:
+ /*  FUNCTION_DECLs appear when there is an implicit function
+ declaration in the parameter list.  */
+ gcc_assert (b->nested);
+ goto set_shadowed;
+
case CONST_DECL:
case TYPE_DECL:
-   case FUNCTION_DECL:
  /* CONST_DECLs appear here when we have an embedded enum,
 and TYPE_DECLs appear here when we have an embedded struct
 or union.  No warnings for this - we already warned about the
-type itself.  FUNCTION_DECLs appear when there is an implicit
-function declaration in the parameter list.  */
+type itself.  */

  /* When we reinsert this decl in the function body, we need
 to reconstruct whether it was marked as nested.  */
- gcc_assert (TREE_CODE (decl) == FUNCTION_DECL
- ? b->nested
- : !b->nested);
+ gcc_assert (!b->nested);
  DECL_CHAIN (decl) = others;
  others = decl;
  /* fall through */

case ERROR_MARK:
+   set_shadowed:
  /* error_mark_node appears here when we have an undeclared
 variable.  Just throw it away.  */
  if (b->id)

[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops

[winter-...@bfw-online.de]

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

--- Comment #12 from Leon Winter  ---
> Are you saying that GCC 4.9 does not warn? That would be surprising and a
> regression. If you could find the revision that started warning, that would
> be helpful.

Funny you would ask, it turns out that only in -O2 it does warn. However my
test case is a simplified version of real project for which no warning is
generated (even in -O2) which fails to build with GCC 5 (due to -Werror). I
will try to come up with a test case more like the actual code and which would
then also compile just fine (without warnings) using gcc-4.9.

Your minimal testcase triggers the warning also for gcc-4.9 on every
optimization level.

[Bug c++/70065] New: Add a new option to suppress a warnings about operators priority

[beaux_monde at tut dot by]

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

Bug ID: 70065
   Summary: Add a new option to suppress a warnings about
operators priority
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: beaux_monde at tut dot by
  Target Milestone: ---

Created attachment 37856
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37856&action=edit
The patch

Hello.
I have a patch which adds an option to suppress warnings about operators'
precedence. For example for this code

bool a, b, c;

// Something...

if(a && b || c)
{
  // Do something...
}

g++ will print the "Suggest parenthesis around a && b" warning. But the &&
operator has a higher priority, so parenthesis here needed to ensure that all
is OK.

[Bug c++/70065] Add a new option to suppress a warnings about operators priority

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Patches should be sent to gcc-patc...@gcc.gnu.org for review. Please avoid
unrelated whitespace changes in your patch. The test "if (warn_precedence)"
seems redundant with the use of OPT_Wprecedence.

[Bug c++/70065] Add a new option to suppress a warnings about operators priority

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Wait, so what is wrong with this?
warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
You can use -Wno-parentheses to disable that warning.

[Bug c++/70065] Add a new option to suppress a warnings about operators priority

[beaux_monde at tut dot by]

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

--- Comment #3 from Serge Roussak  ---
(In reply to Marc Glisse from comment #1)
> The test "if (warn_precedence)"
> seems redundant with the use of OPT_Wprecedence.

I see all except this mentioned: what do you mean?

[Bug c++/70065] Add a new option to suppress a warnings about operators priority

[beaux_monde at tut dot by]

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

--- Comment #4 from Serge Roussak  ---
(In reply to Marek Polacek from comment #2)
> Wait, so what is wrong with this?
> warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
> You can use -Wno-parentheses to disable that warning.

Yes, but -Wno-parentheses disables something else in addition to that thing
related with the operators' priority.

[Bug c++/70065] Add a new option to suppress a warnings about operators priority

[beaux_monde at tut dot by]

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

--- Comment #5 from Serge Roussak  ---
(In reply to Marek Polacek from comment #2)
> Wait, so what is wrong with this?
> warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
> You can use -Wno-parentheses to disable that warning.

ADD: ie my patch is a subset of the -Wno-parentheses.

[Bug target/70044] [5/6 Regression] -flto turns on -fomit-frame-pointer

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-03-03
  Component|lto |target
   Target Milestone|--- |5.4
 Ever confirmed|0   |1
  Known to fail||5.3.1, 6.0

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Thanks, I can see the bug in aarch64_override_options_after_change_1.
The logic with -momit-leaf-frame-pointer gets tangled up with
-fomit-frame-pointer

[Bug c++/68530] [C++14] sorry, unimplemented: unexpected AST of kind loop_expr

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code,  |ice-on-invalid-code
   |rejects-valid   |
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

[amodra at gmail dot com]

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

--- Comment #12 from Alan Modra  ---
Created attachment 37857
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37857&action=edit
workaround patch

Given the problems identified with notes (and of course the notes are what
drives reg_equiv_init passed on to reload), one simple fix is to run
delete_trivially_dead_insns early in ira.  I've left the later call in, but
that might be better moved into the optimize && rebuild_p block.

[Bug target/68802] seg fault when non-main thread calls std::current_exception ARMv7-A

[philip.deegan at gmail dot com]

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

--- Comment #3 from Philip Deegan  ---
Anything I can do to help?

[Bug c/69798] ICE on invalid code on x86_64-linux-gnu in c_parser_braced_init, at c/c-parser.c:4338

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Patch posted
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00251.html
we'll see.

[Bug c++/68206] ICE: unimplemented: unexpected AST of kind loop_expr in potential_constant_expression_1

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/70021] [6 Regression] Test miscompiled with -O3 option for -march=core-avx2.

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar  3 14:32:15 2016
New Revision: 233940

URL: https://gcc.gnu.org/viewcvs?rev=233940&root=gcc&view=rev
Log:
PR target/70021
* tree-vect-stmts.c (vect_mark_relevant): Remove USED_IN_PATTERN
argument, if STMT_VINFO_IN_PATTERN_P (stmt_info), always mark
the pattern no matter if it is used just by non-pattern, pattern
or mix thereof.
(process_use, vect_mark_stmts_to_be_vectorized): Adjust callers.
* tree-vect-patterns.c (vect_recog_vector_vector_shift_pattern): If
oprnd1 def_stmt is in pattern, don't look through it.

* gcc.dg/vect/pr70021.c: New test.
* gcc.target/i386/pr70021.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr70021.c
trunk/gcc/testsuite/gcc.target/i386/pr70021.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-patterns.c
trunk/gcc/tree-vect-stmts.c

[Bug c++/64696] [C++14] braced-init-list does not respect designated initializer

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-03
 CC||jason at gcc dot gnu.org
Summary|[C++14] braced-init-list|[C++14] braced-init-list
   |does not cause expected |does not respect designated
   |aggregate initialization|initializer
 Ever confirmed|0   |1

--- Comment #1 from Jason Merrill  ---
G++ implements issue 1467, so the only bug is with the designated initializer,
which is an extension for C compatibility.

[Bug target/70021] [6 Regression] Test miscompiled with -O3 option for -march=core-avx2.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
Fixed.

[Bug c++/69059] [C++14] Invalid rejection of expression as not-a-constant-expression

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-03-03
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/68074] [C++14] Complex ConstExpr Evaluation

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-03-03
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c/68187] [6 Regression] Poor error message from -Wmisleading-indentation on glibc's ../stdlib/strtol_l.c

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
Candidate patches posted:
  https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00260.html
  https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00261.html

[Bug tree-optimization/70032] tree-ssa-tail-merge engine replacement

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> Note the very first "cleanup" would be to rip out all value numbering use
> from
> the current implementation and make the pass properly separate.  Now that
> FRE/PRE do full copy/constant propagation valueization shouldn't be necessary
> any more.  And the special VN hacks for tail-merging could be removed
> obviously.

I did an experiment and implemented vn_valueize as the identity function in
tree-ssa-tail-merge.c.

The result with my tail-merge test script is:
...
FAIL: gcc.dg/pr51879.c scan-tree-dump-times pre "bar \\(" 1
FAIL: gcc.dg/pr51879-3.c scan-tree-dump-times pre "bar \\(" 1
FAIL: gcc.dg/pr43864-3.c scan-tree-dump-times pre "(?n)_.*\\+.*_" 1
FAIL: gcc.dg/pr43864-3.c scan-tree-dump-times pre "if " 0
FAIL: gcc.dg/pr43864-4.c scan-tree-dump-times pre "(?n)_.*-.*_" 2
FAIL: gcc.dg/pr43864-4.c scan-tree-dump-times pre "(?n)_.*\\+.*_" 1
FAIL: gcc.dg/pr43864-4.c scan-tree-dump-times pre "if " 0
FAIL: gcc.dg/pr51879-6.c scan-tree-dump-times pre "bar \\(" 1
FAIL: gcc.dg/pr43864-2.c scan-tree-dump-times pre "(?n)_.*\\+.*_" 1
FAIL: gcc.dg/pr43864-2.c scan-tree-dump-times pre "if " 0
FAIL: gcc.dg/pr51879-16.c scan-tree-dump-times pre "foo \\(" 1
FAIL: gcc.dg/pr51879-16.c scan-tree-dump-times pre "foo2 \\(" 1
FAIL: gcc.dg/pr51879-2.c scan-tree-dump-times pre "bar \\(" 1
FAIL: gcc.dg/pr51879-2.c scan-tree-dump-times pre "baz \\(" 1
FAIL: gcc.dg/pr51879-18.c scan-tree-dump-times pre "foo \\(" 1
...

Looking at the first failure, gcc.dg/pr51879.c, the representation at optimized
looks like:
...
foo (int y)
{
  int a;

  :
  if (y_3(D) == 6)
goto ;
  else
goto ;

  :
  # .MEM_5 = VDEF <.MEM_4(D)>
  a_6 = bar (7);
  goto ;

  :
  # .MEM_7 = VDEF <.MEM_4(D)>
  a_8 = bar (7);

  :
  # a_1 = PHI 
  # .MEM_2 = PHI <.MEM_5(3), .MEM_7(4)>
  # .MEM_9 = VDEF <.MEM_2>
  baz (a_1); [tail call]
  # VUSE <.MEM_9>
  return;

}
...

Tail-merge can't know that a_6 and a_8 are equally valued unless it uses value
numbering, and no other optimization seems to merge the two calls by moving
them up to bb2 (and in the general case, that's not necessary possible either).

Concluding, atm value numbering seems to be necessary at least for this kind of
examples.

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[seurer at linux dot vnet.ibm.com]

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

--- Comment #85 from Bill Seurer  ---
I just grabbed a fresh copy of the gcc source, applied the patch, built it,
fixed up the options for 416.gamess, and when I ran it it worked!  I should
have done that yesterday.

[Bug testsuite/70055] gcc.target/i386/chkp-stropt-16.c is incompatible with glibc 2.23

[wdijkstr at arm dot com]

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

Wilco  changed:

   What|Removed |Added

 CC||wdijkstr at arm dot com

--- Comment #2 from Wilco  ---
(In reply to Jakub Jelinek from comment #1)
> These glibc inlines are just wrong, they should trust the compiler doing the
> right thing at least for contemporary versions.
> 05a910f7b420c2b831f35ba90e61c80f001c0606 should be IMHO reverted, it should
> be approached at the compiler side if the ARM folks see any performance
> issues with what is generated.

It's not about the generated code, it's about whether one calls memcpy or
mempcpy in the case where GCC doesn't inline it. Few targets support an
assembler mempcpy implementation, so by default the best option is defer to
memcpy. Targets can add an optimized mempcpy and define
_HAVE_STRING_ARCH_mempcpy to get mempcpy (as x86 does).

Is there a mechanism by which GCC is told accurately whether the library it
targets supports an optimized mempcpy?

[Bug target/70062] ICE: in decide_alg, at config/i386/i386.c:26173 with -mmemcpy-strategy=libcall

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-03
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
This ICEs since the -mmemcpy-strategy option has been added in r201645, so
technically not a regression.

[Bug testsuite/70055] gcc.target/i386/chkp-stropt-16.c is incompatible with glibc 2.23

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
If some arch in glibc implements memcpy.S and does not implement mempcpy.S,
then obviously the right fix is to add mempcpy.S for that arch, usually it is
just a matter of #include memcpy.S with some define USE_AS_MEMPCPY, and change
a couple of instructions in the assembly.  You don't need to remember the
original value of dest, usually you have the address to which you store bytes
in some register, so it is just a matter of copying it to the return register.

[Bug testsuite/70055] gcc.target/i386/chkp-stropt-16.c is incompatible with glibc 2.23

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Note the choice of this in a header file is obviously wrong, if you at some
point fix this up, then apps will still call memcpy rather than mempcpy, even
when the latter is more efficient (because it doesn't have to save the length
value in some location where it survives across the call).
Note if you don't use the result of mempcpy, gcc is able to optimize it into
memcpy, and tons of other optimizations.

[Bug rtl-optimization/70061] [6 Regression] ICE: SIGSEGV in delete_insn_chain() with unused label

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-03
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r226901, most likely just a formerly latent issue.

[Bug c/70060] array initialization adds to executable size

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
If you want it to be initialized at runtime, do that yourself.
The compiler can't do that, you could e.g. access bigarr from another
compilation unit before the constructors of this CU are executed etc.

[Bug rtl-optimization/70061] [6 Regression] ICE: SIGSEGV in delete_insn_chain() with unused label

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #2 from Jeffrey A. Law  ---
Yea, I doubt r226901 is the root cause.  We're trying to merge two blocks. 
Note how the block note occurs after the first insn associated with bb3.  Not
sure if that's the cause, but it looks odd:


(note 1 0 13 NOTE_INSN_DELETED)

(note 13 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(note 2 13 14 2 NOTE_INSN_FUNCTION_BEG)

(insn 14 2 16 3 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int 32 [0x20])))
(clobber (reg:CC 17 flags))
]) -1
 (expr_list:REG_ARGS_SIZE (const_int 0 [0])
(nil)))

(note 16 14 15 3 [bb 3] NOTE_INSN_BASIC_BLOCK)

[Bug target/70062] ICE: in decide_alg, at config/i386/i386.c:26173 with -mmemcpy-strategy=libcall

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #1)
> This ICEs since the -mmemcpy-strategy option has been added in r201645, so
> technically not a regression.

IMO, it looks like the fix for PR 69888 has to be refined a bit.

[Bug target/70062] ICE: in decide_alg, at config/i386/i386.c:26173 with -mmemcpy-strategy=libcall

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
I'll look at it then.

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[seurer at linux dot vnet.ibm.com]

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

--- Comment #86 from Bill Seurer  ---
I also tried it on a power8 BE machine and it worked fine there, too.

[Bug c/70060] array initialization adds to executable size

[stsp at users dot sourceforge.net]

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

--- Comment #4 from Stas Sergeev  ---
(In reply to Jakub Jelinek from comment #3)
> If you want it to be initialized at runtime, do that yourself.
> The compiler can't do that, you could e.g. access bigarr from another
> compilation unit before the constructors of this CU are executed etc.
OK, but in my example only the first element
of an array needs an initialization. Wasn't it
possible in that case to reserve just 1 page in
rodata and not waste the megabytes of space for all zeros?
But yes, I understand having sparse rodata would
be a difficult task to achieve...

[Bug target/70062] ICE: in decide_alg, at config/i386/i386.c:26173 with -mmemcpy-strategy=libcall

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 37858
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37858&action=edit
gcc6-pr70062.patch

Untested fix.

[Bug rtl-optimization/69904] [6 Regression] shrink-wrapping creates weird atomic compare exchange loop on arm

[ktkachov at gcc dot gnu.org]

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

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Mar  3 17:25:43 2016
New Revision: 233941

URL: https://gcc.gnu.org/viewcvs?rev=233941&root=gcc&view=rev
Log:
[ARM] PR rtl-optimization/69904: Disallow copying/duplicating of load-exclusive
operations

PR rtl-optimization/69904
* config/arm/arm.c (arm_cannot_copy_insn_p):
Return true for load-exclusive instructions.

* gcc.target/arm/pr69904.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/arm/pr69904.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/69904] [6 Regression] shrink-wrapping creates weird atomic compare exchange loop on arm

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from ktkachov at gcc dot gnu.org ---
Fixed.

[Bug c++/70066] New: alignas imposes the wrong limit on data members

[msebor at gcc dot gnu.org]

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

Bug ID: 70066
   Summary: alignas imposes the wrong limit on data members
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

On the x86_64-*-linux-gnu target, G++ enforces 128 bytes as the maximum
alignment for data members, even though GCC accepts much more restrictive
alignments.  For example, in the program below the struct is aligned on a
128-byte boundary in C++ but on a 256-byte boundary in C.

The C++ restriction is enforced by the
check_cxx_fundamental_alignment_constraints() function defined in
c-family/c-common.c.  The function uses the locally defined macro
MAX_TARGET_FIELD_ALIGNMENT as the upper bound on the alignment:

  #ifdef BIGGEST_FIELD_ALIGNMENT
  #define MAX_TARGET_FIELD_ALIGNMENT BIGGEST_FIELD_ALIGNMENT
  #else
  #define MAX_TARGET_FIELD_ALIGNMENT BIGGEST_ALIGNMENT
  #endif

The macro BIGGEST_FIELD_ALIGNMENT is not defined in this file, so the function
falls back on BIGGEST_ALIGNMENT which is 128 (the __BIGGEST_ALIGNMENT__ user
macro is defined to 16).

The BIGGEST_FIELD_ALIGNMENT macro is defined in config/i386/i386.h with the
following comment:

  /* ??? Blah -- this macro is used directly by libobjc.  Since it
 supports no vector modes, cut out the complexity and fall back
 on BIGGEST_FIELD_ALIGNMENT.  */
  #ifdef IN_TARGET_LIBS
  #ifdef __x86_64__
  #define BIGGEST_FIELD_ALIGNMENT 128
  ...

which happens to be the same as BIGGEST_ALIGNMENT.  However, both alignments
are in *bits* not *bytes* as assumed by the C++ functions, so G++ not only
enforces a more restrictive limit than G++, it also uses the wrong units.

In contrast, the far more liberal alignment limit enforced by the C front end
in the check_user_alignment() function uses the following test, allowing for
alignments of as great as 2^28 bytes:

  else if (i >= HOST_BITS_PER_INT - BITS_PER_UNIT_LOG)
{
  error ("requested alignment is too large");
  return -1;


$ (set -x; cat t.c; cc="/build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc"; for
lang in c c++; do $cc -S -Wall -Wextra -Wpedantic -x$lang t.c; done)
+ cat t.c
#if !__cplusplus
#  define alignas _Alignas
#endif

struct S { alignas (256) int i; };
+ cc='/build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc'
+ for lang in c c++
+ /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -S -Wall -Wextra -Wpedantic
-xc t.c
+ for lang in c c++
+ /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -S -Wall -Wextra -Wpedantic
-xc++ t.c
t.c:5:30: warning: requested alignment 256 is larger than 128 [-Wattributes]
 struct S { alignas (256) int i; };
  ^

[Bug c++/70066] alignas imposes the wrong limit on data members

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #1 from Martin Sebor  ---
The behavior looks the same in all supported GCC version going all the way back
to 4.9.3.

[Bug rtl-optimization/56069] [4.9/5/6 Regression] RA pessimization

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |7.0

--- Comment #14 from Bernd Schmidt  ---
Patch and discussion here.
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00182.html

Patch approved for gcc-7.

[Bug c++/70066] alignas imposes the wrong limit on data members

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
> The BIGGEST_FIELD_ALIGNMENT macro is defined in config/i386/i386.h with the
> following comment:
...
>  #ifdef IN_TARGET_LIBS

This definition version is only ever used in libobjc and libgcc.

[Bug c++/70066] alignas imposes the wrong limit on data members

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
This is the definition which matters:

/* Minimum size in bits of the largest boundary to which any
   and all fundamental data types supported by the hardware
   might need to be aligned. No data type wants to be aligned
   rounder than this.

   Pentium+ prefers DFmode values to be aligned to 64 bit boundary
   and Pentium Pro XFmode values at 128 bit boundaries.

   When increasing the maximum, also update
   TARGET_ABSOLUTE_BIGGEST_ALIGNMENT.  */

#define BIGGEST_ALIGNMENT \
  (TARGET_IAMCU ? 32 : (TARGET_AVX512F ? 512 : (TARGET_AVX ? 256 : 128)))

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[alalaw01 at gcc dot gnu.org]

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

--- Comment #87 from alalaw01 at gcc dot gnu.org ---
Great, many thanks for the tests, I was worried if we had hit another distinct
issue. (Of course this would be better on gcc-patches!)

[Bug testsuite/70055] gcc.target/i386/chkp-stropt-16.c is incompatible with glibc 2.23

[wdijkstr at arm dot com]

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

--- Comment #5 from Wilco  ---
(In reply to Jakub Jelinek from comment #3)
> If some arch in glibc implements memcpy.S and does not implement mempcpy.S,
> then obviously the right fix is to add mempcpy.S for that arch, usually it
> is just a matter of #include memcpy.S with some define USE_AS_MEMPCPY, and
> change a couple of instructions in the assembly.  You don't need to remember
> the original value of dest, usually you have the address to which you store
> bytes in some register, so it is just a matter of copying it to the return
> register.

We had a long discussion on this at the time. Very few targets have implemented
mempcpy.S so it would be a lot of effort to do so. Sharing a single
implementation of memcpy is typically not possible without slowing down memcpy
(which is more important), and thus you end up with 2 separate implementations
which creates unnecessary cache pollution.

So overall I believe the best option for most targets is to defer to memcpy
with an extra add instruction to compute the end. We could do that in GCC
rather than in the GLIBC headers, but then it would be harder to actually call
mempcpy in the case that a target supports an optimized implementation.

[Bug testsuite/70055] gcc.target/i386/chkp-stropt-16.c is incompatible with glibc 2.23

[wdijkstr at arm dot com]

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

--- Comment #6 from Wilco  ---
(In reply to Jakub Jelinek from comment #4)
> Note the choice of this in a header file is obviously wrong, if you at some
> point fix this up, then apps will still call memcpy rather than mempcpy,
> even when the latter is more efficient (because it doesn't have to save the
> length value in some location where it survives across the call).
> Note if you don't use the result of mempcpy, gcc is able to optimize it into
> memcpy, and tons of other optimizations.

It's highly unlikely that calling mempcpy would ever provide a performance
gain.

[Bug c++/70066] alignas imposes the wrong limit on data members

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-*-*

--- Comment #4 from Andrew Pinski  ---
@defmac BIGGEST_ALIGNMENT
Biggest alignment that any data type can require on this machine, in
bits.  Note that this is not the biggest alignment that is supported,
just the biggest alignment that, when violated, may cause a fault.
@end defmac


@deftypevr {Target Hook} HOST_WIDE_INT TARGET_ABSOLUTE_BIGGEST_ALIGNMENT
If defined, this target hook specifies the absolute biggest alignment
that a type or variable can have on this machine, otherwise,
@code{BIGGEST_ALIGNMENT} is used.
@end deftypevr



#undef TARGET_ABSOLUTE_BIGGEST_ALIGNMENT
#define TARGET_ABSOLUTE_BIGGEST_ALIGNMENT 512




I suspect there is a target issue here or the front-end should be using
TARGET_ABSOLUTE_BIGGEST_ALIGNMENT instead.  The back-end is confused about byte
vs bit here and even the comment before the definition of BIGGEST_ALIGNMENT is
incorrect.

[Bug testsuite/70055] gcc.target/i386/chkp-stropt-16.c is incompatible with glibc 2.23

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to Wilco from comment #6)
> (In reply to Jakub Jelinek from comment #4)
> > Note the choice of this in a header file is obviously wrong, if you at some
> > point fix this up, then apps will still call memcpy rather than mempcpy,
> > even when the latter is more efficient (because it doesn't have to save the
> > length value in some location where it survives across the call).
> > Note if you don't use the result of mempcpy, gcc is able to optimize it into
> > memcpy, and tons of other optimizations.
> 
> It's highly unlikely that calling mempcpy would ever provide a performance
> gain.

There is no reason why the memcpy vs. mempcpy calls should not be the same
speed (+/- a cycle or 3, but it can actually be that mempcpy may be faster).
The gain is on the caller side, mempcpy allows for more compact and faster code
in quite common case.
By sticking the bogus __mempcpy_inline you pessimize apps until they are
recompiled, no matter whether glibc is fixed in the mean time or not.

[Bug middle-end/57955] [4.9/5/6 Regression] Uniquization of constants reduces alignment of initializers

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
So, does anybody plan to change CONSTANT_ALIGNMENT for rs6000?  If not, I think
we should close this bug, because changing the generic code back is
undesirable.

[Bug c++/65061] [4.9 Regression] Issue with using declaration and member class template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed.

[Bug c++/65061] [4.9 Regression] Issue with using declaration and member class template

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Thu Mar  3 18:43:01 2016
New Revision: 233942

URL: https://gcc.gnu.org/viewcvs?rev=233942&root=gcc&view=rev
Log:
PR c++/65061
* parser.c (cp_parser_template_name): Call strip_using_decl.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/inherit/using8.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/parser.c

[Bug c++/67257] [5 regression] Internal compiler error in retrieve_specialization

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|5.4 |6.0

--- Comment #6 from Jason Merrill  ---
Fixed for GCC 6, not backporting fix for invalid code.

[Bug c++/69257] g++ ICE in "create_tmp_var" on invalid inline-asm

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #6 from Jason Merrill  ---
Fixed for GCC 6.

[Bug middle-end/57955] [4.9/5/6 Regression] Uniquization of constants reduces alignment of initializers

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #14 from David Edelsohn  ---
I'll discuss this with Bill.  Tuning CONSTANT_ALIGNMENT probably would be
beneficial.

[Bug c++/70066] alignas imposes the wrong limit on data members

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||58601

--- Comment #5 from Martin Sebor  ---
I should note that attribute aligned is accepted with larger values than 128,
so the problem is limited to enforcing the limit requested via the C++ 11
alignas operator.  As evident from the number of bugs linked to bug 58601,
alignas and its interaction with attribute aligned suffers from many problems
in G++.

While the x86_64 back end might be confused about some of the alignment macros
I think the underlying problem here is thec
heck_cxx_fundamental_alignment_constraints() function and its use of the
macros.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58601
[Bug 58601] [meta-bug] alignas

[Bug testsuite/70055] gcc.target/i386/chkp-stropt-16.c is incompatible with glibc 2.23

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  ---
Inlining mempcpy uses a callee-saved register:


hjl@gnu-6 tmp]$ cat m.c 
extern char *src, *dst;

char *
foo (unsigned long i)
{
  return __builtin_mempcpy (dst, src, i);
}

char *
bar (unsigned long i)
{
  return __builtin_memcpy (dst, src, i) + i;
}
[hjl@gnu-6 tmp]$ gcc -S -O2 m.c
[hjl@gnu-6 tmp]$ cat m.s
.file   "m.c"
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movq%rdi, %rdx
movqsrc(%rip), %rsi
movqdst(%rip), %rdi
jmp mempcpy
.cfi_endproc
.LFE0:
.size   foo, .-foo
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.section.text.unlikely
.LCOLDB1:
.text
.LHOTB1:
.p2align 4,,15
.globl  bar
.type   bar, @function
bar:
.LFB1:
.cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq%rdi, %rdx
movq%rdi, %rbx
movqsrc(%rip), %rsi
movqdst(%rip), %rdi
callmemcpy
addq%rbx, %rax
popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE1:
.size   bar, .-bar
.section.text.unlikely
.LCOLDE1:
.text
.LHOTE1:
.ident  "GCC: (GNU) 5.3.1 20160212 (Red Hat 5.3.1-4)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 tmp]$ 

Not inlining mempcpy is preferred.

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

[orion at cora dot nwra.com]

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

Bug ID: 70067
   Summary: internal compiler error: in strip_typedefs, at
cp/tree.c:1466
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: orion at cora dot nwra.com
  Target Milestone: ---

Trying to build 3Depict in Fedora Rawhide with gcc 6.0.0-0.14.fc25:

g++ -DHAVE_CONFIG_H -I. -I..-O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic
-I/usr/include/freetype2  -I/usr/lib64/wx/include/gtk3-unicode-3.0
-I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ 
-I/usr/include  -I/usr/include/libxml2  -fopenmp -D_GLIBCXX_PARALLEL  -pipe 
-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -c -o
backend/3Depict-filter.o `test -f 'backend/filter.cpp' || echo
'./'`backend/filter.cpp
In file included from ./common/voxels.h:39:0,
 from ./gl/isoSurface.h:23,
 from ./gl/drawables.h:33,
 from ./backend/filter.h:34,
 from ./backend/plot.h:23,
 from gui/dialogs/rangeEditDialog.h:22,
 from gui/dialogs/rangeEditDialog.cpp:19:
/usr/include/vigra/accumulator.hxx: In member function 'bool
vigra::acc::DynamicAccumulatorChain::activateImpl(std::__cxx11::string)':
/usr/include/vigra/accumulator.hxx:2223:61: internal compiler error: in
strip_typedefs, at cp/tree.c:1466
 return acc_detail::ApplyVisitorToTag::exec(*this,
 ^
Please submit a full bug report,
with preprocessed source if appropriate.

https://koji.fedoraproject.org/koji/taskinfo?taskID=13217310

[Bug fortran/70058] Segmentation fault when open file with existing file and status = "UNKNOWN"

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-03
 CC||jvdelisle at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jerry DeLisle  ---
Thanks for report.  If it worked before it is a regression. I will start
working on this right away.

[Bug fortran/70058] Segmentation fault when open file with existing file and status = "UNKNOWN"

[jvdelisle at gcc dot gnu.org]

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

--- Comment #2 from Jerry DeLisle  ---
Paul, could you please post the terminal output that gives the error message
please.

[Bug fortran/70068] New: ICE: out of memory on involving empty substring

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

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

Bug ID: 70068
   Summary: ICE: out of memory on involving empty substring
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Looks strange, is legal (empty substring, zero length) :


$ cat z1.f90
program p
   character(99), parameter :: x(2) = ' '
   character(99), parameter :: y = x(2)(99:1)
end

$ gfortran-6 z1.f90
f951: out of memory allocating 18446744073709551232 bytes after a total of
634880 bytes



$ cat z2.f90
program p
   character(99), parameter :: x(2) = ' '
   character(99) :: y = x(2)(99:1)
end

$ gfortran-6 z2.f90
f951: out of memory allocating 18446744073709551232 bytes after a total of
626688 bytes



Compiles and works :

$ cat z3.f90
program p
   character(99), parameter :: x(2) = 'x'
   character(99) :: y
   y = x(2)(99:1)
   print *, y
end



Works with a scalar x instead of an array :

$ cat z4.f90
program p
   character(99), parameter :: x = ' '
   character(99), parameter :: y = x(99:1)
   print *, y
end

[Bug fortran/70068] ICE: out of memory on involving empty substring

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

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

--- Comment #1 from Gerhard Steinmetz  
---
Similar :


$ cat z7.f90
program p
   integer :: i
   character(3), parameter :: x(3) = ['abc', 'ijk', 'xyz']
   character(3), parameter :: y(2) = [(x(i)(i:1), i=2,3)]
end

$ gfortran-6 z7.f90
*** Error in `/usr/lib64/gcc/x86_64-suse-linux/6/f951': malloc(): memory
corruption: 0x03081750 ***



$ cat z8.f90
program p
   integer :: i
   character(3), parameter :: x(3) = ['abc', 'ijk', 'xyz']
   character(3) :: y(2) = [(x(i)(i:1), i=2,3)]
end

$ gfortran-6 z8.f90
*** Error in `/usr/lib64/gcc/x86_64-suse-linux/6/f951': malloc(): memory
corruption: 0x025d6730 ***



$ cat z9.f90
program p
   integer :: i
   character(3), parameter :: x(3) = ['abc', 'ijk', 'xyz']
   character(3) :: y(2)
   y = [(x(i)(i:1), i=2,3)]
end

$ gfortran-6 z9.f90
*** Error in `/usr/lib64/gcc/x86_64-suse-linux/6/f951': malloc(): memory
corruption: 0x02b57900 ***



Compiles and runs :

$ cat za.f90
program p
   integer :: i
   character(3) :: x(3)
   character(3) :: y(2)
   x = ['abc', 'ijk', 'xyz']
   y = [(x(i)(i:1), i=2,3)]
   print *, len_trim(x), x
   print *, len_trim(y)
end

$ gfortran-6 za.f90
$ a.out
   3   3   3 abcijkxyz
   0   0

[Bug middle-end/70069] New: Uninitialized value default to zero, plus warning

[rth at gcc dot gnu.org]

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

Bug ID: 70069
   Summary: Uninitialized value default to zero, plus warning
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rth at gcc dot gnu.org
  Target Milestone: ---

Quoting Ingo Monlar, via a LKML discussion:

=
It could be combined with the following 'safe' runtime behavior: when built
with 
-Ow then all uninitialized values are initialized to 0. This should be
relatively 
easy to implement, as it does not depend on any optimization. After all is said 
and done, there's two cases:

  - a 0-initialization gets optimized out by an optimization pass. This is the 
common case.

  - a variable gets initialized to 0 unnecessarily. (If a warning got ignored.)

having some runtime overhead for zero initialization is much preferred for many 
projects.

The warning could even be generated at this late stage: i.e. the warning would 
simply warn about remaining 0-initializations that previous passes were unable
to 
eliminate.

This way no undeterministic, random, uninitialized (and worst-case: attacker 
controlled) values can ever enter the program flow (from the stack) - in the
worst 
case (where a warning was ignored) a 0 value is set implicitly - which is still 
deterministic behavior.
==

I imagine a marked value of some sort (e.g. a flag on existing *_CST, or
maybe a new UNINIT_CST) with such an initialization being applied to all
auto variables that aren't already initialized at declaration.  Optimize
as usual, but don't discard the marked value at PHIs.  Warn if any persist
during expansion.

All controlled by -fnew-flag, so that it's opt-in.

[Bug fortran/70070] New: ICE on initializing character data beyond min/max bound

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

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

Bug ID: 70070
   Summary: ICE on initializing character data beyond min/max
bound
   Product: gcc
   Version: 6.0
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 code accidentally accesses invalid data :


$ cat z1.f90
program p
   integer :: i
   character(1) :: c
   data (c(i:i), i=1,11) /11*'c'/
end

$ gfortran-6 z1.f90
*** Error in `/usr/lib64/gcc/x86_64-suse-linux/6/f951': free(): invalid next
size (fast): 0x029ac080 ***
...
internal compiler error: Aborted



$ cat z3.f90
program p
   integer :: i
   character(99) :: c
   data (c(i:i), i=1,999) /999*'c'/
end

$ gfortran-6 z3.f90
*** Error in `/usr/lib64/gcc/x86_64-suse-linux/6/f951': free(): invalid next
size (normal): 0x02fa2440 ***
*** Error in `/usr/lib64/gcc/x86_64-suse-linux/6/f951': corrupted double-linked
list: 0x02f226f0 ***