[Bug target/67714] [6 Regression] signed char is zero-extended instead of sign-extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67714 --- Comment #20 from Christophe Lyon --- Author: clyon Date: Mon Mar 7 08:18:25 2016 New Revision: 234019 URL: https://gcc.gnu.org/viewcvs?rev=234019&root=gcc&view=rev Log: 2016-03-07 Christophe Lyon Backport from mainline 2016-02-04 Kyrylo Tkachov PR target/65932 PR target/67714 * config/arm/arm.c (arm_new_rtx_costs, MULT case): Properly extract the operands of the SIGN_EXTENDs from a SMUL[TB][TB] rtx. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/arm/arm.c
[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932 --- Comment #34 from Christophe Lyon --- Author: clyon Date: Mon Mar 7 08:18:25 2016 New Revision: 234019 URL: https://gcc.gnu.org/viewcvs?rev=234019&root=gcc&view=rev Log: 2016-03-07 Christophe Lyon Backport from mainline 2016-02-04 Kyrylo Tkachov PR target/65932 PR target/67714 * config/arm/arm.c (arm_new_rtx_costs, MULT case): Properly extract the operands of the SIGN_EXTENDs from a SMUL[TB][TB] rtx. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/arm/arm.c
[Bug target/70113] New: [AArch64] -mpc-relative-literal-loads conflicts with fix-cortex-a53-843419
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70113 Bug ID: 70113 Summary: [AArch64] -mpc-relative-literal-loads conflicts with fix-cortex-a53-843419 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- This is a follow-up to PR 633304. When the Linux kernel is configured with CONFIG_ARM64_ERRATUM_843419, the support for relocations R_AARCH64_ADR_PREL_PG_HI21 and R_AARCH64_ADR_PREL_PG_HI21_NC is removed from the kernel to avoid loading objects with possibly offending sequences. In this case the kernel is built with -mcmodel=large. However, since -mpc-relative-literal-loads is now disabled by default, GCC may still emit such relocations. This PR is a proposal to change GCC's -mfix-cortex-a53-843419 to change the default for -mpc-relative-literal-loads. I proposed a patch: https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01986.html
[Bug target/70113] [AArch64] -mpc-relative-literal-loads conflicts with fix-cortex-a53-843419
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70113 --- Comment #1 from Christophe Lyon --- Follow-up: https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00445.html
[Bug c/70114] New: Incompatible implicit function prototype when parameters match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70114
Bug ID: 70114
Summary: Incompatible implicit function prototype when
parameters match
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tanzx940228 at hotmail dot com
Target Milestone: ---
Created attachment 37883
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37883&action=edit
All the 3 examples shown in the comment.
Brief:
A function call in a scope where no prototype is given triggers an error, when
the parameters match a prototype given in a different scope.
Detail: I'm going to show 3 examples. The bug is shown in the 3rd example. All
3 examples are standalone .c files.
1.correct.c
---
int main() {
{
int foo(int arg);
foo(3);
}
{
int foo(float arg0, float arg1); // both gcc and clang get errors
return foo(3.0f, 4.0f);
}
}
Note that different prototypes are given in different scopes. Both gcc and
clang treat this as an error. This means they both think that a function can
only have one prototype throughout the translation unit - totally reasonable.
2.gcc.okay.c
int main() {
{
int foo(int arg);
foo(3);
}
{
foo(3.0f, 4.0f); // gcc passes, clang gets an error
}
}
In this example, the second usage of 'foo' is in a scope with no prototype
given. Clang is smart enough to tell you that there is a prototype in another
scope, and the parameters in the call don't match that prototype. gcc compiles
this program (with a warning) - which is acceptable. Maybe gcc thinks that it's
the user's responsibility to check the parameters if he doesn't give a
prototype in the scope.
3.gcc.error.c
-
int main() {
{
int foo(float arg0, float arg1);
foo(3.0f, 4.0f);
}
{
foo(3.0f, 4.0f); // clang passes, gcc gets an error???
}
}
This is really weird! Clang gives me a warning saying that I'm using an
out-of-scope prototype. BUT gcc gives me an error, saying "incompatible
implicit declaration of function ‘foo’"! What happened?
I'm using:
gcc (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010
Ubuntu clang version 3.6.2-1 (tags/RELEASE_362/final) (based on LLVM 3.6.2)
Target: x86_64-pc-linux-gnu
Thread model: posix
[Bug target/70110] [6 Regression] ICE at -O3 in the 32-bit mode in set_last_insn, at emit-rtl.h:420
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70110 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 37884 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37884&action=edit gcc6-pr70110.patch Untested fix.
[Bug tree-optimization/70115] New: gcc ICE at -O2 (seg fault) and above on valid code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70115
Bug ID: 70115
Summary: gcc ICE at -O2 (seg fault) and above on valid code on
x86_64-linux-gnu
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: helloqirun at gmail dot com
Target Milestone: ---
The following valid code causes an ICE when compiled with the current gcc trunk
at -O2 and above on x86_64-linux-gnu in both 32-bit and 64-bit modes.
It also crashes gcc-5.X and 4.8. But 4.9 and 4.6 work fine.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160306 (experimental) [trunk revision 234013] (GCC)
$ gcc-trunk -O2 abc.c
abc.c: In function 'main':
abc.c:3:5: internal compiler error: Segmentation fault
int main() {
^~~~
0xb5a3cf crash_signal
../../gcc/gcc/toplev.c:335
0x89d0cb contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3119
0x89d0cb fold_comparison
../../gcc/gcc/fold-const.c:8433
0x8826da fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/gcc/fold-const.c:3
0x8a0714 fold(tree_node*)
../../gcc/gcc/fold-const.c:12113
0xcb14b8 simplify_replace_tree
../../gcc/gcc/tree-ssa-loop-niter.c:1798
0xcb315c substitute_in_loop_info(loop*, tree_node*, tree_node*)
../../gcc/gcc/tree-ssa-loop-niter.c:4293
0xb96a17 replace_uses_by(tree_node*, tree_node*)
../../gcc/gcc/tree-cfg.c:1871
0xb97317 gimple_merge_blocks
../../gcc/gcc/tree-cfg.c:1938
0x7589b5 merge_blocks(basic_block_def*, basic_block_def*)
../../gcc/gcc/cfghooks.c:774
0xba0593 cleanup_tree_cfg_bb
../../gcc/gcc/tree-cfgcleanup.c:660
0xba0f56 cleanup_tree_cfg_1
../../gcc/gcc/tree-cfgcleanup.c:726
0xba0f56 cleanup_tree_cfg_noloop
../../gcc/gcc/tree-cfgcleanup.c:761
0xba0f56 cleanup_tree_cfg()
../../gcc/gcc/tree-cfgcleanup.c:812
0xc95459 tree_unroll_loops_completely(bool, bool)
../../gcc/gcc/tree-ssa-loop-ivcanon.c:1369
0xc956d3 execute
../../gcc/gcc/tree-ssa-loop-ivcanon.c:1528
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
$ cat abc.c
typedef int size_t;
char a;
int main() {
size_t b, c;
for (;;) {
b = 0;
for (; c;)
;
for (; b < sizeof(long); b++)
;
for (; b < c; b++)
a++;
for (; c < b; c++)
;
}
}
[Bug target/70083] [6 Regression] ICE: in assign_stack_local_1, at function.c:409 with -fschedule-insns -mavx512* @ i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70083 --- Comment #2 from Jakub Jelinek --- The problem is that while the function is compiled with -mavx512dq, there are no 512-bit vectors in it and thus the dynamic stack realignment code only ensures the stack is 256-bit aligned. But, LRA for some reason chooses to split_reg a function parameter, and that one has its regno_reg_rtx (reg:XI 22 xmm1), a 512-bit mode that doesn't occur in the function, it comes from init_emit_regs: 5814 for (i = 0; i < FIRST_PSEUDO_REGISTER; i++) 5815initial_regno_reg_rtx[i] = gen_raw_REG (reg_raw_mode[i], i); So it creates another pseudo with this extra large mode, and then at a later point attempts to spill it, which is obviously not going to work.
[Bug target/62281] gcc doesn't conform to Solaris 32-bit ABI by expecting 16-byte stack alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62281 --- Comment #11 from Rainer Orth --- *** Bug 61949 has been marked as a duplicate of this bug. ***
[Bug target/61949] [6 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 Rainer Orth changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #29 from Rainer Orth --- I've now received confirmation that 32-bit Solaris/x86 only guarantees 4-byte stack alignment. Rainer *** This bug has been marked as a duplicate of bug 62281 ***
[Bug target/62281] gcc doesn't conform to Solaris 32-bit ABI by expecting 16-byte stack alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62281 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-03-07 Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #12 from Rainer Orth --- Mine, received confirmation that only 4-byte stack alignment is guaranteed on 32-bit Solaris/x86 from the Solaris and Studio groups in Oracle. Rainer
[Bug target/62281] gcc doesn't conform to Solaris 32-bit ABI by expecting 16-byte stack alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62281 --- Comment #13 from Rainer Orth --- Author: ro Date: Mon Mar 7 09:51:31 2016 New Revision: 234022 URL: https://gcc.gnu.org/viewcvs?rev=234022&root=gcc&view=rev Log: Only assume 4-byte stack alignment on 32-bit Solaris/x86 (PR target/62281) PR target/62281 * config/i386/sol2.h (STACK_REALIGN_DEFAULT): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sol2.h
[Bug tree-optimization/70116] New: tail-merge merges ubsan internal fns with different location information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70116 Bug ID: 70116 Summary: tail-merge merges ubsan internal fns with different location information Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00758.html : ... I'd actually think it would be better to give up on the UBSAN_* internal calls in tail merging. Those internal pass arguments based on their gimple_location, so tail merging breaks them. ...
[Bug tree-optimization/70116] tail-merge merges ubsan internal fns with different location information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70116 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic, patch --- Comment #1 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00462.html
[Bug target/62281] gcc doesn't conform to Solaris 32-bit ABI by expecting 16-byte stack alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62281 --- Comment #14 from Rainer Orth --- Fixed for 6.1.
[Bug target/70117] New: ppc long double isinf() is wrong?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70117
Bug ID: 70117
Summary: ppc long double isinf() is wrong?
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
CC: meissner at gcc dot gnu.org
Target Milestone: ---
Appearantly gnulib has its own idea of LDBL_MAX and with recent glibc changing
isinf to use GCC builtins we end up with the following failing test which
may be because GCC folds the isinf() call to do effectively
if (islessequal (fabsl (gl_LDBL_MAX.ld),
1.79769313486231580793728971405301199252069012264752390332e+308))
which may or may not be valid for IBM long double (double double) which is
said to have "many" LDBL_MAX?
#include
union gl_long_double_union
{
struct { double hi; double lo; } dd;
long double ld;
};
const union gl_long_double_union gl_LDBL_MAX =
{ { (DBL_MAX), (DBL_MAX) / (double)134217728UL / (double)134217728UL } };
int main()
{
if (__builtin_isinfl (gl_LDBL_MAX.ld))
__builtin_abort ();
if (__builtin_isinfl (-gl_LDBL_MAX.ld))
__builtin_abort ();
return 0;
}
[Bug other/70118] New: UBSan claims misaligned access in SSE instrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70118 Bug ID: 70118 Summary: UBSan claims misaligned access in SSE instrinsics Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: linux at carewolf dot com Target Milestone: --- The intrinsics _mm_loadl_epi64 and _mm_storel_epi64 triggers UBSan warnings on unaligned access because the instrinsics definitions in emmintrin.h are using __m64 and __v2di pointers, and both those types have been declared with default alignment. The intrinsics definitions should probably either be replaced with a __builtin_ia32_movq, or the __m64 and __v2di types be defined with __attribute__ ((aligned(1))).
[Bug c++/70091] Codegen emits dead load on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70091
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-03-07
Ever confirmed|0 |1
Known to fail||5.3.0
--- Comment #1 from Richard Biener ---
The C++ FE emits
;; Function void bitfield::and_assign() volatile (null)
;; enabled by -tree-original
<_raw = *(volatile struct
bitfield *) this;, bitfield::_and ((unsigned int) ((volatile struct bitfield *)
this)->_raw, 1);) >;
<_raw = (unsigned int) ((volatile
struct bitfield *) this)->_raw & 1) >;
there's the odd
((volatile struct bitfield *) this)->_raw = *(volatile struct bitfield *) this;
statement which causes this. But the store goes away somehow. GIMPLE:
void bitfield::and_assign() volatile (volatile struct bitfield * const this)
{
struct bitfield vol.0;
unsigned int D.2339;
unsigned int D.2340;
unsigned int D.2341;
unsigned int D.2342;
vol.0 = *this;
D.2339 = this->_raw;
D.2340 = bitfield::_and (D.2339, 1);
this->_raw = D.2340;
Confirmed as FE bug.
[Bug c/70093] Instancing function with VM return type cases internal compiler error in 'assign_stack_temp_for_type'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70093 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-07 Ever confirmed|0 |1 Known to fail||4.3.5, 5.3.0, 6.0 --- Comment #3 from Richard Biener --- Confirmed. Not sure if the code is valid.
[Bug tree-optimization/70115] gcc ICE at -O2 (seg fault) and above on valid code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70115 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-07 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with r211725: commit 39b620843f18a606cf319d09a41689352493728d Author: rguenth Date: Tue Jun 17 07:42:47 2014 + 2014-06-17 Richard Biener * tree-ssa-propagate.c: Include domwalk.h. (substitute_and_fold): Outline main worker into a domwalker ... (substitute_and_fold_dom_walker::before_dom_children): ... here. Schedule stmts we can fully propagate for removal. Remove poor-mans DCE. (substitute_and_fold): Apply a dominator walk to perform substitution. Process stmts scheduled for removal here. * gcc.dg/tree-ssa/20041122-1.c: Adjust. * gcc.dg/tree-ssa/forwprop-21.c: Likewise. * gcc.dg/tree-ssa/vrp35.c: Revert previous adjustments. * gcc.dg/tree-ssa/vrp36.c: Likewise. * gcc.dg/vect/nodump-forwprop-22.c: Adjust.
[Bug tree-optimization/70094] Missed optimization when passing a constant struct argument by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70094
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-03-07
Component|c++ |tree-optimization
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Confirmed. This is quite hard for us as GIMPLE doesn't allow arbitrary
constant
literals as function arguments and at RTL we can't remove the stack local
anymore.
So to make this work on GIMPLE we'd need to allow
bar ( CONSTRUCTOR {1, 2, 3 } )
so maybe CONSTRUCTORs marked with TREE_CONSTANT. Of course expansion
needs to work as well for this.
The optimization pass to generate this would be SRA.
Cost issues if you have two calls like
bar (f);
bar (f);
etc.
[Bug middle-end/70100] [5 Regression] ICE: in execute, at cfgexpand.c:6066
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70100 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |5.4
[Bug tree-optimization/70102] Tree re-association prevents SLP vectorization at -Ofast.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70102 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-03-07 CC|richard.guenther at gmail dot com | Blocks||53947 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed and mine. I suppose taking into account operation kind of defs when computing rank() may work here. But in general the vectorizer doesn't consider re-associating things when building the SLP tree. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/70103] gcc reports bad dependence and bails out of vectorization for one of the bwaves loops.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70103 Richard Biener changed: What|Removed |Added Keywords||alias, missed-optimization Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-03-07 CC|richard.guenther at gmail dot com | Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Please split the second issue into a separate bug. I have a patch for the dependence issue (but need to thing about its cost).
[Bug c++/70105] [6 regression] giant warning when building gcc-5 with gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70105 Richard Biener changed: What|Removed |Added Version|unknown |6.0 Target Milestone|--- |6.0
[Bug c++/70106] [4.9/5/6 Regression][C++11 or above] adding parenthesis [cerr << (var)] cause error: invalid static_cast from type 'const size_t {aka const long unsigned int}' to type 'size_t& {aka lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70106
Richard Biener changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-03-07
Known to work||4.8.5
Target Milestone|--- |4.9.4
Summary|[4.9/5.3/6.0][C++11 or |[4.9/5/6 Regression][C++11
|above] adding parenthesis |or above] adding
|[cerr << (var)] cause |parenthesis [cerr << (var)]
|error: invalid static_cast |cause error: invalid
|from type 'const size_t |static_cast from type
|{aka const long unsigned|'const size_t {aka const
|int}' to type 'size_t& {aka |long unsigned int}' to type
|long unsigned int&}'|'size_t& {aka long unsigned
||int&}'
Ever confirmed|0 |1
--- Comment #3 from Richard Biener ---
Confirmed.
[Bug other/70118] UBSan claims misaligned access in SSE instrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70118 marc at kdab dot com changed: What|Removed |Added CC||marc at kdab dot com --- Comment #1 from marc at kdab dot com --- Confirmed on gcc version 6.0.0 20160304
[Bug tree-optimization/70109] [6 Regression] FAIL: gcc.dg/vect/O3-pr36098.c scan-tree-dump-times vect "vectorizing stmts usin g SLP" 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70109 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-03-07 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine then.
[Bug target/70119] New: AArch64 should take advantage of implicit truncation of variable shift amount without defining SHIFT_COUNT_TRUNCATED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70119
Bug ID: 70119
Summary: AArch64 should take advantage of implicit truncation
of variable shift amount without defining
SHIFT_COUNT_TRUNCATED
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
Consider the testcases:
unsigned f1(unsigned x, int y) { return x << (y & 31); }
unsigned long f2(unsigned long x, int y) { return x << (y & 63); }
unsigned long
f3 (unsigned long bit_addr)
{
unsigned long bitnumb = bit_addr & 63;
return (1L << bitnumb);
}
Currently we generate for -O2:
f1:
and w1, w1, 31
lsl w0, w0, w1
ret
f2:
and w1, w1, 63
lsl x0, x0, x1
ret
f3:
and x0, x0, 63
mov x1, 1
lsl x0, x1, x0
ret
The masking of the shift amount could be omitted because the lsl (and other
shuft/rotate instructions) implicitly truncate their shift amount to the
register width.
GCC could figure that out if we defined SHIFT_COUNT_TRUNCATED, but we can't do
that for TARGET_SIMD because the variable shift patterns have alternatives that
perform the shifts on the vector registers. Those instructions don't truncate
their shift amount.
A simple solution is to write a pattern for combine to catch the shift/rotate
by an and-immediate and emit the simple ALU shift/rotate instruction:
(set (reg:SI 1)
(ashift:SI (reg:SI 2)
(and:QI (reg:QI 3) (const_int 31
The AND operation is in QImode because the shift expanders expand the shift
amount to a QImode value.
This doesn't quite work, however. During combine the midend creates a subreg of
the whole AND expression for the shift amount:
(subreg:QI (and:SI (reg:SI x1)
(const_int 31)) 0)
instead of propagating the subreg inside the AND.
Some discussion at:
https://gcc.gnu.org/ml/gcc/2016-02/msg00357.html
(thread continues into 2016-03)
One solution could be to teach simplify-rtx to move the subreg inside.
Another proposed solution is to teach the backend to match different modes for
the shift amounts.
However, I haven't had much luck implementing that idea.
The "ashl" standard name must expand to a single mode for the shift amount and
any explicit masking operation (like in the testcases) that is propagated into
the shift amount must be forced to that mode. For QImode and SImode shift
amounts I'm seeing the same issue as above (subreg of an AND-immediate) and for
DImode shift amounts I see zero_extends of SImode rtxes being created for the
shift amount, that also don't match.
[Bug target/70118] UBSan claims misaligned access in SSE instrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70118 Richard Biener changed: What|Removed |Added Keywords||diagnostic, wrong-code Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-07 Component|other |target Ever confirmed|0 |1
[Bug tree-optimization/70115] [5/6 Regression] gcc ICE at -O2 (seg fault) and above on valid code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70115 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Known to work||4.9.4 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |5.4 Summary|gcc ICE at -O2 (seg fault) |[5/6 Regression] gcc ICE at |and above on valid code on |-O2 (seg fault) and above |x86_64-linux-gnu|on valid code on ||x86_64-linux-gnu --- Comment #2 from Richard Biener --- I will have a look.
[Bug rtl-optimization/69710] performance issue with SP Linpack with Autovectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69710 --- Comment #14 from amker at gcc dot gnu.org --- (In reply to Doug Gilmore from comment #13) > I think this should be fairly straightforward to fix in the > autovectorization pass. Hopefully I should be able to post a patch > in the next few days. I had a patch too, will send it for review in GCC7 if it's still needed. Thanks.
[Bug rtl-optimization/29854] reload_combine looses track of uses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29854 Oleg Endo changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME
[Bug other/29842] [meta-bug] outstanding patches / issues from STMicroelectronics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29842 Bug 29842 depends on bug 29854, which changed state. Bug 29854 Summary: reload_combine looses track of uses https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29854 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME
[Bug c++/70106] [4.9/5/6 Regression][C++11 or above] adding parenthesis [cerr << (var)] cause error: invalid static_cast from type 'const size_t {aka const long unsigned int}' to type 'size_t& {aka lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70106 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Started with r208352.
[Bug tree-optimization/70115] [5/6 Regression] gcc ICE at -O2 (seg fault) and above on valid code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70115 --- Comment #3 from Richard Biener --- Ok, so cunroll unrolls for (; b < c; b++) a++; to "nothing" which releases b_2 but that is still used in the followup loops nb_iterations expression, b_2 >= c_19 ? (unsigned int) b_2 - (unsigned int) c_19 : 0 then CFG cleanup comes along merging two blocks and propagating out the PHI node # c_19 = PHI which substitutes c_3 in that expression with c_19 and tries to simplify the result b_2 >= c_19 which trips over the released SSA name. Now I wonder if this shouldn't happen with loop-closed SSA as we have a use of b_2 after its def loop (but the def is the loop header PHI). Ah, but cunrolli is _not_ operating on loop-closed SSA form. If I change that it exposes that cunroll has its own constant propagation replace-all-uses function which misses loop meta data... which is actually the only thing I need to fix here.
[Bug tree-optimization/70013] [6 Regression] packed structure tree-sra loses initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70013 alalaw01 at gcc dot gnu.org changed: What|Removed |Added CC||alalaw01 at gcc dot gnu.org --- Comment #4 from alalaw01 at gcc dot gnu.org --- Hmmm. First thing I notice is that the type of d (struct S0[2]) is not scalarizable_type_p, but passes type_internals_preclude_sra_p. Changing the latter to bail out on DECL_BIT_FIELD (as the former does) fixes the ICE, but I'm not yet sure we want to do that.
[Bug testsuite/70109] [6 Regression] FAIL: gcc.dg/vect/O3-pr36098.c scan-tree-dump-times vect "vectorizing stmts usin g SLP" 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70109
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |testsuite
--- Comment #2 from Richard Biener ---
We now vectorize this there correctly, also on x86_64 with -march=corei7. The
testcase was added for a fixed miscompile which should have added a runtime
testcase instead.
I will add a { target { ! vect_perm } } but I suppose given this dg test it
might
still get us false positives/negatives.
[Bug testsuite/70109] [6 Regression] FAIL: gcc.dg/vect/O3-pr36098.c scan-tree-dump-times vect "vectorizing stmts usin g SLP" 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70109 --- Comment #3 from Richard Biener --- Author: rguenth Date: Mon Mar 7 11:45:49 2016 New Revision: 234024 URL: https://gcc.gnu.org/viewcvs?rev=234024&root=gcc&view=rev Log: 2016-03-07 Richard Biener PR testsuite/70109 * gcc.dg/vect/O3-pr36098.c: New testcase. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/O3-pr36098.c
[Bug rtl-optimization/70061] [6 Regression] ICE: SIGSEGV in delete_insn_chain() with unused label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70061 --- Comment #4 from Richard Henderson --- Author: rth Date: Mon Mar 7 11:48:57 2016 New Revision: 234025 URL: https://gcc.gnu.org/viewcvs?rev=234025&root=gcc&view=rev Log: PR rtl-opt/70061 * tree-outofssa.c (emit_partition_copy): Flush pending stack adjust. (insert_value_copy_on_edge): Likewise. * gcc.c-torture/compile/pr70061.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr70061.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-outof-ssa.c
[Bug testsuite/70109] [6 Regression] FAIL: gcc.dg/vect/O3-pr36098.c scan-tree-dump-times vect "vectorizing stmts usin g SLP" 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70109 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug rtl-optimization/70061] [6 Regression] ICE: SIGSEGV in delete_insn_chain() with unused label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70061 Richard Henderson changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Henderson --- Fixed.
[Bug target/70119] AArch64 should take advantage of implicit truncation of variable shift amount without defining SHIFT_COUNT_TRUNCATED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70119 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-07 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. SHIFT_COUNT_TRUNCATED should simply go away.
[Bug target/70119] AArch64 should take advantage of implicit truncation of variable shift amount without defining SHIFT_COUNT_TRUNCATED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70119 --- Comment #2 from Uroš Bizjak --- (In reply to Richard Biener from comment #1) > Confirmed. SHIFT_COUNT_TRUNCATED should simply go away. The same limitation is with x86. Shifts trucate the shift count, but bit-test (BT) instructions take modulo of the bit offset operand. We have somehow hacked around this by introducing 3_mask patterns to i386.md in the hope that combine catches the masking, but the solution is far from optimal.
[Bug target/70120] New: [aarch64] -mno-pc-relative-literal-loads -g causes Assembler messages: Error: unaligned opcodes detected in executable segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120 Bug ID: 70120 Summary: [aarch64] -mno-pc-relative-literal-loads -g causes Assembler messages: Error: unaligned opcodes detected in executable segment Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: assemble-failure Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Target: aarch64-unknown-linux-gnu Created attachment 37885 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37885&action=edit reduced testcase Compiler output: $ aarch64-unknown-linux-gnu-gcc -Og -fschedule-insns -mno-pc-relative-literal-loads -g testcase.c /tmp/ccGjqX1U.s: Assembler messages: /tmp/ccGjqX1U.s: Error: unaligned opcodes detected in executable segment $ aarch64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-234020-checking-yes-rtl-df-nographite-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/6.0.0/lto-wrapper Target: aarch64-unknown-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=aarch64-unknown-linux-gnu --with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld --with-as=/usr/bin/aarch64-unknown-linux-gnu-as --with-sysroot=/usr/aarch64-unknown-linux-gnu --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-234020-checking-yes-rtl-df-nographite-aarch64 Thread model: posix gcc version 6.0.0 20160307 (experimental) (GCC) There are two ways to fix the assembly. 1) align the data: @@ -279,6 +279,7 @@ .align 1 .LC3: .hword 0 + .hword 0 .Letext0: .section.debug_info,"",@progbits .Ldebug_info0: 2) place the data in .rodata: @@ -276,9 +276,11 @@ .hword 0 .hword 0 .hword 0 + .section .rodata .align 1 .LC3: .hword 0 + .text .Letext0: .section.debug_info,"",@progbits .Ldebug_info0:
[Bug target/70119] AArch64 should take advantage of implicit truncation of variable shift amount without defining SHIFT_COUNT_TRUNCATED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70119 --- Comment #3 from ktkachov at gcc dot gnu.org --- Right, I see we have the same issue on aarch64 as on x86. So what would be the accepted solution here? I've been playing with a patch to simplify-rtx to move the subreg inside the AND and transform the AND into a QImode operation, but there were concerns on it pessimising other code
[Bug target/70120] [aarch64] -mno-pc-relative-literal-loads -g causes Assembler messages: Error: unaligned opcodes detected in executable segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-07 CC||ktkachov at gcc dot gnu.org, ||ramana at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed.
[Bug c++/70121] New: spurious warning and crash when returning a reference from lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70121
Bug ID: 70121
Summary: spurious warning and crash when returning a reference
from lambda
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blastrock at free dot fr
Target Milestone: ---
When I try to compile this simple program with gcc 5.3.1:
#include
int main(int argc, char *argv[])
{
const int val = 28;
auto ff = [&]() -> const int& { return val; };
int i = ff();
}
with the argument -std=c++11, I get the following warning:
warning: returning reference to temporary [-Wreturn-local-addr]
And the program crashes on the int assign statement.
I believe this code is legal, the temporary variable is still valid when the
lambda is called. And the same code compiles without warning and runs without
crash with clang 3.7.
[Bug target/50099] ICE: internal compiler error: in extract_insn, at recog.c:2113 while building lttng-ust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50099 Bernd Schmidt changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #42 from Bernd Schmidt --- I think this was fixed by Ramana's patch.
[Bug target/70119] AArch64 should take advantage of implicit truncation of variable shift amount without defining SHIFT_COUNT_TRUNCATED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70119 --- Comment #4 from Richard Biener --- (In reply to ktkachov from comment #3) > Right, I see we have the same issue on aarch64 as on x86. > So what would be the accepted solution here? > I've been playing with a patch to simplify-rtx to move the subreg inside the > AND and transform the AND into a QImode operation, but there were concerns > on it pessimising other code I think adding some special support to combine itself might be better.
[Bug c/70093] Instancing function with VM return type cases internal compiler error in 'assign_stack_temp_for_type'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70093 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- I'll look.
[Bug tree-optimization/70013] [6 Regression] packed structure tree-sra loses initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70013
--- Comment #5 from alalaw01 at gcc dot gnu.org ---
Prior to SRA, we have
d = *.LC0;
d$0$f0_7 = MEM[(struct S0[2] *)&*.LC0].f0;
e$f0_9 = MEM[(struct S0[2] *)&d + 3B].f0;
_3 = (int) d$0$f0_7;
c = _3;
_5 = (int) e$f0_9;
__builtin_printf ("%x\n", _5);
sra_modify_assign for d=*.LC0 ends up in load_assign_lhs_subreplacements, where
d has two children; the second is grp_to_be_replaced, but because we did not
completely_scalarize LC0, there is an access to only the first half of *.LC0,
and no corresponding RHS for the second half of d ('racc =
find_access_in_subtree (sad->top_racc, offset, lacc->size' returns null). So we
generate the bad
d$3$f0_14 = MEM[(struct S0[2] *)&d + 3B].f0;
that is, initializing the scalar replacement for the second half of d, with a
value read from the first half of d.
[Bug c/70093] Instancing function with VM return type cases internal compiler error in 'assign_stack_temp_for_type'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70093 --- Comment #5 from Marek Polacek --- Even gcc34 ICEs here, so dunno when exactly it started, but it was a long long time ago in a galaxy far far away.
[Bug target/70117] ppc long double isinf() is wrong?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70117
Ulrich Weigand changed:
What|Removed |Added
CC||amodra at gcc dot gnu.org,
||dje at gcc dot gnu.org,
||uweigand at gcc dot gnu.org
--- Comment #1 from Ulrich Weigand ---
Hmm. For some reason, the gnulib definition of LDBL_MAX differs from GCC's
definition. With gnulib, we get:
high double: 7FEF
low double: 7C8F
while with GCC, we get:
high double: 7FEF
low double: 7C8F FFFE
In any case, someone is wrong here -- values of LDBL_MAX should certainly
agree.
Now I'm not completely sure why GCC choses the value it does, I notice that
GCC's choice is certainly deliberate; there's extra code to flip the last bit:
real.c:get_max_float
if (fmt->pnan < fmt->p)
{
/* This is an IBM extended double format made up of two IEEE
doubles. The value of the long double is the sum of the
values of the two parts. The most significant part is
required to be the value of the long double rounded to the
nearest double. Rounding means we need a slightly smaller
value for LDBL_MAX. */
buf[4 + fmt->pnan / 4] = "7bde"[fmt->pnan % 4];
}
and similarly real.c:real_maxval
if (fmt->pnan < fmt->p)
/* This is an IBM extended double format made up of two IEEE
doubles. The value of the long double is the sum of the
values of the two parts. The most significant part is
required to be the value of the long double rounded to the
nearest double. Rounding means we need a slightly smaller
value for LDBL_MAX. */
clear_significand_bit (r, SIGNIFICAND_BITS - fmt->pnan - 1);
This code was originally added by Alan back in 2004 ... adding Alan on CC if he
recalls what this was all about.
[Bug middle-end/69916] [openacc] ICE in single_succ_edge called from oacc_loop_xform_loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69916 --- Comment #5 from Nathan Sidwell --- Author: nathan Date: Mon Mar 7 13:22:07 2016 New Revision: 234026 URL: https://gcc.gnu.org/viewcvs?rev=234026&root=gcc&view=rev Log: gcc/ PR middle-end/69916 * omp-low.c (struct oacc_loop): Add ifns. (new_oacc_loop_raw): Initialize it. (finish_oacc_loop): Clear mask & flags if no ifns. (oacc_loop_discover_walk): Count IFN_GOACC_LOOP calls. (oacc_loop_xform_loop): Add ifns arg & adjust. (oacc_loop_process): Adjust oacc_loop_xform_loop call. gcc/testsuite/ PR middle-end/69916 * c-c-++-common/goacc/pr69916.c: New. Added: trunk/gcc/testsuite/c-c++-common/goacc/pr69916.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog
[Bug target/70117] ppc long double isinf() is wrong?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70117
--- Comment #2 from rguenther at suse dot de ---
On Mon, 7 Mar 2016, uweigand at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70117
>
> Ulrich Weigand changed:
>
>What|Removed |Added
>
> CC||amodra at gcc dot gnu.org,
>||dje at gcc dot gnu.org,
>||uweigand at gcc dot gnu.org
>
> --- Comment #1 from Ulrich Weigand ---
> Hmm. For some reason, the gnulib definition of LDBL_MAX differs from GCC's
> definition. With gnulib, we get:
>
> high double: 7FEF
> low double: 7C8F
>
> while with GCC, we get:
>
> high double: 7FEF
> low double: 7C8F FFFE
>
> In any case, someone is wrong here -- values of LDBL_MAX should certainly
> agree.
>
> Now I'm not completely sure why GCC choses the value it does, I notice that
> GCC's choice is certainly deliberate; there's extra code to flip the last bit:
>
> real.c:get_max_float
>
> if (fmt->pnan < fmt->p)
> {
> /* This is an IBM extended double format made up of two IEEE
> doubles. The value of the long double is the sum of the
> values of the two parts. The most significant part is
> required to be the value of the long double rounded to the
> nearest double. Rounding means we need a slightly smaller
> value for LDBL_MAX. */
> buf[4 + fmt->pnan / 4] = "7bde"[fmt->pnan % 4];
> }
>
> and similarly real.c:real_maxval
>
> if (fmt->pnan < fmt->p)
> /* This is an IBM extended double format made up of two IEEE
>doubles. The value of the long double is the sum of the
>values of the two parts. The most significant part is
>required to be the value of the long double rounded to the
>nearest double. Rounding means we need a slightly smaller
>value for LDBL_MAX. */
> clear_significand_bit (r, SIGNIFICAND_BITS - fmt->pnan - 1);
>
> This code was originally added by Alan back in 2004 ... adding Alan on CC if
> he
> recalls what this was all about.
Note that independent of that question whether the number is isinf or not
depends only on the first double (which is not inf). So eventually
just the folding is bogus - who knows.
[Bug target/70048] [6 Regression][AArch64] Inefficient local array addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048 Richard Henderson changed: What|Removed |Added Status|NEW |ASSIGNED CC||rth at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |rth at gcc dot gnu.org --- Comment #6 from Richard Henderson --- Created attachment 37886 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37886&action=edit proposed patch I agree -- at minimum virtual and eliminable frame registers ought to be special-cased. If we separate the constants too far, we'll never be able to fold the constant plus the adjustment back together. If the statement in #c4 is taken at face value -- that r233136 was applied to simplify frame-based array accesses... Well, I simply don't believe that. I can see how the patch would aid reduction of access to members of a structure that are in an array which in turn is *not* on the stack. But for the average stack-based access I can't see except that it would hurt.
[Bug tree-optimization/70013] [6 Regression] packed structure tree-sra loses initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70013 --- Comment #6 from alalaw01 at gcc dot gnu.org --- Ugh, initializing the scalar replacement for the first half of d, with a value read from the first half of d (should be from the first half of *.LC0).
[Bug target/70083] [6 Regression] ICE: in assign_stack_local_1, at function.c:409 with -fschedule-insns -mavx512* @ i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70083 Bernd Schmidt changed: What|Removed |Added CC||bernds at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |bernds at gcc dot gnu.org --- Comment #3 from Bernd Schmidt --- Guess I'll poke at it, unless you want it, Jakub?
[Bug tree-optimization/70115] [5 Regression] gcc ICE at -O2 (seg fault) and above on valid code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70115 Richard Biener changed: What|Removed |Added Known to work||6.0 Summary|[5/6 Regression] gcc ICE at |[5 Regression] gcc ICE at |-O2 (seg fault) and above |-O2 (seg fault) and above |on valid code on|on valid code on |x86_64-linux-gnu|x86_64-linux-gnu Known to fail||5.3.0 --- Comment #4 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/70115] [5 Regression] gcc ICE at -O2 (seg fault) and above on valid code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70115 --- Comment #5 from Richard Biener --- Author: rguenth Date: Mon Mar 7 14:15:56 2016 New Revision: 234027 URL: https://gcc.gnu.org/viewcvs?rev=234027&root=gcc&view=rev Log: 2016-03-07 Richard Biener PR tree-optimization/70115 * tree-ssa-loop-ivcanon.c (propagate_into_all_uses): Remove. (propagate_constants_for_unrolling): Use replace_uses_by. * gcc.dg/torture/pr70115.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr70115.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-ivcanon.c
[Bug c++/70121] [5/6 Regression] spurious warning and crash when returning a reference from lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70121 Marc Glisse changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-07 Summary|spurious warning and crash |[5/6 Regression] spurious |when returning a reference |warning and crash when |from lambda |returning a reference from ||lambda Ever confirmed|0 |1 --- Comment #1 from Marc Glisse --- The wrong warning is old, but since gcc-5 we reuse that warning code to change the return to null, which makes the issue much worse.
[Bug target/70083] [6 Regression] ICE: in assign_stack_local_1, at function.c:409 with -fschedule-insns -mavx512* @ i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70083 --- Comment #4 from Jakub Jelinek --- RA is not my area of expertise, so sure, go ahead (unless Vlad wants to have a look).
[Bug tree-optimization/70013] [6 Regression] packed structure tree-sra loses initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70013 --- Comment #7 from alalaw01 at gcc dot gnu.org --- *second* half, sorry. grp_to_be_replaced is here true, but grp_unscalarized_data is false, so handle_unscalarized_data_in_subtree sets sad->refreshed=UDH_LEFT and we build the access to the LHS. (Then, load_assign_lhs_subreplacements exits, and the caller sees UDH_LEFT and removes the original block move statement.) In contrast, on a similar testcase using a parameter rather than *.LC0, grp_unscalarized_data is true, handle_unscalarized_data_in_subtree sets sad->refreshed=UDH_RIGHT and we build an access to the RHS, which is OK; and leave the block move statement in place, hence correctness.
[Bug lto/69607] undefined reference to MAIN__._omp_fn.0 in atomic_capture-1.f with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607 --- Comment #24 from vries at gcc dot gnu.org --- (In reply to vries from comment #23) > pinged patch: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01632.html ping^2: https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00487.html
[Bug c++/67364] [5/6 Regression] "accessing uninitialized member" error in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67364 --- Comment #15 from Jason Merrill --- Author: jason Date: Mon Mar 7 14:43:14 2016 New Revision: 234028 URL: https://gcc.gnu.org/viewcvs?rev=234028&root=gcc&view=rev Log: PR c++/67364 * constexpr.c (cxx_eval_store_expression): Replace CONSTRUCTOR_ELTS in nested CONSTRUCTORs, too. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-aggr3.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/constexpr.c
[Bug tree-optimization/70116] tail-merge merges ubsan internal fns with different location information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70116 --- Comment #2 from vries at gcc dot gnu.org --- Author: vries Date: Mon Mar 7 14:50:13 2016 New Revision: 234029 URL: https://gcc.gnu.org/viewcvs?rev=234029&root=gcc&view=rev Log: Skip ubsan/asan internal fns with different location in tail-merge 2016-03-07 Tom de Vries PR tree-optimization/70116 * tree-ssa-tail-merge.c (merge_stmts_p): New function, handling is_tm_ending stmts and ubsan/asan internal functions. (find_duplicate): Use it. Don't test is_tm_ending here. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-tail-merge.c
[Bug rtl-optimization/69710] performance issue with SP Linpack with Autovectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69710 --- Comment #15 from Doug Gilmore --- > I had a patch too, will send it for review in GCC7 if it's still needed. Sorry I got side track last week and didn't make much progress. Please go ahead and submit if you have something you feel comfortable with, I'll assist in testing. Thanks,
[Bug libgomp/70122] New: [openacc] Handle acc loop directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70122 Bug ID: 70122 Summary: [openacc] Handle acc loop directive Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Atm, in trunk, we don't explicitly handle acc loop directive in a kernels region. As a consequence, such kernels regions are executed sequentially.
[Bug tree-optimization/70013] [6 Regression] packed structure tree-sra loses initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70013 --- Comment #8 from Martin Jambor --- That is what I suspected. Please have at look why analyze_access_subtree (which has to set the grp_unscalarized_data flag) acts differently then.
[Bug libgomp/70122] [openacc] Handle acc loop directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70122 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization, patch --- Comment #1 from vries at gcc dot gnu.org --- patch: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01903.html pinged: https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00452.html
[Bug libgomp/70122] [openacc] Handle acc loop directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70122 vries at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement
[Bug libgomp/70122] [openacc] Handle acc loop directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70122 --- Comment #2 from vries at gcc dot gnu.org --- For now, marking missed-optimization/enhancement. There might also be correctness failures due to the lack of explicit handling, I'm not sure.
[Bug libgomp/70122] [openacc] Handle acc loop directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70122 --- Comment #3 from vries at gcc dot gnu.org --- (In reply to vries from comment #2) > For now, marking missed-optimization/enhancement. There might also be > correctness failures due to the lack of explicit handling, I'm not sure. Which is why I'd like to have it in stage4, if possible.
[Bug tree-optimization/70013] [6 Regression] packed structure tree-sra loses initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70013 --- Comment #9 from alalaw01 at gcc dot gnu.org --- In analyze_access_subtree (since r147980, "New implementation of SRA", 2009): else if (root->grp_write || TREE_CODE (root->base) == PARM_DECL) root->grp_unscalarized_data = 1; /* not covered and written to */ adding a case for constant_decl_p alongside the PARM_DECL case, fixes the ICE; AArch64 bootstrap in progress.
[Bug target/70117] ppc long double isinf() is wrong?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70117 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #3 from Alan Modra --- > while with GCC, we get: > > high double: 7FEF > low double: 7C8F FFFE Right. This is 0x1.f78p+1023 gnulib isn't correct here. As the comment says the high double must be the value of the long double correctly rounded to double (to nearest since that is the only mode supported for IBM extended double). Any long double value higher than the above will round up the high double to inf.
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 Tom Tromey changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #36 from Tom Tromey --- This came up for Mozilla today: https://groups.google.com/forum/#!topic/mozilla.dev.platform/YT7SXFhyr_I Essentially, this warning and the "intentional fallthrough" attribute exist for both clang and MSVC and will be enabled there; but GCC still doesn't have this feature.
[Bug middle-end/69920] [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69920 --- Comment #16 from Martin Jambor --- Author: jamborm Date: Mon Mar 7 15:17:49 2016 New Revision: 234030 URL: https://gcc.gnu.org/viewcvs?rev=234030&root=gcc&view=rev Log: Fix PR 69666 and PR 69920 2016-03-07 Martin Jambor PR tree-optimization/69666 PR middle-end/69920 * tree-sra.c (sra_modify_assign): Do not attempt to create default_def replacements for unscalarizable regions. Do not remove loads of uninitialized aggregates to SSA_NAMEs. testsuite/ * gcc.dg/torture/pr69932.c: New test. * gcc.dg/torture/pr69936.c: Likewise. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr69932.c branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr69936.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/tree-sra.c
[Bug tree-optimization/69666] [5 Regression] gcc ICE at -O2 and -O3 on valid code on x86_64-linux-gnu in "verify_gimple failed"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69666 --- Comment #13 from Martin Jambor --- Author: jamborm Date: Mon Mar 7 15:17:49 2016 New Revision: 234030 URL: https://gcc.gnu.org/viewcvs?rev=234030&root=gcc&view=rev Log: Fix PR 69666 and PR 69920 2016-03-07 Martin Jambor PR tree-optimization/69666 PR middle-end/69920 * tree-sra.c (sra_modify_assign): Do not attempt to create default_def replacements for unscalarizable regions. Do not remove loads of uninitialized aggregates to SSA_NAMEs. testsuite/ * gcc.dg/torture/pr69932.c: New test. * gcc.dg/torture/pr69936.c: Likewise. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr69932.c branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr69936.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/tree-sra.c
[Bug libstdc++/69879] Create a pointer to the default operator new and delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69879 Gabriel Ibarra changed: What|Removed |Added Attachment #37848|0 |1 is obsolete|| --- Comment #5 from Gabriel Ibarra --- Created attachment 37887 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37887&action=edit [RFC] Added default functions for new and delete operators + unit test. Hi, I added a new section (GLIBCXX_3.4.23) and a test file for this issue. Jonathan, I have a couple of questions: 1) When you say "it can't be applied until after GCC 6", you mean that my changes won't be commited until then? If you commit this now, how would you handle me using 4.23 as a version number? 2) If you commit this now, is there any way to make the unit test that I added run only for GLIBCXX_3.4.23? 3) And finally, how should I deal with the sized delete? Since it depends on the __cpp_sized_deallocation macro, should I add a test that also depends on this macro? Thanks, Gabriel
[Bug target/70048] [6 Regression][AArch64] Inefficient local array addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048 Jiong Wang changed: What|Removed |Added CC||jiwang at gcc dot gnu.org --- Comment #7 from Jiong Wang --- (In reply to Richard Henderson from comment #6) > Created attachment 37886 [details] > proposed patch > > I agree -- at minimum virtual and eliminable frame registers ought to be > special-cased. If we separate the constants too far, we'll never be able > to fold the constant plus the adjustment back together. > > If the statement in #c4 is taken at face value -- that r233136 was applied > to simplify frame-based array accesses... Well, I simply don't believe > that. > > I can see how the patch would aid reduction of access to members of a > structure that are in an array which in turn is *not* on the stack. But > for the average stack-based access I can't see except that it would hurt. (In reply to Richard Henderson from comment #6) > Created attachment 37886 [details] > proposed patch > > I agree -- at minimum virtual and eliminable frame registers ought to be > special-cased. If we separate the constants too far, we'll never be able > to fold the constant plus the adjustment back together. > > If the statement in #c4 is taken at face value -- that r233136 was applied > to simplify frame-based array accesses... Well, I simply don't believe > that. > > I can see how the patch would aid reduction of access to members of a > structure that are in an array which in turn is *not* on the stack. But > for the average stack-based access I can't see except that it would hurt. Richard, There is a similar hunk in aarch64 TARGET_LEGITIMATE_ADDRESS_P implementation (the "case PLUS" in aarch64_classify_address) which allows virtual frame reference be with any constant offset. if (! strict_p && REG_P (op0) && (op0 == virtual_stack_vars_rtx || op0 == frame_pointer_rtx || op0 == arg_pointer_rtx) Looks to me, your patch have handled situations where op0 are virtual_stack_dynamic_rtx and virtual_outgoing_args_rtx as well. Suppose offset elimination will happen on these two, then I think we should update the code in TARGET_LEGITIMATE_ADDRESS_P to use the same checks in your patch, then the two places are consitent.
[Bug tree-optimization/70116] tail-merge merges ubsan internal fns with different location information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70116 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #3 from vries at gcc dot gnu.org --- Patch committed, no test-case known. Marking resolved-fixed.
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 --- Comment #37 from Matthew Woehlke --- > Essentially, this warning and the "intentional fallthrough" attribute exist for both clang and MSVC and will be enabled there; but GCC still doesn't have this feature. [[fallthrough]] was approved for C++17. While the standard does not normatively *require* a diagnostic, it's certainly expected that one be issued. It's a shame that gcc is behind the curve here.
[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503 Thomas Preud'homme changed: What|Removed |Added Status|WAITING |RESOLVED CC||thopre01 at gcc dot gnu.org Resolution|--- |FIXED --- Comment #26 from Thomas Preud'homme --- Fixed as of r222512
[Bug target/70120] [aarch64] -mno-pc-relative-literal-loads -g causes Assembler messages: Error: unaligned opcodes detected in executable segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120 --- Comment #2 from Zdenek Sojka --- Created attachment 37888 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37888&action=edit another testcase This testcase does not need -mno-pc-relative-literal-loads. $ aarch64-unknown-linux-gnu-gcc -Og -freorder-functions -g3 -mcmodel=large testcase.c /tmp/cc4Fczxu.s: Assembler messages: /tmp/cc4Fczxu.s: Error: unaligned opcodes detected in executable segment
[Bug tree-optimization/69666] [5 Regression] gcc ICE at -O2 and -O3 on valid code on x86_64-linux-gnu in "verify_gimple failed"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69666 --- Comment #14 from Martin Jambor --- With the reverted patch re-applied, this should be again fixed everywhere (and the fix should not be causing any new issues).
[Bug target/70120] [6 Regression][aarch64] -freorder-functions -g causes Assembler messages: Error: unaligned opcodes detected in executable segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120 ktkachov at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.4, 5.3.1 Summary|[aarch64] |[6 Regression][aarch64] |-freorder-functions -g |-freorder-functions -g |causes Assembler messages: |causes Assembler messages: |Error: unaligned opcodes|Error: unaligned opcodes |detected in executable |detected in executable |segment |segment --- Comment #3 from ktkachov at gcc dot gnu.org --- Confirmed as well. That makes this a regression for GCC 6
[Bug target/70123] New: [6 Regression] Miscompilation of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70123
Bug ID: 70123
Summary: [6 Regression] Miscompilation of
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
The following testcase is miscompiled on s390x-linux with -O2 -m64
-march=z9-109 -mtune=z10 -fPIC starting with r222144.
It works with -mno-lra, so suspect either a LRA bug or machine description bug.
The effect is that the
186 for (h = 0; h < g; h++)
187 baz (" %2d", t[h]);
loop iterates until &t[h] is unaccessible. But g should be at most 20, so h
certainly shouldn't be almost 5000.
-fsanitize=undefined,address and valgrind is clean on this on x86_64-linux.
__attribute__ ((noinline, noclone)) int
bar (int flag, const char *__restrict format, ...)
{
asm volatile ("" : : "r" (flag), "r" (format) : "memory");
return 0;
}
extern inline __attribute__ ((__always_inline__, __gnu_inline__,
__artificial__)) int
baz (const char *__restrict fmt, ...)
{
return bar (1, fmt, __builtin_va_arg_pack ());
}
__attribute__ ((noinline, noclone)) int
f1 (void **a, const char *b, int *c)
{
*a = 0;
*c = 0;
asm volatile ("" : : "r" (&a), "r" (b), "r" (&c) : "memory");
return 0;
}
__attribute__ ((noinline, noclone)) int
f2 (void *a, int b, int c, long d[], int *e)
{
asm volatile ("" : : "r" (a), "r" (b), "r" (c), "r" (d), "r" (e) : "memory");
return 1;
}
__attribute__ ((noinline, noclone)) int
f3 (void *a, int *b)
{
asm volatile ("" : : "r" (a), "r" (b) : "memory");
return 0;
}
__attribute__ ((noinline, noclone)) int
f4 (void *a, const char *b, int c, int d, double *e, int f, char **g, int *h)
{
asm volatile ("" : : "r" (a), "r" (b), "r" (c), "r" (d) : "memory");
asm volatile ("" : : "r" (e), "r" (f), "r" (g), "r" (h) : "memory");
return 0;
}
__attribute__ ((noinline, noclone)) int
f5 (void *a, long long b, int c, char **d, char **e, char **f, const char *g,
long long h, int *i)
{
asm volatile ("" : : "r" (a), "r" (b), "r" (c), "r" (d) : "memory");
asm volatile ("" : : "r" (e), "r" (f), "r" (g), "r" (h) : "memory");
asm volatile ("" : : "r" (i) : "memory");
return 0;
}
__attribute__ ((noinline, noclone)) int
f6 (void *a, int b, int *c, int *d)
{
asm volatile ("" : : "r" (a), "r" (b), "r" (c), "r" (d) : "memory");
return 0;
}
__attribute__ ((noinline, noclone)) int
f7 (void *a, int b, long long c, long long d, long long e, double *f, int *g)
{
asm volatile ("" : : "r" (a), "r" (b), "r" (c), "r" (d) : "memory");
asm volatile ("" : : "r" (e), "r" (f), "r" (g) : "memory");
return 0;
}
__attribute__ ((noinline, noclone)) int
f8 (void *a, int b, long long c, long long d, long long e, char *f, const char
**g, int *h, int *i)
{
asm volatile ("" : : "r" (a), "r" (b), "r" (c), "r" (d) : "memory");
asm volatile ("" : : "r" (e), "r" (f), "r" (g), "r" (h) : "memory");
asm volatile ("" : : "r" (i) : "memory");
return 0;
}
__attribute__ ((noinline, noclone)) int
f9 (void *a, int b, long long c, long long d, long long e, char *f, int *g)
{
asm volatile ("" : : "r" (a), "r" (b), "r" (c), "r" (d) : "memory");
asm volatile ("" : : "r" (e), "r" (f), "r" (g) : "memory");
return 0;
}
__attribute__ ((noinline, noclone)) int
f10 (void *a, int b, long long c, long long d, long long e, unsigned char f,
unsigned char *g, int *h, int *i)
{
asm volatile ("" : : "r" (a), "r" (b), "r" (c), "r" (d) : "memory");
asm volatile ("" : : "r" (e), "r" (f), "r" (g), "r" (h) : "memory");
asm volatile ("" : : "r" (i) : "memory");
return 0;
}
__attribute__ ((noinline, noclone)) int
f11 (void *a, int b, long long c, long long d, long long e, long f, long *g,
int *h, int *i)
{
asm volatile ("" : : "r" (a), "r" (b), "r" (c), "r" (d) : "memory");
asm volatile ("" : : "r" (e), "r" (f), "r" (g), "r" (h) : "memory");
asm volatile ("" : : "r" (i) : "memory");
return 0;
}
__attribute__ ((noinline, noclone)) int
f12 (void *a, int b, long long c, long long d, long long e, float f, float *g,
int *h, int *i)
{
asm volatile ("" : : "r" (a), "r" (b), "r" (c), "r" (d) : "memory");
asm volatile ("" : : "r" (e), "r" (f), "r" (g), "r" (h) : "memory");
asm volatile ("" : : "r" (i) : "memory");
return 0;
}
__attribute__ ((noinline, noclone)) int
f13 (void *a, int b, long long c, long *d, long *e, int *f)
{
asm volatile ("" : : "r" (a), "r" (b), "r" (c), "r" (d) : "memory");
asm volatile ("" : : "r" (e), "r" (f) : "memory");
return 0;
}
__attribute__ ((noinline, noclone)) int
f14 (void *a, int b, int *c, int *d)
{
asm volatile ("" : : "r" (a), "r" (b), "r" (c), "r" (d) : "memory");
return 0;
}
volatile int a;
int
main ()
{
int b, c, d = 0, e, f = 0;
long g, h;
int j = 0;
long k, l;
int m;
unsigned char n[21];
long o[21];
float p[21];
double
[Bug target/70117] ppc long double isinf() is wrong?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70117 --- Comment #4 from Ulrich Weigand --- (In reply to Alan Modra from comment #3) > > while with GCC, we get: > > > > high double: 7FEF > > low double: 7C8F FFFE > > Right. This is 0x1.f78p+1023 > > gnulib isn't correct here. As the comment says the high double must be the > value of the long double correctly rounded to double (to nearest since that > is the only mode supported for IBM extended double). Any long double value > higher than the above will round up the high double to inf. Well, what I don't quite understand is that the gnulib value, which is 0x1.f7cp+1023 likewise should round to the same double value, shouldn't it? I notice that if I actually attempt to use that value in C source code, the compiler does indeed round it to inf -- but I don't see why it actually should do so ...
[Bug target/70123] [6 Regression] Miscompilation of cfitsio testcase on s390x-linux starting with r222144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70123 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-07 CC||krebbel at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Target Milestone|--- |6.0 Summary|[6 Regression] |[6 Regression] |Miscompilation of |Miscompilation of cfitsio ||testcase on s390x-linux ||starting with r222144 Ever confirmed|0 |1
[Bug rtl-optimization/69633] [6 Regression] Redundant move is generated after r228097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69633 Bernd Schmidt changed: What|Removed |Added CC||bernds at gcc dot gnu.org --- Comment #2 from Bernd Schmidt --- Doesn't seem to happen over here. Can you still reproduce this with trunk? Please post exact arguments to cc1 if it does.
[Bug c++/70124] New: alignas error in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70124
Bug ID: 70124
Summary: alignas error in constexpr function
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: ---
Both attribute aligned and the alignas specifier are rejected with an error in
a constexpr function complaining that the alignment isn't a constant
expression. Attribute vector_size, on the other hand, is accepted in the same
context.
Note also that the diagnostic doesn't mention the value of the (constant)
argument or include the call site, making it difficult to determine which
invocation of the function caused the error when there is more than one.
$ cat x.c && /build/gcc-trunk-bootstrap/gcc/xg++ -B
/build/gcc-trunk-bootstrap/gcc -S -Wall -Wextra -Wpedantic -o/dev/null -xc++
x.c
constexpr int foo (unsigned N)
{
typedef __attribute__ ((aligned (1 << N))) int I;
I i = 0;
return i;
}
int i = foo (__alignof__ (int));
x.c: In function ‘constexpr int foo(unsigned int)’:
x.c:3:50: error: requested alignment is not an integer constant
typedef __attribute__ ((aligned (1 << N))) int I;
^
$ cat x.c && /build/gcc-trunk-bootstrap/gcc/xg++ -B
/build/gcc-trunk-bootstrap/gcc -S -Wall -Wextra -Wpedantic -o/dev/null -xc++
x.c
constexpr int foo (unsigned N)
{
alignas (1 << N) int i = 0;
return i;
}
int i = foo (__alignof__ (int));
x.c: In function ‘constexpr int foo(unsigned int)’:
x.c:3:17: error: ‘N’ is not a constant expression
alignas (1 << N) int i = 0;
^
x.c:3:17: error: ‘N’ is not a constant expression
[Bug lto/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 Bernd Schmidt changed: What|Removed |Added CC||bernds at gcc dot gnu.org --- Comment #8 from Bernd Schmidt --- Created attachment 37889 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37889&action=edit Candidate patch Testing this.
[Bug c++/70125] New: attributes diagnostics missing essential context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70125
Bug ID: 70125
Summary: attributes diagnostics missing essential context
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: ---
Diagnostics for attributes are missing information that can be essential in
determining the root cause of the problem. For example, the following test
case causes a warning pointing out that the attribute vector_size is ignored.
But there is no indication as to which of the two invocations of the function
in which the attribute is used causes the diagnostic. To help debug these
problems the diagnostic should include both the value of the vector_size
attribute and, for constexpr functions, the call stack.
$ cat x.c && /build/gcc-trunk-bootstrap/gcc/xg++ -B
/build/gcc-trunk-bootstrap/gcc -S -Wall -Wextra -Wpedantic -o/dev/null -xc++
x.c
constexpr int foo (unsigned N)
{
typedef int V __attribute__ ((vector_size (N)));
V v = 0;
return v;
}
int i = foo (1);
int j = foo (16);
x.c: In function ‘constexpr int foo(unsigned int)’:
x.c:3:49: warning: ‘vector_size’ attribute ignored [-Wattributes]
typedef int V __attribute__ ((vector_size (N)));
^
[Bug c++/70124] alignas error in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70124 --- Comment #1 from Martin Sebor --- Bug 70125 tracks the problem with the missing context of the diagnostic.
[Bug rtl-optimization/69052] [6 Regression] Performance regression after r229402.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69052 --- Comment #17 from amker at gcc dot gnu.org --- Author: amker Date: Mon Mar 7 16:39:27 2016 New Revision: 234034 URL: https://gcc.gnu.org/viewcvs?rev=234034&root=gcc&view=rev Log: PR rtl-optimization/69052 * rtlanal.c (commutative_operand_precedence): Set higher precedence to CONST_WIDE_INT. Modified: trunk/gcc/ChangeLog trunk/gcc/rtlanal.c
[Bug target/70120] [6 Regression][aarch64] -g causes Assembler messages: Error: unaligned opcodes detected in executable segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120 Zdenek Sojka changed: What|Removed |Added Summary|[6 Regression][aarch64] |[6 Regression][aarch64] -g |-freorder-functions -g |causes Assembler messages: |causes Assembler messages: |Error: unaligned opcodes |Error: unaligned opcodes|detected in executable |detected in executable |segment |segment | --- Comment #4 from Zdenek Sojka --- I have another testcase that fails with -Og -fno-dce -fno-forward-propagate -ffunction-sections -fno-tree-dce -g1 -mcmodel=tiny... so probably not caused by just -freorder-functions.
[Bug tree-optimization/69740] [5/6 Regression] gcc ICE at -O2 and above on valid code on x86_64-linux-gnu in "verify_loop_structure"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69740 --- Comment #12 from Jeffrey A. Law --- Author: law Date: Mon Mar 7 17:01:54 2016 New Revision: 234036 URL: https://gcc.gnu.org/viewcvs?rev=234036&root=gcc&view=rev Log: PR tree-optimization/69740 * cfghooks.c (remove_edge): Request loop fixups if we delete an edge that might turn an irreducible loop into a natural loop. * cfgloop.h (check_verify_loop_structure): Clear LOOPS_NEED_FIXUP. Move after definition of loops_state_clear. PR tree-optimization/69740 * gcc.c-torture/compile/pr69740-1.c: New test. * gcc.c-torture/compile/pr69740-2.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr69740-1.c trunk/gcc/testsuite/gcc.c-torture/compile/pr69740-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfghooks.c trunk/gcc/cfgloop.h trunk/gcc/testsuite/ChangeLog
[Bug c++/66786] [5/6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66786 --- Comment #8 from Patrick Palka --- Author: ppalka Date: Mon Mar 7 17:09:53 2016 New Revision: 234038 URL: https://gcc.gnu.org/viewcvs?rev=234038&root=gcc&view=rev Log: Adjust fix for PR c++/66786 gcc/cp/ChangeLog: PR c++/66786 * pt.c (get_template_info): Handle PARM_DECL. (template_class_depth): Check DECL_P instead of VAR_OR_FUNCTION_DECL_P. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug rtl-optimization/19705] -fno-branch-count-reg doesn't prevent decrement and branch instructions on a count register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19705 --- Comment #7 from Martin Sebor --- Author: msebor Date: Mon Mar 7 17:10:12 2016 New Revision: 234039 URL: https://gcc.gnu.org/viewcvs?rev=234039&root=gcc&view=rev Log: PR rtl-optimization/19705 - -fno-branch-count-reg doesn't prevent decrement and branch instructions on a count register gcc/ChangeLog: 2016-03-07 Martin Sebor PR rtl-optimization/19705 * doc/invoke.texi (Options That Control Optimization): Clarify -fno-branch-count-reg. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
