[Bug ipa/82801] [6/7/8 Regression] Internal compiler error with Eigen and __attribute__((always_inline, flatten))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82801 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-02 CC||trippels at gcc dot gnu.org Known to work||4.9.4 Summary|Internal compiler error |[6/7/8 Regression] Internal |with Eigen and |compiler error with Eigen |__attribute__((always_inlin |and |e, flatten))|__attribute__((always_inlin ||e, flatten)) Ever confirmed|0 |1 --- Comment #2 from Markus Trippelsdorf --- Confirmed. The reduced testcase is fine.
[Bug ipa/82801] [6/7/8 Regression] Internal compiler error with Eigen and __attribute__((always_inline, flatten))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82801
--- Comment #3 from Markus Trippelsdorf ---
node->decl is NULL, so perhaps:
diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
index b8e65e2fa7ec..1713c41d4369 100644
--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-inline.c
@@ -2425,7 +2425,7 @@ ipa_inline (void)
entry of cycles, possibly cloning that entry point and
try to flatten itself turning it into a self-recursive
function. */
- if (lookup_attribute ("flatten",
+ if (node->decl && lookup_attribute ("flatten",
DECL_ATTRIBUTES (node->decl)) != NULL)
{
if (dump_file)
[Bug ipa/82801] [6/7/8 Regression] Internal compiler error with Eigen and __attribute__((always_inline, flatten))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82801 Martin Liška changed: What|Removed |Added CC||hubicka at ucw dot cz, ||jamborm at gcc dot gnu.org Known to fail||5.4.0, 6.3.0, 7.2.0, 8.0 --- Comment #4 from Martin Liška --- Thanks for that. Btw. started with r218024. I think we can't check for node->decl as the node is removed in time it's checked: cgraph dump: ... Removing unused symbols: A< >::A() [with int = 1] ... ipa inline dump: Flattening functions: Flattening double B::m_fn1() const Inlining A< >::A() [with int = 1] into double B::m_fn1() const. Estimating body: A< >::A() [with int = 1]/3 Known to be false: not inlined size:0 time:0.00 nonspec time:2.00 That said proper fix would be probably to have a cgraph node removal hook that will register removed nodes that will be skipping in main flattening loop. Do we face a similar problem somewhere else in inliner?
[Bug target/82795] [8 Regression] ICE in predicate_mem_writes, at tree-if-conv.c:2251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82795 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-02 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r253933.
[Bug sanitizer/82802] Potential UBSAN error with pointer difference (32-bits mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82802
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-11-02
CC||dodji at gcc dot gnu.org,
||dvyukov at gcc dot gnu.org,
||jakub at gcc dot gnu.org,
||kcc at gcc dot gnu.org,
||marxin at gcc dot gnu.org,
||mpolacek at gcc dot gnu.org
Component|c |sanitizer
Target Milestone|--- |6.5
Ever confirmed|0 |1
--- Comment #1 from Martin Liška ---
Confirmed, there's small reproducer:
$ cat pr82802.c
int main()
{
int *high = 0x80007800;
int *low = 0x70018AAB;
return high - low;
}
$ gcc pr82802.c -fsanitize=undefined -m32 && ./a.out
pr82802.c: In function ‘main’:
pr82802.c:3:15: warning: initialization makes pointer from integer without a
cast [-Wint-conversion]
int *high = 0x80007800;
^~
pr82802.c:4:14: warning: initialization makes pointer from integer without a
cast [-Wint-conversion]
int *low = 0x70018AAB;
^~
pr82802.c:6:15: runtime error: signed integer overflow: -2147452928 -
1879149227 cannot be represented in type 'int'
[Bug c++/82793] __attribute__((target("sse"))) causes call throught ifunc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82793 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- I'll take a look.
[Bug target/82804] New: [7/8 Regression] SPEC CPU2006 470.lbm ~5% performance deviation with r237185
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82804 Bug ID: 82804 Summary: [7/8 Regression] SPEC CPU2006 470.lbm ~5% performance deviation with r237185 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Starting with the revision we lost about ~5 on Zen wit -O2 -mtune=native.
[Bug c/82765] [6/7 Regression] ICE at -Os on valid code on x86_64-linux-gnu: in tree_to_shwi, at tree.c:6611
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82765 Richard Biener changed: What|Removed |Added Known to work||8.0 Summary|[6/7/8 Regression] ICE at |[6/7 Regression] ICE at -Os |-Os on valid code on|on valid code on |x86_64-linux-gnu: in|x86_64-linux-gnu: in |tree_to_shwi, at|tree_to_shwi, at |tree.c:6611 |tree.c:6611 --- Comment #6 from Richard Biener --- Fixed on trunk sofar. --- Comment #7 from Richard Biener --- Author: rguenth Date: Thu Nov 2 08:28:18 2017 New Revision: 254337 URL: https://gcc.gnu.org/viewcvs?rev=254337&root=gcc&view=rev Log: 2017-11-02 Richard Biener PR middle-end/82765 * varasm.c (decode_addr_const): Make offset HOST_WIDE_INT. Truncate ARRAY_REF index and element size. * gcc.dg/pr82765.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr82765.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/varasm.c
[Bug c/82765] [6/7 Regression] ICE at -Os on valid code on x86_64-linux-gnu: in tree_to_shwi, at tree.c:6611
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82765 Richard Biener changed: What|Removed |Added Known to work||8.0 Summary|[6/7/8 Regression] ICE at |[6/7 Regression] ICE at -Os |-Os on valid code on|on valid code on |x86_64-linux-gnu: in|x86_64-linux-gnu: in |tree_to_shwi, at|tree_to_shwi, at |tree.c:6611 |tree.c:6611 --- Comment #6 from Richard Biener --- Fixed on trunk sofar.
[Bug fortran/82774] [6/7/8 Regression] Structure constructor and deferred type parameter character component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82774 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.5
[Bug testsuite/82770] [8 regression] gcc.dg/pr78768.c xpass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82770 Richard Biener changed: What|Removed |Added Component|lto |testsuite Target Milestone|--- |8.0
[Bug hsa/82771] FAIL: brig.dg/test/gimple/packed.hsail (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82771 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener --- Fixed I assume.
[Bug tree-optimization/82776] Unable to optimize the loop when iteration count is unavailable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-02 Version|unknown |8.0 Ever confirmed|0 |1
[Bug rtl-optimization/82778] crash: insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82778 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed then.
[Bug target/82804] [7/8 Regression] SPEC CPU2006 470.lbm ~5% performance deviation with r237185
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82804 --- Comment #1 from Martin Liška --- Created attachment 42520 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42520&action=edit perf annotate
[Bug target/82804] [7/8 Regression] SPEC CPU2006 470.lbm ~5% performance deviation with r237185
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82804 --- Comment #2 from Martin Liška --- Created attachment 42521 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42521&action=edit perf report
[Bug target/82804] [7/8 Regression] SPEC CPU2006 470.lbm ~5% performance deviation with r237185
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82804 --- Comment #3 from Martin Liška --- Created attachment 42522 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42522&action=edit perf diff
[Bug target/82804] [7/8 Regression] SPEC CPU2006 470.lbm ~5% performance deviation with r237185
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82804 --- Comment #4 from Martin Liška --- Created attachment 42523 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42523&action=edit perf annotate
[Bug target/82804] [7/8 Regression] SPEC CPU2006 470.lbm ~5% performance deviation with r237185
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82804 --- Comment #5 from Martin Liška --- Created attachment 42524 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42524&action=edit perf report
[Bug c++/82781] [6/7/8 Regression] Vector extension operators return wrong result in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82781 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/82805] [7/8 Regression] SPEC CPU2006 454.calculix ~6% performance deviation in between 6.3 and 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82805 --- Comment #1 from Martin Liška --- Created attachment 42525 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42525&action=edit perf report
[Bug target/82805] New: [7/8 Regression] SPEC CPU2006 454.calculix ~6% performance deviation in between 6.3 and 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82805 Bug ID: 82805 Summary: [7/8 Regression] SPEC CPU2006 454.calculix ~6% performance deviation in between 6.3 and 7.2 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- We lost about 6% on Zen with -O2 -mtune=generic in between these 2 releases. It's quite hard to bisect a single revision.
[Bug target/82805] [7/8 Regression] SPEC CPU2006 454.calculix ~6% performance deviation in between 6.3 and 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82805 --- Comment #2 from Martin Liška --- Created attachment 42526 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42526&action=edit perf report
[Bug target/82804] [7/8 Regression] SPEC CPU2006 470.lbm ~5% performance deviation with r237185
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82804 --- Comment #6 from Martin Liška --- Can't be reproduced on Haswell.
[Bug driver/82806] New: Stabilize paths in assembler and dumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82806 Bug ID: 82806 Summary: Stabilize paths in assembler and dumps Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- Recently I've run into the following issues: 1. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82415 "Bug 82415 - FAIL: gcc.target/i386/naked-1.c scan-assembler-not ret". I build and tested gcc in a directory with "ret" in the path, and an assembler scan triggered on that. 2. https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00055.html. I build and tested gcc in a directory with "while" in the path, and a tree-dump scan triggered on that. I wonder if we can add a gcc option -fstrip-path[=] that strips (or replaces with a constant string) paths in compiler output such as dumps and assembler. By using by default fstrip-path="stripped-path" or some such in the testsuite, we can stabilize compiler output and reduce noise in the testsuite.
[Bug target/82805] [7/8 Regression] SPEC CPU2006 454.calculix ~6% performance deviation in between 6.3 and 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82805 --- Comment #3 from Martin Liška --- Created attachment 42528 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42528&action=edit perf diff
[Bug target/82807] New: [7/8 Regression] SPEC CPU2006 473.astar ~6% performance deviation in between 6.3 and 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82807 Bug ID: 82807 Summary: [7/8 Regression] SPEC CPU2006 473.astar ~6% performance deviation in between 6.3 and 7.2 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- We lost about 6% on Zen with -Ofast -mtune=generic in between these 2 releases. It's quite hard to bisect a single revision.
[Bug target/82807] [7/8 Regression] SPEC CPU2006 473.astar ~6% performance deviation in between 6.3 and 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82807 --- Comment #2 from Martin Liška --- Created attachment 42530 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42530&action=edit perf report
[Bug target/82807] [7/8 Regression] SPEC CPU2006 473.astar ~6% performance deviation in between 6.3 and 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82807 --- Comment #1 from Martin Liška --- Created attachment 42529 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42529&action=edit perf annotate
[Bug target/82807] [7/8 Regression] SPEC CPU2006 473.astar ~6% performance deviation in between 6.3 and 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82807 --- Comment #3 from Martin Liška --- Created attachment 42531 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42531&action=edit perf annotate
[Bug target/82807] [7/8 Regression] SPEC CPU2006 473.astar ~6% performance deviation in between 6.3 and 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82807 --- Comment #4 from Martin Liška --- Created attachment 42532 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42532&action=edit perf report
[Bug target/82807] [7/8 Regression] SPEC CPU2006 473.astar ~6% performance deviation in between 6.3 and 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82807 --- Comment #5 from Martin Liška --- Created attachment 42533 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42533&action=edit perf diff
[Bug testsuite/82415] FAIL: gcc.target/i386/naked-1.c scan-assembler-not ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82415
--- Comment #3 from Tom de Vries ---
Author: vries
Date: Thu Nov 2 09:07:27 2017
New Revision: 254338
URL: https://gcc.gnu.org/viewcvs?rev=254338&root=gcc&view=rev
Log:
Fix scan-assembler patterns in i386/naked-{1,2}.c
2017-11-02 Tom de Vries
PR testsuite/82415
* gcc.target/i386/naked-1.c: Make scan patterns more precise.
* gcc.target/i386/naked-2.c: Same.
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/naked-1.c
trunk/gcc/testsuite/gcc.target/i386/naked-2.c
[Bug ipa/82808] New: LTO clone wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82808
Bug ID: 82808
Summary: LTO clone wrong value
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: npickito at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Target: x86-64
Version: trunk@254336, 7.x
* work on 6.x
Option:
gcc case.c -O2 -fno-inline -flto
How to reproduce:
./a.out
Aborted (core dumped)
Expect:
exited normally
Case:
void foo(double *a, double x)
{
*a = x;
}
double f_c1(int m, double *a)
{
foo(a, m);
return *a;
}
int main(){
double data;
double ret = 0 ;
if ((ret = f_c1(2, &data)) != 2)
{
__builtin_abort ();
}
return 0;
}
Symptom:
`x` in `foo` seems like propagated as 0.
Code gen in x86_64
foo.constprop.1:
.LFB3:
.cfi_startproc
movq$0x0, (%rdi)
ret
.cfi_endproc
.LFE3:
.size foo.constprop.1, .-foo.constprop.1
.p2align 4,,15
.type f_c1.constprop.0, @function
[Bug target/82809] New: [8 Regression] ICE in in ix86_vector_duplicate_value, at config/i386/i386.c:41242
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82809 Bug ID: 82809 Summary: [8 Regression] ICE in in ix86_vector_duplicate_value, at config/i386/i386.c:41242 Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: alan.hayward at arm dot com, david.sherwood at arm dot com, richard.sandiford at linaro dot org Target Milestone: --- Host: x86_64-linux-gnu Target: x86_64-linux-gnu Starting from r254292 we ICE on: $ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/pr52199.c -Ofast -fno-tree-dominator-opts during RTL pass: expand /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/pr52199.c: In function ‘time_read’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/pr52199.c:22:24: internal compiler error: in ix86_vector_duplicate_value, at config/i386/i386.c:41242 time->abday[cnt] = ""; ~^~~~ 0xef478e ix86_vector_duplicate_value ../../gcc/config/i386/i386.c:41242 0xf0f479 ix86_expand_vector_init_duplicate ../../gcc/config/i386/i386.c:41365 0xf439b7 ix86_expand_vector_init(bool, rtx_def*, rtx_def*) ../../gcc/config/i386/i386.c:42206 0x117013d gen_vec_initv2sfsf(rtx_def*, rtx_def*) ../../gcc/config/i386/mmx.md:660 0x87bcde insn_gen_fn::operator()(rtx_def*, rtx_def*) const ../../gcc/recog.h:301 0x87bcde store_constructor ../../gcc/expr.c:6709 0x87cda5 expand_constructor ../../gcc/expr.c:8006 0x86a341 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:10105 0x86b813 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:9791 0x879da7 expand_expr ../../gcc/expr.h:276 0x879da7 expand_assignment(tree_node*, tree_node*, bool) ../../gcc/expr.c:4947 0x74fbf8 expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3676 0x74fbf8 expand_gimple_stmt ../../gcc/cfgexpand.c:3774 0x751f07 expand_gimple_basic_block ../../gcc/cfgexpand.c:5779 0x758426 execute ../../gcc/cfgexpand.c:6385
[Bug testsuite/82415] FAIL: gcc.target/i386/naked-1.c scan-assembler-not ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82415 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Tom de Vries --- Test-case fixed, marking resolved-fixed.
[Bug ipa/82808] [7/8 Regression] LTO clone wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82808
Martin Liška changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-11-02
CC||jamborm at gcc dot gnu.org,
||kugan at gcc dot gnu.org
Target Milestone|--- |7.3
Summary|LTO clone wrong value |[7/8 Regression] LTO clone
||wrong value
Ever confirmed|0 |1
--- Comment #1 from Martin Liška ---
Confirmed, we really wrongly propagate 0 to x:
$ cat xxx.ltrans0.075i.cp
;; Function foo.constprop (foo.constprop.1, funcdef_no=3, decl_uid=4078,
cgraph_uid=1, symbol_order=5) (executed once)
Modification phase of node foo.constprop/5
Adjusting mask for param 0 to 0x0
Setting nonnull for 0
foo.constprop (double * a)
{
double x;
[100.00%] [count: INV]:
[100.00%] [count: INV]:
*a_2(D) = x_1(D);
return;
}
Started with r241990.
[Bug target/82805] [7/8 Regression] SPEC CPU2006 454.calculix ~6% performance deviation in between 6.3 and 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82805 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #4 from Jan Hubicka --- Caluculix also sees smaller regression on Haswell due to the vectorization costmodel change. I will try to take a look.
[Bug middle-end/82810] New: missed uninitialized variable warning in for/while loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82810
Bug ID: 82810
Summary: missed uninitialized variable warning in for/while
loop
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.smets at nokia dot com
Target Milestone: ---
In the following code x clearly is used uninitialized
#include
int main(void)
{
while (1)
{
int x;
printf("x=%d\n", x);
x = 0;
}
return 0;
}
Possibly dup of 82101 ?
[Bug c++/82790] [GCC 5, 6, 7] -Wuseless-cast doesn't detect unnecessary removal of const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82790 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-02 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Confirmed.
[Bug sanitizer/82517] use-after-scope for a variable with big alignment causes a false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82517 Martin Liška changed: What|Removed |Added Known to work|8.0 | Known to fail||8.0 --- Comment #4 from Martin Liška --- Reopening for trunk as it should check for: BITS_PER_UNIT * ASAN_SHADOW_GRANULARITY <= MAX_SUPPORTED_STACK_ALIGNMENT.
[Bug target/82795] [8 Regression] ICE in predicate_mem_writes, at tree-if-conv.c:2251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82795 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Mine. *sigh*
[Bug target/82811] New: Assembler error on tic6x-none-elf with march=c64x+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82811
Bug ID: 82811
Summary: Assembler error on tic6x-none-elf with march=c64x+
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: g.hoogewerf at gmail dot com
Target Milestone: ---
The following test case triggers an error on several versions of GCC, including
7.2.0 and 4.9.4. I tried several versions of binutils, including 2.20 and
2.26.1.
long long test(long long a, long long b)
{
long long c = 0;
c |= ((a & 0x) << 0);
c |= (b << 16);
return c;
}
To trigger the error, the source should be compiled with: "-march=c64x+ -O2".
The error does not occur when building with "-march=c67x+".
When running with -v -save-temps, the output is:
Using built-in specs.
COLLECT_GCC=./tools/i686-pc-linux-gnu/tic6x-none-elf/bin/tic6x-none-elf-gcc
Target: tic6x-none-elf
Configured with: /home/ghoogewerf/GccBuild/src/gcc/configure
--prefix=/home/ghoogewerf/GccBuild/build/tic6x-none-elf-newlib/tools/i686-pc-linux-gnu/tic6x-none-elf
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=tic6x-none-elf
--enable-languages=c,c++ --disable-libssp --disable-wchar_t --disable-multilib
--with-pkgversion='Test G++ 7.2.0-p3' --disable-nls --disable-fixed-point
--disable-decimal-float --with-arch=c64x+ --disable-lto --with-newlib
--with-headers=/home/ghoogewerf/GccBuild/src/newlib/newlib/libc/include
Thread model: single
gcc version 7.2.0 (Test G++ 7.2.0-p3)
COLLECT_GCC_OPTIONS='-c' '-O2' '-Wall' '-Wextra' '-march=c64x+' '-v'
'-save-temps'
/home/ghoogewerf/GccBuild/build/tic6x-none-elf-newlib/tools/i686-pc-linux-gnu/tic6x-none-elf/libexec/gcc/tic6x-none-elf/7.2.0/cc1
-E -quiet -v pack.c -march=c64x+ -Wall -Wextra -O2 -fpch-preprocess -o pack.i
#include "..." search starts here:
#include <...> search starts here:
/home/ghoogewerf/GccBuild/build/tic6x-none-elf-newlib/tools/i686-pc-linux-gnu/tic6x-none-elf/lib/gcc/tic6x-none-elf/7.2.0/include
/home/ghoogewerf/GccBuild/build/tic6x-none-elf-newlib/tools/i686-pc-linux-gnu/tic6x-none-elf/lib/gcc/tic6x-none-elf/7.2.0/include-fixed
/home/ghoogewerf/GccBuild/build/tic6x-none-elf-newlib/tools/i686-pc-linux-gnu/tic6x-none-elf/lib/gcc/tic6x-none-elf/7.2.0/../../../../tic6x-none-elf/sys-include
/home/ghoogewerf/GccBuild/build/tic6x-none-elf-newlib/tools/i686-pc-linux-gnu/tic6x-none-elf/lib/gcc/tic6x-none-elf/7.2.0/../../../../tic6x-none-elf/include
End of search list.
COLLECT_GCC_OPTIONS='-c' '-O2' '-Wall' '-Wextra' '-march=c64x+' '-v'
'-save-temps'
/home/ghoogewerf/GccBuild/build/tic6x-none-elf-newlib/tools/i686-pc-linux-gnu/tic6x-none-elf/libexec/gcc/tic6x-none-elf/7.2.0/cc1
-fpreprocessed pack.i -quiet -dumpbase pack.c -march=c64x+ -auxbase pack -O2
-Wall -Wextra -version -o pack.s
GNU C11 (Test G++ 7.2.0-p3) version 7.2.0 (tic6x-none-elf)
compiled by GNU C version 4.9.4, GMP version 6.1.0, MPFR version 3.1.3,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (Test G++ 7.2.0-p3) version 7.2.0 (tic6x-none-elf)
compiled by GNU C version 4.9.4, GMP version 6.1.0, MPFR version 3.1.3,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: f86a3322b854da36fc325771f0c6992e
COLLECT_GCC_OPTIONS='-c' '-O2' '-Wall' '-Wextra' '-march=c64x+' '-v'
'-save-temps'
/home/ghoogewerf/GccBuild/build/tic6x-none-elf-newlib/tools/i686-pc-linux-gnu/tic6x-none-elf/lib/gcc/tic6x-none-elf/7.2.0/../../../../tic6x-none-elf/bin/as
-march=c64x+ -o pack.o pack.s
pack.s: Assembler messages:
pack.s:15: Error: operand 1 of 'pack2' on wrong side
Thanks,
G. Hoogewerf
[Bug fortran/82796] [6/7/8 Regression] Private+equivalence in used module breaks compilation of pure function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82796 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.5
[Bug c++/82797] Suggest -Wshadow suppression for nested if/else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82797 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-02 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug c++/82799] [8 Regression] -Wunused-but-set-variable false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82799 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug ipa/82801] [6/7/8 Regression] Internal compiler error with Eigen and __attribute__((always_inline, flatten))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82801 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.5
[Bug target/82804] [7/8 Regression] SPEC CPU2006 470.lbm ~5% performance deviation with r237185
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82804 Richard Biener changed: What|Removed |Added Version|unknown |7.2.0 Target Milestone|--- |7.3
[Bug sanitizer/82802] Potential UBSAN error with pointer difference (32-bits mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82802 Richard Biener changed: What|Removed |Added CC||glisse at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target Milestone|6.5 |--- Known to fail||5.4.0, 7.2.0 --- Comment #2 from Richard Biener --- I think this was noted by Jakub somewhere - the FE converts the pointers to signed integer for the subtraction which causes the issue for pointers into objects that "wrap" around the "half" address-space. POINTER_DIFF_EXPR is supposed to allow fixing this. A band-aid would be to perform the subtraction in an unsigned type, then casting the result to a signed type to do the division by the element size. I think Jakub did this and there was some fallout.
[Bug target/82812] New: ICE in emit_move_insn, at expr.c:3706
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82812 Bug ID: 82812 Summary: ICE in emit_move_insn, at expr.c:3706 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: julia.koval at intel dot com, kyukhin at gcc dot gnu.org Target Milestone: --- Target: x86_64-linux-gnu A GFNI fails starting from r254250: $ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/gfni-3.c -mgfni during RTL pass: expand In file included from /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/include/immintrin.h:95:0, from /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/include/x86intrin.h:48, from /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/gfni-3.c:6: /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/gfni-3.c: In function ‘avx512vl_test’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/gfni-3.c:15:10: internal compiler error: in emit_move_insn, at expr.c:3703 x3 = _mm256_gf2p8affineinv_epi64_epi8(x3, x4, 3); ^~~~ 0x8d4cba emit_move_insn(rtx_def*, rtx_def*) ../../gcc/expr.c:3702 0x8b7342 copy_to_reg(rtx_def*) ../../gcc/explow.c:591 0xfec6d6 ix86_expand_args_builtin ../../gcc/config/i386/i386.c:34113 0xff96ef ix86_expand_builtin ../../gcc/config/i386/i386.c:37244 0x77d6e5 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) ../../gcc/builtins.c:6512 0x8d1269 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:10847 0x8dceb3 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool, tree_node*) ../../gcc/expr.c:5551 0x8de6b7 expand_assignment(tree_node*, tree_node*, bool) ../../gcc/expr.c:5319 0x7ad8ed expand_call_stmt ../../gcc/cfgexpand.c:2672 0x7b0cd8 expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3608 0x7b13ce expand_gimple_stmt ../../gcc/cfgexpand.c:3774 0x7b8f02 expand_gimple_basic_block ../../gcc/cfgexpand.c:5779 0x7ba92f execute ../../gcc/cfgexpand.c:6385
[Bug target/82812] ICE in emit_move_insn, at expr.c:3706
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82812 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-02 Target Milestone|--- |8.0 Ever confirmed|0 |1
[Bug target/82795] [8 Regression] ICE in predicate_mem_writes, at tree-if-conv.c:2251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82795 --- Comment #3 from Richard Biener --- Well, not really a "regression", it was broken before the original fix. The assert is simply bogus.
[Bug target/56412] [4.8] "libtool: cygpath: command not found" for mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56412 Eric Gallager changed: What|Removed |Added Status|WAITING |SUSPENDED --- Comment #8 from Eric Gallager --- (In reply to Eric Gallager from comment #7) > (In reply to Kai Tietz from comment #6) > > Yes, this is a libtool bug. If thing is solved on libtool, then we can > > continue on that. So long I set bug in status waiting > > If there's an upstream URL for the libtool bug report, we can set it to > RESOLVED MOVED instead of WAITING. changing it to SUSPENDED instead for now since no one from gcc is working on it, but I still want to move it out of the WAITING queue and don't want to close it either
[Bug rtl-optimization/57970] segfault in sched-deps.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57970 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #7 from Eric Gallager --- (In reply to Eric Gallager from comment #6) > (In reply to Chris King from comment #5) > > Would a unit test case be acceptable? That should be an easy way to evince > > this bug and I'd be glad to write one. > > It might not've been when you wrote this, but I guess now that David Malcolm > has added unit testing capabilities to gcc, maybe... > (See gcc/selftest.h and gcc/selftest.c for info) Since there's been no response with even a unit-test since then, closing due to lack of reproducibility.
[Bug fortran/53077] replace "Illegal preprocessor directive" message with "Ignoring preprocessor directive at %C. Use -cpp to enable the C preprocessor" (a patch by Tobias included)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53077 Eric Gallager changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |dominiq at lps dot ens.fr --- Comment #8 from Eric Gallager --- (In reply to Eric Gallager from comment #7) > (In reply to Dominique d'Humieres from comment #6) > > Is there any objection if I do the testing and packaging for the patch in > > comment 4? > > No objection seen; go for it! In fact, I'll even assign it to you since you expressed interest.
[Bug target/82809] [8 Regression] ICE in in ix86_vector_duplicate_value, at config/i386/i386.c:41242
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82809 Richard Biener changed: What|Removed |Added Version|unknown |8.0 Target Milestone|--- |8.0
[Bug ipa/82808] [7/8 Regression] LTO clone wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82808 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/82807] [7/8 Regression] SPEC CPU2006 473.astar ~6% performance deviation in between 6.3 and 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82807 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Version|unknown |7.2.0 Target Milestone|--- |7.3
[Bug target/82805] [7/8 Regression] SPEC CPU2006 454.calculix ~6% performance deviation in between 6.3 and 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82805 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Version|unknown |7.2.0 Target Milestone|--- |7.3
[Bug target/82812] ICE in emit_move_insn, at expr.c:3706
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82812 Richard Biener changed: What|Removed |Added Version|unknown |8.0 Target Milestone|8.0 |---
[Bug target/59865] gnu multiversion calculates wrong target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59865 --- Comment #4 from Eric Gallager --- (In reply to Eric Gallager from comment #3) > > I can't reproduce this bug due to my target lacking ifunc support. Someone > with a more capable target will need to test to be able to move this bug out > of WAITING. Now that I have access to the gcc compile farm, I have been able to test on x86_64-pc-linux-gnu, and I get an assemble failure instead of an executable: egallager@gcc12:~$ /opt/cfarm/gcc-latest/bin/gcc 59865.C -S -Wall -Wextra egallager@gcc12:~$ /opt/cfarm/gcc-latest/bin/gcc 59865.C -o 59865.exe /tmp/cc2p5hY8.s: Assembler messages: /tmp/cc2p5hY8.s:158: Error: unrecognized symbol type "gnu_indirect_function" egallager@gcc12:~$ grep movl 59865.s | grep foov movl$_Z3foov.popcnt, %eax movl$_Z3foov.arch_corei7, %eax movl$_Z3foov, %eax egallager@gcc12:~$
[Bug ipa/82808] [7/8 Regression] LTO clone wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82808 --- Comment #2 from prathamesh3492 at gcc dot gnu.org --- Works fine with -O2 -fno-inline, but aborts with -flto -O2 -fno-inline. Does this possibly indicate an issue with streaming ? Thanks, Prathamesh
[Bug ipa/82808] [7/8 Regression] LTO clone wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82808 --- Comment #3 from prathamesh3492 at gcc dot gnu.org --- (In reply to prathamesh3492 from comment #2) > Works fine with -O2 -fno-inline, but aborts with -flto -O2 -fno-inline. > Does this possibly indicate an issue with streaming ? Oops, no. Changing the definitions to static makes the test-case abort with -O2. Sorry for the noise. > > Thanks, > Prathamesh
[Bug target/82809] [8 Regression] ICE in in ix86_vector_duplicate_value, at config/i386/i386.c:41242
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82809 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-11-02 CC||rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from rsandifo at gcc dot gnu.org --- Looking.
[Bug target/82809] [8 Regression] ICE in in ix86_vector_duplicate_value, at config/i386/i386.c:41242
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82809 --- Comment #2 from rsandifo at gcc dot gnu.org --- Created attachment 42534 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42534&action=edit Candidate fix This patch seems to fix it. Only lightly tested so far.
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 --- Comment #30 from H.J. Lu --- (In reply to Eric Gallager from comment #29) > > I don't remember the exact commit number but HJ Lu added it; I added him on > cc with my previous comment, so maybe he can explain. It is r251180.
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 --- Comment #31 from Sven --- https://gcc.gnu.org/viewcvs/gcc/trunk/?view=log&pathrev=251180 I am reading the commit message, and the example doesn't make any sense. The aligned attribute is for providing additional alignment guarantees in addition to the types default alignment. In particular, the documentation of the aligned type attribute specifically states, that this attribute cannot decrease alignment. It can only _increase_ alignment. In particular, aligned(4) in combination with a 64bit type makes little sense.
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 --- Comment #32 from H.J. Lu --- (In reply to Sven from comment #31) > https://gcc.gnu.org/viewcvs/gcc/trunk/?view=log&pathrev=251180 > > I am reading the commit message, and the example doesn't make any sense. > The aligned attribute is for providing additional alignment guarantees in > addition to the types default alignment. In particular, the documentation of > the aligned type attribute specifically states, that this attribute cannot > decrease alignment. It can only _increase_ alignment. > > In particular, aligned(4) in combination with a 64bit type makes little > sense. long long is aligned to 4 bytes in struct for i386.
[Bug target/82795] [8 Regression] ICE in predicate_mem_writes, at tree-if-conv.c:2251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82795 --- Comment #4 from Richard Biener --- Author: rguenth Date: Thu Nov 2 13:13:53 2017 New Revision: 254342 URL: https://gcc.gnu.org/viewcvs?rev=254342&root=gcc&view=rev Log: 2017-11-02 Richard Biener PR tree-optimization/82795 * tree-if-conv.c (predicate_mem_writes): Remove bogus assert. * gcc.target/i386/pr82795.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/i386/pr82795.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #33 from H.J. Lu ---
[hjl@gnu-skl-1 gcc]$ cat x.c
#include
#include
typedef int aligned_int __attribute__((warn_if_not_aligned(4)));
int main(void)
{
struct foo {
char c;
aligned_int x;
} __attribute__((packed));
struct foo arr[2] = { { 'a', 10 }, {'b', 20 } };
int *p0 = &arr[0].x;
int *p1 = &arr[1].x;
printf("sizeof(struct foo) = %d\n",
(int)sizeof(struct foo));
printf("offsetof(struct foo, c) = %d\n",
(int)offsetof(struct foo, c));
printf("offsetof(struct foo, x) = %d\n",
(int)offsetof(struct foo, x));
printf("arr[0].x = %d\n", arr[0].x);
printf("arr[1].x = %d\n", arr[1].x);
printf("p0 = %p\n", (void*)p0);
printf("p1 = %p\n", (void*)p1);
printf("*p0 = %d\n", *p0);
printf("*p1 = %d\n", *p1);
return 0;
}
[hjl@gnu-skl-1 gcc]$ ./xgcc -B./ -S x.c -Wall
x.c: In function \u2018main\u2019:
x.c:9:5: warning: alignment 1 of \u2018struct foo\u2019 is less than 4
[-Wif-not-aligned]
} __attribute__((packed));
^
x.c:8:14: warning: \u2018x\u2019 offset 1 in \u2018struct foo\u2019 isn't
aligned to 4 [-Wif-not-aligned]
aligned_int x;
^
[hjl@gnu-skl-1 gcc]$
[Bug ipa/82808] [7/8 Regression] LTO clone wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82808 --- Comment #4 from prathamesh3492 at gcc dot gnu.org --- Created attachment 42535 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42535&action=edit Untested fix Hi, The issue here for propagating value of 'm' from f_c1 to foo() is that the jump function operation is FLOAT_EXPR, and the type of input param 'm' is int, so fold_unary() doesn't do the conversion to real_type. The attached patch fixes that by calling fold_convert if operation is FLOAT_EXPR and converts it to the type of corresponding parameter in callee. Does this look in the right direction ? I will validate the patch and post upstream if there are no regressions. Thanks, Prathamesh
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #34 from Sven ---
(In reply to H.J. Lu from comment #32)
> long long is aligned to 4 bytes in struct for i386.
Understood. So the aligned(4) was just added to explicitly restating the
alignment?
Anyhow, the two warnings added by that commit seem unrelated to this issue. The
warnings added check the alignment of variables and members in memory. When
they fall below the given threshold, a warning is issued.
This bug report however is about a different issue. Every member of a packed
struct has an alignment guarantee of 1 - no more than that. However, a regular
int* variable guarantees, when dereferenced, guarantees an alignment of 4 (on
i386 and arm, for example). So the following code should produce a warning:
struct foo
{
int i;
} __attribute__((packed));
struct foo *x;
int *y = &(x->i);
The issue becomes more obvious with this struct:
struct foo2
{
char c;
int i;
} __attribute__((packed));
However, both foo and foo2 only have an alignment guarantee of at most 1, so
also the int member inside both structs has an alignment guarantee of at most
1.
As mentioned in the initial post, gcc will generate the proper machine code to
read an unaligned int (on arm for example) when using x->i directly. However,
when using *y, gcc will assume 4 byte alignment. That is to be expected, hence
gcc should warn about the fact, and the address of a (potentially) unaligned
int is assigned to a regular int* pointer.
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 --- Comment #35 from Sven --- (In reply to Sven from comment #34) > That is to be > expected, hence gcc should warn about the fact, and the address of a > (potentially) unaligned int is assigned to a regular int* pointer. Sorry, typo: That is to be expected, hence gcc should warn about the fact that the address of a (potentially) unaligned int is assigned to a regular int* pointer.
[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641
--- Comment #6 from Richard Earnshaw ---
(In reply to Tamar Christina from comment #5)
> My patch adds support for
>
>
> ```
> #pragma GCC push_options
> #pragma GCC target("arch=armv8-a+crc")
> __attribute__((target("arch=armv8-a+crc"))) uint32_t crc32cw(uint32_t crc,
> uint32_t val)
> ```
>
> and just
>
>
> ```
> #pragma GCC push_options
> #pragma GCC target("+crc")
> __attribute__((target("+crc"))) uint32_t crc32cw(uint32_t crc, uint32_t val)
> ```
>
> if the compiler was invoked with `-march=armv8-a`.
>
> However it currently doesn't allow
>
>
> ```
> #pragma GCC push_options
> #pragma GCC target("armv8-a+crc")
> __attribute__((target("armv8-a+crc"))) uint32_t crc32cw(uint32_t crc,
> uint32_t val)
> ```
>
> as it doesn't know if you wanted to change the `fpu` or `arch` here.
> Should I support this case as well?
No, I think we should insist on an arch= or fpu= prefix for all but the adding
extensions case.
Note that extensions can only modify the existing architecture if it supports
that extension. This is because the modifiers are context dependent: for
example the +fp extension (new in gcc-8) will enable floating-point
instructions that come with the specified architecture.
Also note that in the long-term -mfpu and pragma/attribute variants thereof are
likely to be deprecated in favour of specifying all this through the
architecture string.
[Bug ipa/82808] [7/8 Regression] LTO clone wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82808
--- Comment #5 from Martin Jambor ---
(In reply to prathamesh3492 from comment #4)
> Created attachment 42535 [details]
> Untested fix
>
> Hi,
> The issue here for propagating value of 'm' from f_c1 to foo() is that the
> jump function operation is FLOAT_EXPR, and the type of input param 'm' is
> int, so fold_unary() doesn't do the conversion to real_type.
Thanks a lot for the quick the analysis.
> The attached
> patch fixes that by calling fold_convert if operation is FLOAT_EXPR and
> converts it to the type of corresponding parameter in callee.
> Does this look in the right direction ?
> --- a/gcc/ipa-cp.c
> +++ a/gcc/ipa-cp.c
> @@ -1233,7 +1234,13 @@ ipa_get_jf_pass_through_result (struct
> ipa_jump_func *j> func, tree input)
>if (!is_gimple_ip_invariant (input))
> return NULL_TREE;
>
> - if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
> + if (parm_type &&
> + ipa_get_jf_pass_through_operation (jfunc) == FLOAT_EXPR)
> +{
> + res = fold_convert (parm_type, input);
> + restype = parm_type;
> +}
> + else if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
I don't think it is correct to make parm_type a parameter with NULL
default value and then only handle FLOAT_EXPR safely when it arrives
through paths that actually provide a non-NULL value.
So either we should just always return NULL for FLOAT_EXPR operation
or return NULL_TREE when operation is FLOAT_EXPR and param_tree is
NULL (or provide the type from all callers but I can see that might be
a bit painful).
DO I assume correctly that we have the same problem with
FIX_TRUNC_EXPR too?
[Bug ipa/82808] [7/8 Regression] LTO clone wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82808
--- Comment #6 from prathamesh3492 at gcc dot gnu.org ---
(In reply to Martin Jambor from comment #5)
> (In reply to prathamesh3492 from comment #4)
> > Created attachment 42535 [details]
> > Untested fix
> >
>
> > Hi,
> > The issue here for propagating value of 'm' from f_c1 to foo() is that the
> > jump function operation is FLOAT_EXPR, and the type of input param 'm' is
> > int, so fold_unary() doesn't do the conversion to real_type.
>
> Thanks a lot for the quick the analysis.
>
> > The attached
> > patch fixes that by calling fold_convert if operation is FLOAT_EXPR and
> > converts it to the type of corresponding parameter in callee.
> > Does this look in the right direction ?
>
> > --- a/gcc/ipa-cp.c
> > +++ a/gcc/ipa-cp.c
> > @@ -1233,7 +1234,13 @@ ipa_get_jf_pass_through_result (struct
> > ipa_jump_func *j> func, tree input)
> >if (!is_gimple_ip_invariant (input))
> > return NULL_TREE;
> >
> > - if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
> > + if (parm_type &&
> > + ipa_get_jf_pass_through_operation (jfunc) == FLOAT_EXPR)
> > +{
> > + res = fold_convert (parm_type, input);
> > + restype = parm_type;
> > +}
> > + else if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
>
> I don't think it is correct to make parm_type a parameter with NULL
> default value and then only handle FLOAT_EXPR safely when it arrives
> through paths that actually provide a non-NULL value.
>
> So either we should just always return NULL for FLOAT_EXPR operation
> or return NULL_TREE when operation is FLOAT_EXPR and param_tree is
> NULL (or provide the type from all callers but I can see that might be
> a bit painful).
Indeed, I will modify the patch to return NULL_TREE when operation is
FLOAT_EXPR and parm_type is NULL.
>
> DO I assume correctly that we have the same problem with
> FIX_TRUNC_EXPR too?
I suppose yes, I will add case for FIX_TRUNC_EXPR in the patch. I am not sure
though how to write a C test-case for generating FIX_TRUNC_EXPR ?
Thanks,
Prathamesh
[Bug target/82795] [8 Regression] ICE in predicate_mem_writes, at tree-if-conv.c:2251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82795 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug ada/82813] New: warning: '.builtin_memcpy' writing between 2 and 6 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82813 Bug ID: 82813 Summary: warning: '.builtin_memcpy' writing between 2 and 6 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=] Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: charlet at gcc dot gnu.org, msebor at gcc dot gnu.org Target Milestone: --- Created attachment 42536 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42536&action=edit optimized tree dump Hello. Not being sure whether it's real issue or false positive: 214elsif Including_RTS then 215 for J in Start .. Sw'Last loop 216 if Sw (J) = Directory_Separator then 217 Switch := 218 new String' 219 (Sw (1 .. Start - 1) 220 & Parent 221 & Directory_Separator 222 & Sw (Start .. Sw'Last)); 223 return; 224 end if; 225 end loop; Optimized dump is in attachment.
[Bug ipa/82808] [7/8 Regression] LTO clone wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82808
--- Comment #7 from Richard Biener ---
ipa_get_jf_pass_through_result has multiple issues:
static tree
ipa_get_jf_pass_through_result (struct ipa_jump_func *jfunc, tree input)
{
tree restype, res;
if (ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
return input;
we may miss a truncation here (and should check for CONVERT_EXPR_CODE_P).
if (!is_gimple_ip_invariant (input))
return NULL_TREE;
if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
== tcc_unary)
res = fold_unary (ipa_get_jf_pass_through_operation (jfunc),
TREE_TYPE (input), input);
the bug here is that the operation is type-changing but we use the
type of the input(!) rather than the type of the output when computing
the result. I suppose the output is the type of the current formal
parameter -- is that available somehow?
else
{
if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
== tcc_comparison)
restype = boolean_type_node;
else
restype = TREE_TYPE (input);
same issue for operations like widen_sum_expr but of course less likely
to hit us here.
res = fold_binary (ipa_get_jf_pass_through_operation (jfunc), restype,
input, ipa_get_jf_pass_through_operand (jfunc));
}
if (res && !is_gimple_ip_invariant (res))
return NULL_TREE;
I think the immediate thing to do is make the list of handled expression
codes explicit - thus change the tree-code-class checks to
switch (code)
{
case handled-unary:
fold_unary...
case handled-comparison:
...
etc.
or somehow properly get the jf "target" type.
[Bug ipa/82808] [7/8 Regression] LTO clone wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82808
--- Comment #8 from Martin Jambor ---
(In reply to Richard Biener from comment #7)
> ipa_get_jf_pass_through_result has multiple issues:
>
> static tree
> ipa_get_jf_pass_through_result (struct ipa_jump_func *jfunc, tree input)
> {
> tree restype, res;
>
> if (ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
> return input;
>
> we may miss a truncation here (and should check for CONVERT_EXPR_CODE_P).
I admit this is confusing but no. Until gcc7 we had two kinds of
pass-through jump functions, binary and really_no_operation_at_all.
NOP_EXPR was used to mark that more simple case and still is.
However, despite having unary pass-through jump functions now, we
never construct those with if the operation would be a
CONVERT_EXPR_CODE_P. Maybe we should use ERROR_MARK or something
instead of NOP_EXPR.
>
> if (!is_gimple_ip_invariant (input))
> return NULL_TREE;
>
> if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
> == tcc_unary)
> res = fold_unary (ipa_get_jf_pass_through_operation (jfunc),
> TREE_TYPE (input), input);
>
> the bug here is that the operation is type-changing but we use the
> type of the input(!) rather than the type of the output when computing
> the result. I suppose the output is the type of the current formal
> parameter -- is that available somehow?
The output in the original IL was the actual argument, at IPA level we
generally assume that it is compatible with the callee formal
argument. That type is now available from the new parameter that
Prathamesh is adding with his patch, but he does not pass them from
all callers. If the type is required for more than a bunch of
not-likely-important operations, we should try harder and provide it
from everywhere (possibly incrementally).
>
> else
> {
> if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
> == tcc_comparison)
> restype = boolean_type_node;
> else
> restype = TREE_TYPE (input);
>
> same issue for operations like widen_sum_expr but of course less likely
> to hit us here.
>
> res = fold_binary (ipa_get_jf_pass_through_operation (jfunc), restype,
> input, ipa_get_jf_pass_through_operand (jfunc));
> }
> if (res && !is_gimple_ip_invariant (res))
> return NULL_TREE;
>
>
> I think the immediate thing to do is make the list of handled expression
> codes explicit - thus change the tree-code-class checks to
>
> switch (code)
> {
> case handled-unary:
> fold_unary...
>
> case handled-comparison:
> ...
>
> etc.
>
> or somehow properly get the jf "target" type.
Nowadays it should be possible to do the latter (but people always
frown when I introduce more type handling to WPA, so I would not
necessarily object to the former either).
[Bug fortran/82814] New: ICE from submodule character function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82814 Bug ID: 82814 Summary: ICE from submodule character function Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: werner.blokbuster at gmail dot com Target Milestone: --- The following program gives an ICE with gfortran 7.2.0 and 6.4.0. Unfortunately I do not have version 8 to test. module u implicit none interface unique module function uniq_char(input) result(uniq) character(*), intent(in) :: input(:) character(size(input)), allocatable :: uniq(:) end function uniq_char end interface unique end module u submodule (u) z implicit none contains module function uniq_char(input) result(uniq) character(*), intent(in) :: input(:) character(size(input)), allocatable :: uniq(:) allocate(uniq(1)) uniq = 'A' end function uniq_char end submodule z program test_uniq use u, only: unique implicit none write(*,*) unique(['1','2','1','2']) end program test_uniq ICE: test_uniq.f:27:0: allocate(uniq(1)) internal compiler error: Segmentation fault: 11 test_uniq.f:27:0: internal compiler error: Abort trap: 6 The program compiles and runs if any of: - character variables are replaced with integer or real variables; - the submodule is not used and the function is placed within module u; - the variable 'uniq' is given a fixed length, e.g. character(1). I'm running on a macbook 10.12.6 using gfortran from macports. WB
[Bug ada/82813] warning: '.builtin_memcpy' writing between 2 and 6 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82813 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-02 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- I can reproduce.
[Bug ada/82813] warning: '.builtin_memcpy' writing between 2 and 6 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82813
--- Comment #2 from Eric Botcazou ---
It's unreachable code:
[0.23%] [count: INV]:
# DEBUG S117b.276 => &D.9593
.builtin_memcpy (&MEM[(void *)&D.9593], pretmp_305, _250);
The only predecessor is:
[0.32%] [count: INV]:
L113b_224 = start_130 + _322;
# DEBUG L114b => 1
# DEBUG make_util__ensure_absolute_path__B_4__L_5__TTS117bSP1___L => 1
# DEBUG make_util__ensure_absolute_path__B_4__L_5__TTS117bSP1___U =>
L113b_224
# DEBUG D.7306 => 1
# DEBUG iftmp.271 => 1 + 18446744073709551615
if (L113b_224 != 0)
goto ; [64.00%]
else
goto ; [36.00%]
whose only predecessor is:
[0.63%] [count: INV]:
_37 = parent$P_BOUNDS_1->UB0;
_38 = parent$P_BOUNDS_1->LB0;
_330 = iftmp.245_24 - start_130;
_322 = _330 + 1;
_250 = (sizetype) j_231;
pretmp_305 = &MEM[(void *)sw.246_6][1 ...]{lb: 1 sz: 1};
if (_37 >= _38)
goto ; [50.00%]
else
goto ; [50.00%]
So is reachable only if parent$P_BOUNDS_1->UB0 < parent$P_BOUNDS_1->LB0
is true.
But this condition is caught by the block just above:
if Parent'Length = 0 then
Do_Fail
("relative search path switches ("""
& Sw
& """) are not allowed");
[7.26%] [count: INV]:
_19 = parent$P_BOUNDS_1->LB0;
_20 = parent$P_BOUNDS_1->UB0;
if (_19 > _20)
goto ; [33.00%]
else
goto ; [67.00%]
is a dominator of so is reachable only if
parent$P_BOUNDS_1->LB0 > parent$P_BOUNDS_1->UB0 is false, which is the opposite
of the above condition, so is not reachable.
[Bug target/82812] ICE in emit_move_insn, at expr.c:3706
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82812 jkoval at gcc dot gnu.org changed: What|Removed |Added CC||jkoval at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jkoval at gcc dot gnu.org --- Comment #1 from jkoval at gcc dot gnu.org --- This happens, because there were no flags for SSE/AVX requirement in i386-builtin.def for GFNI. I will fix it soon.
[Bug middle-end/82815] New: RTL frontend errors out on const_double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82815
Bug ID: 82815
Summary: RTL frontend errors out on const_double
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: thopre01 at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 42537
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42537&action=edit
Testcase showing bug in read_rtx_operand
read_rtx_operand in read-rtl.c assumes that a format starting with w is an
integer but this can also be a const_double (see real.h). It then tries to
validate the integer constant which fails and errors out with:
error: invalid decimal constant "1.0e+0"
The attached testcase shows the bug when compiled with:
arm-none-eabi-gcc -S foo.c -march=armv7e-m -mfloat-abi=hard -mfpu=fpv5-d16
testcase_read-rtl.c
The RTL is generated from:
double foo (void)
{
return 1.0;
}
and dumped from arm_reorg. Similar procedure on other targets should lead to
the error as well.
[Bug tree-optimization/82816] New: ICE on valid code at -Os and above: in find_widening_optab_handler_and_mode, at optabs-query.c:414
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82816
Bug ID: 82816
Summary: ICE on valid code at -Os and above: in
find_widening_optab_handler_and_mode, at
optabs-query.c:414
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
This appears to be a recent regression.
$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20171102 (experimental) [trunk revision 254338] (GCC)
$
$ gcctk -O1 -c small.c
$ gcc-7.2.0 -Os -c small.c
$
$ gcctk -Os -c small.c
during GIMPLE pass: widening_mul
small.c: In function ‘f’:
small.c:8:6: internal compiler error: in find_widening_optab_handler_and_mode,
at optabs-query.c:414
void f ()
^
0xb749b8 find_widening_optab_handler_and_mode(optab_tag, machine_mode,
machine_mode, machine_mode*)
../../gcc-source-trunk/gcc/optabs-query.c:414
0xe0b484 insn_code
find_widening_optab_handler_and_mode(optab_tag,
scalar_int_mode const&, scalar_int_mode const&, scalar_int_mode*)
../../gcc-source-trunk/gcc/optabs-query.h:201
0xe0b484 convert_mult_to_widen
../../gcc-source-trunk/gcc/tree-ssa-math-opts.c:3273
0xe0f29f execute
../../gcc-source-trunk/gcc/tree-ssa-math-opts.c:4205
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$
--
struct A
{
int b:3;
} d, e;
int c;
void f ()
{
char g = d.b * e.b;
c = g;
}
[Bug tree-optimization/82788] wrong code with -fstack-clash-protection --param=stack-clash-protection-probe-interval=10 on simple code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82788 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #1 from Jeffrey A. Law --- Sigh. Yet more evidence that user-configurable probing intervals is probably a bad idea...
[Bug ada/82813] warning: '.builtin_memcpy' writing between 2 and 6 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82813 Martin Sebor changed: What|Removed |Added Depends on||80545 --- Comment #3 from Martin Sebor --- The warning will go away once pr80545 is fixed but I wonder if a better (independent) solution in this case is to detect that the code is, in fact, unreachable, and avoid emitting it to begin with. Alternatively, if it is too hard to determine that it's unreachable, it should be possible to detect that the memcpy call is invalid earlier and replace it with either __builtin_unreachable or __builtin_trap. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80545 [Bug 80545] option -Wstringop-overflow not recognized by Fortran
[Bug rtl-optimization/82803] Wildly excessive calls to __tls_get_addr with optimizations enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82803
--- Comment #3 from Alex Mohr ---
FWIW a loop is not required. This generates 4 calls to __tls_get_addr:
static thread_local int x;
int g();
int f() {
int *px = &x;
if (g()) *px += g();
if (g()) *px += g();
if (g()) *px += g();
return *px;
}
[Bug ada/82813] warning: '.builtin_memcpy' writing between 2 and 6 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82813
--- Comment #4 from Eric Botcazou ---
> The warning will go away once pr80545 is fixed but I wonder if a better
> (independent) solution in this case is to detect that the code is, in fact,
> unreachable, and avoid emitting it to begin with.
Yes, it's a missed optimization at the GIMPLE level.
> Alternatively, if it is too hard to determine that it's unreachable, it should
> be possible to detect that the memcpy call is invalid earlier and replace it
> with either __builtin_unreachable or __builtin_trap.
Possibly, 121t.phicprop1 has:
S117b.276_245 = .builtin_alloca_with_align (0, 8);
# DEBUG S117b.276 => S117b.276_245
_46 = (sizetype) j_231;
_48 = &*sw.246_6[1 ...]{lb: 1 sz: 1};
_49 = &*S117b.276_245[1 ...]{lb: 1 sz: 1};
.builtin_memcpy (_49, _48, _46);
[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641 --- Comment #7 from Yichao Yu --- It would be great if `+crc` can work if it's not ambiguous. Requiring `arch=armv8-a+crc` works for me too, and it'll just require more preprocessor checks.
[Bug c/82817] New: C frontend errors on SSA name from REG_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82817 Bug ID: 82817 Summary: C frontend errors on SSA name from REG_EXPR Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: thopre01 at gcc dot gnu.org CC: dmalcolm at gcc dot gnu.org Target Milestone: --- Created attachment 42538 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42538&action=edit unparsable RTL Hi, when parsing a __RTL function with expression containing a SSA name of a local variable (of the form ._, the C parser errors out because libcpp think it is a floating-point but validation remarks that it is invalid: error: invalid suffix "_2" on floating constant (cinsn 11 (set (reg:SI r3 [orig:111 c.1_2 ] [111]) We could strip the REG_EXPR expression when printing RTL for the frontend via print_rtx_function but I believe going through libcpp is wrong. Here is how we get there: #0 cpp_classify_number (pfile=0x25585b0, token=0x25ac998, ud_suffix=0x7fffd7d0, virtual_location=166019) at /data/dev/builds/arm-none-eabi/default/src/libcpp/expr.c:685 #1 0x008b68ab in c_lex_with_flags (value=0x7654e010, loc=0x7654e00c, cpp_flags=0x7654e018 "\001", lex_flags=0) at /data/dev/builds/arm-none-eabi/default/src/gcc/c-family/c-lex.c:415 #2 0x00817b69 in c_lex_one_token (parser=0x7654e000, token=0x7654e008) at /data/dev/builds/arm-none-eabi/default/src/gcc/c/c-parser.c:251 #3 0x00817fa4 in c_parser_peek_token (parser=0x7654e000) at /data/dev/builds/arm-none-eabi/default/src/gcc/c/c-parser.c:438 #4 0x00850852 in c_parser_parse_rtl_body (parser=0x7654e000, start_with_pass=0x25f45f0 "shorten") at /data/dev/builds/arm-none-eabi/default/src/gcc/c/c-parser.c:18639 Looking at the use done of c_parser_peek_token in c_parser_parse_rtl_body, I wonder why not call a much lower level function that just reads the input file and parse parenthesis and end of file itself. Tokenization does not seem necessary here since all the validation for RTL is done outside the C frontend. I've reduced manually the RTL function I had to the attached function. I'm not sure it's valid RTL but at least the syntax should be correct. When building it with arm-none-eabi-gcc -c -march=armv7e-m -mfloat-abi=hard -mfpu=fpv5-sp-d16 one gets the following errors: prx.c: In function 'fn1': prx.c:14:44: error: invalid suffix "_2" on floating constant (cinsn 11 (set (reg:SI r3 [orig:111 c.1_2 ] [111]) ^~~~ prx.c:12:56: error: expected character `[', found `)' prx.c:12:85: note: following context is ` [0 S4 A32])) "testcase.c":7'
[Bug c++/82710] [8 Regression] Incorrect warning:unnecessary parentheses in declaration of global friend functions [-Werror=parentheses]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82710 --- Comment #5 from Nathan Sidwell --- Author: nathan Date: Thu Nov 2 18:26:29 2017 New Revision: 254349 URL: https://gcc.gnu.org/viewcvs?rev=254349&root=gcc&view=rev Log: [PR c++/82710] false positive paren warning https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00119.html PR c++/82710 * decl.c (grokdeclarator): Don't warn when parens protect a return type from a qualified name. PR c++/82710 * g++.dg/warn/pr82710.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/pr82710.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug other/81096] [8 regression] test case ttest in libbacktrace fails starting with its introduction in r249111
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81096 --- Comment #7 from Wilco --- Is this now fixed on PPC too? If so, it can be closed.
[Bug c++/82710] [8 Regression] Incorrect warning:unnecessary parentheses in declaration of global friend functions [-Werror=parentheses]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82710 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Nathan Sidwell --- Fixed r254349.
[Bug c++/57728] Explicit template instantiation with defaulted method causes missing symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57728
Jens Maurer changed:
What|Removed |Added
CC||jens.maurer at gmx dot net
--- Comment #13 from Jens Maurer ---
This bug saw its last activity nearly a year ago, with patches from Jason
applied, but the issue does not seem to be fixed in its entirety (using gcc
7.2).
Specifically, this translation unit:
template
struct C {
C() = default;
void f() { }
int i = 5;
};
template class C;
causes C::f() to be defined, but the defaulted constructor of C is
not defined. (Replacing "= default" with "{}" causes definition of the C
constructor.)
$ nm -C x.o
W C::f()
The current behavior is obviously not what we want if we choose to use explicit
instantiations.
[Bug c++/70401] [c++1z on mingw]compile variadic template failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70401 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot com --- Comment #1 from Paolo Carlini --- Can you please check gcc-7.x or current trunk? Somebody with access to mingw? On x86_64-linux both are fine and the issue could be closed.
[Bug target/79868] aarch64: diagnostic "malformed target %s value" not translateable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79868 --- Comment #9 from Steve Ellcey --- Author: sje Date: Thu Nov 2 21:56:00 2017 New Revision: 254359 URL: https://gcc.gnu.org/viewcvs?rev=254359&root=gcc&view=rev Log: PR target/79868 * config/aarch64/aarch64-c.c (aarch64_pragma_target_parse): Remove second argument from aarch64_process_target_attr call. * config/aarch64/aarch64-protos.h (aarch64_process_target_attr): Ditto. * config/aarch64/aarch64.c (aarch64_attribute_info): Change field type. (aarch64_handle_attr_arch): Remove second argument. (aarch64_handle_attr_cpu): Ditto. (aarch64_handle_attr_tune): Ditto. (aarch64_handle_attr_isa_flags): Ditto. (aarch64_process_one_target_attr): Ditto. (aarch64_process_target_attr): Ditto. (aarch64_option_valid_attribute_p): Remove second argument. on aarch64_process_target_attr call. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64-c.c trunk/gcc/config/aarch64/aarch64-protos.h trunk/gcc/config/aarch64/aarch64.c
[Bug target/79868] aarch64: diagnostic "malformed target %s value" not translateable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79868 --- Comment #10 from Steve Ellcey --- Author: sje Date: Thu Nov 2 21:58:05 2017 New Revision: 254360 URL: https://gcc.gnu.org/viewcvs?rev=254360&root=gcc&view=rev Log: PR target/79868 * gcc.target/aarch64/spellcheck_1.c: Update dg-error string to match new format. * gcc.target/aarch64/spellcheck_2.c: Ditto. * gcc.target/aarch64/spellcheck_3.c: Ditto. * gcc.target/aarch64/target_attr_11.c: Ditto. * gcc.target/aarch64/target_attr_12.c: Ditto. * gcc.target/aarch64/target_attr_17.c: Ditto. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/aarch64/spellcheck_1.c trunk/gcc/testsuite/gcc.target/aarch64/spellcheck_2.c trunk/gcc/testsuite/gcc.target/aarch64/spellcheck_3.c trunk/gcc/testsuite/gcc.target/aarch64/target_attr_11.c trunk/gcc/testsuite/gcc.target/aarch64/target_attr_12.c trunk/gcc/testsuite/gcc.target/aarch64/target_attr_17.c
[Bug c++/81957] ICE decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81957 --- Comment #3 from paolo at gcc dot gnu.org --- Author: paolo Date: Fri Nov 3 00:13:06 2017 New Revision: 254361 URL: https://gcc.gnu.org/viewcvs?rev=254361&root=gcc&view=rev Log: /cp 2017-11-02 Paolo Carlini PR c++/81957 * pt.c (make_pack_expansion): Add tsubst_flags_t parameter. (expand_integer_pack, convert_template_argument, coerce_template_parms, gen_elem_of_pack_expansion_instantiation, tsubst_pack_expansion, unify): Adjust calls. * tree.c (cp_build_qualified_type_real): Likewise. * cp-tree.h (make_pack_expansion): Adjust declaration. /testsuite 2017-11-02 Paolo Carlini PR c++/81957 * g++.dg/cpp0x/variadic-crash5.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic-crash5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog
