[Bug fortran/66193] New: ICE for initialisation of some non-zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 Bug ID: 66193 Summary: ICE for initialisation of some non-zero-sized arrays Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This initialisation of an array (NOT zero sized, NOT a parameter) program p real :: z(2) z = 1 + [real :: 1, 2] end yields (with gfortran 5.1.1 on SUSE Linux 13.2, 64 bit) f951: internal compiler error: Segmentation fault This variation ... program p real :: z(2) = 1 + [real :: 1, 2] end or with an additional parameter attribute ... program p real, parameter :: z(2) = 1 + [real :: 1, 2] end yields the same error message as above. Kind regards.
[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66163
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at redhat dot com
--- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org ---
Forgot to actually CC Jason, sorry for that.
static size_t offsetOfThis() {
JitFrameLayout* base = nullptr;
return reinterpret_castsize_t(base-argv()[0]);
}
Jason,
just to double check, this is indeed an undefined and offsetof is usable
only for POD?
[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org --- Do you compile these test cases with -O? What happens if you specify -fno-frontend-optimize ?
[Bug target/66136] AArch64 geniterators.sh relies on GNU sed syntax, causing build failure on FreeBSD and probably Mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136 --- Comment #5 from Szabolcs Nagy nszabolcs at gmail dot com --- patch that uses awk: https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01578.html
[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66163 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.0.1 |6.0
[Bug tree-optimization/66165] [6 Regression] vect_transform_slp_perm_load: vec out of range ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66165 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |6.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug sanitizer/66190] [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190
--- Comment #1 from Martin Liška marxin at gcc dot gnu.org ---
w/o -flto one gets:
test2.ii:14:56: internal compiler error: in expand_expr_real_1, at expr.c:10766
GrAAHairLinePathRenderer::~GrAAHairLinePathRenderer() {}
^
0x8370e3 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10766
0xcad79e expand_expr
../../gcc/expr.h:254
0xcad79e output_constant
../../gcc/varasm.c:4769
0xcaddaa assemble_variable_contents
../../gcc/varasm.c:2067
0xcb40c3 assemble_variable(tree_node*, int, int, int)
../../gcc/varasm.c:2289
0xcb757d varpool_node::assemble_decl()
../../gcc/varpool.c:603
0x79f103 output_in_order
../../gcc/cgraphunit.c:2137
0x79f452 symbol_table::compile()
../../gcc/cgraphunit.c:2378
0x7a0c5c symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2461
0x639792 cp_write_global_declarations()
../../gcc/cp/decl2.c:4755
[Bug ipa/66181] [6 Regression]: /usr/include/bits/types.h:134:16: ICE: verify_type failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66181 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0
[Bug lto/66180] [6 Regression] many -Wodr false positives when building LLVM with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66180 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0
[Bug sanitizer/66190] [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r213406.
[Bug tree-optimization/65637] expand_omp_for_static_chunk ssa-handling code is untested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65637 --- Comment #7 from vries at gcc dot gnu.org --- Author: vries Date: Mon May 18 13:22:15 2015 New Revision: 223290 URL: https://gcc.gnu.org/viewcvs?rev=223290root=gccview=rev Log: Fix gcc_assert in expand_omp_for_static_chunk 2015-05-18 Tom de Vries t...@codesourcery.com PR tree-optimization/65637 * omp-low.c (expand_omp_for_static_chunk): Fix gcc_assert for the case that head is NULL. Modified: branches/gomp-4_0-branch/gcc/ChangeLog branches/gomp-4_0-branch/gcc/omp-low.c
[Bug c/66194] New: emit vectorization instruction for not aligned data(amd64), -fno-strict-aliasing not help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66194
Bug ID: 66194
Summary: emit vectorization instruction for not aligned
data(amd64), -fno-strict-aliasing not help
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dushistov at mail dot ru
Target Milestone: ---
Created attachment 35562
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35562action=edit
code example
If such code compiled
1)with optinos -fno-strict-aliasing -O3 -std=c99
2)as separate module
3)amd64
then it crashes if key misaligned:
void
dummyhash (const void *key, int len, uint32_t seed, void *out)
{
uint32_t h = seed, *pk = (uint32_t *)key;
for (; len 3; len -= 4, pk++)
h ^= (*pk + len);
const unsigned char *s = (unsigned char *)pk;
switch (len) {
case 3:
h ^= ((*s++ + 3) 24);
case 2:
h ^= ((*s++ + 2) 16);
case 1:
h ^= (*s + 1);
}
*(uint32_t*)out = h;
}
With -O2 works fine, I attach full example and makefile to bug.
With clang 3.6.0 and icc (ICC) 13.1.3 20130607 all works fine.
[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 --- Comment #1 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- For integer instead of real ... program p integer :: z(2) z = 1.2 + [integer :: 3.5, 4.5] print *, z end it compiles with gfortran snippet.f90 but running ./a.out prints an unexpected 1 1 --- On the other hand, something like this with a zero-sized array ... program p integer(8) :: z(2) z = 1 + [ integer(8) :: [ integer(4) :: ], 1, 2 ] end gives an ... f951: internal compiler error: Segmentation fault
[Bug c++/66192] New: C++ static initializer unnecessary __cxa_guard_acquire for TARGET_RELAXED_ORDERING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66192
Bug ID: 66192
Summary: C++ static initializer unnecessary __cxa_guard_acquire
for TARGET_RELAXED_ORDERING
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
// static_init.cc
int* f(void) {
static int* p = new int;
return p;
}
$ g++ -O2 -S -fno-exceptions static_init.cc
generates an unnecessary call to __cxa_guard_acquire on what should be the fast
path for targets with TARGET_RELAXED_ORDERING defined. The guard should be an
atomic variable accessed with the equivalent of __atomic_load(ACQUIRE) instead
of a heavy-weight __cxa_guard_acquire() call invoking heavier-weight
synchronization.
[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66163
--- Comment #7 from Jan Hubicka hubicka at ucw dot cz ---
According to -fsanitize=null, there are many places in Firefox that produce
undefined behavior in followin way:
https://bugzilla.mozilla.org/show_bug.cgi?id=1165904
One common example:
static size_t offsetOfThis() {
JitFrameLayout* base = nullptr;
return reinterpret_castsize_t(base-argv()[0]);
}
Jason,
just to double check, this is indeed an undefined and offsetof is usable
only for POD?
Honza
[Bug fortran/66102] dependency mishandling with reallocation on assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66102 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Attachment #35518|0 |1 is obsolete|| --- Comment #3 from Mikael Morin mikael at gcc dot gnu.org --- Created attachment 35563 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35563action=edit Fixed test The initial test was bogus, because [b, e] and [a, e] are not conformable. Fixed as follows --- comment_0.f90 2015-05-16 21:46:41.932079904 +0200 +++ realloc_on_assign_23_fixed.f90 2015-05-16 22:26:57.001112948 +0200 @@ -29,8 +29,8 @@ if (any([(b(i)%i, i=1,size(b))] /= [(i, i=1,size(b))])) call abort contains subroutine foo -a = [a, e] b = first_arg([b, e], [a, e]) +a = [a, e] end subroutine elemental function first_arg(arg1, arg2) type(t), intent(in) :: arg1, arg2
[Bug c++/66192] C++ static initializer unnecessary __cxa_guard_acquire for TARGET_RELAXED_ORDERING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66192 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Target||powerpc*-*, sparc*-*-*, ||arm*-*-*, aarch*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-18 CC||jason at gcc dot gnu.org, ||ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Edelsohn dje at gcc dot gnu.org --- This has been present since the initial implementation from 2004. https://gcc.gnu.org/ml/gcc-patches/2004-12/msg01992.html LLVM Clang does not generate __cxa_guard_acquire for the fast path.
[Bug c++/66191] GCC optimizes away if clause checking similar but not same condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66191 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Well, you invoke undefined behavior when negate INT_MIN.
[Bug tree-optimization/66165] [6 Regression] vect_transform_slp_perm_load: vec out of range ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66165 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Also a missed optimization due to dependence analysis issues.
[Bug c++/66191] GCC optimizes away if clause checking similar but not same condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66191 --- Comment #3 from Nenad Mikša DoDoEntertainment at gmail dot com --- Thanks for info.
[Bug c++/66191] GCC optimizes away if clause checking similar but not same condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66191 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|major |normal --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- Both GCC and Clang provide ubsan (via -fsanitize=undefined) which will find this error: proba2.cpp:14:28: runtime error: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself
[Bug sanitizer/66190] [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-18 Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug c++/66191] GCC optimizes away if clause checking similar but not same condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66191 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Yeah. You should have used e.g. return -_int2double(-(unsigned)i); instead.
[Bug tree-optimization/65637] expand_omp_for_static_chunk ssa-handling code is untested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65637 --- Comment #8 from vries at gcc dot gnu.org --- Author: vries Date: Mon May 18 13:22:26 2015 New Revision: 223291 URL: https://gcc.gnu.org/viewcvs?rev=223291root=gccview=rev Log: Fix inner loop phi in expand_omp_for_static_chunk 2015-05-18 Tom de Vries t...@codesourcery.com PR tree-optimization/65637 * omp-low.c (find_phi_with_arg_on_edge): New function. (expand_omp_for_static_chunk): Fix inner loop phi. Modified: branches/gomp-4_0-branch/gcc/ChangeLog branches/gomp-4_0-branch/gcc/omp-low.c
[Bug tree-optimization/65637] expand_omp_for_static_chunk ssa-handling code is untested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65637 --- Comment #9 from vries at gcc dot gnu.org --- Author: vries Date: Mon May 18 13:22:36 2015 New Revision: 223292 URL: https://gcc.gnu.org/viewcvs?rev=223292root=gccview=rev Log: Handle 2 preds for fin_bb in expand_omp_for_static_chunk 2015-05-18 Tom de Vries t...@codesourcery.com PR tree-optimization/65637 * omp-low.c (expand_omp_for_static_chunk): Handle case that fin_bb has 2 predecessors. Modified: branches/gomp-4_0-branch/gcc/ChangeLog branches/gomp-4_0-branch/gcc/omp-low.c
[Bug sanitizer/66190] [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- So static int b = (int ) (UBSAN_NULL (a, 2B, 0);, a;); survives it to the expansion. It appears that we shouldn't instrument statics like that.
[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66163
--- Comment #6 from Martin Liška marxin at gcc dot gnu.org ---
According to -fsanitize=null, there are many places in Firefox that produce
undefined behavior in followin way:
https://bugzilla.mozilla.org/show_bug.cgi?id=1165904
One common example:
static size_t offsetOfThis() {
JitFrameLayout* base = nullptr;
return reinterpret_castsize_t(base-argv()[0]);
}
Martin
[Bug sanitizer/66190] [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.2
[Bug c++/66191] New: GCC optimizes away if clause checking similar but not same condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66191
Bug ID: 66191
Summary: GCC optimizes away if clause checking similar but not
same condition
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: DoDoEntertainment at gmail dot com
Target Milestone: ---
Created attachment 35561
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35561action=edit
Program that causes issue, executable, preprocessed output, GCC info, etc.
Hello everyone,
this is my first GCC bug report so please tell me if something is missing. I've
added all required by 'https://gcc.gnu.org/bugs/' in provided tar.gz file.
The bug happens when using optimization level O2 or higher.
Consider this chunk of code:
static const double
double0_15[]={0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,10.0,11.0,12.0,13.0,14.0,15.0};
static double _int2double(unsigned i){
if (i16)
return double0_15[i];
else
return _int2double(i/16)*16.0+double0_15[i%16];
}
double int2double(int i){
if (i0)
return -_int2double(-i);
else
return _int2double(i);
}
If 'int2double' is called with negative value (see attached tar.gz for complete
example that reproduces the bug) then if clause in '_int2double' is skipped
which causes a segfault if i-16.
The code chunk is taken from free computer algebra system Giac
(http://www-fourier.ujf-grenoble.fr/~parisse/giac.html).
In attached tar.gz you can find the minimal program that reproduces the issue,
preprocessed outputs (.ii, .o and .s files) and invocation log (everything GCC
prints to stderr while working, including build configuration, correct version
etc.). The system is fully updated ArchLinux with GCC 4.9.2.
I've also attached full debug output of clang compiler for convenience because
the same program can be compiled with clang without causing error.
[Bug tree-optimization/66185] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66185 Richard Biener rguenth at gcc dot gnu.org 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 rguenth at gcc dot gnu.org --- Mine (probably a dup).
[Bug middle-end/66178] [4.8/4.9/5/6 Regression] Another label as values ICE in gen_reg_rtx, at emit-rtl.c:1059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66178 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.3.4 Version|unknown |6.0 Keywords||accepts-invalid Last reconfirmed||2015-05-18 Component|tree-optimization |middle-end Ever confirmed|0 |1 Summary|Another label as values ICE |[4.8/4.9/5/6 Regression] ||Another label as values ICE ||in gen_reg_rtx, at ||emit-rtl.c:1059 Target Milestone|--- |4.8.5 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. t.c:10:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1059 } ^ 0x95343b gen_reg_rtx(machine_mode) /space/rguenther/src/svn/trunk2/gcc/emit-rtl.c:1059 0xc8a3da maybe_legitimize_operand /space/rguenther/src/svn/trunk2/gcc/optabs.c:8296 0xc8a739 maybe_legitimize_operands(insn_code, unsigned int, unsigned int, expand_operand*) /space/rguenther/src/svn/trunk2/gcc/optabs.c:8369 0xc8a7ca maybe_gen_insn(insn_code, unsigned int, expand_operand*) /space/rguenther/src/svn/trunk2/gcc/optabs.c:8387 0xc79a83 expand_binop_directly /space/rguenther/src/svn/trunk2/gcc/optabs.c:1496 0xc79d0c expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*, int, optab_methods) /space/rguenther/src/svn/trunk2/gcc/optabs.c:1566 ... 0x1103344 expand_expr /space/rguenther/src/svn/trunk2/gcc/expr.h:254 0x111098b output_constant /space/rguenther/src/svn/trunk2/gcc/varasm.c:4793 while for example GCC 4.3 says gcc-4.3 -S t.c -O2 t.c: In function ‘test’: t.c:4: error: initializer element is not computable at load time and gcc-4.8 -S t.c -O2 t.c:10:1: internal compiler error: output_operand: invalid expression as operand } ^ Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.opensuse.org/ for instructions. I think the initializers are simply not valid.
[Bug libstdc++/66157] bits/random.tcc compiler error when using -fno-for-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66157 --- Comment #9 from Luca Stoppa luca.stoppa at bbh dot com --- I see. Thanks again for your answer.
[Bug tree-optimization/14741] graphite with loop blocking and interchanging doesn't optimize a matrix multiplication loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741 --- Comment #32 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Thomas Koenig from comment #31) If the middle end is not up to this, should we be looking at doing loop blocking in the Fortran front end, at least for the Matmul intrinsic? I think this makes sense, fixing this issue in the middle end seems to be a project on a different timescale. Ideally, matmul expands to something that generates good code even at e.g. -O2 -march=native (which would require both blocking and unrolling). At that point, the inlined code would be faster than the runtime library...for all sizes.
[Bug tree-optimization/66185] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66185 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-18 CC||jakub at gcc dot gnu.org Target Milestone|--- |6.0 Summary|ICE on valid code at -O3 on |[6 Regression] ICE on valid |x86_64-linux-gnu|code at -O3 on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r222514.
[Bug target/66195] New: Optimize _GLIBCXX_GUARD_TEST_AND_ACQUIRE and _GLIBCXX_GUARD_SET_AND_RELEASE for PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66195 Bug ID: 66195 Summary: Optimize _GLIBCXX_GUARD_TEST_AND_ACQUIRE and _GLIBCXX_GUARD_SET_AND_RELEASE for PowerPC Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org Target Milestone: --- Target-specific optimization opportunity in libstdc++/libsupc++ for __cxa_guard_acquire and __cxa_guard_release.
[Bug sanitizer/66190] [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- So maybe the following? Not sure how well it plays with weak vars/fns though... --- a/gcc/c-family/c-ubsan.c +++ b/gcc/c-family/c-ubsan.c @@ -433,8 +433,9 @@ ubsan_maybe_instrument_reference_or_call (location_t loc, tree op, tree ptype, int save_flag_delete_null_pointer_checks = flag_delete_null_pointer_checks; flag_delete_null_pointer_checks = 1; - if (!tree_single_nonzero_warnv_p (op, strict_overflow_p) - || strict_overflow_p) + if ((!tree_single_nonzero_warnv_p (op, strict_overflow_p) + || strict_overflow_p) + !TREE_STATIC (TREE_OPERAND (op, 0))) instrument = true; flag_delete_null_pointer_checks = save_flag_delete_null_pointer_checks;
[Bug c/66194] emit vectorization instruction for not aligned data(amd64), -fno-strict-aliasing not help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66194 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-05-18 CC||hjl.tools at gmail dot com Ever confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- Which gcc did you use? Please provide a run-time test.
[Bug c/66194] emit vectorization instruction for not aligned data(amd64), -fno-strict-aliasing not help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66194 --- Comment #3 from Evgeniy Dushistov dushistov at mail dot ru --- So step to reproduce: 1)Download attachment 2)Extract tar xvf dummy_hash.tar 3)Build cd dummy_hash make 4)Run ./thash
[Bug c/66194] emit vectorization instruction for not aligned data(amd64), -fno-strict-aliasing not help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66194 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- C standard says this is undefined code.
[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 --- Comment #3 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Hmm, no observable difference with option -fno-frontend-optimize, sorry. Of course I probed some combinations for several options. One example for a more extensive debug run : gfortran \ -O0 -g -msse3 \ -fno-omit-frame-pointer \ -fdefault-real-8 \ -fno-align-commons \ -std=f2008 \ -pedantic \ -fcheck=all \ -fbacktrace \ -ftrapv \ -ffpe-trap=invalid,zero,overflow \ -fstack-protector \ -fstack-protector-all \ \ -Wall \ -Wextra \ -Wsurprising \ -Warray-bounds \ -Warray-temporaries \ -Wcharacter-truncation \ -Wconversion-extra \ -Wfunction-elimination \ -Wrealloc-lhs \ -Wrealloc-lhs-all \ -Wtabs \ -Wunderflow \ -Wunused-dummy-argument \ \ # ... some more # ... with and without -c
[Bug target/66049] [6 regression] Few AArch64 extend and add with shift tests generates sub optimal code with trunk gcc 6.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66049
--- Comment #7 from vekumar at gcc dot gnu.org ---
(In reply to ktkachov from comment #3)
Venkat, are you planning to submit this patch to gcc-patches?
Also, does this mean we can remove the patterns that do arith+shift using
MULT rtxes? (like *adds_optabmode_multp2)
Hi Kyrill,
I added shift based patterns for
*adds_optabmode_multp2
*subs_optabmode_multp2
*add_uxtmode_multp2
*add_uxtsi_multp2_uxtw
*sub_uxtmode_multp2
*sub_uxtsi_multp2_uxtw
*adds_mul_imm_mode
*subs_mul_imm_mode
I added gcc_unreachable to these patterns and gcc boostrapped except
add_uxtmode_multp2 pattern.
The pattern *add_uxtdi_multp2 can still be generated.
/root/work/GCC_Team/vekumar/build-assert-check/./gcc/xgcc
-B/root/work/GCC_Team/vekumar/build-assert-check/./gcc/
-B/root/work/GCC_Team/vekumar/install-assert-check/aarch64-unknown-linux-gnu/bin/
-B/root/work/GCC_Team/vekumar/install-assert-check/aarch64-unknown-linux-gnu/lib/
-isystem
/root/work/GCC_Team/vekumar/install-assert-check/aarch64-unknown-linux-gnu/include
-isystem
/root/work/GCC_Team/vekumar/install-assert-check/aarch64-unknown-linux-gnu/sys-include
-g -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -fPIC -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector -fPIC -I. -I. -I../.././gcc
-I../../../gcc-assert-check/libgcc -I../../../gcc-assert-check/libgcc/.
-I../../../gcc-assert-check/libgcc/../gcc
-I../../../gcc-assert-check/libgcc/../include -DHAVE_CC_TLS -o _gcov.o -MT
_gcov.o -MD -MP -MF _gcov.dep -DL_gcov -c
../../../gcc-assert-check/libgcc/libgcov-driver.c
insn 1325 1324 1326 137 (set (reg:DI 725 [ ix ])
(zero_extend:DI (reg/v:SI 197 [ ix ])))
../../../gcc-assert-check/libgcc/libgcov-driver.c:103 73
{*zero_extendsidi2_aarch64}
(nil))
(insn 1326 1325 1327 137 (set (reg:DI 726)
(plus:DI (reg:DI 725 [ ix ])
(const_int 4 [0x4])))
../../../gcc-assert-check/libgcc/libgcov-driver.c:103 87 {*adddi3_aarch64}
(expr_list:REG_DEAD (reg:DI 725 [ ix ])
(nil)))
(insn 1327 1326 3536 137 (set (reg/f:DI 727)
(mem/f:DI (plus:DI (mult:DI (reg:DI 726)
(const_int 8 [0x8]))
(reg/v/f:DI 571 [ list ])) [2 MEM[(const struct gcov_info
*)list_372].merge S8 A64]))
../../../gcc-assert-check/libgcc/libgcov-driver.c:103 40 {*movdi_aarch64}
Successfully matched this instruction:
(set (reg/f:DI 727)
(plus:DI (and:DI (mult:DI (subreg:DI (reg/v:SI 197 [ ix ]) 0)
(const_int 8 [0x8]))
(const_int 34359738360 [0x7fff8]))
(reg/v/f:DI 571 [ list ])))
(insn 1326 1325 1327 137 (set (reg:DI 726)
(plus:DI (and:DI (mult:DI (subreg:DI (reg/v:SI 197 [ ix ]) 0)
(const_int 8 [0x8]))
(const_int 34359738360 [0x7fff8]))
(reg/v/f:DI 571 [ list ])))
../../../gcc-assert-check/libgcc/libgcov-driver.c:103 252 {*add_uxtdi_multp2}
(nil))
(insn 1327 1326 3536 137 (set (reg/f:DI 727)
(mem/f:DI (plus:DI (reg:DI 726)
(const_int 32 [0x20])) [2 MEM[(const struct gcov_info
*)list_372].merge S8 A64]))
../../../gcc-assert-check/libgcc/libgcov-driver.c:103 40 {*movdi_aarch64}
I am going to first send out patch for adding new shift based patterns.
Then separate patch test and remove mul patterns.
[Bug rtl-optimization/57032] [4.9/5/6 Regression]: internal compiler error: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57032 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Uroš Bizjak ubizjak at gmail dot com --- This particular problem is now fixed.
[Bug c/66194] emit vectorization instruction for not aligned data(amd64), -fno-strict-aliasing not help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66194 --- Comment #2 from Evgeniy Dushistov dushistov at mail dot ru --- (In reply to H.J. Lu from comment #1) Which gcc did you use? Please provide a run-time test. I try gcc 4.6.4, 4.7.4, 4.9.2, 5.1.0. If you compile attachment on linux/amd64 and run: ./thash then it give segfault with all versions.
[Bug tree-optimization/65752] Too strong optimizations int - pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
Chung-Kil Hur gil.hur at sf dot snu.ac.kr changed:
What|Removed |Added
CC||gil.hur at sf dot snu.ac.kr
--- Comment #13 from Chung-Kil Hur gil.hur at sf dot snu.ac.kr ---
Hi, I have the following modified code.
#include stdio.h
#include stdint.h
#include limits.h
int main() {
int x = 0, *p = 0;
uintptr_t i;
uintptr_t j = (uintptr_t) x;
uintptr_t k = j+j;
uintptr_t l = 2*j - j - j;
for (i = j+j-k+l; ; i++) {
if (i == (uintptr_t)x) { p = (int*)i; break; }
}
*p = 15;
printf(%d\n, x);
}
This example still prints out 0 instead of 15.
In this example, it seems that the integer j+j-k+l has no provenance.
It is unclear to me how the provenance is calculated.
Is there any concrete rule for calculating provenance?
[Bug c/66194] emit vectorization instruction for not aligned data(amd64), -fno-strict-aliasing not help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66194 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- -fsanitize=undefined shows: % ./thash dummyhash.c:10:11: runtime error: load of misaligned address 0x7ffd86aca073 for type 'uint32_t', which requires 4 byte alignment 0x7ffd86aca073: note: pointer points here 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^
[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||kargl at gcc dot gnu.org --- Comment #4 from kargl at gcc dot gnu.org --- Confirmed. Here's a slightly expanded testcase where it shows that the first 2 lines are failing. program p real :: z(2) z = 1 + [real :: 1, 2]! fails z = 1. + [real :: 1, 2] ! fails z = 1. + [1, 2]! OK z = 1. + [real :: 1., 2.] ! OK z = 1. + [real :: 1.d0, 2.d0] ! OK z = 1 + [1, 2] ! OK z = 1 + [real :: 1., 2.] ! OK z = 1 + [real :: 1.d0, 2.d0] ! OK z = [1, 2] + 1 ! OK z = [real :: 1., 2.] + 1 ! OK z = [real :: 1.d0, 2.d0] + 1 ! OK z = [1, 2] + 1.! OK z = [real :: 1., 2.] + 1. ! OK z = [real :: 1.d0, 2.d0] + 1. ! OK print *, z end
[Bug lto/66103] [6 Regression] ICE verify_type failed with LTO and -g -O0 via dwarf2out.c's gen_type_die_with_usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66103 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org --- I committed the patch to block debug info for slim LTO. This testcase will need -ffat-lto-objects to reproduce. I suppose the practical approach is to allow the mismatch here with flat_fat_lto_objects !in_lto_p with the explanation that free lang data partially clears it.
[Bug c/66194] emit vectorization instruction for not aligned data(amd64), -fno-strict-aliasing not help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66194 --- Comment #6 from Evgeniy Dushistov dushistov at mail dot ru --- (In reply to Andrew Pinski from comment #5) C standard says this is undefined code. Where? there is two issues aliasing (but I use -fno-strict-aliasing), and alignment, c99 of course do not mention exact value of align requirements, But from http://www.x86-64.org/documentation/abi.pdf (I think gcc uses it on amd64): Like the Intel386 architecture, the AMD64 architecture in general does not require all data accesses to be properly aligned. Misaligned data accesses are slower than aligned accesses but otherwise behave identically. So I think that with System V AMD64 ABI it is allowed to use int pointer that not aligned, and of course this example created for demonstrate misaligned access. And for example icc not generate code with simd (which cause crash) instructions for this function.
[Bug middle-end/66110] uint8_t memory access not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110 --- Comment #11 from Andreas Schwab sch...@linux-m68k.org --- Since typedef does not create a new type the effect of uint8_t is exactly the same as the type it is defined from. Thus if uint8_t is defined from unsigned char then uint8_t is a character type.
[Bug middle-end/66110] uint8_t memory access not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110 --- Comment #12 from Kevin OConnor kevin at koconnor dot net --- (In reply to Andreas Schwab from comment #11) Since typedef does not create a new type the effect of uint8_t is exactly the same as the type it is defined from. Thus if uint8_t is defined from unsigned char then uint8_t is a character type. Yes, of course. My point is that gcc does not need to define uint8_t / __UINT8_TYPE__ as 'unsigned char'. Instead it could define it as a new integer type (eg, __gcc_uint8_t) that is an 8-bit integer that does not alias. As before, I understand if the cost of doing this is too high, but it's unfortunate that there currently does not appear to be any way to define a pointer to an 8-bit integer that doesn't alias.
[Bug rtl-optimization/57032] [4.9/5/6 Regression]: internal compiler error: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57032 --- Comment #15 from uros at gcc dot gnu.org --- Author: uros Date: Mon May 18 16:34:23 2015 New Revision: 223298 URL: https://gcc.gnu.org/viewcvs?rev=223298root=gccview=rev Log: PR target/57032 * config/alpha/constraints.md (Q): Rewrite as define_memory_constraint. Check for a memory location that is not a reference (using an AND) to an unaligned location here. * config/alpha/predicates.md (normal_memory_operand): Remove. Modified: trunk/gcc/ChangeLog trunk/gcc/config/alpha/constraints.md trunk/gcc/config/alpha/predicates.md
[Bug middle-end/66110] uint8_t memory access not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110 --- Comment #10 from Kevin OConnor kevin at koconnor dot net --- I've looked through the C specs (both C99 and C11) and I don't see anything that requires uint8_t (nor int8_t) to be considered character types. I do see three relevant sections in the spec which I'm including below. For aliasing there is section 6.5: 7 An object shall have its stored value accessed only by an lvalue expression that has one of the following types: [...] -- a character type. For character types there is section 6.2.5: 15 The three types char, signed char, and unsigned char are collectively called the character types. [...] For uint8_t there is section 7.20.1.1: 7.20.1.1 Exact-width integer types 1 The typedef name intN_t designates a signed integer type with width N , no padding bits, and a two's complement representation. Thus, int8_t denotes such a signed integer type with a width of exactly 8 bits. 2 The typedef name uintN_t designates an unsigned integer type with width N and no padding bits. Thus, uint24_t denotes such an unsigned integer type with a width of exactly 24 bits. So, my read is that uint8_t must be considered an integer type, but is not required to be considered a character type. That said, I understand that changing uint8_t may cause problems for some existing user-code. I'd think those enabling -fstrict-aliasing would want the optimization benefit though. I certainly understand if the cost of introducing another integer type and the potential cost of causing issues for existing code is considered too high. It is unfortunate, though, that there doesn't appear to currently be any way to declare a pointer to a non-aliasing 8-bit integer (that doesn't involve 'struct' hacks).
[Bug target/66195] Optimize _GLIBCXX_GUARD_TEST_AND_ACQUIRE and _GLIBCXX_GUARD_SET_AND_RELEASE for PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66195 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Target||powerpc*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-18 CC||munroesj at us dot ibm.com, ||wschmidt at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from David Edelsohn dje at gcc dot gnu.org --- Confirmed.
[Bug ipa/66122] Bad uninlining decisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
--- Comment #10 from Denis Vlasenko vda.linux at googlemail dot com ---
(In reply to Jakub Jelinek from comment #9)
If you expect that all functions with inline keyword must be always inlined,
then you really should use __always_inline__ attribute. Otherwise, inline
keyword is primarily an optimization hint to the compiler that it might be
desirable to inline it. So, talking about uninlining or deinlining makes
absolutely no sense,
Jakub, are you saying that compiling
static inline oid spin_unlock(spinlock_t *lock)
{
__raw_spin_unlock(lock-rlock);
}
, where __raw_spin_unlock is a function (not macro), to a deinlined function
spin_unlock:
call __raw_spin_unlock
ret
and then callers doing
call spin_unlock
*can ever* make sense? That's ridiculous.
How about this?
static inline void atomic_inc(atomic_t *v)
{
asm volatile(LOCK_PREFIX incl %0
: +m (v-counter));
}
You think it's okay to not inline one insn?
Kernel people did not take my patch which tries to fix this by __always_inining
locking ops. Basically, they think that compiler should not do stupid things.
[Bug c/66194] emit vectorization instruction for not aligned data(amd64), -fno-strict-aliasing not help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66194 --- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org --- 6.3.2.3 p7: »A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned for the referenced type, the behavior is undefined.«
[Bug c/66194] emit vectorization instruction for not aligned data(amd64), -fno-strict-aliasing not help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66194 --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Evgeniy Dushistov from comment #8) (In reply to Markus Trippelsdorf from comment #7) 6.3.2.3 p7: »A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned for the referenced type, the behavior is undefined.« Yep, but what does it mean not correctly aligned? each type has an alignment associated with it. In the case of AMD64, it is defined by the ABI. x86/amd64 allow misaligned memory access, ABI also allow this: ABI requirements are not C requirements always. This paragraph is talking about memory accesses but really it did not take into account other requirements of C correctly.
[Bug c++/65890] [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890 --- Comment #5 from frankhb1989 at gmail dot com --- (In reply to Jonathan Wakely from comment #3) This was changed by http://open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#613 It was a defect in the original standard. What possible advantage is there in rejecting it in C++03 mode but accepting it in C++11 mode? i.e. why do you consider this a bug? Mainly for testing of the conformance. Although it is treated a defect of the design and has been changed later, the old rules are still well-defined and the published standard itself is consistent. So if I did not get wrong about the purpose of '-std=', this should be a bug. Whether it is worth being fixed is another problem. On the other hand, I'd debate the resolution of this CWG issue is not pure improvement. There could be a trick to distinguish static and non-static data members through SFINAE on expressions like 'sizeof((C::x))'. It is broken now.
[Bug ipa/66122] Bad uninlining decisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Comment #11 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
(In reply to Denis Vlasenko from comment #10)
(In reply to Jakub Jelinek from comment #9)
If you expect that all functions with inline keyword must be always inlined,
then you really should use __always_inline__ attribute. Otherwise, inline
keyword is primarily an optimization hint to the compiler that it might be
desirable to inline it. So, talking about uninlining or deinlining makes
absolutely no sense,
Jakub, are you saying that compiling
static inline oid spin_unlock(spinlock_t *lock)
{
__raw_spin_unlock(lock-rlock);
}
, where __raw_spin_unlock is a function (not macro), to a deinlined function
spin_unlock:
call __raw_spin_unlock
ret
and then callers doing
call spin_unlock
*can ever* make sense? That's ridiculous.
How about this?
static inline void atomic_inc(atomic_t *v)
{
asm volatile(LOCK_PREFIX incl %0
: +m (v-counter));
}
You think it's okay to not inline one insn?
Kernel people did not take my patch which tries to fix this by
__always_inining locking ops.
That is their problem then. Every other sane project uses __always_inline for
this issue.
Basically, they think that compiler should not do stupid things.
The compiler isn't psychic, e.g. it doesn't parse asm statements at all (so
it cannot know how many insn it contains).
[Bug ipa/66181] [6 Regression]: /usr/include/bits/types.h:134:16: ICE: verify_type failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66181 --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org --- I suppose the problem here is that stor-layout adds TYPE_NO_FORCE_BLK on the main variant. I suppose either we can copy it consistently: Index: stor-layout.c === --- stor-layout.c (revision 222869) +++ stor-layout.c (working copy) @@ -1834,6 +1834,7 @@ TYPE_ALIGN (variant) = valign; TYPE_PRECISION (variant) = precision; SET_TYPE_MODE (variant, mode); + TYPE_NO_FORCE_BLK (variant) = TYPE_NO_FORCE_BLK (type); } } } or declare the flag to be local to stor-layout, clear it in free_lang_data and avoid its LTO streaming.
[Bug c/66194] emit vectorization instruction for not aligned data(amd64), -fno-strict-aliasing not help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66194 --- Comment #8 from Evgeniy Dushistov dushistov at mail dot ru --- (In reply to Markus Trippelsdorf from comment #7) 6.3.2.3 p7: »A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned for the referenced type, the behavior is undefined.« Yep, but what does it mean not correctly aligned? x86/amd64 allow misaligned memory access, ABI also allow this: the AMD64 architecture in general does not require all data accesses to be properly aligned The only exceptions are that __m128 and __m256 must always be aligned properly, So is it gcc only requirements for x86/amd64, that things like char buf[8] __attribute__ ((aligned (8))); int *p = buf[3]; p is not correctly aligned?
[Bug ipa/66122] Bad uninlining decisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122 --- Comment #12 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #11) The compiler isn't psychic, e.g. it doesn't parse asm statements at all (so it cannot know how many insn it contains). Actually it does some parsing just to see how many statements. That is it uses ';', and newline as an estimate of how many statements there are. And then uses that for an estimate in the cost (I know it does this because I added this support). But there are some many different heuristics for the inliner and it could decide if it is one instruction not to inline it anyways for other reasons.
[Bug lto/66196] New: Wrong type incompatibility warning for -flto and C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66196
Bug ID: 66196
Summary: Wrong type incompatibility warning for -flto and C
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
jan@linux-qos1:~ cat t.c
union a {
int a;
long b;
};
union a a;
jan@linux-qos1:~ cat t2.c
union a {
long b;
int a;
};
union a a;
jan@linux-qos1:~ gcc -O2 -flto t.c t2.c
t2.c:5:9: warning: type of ‘a’ does not match original declaration [enabled by
default]
union a a;
^
t.c:5:9: note: previously declared here
union a a;
^
I believe the warning is wrong here by 6.2.7.1 of the standard:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
Moreover, two structure, union, or enumerated types declared in separate
translation units are compatible if their tags and members satisfy the
following requirements: If one is declared with a tag, the other shall be
declared with the same tag. If both are completed anywhere within their
respective translation units, then the following additional requirements apply:
there shall be a one-to-one correspondence between their members such that each
pair of corresponding members are declared with compatible types; if one member
of the pair is declared with an alignment specifier, the other is declared with
an equivalent alignment specifier; and if one member of the pair is declared
with a name, the other is declared with the same name. For two structures,
corresponding members shall be declared in the same order. For two
structures or unions, corresponding bit-fields shall have the same widths. For
two enumerations, corresponding members shall have the same values.
For two structures, corresponding members shall be declared in the same
order. seems to rule out unions.
We do not match alignments/memory layout/bitfields in type canonical type code
that we probably should.
I suppose we can't match FIELD_DECL names in current implementation to allow
non-C/C++ matching.
The warning probably translates to a wrong code eventually.
[Bug fortran/64925] ICE with same names for dummy arg and internal procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64925 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon May 18 19:25:49 2015 New Revision: 223313 URL: https://gcc.gnu.org/viewcvs?rev=223313root=gccview=rev Log: 2015-05-18 Steven G. Kargl ka...@gcc.gnu.org PR fortran/64925 * symbol.c(check_conflict): Check for a conflict between a dummy argument and an internal procedure name. 2015-05-18 Steven G. Kargl ka...@gcc.gnu.org PR fortran/64925 * gfortran.dg/pr64925.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr64925.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog
[Bug c/66194] emit vectorization instruction for not aligned data(amd64), -fno-strict-aliasing not help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66194 --- Comment #10 from Evgeniy Dushistov dushistov at mail dot ru --- ABI requirements are not C requirements always. This paragraph is talking about memory accesses but really it did not take into account other requirements of C correctly. But where then I can get this C requirements, standard(C99) mention only align requirements, but no method how to calculate them, so it may be a)ABI that gcc implement, but compiler may have more strict requirement (and you acknowledge this) b)In gcc documentation, but I can see in C Implementation any hints, there is only in Extensions to the C Language Family operator alignof, that give 4 for both x86/amd64, but it describe it as: Some machines never actually require alignment; they allow reference to any data type even at an odd address. For these machines, '__alignof__' reports the smallest alignment that GCC gives the data type, usually as mandated by the target ABI, there is no note that result of alignof is strict memory requirements of gcc, If I add note about this in texinfo, is this patch be accepted?
[Bug fortran/66039] ICE on incomplete parentheses at rewind, flush, endfile, backspace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66039 --- Comment #2 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon May 18 21:04:33 2015 New Revision: 223315 URL: https://gcc.gnu.org/viewcvs?rev=223315root=gccview=rev Log: 2015-05-18 Steven G. Kargl ka...@gcc.gnu.org PR fortran/66039 * io.c (match_filepos): Check for incomplete/mangled REWIND, FLUSH, BACKSPACE, and ENDFILE statements 2015-05-18 Steven G. Kargl ka...@gcc.gnu.org PR fortran/66039 * gfortran.dg/filepos1.f90: New test Added: trunk/gcc/testsuite/gfortran.dg/filepos1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/66181] [6 Regression]: /usr/include/bits/types.h:134:16: ICE: verify_type failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66181 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org --- When building an SH cross compiler, there is a similar error when building libstdc++. The patch in comment 6 makes the build run to completion.
[Bug fortran/66043] ICE on storage_size of null or output of null array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66043 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon May 18 21:52:03 2015 New Revision: 223320 URL: https://gcc.gnu.org/viewcvs?rev=223320root=gccview=rev Log: 2015-05-18 Steven G. Kargl ka...@gcc.gnu.org PR fortran/66043 * check.c (gfc_check_storage_size): Prevent the direct use of NULL() in STORAGE_SIZE() reference. 2015-05-18 Steven G. Kargl ka...@gcc.gnu.org PR fortran/66043 * gfortran.dg/storage_size_6.f90: New tests. Added: trunk/gcc/testsuite/gfortran.dg/storage_size_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/66110] uint8_t memory access not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110 --- Comment #13 from joseph at codesourcery dot com joseph at codesourcery dot com --- I concur that it would be valid to define those typedefs to be extended integer types withing the special aliasing properties. The first suggestion of that on the GCC lists that I know of is https://gcc.gnu.org/ml/gcc/2000-05/msg01106.html. However, it was noted in https://gcc.gnu.org/ml/gcc/2000-07/msg00155.html that there would be C++ issues. I see that C++ does now have extended integer types, which it didn't at that time, but there would still be questions of mangling (changing typedefs from standard headers breaks the library ABI for anything using those types in C++ interfaces, because of changed mangling). And of course the question of what expectations might be broken in C by making these typedefs into extended integer types. Cf https://gcc.gnu.org/ml/gcc-patches/2002-01/msg01941.html implementing a char_no_alias_everything attribute.
[Bug fortran/66040] ICE on misplaced sequence in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66040 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon May 18 21:16:05 2015 New Revision: 223318 URL: https://gcc.gnu.org/viewcvs?rev=223318root=gccview=rev Log: 2015-05-18 Steven G. Kargl ka...@gcc.gnu.org PR fortran/66040 * parse.c(verify_st_order): Replace a gfc_internal_error with your generic gfc_error. 2015-05-18 Steven G. Kargl ka...@gcc.gnu.org PR fortran/66040 * gfortran.dg/misplaced_statement.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/misplaced_statement.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/parse.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/65874] [5 Regression] bootstrap comparison failure (gcc/ira.o) on ia64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65874 --- Comment #2 from Matthias Klose doko at gcc dot gnu.org --- is there an easy way to implement this scenario with a patch? I don't have access anymore to ia64 machines, the only resource is a buildd building distribution packages.
[Bug fortran/66044] ICE on misplaced entry statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66044 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon May 18 22:06:48 2015 New Revision: 223321 URL: https://gcc.gnu.org/viewcvs?rev=223321root=gccview=rev Log: 2015-05-18 Steven G. Kargl ka...@gcc.gnu.org PR fortran/66044 * decl.c(gfc_match_entry): Change a gfc_internal_error() into a gfc_error() 2015-05-18 Steven G. Kargl ka...@gcc.gnu.org PR fortran/66044 * gfortran.dg/entry_21.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/entry_21.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/66045] ICE on incorrect code with null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66045 --- Comment #2 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon May 18 22:21:08 2015 New Revision: 223322 URL: https://gcc.gnu.org/viewcvs?rev=223322root=gccview=rev Log: 2015-05-18 Steven G. Kargl ka...@gcc.gnu.org PR fortran/66045 * expr.c (gfc_check_assign): Check for assignment of NULL() instead of the (intended) pointer assignment. 2015-05-18 Steven G. Kargl ka...@gcc.gnu.org PR fortran/66045 * gfortran.dg/null1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/null1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/66178] [4.8/4.9/5/6 Regression] Another label as values ICE in gen_reg_rtx, at emit-rtl.c:1059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66178 Mikhail Maltsev miyuki at gcc dot gnu.org changed: What|Removed |Added CC||miyuki at gcc dot gnu.org --- Comment #4 from Mikhail Maltsev miyuki at gcc dot gnu.org --- But for static int a = ((char *)l1-(char *)l2)+1; GCC is able to emit a valid initializer: .LFE1: .size main, .-main .section.rodata .align 4 .type a.1833, @object .size a.1833, 4 a.1833: .long .L2-.L3+1 And for last testcase the backtrace looks quite different: ./test.c:13:1: internal compiler error: output_operand: invalid expression as operand } ^ 0x7ed77f output_operand_lossage(char const*, ...) ../../src/gcc/final.c:3446 0x7ee045 output_addr_const(_IO_FILE*, rtx_def*) ../../src/gcc/final.c:4035 0x7edfe5 output_addr_const(_IO_FILE*, rtx_def*) ../../src/gcc/final.c:3995 0xd808ee assemble_integer_with_op(char const*, rtx_def*) ../../src/gcc/varasm.c:2743 0xd80956 default_assemble_integer(rtx_def*, unsigned int, int) ../../src/gcc/varasm.c:2759 0xd809d0 assemble_integer(rtx_def*, unsigned int, unsigned int, int) ../../src/gcc/varasm.c:2775 0xd86910 output_constant ../../src/gcc/varasm.c:4795
[Bug middle-end/66110] uint8_t memory access not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110 --- Comment #14 from Kevin OConnor kevin at koconnor dot net --- (In reply to jos...@codesourcery.com from comment #13) I concur that it would be valid to define those typedefs to be extended integer types withing the special aliasing properties. The first suggestion of that on the GCC lists that I know of is https://gcc.gnu.org/ml/gcc/2000-05/msg01106.html. However, it was noted in https://gcc.gnu.org/ml/gcc/2000-07/msg00155.html that there would be C++ issues. I see that C++ does now have extended integer types, which it didn't at that time, but there would still be questions of mangling (changing typedefs from standard headers breaks the library ABI for anything using those types in C++ interfaces, because of changed mangling). And of course the question of what expectations might be broken in C by making these typedefs into extended integer types. Many thanks. Those links and the background information is quite helpful. I agree that breaking the C++ ABI would not make sense on the major platforms. Cf https://gcc.gnu.org/ml/gcc-patches/2002-01/msg01941.html implementing a char_no_alias_everything attribute. I do think having something like char_no_alias_everything would be useful. My interest in this discussion was due to the code generation on the embedded AVR platform (where 8-bit integers are very common). If non-aliasing 8-bit integer types existed, I suspect dealing with ABI breakage would be more tenable on AVR. (And if nothing else, utilizing them within an individual AVR project would not be difficult.)
[Bug c++/65890] [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to frankhb1989 from comment #5) Mainly for testing of the conformance. I don't understand what this means. Testing what? G++? G++ does not exist for you to test its conformance to a standard. Most users don't care about slavish conformance to a defective specification, they want a useful compiler. Although it is treated a defect of the design and has been changed later, the old rules are still well-defined and the published standard itself is consistent. So if I did not get wrong about the purpose of '-std=', this should be a bug. Whether it is worth being fixed is another problem. You are wrong about how -std options work. We incorporate dozens of DRs into all modes, instead of making them only apply to later standard modes. On the other hand, I'd debate the resolution of this CWG issue is not pure improvement. There could be a trick to distinguish static and non-static data members through SFINAE on expressions like 'sizeof((C::x))'. It is broken now. SFINAE in C++03 was not nearly as useful, and doesn't work for private members. The language is more useful now, there is no reason to hobble it with a foolish consistency to a defective design. Not a bug.
[Bug c++/66197] New: c++1z generic function wrong type for auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66197
Bug ID: 66197
Summary: c++1z generic function wrong type for auto
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: theonetruekenny at yahoo dot com
Target Milestone: ---
https://gcc.gnu.org/ml/gcc-help/2015-05/msg00066.html
#include iostream
auto add_1(auto a, auto b) { return a + b;}
auto add_2 = [](auto a, auto b) { return a + b;};
int main()
{
std::cout
a1: add_1(3.5, 4) \n
a2: add_1(3, 4.5) \n
a3: add_2(3.5, 4) \n
a4: add_2(3, 4.5) \n;
}
This gives me:
a1: 7.5
a2: 7
a3: 7.5
a4: 7.5
But the expected value for a2 would also be 7.5.
This was with This is with a fedora 22/x86-64 machine.
gcc version 5.1.1 20150422 (Red Hat 5.1.1-1) (GCC)
According to the current spec:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3889.pdf
15 A generic function is denoted by function declarator having auto
or a concept-name as part of the type-specifier in its
parameter-declaration-clause
17 All placeholder types introduced using the same concept-name have
the same invented template parameter.
It would appear that gcc is applying the rule from 17 even in the case of
'auto'.
[Bug rtl-optimization/66168] [6 Regression] ICE at -O3 in elimination_costs_in_insn, at reload1.c:3677
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66168 --- Comment #4 from Thomas Preud'homme thopre01 at gcc dot gnu.org --- Testsuite came back ok. Will post patch shortly.
[Bug c++/66197] c++1z generic function wrong type for auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66197 --- Comment #1 from theonetruekenny at yahoo dot com --- This might be another symptom of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64969
[Bug fortran/66052] Segmentation fault for misplaced protected statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66052 --- Comment #2 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon May 18 22:52:52 2015 New Revision: 223324 URL: https://gcc.gnu.org/viewcvs?rev=223324root=gccview=rev Log: 2015-05-18 Steven G. Kargl ka...@gcc.gnu.org PR fortran/66052 * decl.c(gfc_match_protected): Prevent dereference of NULL pointer. 2015-05-18 Steven G. Kargl ka...@gcc.gnu.org PR fortran/66052 * gfortran.dg/protected_9.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/protected_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/66181] [6 Regression]: /usr/include/bits/types.h:134:16: ICE: verify_type failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66181 Thomas Preud'homme thopre01 at gcc dot gnu.org changed: What|Removed |Added CC||thopre01 at gcc dot gnu.org --- Comment #8 from Thomas Preud'homme thopre01 at gcc dot gnu.org --- Patch in #6 also fixes build of arm-none-eabi cross-compiler.
[Bug fortran/66057] ICE for incomplete generic statement (gfc_match_generic)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66057 --- Comment #2 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon May 18 23:09:49 2015 New Revision: 223325 URL: https://gcc.gnu.org/viewcvs?rev=223325root=gccview=rev Log: 2015-05-18 Steven G. Kargl ka...@gcc.gnu.org PR fortran/66057 * decl.c(gfc_match_generic): Detected a malformed GENERIC statement. 2015-05-18 Steven G. Kargl ka...@gcc.gnu.org PR fortran/66057 * gfortran.dg/generic_29.f90: New tests. Added: trunk/gcc/testsuite/gfortran.dg/generic_29.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/66057] ICE for incomplete generic statement (gfc_match_generic)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66057 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon May 18 23:26:38 2015 New Revision: 223326 URL: https://gcc.gnu.org/viewcvs?rev=223326root=gccview=rev Log: 2015-05-18 Steven G. Kargl ka...@gcc.gnu.org PR fortran/66057 * interface.c(gfc_match_end_interface): Enforce F2008 C1202 (R1201). * match.c(gfc_op2string): Return 'none' for INTRINSIC_NONE. 2015-05-18 Steven G. Kargl ka...@gcc.gnu.org PR fortran/66057 * gfortran.dg/interface_operator_1.f90: New tests. Added: trunk/gcc/testsuite/gfortran.dg/interface_operator_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/66186] [4.9/5/6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66186 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-18 CC||jakub at gcc dot gnu.org Summary|wrong code at -O3 on|[4.9/5/6 Regression] wrong |x86_64-linux-gnu|code at -O3 on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r204458. But most likely this is yet another case of the RTL bug where stack pointer based accesses are considered as non-trapping, despite being clearly out of bounds. The pcom change only changed f_I_lsm0.4_7 = f[65535]; which the compiler can see as being out of bounds access quickly (note, f is int f[2]), but after the pcom change it uses f_I_lsm0.4_7 = MEM[(int *)f + 262140B]; and for some reason we don't consider that as clearly out of bounds access.
[Bug fortran/66189] New: Block loops for inline matmul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66189 Bug ID: 66189 Summary: Block loops for inline matmul Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- It would be nice to block (and possibly unroll, but that may better be left to -O3) inline matrix multiplication for better performance. Now we generate the loops in the front end, it should be doable.
[Bug target/66015] align directives not propagated after __attribute__ ((__optimize__ (O2)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66015 chrbr at gcc dot gnu.org changed: What|Removed |Added Target|aarch64, alpha |aarch64, alpha,ia64 --- Comment #6 from chrbr at gcc dot gnu.org --- yes, although the patch still not approved/applied for ia64. https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00312.html
[Bug tree-optimization/66186] [4.9/5/6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66186 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.3
[Bug rtl-optimization/66187] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66187 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-18 CC||jakub at gcc dot gnu.org Target Milestone|--- |6.0 Summary|wrong code at -O1, -O2 and |[6 Regression] wrong code |-O3 on x86_64-linux-gnu |at -O1, -O2 and -O3 on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r222877. I bet the problem is in: (tree_int_cst_min_precision (@4, UNSIGNED) = TYPE_PRECISION (TREE_TYPE (@0))) which for signed types IMHO should be instead.
[Bug sanitizer/66190] New: [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190
Bug ID: 66190
Summary: [5/6 Regression] ICE: tree code ‘call_expr’ is not
supported in LTO streams with -fsanitize=null
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
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
Target Milestone: ---
$ cat test.ii
class A {
public:
void m_fn1(int);
};
class GrAAHairLinePathRenderer {
~GrAAHairLinePathRenderer();
A onStencilPath_drawState;
virtual void m_fn2() {
static int a;
static int b(a);
onStencilPath_drawState.m_fn1(b);
}
};
GrAAHairLinePathRenderer::~GrAAHairLinePathRenderer() {}
$ g++ test.ii -flto -c -fsanitize=null
test.ii:14:56: internal compiler error: tree code ‘call_expr’ is not supported
in LTO streams
GrAAHairLinePathRenderer::~GrAAHairLinePathRenderer() {}
^
0x678d8e lto_write_tree
../../gcc/lto-streamer-out.c:415
0x678d8e lto_output_tree_1
../../gcc/lto-streamer-out.c:464
0x678d8e DFS::DFS(output_block*, tree_node*, bool, bool, bool)
../../gcc/lto-streamer-out.c:654
0xe378ce lto_output_tree(output_block*, tree_node*, bool, bool)
../../gcc/lto-streamer-out.c:1609
0xdbf5f5 write_global_stream
../../gcc/lto-streamer-out.c:2397
0xdbf5f5 lto_output_decl_state_streams(output_block*, lto_out_decl_state*)
../../gcc/lto-streamer-out.c:2444
0xdbf5f5 produce_asm_for_decls()
../../gcc/lto-streamer-out.c:2814
0xdb4004 write_lto() [clone .lto_priv.4579]
../../gcc/passes.c:2410
0xe22b49 ipa_write_summaries_1
../../gcc/passes.c:2471
0xe22b49 ipa_write_summaries()
../../gcc/passes.c:2531
0xd41543 ipa_passes
../../gcc/cgraphunit.c:2216
0xd41543 symbol_table::compile()
../../gcc/cgraphunit.c:2312
0xd50e1d symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2461
0xdd9dc0 cp_write_global_declarations()
../../gcc/cp/decl2.c:4755
Breakpoint 1, lto_write_tree (ob=0x1a41670, expr=0x76c41948, ref_p=false)
at ../../gcc/lto-streamer-out.c:415
415 get_tree_code_name (TREE_CODE (expr)));
(gdb) p debug_tree(expr)
call_expr 0x76c41948
type void_type 0x76c5d000 void VOID
align 8 symtab 0 alias set -1 canonical type 0x76c5d000
pointer_to_this pointer_type 0x76c5d150
side-effects tree_0 tree_3
arg 0 addr_expr 0x76dc4540
type pointer_type 0x76c5d7e0 type integer_type 0x76c3b690
int
public unsigned DI
size integer_cst 0x76c37e58 constant 64
unit size integer_cst 0x76c37e70 constant 8
align 64 symtab 0 alias set -1 canonical type 0x76c5d7e0
constant
arg 0 var_decl 0x76c44cf0 a type integer_type 0x76c3b690 int
addressable used public static weak decl_5 decl_6 SI file test.ii
line 9 col 16
size integer_cst 0x76c590a8 constant 32
unit size integer_cst 0x76c590c0 constant 4
align 32 context function_decl 0x76dd7870 m_fn2 chain
var_decl 0x76c44d80 b
arg 1 integer_cst 0x76dd6588 type pointer_type 0x76c5d7e0
constant 2
arg 2 integer_cst 0x76c59288 type integer_type 0x76c5d348
constant 0
$1 = void
Thanks,
Martin
[Bug rtl-optimization/66168] [6 Regression] ICE at -O3 in elimination_costs_in_insn, at reload1.c:3677
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66168 --- Comment #3 from Thomas Preud'homme thopre01 at gcc dot gnu.org --- I have a patch that pass bootstrap. Trying the testsuite now.
[Bug middle-end/66110] uint8_t memory access not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #9 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Kevin OConnor from comment #8)
Thanks! I can confirm the latest trunk performs the desired optimization.
However, this test case still isn't fully optimized:
void f2(struct s1 *ps1, uint8_t *pi8)
{
ps1-f1 = 3;
*pi8 = 8;
ps1-f1 += 2;
}
That is, an uint8_t* still aliases with every other type. The struct
optimization is more important for my usage, but it is unfortunate that
uint8_t*/int8_t* are pessimized. (In particular, there does not appear to
be any way to declare a pointer to an 8 bit integer that doesn't alias every
other type.)
I can open a separate bugzilla entry on the above.
Well, so it ultimiatively boils down to GCC defining
#define __UINT8_TYPE__ unsigned char
and that being a character type. I'm not sure whether the C or C++ standards
mandate that uint8_t be a 'character type' as far as type-based aliasing goes
but I would expect that user-code may rely on that property. So yes, there
would be no 1-byte type that doesn't get alias-set zero. Well - you could
use
struct byte { uint8_t b; };
and make sure to use aggregate assignments everywhere, only ever extracting
the actual value from temporary aggregates...
[Bug rtl-optimization/66187] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66187 Jakub Jelinek jakub at gcc dot gnu.org 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 jakub at gcc dot gnu.org --- Created attachment 35560 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35560action=edit gcc6-pr66187.patch Untested fix. Perhaps for the unsigned type and plus only, we could do even better, we don't really need to ensure the mask fits into precision, but perhaps just that the bit immediately above precision is clear (all bits above that are necessarily clear in the plus).
[Bug lto/59626] [4.8 Regression] /usr/include/bits/unistd.h:173:1: error: inlining failed in call to always_inline 'readlinkat': recursive inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59626 --- Comment #25 from Arseny Solokha asolokha at gmx dot com --- I observe it when building gcc-6.0.0_alpha20150517 snapshot using gcc 5.1.0 without LTO: /bin/bash ./libtool --tag=CXX --mode=compile powerpc-e500v2-linux-gnuspe-c++ -B/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/build/powerpc-e500v2-linux-gnuspe/libstdc++-v3/src/.libs -B/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/build/powerpc-e500v2-linux-gnuspe/libstdc++-v3/libsupc++/.libs -DHAVE_CONFIG_H -I. -I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm -I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/config/linux/powerpc -I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/config/linux -I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/config/powerpc -I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/config/posix -I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/config/generic -I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm -ftls-model=initial-exec -mhtm -Wall -Werror -Wc,-pthread -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -g -O2 -pipe -D_GNU_SOURCE -MT util.lo -MD -MP -MF .deps/util.Tpo -c -o util.lo /usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/util.cc libtool: compile: powerpc-e500v2-linux-gnuspe-c++ -B/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/build/powerpc-e500v2-linux-gnuspe/libstdc++-v3/src/.libs -B/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/build/powerpc-e500v2-linux-gnuspe/libstdc++-v3/libsupc++/.libs -DHAVE_CONFIG_H -I. -I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm -I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/config/linux/powerpc -I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/config/linux -I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/config/powerpc -I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/config/posix -I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/config/generic -I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm -ftls-model=initial-exec -mhtm -Wall -pthread -Werror -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -g -O2 -pipe -D_GNU_SOURCE -MT util.lo -MD -MP -MF .deps/util.Tpo -c /usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/util.cc -fPIC -DPIC -o .libs/util.o In file included from /usr/powerpc-e500v2-linux-gnuspe/usr/include/stdio.h:936:0, from /usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/util.cc:27: /usr/powerpc-e500v2-linux-gnuspe/usr/include/bits/stdio2.h: In function 'void GTM::gtm_verror(const char*, __va_list_tag*)': /usr/powerpc-e500v2-linux-gnuspe/usr/include/bits/stdio2.h:124:1: error: inlining failed in call to always_inline 'int vfprintf(FILE*, const char*, __va_list_tag*)': function body can be overwritten at link time vfprintf (FILE *__restrict __stream, ^ /usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/util.cc:35:31: error: called from here vfprintf (stderr, fmt, list); ^
[Bug ipa/66122] Bad uninlining decisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122 --- Comment #8 from Denis Vlasenko vda.linux at googlemail dot com --- If you try to reproduce this with kernel build, be sure to not select CONFIG_OPTIMIZE_INLINING (it forces inlining by making all iniline functions __always_inline). I didn't mention it before, but the recent (as of this writing) gcc 5.1.1 20150422 (Red Hat 5.1.1-1) with -Os easily triggers this behavior (more than a thousand *.o modules with spurious deinlines during kernel build).
[Bug ipa/66122] Bad uninlining decisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Denis Vlasenko from comment #8) If you try to reproduce this with kernel build, be sure to not select CONFIG_OPTIMIZE_INLINING (it forces inlining by making all iniline functions __always_inline). I didn't mention it before, but the recent (as of this writing) gcc 5.1.1 20150422 (Red Hat 5.1.1-1) with -Os easily triggers this behavior (more than a thousand *.o modules with spurious deinlines during kernel build). If you expect that all functions with inline keyword must be always inlined, then you really should use __always_inline__ attribute. Otherwise, inline keyword is primarily an optimization hint to the compiler that it might be desirable to inline it. So, talking about uninlining or deinlining makes absolutely no sense, the compiler either chooses to inline a function, or doesn't, based on some heuristics, command line options etc. For -Os, not inlining a function declared with inline keyword is often the right thing to do. And as Richard said, you can always look at the dump file to see why something hasn't been inlined.
[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66163 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.0.1
[Bug go/66147] [5/6 Regression] go fails to cross build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66147 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.2
[Bug middle-end/66148] [6 regression] build/genpreds: Internal error: abort in choose_enum_order, at genpreds.c:1006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66148 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0
