[Bug bootstrap/83015] [8 regression] bootstrap comparison failure on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83015 --- Comment #17 from Jan Hubicka --- Indeed with the configure flags used by your tester it does reproduce. It is difference in inlining priority order, perhaps caused by the badness sanity check (though I fail to see how)
[Bug testsuite/81807] [8 Regression] many *.cc asan tests fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81807 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||chefmax at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Actually, looking in detail, this has been fixed by r251265 by reverting the change. The *.cc files are intentionally not executed, those are the original upstream tests which are sourced by the asan_test.C wrapper provided by us. It is true that dlclose-test-1-so.cc and shared-lib-test-1-so.cc are not included from anything and not run at all. But those tests are something that really need very special treatment in asan.exp, and apparently that ended up not being included. Some of it has been in e.g. in: https://gcc.gnu.org/ml/gcc-patches/2012-12/msg00106.html Anyway, closing as the regressions don't appear anymore. We might want to backport some asan_test.cc etc. changes, haven't done that recently during the merge.
[Bug fortran/83064] DO CONCURRENT inconsistent results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064
--- Comment #8 from rguenther at suse dot de ---
On Thu, 23 Nov 2017, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064
>
> --- Comment #7 from Dominique d'Humieres ---
> > I looked at the IL from the Fortran FE and it clearly uses a single memory
> > area for tmp for each outer loop iteration. That is, the memory is allocated
> > by the caller.
>
> I confirm that using
>
> pik = compute( low(i), high(i) )
> pi(i) = sum(pik)
>
> gives the right result.
>
> Does it means that the 'sum' in 'sum(compute( low(i), high(i) ))' is not part
> of the parallelization?
no idea, I can't do the above, pik is not declared.
>
> > > Do you understand why the code is not parallelized with
> > > -ftree-parallelize-loops=4?
>
> > Because the outer loop has four iterations and we statically require
> > at least two per thread for outer loops.
>
> Why is it so? and is it documented?
It is documented:
@item parloops-min-per-thread
The minimum number of iterations per thread of an innermost parallelized
loop for which the parallelized variant is prefered over the single
threaded
one. The default is 100. Note that for a parallelized loop nest the
minimum number of iterations of the outermost loop per thread is two.
note autopar isn't very well maintained and certainly the cost modeling
needs some work.
So for the issue in this bug the .original from the fortran FE looks
ok:
while (1)
{
if (ANNOTATE_EXPR ) goto L.10;
{
real(kind=4) val.5;
integer(kind=8) * D.3618;
integer(kind=8) * D.3619;
struct array1_real(kind=4) atmp.6;
real(kind=4) A.7[4];
val.5 = 0.0;
D.3618 = &low[NON_LVALUE_EXPR + -1];
D.3619 = &high[NON_LVALUE_EXPR + -1];
typedef real(kind=4) [4];
atmp.6.dtype = 281;
atmp.6.dim[0].stride = 1;
atmp.6.dim[0].lbound = 0;
atmp.6.dim[0].ubound = 3;
atmp.6.data = (void * restrict) &A.7;
atmp.6.offset = 0;
compute (&atmp.6, D.3618, D.3619);
so A.7 is in scope of the concurrent loop body and gimplification
adds a CLOBBER at the end of the scope.
I believe there's no logic in autopar that would use this to
force local allocation of that variable. It might be also
fragile since we can't really rely on those CLOBBERs persisting(?)
This means a DO CONCURRENT isn't enough to skip the validity
check in autopar, in fact DO CONCURRENT doesn't tell us anything
but maybe skipping any cost modeling during autopar?
[Bug bootstrap/83015] [8 regression] bootstrap comparison failure on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83015 --- Comment #18 from Jan Hubicka --- With the release checking in stage1 it reproduces on x86-64, too. I am testing Index: ipa-inline.c === --- ipa-inline.c(revision 255103) +++ ipa-inline.c(working copy) @@ -1865,6 +1865,8 @@ inline_small_functions (void) gcc_assert (cached_badness == current_badness); gcc_assert (current_badness >= badness); } + else +current_badness = edge_badness (edge, false); #else current_badness = edge_badness (edge, false); #endif
[Bug c++/83138] ICE: Segfault expanding function parameter pack in subsequent sibling pack declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83138 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-24 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- I can't reproduce "This used to work", before r183768 it used to be rejected: pr83138.C:3:21: error: expansion pattern ‘char [][4]’ contains no argument packs pr83138.C:3:21: error: no matching function for call to ‘g()’ pr83138.C:3:21: note: candidate is: pr83138.C:2:28: note: template void g(T) pr83138.C:2:28: note: substitution of deduced template arguments resulted in errors seen above and since then it ICEs due to running out of stack (apparently endless recursion in: #9 0x009f4458 in tsubst_pack_expansion (t=, args=, complain=0, in_decl=) at ../../gcc/cp/pt.c:11497 #10 0x009fbc98 in tsubst_decl (t=, args=, complain=0) at ../../gcc/cp/pt.c:12711 #11 0x009ff9b3 in tsubst (t=, args=, complain=0, in_decl=) at ../../gcc/cp/pt.c:13577 #12 0x009fc3f1 in tsubst_decl (t=, args=, complain=0) at ../../gcc/cp/pt.c:12793 #13 0x009f4458 in tsubst_pack_expansion (t=, args=, complain=0, in_decl=) at ../../gcc/cp/pt.c:11497 ).
[Bug sanitizer/83014] ICE in pretty-print with -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83014 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Fri Nov 24 08:35:10 2017 New Revision: 255134 URL: https://gcc.gnu.org/viewcvs?rev=255134&root=gcc&view=rev Log: PR sanitizer/83014 * ubsan.c (ubsan_type_descriptor): Use pp_unsigned_wide_integer instead of pp_printf with HOST_WIDE_INT_PRINT_DEC. Avoid calling tree_to_uhwi twice. * gcc.dg/ubsan/pr83014.c: New test. Added: trunk/gcc/testsuite/gcc.dg/ubsan/pr83014.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/ubsan.c
[Bug fortran/83064] DO CONCURRENT inconsistent results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064
--- Comment #9 from Richard Biener ---
How does this work with OpenMP and compiler/FE generated temporary arrays?
If I just do
!$OMP parallel do
do i = 1,nsplit
pi(i) = sum(compute( low(i), high(i) ))
end do
I still get
#pragma omp parallel
{
{
#pragma omp for private(i) nowait
for (i = 1; i <= 4; i = i + 1)
{
{
real(kind=4) val.4;
integer(kind=8) * D.3617;
integer(kind=8) * D.3618;
struct array1_real(kind=4) atmp.5;
real(kind=4) A.6[4];
...
atmp.5.data = (void * restrict) &A.6;
atmp.5.offset = 0;
compute (&atmp.5, D.3617, D.3618);
and after lower:
.omp_data_o.17.high = &high;
.omp_data_o.17.low = &low;
.omp_data_o.17.pi = π
#pragma omp parallel shared(pi) shared(low) shared(high) [child fn:
MAIN__._omp_fn.0 (.omp_data_o.17)]
.omp_data_i = (struct .omp_data_s.16 & restrict) &.omp_data_o.17;
#pragma omp for private(i) nowait
for (i = 1; i <= 4; i = i + 1)
try
{
val.4 = 0.0;
D.3644 = i + -1;
D.3674 = .omp_data_i->low;
D.3617 = &*D.3674[D.3644];
D.3644 = i + -1;
D.3675 = .omp_data_i->high;
D.3618 = &*D.3675[D.3644];
atmp.5.dtype = 281;
atmp.5.dim[0].stride = 1;
atmp.5.dim[0].lbound = 0;
atmp.5.dim[0].ubound = 3;
atmp.5.data = &A.6;
but somehow OMP expansion duplicated A.6 into the child function. Does it
simply look at the BLOCK_VARs and duplicates them all, replacing what is
used in the body? There is separate_decls_in_region that I guess is supposed
to do that for autopar, but it only looks at SSA names. So it must be really
the OMP (SSA) lowering that was supposed to handle this duplication? At least
for the OMP example above I don't see anything explicitely marking A.6/atmp
as non-shared.
[Bug fortran/83064] DO CONCURRENT inconsistent results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064 Richard Biener changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #10 from Richard Biener --- Jakub, see last comment for OMP expansion question.
[Bug fortran/83076] [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83076 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org, ||pault at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started with r254427.
[Bug fortran/83064] DO CONCURRENT inconsistent results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064 --- Comment #11 from Jakub Jelinek --- There should be no duplication except for vars mentioned in the clauses on OpenMP constructs (explicit or implicit). So, vars declared outside of the region and referenced inside of the region are either implicitly or explicitly shared/privatized/mapped etc. and vars defined inside of the region are just moved to the new outlined function. We move there the whole BLOCK subtree that is fully contained within the region and the vars too.
[Bug fortran/36313] [F03] {MIN,MAX}{LOC,VAL} should accept character arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36313 --- Comment #13 from Janne Blomqvist --- Author: jb Date: Fri Nov 24 08:51:15 2017 New Revision: 255135 URL: https://gcc.gnu.org/viewcvs?rev=255135&root=gcc&view=rev Log: PR 36313 Replace int with gfc_charlen_type, take 3 Still some prototypes that didn't match the implementation. 2017-11-24 Janne Blomqvist PR fortran/36313 * m4/maxloc2s.m4: Replace int with gfc_charlen_type, take 3. * m4/minloc2s.m4: Likewise. * generated/maxloc2_16_s1.c: Regenerated. * generated/maxloc2_16_s4.c: Regenerated. * generated/maxloc2_4_s1.c: Regenerated. * generated/maxloc2_4_s4.c: Regenerated. * generated/maxloc2_8_s1.c: Regenerated. * generated/maxloc2_8_s4.c: Regenerated. * generated/minloc2_16_s1.c: Regenerated. * generated/minloc2_16_s4.c: Regenerated. * generated/minloc2_4_s1.c: Regenerated. * generated/minloc2_4_s4.c: Regenerated. * generated/minloc2_8_s1.c: Regenerated. * generated/minloc2_8_s4.c: Regenerated. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/generated/maxloc2_16_s1.c trunk/libgfortran/generated/maxloc2_16_s4.c trunk/libgfortran/generated/maxloc2_4_s1.c trunk/libgfortran/generated/maxloc2_4_s4.c trunk/libgfortran/generated/maxloc2_8_s1.c trunk/libgfortran/generated/maxloc2_8_s4.c trunk/libgfortran/generated/minloc2_16_s1.c trunk/libgfortran/generated/minloc2_16_s4.c trunk/libgfortran/generated/minloc2_4_s1.c trunk/libgfortran/generated/minloc2_4_s4.c trunk/libgfortran/generated/minloc2_8_s1.c trunk/libgfortran/generated/minloc2_8_s4.c trunk/libgfortran/m4/maxloc2s.m4 trunk/libgfortran/m4/minloc2s.m4
[Bug fortran/81841] [6/7 Regression] THREADPRIVATE (OpenMP) wrongly rejected in BLOCK DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81841 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|[6/7/8 Regression] |[6/7 Regression] |THREADPRIVATE (OpenMP) |THREADPRIVATE (OpenMP) |wrongly rejected in BLOCK |wrongly rejected in BLOCK |DATA|DATA --- Comment #15 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/81740] [6/7/8 Regression] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81740
--- Comment #3 from Jakub Jelinek ---
Testcase modified for the testsuite:
int a[8][10] = { [2][5] = 4 }, c;
int
main ()
{
short b;
int i, d;
for (b = 4; b >= 0; b--)
for (c = 0; c <= 6; c++)
a[c + 1][b + 2] = a[c][b + 1];
for (i = 0; i < 8; i++)
for (d = 0; d < 10; d++)
if (a[i][d] != (i == 3 && d == 6) * 4)
__builtin_abort ();
return 0;
}
[Bug fortran/83064] DO CONCURRENT inconsistent results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064 --- Comment #12 from rguenther at suse dot de --- On Fri, 24 Nov 2017, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064 > > --- Comment #11 from Jakub Jelinek --- > There should be no duplication except for vars mentioned in the clauses on > OpenMP constructs (explicit or implicit). So, vars declared outside of the > region and referenced inside of the region are either implicitly or explicitly > shared/privatized/mapped etc. and vars defined inside of the region are just > moved to the new outlined function. We move there the whole BLOCK subtree > that > is fully contained within the region and the vars too. Yes, that's what I'm seeing with OMP but I'm not seeing that with autopar. Ah, it looks like autopar identifies the "local" as to be globalized in eliminate_local_variables_stmt. So it would need to somehow detect whether a variable "belongs" to the loop we are parallelizing. Which means detecting whether a BLOCK belongs to a loop? I guess OMP expansion has an easier job here given it has an IL that is much closer to source form... Would we want to record sth like a BLOCK for the scope of a loop in the loop structure? We'd also rely on the CLOBBERs inside to avoid leaking uses/defs. Of course a "simple" liveness analysis like that done during RTL expansion is possible as well. But I fear that it might not be good enough.
[Bug c/83139] New: error: null destination pointer [-Werror=format-truncation=] for second call with same destination pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83139 Bug ID: 83139 Summary: error: null destination pointer [-Werror=format-truncation=] for second call with same destination pointer Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: j...@jak-linux.org Target Milestone: --- Created attachment 42701 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42701&action=edit Example In the attached example (minified proxychains common.c), there are two cases of snprintf(pbuf, bufsize, in a function. The second one causes an error, at -O2 or higher: $ gcc -Wall -Werror -O2 -c -v -save-temps common.c Using built-in specs. COLLECT_GCC=/usr/bin/gcc OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 7.2.0-16' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 7.2.0 (Debian 7.2.0-16) COLLECT_GCC_OPTIONS='-Wall' '-Werror' '-O2' '-c' '-v' '-save-temps' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/7/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu common.c -mtune=generic -march=x86-64 -Wall -Werror -O2 -fpch-preprocess -o common.i ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-linux-gnu/7/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-Wall' '-Werror' '-O2' '-c' '-v' '-save-temps' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/7/cc1 -fpreprocessed common.i -quiet -dumpbase common.c -mtune=generic -march=x86-64 -auxbase common -O2 -Wall -Werror -version -o common.s GNU C11 (Debian 7.2.0-16) version 7.2.0 (x86_64-linux-gnu) compiled by GNU C version 7.2.0, GMP version 6.1.2, MPFR version 3.1.6, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C11 (Debian 7.2.0-16) version 7.2.0 (x86_64-linux-gnu) compiled by GNU C version 7.2.0, GMP version 6.1.2, MPFR version 3.1.6, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 4f65f393f8f34cf4758c10c601ec207f common.c: In function ‘get_config_path’: common.c:29:2: error: null destination pointer [-Werror=format-truncation=] snprintf(pbuf, bufsize, "%s/.proxychains/%s", path, PROXYCHAINS_CONF_FILE); ^~~ cc1: all warnings being treated as errors If the pointer was not NULL before, and there is no char** pointer at all, there seems to be no way it could suddenly become NULL, so the error is wrong.
[Bug c/83139] error: null destination pointer [-Werror=format-truncation=] for second call with same destination pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83139 --- Comment #1 from Julian Andres Klode --- Created attachment 42702 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42702&action=edit generated .i file
[Bug tree-optimization/83128] Unable to optimize {m,c}alloc when strings builtin are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83128 --- Comment #3 from Richard Biener --- Author: rguenth Date: Fri Nov 24 09:40:40 2017 New Revision: 255136 URL: https://gcc.gnu.org/viewcvs?rev=255136&root=gcc&view=rev Log: 2017-11-24 Richard Biener PR tree-optimization/83128 * tree-ssa-sccvn.c (fully_constant_vn_reference_p): Handle STRING_CSTs. (vn_reference_lookup_3): Likewise. * gcc.dg/tree-ssa/ssa-fre-62.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-62.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug tree-optimization/83128] Unable to optimize {m,c}alloc when strings builtin are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83128 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.0 Resolution|--- |FIXED --- Comment #2 from Richard Biener --- Fixed.
[Bug fortran/83064] DO CONCURRENT inconsistent results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064 --- Comment #13 from Dominique d'Humieres --- > > I confirm that using > > > > pik = compute( low(i), high(i) ) > > pi(i) = sum(pik) > > > > gives the right result. > > > > Does it means that the 'sum' in 'sum(compute( low(i), high(i) ))' > > is not part of the parallelization? > no idea, I can't do the above, pik is not declared. As said in comment 5, real(real64), dimension(nsplit) :: pi has to be replaced with real(real64), dimension(nsplit) :: pi, pik With my limited understanding of DO CONCURRENT, do concurrent (i = 1:nsplit) body(i) end do the evaluations of 'body' for different values of 'i' are independent. I think that implied that all the temporaries generated in body have to be local.
[Bug c/83139] error: null destination pointer [-Werror=format-truncation=] for second call with same destination pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83139 --- Comment #2 from Julian Andres Klode --- Apparently, this is because check_path() is being inlined and checks that the argument is NULL. Then when it sees the second use of pbuf, it considers it possible that it is NULL. I'm not sure it's really a bug. It depends on whether it would do the same if check_path() were used elsewhere where the !pbuf check is actually important.
[Bug libstdc++/83140] New: assoc_legendre returns negated value when m is odd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83140 Bug ID: 83140 Summary: assoc_legendre returns negated value when m is odd Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: kwsm.gcc at gmail dot com Target Milestone: --- In the standard, Legendre polynomials and associated Legendre functions are defined as P_l = (1 / 2^l l!) d^l/dx^l (x^2 - 1)^l, and P_l^m = (1 - x^2)^(m/2) d^m/dx^m P_l, respectively. Then, for example, P_1^1 should be √(1 - x^2), but GCC returns -√(1 - x^2): the return value of std::assoc_legendre(1, 1, 0.5) is -0.866. GCC's implementation uses recurrence of associated Legendre function P_m^m = (-1)^m (2m - 1)!! (1 - x^2)^(m/2), but this corresponds to P_l^m = (-1)^m (1 - x^2)^(m/2) d^m/dx^m P_l. Namely, std::assoc_legendre returns negated value when m is odd.
[Bug c++/81675] [6/7/8 Regression] attribute(noreturn) of destructor in :? not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81675 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 42703 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42703&action=edit gcc8-pr81675.patch Untested fix.
[Bug rtl-optimization/81553] [7/8 Regression] ICE in immed_wide_int_const, at emit-rtl.c:607
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81553 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 42704 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42704&action=edit gcc8-pr81553.patch Untested fix.
[Bug tree-optimization/83141] New: SRA and memcpy folding interact badly generating wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83141
Bug ID: 83141
Summary: SRA and memcpy folding interact badly generating
wrong-code
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
/* { dg-do run } */
struct A { short s; long i; long j; };
struct A a, b;
void foo ()
{
struct A c;
__builtin_memcpy (&c, &b, sizeof (struct A));
__builtin_memcpy (&a, &c, sizeof (struct A));
}
int main()
{
__builtin_memset (&b, 0, sizeof (struct A));
b.s = 1;
__builtin_memcpy ((char *)&b + sizeof (short), &b, sizeof (short));
foo ();
__builtin_memcpy (&a, (char *)&a + sizeof (short), sizeof (short));
if (a.s != 1)
__builtin_abort ();
return 0;
}
[Bug bootstrap/83015] [8 regression] bootstrap comparison failure on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83015 --- Comment #19 from Jan Hubicka --- Author: hubicka Date: Fri Nov 24 11:24:55 2017 New Revision: 255138 URL: https://gcc.gnu.org/viewcvs?rev=255138&root=gcc&view=rev Log: PR bootstrap/83015 * ipa-inline.c (inline_small_functions): Set current badnes correctly when skipping checking. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c
[Bug target/81535] [8 regression] gcc.target/powerpc/pr79439.c fails starting with r250442
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81535 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Any progress with this?
[Bug bootstrap/81470] [8 Regression] Bootstrap comparison failures in gcc/ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81470 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Is this still a problem? At least on x86_64-linux many people have done many successful bootstraps with ada since then.
[Bug tree-optimization/83141] SRA and memcpy folding interact badly generating wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83141 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-11-24 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug ipa/81465] [8 Regression] ICE in estimate_edge_growth at gcc/ipa-inline.h:85 on s390x target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81465 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Any progress on this?
[Bug target/81535] [8 regression] gcc.target/powerpc/pr79439.c fails starting with r250442
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81535 --- Comment #6 from Yury Gribov --- (In reply to Jakub Jelinek from comment #5) > Any progress with this? I filed patch back then (https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01873.html) and missed reply from Segher. I'll reply to his comments in gcc-patches today.
[Bug target/81456] [7/8 Regression] x86-64 optimizer makes wrong decision when optimizing for size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81456 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Yeah, the earlier in the optimization pipeline we need to make decisions, the more approximate the cost models are, unless we have infinite compile time and compile memory resources, we can't try both alternatives with all subsequent passes and choose what is in the end better; so, before RA we can't know what the register allocation will need to do with the code. -Os certainly doesn't and can't guarantee the resulting code will be always smaller than or equal to code with -O2, what matters is whether it creates smaller code on large amounts of real-world code; so, we generally choose to do or not to do optimizations where we know they do or don't generally result in smaller code on average. You can always find counter-examples where the heuristics just doesn't handle a particular case in the end well. Not convinced we need to track each such case.
[Bug bootstrap/81470] [8 Regression] Bootstrap comparison failures in gcc/ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81470 --- Comment #3 from Rainer Emrich --- (In reply to Jakub Jelinek from comment #2) > Is this still a problem? At least on x86_64-linux many people have done > many successful bootstraps with ada since then. I will test next week, when I find the time.
[Bug lto/81406] [6/7/8 Regression] ICE in check_die, at dwarf2out.c:6185
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81406 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Can't reproduce with current trunk.
[Bug tree-optimization/82402] [6/7 Regression] error: SSA_NAME_OCCURS_IN_ABNORMAL_PHI should be set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82402 Richard Biener changed: What|Removed |Added Known to work||8.0 Summary|[6/7/8 Regression] error: |[6/7 Regression] error: |SSA_NAME_OCCURS_IN_ABNORMAL |SSA_NAME_OCCURS_IN_ABNORMAL |_PHI should be set |_PHI should be set --- Comment #8 from Richard Biener --- Fixed on trunk sofar.
[Bug c++/79008] missing detail in -Wbuiltin-declaration-mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79008
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|2017-08-22 00:00:00 |2017-11-24
Ever confirmed|0 |1
--- Comment #3 from Eric Gallager ---
(In reply to Martin Sebor from comment #2)
> I think what I had in mind was incompatible attribute specifications rather
> than missing ones but my description sounds a little confused.
> -Wbuiltin-declaration-mismatch also doesn't diagnose incompatible attributes
> (maybe it should).
>
> One example of an incompatibility is the following declaration:
>
> int __attribute__ ((pure)) abs (int);
>
> where abs() the built-in is actually declared const. GCC doesn't currently
> diagnose this except with my patch for bug 81544 (yet to be reviewed).
>
> Another, slightly different, example is declaring a standard library
> function with the wrong attributes, like this one:
>
> void* __attribute__ ((malloc, alloc_size (1))) realloc (void*, size_t);
>
> This is wrong on two counts: first, realloc cannot be declared with
> attribute malloc because it need not return a unique pointer. Second,
> alloc_size specifies the wrong argument (this is bug 78667).
>
> Since many built-in functions are decorated with multiple attributes it
> seems that rather than pointing out these kinds of issues one attribute at a
> time (either when there are more than one or as the user adjusts their
> declaration) it would be simpler and more user-friendly to include in the
> diagnostic all the attributes the built-in is decorated with. Hence the
> suggestion to introduce a a new flag (and perhaps also a conversion
> specifier) to the pretty printer to have it (optionally) print the whole
> attribute list, or parts of it.
>
> E.g.,
>
> warning ("%#qD conflicts with built-in declaration %#qD", user_decl,
> builtin_in_decl);
>
> might print
>
> warning: ‘int abs(int) __attribute__ ((pure))’ conflicts with built-in
> declaration ‘int abs(int) __attribute__ ((const))’
Confirmed.
[Bug tree-optimization/82402] [6/7 Regression] error: SSA_NAME_OCCURS_IN_ABNORMAL_PHI should be set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82402 --- Comment #9 from Richard Biener --- Author: rguenth Date: Fri Nov 24 12:34:23 2017 New Revision: 255140 URL: https://gcc.gnu.org/viewcvs?rev=255140&root=gcc&view=rev Log: 2017-11-24 Richard Biener PR tree-optimization/82402 * tree-vect-loop-manip.c (create_lcssa_for_virtual_phi): Properly set SSA_NAME_OCCURS_IN_ABNORMAL_PHI. * gcc.dg/torture/pr82402.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr82402.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop-manip.c
[Bug tree-optimization/82991] memcpy and strcpy return value can be assumed to be equal to first argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82991 --- Comment #4 from Richard Biener --- Created attachment 42705 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42705&action=edit patch Things got stuck on _b_o_s fallout. See https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02113.html and followups. Attaching what I have currently, no time to rescue things on the _b_o_s side. I think we should eventually forgo the idea that IPA inlining might help getting accurate _b_o_s results and instead rely on early optimized bodies being early inlined into contexts where the passed addresses are still in original form. Thus do everything in NEXT_PASS (pass_object_sizes, true /* insert_min_max_p */); I have yet to see a testcase from the real world where IPA inlining uncovered a bug.
[Bug tree-optimization/83142] New: Missed tail-call opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83142
Bug ID: 83142
Summary: Missed tail-call opportunity
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
The following is not tail-called even though memmove returns dest (and the
compiler knows that):
struct A { int i; int j; int k; };
void *bar (struct A *dest, struct A *src)
{
__builtin_memmove (dest, src, sizeof (struct A));
return dest;
}
[Bug tree-optimization/82991] memcpy and strcpy return value can be assumed to be equal to first argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82991
Richard Biener changed:
What|Removed |Added
Depends on||83142
--- Comment #5 from Richard Biener ---
Another concern was tail-call optimization which needs to learn that
foo (x);
return x;
can be tail-called when foo is returning the argument we return from the
function. Not too difficult to add.
We don't seem to have a testcase verifying tail-calling of memcpy or another
function returning an argument, so this is an invisible regression of the
patch.
struct A { int i; int j; int k; };
void *bar (struct A *dest, struct A *src)
{
return __builtin_memmove (dest, src, sizeof (struct A));
}
is optimized to the following at -O2 but no longer with the current patch:
bar:
.LFB0:
.cfi_startproc
movl$12, %edx
jmp memmove
the following testcase isn't optimized:
struct A { int i; int j; int k; };
void *bar (struct A *dest, struct A *src)
{
__builtin_memmove (dest, src, sizeof (struct A));
return dest;
}
both should be after a suitable fix. -> PR83142.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83142
[Bug 83142] Missed tail-call opportunity
[Bug target/83143] New: [SH]: Assembler messages: invalid operands (*UND* and .text sections) for `-'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143 Bug ID: 83143 Summary: [SH]: Assembler messages: invalid operands (*UND* and .text sections) for `-' Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de Target Milestone: --- Created attachment 42706 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42706&action=edit C source code file which causes the miscompiled code Trying to build mesa on Debian unstable (sh4) with gcc-7.2.0 fails with: (sid-sh4-sbuild)root@nofan:/build/mesa-D7X6g9/mesa-17.2.4/build# make /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) Making all in src make[1]: Entering directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src' /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) updating git_sha1.h /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) /usr/bin/make all-recursive /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) make[2]: Entering directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src' /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) Making all in . make[3]: Entering directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src' make[3]: Nothing to be done for 'all-am'. make[3]: Leaving directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src' Making all in gtest make[3]: Entering directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src/gtest' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src/gtest' Making all in util make[3]: Entering directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src/util' /usr/bin/make all-recursive /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) make[4]: Entering directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src/util' /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) Making all in . make[5]: Entering directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src/util' make[5]: Nothing to be done for 'all-am'. make[5]: Leaving directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src/util' Making all in tests/hash_table make[5]: Entering directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src/util/tests/hash_table' make[5]: Nothing to be done for 'all'. make[5]: Leaving directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src/util/tests/hash_table' make[4]: Leaving directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src/util' make[3]: Leaving directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src/util' Making all in mapi/glapi/gen make[3]: Entering directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src/mapi/glapi/gen' /usr/bin/make all-am /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) make[4]: Entering directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src/mapi/glapi/gen' make[4]: Nothing to be done for 'all-am'. make[4]: Leaving directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src/mapi/glapi/gen' make[3]: Leaving directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src/mapi/glapi/gen' Making all in mapi make[3]: Entering directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src/mapi' /usr/bin/make all-recursive /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) make[4]: Entering directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src/mapi' /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) make[5]: Entering directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src/mapi' make[5]: Nothing to be done for 'all-am'. make[5]: Leaving directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src/mapi' make[4]: Leaving directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src/mapi' make[3]: Leaving directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src/mapi' Making all in compiler make[3]: Entering directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src/compiler' /usr/bin/make all-am /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) make[4]: Entering directory '/build/mesa-D7X6g9/mesa-17.2.4/build/src/compiler' /bin/bash ../../libtool --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"Mesa\" -DPACKAGE_TARNAME=\"mesa\" -DPACKAGE_VERSION=\"17.2.4\" -DPACKAGE_STRING=\"Mesa\ 17.2.4\" -DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi\?product=Mesa\"; -DPACKAGE_URL=\"\" -DPACKAGE=\"mesa\" -DVERSION=\"17.2.4\" -D_FILE_OFFSET_BITS=64 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE___BUILTIN_BSWAP32=1 -DHAVE___BUILTIN_BSWAP64=1 -DHAVE___BUILTIN_CLZ=1 -DHAVE___BUILTIN_CLZLL=1 -DHAVE___BUILTIN_CTZ=1 -DHAVE___BUILTIN_EXPECT=1 -DH
[Bug target/83143] [SH]: Assembler messages: invalid operands (*UND* and .text sections) for `-'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143 --- Comment #1 from John Paul Adrian Glaubitz --- Created attachment 42707 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42707&action=edit Intermediate source for nir_lower_int64.c
[Bug target/83143] [SH]: Assembler messages: invalid operands (*UND* and .text sections) for `-'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143 --- Comment #2 from John Paul Adrian Glaubitz --- Created attachment 42708 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42708&action=edit Generated assembly for nir_lower_int64.c (gzipped)
[Bug tree-optimization/83141] SRA and memcpy folding interact badly generating wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83141 --- Comment #2 from Richard Biener --- https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02199.html regresses gfortran.dg/pr45636.f90 because Jakubs pattern matching in tree-ssa-forwprop.c:simplify_builtin_call no longer applies ... (we fold more memcpy calls).
[Bug c++/83144] New: ICE using trailing return type and constexpr with GCC 7.X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83144 Bug ID: 83144 Summary: ICE using trailing return type and constexpr with GCC 7.X Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: joel.falcou at lri dot fr Target Milestone: --- Created attachment 42709 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42709&action=edit ICE using trailing return type and constexpr with GCC 7.X ICE using trailing return type and constexpr with GCC 7.X This is easily worked-around but clang and g++ 5.4 compile it without issues.
[Bug target/83143] [SH]: Assembler messages: invalid operands (*UND* and .text sections) for `-'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143 --- Comment #3 from John Paul Adrian Glaubitz --- Created attachment 42710 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42710&action=edit Generated object for nir_lower_int64.c
[Bug target/83143] [SH]: Assembler messages: invalid operands (*UND* and .text sections) for `-'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143 --- Comment #4 from John Paul Adrian Glaubitz --- Building with "-O0" instead of "-O2" resolves the issue.
[Bug ipa/81465] [8 Regression] ICE in estimate_edge_growth at gcc/ipa-inline.h:85 on s390x target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81465
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #6 from Jan Hubicka ---
The testcase no longer reproduces and we test that there is no inline clone in
same comdat group:
212982 marxin if (global.inlined_to && same_comdat_group)
186998hubicka {
186998hubicka error ("inline clone in same comdat group list");
186998hubicka error_found = true;
186998hubicka }
This address comment #3. Comment #2 was fixed by not estimating growth in this
case.
[Bug sanitizer/82802] Potential UBSAN error with pointer difference (32-bits mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82802 --- Comment #3 from Marc Glisse --- This seems fixed on trunk, and impossible to backport.
[Bug ipa/81360] [8 Regression] ice in estimate_edge_growth, at ipa-inline.h:86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81360 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jan Hubicka --- Fixed.
[Bug bootstrap/83015] [8 regression] bootstrap comparison failure on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83015 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #20 from Jan Hubicka --- Fixed.
[Bug target/83143] [SH]: Assembler messages: invalid operands (*UND* and .text sections) for `-'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143 --- Comment #5 from John Paul Adrian Glaubitz --- It's fixed by adding "-freorder-blocks-algorithm=simple" which overrides "-freorder-blocks-algorithm=stc" from "-O2".
[Bug fortran/81304] [6/7/8 Regression] Bogus warning with -Wsurprising and -fopenmp: Type specified for intrinsic function 'min' / 'max'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81304 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 42711 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42711&action=edit gcc8-pr81304.patch Untested fix.
[Bug target/81363] [8 regression] FAIL: gcc.dg/vect/pr51581-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81363 Jakub Jelinek changed: What|Removed |Added CC||carll at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- This went away with r250295 which reverted some earlier commit. Was the patch reverted because of this LRA ICE, or for some other reason. I.e. can we close it as RESOLVED/FIXED, or is there a plan to reapply the patch eventually and something we should get RA folks involved in?
[Bug c++/83145] New: Ambiguous overload with templates, only GCC7 C++17 mode (regression?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83145
Bug ID: 83145
Summary: Ambiguous overload with templates, only GCC7 C++17
mode (regression?)
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: l.lunak at centrum dot cz
Target Milestone: ---
The following code produces an ambiguous overload error only with GCC7 in C++17
mode. GCC6 is fine, GCC7 in C++14 mode is fine, Clang5 is fine, MSVC2015/2017
are fine. It would seem to me that the first overload is more specific and thus
should be the one selected.
==
template
class Variant {
};
class BinaryOutputStream {
};
template
BinaryOutputStream& operator<<(BinaryOutputStream& stream, const
Variant& /*variant*/) {
return stream;
}
template class
TCollection,
typename T,
typename TAllocator,
typename TCounter>
BinaryOutputStream& operator<<(BinaryOutputStream& ostream, const
TCollection& /*arr*/) {
return ostream;
}
int main()
{
Variant variant;
BinaryOutputStream stream;
stream << variant;
return 0;
}
=
$ g++-7 -Wall -Wextra a.cpp -c -std=gnu++17
a.cpp: In function ‘int main()’:
a.cpp:25:12: error: ambiguous overload for ‘operator<<’ (operand types are
‘BinaryOutputStream’ and ‘Variant’)
stream << variant;
~~~^~
a.cpp:9:21: note: candidate: BinaryOutputStream&
operator<<(BinaryOutputStream&, const Variant&) [with TValues =
{float, int, char}]
BinaryOutputStream& operator<<(BinaryOutputStream& stream, const
Variant& /*variant*/) {
^~~~
a.cpp:17:21: note: candidate: BinaryOutputStream&
operator<<(BinaryOutputStream&, const TCollection&)
[with TCollection = Variant; T = float; TAllocator = int; TCounter = char]
BinaryOutputStream& operator<<(BinaryOutputStream& ostream, const
TCollection& /*arr*/) {
^~~~
$ g++-7 -Wall -Wextra a.cpp -c -std=gnu++14
$ g++-6 -Wall -Wextra a.cpp -c -std=gnu++17
$ clang++ -Wall -Wextra a.cpp -c -std=gnu++17
$ g++-7 -v
Using built-in specs.
COLLECT_GCC=g++-7
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=hsa:nvptx-none
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,fortran,ada,go
--enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, --without-cuda-driver
--enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/7 --enable-ssp --disable-libssp
--disable-libvtv --disable-libcc1 --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--with-default-libstdcxx-abi=gcc4-compatible
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-7 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux
Thread model: posix
gcc version 7.1.1 20170607 [gcc-7-branch revision 248970] (SUSE Linux)
[Bug c++/80792] worse code generated compared to clang when using std::tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80792 --- Comment #3 from Marc Glisse --- It seems that clang have fixed their ABI to generate code similar to gcc. Any objection to closing this?
[Bug target/82248] probe_stack can generate unpredictable STR on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82248 --- Comment #5 from rguenther at suse dot de --- On Thu, 23 Nov 2017, ramana at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82248 > > --- Comment #3 from Ramana Radhakrishnan --- > (In reply to Richard Biener from comment #2) > > Miscompiles mpfr for us on armv7. Isn't it easy enough to handle this in > > the insn pattern by using some non pre/post-indexed memory_operand predicate > > and or using an early clobbered match_scratch to allocate 'r0'? > > > I was testing a patch that used 'o' instead of 'm' in the constraint as that's > just an offsettable address and would prevent post/ pre-inc type operations > but > it slipped through the cracks with travels in September :( > > Can you test if that is sufficient for you or what's the runes in configure > for > forcing probe_stack_range ? Seems to work fine. Richard.
[Bug c++/83145] Ambiguous overload with templates, only GCC7 C++17 mode (regression?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83145 --- Comment #1 from Jonathan Wakely --- This is affected by the -fnew-ttp-matching option, which is enabled by default for C++17 and disabled otherwise. You get the same error with C++14 if you use -fnew-tpp-matching, and it compiles with C++17 and -fno-new-ttp-matching I think the C++17 standard requires the new behaviour, so this isn't a bug.
[Bug c++/83145] Ambiguous overload with templates, only GCC7 C++17 mode (regression?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83145 --- Comment #2 from Jonathan Wakely --- The new rule was introduced by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0522r0.html
[Bug c++/83136] static class template member: invalid application of ‘sizeof’ to incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83136
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-11-24
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
Reduced:
namespace std
{
using size_t = decltype(sizeof(0));
template
struct aligned_storage
{
struct type {
alignas(A) char _data[N];
};
};
template
using aligned_storage_t = typename aligned_storage::type;
}
template
struct Storage
{
std::aligned_storage_t data[N];
};
template
struct PoolObj
{
static void* operator new(std::size_t)
{
return &T::pool.data[0];
}
static void operator delete(void*, std::size_t)
{
}
};
template
struct Bar : PoolObj>
{
static Storage, 10> pool;
};
template
Storage, 10> Bar::pool {};
int main()
{
Bar* b = new Bar();
delete b;
}
Clang and EDG accept it.
[Bug target/83143] [SH]: Assembler messages: invalid operands (*UND* and .text sections) for `-'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143 Oleg Endo changed: What|Removed |Added CC||segher at kernel dot crashing.org --- Comment #6 from Oleg Endo --- (In reply to John Paul Adrian Glaubitz from comment #2) > Created attachment 42708 [details] > Generated assembly for nir_lower_int64.c (gzipped) In the asm code I see the following line ... .L3195: .long nir_alu_instr_create@PLT-(.LPCS230+2-.) ... but the label .LPCS230 does not not exist in the file. So I guess this is where the error comes from. But no idea why the label is not there. AFAIR Segher did some stuff for block reordering. Maybe he's got any clue.
[Bug target/83133] Superflous x86 test instructions in generated assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #1 from Uroš Bizjak --- (In reply to Maxim Egorushkin from comment #0) > g function assembly contains a superflous test instruction. It should not > generate that instruction, since sub instruction already sets all the > required flags. I first discovered this issue in gcc-4.9.2 and it is still > there in gcc-7.2.0. SUBL also sets overflow flat (OF). JLE in fact jumps when (ZF=1 or SF≠OF), so assuming OF is always cleared is waaay to dangerous. As a matter of fact, flag-setting cmp/sub/add patterns can be changed to operate in CCNOmode instead of CCGOCmode when strict signed overflow rules are in effect (in C/C++ signed overflow is undefined, so we CAN assume signed overflow never happens and consequently flag OF is never set), but it would be major PITA on x86 architecture, where plus and minus operations on signed integers always overflow "as expected". (BTW: I did implement the above idea, but compiler failed bootstrap comparison check. I'm surprised clang was brave enough to implement this dangerous optimization.)
[Bug tree-optimization/71026] Missing division optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71026 --- Comment #10 from Wilco --- Author: wilco Date: Fri Nov 24 16:03:13 2017 New Revision: 255141 URL: https://gcc.gnu.org/viewcvs?rev=255141&root=gcc&view=rev Log: Factor out division by squares This patch implements the some of the division optimizations discussed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71026. The division reciprocal optimization now handles divisions by squares: x / (y * y) -> x * (1 / y) * (1 / y) This requires at least one more division by y before it triggers - the 3 divisions of (1/ y) are then CSEd into a single division. Overall this changes 1 division into 1 multiply, which is generally much faster. 2017-11-24 Jackson Woodruff gcc/ PR tree-optimization/71026 * tree-ssa-math-opts (is_division_by_square, is_square_of): New. (insert_reciprocals): Change to insert reciprocals before a division by a square and to insert the square of a reciprocal. (execute_cse_reciprocals_1): Change to consider division by a square. (register_division_in): Add importance parameter. testsuite/ PR tree-optimization/71026 * gfortran.dg/extract_recip_1.f: New test. * gcc.dg/extract_recip_3.c: New test. * gcc.dg/extract_recip_4.c: New test. Added: trunk/gcc/testsuite/gcc.dg/extract_recip_3.c trunk/gcc/testsuite/gcc.dg/extract_recip_4.c trunk/gcc/testsuite/gfortran.dg/extract_recip_1.f Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-math-opts.c
[Bug tree-optimization/32306] [6/7/8 Regression] redundant && || not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306 --- Comment #36 from Jeffrey A. Law --- Just a couple notes. I'm not currently looking at this, but this is probably the best bug to track thoughts around how to try and capture secondary effects of jump threading without re-running all of DOM. -- Taken from another BZ so that it doesn't get lost -- I looked at ways to introduce iteration without the full DOM pass years ago. It was pretty obvious that the most interesting things happened as a result of exposing degenerate PHIs. But I wasn't ever able to make a leap from that to a low overhead iterating jump threader. What did come out of it was the phi-only cprop pass which propagates away the degenerate PHIs. -- And today's thought. In addition to degenerate PHIs the other key property which indicates an exposed secondary opportunity is a reduction in the number of preds for a block. Particularly when we can drop from N to 1 pred. ssa--dom-simplify-1 is a good example, particularly if one disables the VRP threader. Prior to DOM we'll see: ;; basic block 2, loop depth 0, count 1073741825 (estimated locally), maybe hot ;;prev block 0, next block 3, flags: (NEW, REACHABLE, VISITED) ;;pred: ENTRY [always] count:1073741826 (estimated locally) (FALLTHRU,EXECUTABLE) if (x_3(D) > 3) goto ; [33.00%] else goto ; [67.00%] ;;succ: 3 [33.0% (guessed)] count:354334800 (estimated locally) (TRUE_VALUE,EXECUTABLE) ;;4 [67.0% (guessed)] count:719407025 (estimated locally) (FALSE_VALUE,EXECUTABLE) ;; basic block 3, loop depth 0, count 354334802 (estimated locally), maybe hot ;;prev block 2, next block 4, flags: (NEW, REACHABLE, VISITED) ;;pred: 2 [33.0% (guessed)] count:354334800 (estimated locally) (TRUE_VALUE,EXECUTABLE) frob (1); ;;succ: 4 [always (guessed)] count:354334802 (estimated locally) (FALLTHRU,EXECUTABLE) ;; basic block 4, loop depth 0, count 1073741825 (estimated locally), maybe hot ;;prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED) ;;pred: 3 [always (guessed)] count:354334802 (estimated locally) (FALLTHRU,EXECUTABLE) ;;2 [67.0% (guessed)] count:719407025 (estimated locally) (FALSE_VALUE,EXECUTABLE) if (x_3(D) > 2) goto ; [33.00%] else goto ; [67.00%] ;;succ: 5 [33.0% (guessed)] count:354334800 (estimated locally) (TRUE_VALUE,EXECUTABLE) ;;6 [67.0% (guessed)] count:719407025 (estimated locally) (FALSE_VALUE,EXECUTABLE) ;; basic block 5, loop depth 0, count 354334802 (estimated locally), maybe hot ;;prev block 4, next block 6, flags: (NEW, REACHABLE, VISITED) ;;pred: 4 [33.0% (guessed)] count:354334800 (estimated locally) (TRUE_VALUE,EXECUTABLE) frob (x_3(D)); ;;succ: 6 [always (guessed)] count:354334802 (estimated locally) (FALLTHRU,EXECUTABLE) ;; basic block 6, loop depth 0, count 1073741825 (estimated locally), maybe hot ;;prev block 5, next block 1, flags: (NEW, REACHABLE, VISITED) ;;pred: 4 [67.0% (guessed)] count:719407025 (estimated locally) (FALSE_VALUE,EXECUTABLE) ;;5 [always (guessed)] count:354334802 (estimated locally) (FALLTHRU,EXECUTABLE) return; ;;succ: EXIT [always (guessed)] count:1073741825 (estimated locally) } DOM is going to discover the 3->4->5 jump thread easily.But there are no PHIs in BB4 that would trigger any kind of reanalysis. But the # preds for BB4 drops from 2 to 1. This is important as the remaining path into BB4 can be further optimized after we realize the 3->4->5 jump thread. It feels as if when we discover a degenerate PHI or the incoming preds drops to 1, then we ought to start a re-analysis. The blocks involved would start at the idom of the affected block, covering the dominance tree and the PHI nodes as the dominance frontier. I thought I explored that idom/dominance tree/dominance frontier idea years ago and likely dismissed it as incomplete (consider how scrambled the dominance tree can get after threading). But while I could certainly conjure up scenarios where it's incomplete, it might be "good enough" to catch the secondary opportunities without a fully iterating DOM. -- Of course I'm also very interested to evaluate if any of that is necessary with Aldy's recent work on the backwards threader.
[Bug fortran/83146] New: ICE on SELECT CASE statement with associate name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83146 Bug ID: 83146 Summary: ICE on SELECT CASE statement with associate name Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- The current 8.0 trunk gives an ICE on the following example. 6.4.1 also gives an ICE. type foo integer n end type type bar type(foo) array(2) end type type(bar) b associate (n_array => b%array%n) select case (n_array(1)) case default end select end associate end Here's the traceback $ gfortran -c gfortran-20171124.f90 gfortran-20171124.f90:9:0: select case (n_array(1)) internal compiler error: in gfc_get_element_type, at fortran/trans-types.c:1231 0x5a5da8 gfc_get_element_type(tree_node*) ../../gcc/fortran/trans-types.c:1231 0x95d247 trans_associate_var ../../gcc/fortran/trans-stmt.c:1632 0x95d247 gfc_trans_block_construct(gfc_code*) ../../gcc/fortran/trans-stmt.c:1890 0x8e48c7 trans_code ../../gcc/fortran/trans.c:1924 0x90e7a8 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6437 0x89d036 translate_all_program_units ../../gcc/fortran/parse.c:6091 0x89d036 gfc_parse_file() ../../gcc/fortran/parse.c:6294 0x8e0eaf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug target/83133] Superflous x86 test instructions in generated assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #2 from Maxim Egorushkin --- (In reply to Uroš Bizjak from comment #1) > (In reply to Maxim Egorushkin from comment #0) > > g function assembly contains a superflous test instruction. It should not > > generate that instruction, since sub instruction already sets all the > > required flags. I first discovered this issue in gcc-4.9.2 and it is still > > there in gcc-7.2.0. > > SUBL also sets overflow flat (OF). JLE in fact jumps when (ZF=1 or SF≠OF), > so assuming OF is always cleared is waaay to dangerous. > > As a matter of fact, flag-setting cmp/sub/add patterns can be changed to > operate in CCNOmode instead of CCGOCmode when strict signed overflow rules > are in effect (in C/C++ signed overflow is undefined, so we CAN assume > signed overflow never happens and consequently flag OF is never set), but it > would be major PITA on x86 architecture, where plus and minus operations on > signed integers always overflow "as expected". > > (BTW: I did implement the above idea, but compiler failed bootstrap > comparison check. I'm surprised clang was brave enough to implement this > dangerous optimization.) Could you provide an example where that "dangerous optimization" would break well-formed code please?
[Bug target/83133] Superflous x86 test instructions in generated assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #3 from Uroš Bizjak ---
(In reply to Maxim Egorushkin from comment #2)
> Could you provide an example where that "dangerous optimization" would break
> well-formed code please?
--cut here--
#include
void positive (int a) { printf ("positive: %i\n", a); }
void nonpositive (int a) { printf ("nonpositive: %i\n", a); }
void
__attribute__((noinline))
g (int a, int b)
{
int diff = a - b;
if (diff > 0)
return positive (diff);
else
return nonpositive (diff);
}
int
main ()
{
int a = -0x8000;
int b = 0x01;
g (a, b);
return 0;
}
--cut here--
$ gcc -O2 ttt.c
$ ./a.out
positive: 2147483647
$ gcc -O0 ttt.c
$ ./a.out
positive: 2147483647
$ clang -O2 ttt.c
$ ./a.out
nonpositive: 2147483647 <- HERE!
$ clang -O0 ttt.c
$ ./a.out
positive: 2147483647
[Bug target/83133] Superflous x86 test instructions in generated assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #4 from Uroš Bizjak --- $ gcc --version gcc (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2) Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ clang --version clang version 4.0.1 (tags/RELEASE_401/final) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin
[Bug target/83133] Superflous x86 test instructions in generated assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #5 from joseph at codesourcery dot com --- Both 32-bit and 64-bit ABIs make the values of flags in EFLAGS (other than DF) undefined on function entry and return. Thus, a function can never assume anything about the value of OF unless it has executed an instruction known to set/clear it and has not called any other functions since then.
[Bug fortran/83146] ICE on SELECT CASE statement with associate name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83146 --- Comment #1 from Neil Carlson --- I thought that assigning the select case expression to a temporary integer and using that variable in the select case statement would be a workaround, but no. You can put anything unrelated to the associate name in the select case and you still get an ICE. It seems the the associate block itself is the problem. Here's the tweaked example type foo integer n end type type bar type(foo) array(2) end type type(bar) b integer :: m=0 associate (n_array => b%array%n) select case (m) case default end select end associate end
[Bug target/83133] Superflous x86 test instructions in generated assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #6 from Maxim Egorushkin ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Maxim Egorushkin from comment #2)
>
> > Could you provide an example where that "dangerous optimization" would break
> > well-formed code please?
>
> --cut here--
> #include
>
> void positive (int a) { printf ("positive: %i\n", a); }
> void nonpositive (int a) { printf ("nonpositive: %i\n", a); }
>
> void
> __attribute__((noinline))
> g (int a, int b)
> {
> int diff = a - b;
>
> if (diff > 0)
> return positive (diff);
> else
> return nonpositive (diff);
> }
>
> int
> main ()
> {
> int a = -0x8000;
> int b = 0x01;
>
> g (a, b);
>
> return 0;
> }
> --cut here--
>
> $ gcc -O2 ttt.c
> $ ./a.out
> positive: 2147483647
>
> $ gcc -O0 ttt.c
> $ ./a.out
> positive: 2147483647
>
> $ clang -O2 ttt.c
> $ ./a.out
> nonpositive: 2147483647 <- HERE!
>
> $ clang -O0 ttt.c
> $ ./a.out
> positive: 2147483647
This code underflows a signed integer, which is undefined behaviour, if I am
not mistaken. So, this would not be a valid example, would it?
[Bug rtl-optimization/82621] [6/7 Regression] wrong code with -Og -fgcse -fweb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82621 --- Comment #8 from Segher Boessenkool --- Author: segher Date: Fri Nov 24 17:00:57 2017 New Revision: 255142 URL: https://gcc.gnu.org/viewcvs?rev=255142&root=gcc&view=rev Log: combine: Don't split insns if half is unused (PR82621) If we have a PARALLEL of two SETs, and one half is unused, we currently happily split that into two instructions (albeit the unused one is useless). Worse, as PR82621 shows, combine will happily merge this insn into I3 even if some intervening insn sets the same register again, which is wrong. This fixes it by not splitting PARALLELs with REG_UNUSED notes. It all is handled fine by combine in that case; just the "single set that is unused" case isn't handled properly. This also results in better code: combine will now actually throw away the unused SET. (It still won't do that in an I3). PR rtl-optimization/82621 * combine.c (try_combine): Do not split PARALLELs of two SETs if the dest of one of those SETs is unused. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/combine.c
[Bug rtl-optimization/82621] [6/7 Regression] wrong code with -Og -fgcse -fweb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82621 --- Comment #9 from Segher Boessenkool --- Author: segher Date: Fri Nov 24 17:03:04 2017 New Revision: 255143 URL: https://gcc.gnu.org/viewcvs?rev=255143&root=gcc&view=rev Log: combine: Don't split insns if half is unused (PR82621) If we have a PARALLEL of two SETs, and one half is unused, we currently happily split that into two instructions (albeit the unused one is useless). Worse, as PR82621 shows, combine will happily merge this insn into I3 even if some intervening insn sets the same register again, which is wrong. This fixes it by not splitting PARALLELs with REG_UNUSED notes. It all is handled fine by combine in that case; just the "single set that is unused" case isn't handled properly. This also results in better code: combine will now actually throw away the unused SET. (It still won't do that in an I3). PR rtl-optimization/82621 * combine.c (try_combine): Do not split PARALLELs of two SETs if the dest of one of those SETs is unused. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/combine.c
[Bug rtl-optimization/82621] [6/7 Regression] wrong code with -Og -fgcse -fweb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82621 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Segher Boessenkool --- Fixed on all open branches.
[Bug target/83133] Superflous x86 test instructions in generated assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #7 from joseph at codesourcery dot com --- On Fri, 24 Nov 2017, maxim.yegorushkin at gmail dot com wrote: > This code underflows a signed integer, which is undefined behaviour, if I am > not mistaken. So, this would not be a valid example, would it? It's valid to call a function in another file compiled with another compiler that follows the ABI, or compiled with -fwrapv, or not written in C at all. The ABI means you can't assume anything about what a called function does with OF, unless you know the function is called from the same translation unit and know that it has been compiled to do particular things with OF, and can't assume anything about the value of OF on entry, unless it's a static function and you know about what all the callers do.
[Bug target/83133] Superflous x86 test instructions in generated assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #8 from Uroš Bizjak --- (In reply to jos...@codesourcery.com from comment #5) > Both 32-bit and 64-bit ABIs make the values of flags in EFLAGS (other than > DF) undefined on function entry and return. Thus, a function can never > assume anything about the value of OF unless it has executed an > instruction known to set/clear it and has not called any other functions > since then. In the testcase, there is nothing that violates ABI. It all happens in "g" that passes calculated result to a function. Selected function depends on flags, calculated from the subtraction, and wrong function gets selected when overflow happens.
[Bug fortran/83146] ICE on SELECT CASE statement with associate name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83146 --- Comment #2 from Neil Carlson --- Turns out you don't need anything at all in the associate block to get an ICE: type foo integer n end type type bar type(foo) array(2) end type type(bar) b associate (n_array => b%array%n) end associate end
[Bug debug/81307] [8 regression] g++.dg/debug/debug9.C -gstabs FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81307 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 42712 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42712&action=edit gcc8-pr81307.patch Untested fix.
[Bug target/83133] Superflous x86 test instructions in generated assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #10 from Maxim Egorushkin --- (In reply to Uroš Bizjak from comment #8) > (In reply to jos...@codesourcery.com from comment #5) > > Both 32-bit and 64-bit ABIs make the values of flags in EFLAGS (other than > > DF) undefined on function entry and return. Thus, a function can never > > assume anything about the value of OF unless it has executed an > > instruction known to set/clear it and has not called any other functions > > since then. > > In the testcase, there is nothing that violates ABI. Not sure why ABI got involved here. > It all happens in "g" > that passes calculated result to a function. Selected function depends on > flags, calculated from the subtraction, and wrong function gets selected > when overflow happens. The underflow happens as a result of that subtraction. That underflow leads to UB. In the case of UB, both gcc and clang behaviours are valid. The clang behaviour is one instruction cheaper though.
[Bug target/83133] Superflous x86 test instructions in generated assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #9 from Uroš Bizjak --- (In reply to Maxim Egorushkin from comment #6) > This code underflows a signed integer, which is undefined behaviour, if I am > not mistaken. So, this would not be a valid example, would it? An example of "dangerous optimization" from Comment #2 was requested. The optimization is valid, but this code happens as well. As shown in the example, the program, compiled with clang declared 2147483647 as nonpositive when compiled with -O2 and as positive when compiled with -O0. We can sweep the issue under the carpet as "undefined behaviour", but I don't want to jeopardize the robustness of an industrial-strength compiler with the implementation of this relatively minor optimization.
[Bug rtl-optimization/81288] [6/7/8 Regression] ICE on 32-bit BE powerpc targets -w -misel -O2 (-O3, -Ofast, -Os)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81288 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org
[Bug target/83133] Superflous x86 test instructions in generated assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #12 from Maxim Egorushkin --- (In reply to jos...@codesourcery.com from comment #7) > On Fri, 24 Nov 2017, maxim.yegorushkin at gmail dot com wrote: > > > This code underflows a signed integer, which is undefined behaviour, if I am > > not mistaken. So, this would not be a valid example, would it? > > It's valid to call a function in another file compiled with another > compiler that follows the ABI, or compiled with -fwrapv, or not written in > C at all. That amounts to saying that the extra test instruction should only be emitted when compiling with -fwrapv. Is that right?
[Bug target/83133] Superflous x86 test instructions in generated assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #11 from Maxim Egorushkin --- (In reply to jos...@codesourcery.com from comment #7) > On Fri, 24 Nov 2017, maxim.yegorushkin at gmail dot com wrote: > > > This code underflows a signed integer, which is undefined behaviour, if I am > > not mistaken. So, this would not be a valid example, would it? > > It's valid to call a function in another file compiled with another > compiler that follows the ABI, or compiled with -fwrapv, or not written in > C at all. That amounts to saying that the extra test instruction should only be emitted when compiling with -fwrapv. Is that right?
[Bug target/83133] Superflous x86 test instructions in generated assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #13 from Maxim Egorushkin --- (In reply to Uroš Bizjak from comment #9) > (In reply to Maxim Egorushkin from comment #6) > > > This code underflows a signed integer, which is undefined behaviour, if I am > > not mistaken. So, this would not be a valid example, would it? > > An example of "dangerous optimization" from Comment #2 was requested. The > optimization is valid, but this code happens as well. As shown in the > example, the program, compiled with clang declared 2147483647 as nonpositive > when compiled with -O2 and as positive when compiled with -O0. > > We can sweep the issue under the carpet as "undefined behaviour", but I > don't want to jeopardize the robustness of an industrial-strength compiler > with the implementation of this relatively minor optimization. It looks like -fstrict-overflow flag is there to enable exactly this kind of optimization.
[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213 --- Comment #24 from Neil Carlson --- Ping. This bug has been around for over 6 years now.
[Bug target/83133] Superflous x86 test instructions in generated assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #14 from Uroš Bizjak --- (In reply to Maxim Egorushkin from comment #13) > It looks like -fstrict-overflow flag is there to enable exactly this kind of > optimization. Yes, and it is set by default. Meaning that ALL code has to be reviewed for undefined overflows just because of this optimization.
[Bug target/83133] Superflous x86 test instructions in generated assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #15 from Marc Glisse --- Gcc's RTL internal representation sees the same thing for your code and for int diff = (unsigned)a - (unsigned)b; llvm represents both differently and generates different code for the two.
[Bug target/83133] Superflous x86 test instructions in generated assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #16 from joseph at codesourcery dot com --- On Fri, 24 Nov 2017, maxim.yegorushkin at gmail dot com wrote: > > It's valid to call a function in another file compiled with another > > compiler that follows the ABI, or compiled with -fwrapv, or not written in > > C at all. > > That amounts to saying that the extra test instruction should only be emitted > when compiling with -fwrapv. Is that right? No. It's valid for a function compiled without -fwrapv to call one compiled with -fwrapv. After such a call, the value of OF is unknown. That is, there is no need for any undefined behavior for OF to be set after a function call, and there is no need for any undefined behavior for OF to be set on function entry, and a function cannot know whether its caller or callees were compiled in ways that allow them to set OF. It's *also* perfectly valid for code with no undefined behavior and no -fwrapv to set OF if an instruction that happens to set OF happens to be the most convenient way of implementing that code's semantics.
[Bug target/83133] Superflous x86 test instructions in generated assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #17 from Uroš Bizjak --- (In reply to Marc Glisse from comment #15) > Gcc's RTL internal representation sees the same thing for your code and for > > int diff = (unsigned)a - (unsigned)b; > > llvm represents both differently and generates different code for the two. GCC represents unsigned comparison with LTU and signed with LT. This optimization can be implemented by changing condition of *sub_2 pattern from: ix86_match_ccmode (insn, CCGOCmode) to ix86_match_ccmode (insn, flag_wrapv ? CCGOCmode : CCNOmode)
[Bug target/83133] Superflous x86 test instructions in generated assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #18 from joseph at codesourcery dot com --- On Fri, 24 Nov 2017, ubizjak at gmail dot com wrote: > In the testcase, there is nothing that violates ABI. It all happens in "g" > that > passes calculated result to a function. Selected function depends on flags, > calculated from the subtraction, and wrong function gets selected when > overflow > happens. Thanks for the explanation. As long as the transformation is local (relying on an OF value that definitely comes from a particular instruction that would clear it in the absence of overflow, not relying on other computations not having overflowed), using it should be valid, provided you take into account that RTL has no undefined behavior on signed overflow (flag_wrapv only affects GIMPLE semantics, not RTL semantics), so the flag can only be used when instruction semantics for when it is set are consistent with the RTL semantics for the comparison. What's not valid is using sticky overflow flags such as exist in some instruction sets.
[Bug rtl-optimization/83147] New: LRA inheritance undo on multiple sets problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83147
Bug ID: 83147
Summary: LRA inheritance undo on multiple sets problem
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
Created attachment 42713
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42713&action=edit
Autoreduced testcase
Compiling the attached testcase with:
gcc -march=z196 -m64 -mzarch -O2 -o t.s t.cc
produces the following sequence:
...
stmg%r2,%r3,160(%r15)
ltg %r2,184(%r15)<--- read from uninitialized memory
lghi%r3,0
ltg %r1,168(%r15)
lghi%r1,1
locgre %r2,%r1
...
This currently makes bootstrap with "--with-arch=z196" fail on S/390.
The ltg instruction is a load and test being a parallel of a compare and a set
using the same source operand (272r.ira):
(insn 122 62 48 6 (parallel [
(set (reg:CCZ 33 %cc)
(compare:CCZ (subreg:DI (reg:TI 100 [ width+-8 ]) 8)
(const_int 0 [0])))
(set (reg:DI 118 [ nbwc ])
(subreg:DI (reg:TI 100 [ width+-8 ]) 8))
]) 1213 {*tstdi_extimm}
(expr_list:REG_UNUSED (reg:CCZ 33 %cc)
(nil)))
LRA generates an inheritance reload replacing both occurrences of the source
operand r100 with r132 (273r.reload):
<<
Creating newreg=132 from oldreg=100, assigning class GENERAL_REGS to
inheritance r132
Original reg change 100->132 (bb6):
122: {%cc:CCZ=cmp(r132:TI#8,0);r118:DI=r132:TI#8;}
REG_UNUSED %cc:CCZ
Add inheritance<-original before:
162: r132:TI=r100:TI
Inheritance reuse change 100->132 (bb6):
158: r129:DI=r132:TI#8
REG_DEAD r132:TI
And another one for r100 stacking on top of the first:
163: r133=r100
162: r132=r133
122: use r132
<<
Creating newreg=133 from oldreg=100, assigning class GENERAL_REGS to
inheritance r133
Original reg change 100->133 (bb5):
41: r78:DI=r133:TI#8
Add inheritance<-original before:
163: r133:TI=r100:TI
Inheritance reuse change 100->133 (bb6):
162: r132:TI=r133:TI
The inheritance undo code then tries to replace r132 in insn 122 with r133.
Unfortunately it only replaces one of the source operands.
The reason is that the target of the first part of the parallel (the cmp) is
REG_UNUSED and hence single_set ignores it and returns just the second part of
the insn. The code then operates on the source operand return by single_set
(lra-constraint.c:6698):
if (GET_CODE (SET_SRC (set)) == SUBREG)
SUBREG_REG (SET_SRC (set)) = SET_SRC (prev_set);
else
SET_SRC (set) = SET_SRC (prev_set);
The replacement perhaps needs to be done recursively to get all the sources?
** Undoing inheritance #2: **
Inherit 3 out of 4 (75.00%)
Insn after restoring regs:
158: r129:DI=r100:TI#8
REG_DEAD r100:TI
Change reload insn:
122: {%cc:CCZ=cmp(r132:TI#8,0);r118:DI=r133:TI#8;}< 2 different
sources
REG_UNUSED %cc:CCZ
Insn after restoring regs:
162: r100:TI=r133:TI
REG_DEAD r133:TI
[Bug rtl-optimization/83147] LRA inheritance undo on multiple sets problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83147 --- Comment #1 from Andreas Krebbel --- Created attachment 42714 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42714&action=edit Experimental patch This patch appears to fix the problem for me. However, it isn't really tested yet.
[Bug rtl-optimization/83147] LRA inheritance undo on multiple sets problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83147 Andreas Krebbel changed: What|Removed |Added Keywords||wrong-code Target||s390x-ibm-linux Priority|P3 |P2 Host||s390x-ibm-linux Build||s390x-ibm-linux
[Bug fortran/83146] [6/7/8 Regression] ICE on SELECT CASE statement with associate name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83146 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||4.8.5 Keywords||ice-on-valid-code Last reconfirmed||2017-11-24 Ever confirmed|0 |1 Summary|ICE on SELECT CASE |[6/7/8 Regression] ICE on |statement with associate|SELECT CASE statement with |name|associate name Target Milestone|--- |6.5 Known to fail||4.9.3, 5.5.0, 6.4.0, 7.2.0, ||8.0 --- Comment #3 from Dominique d'Humieres --- Regression occurring between revisions r205210 (2013-11-21, OK) and r207996 (2014-02-21, ICE).
[Bug fortran/83135] Routines in submodules treat protected variables from other modules as public
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83135 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-24 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 6.4 up to trunk (8.0).
[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213 --- Comment #25 from Neil Carlson --- Here's another example similar to those above but even simpler IMHO and involving a CLASS(*) pointer component type box class(*), pointer :: uptr => null() end type integer, target :: n call sub(box(n)) contains subroutine sub(b) type(box), intent(in) :: b end subroutine end call sub(box(n)) 1 Error: Can't convert INTEGER(4) to CLASS(*) at (1) This should work in F2003. GFortran seems to be fundamentally broken when it comes to derived types with polymorphic pointer components and intrinsic structure constructors.
[Bug c/81875] omp for loop optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81875 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug target/83133] Superflous x86 test instructions in generated assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133 --- Comment #19 from Marc Glisse --- (In reply to Uroš Bizjak from comment #17) > (In reply to Marc Glisse from comment #15) > > Gcc's RTL internal representation sees the same thing for your code and for > > > > int diff = (unsigned)a - (unsigned)b; > > > > llvm represents both differently and generates different code for the two. > > GCC represents unsigned comparison with LTU and signed with LT. Above I only used unsigned for the subtraction, not for the comparison. This was a way to explain to Maxim that in RTL, we have lost the information that an overflow would be undefined behavior. Expansion is currently the last chance we get to use the GIMPLE information about overflow. Otherwise, we would need to find a way in RTL to represent this overflow behavior (say that it sets OF to false, but we are already using a parallel to say it sets CCGOC so I don't know how we would spell that). By the way, writing ab instead of diff<0 or diff>0 doesn't help, it actually hurts gcc. I thought we had a pass to merge adjacent subtraction and comparison of the same numbers...
[Bug fortran/83148] New: [7.2 regression] ICE: crash_signal from toplev.c:325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83148 Bug ID: 83148 Summary: [7.2 regression] ICE: crash_signal from toplev.c:325 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- The following example gives an ICE with the current 8.0 trunk, but not with 7.2.1 or 6.4.1. module fhypre use iso_c_binding, only: c_ptr, c_null_ptr use iso_c_binding, only: hypre_obj => c_ptr, hypre_null_obj => c_null_ptr private public :: hypre_obj, hypre_null_obj end module module hypre_hybrid_type use fhypre type hypre_hybrid type(hypre_obj) :: solver = hypre_null_obj end type hypre_hybrid end module Here's the traceback $ gfortran -c gfortran-20171124c.f90 f951: internal compiler error: Segmentation fault 0xd6b98f crash_signal ../../gcc/toplev.c:325 0xfb33fd tree_class_check(tree_node const*, tree_code_class, char const*, int, char const*) ../../gcc/tree.h:3480 0xfb33fd wi::from_mpz(tree_node const*, __mpz_struct*, bool) ../../gcc/wide-int.cc:244 0x900284 gfc_conv_mpz_to_tree(__mpz_struct*, int) ../../gcc/fortran/trans-const.c:205 0x9008bf gfc_conv_constant(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-const.c:413 0x922b91 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc/fortran/trans-expr.c:6833 0x9231ad gfc_conv_structure(gfc_se*, gfc_expr*, int) ../../gcc/fortran/trans-expr.c:7748 0x922cdf gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc/fortran/trans-expr.c:6883 0x90a78b gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.c:1819 0x90d340 gfc_create_module_variable ../../gcc/fortran/trans-decl.c:4943 0x8cf472 do_traverse_symtree ../../gcc/fortran/symbol.c:4157 0x910193 gfc_generate_module_vars(gfc_namespace*) ../../gcc/fortran/trans-decl.c:5415 0x8e88fc gfc_generate_module_code(gfc_namespace*) ../../gcc/fortran/trans.c:2180 0x89cf7b translate_all_program_units ../../gcc/fortran/parse.c:6078 0x89cf7b gfc_parse_file() ../../gcc/fortran/parse.c:6294 0x8e0eaf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug target/83100] [8 Regression] powerpc: internal compiler error: in get_variable_section, at varasm.c:1150 with -fdata-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83100 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||law at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- That change looks wrong to me. Previously the variable was common and thus if you e.g. mixed it with some other TU that has const int a = 5; then you could link the two together and the value of the variable would be 5. But with the changes, that is no longer the case (if it doesn't ICE), the variable is put into .rodata section.
[Bug target/83100] [8 Regression] powerpc: internal compiler error: in get_variable_section, at varasm.c:1150 with -fdata-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83100
--- Comment #5 from Jakub Jelinek ---
I'll test:
--- gcc/varasm.c.jj 2017-11-21 20:23:02.0 +0100
+++ gcc/varasm.c2017-11-24 21:43:55.616951823 +0100
@@ -986,9 +986,9 @@ decode_reg_name (const char *name)
bool
bss_initializer_p (const_tree decl)
{
- /* Do not put constants into the .bss section, they belong in a readonly
- section. */
- return (!TREE_READONLY (decl)
+ /* Do not put non-common constants into the .bss section, they belong in
+ a readonly section. */
+ return ((!TREE_READONLY (decl) || DECL_COMMON (decl))
&& (DECL_INITIAL (decl) == NULL
/* In LTO we have no errors in program; error_mark_node is used
to mark offlined constructors. */
after cooking up a testcase.
