[Bug tree-optimization/69719] [5 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69719 --- Comment #6 from Richard Biener --- Author: rguenth Date: Wed Feb 10 08:36:03 2016 New Revision: 233262 URL: https://gcc.gnu.org/viewcvs?rev=233262&root=gcc&view=rev Log: 2016-02-10 Richard Biener PR tree-optimization/69719 * tree-vect-data-refs.c (vect_prune_runtime_alias_test_list): Adjust previous fix by ensuring that dr_a1 is left of dr_a2. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug fortran/69741] New: forall array scalar loop counters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69741 Bug ID: 69741 Summary: forall array scalar loop counters Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: nickpapior at gmail dot com Target Milestone: --- In forall statements it may be easier in some cases to use array elements as loop counters. I can only find in the specification that an integer scalar is required as a loop counter and hence I thought that i(1) may be a valid loop counter. 1. If this is allowed then there is a bug. 2. If this is not allowed then the error message is vague and unclear. Compiling the following program results in an error: ``` subroutine check integer :: ii(2) real :: a(3,2) forall (ii(1)=1:3 , ii(2)=1:2) a(ii(1),ii(2)) = ii(1) * ii(2) end forall end subroutine check ``` With the error being: ``` test.f90:5:21: forall (ii(1)=1:3 , ii(2)=1:2) 1 Error: An outer FORALL construct already has an index with this name (1) test.f90:6:5: a(ii(1),ii(2)) = ii(1) * ii(2) 1 Warning: The FORALL with index ‘ii’ is not used on the left side of the assignment at (1) and so might cause multiple assignment to this object test.f90:6:5: Warning: The FORALL with index ‘ii’ is not used on the left side of the assignment at (1) and so might cause multiple assignment to this object ``` This error message does not reflect the actual error if array elements are not allowed as loop counters. PS: Compiler info: gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/opt/generic/gcc/5.2.0/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix /opt/generic/gcc/5.2.0 --with-gmp=/opt/generic/gmp/6.0.0a --with-mpfr=/opt/generic/mpfr/3.1.3 --with-mpc=/opt/generic/mpc/1.0.3 --with-isl=/opt/generic/isl/0.15 --enable-lto --enable-threads --enable-stage1-languages=c,c++,fortran,go,objc,obj-c++ --with-multilib-list=m64 Thread model: posix gcc version 5.2.0 (GCC)
[Bug rtl-optimization/69737] [5 Regression] FAIL: gcc.c-torture/execute/pr64682.c -O2 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69737 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |5.4
[Bug c++/69736] [4.9/5/6 Regression] "error: too few arguments to function" in c++14 but not c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69736 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |4.9.4
[Bug tree-optimization/69735] [6 Regression] internal compiler error: in harmful_loop_in_region, at graphite-scop-detection.c:1045
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69735 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug bootstrap/69725] LTO/PGO bootstrap fails with in-tree gmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69725 --- Comment #11 from Richard Biener --- At least it's very slow doing the configure checks and I see it LTOs gmp all the time (configuring mpfr). Just trying regular LTO bootstrap right now btw, w/o profile-feedback.
[Bug fortran/69742] New: ICE with -O3 and ASSOCIATE containing repeated expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69742 Bug ID: 69742 Summary: ICE with -O3 and ASSOCIATE containing repeated expression Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mrestelli at gmail dot com Target Milestone: --- This code produces and internal compiler error when compiled with -O3. It seems that the problem is the appearance of the same expression twice inside the associate construct. The code compiles and runs without optimization. program p implicit none integer, allocatable :: i(:), j allocate( i(5) ) i = (/( j , j=1,5 )/) ! The ICE appears when "size(i)" is used twice in associate associate( i5 => i(size(i):size(i)) ) ! this gives ICE !associate( i5 => i(size(2*i):size(i)) ) ! this works i5 = 2 end associate write(*,*) i end program p $ gfortran -O3 test.f90 -o test test.f90:11:0: i5 = 2 internal compiler error: in gimplify_var_or_parm_decl, bei gimplify.c:1840 0x86e434 gimplify_var_or_parm_decl gcc/gimplify.c:1840 0x872051 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) gcc/gimplify.c:10595 0x8719cc gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) gcc/gimplify.c:10455 0x87b680 gimplify_modify_expr gcc/gimplify.c:4709 0x872210 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) gcc/gimplify.c:10162 0x874c46 gimplify_stmt(tree_node**, gimple**) gcc/gimplify.c:5642 0x87339b gimplify_statement_list gcc/gimplify.c:1526 0x87339b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) gcc/gimplify.c:10579 0x874c46 gimplify_stmt(tree_node**, gimple**) gcc/gimplify.c:5642 0x8756bd gimplify_bind_expr gcc/gimplify.c:1142 0x871d42 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) gcc/gimplify.c:10361 0x874c46 gimplify_stmt(tree_node**, gimple**) gcc/gimplify.c:5642 0x87339b gimplify_statement_list gcc/gimplify.c:1526 0x87339b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) gcc/gimplify.c:10579 0x874c46 gimplify_stmt(tree_node**, gimple**) gcc/gimplify.c:5642 0x872952 gimplify_and_add(tree_node*, gimple**) gcc/gimplify.c:425 0x872952 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) gcc/gimplify.c:10501 0x874c46 gimplify_stmt(tree_node**, gimple**) gcc/gimplify.c:5642 0x8756bd gimplify_bind_expr gcc/gimplify.c:1142 0x871d42 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) gcc/gimplify.c:10361 $ gfortran --version GNU Fortran (GCC) 6.0.0 20160209 (experimental)
[Bug tree-optimization/69291] [6 Regression] wrong code at -O1 for ruby-2.3.0/regcomp.c:985:compile_length_quantifier_node()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69291
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Status|RESOLVED|REOPENED
Last reconfirmed||2016-02-10
Component|c |tree-optimization
CC||rguenth at gcc dot gnu.org
Resolution|FIXED |---
Ever confirmed|0 |1
Target Milestone|--- |6.0
--- Comment #4 from Richard Biener ---
Issue still happens on i586 and fails the ruby build with
[ 149s] gcc -fomit-frame-pointer -fmessage-length=0 -grecord-gcc-switches -O2
-Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables -Wno-error=misleading-indentation
-Wno-error=narrowing -Wno-error=nonnull -Wno-error=unused-const-variable -g
-fno-strict-aliasing -O -U_FORTIFY_SOURCE -fPIC -L. -fstack-protector
-rdynamic -Wl,-export-dynamic -fstack-protector main.o dmydln.o miniinit.o
miniprelude.o array.o bignum.o class.o compar.o complex.o dir.o dln_find.o
encoding.o enum.o enumerator.o error.o eval.o load.o proc.o file.o gc.o hash.o
inits.o io.o marshal.o math.o node.o numeric.o object.o pack.o parse.o
process.o random.o range.o rational.o re.o regcomp.o regenc.o regerror.o
regexec.o regparse.o regsyntax.o ruby.o safe.o signal.o sprintf.o st.o
strftime.o string.o struct.o time.o transcode.o util.o variable.o version.o
compile.o debug.o iseq.o vm.o vm_dump.o vm_backtrace.o vm_trace.o thread.o
cont.o ascii.o us_ascii.o unicode.o utf_8.o newline.o strlcpy.o strlcat.o
setproctitle.o addr2line.o dmyext.o -lpthread -ldl -lcrypt -lm -o miniruby
[ 149s] ./miniruby -I./lib -I. -I.ext/common ./tool/mkconfig.rb
-timestamp=.rbconfig.time \
[ 149s]-install_name=ruby.ruby2.1 \
[ 149s]-so_name=ruby2.1 rbconfig.rb
[ 149s] ./tool/mkconfig.rb:121:in `gsub': undefined bytecode (bug):
/\$(?:\$|\{?(\w+)\}?)/ (RegexpError)
the regcomp.c workaround, -O0 for compile_length_quantifier_node still works,
in fact "no-tree-dominator-opts" is enough to fix it.
Poking some more.
[Bug fortran/69742] ICE with -O3 and ASSOCIATE containing repeated expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69742 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #1 from Thomas Koenig --- What happens if you run it with gfortran -ffrontend-optimize and with gfortran -O3 -fno-frontend-optimize ?
[Bug fortran/69742] ICE with -O3 and ASSOCIATE containing repeated expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69742 --- Comment #2 from mrestelli --- (In reply to Thomas Koenig from comment #1) > What happens if you run it with > > gfortran -ffrontend-optimize Same ICE > and with > > gfortran -O3 -fno-frontend-optimize ? Works correctly
[Bug bootstrap/59878] [4.9 Regression] ISL from cloog does not work with trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59878 vries at gcc dot gnu.org changed: What|Removed |Added CC||vries at gcc dot gnu.org --- Comment #9 from vries at gcc dot gnu.org --- (In reply to Richard Biener from comment #6) > "Fixed". (or invalid, just depends how you interpret it ;)) > > -> make the cloog folks have the bundled ISL produce a sensible isl_version > () > output would be a better "fix", of course ;) > > Tobias? (not sure, maybe cloog 0.18.1 is fixed in this regard, 0.18.0 > definitely wasn't) $ for d in cloog-*; do echo -n "$d: "; if [ -f $d/isl/GIT_HEAD_ID ]; then cat $d/isl/GIT_HEAD_ID; else echo missing; fi; done cloog-0.16.0: isl-0.05 cloog-0.16.1: isl-0.05.1 cloog-0.16.2: isl-0.06 cloog-0.16.3: isl-0.07 cloog-0.17.0: isl-0.08-60-g60518c5 cloog-0.18.0: missing cloog-0.18.1: missing cloog-0.18.2: UNKNOWN cloog-0.18.3: isl-0.14 cloog-0.18.4: isl-0.15
[Bug c++/69743] New: function overload - template instantiation depth exceeds maximum (gcc4, clang - no problem)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69743
Bug ID: 69743
Summary: function overload - template instantiation depth
exceeds maximum (gcc4, clang - no problem)
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Konstantin.Sadov at gmail dot com
Target Milestone: ---
The following code
[code]
template
void f(int, T... d)
{
}
template
void f(T... d)
{
f(1, d...);
}
void g(void)
{
f(1.0);
}
[code]
produces error
[error]
In instantiation of ‘void f(T ...) [with D = long int; T = {int, lots of int,
int, double}]’:
recursively required from ‘void f(T ...) [with D = long int; T = {int,
double}]’
required from ‘void f(T ...) [with D = long int; T = {double}]’
required from here
fatal error: template instantiation depth exceeds maximum of 900 (use
-ftemplate-depth= to increase the maximum)
[error]
gcc 4.4, gcc 4.7, clang 3.7 compiles the code without problems.
[Bug tree-optimization/69291] [6 Regression] wrong code at -O1 for ruby-2.3.0/regcomp.c:985:compile_length_quantifier_node()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69291 --- Comment #5 from Richard Biener --- Ok, not inlining compile_length_quantifier_node fixes it as well. It's inlined in compile_length_tree. -fdisable-tree-uncprop1 fixes it - that hints more at a target specific RTL issue or an RTL expansion issue. -fno-tree-coalesce-vars also fixes it (disabling TER doesn't).
[Bug libstdc++/69116] [4.9/5 Regression] compile error when including valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69116 --- Comment #9 from Jonathan Wakely --- Author: redi Date: Wed Feb 10 11:10:58 2016 New Revision: 233263 URL: https://gcc.gnu.org/viewcvs?rev=233263&root=gcc&view=rev Log: Constrain std::valarray functions and operators PR libstdc++/69116 * include/bits/valarray_before.h (__fun, __fun_with_valarray): Only define result_type for types which can be safely used with valarrays. * testsuite/26_numerics/valarray/69116.cc: New. Added: branches/gcc-5-branch/libstdc++-v3/testsuite/26_numerics/valarray/69116.cc Modified: branches/gcc-5-branch/libstdc++-v3/ChangeLog branches/gcc-5-branch/libstdc++-v3/include/bits/valarray_before.h
[Bug fortran/69742] ICE with -O3 and ASSOCIATE containing repeated expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69742 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-10 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (6.0) as a frontend optimization.
[Bug tree-optimization/69735] [6 Regression] internal compiler error: in harmful_loop_in_region, at graphite-scop-detection.c:1045
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69735 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug c++/69743] [5/6 Regression] function overload with variadic arguments - template instantiation depth exceeds maximum (gcc4, clang - no problem)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69743 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |5.4 Summary|function overload with |[5/6 Regression] function |variadic arguments -|overload with variadic |template instantiation |arguments - template |depth exceeds maximum |instantiation depth exceeds |(gcc4, clang - no problem) |maximum (gcc4, clang - no ||problem) --- Comment #1 from Jakub Jelinek --- Started to be rejected with r215171.
[Bug libstdc++/69116] [4.9/5 Regression] compile error when including valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69116 --- Comment #10 from Jonathan Wakely --- Author: redi Date: Wed Feb 10 11:25:33 2016 New Revision: 233265 URL: https://gcc.gnu.org/viewcvs?rev=233265&root=gcc&view=rev Log: Constrain std::valarray functions and operators PR libstdc++/69116 * include/bits/valarray_before.h (__fun, __fun_with_valarray): Only define result_type for types which can be safely used with valarrays. * testsuite/26_numerics/valarray/69116.cc: New. Added: branches/gcc-4_9-branch/libstdc++-v3/testsuite/26_numerics/valarray/69116.cc Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/bits/valarray_before.h
[Bug libstdc++/69116] [4.9/5 Regression] compile error when including valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69116 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Known to fail|5.2.1 |4.9.3, 5.3.0 --- Comment #11 from Jonathan Wakely --- Fixed for 4.9.4, 5.4 and 6.1
[Bug fortran/67451] [5/6 Regression] [F08] ICE with sourced allocation from coarray.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67451 --- Comment #11 from vehre at gcc dot gnu.org --- Patch at: https://gcc.gnu.org/ml/fortran/2016-02/msg00033.html Waiting for review and approval of bugreporters whether the patch fixes the issue or not.
[Bug bootstrap/59878] [4.9 Regression] ISL from cloog does not work with trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59878 --- Comment #10 from vries at gcc dot gnu.org --- (In reply to vries from comment #9) By comparing cloog sources with isl tags I got: > cloog-0.16.0: isl-0.05 > cloog-0.16.1: isl-0.05.1 > cloog-0.16.2: isl-0.06 > cloog-0.16.3: isl-0.07 > cloog-0.17.0: isl-0.08-60-g60518c5 > cloog-0.18.0: missing isl-0.11.1 > cloog-0.18.1: missing isl-0.12.1 > cloog-0.18.2: UNKNOWN isl-0.12.1 > cloog-0.18.3: isl-0.14 > cloog-0.18.4: isl-0.15
[Bug rtl-optimization/69710] performance issue with SP Linpack with Autovectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69710
--- Comment #8 from amker at gcc dot gnu.org ---
Reproduced on arm with saxpy.c. The dump for slp is as below:
:
_82 = prologue_after_cost_adjust.7_43 * 4;
vectp_dy.13_81 = dy_9(D) + _82;
_87 = prologue_after_cost_adjust.7_43 * 4;
vectp_dx.16_86 = dx_13(D) + _87;
vect_cst__91 = {da_6(D), da_6(D), da_6(D), da_6(D)};
_95 = prologue_after_cost_adjust.7_43 * 4;
vectp_dy.21_94 = dy_9(D) + _95;
:
# vectp_dy.12_83 = PHI
# vectp_dx.15_88 = PHI
# vectp_dy.20_96 = PHI
# ivtmp_99 = PHI <0(13), ivtmp_100(21)>
vect__12.14_85 = MEM[(float *)vectp_dy.12_83];
vect__15.17_90 = MEM[(float *)vectp_dx.15_88];
vect__16.18_92 = vect_cst__91 * vect__15.17_90;
vect__17.19_93 = vect__12.14_85 + vect__16.18_92;
MEM[(float *)vectp_dy.20_96] = vect__17.19_93;
vectp_dy.12_84 = vectp_dy.12_83 + 16;
vectp_dx.15_89 = vectp_dx.15_88 + 16;
vectp_dy.20_97 = vectp_dy.20_96 + 16;
ivtmp_100 = ivtmp_99 + 1;
if (ivtmp_100 < bnd.9_53)
goto ;
else
goto ;
:
goto ;
IVO recognized below uses:
use 0
address
in statement vect__12.14_85 = MEM[(float *)vectp_dy.12_83];
at position MEM[(float *)vectp_dy.12_83]
type vector(4) float *
base vectp_dy.13_81
step 16
base object (void *) vectp_dy.13_81
related candidates
use 1
generic
in statement vectp_dx.15_88 = PHI
at position
type vector(4) float *
base vectp_dx.16_86
step 16
base object (void *) vectp_dx.16_86
is a biv
related candidates
use 2
address
in statement MEM[(float *)vectp_dy.20_96] = vect__17.19_93;
at position MEM[(float *)vectp_dy.20_96]
type vector(4) float *
base vectp_dy.21_94
step 16
base object (void *) vectp_dy.21_94
related candidates
use 3
compare
in statement if (ivtmp_100 < bnd.9_53)
at position
type unsigned int
base 1
step 1
is a biv
related candidates
There are two problems:
1) we failed recognize that use 0 and 2 are identical to each other. This is
because vectorizer generates redundant setup code in loop pre-header. There
are two possible fixes here. One is to make expand_simple_operations more
aggressive in expanding (used by ivopts) in tree-ssa-loop-niter.c. But I don't
think this is a good idea in all cases, because expanded complicated expression
makes ivo transform and niter analysis harder. The other is to fix vectorizer
to generate clean code. Richard's suggestion is to use gimple_build for that.
2) use 1 is not recognized as an address iv because alignment of that memory
reference.
[Bug c++/69098] [6 regression] Member function pointer template flagged with 'is not a function template'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69098 --- Comment #7 from Jakub Jelinek --- (In reply to Patrick Palka from comment #6) > This fixes it: Are you going to post it to gcc-patches (with ChangeLog and testcase)?
[Bug rtl-optimization/69710] performance issue with SP Linpack with Autovectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69710 --- Comment #9 from amker at gcc dot gnu.org --- Also the problem exists only for arm because it doesn't support [base+index] addressing mode for vect load/store. I guess mips doesn't either.
[Bug c++/69098] [5/6 regression] Member function pointer template flagged with 'is not a function template'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69098 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P2 Target Milestone|6.0 |5.4 Summary|[6 regression] Member |[5/6 regression] Member |function pointer template |function pointer template |flagged with 'is not a |flagged with 'is not a |function template' |function template' --- Comment #8 from Jakub Jelinek --- The #c5 mentioned revisions look really weird, my bisection shows this regressed on the trunk with r226642, which has been indeed backported to 5 branch too. Downgrading to P2, as we've already released one compiler (5.3) with this bug.
[Bug target/68973] [6 regression] Internal compiler error on power for gcc/testsuite/g++.dg/pr67211.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68973
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #14 from Alan Modra ---
This looks like a reload problem. The pr67211.C testcase on powerpc64le gives
reload this insn
(insn 155 153 156 8 (set (reg/f:DI 178 [ p3$_M_first ])
(mem/f:DI (pre_inc:DI (reg/f:DI 185 [ p3$_M_node ])) [3 MEM[base: _9,
offset: 0B]+0 S8 A64])) /src/gcc.git/gcc/testsuite/g++.dg/pr67211.C:28 550
{*movdi_internal64}
(expr_list:REG_INC (reg/f:DI 185 [ p3$_M_node ])
(nil)))
and reload chooses to put reg 185 in fr31, likely due to using that reg in
vector insns elsewhere. Of course, (pre_inc:DI (reg/f:DI 63)) isn't a valid
memory address so it needs reloading. reload does that by reloading the entire
address into a gpr rather than just reloading fr31. Unfortunately neither the
rs6000 backend machinery nor the code in push_reload that normally handles
secondary memory sees that a secondary reload is needed.
There is some pre_inc code in find_reloads_address_1 that could reload just
fr31 but that is currently only active for regs that already have a mem.
Making that code active for invalid hard regs cures this failure.
Another fix is to disable the auto_inc_dec pass (maybe we should do that anyway
for powerpc processors where the update forms of memory insns are slow).
[Bug tree-optimization/69291] [6 Regression] wrong code at -O1 for ruby-2.3.0/regcomp.c:985:compile_length_quantifier_node()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69291 --- Comment #6 from Richard Biener --- Created attachment 37651 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37651&action=edit preprocessed source Build with -m32 -mtune=generic -march=i586 -O [-fPIC] -fdisable-rtl-ce2 (if-conversion after combine) fixes it. IF-THEN-ELSE-JOIN block found, pass 1, test 63, then 64, else 65, join 128 scanning new insn with uid = 842. scanning new insn with uid = 843. scanning new insn with uid = 844. scanning new insn with uid = 845. scanning new insn with uid = 846. scanning new insn with uid = 847. deleting insn with uid = 363. deleting block 65 Removing jump 354. deleting insn with uid = 354. deleting insn with uid = 357. deleting block 64 Conversion succeeded on pass 1. IF-CASE-2 found, start 88, else 90 verify found no changes in insn with uid = 471. deleting block 90 Conversion succeeded on pass 1. Disabling the IF-THEN-ELSE-JOIN transform above fixes the issue.
[Bug rtl-optimization/69291] [6 Regression] wrong code at -O1 for ruby-2.3.0/regcomp.c:985:compile_length_quantifier_node()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69291
--- Comment #7 from Richard Biener ---
It combines
(insn 353 352 354 63 (set (reg:CCZ 17 flags)
(compare:CCZ (mem/f:SI (plus:SI (reg/v/f:SI 225 [ node ])
(const_int 32 [0x20])) [10 MEM[(struct QtfrNode
*)node_14(D)].next_head_exact+0 S4 A32])
(const_int 0 [0]))) regcomp.c:1011 3 {*cmpsi_ccno_1}
(expr_list:REG_DEAD (reg/v/f:SI 225 [ node ])
(nil)))
(jump_insn 354 353 355 63 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 360)
(pc))) regcomp.c:1011 635 {*jcc_1}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 1500 (nil)))
else:
(insn 357 356 360 64 (set (reg/v:SI 224 [ ])
(plus:SI (plus:SI (reg/v:SI 160 [ mod_tlen ])
(reg/v:SI 224 [ ]))
(const_int 11 [0xb]))) regcomp.c:1012 214 {*leasi}
(expr_list:REG_DEAD (reg/v:SI 160 [ mod_tlen ])
(nil)))
then:
(insn 363 362 366 65 (set (reg/v:SI 224 [ ])
(plus:SI (plus:SI (reg/v:SI 160 [ mod_tlen ])
(reg/v:SI 224 [ ]))
(const_int 10 [0xa]))) regcomp.c:1014 214 {*leasi}
(expr_list:REG_DEAD (reg/v:SI 160 [ mod_tlen ])
(nil)))
into (wtf!):
(insn 353 352 842 63 (set (reg:CCZ 17 flags)
(compare:CCZ (mem/f:SI (plus:SI (reg/v/f:SI 225 [ node ])
(const_int 32 [0x20])) [10 MEM[(struct QtfrNode
*)node_14(D)].next_head_exact+0 S4 A32])
(const_int 0 [0]))) regcomp.c:1011 3 {*cmpsi_ccno_1}
(expr_list:REG_DEAD (reg/v/f:SI 225 [ node ])
(nil)))
(insn 842 353 843 63 (set (reg:CCZ 17 flags)
(compare:CCZ (mem/f:SI (plus:SI (reg/v/f:SI 225 [ node ])
(const_int 32 [0x20])) [10 MEM[(struct QtfrNode
*)node_14(D)].next_head_exact+0 S4 A32])
(const_int 0 [0]))) regcomp.c:1012 3 {*cmpsi_ccno_1}
(nil))
(insn 843 842 844 63 (set (reg:QI 331)
(ne:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) regcomp.c:1012 631 {*setcc_qi}
(nil))
(insn 844 843 845 63 (set (reg/v:SI 224 [ ])
(zero_extend:SI (reg:QI 331))) regcomp.c:1012 136 {*zero_extendqisi2}
(nil))
(insn 845 844 846 63 (parallel [
(set (reg:SI 332)
(plus:SI (reg/v:SI 160 [ mod_tlen ])
(reg/v:SI 224 [ ])))
(clobber (reg:CC 17 flags))
]) regcomp.c:1012 218 {*addsi_1}
(nil))
(insn 846 845 847 63 (parallel [
(set (reg/v:SI 224 [ ])
(plus:SI (reg/v:SI 224 [ ])
(reg:SI 332)))
(clobber (reg:CC 17 flags))
]) regcomp.c:1012 218 {*addsi_1}
(nil))
(insn 847 846 366 63 (parallel [
(set (reg/v:SI 224 [ ])
(plus:SI (reg/v:SI 224 [ ])
(const_int 10 [0xa])))
(clobber (reg:CC 17 flags))
]) regcomp.c:1012 218 {*addsi_1}
(nil))
where it overwrites 224 with setcc even thouht 224 is needed to compute the
original expression.
[Bug fortran/67451] [5/6 Regression] [F08] ICE with sourced allocation from coarray.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67451 --- Comment #12 from Dominik Vogt --- The patch works on s390x.
[Bug fortran/69742] [4.9/5/6 Regression] ICE with -O3 and ASSOCIATE containing repeated expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69742 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Target Milestone|--- |4.9.4 Summary|ICE with -O3 and ASSOCIATE |[4.9/5/6 Regression] ICE |containing repeated |with -O3 and ASSOCIATE |expression |containing repeated ||expression --- Comment #4 from Thomas Koenig --- I'll take this.
[Bug rtl-optimization/69291] [6 Regression] wrong code at -O1 for ruby-2.3.0/regcomp.c:985:compile_length_quantifier_node()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69291
--- Comment #8 from Richard Biener ---
#0 noce_emit_store_flag (if_info=0x7fffd7d0, x=0x75ade840,
reversep=1, normalize=0) at /space/rguenther/src/svn/trunk3/gcc/ifcvt.c:839
#1 0x017adfa3 in noce_try_store_flag_constants (
if_info=0x7fffd7d0) at /space/rguenther/src/svn/trunk3/gcc/ifcvt.c:1390
#2 0x017b3230 in noce_process_if_block (if_info=0x7fffd7d0)
at /space/rguenther/src/svn/trunk3/gcc/ifcvt.c:3503
and we try to detect this with
/* If we have x := test ? x + 3 : x + 4 then move the original
x out of the way while we store flags. */
if (common && rtx_equal_p (common, if_info->x))
{
common = gen_reg_rtx (mode);
noce_emit_move_insn (common, if_info->x);
}
but here
(gdb) p debug_rtx (if_info->x)
(reg/v:SI 224 [ ])
(gdb) p debug_rtx (common)
(plus:SI (reg/v:SI 160 [ mod_tlen ])
(reg/v:SI 224 [ ]))
I suppose it should use reg_mentioned_p instead. But even then the generated
code is broken. Seems it doesn't expect a plus as common at all. It then
copies the reg and does
(insn 842 353 843 63 (set (reg:SI 331)
(reg/v:SI 224 [ ])) regcomp.c:1012 86 {*movsi_internal}
(nil))
(insn 843 842 844 63 (set (reg:CCZ 17 flags)
(compare:CCZ (mem/f:SI (plus:SI (reg/v/f:SI 225 [ node ])
(const_int 32 [0x20])) [10 MEM[(struct QtfrNode
*)node_14(D)].next_head_exact+0 S4 A32])
(const_int 0 [0]))) regcomp.c:1012 3 {*cmpsi_ccno_1}
(nil))
(insn 844 843 845 63 (set (reg:QI 332)
(ne:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) regcomp.c:1012 631 {*setcc_qi}
(nil))
(insn 845 844 846 63 (set (reg/v:SI 224 [ ])
(zero_extend:SI (reg:QI 332))) regcomp.c:1012 136 {*zero_extendqisi2}
(nil))
(insn 846 845 847 63 (parallel [
(set (reg/v:SI 224 [ ])
(plus:SI (reg/v:SI 224 [ ])
(reg:SI 331)))
(clobber (reg:CC 17 flags))
]) regcomp.c:1012 218 {*addsi_1}
(nil))
(insn 847 846 366 63 (parallel [
(set (reg/v:SI 224 [ ])
(plus:SI (reg/v:SI 224 [ ])
(const_int 10 [0xa])))
(clobber (reg:CC 17 flags))
]) regcomp.c:1012 218 {*addsi_1}
(nil))
and so loses the reg:SI 160 addend.
[Bug rtl-optimization/69291] [6 Regression] wrong code at -O1 for ruby-2.3.0/regcomp.c:985:compile_length_quantifier_node()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69291
--- Comment #9 from Richard Biener ---
Ah, of course
/* If we have x := test ? x + 3 : x + 4 then move the original
x out of the way while we store flags. */
if (common && reg_mentioned_p (if_info->x, common))
{
common = gen_reg_rtx (mode);
noce_emit_move_insn (common, if_info->x);
}
can't work - we'll overwrite 'common' here.
/* If we have x := test ? x + 3 : x + 4 then move the original
x out of the way while we store flags. */
if (common && reg_mentioned_p (if_info->x, common))
{
rtx tem = gen_reg_rtx (mode);
noce_emit_move_insn (tem, common);
common = tem;
}
does. Of course that insn might not be recognizable. The above fixes the ruby
failure for me.
[Bug rtl-optimization/69291] [6 Regression] wrong code at -O1 for ruby-2.3.0/regcomp.c:985:compile_length_quantifier_node()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69291
--- Comment #10 from Richard Biener ---
Testing
Index: gcc/ifcvt.c
===
--- gcc/ifcvt.c (revision 233262)
+++ gcc/ifcvt.c (working copy)
@@ -1381,10 +1381,11 @@ noce_try_store_flag_constants (struct no
/* If we have x := test ? x + 3 : x + 4 then move the original
x out of the way while we store flags. */
- if (common && rtx_equal_p (common, if_info->x))
+ if (common && reg_mentioned_p (if_info->x, common))
{
- common = gen_reg_rtx (mode);
- noce_emit_move_insn (common, if_info->x);
+ rtx tem = gen_reg_rtx (mode);
+ noce_emit_move_insn (tem, common);
+ common = tem;
}
target = noce_emit_store_flag (if_info, if_info->x, reversep,
normalize);
[Bug rtl-optimization/69291] [6 Regression] wrong code at -O1 for ruby-2.3.0/regcomp.c:985:compile_length_quantifier_node()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69291 Richard Biener changed: What|Removed |Added Status|REOPENED|ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
[Bug rtl-optimization/69291] [6 Regression] wrong code at -O1 for ruby-2.3.0/regcomp.c:985:compile_length_quantifier_node()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69291 --- Comment #11 from Richard Biener --- Caused by r226869.
[Bug ipa/68672] [4.9/5/6 Regression] g++.dg/torture/pr68470.C: ICE: cannot update SSA form: statement uses released SSA name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68672 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- I believe this started with r197375. And why is this happening is fairly obvious, we want to ignore clobbers in the decisions made by fnsplit, and thus we recognize bb8 as the return_bb. When clobbers could have just decls on the LHS, this could not be a problem. It is ok to ignore the clobbers in the decision making, but we really need to adjust them/remove them/move them somewhere else.
[Bug tree-optimization/69726] [6 Regression] Bogus warnings with -O3 -Wuninitialized because dead code after if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69726 --- Comment #5 from Richard Biener --- Author: rguenth Date: Wed Feb 10 12:46:33 2016 New Revision: 233267 URL: https://gcc.gnu.org/viewcvs?rev=233267&root=gcc&view=rev Log: 2016-02-10 Richard Biener PR tree-optimization/69726 * passes.def: Add DCE pass before late uninit. * match.pd: Add A ? B : (!A ? C : X) -> A ? B : C patterns to really fixup if-conversions job. * gcc.dg/uninit-22.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/uninit-22.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/passes.def trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/69726] [6 Regression] Bogus warnings with -O3 -Wuninitialized because dead code after if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69726 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug target/68973] [6 regression] Internal compiler error on power for gcc/testsuite/g++.dg/pr67211.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68973 --- Comment #15 from David Edelsohn --- Improving find_reloads_address_1 seems the better path. auto_inc_dec is beneficial in recent Power processors.
[Bug rtl-optimization/69609] block reordering consumes an inordinate amount of time, REE consumes much memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69609 --- Comment #5 from Richard Biener --- So checking enabled trunk with -O2 -fno-checking results in PRE : 25.58 ( 7%) usr 0.53 (33%) sys 26.14 ( 7%) wall 793 kB ( 0%) ggc reorder blocks : 286.65 (80%) usr 0.08 ( 5%) sys 287.01 (79%) wall 432597 kB (58%) ggc TOTAL : 359.83 1.60 361.82 745954 kB callgrind points at bb_to_key (called 4.7 million times), accounting for 55% of all samples. Ah, bb_to_key does FOR_EACH_EDGE on PREDs which might explain this ... I suppose either caching the result of this loop or limiting it would fix the slowness. The first one looks very desirable. In fact pre-computing bb_to_key once looks very desirable, it looks the result won't change over the pass execution? Well, maybe .end_of_trace will. But then adjusting the pre-computed value of all succs when adjusting .end_of_trace might be possible.
[Bug rtl-optimization/69609] block reordering consumes an inordinate amount of time, REE consumes much memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69609
--- Comment #6 from Richard Biener ---
Maybe sth as simple as
Index: gcc/bb-reorder.c
===
--- gcc/bb-reorder.c(revision 233262)
+++ gcc/bb-reorder.c(working copy)
@@ -889,6 +889,7 @@ bb_to_key (basic_block bb)
/* Prefer blocks whose predecessor is an end of some trace
or whose predecessor edge is EDGE_DFS_BACK. */
+ if (EDGE_COUNT (bb->preds) <= 8)
FOR_EACH_EDGE (e, ei, bb->preds)
{
if ((e->src != ENTRY_BLOCK_PTR_FOR_FN (cfun)
or precomputing whether a BB has abnormal preds and disabling the trace in
that case (or somehow sorting the edge vectors so that abnormal edges
come last so we can stop at the first abnormal edge).
[Bug fortran/69742] [4.9/5/6 Regression] ICE with -O3 and ASSOCIATE containing repeated expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69742 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug tree-optimization/69702] [4.9/5/6 Regression] excessive stack usage with -fprofile-arcs, LIM store motion lacks a register pressure aware cost model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69702 --- Comment #2 from Arnd Bergmann --- Thanks, I have now added -fno-tree-loop-im to the kernel gcov cflags, so files we profile will be built with that. I can confirm that it fixes all stack size warnings that show up with -fprofile-arcs, I found around a dozen of them in various parts of the kernel. Are there any downsides to doing this for all compiler versions? I don't think we care much about a missed optimization when CGOV is used, and nobody ships that on production systems. I guess for older gcc releases it's not necessary to disable tree-loop-im, but it's not easy to make this conditional on the gcc version without major surgery in the kernel build system. I'm also adding -Wno-maybe-uninitialized now, because -fprofile-arcs also introduces countless "error: '...' may be used uninitialized in this function [-Werror=maybe-uninitialized]" warnings that I don't see without -fprofile-arcs, and those are all false positives. Let me know if I should open another bug report for those (I assume there isn't really much to do, based on my reading of https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings). I also found two other files in the kernel that doen't build correctly once -fprofile-arcs is enabled (with or without tree-loop-im), I'll report those as separate bugs.
[Bug tree-optimization/69702] [4.9/5/6 Regression] excessive stack usage with -fprofile-arcs, LIM store motion lacks a register pressure aware cost model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69702 --- Comment #3 from rguenther at suse dot de --- On Wed, 10 Feb 2016, arnd at linaro dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69702 > > --- Comment #2 from Arnd Bergmann --- > Thanks, I have now added -fno-tree-loop-im to the kernel gcov cflags, so files > we profile will be built with that. I can confirm that it fixes all stack size > warnings that show up with -fprofile-arcs, I found around a dozen of them in > various parts of the kernel. > > Are there any downsides to doing this for all compiler versions? I don't think > we care much about a missed optimization when CGOV is used, and nobody ships > that on production systems. I guess for older gcc releases it's not necessary > to disable tree-loop-im, but it's not easy to make this conditional on the gcc > version without major surgery in the kernel build system. Downsides are only missed optimizations. Esp. for profiling it was requested that the couter updates were combined which only will happen (possibly) when we apply store motion. > I'm also adding -Wno-maybe-uninitialized now, because -fprofile-arcs also > introduces countless "error: '...' may be used uninitialized in this function > [-Werror=maybe-uninitialized]" warnings that I don't see without > -fprofile-arcs, and those are all false positives. Let me know if I should > open > another bug report for those (I assume there isn't really much to do, based on > my reading of https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings). I don't remember seeing such bug so yes please. > I also found two other files in the kernel that doen't build correctly once > -fprofile-arcs is enabled (with or without tree-loop-im), I'll report those as > separate bugs. Thanks.
[Bug c++/62134] [C++11] ICE with template alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62134 --- Comment #7 from Jonathan Wakely --- FWIW probably a dup of PR 61198 and so fixed by r218955
[Bug tree-optimization/68021] [6 Regression] ice in rewrite_use_nonlinear_expr with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68021 --- Comment #16 from amker at gcc dot gnu.org --- Author: amker Date: Wed Feb 10 14:09:05 2016 New Revision: 233269 URL: https://gcc.gnu.org/viewcvs?rev=233269&root=gcc&view=rev Log: PR tree-optimization/68021 * tree-ssa-loop-ivopts.c (get_computation_aff): Set ratio to 1 if when computing the value of biv cand by itself. gcc/testsuite/ChangeLog PR tree-optimization/68021 * gcc.dg/tree-ssa/pr68021.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr68021.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c
[Bug tree-optimization/68021] [6 Regression] ice in rewrite_use_nonlinear_expr with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68021 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Jakub Jelinek --- Fixed.
[Bug libstdc++/69744] New: OpenBSD does not define max_align_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69744 Bug ID: 69744 Summary: OpenBSD does not define max_align_t Product: gcc Version: 4.9.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: edd at theunixzoo dot co.uk Target Milestone: --- Hi, I needed to build a "vanilla" (without all the packaging-related patches in OpenBSD ports) gcc-4.9.3 on OpenBSD-5.8/amd64. When building libstdc++ the build bombs out like this: libtool: compile: /home/vext01/research/warmup_experiment/work/gcc/sd_build/./gcc/xgcc -shared-libgcc -B/home/vext01/research/warmup_experiment/work/gcc/sd_build/./gcc -nostdinc++ -L/home/vext01/research/warmup_experiment/work/gcc/sd_build/x86_64-unknown-openbsd5.8/libstdc++-v3/src -L/home/vext01/research/warmup_experiment/work/gcc/sd_build/x86_64-unknown-openbsd5.8/libstdc++-v3/src/.libs -L/home/vext01/research/warmup_experiment/work/gcc/sd_build/x86_64-unknown-openbsd5.8/libstdc++-v3/libsupc++/.libs -B/home/vext01/research/warmup_experiment/work/gcc-inst/x86_64-unknown-openbsd5.8/bin/ -B/home/vext01/research/warmup_experiment/work/gcc-inst/x86_64-unknown-openbsd5.8/lib/ -isystem /home/vext01/research/warmup_experiment/work/gcc-inst/x86_64-unknown-openbsd5.8/include -isystem /home/vext01/research/warmup_experiment/work/gcc-inst/x86_64-unknown-openbsd5.8/sys-include -I/home/vext01/research/warmup_experiment/work/gcc/libstdc++-v3/../libgcc -I/home/vext01/research/warmup_experiment/work/gcc/sd_build/x86_64-unknown-openbsd5.8/libstdc++-v3/include/x86_64-unknown-openbsd5.8 -I/home/vext01/research/warmup_experiment/work/gcc/sd_build/x86_64-unknown-openbsd5.8/libstdc++-v3/include -I/home/vext01/research/warmup_experiment/work/gcc/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=eh_aux_runtime.lo -g -O2 -std=gnu++11 -c ../../../../libstdc++-v3/libsupc++/eh_aux_runtime.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o eh_aux_runtime.o In file included from ../../../../libstdc++-v3/libsupc++/unwind-cxx.h:35:0, from ../../../../libstdc++-v3/libsupc++/eh_aux_runtime.cc:29: /home/vext01/research/warmup_experiment/work/gcc/sd_build/x86_64-unknown-openbsd5.8/libstdc++-v3/include/cstddef:51:11: error: '::max_align_t' has not been declared using ::max_align_t; ^ Makefile:820: recipe for target 'eh_aux_runtime.lo' failed gmake[5]: *** [eh_aux_runtime.lo] Error 1 gmake[5]: Leaving directory '/home/vext01/research/warmup_experiment/work/gcc/sd_build/x86_64-unknown-openbsd5.8/libstdc++-v3/libsupc++' Having spoken to `redi' on IRC, it seems the problem is that OpenBSD's stddef.h does not define max_align_t. Redi asked me to raise an issue. Cheers
[Bug target/68273] [5 Regression] Wrong code on mips/mipsel due to (invalid?) peeking at alignments in function_arg.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273
--- Comment #22 from Richard Biener ---
If -fno-ipa-sra helps can you try
Index: gcc/tree-sra.c
===
--- gcc/tree-sra.c (revision 233268)
+++ gcc/tree-sra.c (working copy)
@@ -4696,7 +4696,7 @@ get_replaced_param_substitute (struct ip
{
char *pretty_name = make_fancy_name (adj->base);
- repl = create_tmp_reg (TREE_TYPE (adj->base), "ISR");
+ repl = create_tmp_reg (TYPE_MAIN_VARIANT (TREE_TYPE (adj->base)),
"ISR");
DECL_NAME (repl) = get_identifier (pretty_name);
obstack_free (&name_obstack, pretty_name);
as well?
[Bug libstdc++/69744] OpenBSD does not define max_align_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69744 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-10 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Libstdc++ should have a configure test for max_align_t and only use the using -declaration conditionally.
[Bug c++/69687] Buffer Overflow in libiberty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687 Marcel Böhme changed: What|Removed |Added Severity|normal |major --- Comment #8 from Marcel Böhme --- Downstream: * Valgrind: https://bugs.kde.org/show_bug.cgi?id=359181 * GDB: https://sourceware.org/bugzilla/show_bug.cgi?id=19597 * Binutils: https://sourceware.org/bugzilla/show_bug.cgi?id=19571
[Bug libstdc++/69744] OpenBSD does not define max_align_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69744 --- Comment #2 from Richard Biener --- stddef.h is provided by GCC itself and thus likely needs "fixing" for OpenBSD (see gcc/ginclude/stddef.h)
[Bug pch/69745] New: Too big precompiled headers seem to result in a silent compilation failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69745 Bug ID: 69745 Summary: Too big precompiled headers seem to result in a silent compilation failure Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch Assignee: unassigned at gcc dot gnu.org Reporter: vz-gcc at zeitlins dot org Target Milestone: --- This problem had been previously reported in https://gcc.gnu.org/ml/gcc-help/2011-12/msg00019.html and also http://stackoverflow.com/q/21008274/15275 and we've just run into it again: creating a precompiled header somehow "succeeds" while creating a 0 byte .gch file and the subsequent compilation using it _silently_ fails, i.e. the compiler exits with 1 without any error messages, not even when called with "-v" option. This was observed using the MinGW-w64 version of gcc (see the full specs below), but from the URLs given above it doesn't seem to be MinGW-specific, so I'm reporting it here. Target: i686-w64-mingw32 Configured with: ../../../src/gcc-4.9.1/configure --host=i686-w64-mingw32 --build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32 --with-sysroot=/c/mingw491/i686-491-win32-sjlj-rt_v3-rev3/mingw32 --with-gxx-include-dir=/mingw32/i686-w64-mingw32/include/c++ --enable-shared --enable-static --enable-targets=all --enable-multilib --enable-languages=ada,c,c++,fortran,objc,obj-c++,lto --enable-libstdcxx-time=yes --enable-threads=win32 --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --disable-isl-version-check --disable-cloog-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch-32=i686 --with-arch-64=nocona --with-tune-32=generic --with-tune-64=core2 --with-libiconv --with-system-zlib --with-gmp=/c/mingw491/prerequisites/i686-w64-mingw32-static --with-mpfr=/c/mingw491/prerequisites/i686-w64-mingw32-static --with-mpc=/c/mingw491/prerequisites/i686-w64-mingw32-static --with-isl=/c/mingw491/prerequisites/i686-w64-mingw32-static --with-cloog=/c/mingw491/prerequisites/i686-w64-mingw32-static --enable-cloog-backend=isl --with-pkgversion='i686-win32-sjlj-rev3, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw491/i686-491-win32-sjlj-rt_v3-rev3/mingw32/opt/include -I/c/mingw491/prerequisites/i686-zlib-static/include -I/c/mingw491/prerequisites/i686-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw491/i686-491-win32-sjlj-rt_v3-rev3/mingw32/opt/include -I/c/mingw491/prerequisites/i686-zlib-static/include -I/c/mingw491/prerequisites/i686-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/c/mingw491/i686-491-win32-sjlj-rt_v3-rev3/mingw32/opt/lib -L/c/mingw491/prerequisites/i686-zlib-static/lib -L/c/mingw491/prerequisites/i686-w64-mingw32-static/lib -Wl,--large-address-aware' Thread model: win32 gcc version 4.9.1 (i686-win32-sjlj-rev3, Built by MinGW-W64 project)
[Bug fortran/67451] [5/6 Regression] [F08] ICE with sourced allocation from coarray.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67451 --- Comment #13 from Dominique d'Humieres --- The patch fixes the two issues I saw on x86_64-apple-darwin15 (comment 10 and an ICE when compiling the test with -fcoarray=lib).
[Bug c++/69687] Buffer Overflow in libiberty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687 Markus Trippelsdorf changed: What|Removed |Added Severity|major |normal
[Bug fortran/69742] [4.9/5/6 Regression] ICE with -O3 and ASSOCIATE containing repeated expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69742 Dominique d'Humieres changed: What|Removed |Added Keywords||ice-on-valid-code Known to work||4.6.4 Known to fail||4.7.3 --- Comment #5 from Dominique d'Humieres --- The change occurred between revisions r17 (2011-10-14, OK) and r180086 (2011-10-17, ICE), likely r180063.
[Bug go/67180] Gccgo does not support MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67180 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-02-10 Ever confirmed|0 |1
[Bug c/69746] New: [6 Regression] diagnostic about non-constant expression not helpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69746 Bug ID: 69746 Summary: [6 Regression] diagnostic about non-constant expression not helpful Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- #define SIZEOF_INT 4 #define ASSERT(e) extern int test[1-2*!(e)]; ASSERT((1 << (8*SIZEOF_INT-1)) < 0) since GCC 6 results in t.c:2:30: error: variably modified ‘test’ at file scope #define ASSERT(e) extern int test[1-2*!(e)]; ^ t.c:4:1: note: in expansion of macro ‘ASSERT’ ASSERT((1 << (8*SIZEOF_INT-1)) < 0) ^~ but no mentioning of the signed overflow occuring in 1 << 31 and thus the non-constant result. GCC 5 accepts this without complaining.
[Bug c++/69649] [6 Regression] ICE in assign_temp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69649 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Wed Feb 10 15:06:20 2016 New Revision: 233271 URL: https://gcc.gnu.org/viewcvs?rev=233271&root=gcc&view=rev Log: PR ipa/69241 PR c++/69649 * gimplify.c (gimplify_modify_expr): Set lhs even for noreturn calls if the return type is TREE_ADDRESSABLE. * cgraphunit.c (cgraph_node::expand_thunk): Likewise. * ipa-split.c (split_function): Fix doubled "we" in comment. Use void return type for the split part even if !split_point->split_part_set_retval. * g++.dg/ipa/pr69241-1.C: New test. * g++.dg/ipa/pr69241-2.C: New test. * g++.dg/ipa/pr69241-3.C: New test. * g++.dg/ipa/pr69649.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr69241-1.C trunk/gcc/testsuite/g++.dg/ipa/pr69241-2.C trunk/gcc/testsuite/g++.dg/ipa/pr69241-3.C trunk/gcc/testsuite/g++.dg/ipa/pr69649.C Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/gimplify.c trunk/gcc/ipa-split.c trunk/gcc/testsuite/ChangeLog
[Bug c/69746] [6 Regression] diagnostic about non-constant expression not helpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69746 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- I think it was intentional that we only warn here with -Wshift-overflow=2, but consider the shift expression as non-constant in any case.
[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69241 --- Comment #21 from Jakub Jelinek --- Author: jakub Date: Wed Feb 10 15:06:20 2016 New Revision: 233271 URL: https://gcc.gnu.org/viewcvs?rev=233271&root=gcc&view=rev Log: PR ipa/69241 PR c++/69649 * gimplify.c (gimplify_modify_expr): Set lhs even for noreturn calls if the return type is TREE_ADDRESSABLE. * cgraphunit.c (cgraph_node::expand_thunk): Likewise. * ipa-split.c (split_function): Fix doubled "we" in comment. Use void return type for the split part even if !split_point->split_part_set_retval. * g++.dg/ipa/pr69241-1.C: New test. * g++.dg/ipa/pr69241-2.C: New test. * g++.dg/ipa/pr69241-3.C: New test. * g++.dg/ipa/pr69649.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr69241-1.C trunk/gcc/testsuite/g++.dg/ipa/pr69241-2.C trunk/gcc/testsuite/g++.dg/ipa/pr69241-3.C trunk/gcc/testsuite/g++.dg/ipa/pr69649.C Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/gimplify.c trunk/gcc/ipa-split.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69241 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #22 from Jakub Jelinek --- Fixed.
[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69241 Markus Trippelsdorf changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #23 from Markus Trippelsdorf --- (In reply to Jakub Jelinek from comment #22) > Fixed. Unfortunately, no. Chromium and the testcase from comment1 still ICE.
[Bug go/68562] morestack misaligns stack on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68562 --- Comment #10 from ian at gcc dot gnu.org --- Author: ian Date: Wed Feb 10 15:14:05 2016 New Revision: 233273 URL: https://gcc.gnu.org/viewcvs?rev=233273&root=gcc&view=rev Log: PR go/68562 * config/i386/morestack.S (__stack_split_initialize): Align stack. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/i386/morestack.S
[Bug go/68562] morestack misaligns stack on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68562 --- Comment #11 from ian at gcc dot gnu.org --- Author: ian Date: Wed Feb 10 15:14:24 2016 New Revision: 233274 URL: https://gcc.gnu.org/viewcvs?rev=233274&root=gcc&view=rev Log: PR go/68562 * config/i386/morestack.S (__stack_split_initialize): Align stack. Modified: branches/gcc-5-branch/libgcc/ChangeLog branches/gcc-5-branch/libgcc/config/i386/morestack.S
[Bug go/68562] morestack misaligns stack on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68562 Ian Lance Taylor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Ian Lance Taylor --- Thanks for testing it. Patch committed to mainline and GCC 5 branch.
[Bug target/69747] New: c6x cross-compiler fails with "Error: inconsistent uses of .cfi_sections"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69747
Bug ID: 69747
Summary: c6x cross-compiler fails with "Error: inconsistent
uses of .cfi_sections"
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Target Milestone: ---
When building both gcc-5.3.1 and gcc-6 for c6x, the builds fail when
configuring libgcc with the following error:
/tmp/cc6wIVaX.s: Assembler messages:
/tmp/cc6wIVaX.s:12: Error: inconsistent uses of .cfi_sections
This can be tested in the build tree with:
echo 'int main() { return 0; }' | ./gcc/xgcc -x c -c -g - -B ./gcc
-fexceptions
The gcc being built is the following:
%global DATE 20151207
%global SVNREV 231358
%global gcc_version 5.3.1
gcc is configured as follows:
CC=gcc \
CXX=g++ \
CFLAGS='-O2 -g -Wall -Wformat-security -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -mtune=generic' \
CXXFLAGS=' -O2 -g -Wformat-security -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -mtune=generic ' \
CFLAGS_FOR_TARGET='-g -O2 -Wall -fexceptions' \
AR_FOR_TARGET=/usr/bin/c6x-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/c6x-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/c6x-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/c6x-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/c6x-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/c6x-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/c6x-linux-gnu-ranlib \
READELF_FOR_TARGET=/usr/bin/c6x-linux-gnu-readelf \
STRIP_FOR_TARGET=/usr/bin/c6x-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/c6x-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/c6x-linux-gnu-windmc \
LDFLAGS='-Wl,-z,relro ' \
../gcc-5.3.1-20151207/configure --bindir=/usr/bin
--build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float
--disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp
--disable-libmudflap --disable-libquadmath --disable-libssp
--disable-libunwind-exceptions --disable-shared --disable-silent-rules
--disable-sjlj-exceptions --disable-threads --with-ld=/usr/bin/c6x-linux-gnu-ld
--enable-__cxa_atexit --enable-checking=release --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++
--enable-linker-build-id --enable-lto --enable-nls --enable-obsolete
--enable-plugin --enable-targets=all --exec-prefix=/usr
--host=x86_64-redhat-linux-gnu --includedir=/usr/include
--infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var
--mandir=/usr/share/man --prefix=/usr --program-prefix=c6x-linux-gnu-
--sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc
--target=c6x-uclinux --with-bugurl=http://bugzilla.redhat.com/bugzilla/
--with-isl --with-linker-hash-style=gnu --with-newlib
--with-plugin-ld=/usr/bin/c6x-linux-gnu-ld
--with-sysroot=/usr/c6x-linux-gnu/sys-root --with-system-libunwind
--with-system-zlib --without-headers
The binutils is binutils-2.26 configured for the same target.
[Bug libstdc++/69744] OpenBSD does not define max_align_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69744
--- Comment #3 from Jonathan Wakely ---
(In reply to Richard Biener from comment #2)
> stddef.h is provided by GCC itself and thus likely needs "fixing" for OpenBSD
> (see gcc/ginclude/stddef.h)
Yeah, for some reason that header isn't used for this target:
# 1
"/home/vext01/research/warmup_experiment/work/gcc/sd_build/x86_64-unknown-openbsd5.8/libstdc++-v3/include/cstddef"
1
# 42
"/home/vext01/research/warmup_experiment/work/gcc/sd_build/x86_64-unknown-openbsd5.8/libstdc++-v3/include/cstddef"
# 43
"/home/vext01/research/warmup_experiment/work/gcc/sd_build/x86_64-unknown-openbsd5.8/libstdc++-v3/include/cstddef"
3
# 1
"/home/vext01/research/warmup_experiment/work/gcc/sd_build/gcc/include-fixed/stddef.h"
1 3 4
# 54
"/home/vext01/research/warmup_experiment/work/gcc/sd_build/gcc/include-fixed/stddef.h"
3 4
typedef long int ptrdiff_t;
# 80
"/home/vext01/research/warmup_experiment/work/gcc/sd_build/gcc/include-fixed/stddef.h"
3 4
typedef __wint_t wint_t;
typedef __mbstate_t mbstate_t;
# 46
"/home/vext01/research/warmup_experiment/work/gcc/sd_build/x86_64-unknown-openbsd5.8/libstdc++-v3/include/cstddef"
2 3
namespace std
{
using ::max_align_t;
}
Does include-fixed/stddef.h take priority over GCC's own stddef.h ?
[Bug c++/69748] New: SIGSEGV received on vmovdqa instruction during avx-vectorized array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69748 Bug ID: 69748 Summary: SIGSEGV received on vmovdqa instruction during avx-vectorized array initialization Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vladyslav.buslov at harmonicinc dot com Target Milestone: --- Created attachment 37652 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37652&action=edit Example program Recently we switched to march=core-avx2 and got unexpected crash during array initialization in class constructor. Problem only appears when __attribute__((__aligned__(64))) is specified for structure that contains instance of that class. According to generated asm code it seems that gcc assumes that array memory is always aligned to 32 and doesn't generate prologue code to process starting bytes up to aligned address. I was able to reproduce this issue with very simple and convoluted example program. Relevant info: ccap@daa-52:~/Sandbox/vb$ g++ -std=gnu++11 -g -v -m64 -pthread -march=core-avx2 -O3 -Wall -Wextra -save-temps testavx.cpp Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.2 (Debian 4.9.2-10) COLLECT_GCC_OPTIONS='-std=gnu++11' '-g' '-v' '-m64' '-pthread' '-march=core-avx2' '-O3' '-Wall' '-Wextra' '-save-temps' '-shared-libgcc' /usr/lib/gcc/x86_64-linux-gnu/4.9/cc1plus -E -quiet -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE -D_REENTRANT testavx.cpp -m64 -march=core-avx2 -std=gnu++11 -Wall -Wextra -g -fworking-directory -O3 -fpch-preprocess -o testavx.ii ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/4.9" ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/4.9 /usr/include/x86_64-linux-gnu/c++/4.9 /usr/include/c++/4.9/backward /usr/lib/gcc/x86_64-linux-gnu/4.9/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/4.9/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-std=gnu++11' '-g' '-v' '-m64' '-pthread' '-march=core-avx2' '-O3' '-Wall' '-Wextra' '-save-temps' '-shared-libgcc' /usr/lib/gcc/x86_64-linux-gnu/4.9/cc1plus -fpreprocessed testavx.ii -quiet -dumpbase testavx.cpp -m64 -march=core-avx2 -auxbase testavx -g -O3 -Wall -Wextra -std=gnu++11 -version -o testavx.s GNU C++ (Debian 4.9.2-10) version 4.9.2 (x86_64-linux-gnu) compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version 3.1.2-p3, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++ (Debian 4.9.2-10) version 4.9.2 (x86_64-linux-gnu) compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version 3.1.2-p3, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: ff85870e740eb08c48a56c2c170390f8 COLLECT_GCC_OPTIONS='-std=gnu++11' '-g' '-v' '-m64' '-pthread' '-march=core-avx2' '-O3' '-Wall' '-Wextra' '-save-temps' '-shared-libgcc' as -v --64 -o testavx.o testavx.s GNU assembler version 2.25 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.25 COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-l
[Bug c++/69748] SIGSEGV received on vmovdqa instruction during avx-vectorized array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69748 --- Comment #1 from Vladyslav Buslov --- Created attachment 37653 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37653&action=edit temp ii file for example program
[Bug tree-optimization/69652] [6 Regression] [ICE] verify_ssa fail w/ -O2 -ffast-math -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69652 --- Comment #8 from Ilya Enkovich --- Author: ienkovich Date: Wed Feb 10 15:22:17 2016 New Revision: 233275 URL: https://gcc.gnu.org/viewcvs?rev=233275&root=gcc&view=rev Log: gcc/ 2016-02-10 Yuri Rumyantsev PR tree-optimization/69652 * tree-vect-loop.c (optimize_mask_stores): Move declaration of STMT1 to nested loop, did source re-formatting, skip debug statements, add check on statement with volatile operand, remove dead scalar statements. gcc/testsuite/ 2016-02-10 Yuri Rumyantsev PR tree-optimization/69652 * gcc.dg/torture/pr69652.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr69652.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug target/69748] SIGSEGV received on vmovdqa instruction during avx-vectorized array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69748 Markus Trippelsdorf changed: What|Removed |Added Target||x86_64-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-10 CC||trippels at gcc dot gnu.org Component|c++ |target Ever confirmed|0 |1 --- Comment #2 from Markus Trippelsdorf --- Confirmed. Only gcc-4.9 is affected. gcc-5 and 6 are fine.
[Bug tree-optimization/69652] [6 Regression] [ICE] verify_ssa fail w/ -O2 -ffast-math -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69652 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed.
[Bug c++/10200] [6 Regression] Weird clash with same names in different scopes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10200 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/68973] [6 regression] Internal compiler error on power for gcc/testsuite/g++.dg/pr67211.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68973 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED CC||segher at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org
[Bug target/69747] c6x cross-compiler fails with "Error: inconsistent uses of .cfi_sections"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69747 --- Comment #1 from dhowells at redhat dot com --- This gcc also fails: %global DATE 20160205 %global SVNREV 233185 %global gcc_version 6.0.0
[Bug c++/20679] [3.4 Regression] Parse error when accessing attributes of an inner class. Enclosing class is template and have methods with the same name.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20679 Bug 20679 depends on bug 10200, which changed state. Bug 10200 Summary: [6 Regression] Weird clash with same names in different scopes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10200 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/10200] [6 Regression] Weird clash with same names in different scopes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10200 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #35 from Jason Merrill --- Fixed for GCC 6. --- Comment #36 from Jason Merrill --- Author: jason Date: Wed Feb 10 15:34:52 2016 New Revision: 233277 URL: https://gcc.gnu.org/viewcvs?rev=233277&root=gcc&view=rev Log: PR c++/10200 * parser.c (cp_parser_lookup_name): When looking for a template after . or ->, only consider class templates. (cp_parser_postfix_dot_deref_expression): Handle the current instantiation. Remember a dependent object expression. * typeck2.c (build_x_arrow): Handle the current instantiation. Added: trunk/gcc/testsuite/g++.dg/lookup/member2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/typeck2.c
[Bug c++/12944] [meta-bug] C++ name-lookup problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12944 Bug 12944 depends on bug 10200, which changed state. Bug 10200 Summary: [6 Regression] Weird clash with same names in different scopes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10200 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/10200] [6 Regression] Weird clash with same names in different scopes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10200 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #35 from Jason Merrill --- Fixed for GCC 6.
[Bug c++/69657] [6 Regression] abs() not inlined after including math.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69657 --- Comment #12 from Jason Merrill --- Author: jason Date: Wed Feb 10 15:34:59 2016 New Revision: 233278 URL: https://gcc.gnu.org/viewcvs?rev=233278&root=gcc&view=rev Log: PR c++/69657 * name-lookup.c (ambiguous_decl): Call remove_hidden_names. (lookup_name_real_1): Likewise. (remove_hidden_names): Handle non-functions too. Added: trunk/gcc/testsuite/g++.dg/lookup/builtin7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c
[Bug target/69748] SIGSEGV received on vmovdqa instruction during avx-vectorized array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69748 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Markus Trippelsdorf --- On the other hand you're invoking undefined behavior: /home/trippels/exam.cpp:32:26: runtime error: constructor call on misaligned address 0x013b6c20 for type 'CoreData', which requires 64 byte alignment 0x013b6c20: 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 ^ /home/trippels/exam.cpp:33:26: runtime error: constructor call on misaligned address 0x013ce370 for type 'CoreData', which requires 64 byte alignment 0x013ce370: 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 ^ exam.cpp:35:20: runtime error: member access within misaligned address 0x013b6c20 for type 'CoreData', which requires 64 byte alignment 0x013b6c20: 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 ^ exam.cpp:35:51: runtime error: member access within misaligned address 0x013ce370 for type 'CoreData', which requires 64 byte alignment 0x013ce370: 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 target/69749] New: Use aligned spill/fill for vector register in interrupt handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69749
Bug ID: 69749
Summary: Use aligned spill/fill for vector register in
interrupt handler
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: vaalfreja at gmail dot com
Target Milestone: ---
On hjl/interrupt/stage1 branch, I got
[hjl@gnu-6 interrupt-2]$ cat y.c
extern void bar (void);
__attribute__((interrupt))
void
foo (void *frame)
{
bar ();
}
[hjl@gnu-6 interrupt-2]$ make y.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -S -O2 y.c
[hjl@gnu-6 interrupt-2]$ cat y.s
.file "y.c"
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
pushq %r11
pushq %r10
pushq %r9
pushq %r8
pushq %rdi
pushq %rsi
pushq %rcx
pushq %rdx
pushq %rax
andq$-16, %rsp
subq$256, %rsp
movups %xmm0, -328(%rbp)
.cfi_escape 0x10,0x11,0x3,0x76,0xb8,0x7d
.cfi_offset 11, -24
.cfi_offset 10, -32
.cfi_offset 9, -40
.cfi_offset 8, -48
.cfi_offset 5, -56
.cfi_offset 4, -64
.cfi_offset 2, -72
.cfi_offset 1, -80
.cfi_offset 0, -88
movups %xmm1, -312(%rbp)
.cfi_escape 0x10,0x12,0x3,0x76,0xc8,0x7d
movups %xmm2, -296(%rbp)
.cfi_escape 0x10,0x13,0x3,0x76,0xd8,0x7d
movups %xmm3, -280(%rbp)
.cfi_escape 0x10,0x14,0x3,0x76,0xe8,0x7d
movups %xmm4, -264(%rbp)
.cfi_escape 0x10,0x15,0x3,0x76,0xf8,0x7d
movups %xmm5, -248(%rbp)
.cfi_escape 0x10,0x16,0x3,0x76,0x88,0x7e
movups %xmm6, -232(%rbp)
.cfi_escape 0x10,0x17,0x3,0x76,0x98,0x7e
movups %xmm7, -216(%rbp)
.cfi_escape 0x10,0x18,0x3,0x76,0xa8,0x7e
movups %xmm8, -200(%rbp)
.cfi_escape 0x10,0x19,0x3,0x76,0xb8,0x7e
movups %xmm9, -184(%rbp)
.cfi_escape 0x10,0x1a,0x3,0x76,0xc8,0x7e
movups %xmm10, -168(%rbp)
.cfi_escape 0x10,0x1b,0x3,0x76,0xd8,0x7e
movups %xmm11, -152(%rbp)
.cfi_escape 0x10,0x1c,0x3,0x76,0xe8,0x7e
movups %xmm12, -136(%rbp)
.cfi_escape 0x10,0x1d,0x3,0x76,0xf8,0x7e
movups %xmm13, -120(%rbp)
.cfi_escape 0x10,0x1e,0x3,0x76,0x88,0x7f
movups %xmm14, -104(%rbp)
.cfi_escape 0x10,0x1f,0x3,0x76,0x98,0x7f
movups %xmm15, -88(%rbp)
.cfi_escape 0x10,0x20,0x3,0x76,0xa8,0x7f
cld
callbar
movups -328(%rbp), %xmm0
movups -312(%rbp), %xmm1
movups -296(%rbp), %xmm2
movups -280(%rbp), %xmm3
movups -264(%rbp), %xmm4
movups -248(%rbp), %xmm5
movups -232(%rbp), %xmm6
movups -216(%rbp), %xmm7
movups -200(%rbp), %xmm8
movups -184(%rbp), %xmm9
movups -168(%rbp), %xmm10
movups -152(%rbp), %xmm11
movups -136(%rbp), %xmm12
movups -120(%rbp), %xmm13
movups -104(%rbp), %xmm14
movups -88(%rbp), %xmm15
leaq-72(%rbp), %rsp
.cfi_restore 29
.cfi_restore 28
.cfi_restore 27
.cfi_restore 26
.cfi_restore 25
.cfi_restore 24
.cfi_restore 23
.cfi_restore 22
.cfi_restore 21
.cfi_restore 20
.cfi_restore 19
.cfi_restore 18
.cfi_restore 17
popq%rax
popq%rdx
popq%rcx
popq%rsi
popq%rdi
popq%r8
popq%r9
popq%r10
popq%r11
popq%rbp
.cfi_def_cfa 7, 8
iretq
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 6.0.0 20160209 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 interrupt-2]$
We should use aligned spill/fill for vector registers.
[Bug target/69750] New: ICE in sh64 targetted gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69750
Bug ID: 69750
Summary: ICE in sh64 targetted gcc-6
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Target Milestone: ---
When cross-building gcc-6 for sh64, the builds fail when configuring libgcc
with an ICE. This can be replicated by running the following command in the
build directory:
echo 'int main() { return 0; }' | ./gcc/xgcc -x c -c -g - -B ./gcc
-fexceptions
The gcc being built is the following:
%global DATE 20160205
%global SVNREV 233185
%global gcc_version 6.0.0
gcc is configured as follows:
CC=gcc \
CXX=g++ \
CFLAGS='-O2 -g -Wall -Wformat-security -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic' \
+echo ' -O2 -g -Wall -Wformat-security -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic ' \
+sed 's/ -Wall / /g;s/ -fexceptions / /g' \
+sed 's/ -Werror=format-security / -Wformat -Werror=format-security /' \
CXXFLAGS=' -O2 -g -Wformat-security -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic ' \
CFLAGS_FOR_TARGET='-g -O2 -Wall -fexceptions' \
AR_FOR_TARGET=/usr/bin/sh64-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/sh64-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/sh64-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/sh64-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/sh64-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/sh64-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/sh64-linux-gnu-ranlib \
READELF_FOR_TARGET=/usr/bin/sh64-linux-gnu-readelf \
STRIP_FOR_TARGET=/usr/bin/sh64-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/sh64-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/sh64-linux-gnu-windmc \
LDFLAGS='-Wl,-z,relro ' \
../gcc-6.0.0-20160205/configure --bindir=/usr/bin
--build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float
--disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp
--disable-libmpx --disable-libquadmath --disable-libssp
--disable-libunwind-exceptions --disable-shared --disable-silent-rules
--disable-sjlj-exceptions --disable-threads
--with-ld=/usr/bin/sh64-linux-gnu-ld --enable-__cxa_atexit
--enable-checking=release --enable-gnu-unique-object --enable-initfini-array
--enable-languages=c,c+--enable-linker-build-id --enable-lto --enable-nls
--enable-obsolete --enable-plugin --enable-targets=all --exec-prefix=/usr
--host=x86_64-redhat-linux-gnu --includedir=/usr/include
--infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var
--mandir=/usr/share/man --prefix=/usr --program-prefix=sh64-linux-gnu-
--sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc
--target=sh64-linux-elf --with-bugurl=http://bugzilla.redhat.com/bugzilla/
--with-isl --with-linker-hash-style=gnu --with-newlib
--with-plugin-ld=/usr/bin/sh64-linux-gnu-ld
--with-sysroot=/usr/sh64-linux-gnu/sys-root --with-system-libunwind
--with-system-zlib --without-headers
--with-multilib-list=m5-32media,m5-32media-nofpu,m5-compact,m5-compact-nofpu,m5-64media,m5-64media-nofpu
The binutils is binutils-2.26 configured for the same target.
[Bug bootstrap/68404] [6 Regression] PGO/LTO bootstrap failure on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404 David Edelsohn changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #27 from David Edelsohn --- As Bernd said, this is a work-around, not a fix.
[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69241 --- Comment #24 from Jakub Jelinek --- The #c1 testcase doesn't bother to return a value from the function, does Chromium has similar garbage in it?
[Bug testsuite/69573] FAIL: gcc.dg/pr61053.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573 --- Comment #8 from Martin Sebor --- (In reply to Chen Gang from comment #7) > Can we check __APPLE_CC__ instead of __SIZEOF_LONG_DOUBLE__ ? Thanks for testing the patch! It sounds like on this target, even though sizeof(long double) is 16, its alignment requirement is less than that. Let me see if I can come up with a general solution for this. If not, I'll go with your suggestion and poste an updated patch for review.
[Bug target/69748] SIGSEGV received on vmovdqa instruction during avx-vectorized array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69748 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #4 from Andrew Pinski --- Dup of bug 15795. The real issue is operator new does not know about alignment requirements. *** This bug has been marked as a duplicate of bug 15795 ***
[Bug c++/15795] No way to teach operator new anything about alignment requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795 Andrew Pinski changed: What|Removed |Added CC||vladyslav.buslov@harmonicin ||c.com --- Comment #43 from Andrew Pinski --- *** Bug 69748 has been marked as a duplicate of this bug. ***
[Bug libstdc++/69751] error: call of overloaded 'abs(size_t)' is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69751 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Marek Polacek --- This is invalid; calling abs() on an unsigned value does not make sense. Cf. http://cplusplus.github.io/LWG/lwg-active.html#2192
[Bug libstdc++/69751] New: error: call of overloaded 'abs(size_t)' is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69751
Bug ID: 69751
Summary: error: call of overloaded 'abs(size_t)' is ambiguous
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: martin.gansser at gmail dot com
Target Milestone: ---
g++ -c -ggdb -O0 -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -fPIC
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/mysql
-I/usr/include/python2.7 -I/usr/include/python2.7 -D_GNU_SOURCE
-DBINDEST='"/usr/bin"' -DTARGET='"epgd"' -DLOG_PREFIX='""'
-DPLGDIR='"/usr/lib64/epgd"' -DUSEUUID -DUSEMD5 -DUSELIBXML -DUSELIBARCHIVE
-DUSEJSON -DUSEGUNZIP -I/usr/include/libxml2 -I/usr/include/libxml2
-DGIT_REV='""' -o series.o series.c
series.c: In member function 'int cEpgd::evaluateEpisodes()':
series.c:90:99: error: call of overloaded 'abs(size_t)' is ambiguous
if (::abs(strlen(evtCompShortText) -
strlen(episodeDb->getStrValue("COMPPARTNAME"))) >= dMin)
^
In file included from /usr/include/c++/6.0.0/cstdlib:75:0,
from /usr/include/c++/6.0.0/stdlib.h:36,
from /usr/include/libxml2/libxml/SAX.h:16,
from /usr/include/libxml2/libxml/globals.h:20,
from /usr/include/libxml2/libxml/xmlIO.h:117,
from /usr/include/libxml2/libxml/parser.h:811,
from /usr/include/libxslt/transform.h:15,
from epgd.h:11,
from series.c:8:
/usr/include/stdlib.h:774:12: note: candidate: int abs(int)
extern int abs (int __x) __THROW __attribute__ ((__const__)) __wur;
^~~
the program compiles fine with gcc-5.3.1
[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69241 --- Comment #25 from Markus Trippelsdorf --- (In reply to Jakub Jelinek from comment #24) > The #c1 testcase doesn't bother to return a value from the function, does > Chromium has similar garbage in it? Actually, the chromium file, from which the testcase was reduced, compiles fine now. I will run a full chromium build and close this bug if it succeeds.
[Bug target/69750] ICE in sh64 targetted gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69750 --- Comment #1 from dhowells at redhat dot com --- Doing gdb ./gcc/cc1 and running it with: r -quiet foo.c -g -fexceptions -o /tmp/cc5gm5ki.s shows the failure as: Program received signal SIGSEGV, Segmentation fault. _IO_vfprintf_internal (s=s@entry=0x7bfff4e0, format=format@entry=0xea2d7b "*%s%s%ld", ap=ap@entry=0x7bfff608) at vfprintf.c:1311 1311 f = lead_str_end = __find_specmb ((const UCHAR_T *) format); Asking for a backtrace gives at least 6000 entries, starting like this: #0 _IO_vfprintf_internal (s=s@entry=0x7bfff4e0, format=format@entry=0xea2d7b "*%s%s%ld", ap=ap@entry=0x7bfff608) at vfprintf.c:1311 #1 0x766e488b in __IO_vsprintf (string=0x7bfff7b0 "\004", format=0xea2d7b "*%s%s%ld", args=args@entry=0x7bfff608) at iovsprintf.c:42 #2 0x766c7e57 in __sprintf (s=s@entry=0x7bfff7b0 "\004", format=format@entry=0xea2d7b "*%s%s%ld") at sprintf.c:32 #3 0x00b716f4 in force_const_mem (mode=mode@entry=SImode, x=x@entry=0x7fffea163e70) at ../../gcc-6.0.0-20160205/gcc/varasm.c:3732 #4 0x006cdc43 in emit_move_insn (x=x@entry=0x7fffea163eb8, y=y@entry=0x7fffea163e70) at ../../gcc-6.0.0-20160205/gcc/expr.c:3559 #5 0x006b3c70 in force_reg (mode=mode@entry=SImode, x=x@entry=0x7fffea163e70) at ../../gcc-6.0.0-20160205/gcc/explow.c:631 #6 0x006b490e in force_reg (x=0x7fffea163e70, mode=SImode) at ../../gcc-6.0.0-20160205/gcc/explow.c:451 #7 memory_address_addr_space (mode=SImode, x=0x7fffea163e70, as=) at ../../gcc-6.0.0-20160205/gcc/explow.c:457 #8 0x006a0775 in change_address_1 (memref=0x7fffea163ea0, mode=SImode, mode@entry=VOIDmode, addr=0x7fffea163e70, validate=validate@entry=1, inplace=) at ../../gcc-6.0.0-20160205/gcc/emit-rtl.c:2127 #9 0x006a3880 in replace_equiv_address (memref=, addr=, inplace=inplace@entry=true) at ../../gcc-6.0.0-20160205/gcc/emit-rtl.c:2399 #10 0x006b467a in validize_mem (ref=, ref@entry=0x7fffea163ea0) at ../../gcc-6.0.0-20160205/gcc/explow.c:495 at this point, #4-#10 repeat: #11 0x006cdbbb in emit_move_insn (x=x@entry=0x7fffea163e58, y=0x7fffea163ea0, y@entry=0x7fffea163e10) at ../../gcc-6.0.0-20160205/gcc/expr.c:3582 #12 0x006b3c70 in force_reg (mode=mode@entry=SImode, x=x@entry=0x7fffea163e10) at ../../gcc-6.0.0-20160205/gcc/explow.c:631 #13 0x006b490e in force_reg (x=0x7fffea163e10, mode=SImode) at ../../gcc-6.0.0-20160205/gcc/explow.c:451 #14 memory_address_addr_space (mode=SImode, x=0x7fffea163e10, as=) at ../../gcc-6.0.0-20160205/gcc/explow.c:457 #15 0x006a0775 in change_address_1 (memref=0x7fffea163e40, mode=SImode, mode@entry=VOIDmode, addr=0x7fffea163e10, validate=validate@entry=1, inplace=) at ../../gcc-6.0.0-20160205/gcc/emit-rtl.c:2127 #16 0x006a3880 in replace_equiv_address (memref=, addr=, inplace=inplace@entry=true) at ../../gcc-6.0.0-20160205/gcc/emit-rtl.c:2399 and repeat: #17 0x006b467a in validize_mem (ref=, ref@entry=0x7fffea163e40) at ../../gcc-6.0.0-20160205/gcc/explow.c:495 #18 0x006cdbbb in emit_move_insn (x=x@entry=0x7fffea163df8, ...
[Bug libstdc++/69751] error: call of overloaded 'abs(size_t)' is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69751
--- Comment #2 from Jonathan Wakely ---
(In reply to mgans...@alice.de from comment #0)
> series.c:90:99: error: call of overloaded 'abs(size_t)' is ambiguous
> if (::abs(strlen(evtCompShortText) -
> strlen(episodeDb->getStrValue("COMPPARTNAME"))) >= dMin)
>
This doesn't do what the author of that code thinks it does. If the second
string is longer than the first then the difference between them is not a
negative number, it's a huge unsigned value. Calling abs(int) on a huge
unsigned value will overflow and is undefined behaviour.
This is exactly why calling abs() here should be an error: the code has
undefined behaviour and should be fixed.
[Bug rtl-optimization/59811] [4.9/5/6 Regression] Huge increase in memory usage and compile time in combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59811 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #12 from Jeffrey A. Law --- So Jan fixed the combine issue when he committed his changes to remove statements which set write-only variables. That essentially brought the combiner down to nothing. Hard to believe since it was just a dozen or so nodes that were determined to be write-only. But that was double-checked by just hacking out the call to set_writeonly_bit in one of the older compilers I was testing. Richi's change to improve DOM's handling of aliased loads helps considerably if someone were to disable the IPA propagation bits. Unfortunately we're still burning a lot of time in the alias walking. So we can't reasonably consider this resolved for gcc-6: alias stmt walking : 38.67 (64%) usr 0.01 ( 7%) sys 38.64 (64%) wall 2 kB ( 0%) ggc tree copy propagation : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc combiner: 0.35 ( 1%) usr 0.01 ( 7%) sys 0.36 ( 1%) wall 2709 kB ( 2%) ggc integrated RA : 2.27 ( 4%) usr 0.00 ( 0%) sys 2.31 ( 4%) wall 6634 kB ( 4%) ggc LRA hard reg assignment : 4.39 ( 7%) usr 0.01 ( 7%) sys 4.41 ( 7%) wall 0 kB ( 0%) ggc The alias statement walking is a bit surprising. This is Fortran code after all, I wouldn't expect a lot of aliasing, I guess it's just a lot of calls into the alias statement walking code (but I haven't looked to confirm that theory). I think the RA/LRA times are probably worth some investigation as well once we get a handle on what's causing alias stmt walking to go nuts.
[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69241 --- Comment #26 from Jakub Jelinek --- Created attachment 37654 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37654&action=edit gcc6-pr69241.patch Well, we shouldn't ICE even on questionable testcases where -Wreturn-type complains on them. Untested patch that ought to fix that.
[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671 --- Comment #13 from Vladimir Makarov --- (In reply to Jakub Jelinek from comment #9) > But something like that might remove the flexibility from the register > allocator. > > Wonder why the RA in this case doesn't see that the value loaded into that > pseudo register is CONST0_RTX which satisfies the C constraint and doesn't > undo CSE (rematerialize) in that case if it doesn't have that value already > loaded in the matching register to the output one. LRA remat is a simple global scope subpass to remove reload loads from memory by reusing values held in registers. It does not check constraints at all. Adding some checks will complicate the sub-pass much. I think Kirill proposed a good solution: "Split all patterns into match_dup and 0_operand by hand" I believe it will work well for RA.
[Bug c++/69098] [5/6 regression] Member function pointer template flagged with 'is not a function template'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69098 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #9 from Patrick Palka --- (In reply to Jakub Jelinek from comment #7) > (In reply to Patrick Palka from comment #6) > > This fixes it: > > Are you going to post it to gcc-patches (with ChangeLog and testcase)? It doesn't yet make sense to me why r226642 introduces this regression. Once I figure it out I'll post the patch.
[Bug libstdc++/69751] error: call of overloaded 'abs(size_t)' is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69751 --- Comment #3 from mgansser at alice dot de --- many thanks for supporting me, problem was solved.
[Bug testsuite/69573] FAIL: gcc.dg/pr61053.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573 --- Comment #9 from Martin Sebor --- I built the x86_64-apple-darwin15.3.0 cross-compiler to better understand what the problem is but I don't see it. The cross compiler says the size and alignment of long double is 16 in both ILP32 (with -m32) and LP64. So the patched test should pass without any further changes. Can you let me know the target triple of your GCC and the result of _Alignof(long double)? Below is what I get: $ (set -x; cat t.c && for m in 32 64; do /build/sysroot/x86_64-apple-darwin15.3.0/bin/x86_64-apple-darwin15.3.0-gcc -S -Wall -m$m -o/dev/stdout -std=c11 t.c; done) + cat t.c int alignof_long_double = _Alignof (long double); long double ld = 1; + for m in 32 64 + /build/sysroot/x86_64-apple-darwin15.3.0/bin/x86_64-apple-darwin15.3.0-gcc -S -Wall -m32 -o/dev/stdout -std=c11 t.c .globl _alignof_long_double .data .align 2 _alignof_long_double: .long 16<<< _Alignof(long double) in -m64 .globl _ld .align 4 <<< alignment of ld (2^4 bytes) _ld: .long 0 .long 2147483648 .long 16383 .long 0 .subsections_via_symbols + for m in 32 64 + /build/sysroot/x86_64-apple-darwin15.3.0/bin/x86_64-apple-darwin15.3.0-gcc -S -Wall -m64 -o/dev/stdout -std=c11 t.c .globl _alignof_long_double .data .align 2 _alignof_long_double: .long 16<<< _Alignof(long double) with -m64 .globl _ld .align 4 <<< alignment of ld (2^4 bytes) _ld: .long 0 .long 2147483648 .long 16383 .long 0 .subsections_via_symbols
