[Bug debug/83480] [8 Regression] ICE in create_block_for_bookkeeping, at sel-sched.c:4557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83480 --- Comment #11 from Jakub Jelinek --- Not fully fixed yet, the testcase still ICEs with: -O2 -g -gstatement-frontiers -fselective-scheduling2 -fsel-sched-pipelining -fgcse-sm -floop-parallelize-all -fno-tree-loop-im
[Bug rtl-optimization/83682] [8 Regression] ICE in simplify_subreg, at simplify-rtx.c:6296
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83682 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug debug/83480] [8 Regression] ICE in create_block_for_bookkeeping, at sel-sched.c:4557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83480
--- Comment #10 from Jakub Jelinek ---
Author: jakub
Date: Sat Jan 6 07:48:31 2018
New Revision: 256309
URL: https://gcc.gnu.org/viewcvs?rev=256309&root=gcc&view=rev
Log:
PR debug/83480
* toplev.c (process_options): Don't enable debug_nonbind_markers_p
by default if flag_selective_schedling{,2}. Formatting fixes.
* gcc.dg/pr83480.c: New test.
Added:
trunk/gcc/testsuite/gcc.dg/pr83480.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/toplev.c
[Bug debug/83694] [8 Regression] New test case gcc.dg/pr83666.c from r256232 ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83694 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug rtl-optimization/83682] [8 Regression] ICE in simplify_subreg, at simplify-rtx.c:6296
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83682 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Sat Jan 6 07:47:32 2018 New Revision: 256308 URL: https://gcc.gnu.org/viewcvs?rev=256308&root=gcc&view=rev Log: PR rtl-optimization/83682 * rtl.h (const_vec_duplicate_p): Only return true for VEC_DUPLICATE if it has non-VECTOR_MODE element mode. (vec_duplicate_p): Likewise. * gcc.target/i386/pr83682.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr83682.c Modified: trunk/gcc/ChangeLog trunk/gcc/rtl.h trunk/gcc/testsuite/ChangeLog
[Bug debug/83694] [8 Regression] New test case gcc.dg/pr83666.c from r256232 ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83694 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Sat Jan 6 07:46:39 2018 New Revision: 256307 URL: https://gcc.gnu.org/viewcvs?rev=256307&root=gcc&view=rev Log: PR middle-end/83694 * cfgexpand.c (expand_debug_expr): Punt if mode1 is VOIDmode and bitsize might be greater than MAX_BITSIZE_MODE_ANY_INT. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c
[Bug middle-end/83711] GNU GCC version in geraphviz dot data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83711 Andrew Pinski changed: What|Removed |Added Component|c |middle-end --- Comment #1 from Andrew Pinski --- Complete patches should be sent to gcc-patc...@gcc.gnu.org. Please read https://gcc.gnu.org/contribute.html about how to submit a patch.
[Bug c/83711] New: GNU GCC version in geraphviz dot data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83711
Bug ID: 83711
Summary: GNU GCC version in geraphviz dot data
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mooigraph at users dot sourceforge.net
Target Milestone: ---
It would be better to have the GCC version info in the graphviz dot data
generated with options -fdump-rtl-all-graph and -fdump-tree-all-graph.
Here is a trivial patch to add that similar as GNU Bison has it.
in graph.c
/* Start the dump of a graph. */
static void
start_graph_dump (FILE *fp, const char *base)
{
pretty_printer graph_slim_pp;
graph_slim_pp.buffer->stream = fp;
pretty_printer *const pp = &graph_slim_pp;
pp_printf (pp, "// Generated by GNU GCC version %s.\n", version_string);
pp_printf (pp, "// Report bugs to <%s>.\n",bug_report_url);
pp_printf (pp, "// Home page: <%s>.\n", "https://gcc.gnu.org";);
pp_string (pp, "digraph \"");
pp_write_text_to_stream (pp);
pp_string (pp, base);
pp_write_text_as_dot_label_to_stream (pp, /*for_record=*/false);
pp_string (pp, "\" {\n");
pp_string (pp, "overlap=false;\n");
pp_flush (pp);
}
Then the generated data looks like this:
// Generated by GNU GCC version 8.0.0 20171231 (experimental).
// Report bugs to <.
digraph "rhp.c.088t.fixup_cfg4" {
overlap=false;
subgraph "cluster_rhp_version" {
style="dashed";
color="black";
...
voila.
[Bug c++/83710] New: Unsigned with Signed multiplication followed by right shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83710
Bug ID: 83710
Summary: Unsigned with Signed multiplication followed by right
shift
Product: gcc
Version: 6.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chanpreet.singh at nxp dot com
Target Milestone: ---
Hello,
For a multiplication between signed and unsigned, I expect the 'sign' of the
result to be same as 'sign' of the signed number. But in following case it does
not happen. Looks like a bug to me!
##
#include
#include
#include
#include
#include
#include
// sample code
int main () {
int a = -1;
unsigned intb = 5;
int c ;
c = (a * b)>>1;
std::cout << "c=" << c << " (0x" << std::hex << c << ")" << std::endl;
return 1;
}
--
Output:
c=2147483645 (0x7ffd)
##
I am expecting the output to be -3!
The assembly code generated has two arithmetic instructions: imull (signed
multiply), and shrl (shift right without sign extension) for x86. While I am
expecting the shift instructions to be arithmetic shift right (with sign
extension).
g++ test.cpp -S
---
call__main
movl$-1, -4(%rbp)
movl$5, -8(%rbp)
movl-4(%rbp), %eax
imull -8(%rbp), %eax
shrl%eax
movl%eax, -12(%rbp)
---
Same holds true for long int.
[Bug libstdc++/83709] New: Inserting duplicates into an unordered associative containers causes the container to invalidate iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83709 Bug ID: 83709 Summary: Inserting duplicates into an unordered associative containers causes the container to invalidate iterators Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: david.mrobinson at yahoo dot com Target Milestone: --- Created attachment 43049 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43049&action=edit Demonstrates unordered_set changing its order when no element is added According to the C++11-C++17 draft standards unordered associative containers (unordered_set, unordered_map, unordered_multiset, unordered_multimap) may only invalidate iterators when a non-duplicate element is inserted into them. N4659 (C++17 Draft) 26.2.7 [unord.req] states: "14 The insert and emplace members shall not affect the validity of references to container elements, but may invalidate all iterators to the container. The erase members shall invalidate only iterators and references to the erased elements, and preserve the relative order of the elements that are not erased. 15 The insert and emplace members shall not affect the validity of iterators if (N+n) <= z * B, where N is the number of elements in the container prior to the insert operation, n is the number of elements inserted, B is the container’s bucket count, and z is the container’s maximum load factor." In table 91 a_uniq.insert(t) states: "Effects: Inserts t if and only if there is no element in the container with key equivalent to the key of t" Based on the definition in table 91 of insert, in 26.2.7.15 inserted means that an element must be added to the container for it to actually count as being inserted, adding duplicates does not count. In 26.2.7.15 "n" is the number of elements actually added to the container, not the number of elements insert is called with. Therefore, the current implementation of libstdc++ is in violation of the standard as it invalidates iterators when adding only duplicates. See the attachment for a short program that demonstrates that unordered_set changes the order of its elements when inserting only duplicates. The output of the program should be: Starting Order: T, e, Ending Order: e, T Build command: g++ -v -save-temps main.cpp Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.2.0-8ubuntu3' --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 (Ubuntu 7.2.0-8ubuntu3) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/7/cc1plus -E -quiet -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE main.cpp -mtune=generic -march=x86-64 -fpch-preprocess -fstack-protector-strong -Wformat -Wformat-security -o main.ii ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/7" 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/include/c++/7 /usr/include/x86_64-linux-gnu/c++/7 /usr/include/c++/7/backward /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='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/7/cc1plus -fpreprocessed main.ii -quiet -dumpbase main.cpp -mtune=generic -march=x86-64 -auxbase main -version -fstack-protector-strong -Wformat -Wformat-security -o main.s GNU C++14 (Ubuntu 7.2.0-8ubuntu3) version 7.2.0 (x86_64-linux-gnu) compile
[Bug tree-optimization/79224] [7/8 Regression] Large C-Ray slowdown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79224 --- Comment #19 from Aldy Hernandez --- In my sandbox I see no discernible difference between GCC 6 and current mainline (r256265). I am testing with: ./xgcc -B./ -O3 -ffast-math -funroll-loops -march=core-avx2 -lm c-ray-f.c cat ~/scene | ./a.out -s 5000x4000 >/dev/null The numbers for GCC 6 and mainline are pretty close. I ran each version 4 times on a Linux box under runlevel 3 (no X). The average is: Mainline: 5048 milliseconds GCC 6:5059 milliseconds I am testing on: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz If y'all agree with my tests, should we close this PR?
[Bug c/83559] [8 regression] -Wsuggest-attribute=const conflicts with -Wattributes warning about const attribute on function returning void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83559 --- Comment #6 from Martin Sebor --- The GCC manual says that "It does not make sense for a const function to return void" so I would tend to think of the suggestion as a bug. With that, I would recommend either disabling -Wsuggest-attribute=const when the definition of the function is being compiled by an older version of GCC, or conditionally adding a const declaration of the void function into the source file (not the header) just for the older compilers.
[Bug c/83708] New: Token-based policy broken by __VA_OPT__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83708 Bug ID: 83708 Summary: Token-based policy broken by __VA_OPT__ Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: woong.jun at gmail dot com Target Milestone: --- Use of __VA_OPT__ can break the token-based policy when those optional tokens do not come from arguments. $ cat > foo.c __VERSION__ #define foo(...) __VA_OPT__(foo)__VA_OPT__(bar) foo(dummy) $ gcc -E foo.c # 1 "foo.c" # 1 "" # 1 "" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 1 "" 2 # 1 "foo.c" "8.0.0 20180105 (experimental)" foobar
[Bug fortran/83704] pr31243 revisited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704 --- Comment #2 from Dominique d'Humieres --- > Is this with or without Janne's library side patch? with or without.
[Bug fortran/83704] pr31243 revisited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- (In reply to Dominique d'Humieres from comment #0) > Revision r256284 makes the request in pr31243 obsolete for 64-bit mode. > > On the positive side, -fcheck=bounds now works for the test in comment 9. > > On the negative side, the following test compiles now but its behavior at > run time is not the one I expect: > --- snip --- Is this with or without Janne's library side patch?
[Bug target/83707] New: memcmp inline expansion causing g++.dg/eh/simd-3.C to fail on power7 -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83707 Bug ID: 83707 Summary: memcmp inline expansion causing g++.dg/eh/simd-3.C to fail on power7 -m32 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: acsawdey at gcc dot gnu.org Reporter: acsawdey at gcc dot gnu.org Target Milestone: --- Target: ppc32 power7 This is apparently due to the inline expansion code that went into gcc7. Haven't looked into what is going on yet but hopefully an easy fix. Code looks like this: .L8: bl abort .L6: bl __cxa_begin_catch bl __cxa_end_catch lis 9,.LANCHOR0@ha la 9,.LANCHOR0@l(9) li 10,512 stxvw4x 63,9,10 addi 7,9,512 lis 6,.LANCHOR1@ha la 8,.LANCHOR1@l(6) lwz 10,512(9) lwz 9,.LANCHOR1@l(6) subfc. 9,9,10 bne 0,.L7 lwz 10,4(7) lwz 9,4(8) subfc. 9,9,10 bne 0,.L7 lwz 10,8(7) lwz 9,8(8) subfc. 9,9,10 bne 0,.L7 lwz 10,12(7) lwz 9,12(8) subfc 9,9,10 .L7: subfe 10,10,10 popcntw 9,9 or. 9,9,10 bne 0,.L8
[Bug ipa/83179] [8 regression] gcc.dg/ipa/inline-1.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83179 --- Comment #13 from seurer at gcc dot gnu.org --- Sorry, that's r256279.
[Bug ipa/83179] [8 regression] gcc.dg/ipa/inline-1.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83179 --- Comment #12 from seurer at gcc dot gnu.org --- r256779 seems to have cleared up the inline-c.c test case failures (at least on powerpc64) but it causes a couple other tests to fail. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83706
[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83633 --- Comment #4 from Nathan T. Weeks --- Fortran 2008 appears to have tightened restrictions on explicit-shape arrays in the main program and made this particular case illegal (per section 5.3.8.2 "Explicit-shape array"): C531 (R516) An explicit-shape-spec whose bounds are not constant expressions shall appear only in a subprogram, derived type definition, BLOCK construct, or interface body.
[Bug ipa/83706] New: [8 regression] gcc.dg/ipa/inline-2.c and gcc.dg/ipa/inline-3.c fail starting with r256279
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83706 Bug ID: 83706 Summary: [8 regression] gcc.dg/ipa/inline-2.c and gcc.dg/ipa/inline-3.c fail starting with r256279 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Saw this on powerpc64 both LE and BE. The revision caused some previously failing test cases to now succeed but some different ones to start failing. Previously it was like this: Running /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/ipa/ipa.exp ... FAIL: gcc.dg/ipa/inline-1.c scan-ipa-dump inline "op2 change 9.99. of time" FAIL: gcc.dg/ipa/inline-1.c scan-ipa-dump inline "op3 change 9.99. of time" FAIL: gcc.dg/ipa/inline-1.c scan-ipa-dump inline "op4 change 9.99. of time" FAIL: gcc.dg/ipa/inline-1.c scan-ipa-dump inline "op5 change 9.99. of time" With this revision those tests now pass but these fail: Running /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/ipa/ipa.exp ... FAIL: gcc.dg/ipa/inline-2.c scan-ipa-dump inline "op2 change 10.00. of time" FAIL: gcc.dg/ipa/inline-3.c scan-ipa-dump inline "Scaling time by probability:0.10"
[Bug libstdc++/83626] std::experimental::filesystem::remove_all throws exception instead of returning 0 if path doesn't exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83626 --- Comment #9 from Jonathan Wakely --- Author: redi Date: Fri Jan 5 23:51:22 2018 New Revision: 256301 URL: https://gcc.gnu.org/viewcvs?rev=256301&root=gcc&view=rev Log: PR libstdc++/83626 simplify filesystem::remove and filesystem::remove_all PR libstdc++/83626 * src/filesystem/ops.cc (remove(const path&, error_code&)): Remove unnecessary symlink_status call. (remove_all(const path&, error_code&)): Use filesystem::remove. * src/filesystem/std-ops.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/filesystem/ops.cc trunk/libstdc++-v3/src/filesystem/std-ops.cc
[Bug fortran/83704] pr31243 revisited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704 Dominique d'Humieres changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-05 Ever confirmed|0 |1
[Bug fortran/83705] [8 Regression] ICE/wrong code with large values of REPEAT after revision r256284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83705 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||7.2.0 Keywords||ice-on-valid-code, ||wrong-code Last reconfirmed||2018-01-05 Ever confirmed|0 |1 Summary|[8 Regression] ICE with |[8 Regression] ICE/wrong |large values of REPEAT |code with large values of |after revision r256284 |REPEAT after revision ||r256284 Known to fail||8.0
[Bug fortran/83705] New: [8 Regression] ICE with large values of REPEAT after revision r256284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83705
Bug ID: 83705
Summary: [8 Regression] ICE with large values of REPEAT after
revision r256284
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: dominiq at lps dot ens.fr
CC: jb at gcc dot gnu.org
Target Milestone: ---
The following variant of the second test at
https://gcc.gnu.org/ml/fortran/2017-12/msg00132.html
program main
integer(8), parameter :: n=2_8**28 - 1_8
character(len=*), parameter :: a1 = repeat('x',n)
end program main
compiles with gfortran 7.2.0 and trunk before r256284.
If I replace 2_8**28 - 1_8 with 2_8**28, I get the following ICE
f951(30823,0x7fff9211a340) malloc: *** mach_vm_map(size=18446744073441116160)
failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
f951: out of memory allocating 18446744073441116160 bytes after a total of 0
bytes
If I compile the test with an instrumented compiler (r256049), I get
../../p_work/gcc/fortran/trans-const.c:100:17: runtime error: signed integer
overflow: 8 * 268435456 cannot be represented in type 'int'
(with an earlier revision I also got
../../p_work/gcc/fortran/target-memory.c:71:17: runtime error: signed integer
overflow: 1073741824 * 8 cannot be represented in type ‘int’
)
With an instrumented version of r256284 I got
../../work/gcc/fortran/decl.c:1748:37: runtime error: member access within null
pointer of type 'struct gfc_expr'
for 'n' as small as 2_8**23 + 1_8. I think it is due to the patch
- nlen = ncop * len;
+ gfc_charlen_t nlen = ncop * len;
+
+ /* Here's a semi-arbitrary limit. If the string is longer than 32 MB
+ (8 * 2**20 elements * 4 bytes (wide chars) per element) defer to
+ runtime instead of consuming (unbounded) memory and CPU at
+ compile time. */
+ if (nlen > 8388608)
+return NULL;
which makes sense for variables, but IMO not for parameters.
If I revert this patch, the following test
program main
integer(8), parameter :: n=2_8**32
character(len=n) :: a1 = repeat('x',n)
character(len=3) :: a2, a3
print *, len(a1, kind=8)
a2 = a1(1:3)
a3 = a1(n-2:n)
print *, "'", a2, "', '", a3, "'"
end program main
! https://gcc.gnu.org/ml/fortran/2017-12/msg00132.html
compiles and gives at run time
4294967296
'', ''
Note the empty strings a2 and a3.
With the patch reverted the test gfortran.dg/repeat_7.f90 gives
f951: out of memory allocating 18446744073709551615 bytes after a total of 0
bytes
as well as the first test in this comment with n=2_8**28 (while it compiles
with n=2_8**32).
For n=2_8**28, my instrumented compiler reports
../../work/gcc/fortran/trans-const.c:100:17: runtime error: signed integer
overflow: 8 * 268435456 cannot be represented in type 'int'
[Bug tree-optimization/79224] [7/8 Regression] Large C-Ray slowdown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79224 Aldy Hernandez changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org --- Comment #18 from Aldy Hernandez --- (In reply to Jeffrey A. Law from comment #17) > Aldy, this might be a good one to look at as well -- mostly to see if Jan's > changes in combination with those from Yuri fixed the regression. Ok. I'm taking the PR while I poke at it. No promises, though :).
[Bug middle-end/83684] [8 Regression] ICE in maybe_diag_overlap, at gimple-ssa-warn-restrict.c:1371
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83684 Matthias Klose changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #2 from Matthias Klose --- yes, not seen anymore with r256272
[Bug target/83285] non-atomic stores can removed with seq_cst (and store release) on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83285 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #2 from Steve Ellcey --- This may be fixed on top-of-tree (though I don't know what change might have fixed it). If I build with ToT (8.0 prelease I see all three stores: Example from commoent #1 compiled with -O3: % more x.s .arch armv8-a .file "x.c" .text .align 2 .p2align 3,,7 .global _Z7seq_cstRiRSt6atomicIiE .type _Z7seq_cstRiRSt6atomicIiE, %function _Z7seq_cstRiRSt6atomicIiE: .LFB342: .cfi_startproc mov w2, 1 str w2, [x0] mov w2, 2 stlrw2, [x1] mov w1, 3 str w1, [x0] ret .cfi_endproc .LFE342: .size _Z7seq_cstRiRSt6atomicIiE, .-_Z7seq_cstRiRSt6atomicIiE .ident "GCC: (GNU) 8.0.0 20180105 (experimental)" .section.note.GNU-stack,"",@progbits
[Bug fortran/83704] New: pr31243 revisited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704 Bug ID: 83704 Summary: pr31243 revisited Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: jb at gcc dot gnu.org Target Milestone: --- Revision r256284 makes the request in pr31243 obsolete for 64-bit mode. On the positive side, -fcheck=bounds now works for the test in comment 9. On the negative side, the following test compiles now but its behavior at run time is not the one I expect: subroutine foo(i) integer(kind=8), intent(in) :: i character(len=i) :: x print *, i print *, len(x, kind=8) end subroutine foo program main character (len=2_8**32_8+4_8) :: ch character (len=4) :: a1, a2 ch = '123456789' a1 = ch(1:4) ch(2_8**32_8:2_8**32_8+3_8) = 'abcd' a2 = ch(2_8**32_8:2_8**32_8+4_8) print *, "'",a1,"', '",a2,"'" print *, "'", ch(1:2_8**32_8+3_8), "'" print *, len(ch, kind=8) print *, len(ch(1:2_8**32_8+3_8), kind=8) call foo(2_8**32_8+4_8) end program main The output is '1234', 'abcd' '123' 4294967300 4294967299 Illegal instruction i.e., print *, "'", ch(1:2_8**32_8+3_8), "'" prints only the first three characters of the 'ch' substring and not the entire substring. In addition, if I comment the line print *, len(x, kind=8) the Illegal instruction is no longer present in the output '1234', 'abcd' '123' 4294967300 4294967299 4294967300
[Bug libstdc++/83600] std::match_results C++14 conformance issue: iterators not equal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83600 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to fail||6.4.0, 7.2.0 --- Comment #6 from Jonathan Wakely --- Fixed for 6.5 and 7.3
[Bug libstdc++/83598] std::basic_regex C++14 conformance issue: resulting flags != passed flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83598 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to fail||6.4.0, 7.2.0 --- Comment #7 from Jonathan Wakely --- Fixed for 6.5 and 7.3
[Bug libstdc++/79283] read_symlink fails with /proc symlinks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79283 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.5 --- Comment #4 from Jonathan Wakely --- Fixed for 6.5 and 7.3
[Bug libstdc++/83279] std::experimental::filesystem::copy_file can't copy larger files than 2.0GiB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83279 --- Comment #22 from Jonathan Wakely --- Author: redi Date: Fri Jan 5 22:47:50 2018 New Revision: 256296 URL: https://gcc.gnu.org/viewcvs?rev=256296&root=gcc&view=rev Log: PR libstdc++/83279 handle sendfile not copying entire file Backport from mainline 2017-12-14 Jonathan Wakely PR libstdc++/83279 * src/filesystem/std-ops.cc (do_copy_file): Handle sendfile not copying entire file. Modified: branches/gcc-6-branch/libstdc++-v3/ChangeLog branches/gcc-6-branch/libstdc++-v3/src/filesystem/ops.cc
[Bug libstdc++/83279] std::experimental::filesystem::copy_file can't copy larger files than 2.0GiB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83279 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to fail||6.4.0, 7.2.0 --- Comment #23 from Jonathan Wakely --- fixed for 6.5 and 7.3
[Bug libstdc++/83600] std::match_results C++14 conformance issue: iterators not equal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83600 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Fri Jan 5 22:48:00 2018 New Revision: 256298 URL: https://gcc.gnu.org/viewcvs?rev=256298&root=gcc&view=rev Log: PR libstdc++/83600 fix end iterator for unready std::match_results Backport from mainline 2017-12-27 Jonathan Wakely PR libstdc++/83600 * include/bits/regex.h (match_results::end()): Return valid iterator when not ready. * testsuite/28_regex/match_results/ctors/char/default.cc: Check that unready objects are empty and have equal begin and end iterators. * testsuite/28_regex/match_results/ctors/wchar_t/default.cc: Likewise. Modified: branches/gcc-6-branch/libstdc++-v3/ChangeLog branches/gcc-6-branch/libstdc++-v3/include/bits/regex.h branches/gcc-6-branch/libstdc++-v3/testsuite/28_regex/match_results/ctors/char/default.cc branches/gcc-6-branch/libstdc++-v3/testsuite/28_regex/match_results/ctors/wchar_t/default.cc
[Bug libstdc++/83598] std::basic_regex C++14 conformance issue: resulting flags != passed flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83598 --- Comment #6 from Jonathan Wakely --- Author: redi Date: Fri Jan 5 22:47:54 2018 New Revision: 256297 URL: https://gcc.gnu.org/viewcvs?rev=256297&root=gcc&view=rev Log: PR libstdc++/83598 don't modify flags passed to std::basic_regex constructors Backport from mainline 2017-12-27 Jonathan Wakely PR libstdc++/83598 * include/bits/regex.h (basic_regex): Don't modify flags passed to constructors. * testsuite/28_regex/basic_regex/ctors/83598.cc: New test. Added: branches/gcc-6-branch/libstdc++-v3/testsuite/28_regex/basic_regex/ctors/83598.cc Modified: branches/gcc-6-branch/libstdc++-v3/ChangeLog
[Bug libstdc++/79283] read_symlink fails with /proc symlinks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79283 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Fri Jan 5 22:47:42 2018 New Revision: 256294 URL: https://gcc.gnu.org/viewcvs?rev=256294&root=gcc&view=rev Log: PR libstdc++/79283 fix filesystem::read_symlink for /proc Backport from mainline 2017-10-25 Jonathan Wakely PR libstdc++/79283 * src/filesystem/ops.cc (read_symlink): Handle st_size being zero. Modified: branches/gcc-6-branch/libstdc++-v3/ChangeLog branches/gcc-6-branch/libstdc++-v3/src/filesystem/ops.cc
[Bug libstdc++/83279] std::experimental::filesystem::copy_file can't copy larger files than 2.0GiB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83279 --- Comment #21 from Jonathan Wakely --- Author: redi Date: Fri Jan 5 22:22:12 2018 New Revision: 256290 URL: https://gcc.gnu.org/viewcvs?rev=256290&root=gcc&view=rev Log: PR libstdc++/83279 handle sendfile not copying entire file Backport from mainline 2017-12-14 Jonathan Wakely PR libstdc++/83279 * src/filesystem/std-ops.cc (do_copy_file): Handle sendfile not copying entire file. Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/src/filesystem/ops.cc
[Bug libstdc++/83598] std::basic_regex C++14 conformance issue: resulting flags != passed flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83598 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Fri Jan 5 22:22:17 2018 New Revision: 256291 URL: https://gcc.gnu.org/viewcvs?rev=256291&root=gcc&view=rev Log: PR libstdc++/83598 don't modify flags passed to std::basic_regex constructors Backport from mainline 2017-12-27 Jonathan Wakely PR libstdc++/83598 * include/bits/regex.h (basic_regex): Don't modify flags passed to constructors. * testsuite/28_regex/basic_regex/ctors/83598.cc: New test. Added: branches/gcc-7-branch/libstdc++-v3/testsuite/28_regex/basic_regex/ctors/83598.cc Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/include/bits/regex.h
[Bug libstdc++/83600] std::match_results C++14 conformance issue: iterators not equal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83600 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Fri Jan 5 22:22:28 2018 New Revision: 256292 URL: https://gcc.gnu.org/viewcvs?rev=256292&root=gcc&view=rev Log: PR libstdc++/83600 fix end iterator for unready std::match_results Backport from mainline 2017-12-27 Jonathan Wakely PR libstdc++/83600 * include/bits/regex.h (match_results::end()): Return valid iterator when not ready. * testsuite/28_regex/match_results/ctors/char/default.cc: Check that unready objects are empty and have equal begin and end iterators. * testsuite/28_regex/match_results/ctors/wchar_t/default.cc: Likewise. Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/include/bits/regex.h branches/gcc-7-branch/libstdc++-v3/testsuite/28_regex/match_results/ctors/char/default.cc branches/gcc-7-branch/libstdc++-v3/testsuite/28_regex/match_results/ctors/wchar_t/default.cc
[Bug target/83335] [8 regression][aarch64,ilp32] gcc.target/aarch64/asm-2.c ICEs since 255481
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83335 --- Comment #3 from Steve Ellcey --- Proposed patch https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00348.html
[Bug libstdc++/83626] std::experimental::filesystem::remove_all throws exception instead of returning 0 if path doesn't exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83626 --- Comment #8 from Jonathan Wakely --- Good point.
[Bug libstdc++/83279] std::experimental::filesystem::copy_file can't copy larger files than 2.0GiB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83279 --- Comment #20 from Jonathan Wakely --- Author: redi Date: Fri Jan 5 21:43:56 2018 New Revision: 256289 URL: https://gcc.gnu.org/viewcvs?rev=256289&root=gcc&view=rev Log: PR libstdc++/83279 Use non-null offset argument for sendfile PR libstdc++/83279 * src/filesystem/std-ops.cc (do_copy_file): Use non-null offset with sendfile. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/filesystem/std-ops.cc
[Bug libstdc++/83626] std::experimental::filesystem::remove_all throws exception instead of returning 0 if path doesn't exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83626 --- Comment #7 from Andrew Gunnerson --- Regarding the ENOENT fix above, it should no longer be necessary to call synlink_status() in fs::remove(). All cases are already handled without that check. https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/src/filesystem/ops.cc;h=3690fb94d63d7031dfef08eca17d0ca65a521122;hb=5310392950a93a58fb59a6f659d01137c4b682ec#l1020
[Bug libstdc++/79283] read_symlink fails with /proc symlinks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79283 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Fri Jan 5 21:27:20 2018 New Revision: 256286 URL: https://gcc.gnu.org/viewcvs?rev=256286&root=gcc&view=rev Log: PR libstdc++/79283 fix filesystem::read_symlink for /proc Backport from mainline 2017-10-25 Jonathan Wakely PR libstdc++/79283 * src/filesystem/ops.cc (read_symlink): Handle st_size being zero. Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/src/filesystem/ops.cc
[Bug libstdc++/83626] std::experimental::filesystem::remove_all throws exception instead of returning 0 if path doesn't exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83626 --- Comment #6 from Jonathan Wakely --- Author: redi Date: Fri Jan 5 21:27:25 2018 New Revision: 256287 URL: https://gcc.gnu.org/viewcvs?rev=256287&root=gcc&view=rev Log: PR libstdc++/83626 Don't report errors when removing non-existent files Backport from mainline 2018-01-05 Jonathan Wakely PR libstdc++/83626 * src/filesystem/ops.cc (remove(const path&, error_code&)): Do not report an error for ENOENT. (remove_all(const path&)): Fix type of result variable. (remove_all(const path&, error_code&)): Use non-throwing increment for directory iterator. Call POSIX remove directly to avoid redundant calls to symlink_status. Do not report errors for ENOENT. * testsuite/experimental/filesystem/operations/remove_all.cc: Test throwing overload. Backport from mainline 2018-01-04 Jonathan Wakely PR libstdc++/83626 * src/filesystem/ops.cc (remove(const path&, error_code&))): Remove redundant call to ec.clear(). (remove_all(const path&, error_code&))): Do not return an error for non-existent paths. * testsuite/experimental/filesystem/operations/remove.cc: New test. * testsuite/experimental/filesystem/operations/remove_all.cc: Fix expected results for non-existent paths. Added: branches/gcc-7-branch/libstdc++-v3/testsuite/experimental/filesystem/operations/remove.cc - copied, changed from r256286, branches/gcc-7-branch/libstdc++-v3/testsuite/experimental/filesystem/operations/remove_all.cc Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/src/filesystem/ops.cc branches/gcc-7-branch/libstdc++-v3/testsuite/experimental/filesystem/operations/remove_all.cc
[Bug c/83703] New: Loop termination condition ignored in -O3, works in -O2 or with smaller values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83703
Bug ID: 83703
Summary: Loop termination condition ignored in -O3, works in
-O2 or with smaller values
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: freddie_chopin at op dot pl
Target Milestone: ---
Example code:
-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
#include
#include
const int32_t limit {359};
const int32_t in[]
{
599,
600,
601,
1199,
1200,
1201,
1799,
1800,
1801,
2599,
2600,
};
const int32_t out[]
{
0,
0,
1,
1,
1,
2,
2,
2,
3,
3,
3,
};
int main()
{
for (int32_t b1 = -limit; b1 < limit; ++b1)
{
for (int32_t b0 = -limit; b0 < limit; ++b0)
{
for (int32_t a0 = -limit; a0 < limit; ++a0)
{
if (a0 == 0)
continue;
int fail = 0;
for (size_t i {}; i < sizeof(out) / sizeof(*out) && fail == 0; ++i)
{
fail |= (b1 * in[i] + b0) / a0 != out[i];
}
if (fail == 0)
{
printf("success! %i %i %i\n", (int)b1, (int)b0, (int)a0);
return 0;
}
}
}
printf("fail! %i\n", (int)b1);
}
return 0;
}
-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
This code works as intended when compiled with -O2 - last iteration of the
outer loop is with b1 == 358. However when compiled with -O3, the outer's loop
condition is completely ignored - the loop passes well above the value of
`limit` and continues infinitely. Increasing the value of `limit` gives exactly
the same result.
This fails:
$ gcc -O3 reg.cpp -Wall -Wextra && ./a.out
fail! -359
fail! -358
...
fail! 964
fail! 965
^C
$
This works:
$ gcc -O2 reg.cpp -Wall -Wextra && ./a.out
fail! -359
fail! -358
...
fail! 357
fail! 358
$
When I change `limit` to 358, at -O3 there is only ONE iteration.
$ gcc -O3 reg.cpp -Wall -Wextra && ./a.out
fail! -358
$
When I change `limit` to 357, the program works as intended at -O3. Any value
lower and it's the same
$ gcc --version
gcc (GCC) 7.2.1 20171128
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.
Tested on two PCs with Arch Linux, but both are actually mostly identical in
h/w and s/w.
[Bug fortran/50892] Internal compiler error: in gimplify_expr, at gimplify.c:7477
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50892
--- Comment #9 from Janne Blomqvist ---
Following r256284 (PR 78534) the original testcase ICE's. Interestingly, the
reduced testcases in #c2 and #c3 work fine.
The patch below fixes the ICE
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 533435a..82fe424 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -8392,7 +8392,9 @@ gfc_trans_pointer_assignment (gfc_expr * expr1, gfc_expr
* expr2)
if (expr1->ts.deferred)
{
if (expr2->expr_type != EXPR_NULL && lse.string_length != NULL)
- gfc_add_modify (&block, lse.string_length, rse.string_length);
+ gfc_add_modify (&block, lse.string_length,
+ fold_convert (TREE_TYPE (lse.string_length),
+ rse.string_length));
else if (lse.string_length != NULL)
gfc_add_modify (&block, lse.string_length,
build_zero_cst (TREE_TYPE (lse.string_length)));
[Bug target/83399] Power8 ICE During LRA with 2-op rtl pattern for lvx instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83399 --- Comment #3 from kelvin at gcc dot gnu.org --- Author: kelvin Date: Fri Jan 5 20:43:20 2018 New Revision: 256285 URL: https://gcc.gnu.org/viewcvs?rev=256285&root=gcc&view=rev Log: works without regressions - still seeing problems re: bug 83399 Modified: branches/ibm/ltc99327/gcc/config/rs6000/rs6000-p8swap.c branches/ibm/ltc99327/gcc/config/rs6000/rs6000.c branches/ibm/ltc99327/gcc/config/rs6000/vsx.md branches/ibm/ltc99327/gcc/lra-constraints.c branches/ibm/ltc99327/gcc/lra-eliminations.c branches/ibm/ltc99327/gcc/lra.c branches/ibm/ltc99327/gcc/recog.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/pr48857.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-28.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-29.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-30.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-31.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-32.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-33.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-34.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-35.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-36.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-37.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-38.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-39.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-40.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-41.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-42.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-43.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-44.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-45.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/vec-extract-2.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/vec-extract-3.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/vec-extract-5.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/vec-extract-6.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/vec-extract-7.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/vec-extract-8.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/vec-extract-9.c
[Bug middle-end/83684] [8 Regression] ICE in maybe_diag_overlap, at gimple-ssa-warn-restrict.c:1371
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83684 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-01-05 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Based on the line number in the stack trace I'd say the ICE was due to an overly restrictive assertion that was removed in r256187. Please try a more recent revision to see if the problem clears up and let us know.
[Bug fortran/50892] Internal compiler error: in gimplify_expr, at gimplify.c:7477
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50892 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #8 from Jerry DeLisle --- (In reply to Dominique d'Humieres from comment #7) > > Likely by r240850. > > Confirmed. IMO there is no need for a new test, hence closing s FIXED.` hmm, guess we need this test case now.
[Bug tree-optimization/83702] New: missing strlen range optimization for calls with an offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83702
Bug ID: 83702
Summary: missing strlen range optimization for calls with an
offset
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Testing an unrelated strlen optimization enhancement exposed another limitation
in the folding of strlen expressions. GCC 8 is able to optimize code based on
the knowledge that the length of a string is bounded by the size of the array
it is stored in. But it can only do that for strlen calls with no offset, or
for strlen calls with strings of known length and a constant offset. Calls
that involve an offset into an array are not folded, irrespective of whether
the offset is constant. Similarly, calls that involve strings of known length
and a non-const offset aren't folded. Both sets of cases could be folded.
$ cat x.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout x.c | grep -e
"^f[0-9]" -e abort -estrlen
#define S "1234567"
char a[8] = S;
char a[8];
void f0 (void)
{
if (__builtin_strlen (a) > 7) // folded
__builtin_abort ();
}
void f1 (void)
{
if (__builtin_strlen (S + 1) > 6) // folded
__builtin_abort ();
}
void f2 (void)
{
if (__builtin_strlen (a + 1) > 6) // not folded but could be
__builtin_abort ();
}
void f3 (int i)
{
if (__builtin_strlen (S + i) > 7) // not folded but could be
__builtin_abort ();
}
void f4 (int i)
{
if (__builtin_strlen (a + i) > 7) // not folded but could be
__builtin_abort ();
}
f0 ()
f1 ()
f2 ()
_1 = __builtin_strlen (&MEM[(void *)&a + 1B]);
__builtin_abort ();
f3 (int i)
__builtin_abort ();
f4 (int i)
_3 = __builtin_strlen (_2);
__builtin_abort ();
[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534 --- Comment #21 from Jerry DeLisle --- Regrssion tested on x86_64-pc-freeBSD, no failures
[Bug fortran/83700] [Meta-bug] Fortran Coarray issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700 --- Comment #4 from Damian Rouson --- (In reply to Dominique d'Humieres from comment #3) > AFAIR most of (if not all) the PRs are exposed via -fcoarray=lib > -lcaf_single. Yes, I meant to write "-fcoarray=lib -lcaf_mpi". If the errors are compile-time errors, then it probably doesn't matter, but if they are runtime errors, then it's important to test both with single-image execution (-lcaf_single) and multi-image execution (e.g., -caf_mpi). Also, if anyone is interested in related contract work, let me know. Most of the funding Sourcery Institute can contribute have been expended, but one donor to Sourcery Institute has asked about additional ways to contribute so there could be opportunities for a small amount of funding.
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507 --- Comment #8 from Segher Boessenkool --- Ah yes, I can reproduce it with all those options and -m32. I could swear to have tried exactly that yesterday; pilot error I guess. CA is not just a hard register, but a fixed register, btw.
[Bug fortran/83700] [Meta-bug] Fortran Coarray issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700 --- Comment #3 from Dominique d'Humieres --- > Thanks for this! For anyone looking at this, I'll be glad to assist > with parallel execution testing via -fcoarray=lib. AFAIR most of (if not all) the PRs are exposed via -fcoarray=lib -lcaf_single.
[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534 --- Comment #20 from Janne Blomqvist --- Author: jb Date: Fri Jan 5 19:01:12 2018 New Revision: 256284 URL: https://gcc.gnu.org/viewcvs?rev=256284&root=gcc&view=rev Log: PR 78534 Change character length from int to size_t In order to handle large character lengths on (L)LP64 targets, switch the GFortran character length from an int to a size_t. This is an ABI change, as procedures with character arguments take hidden arguments with the character length. I also changed the _size member in vtables from int to size_t, as there were some cases where character lengths and sizes were apparently mixed up and caused regressions otherwise. Although I haven't tested, this might enable very large derived types as well. Also, as there are some places in the frontend were negative character lengths are used as special flag values, in the frontend the character length is handled as a signed variable of the same size as a size_t, although in the runtime library it really is size_t. I haven't changed the character length variables for the co-array intrinsics, as this is something that may need to be synchronized with OpenCoarrays. This is v5 of the patch. v4 was applied but caused breakage on big endian targets. These have been fixed and tested, thanks to access to the GCC compile farm. Overview of v4 of the patch: v3 was applied but had to reverted due to breaking bootstrap. The fix is in resolve.c:resolve_charlen, where it's necessary to check that an expression is constant before using mpz_sgn. Overview of v3 of the patch: All the issues pointed out by FX's review of v2 have been fixed. In particular, there are now new functions gfc_mpz_get_hwi and gfc_mpz_set_hwi, similar to the GMP functions mpz_get_si and mpz_set_si, except that they get/set a HOST_WIDE_INT instead of a long value. Similarly, gfc_get_int_expr now takes a HOST_WIDE_INT instead of a long, gfc_extract_long is replaced by gfc_extract_hwi. Also, the preliminary work to handle gfc_charlen_type_node being unsigned has been removed. Regtested on x86_64-pc-linux-gnu, i686-pc-linux-gnu and powerpc64-unknown-linux-gnu. Also regtested all three targets by modifying gfortran-dg.exp to also test with "-g -flto", no new failures observed. frontend: 2018-01-05 Janne Blomqvist PR fortran/78534 PR fortran/66310 * array.c (got_charlen): Use gfc_charlen_int_kind. * class.c (gfc_find_derived_vtab): Use gfc_size_kind instead of hardcoded kind. (find_intrinsic_vtab): Likewise. * decl.c (match_char_length): Use gfc_charlen_int_kind. (add_init_expr_to_sym): Use gfc_charlen_t and gfc_charlen_int_kind. (gfc_match_implicit): Use gfc_charlen_int_kind. * dump-parse-tree.c (show_char_const): Use gfc_charlen_t and size_t. (show_expr): Use HOST_WIDE_INT_PRINT_DEC. * expr.c (gfc_get_character_expr): Length parameter of type gfc_charlen_t. (gfc_get_int_expr): Value argument of type HOST_WIDE_INT. (gfc_extract_hwi): New function. (simplify_const_ref): Make string_len of type gfc_charlen_t. (gfc_simplify_expr): Use HOST_WIDE_INT for substring refs. * frontend-passes.c (optimize_trim): Use gfc_charlen_int_kind. * gfortran.h (gfc_mpz_get_hwi): New prototype. (gfc_mpz_set_hwi): Likewise. (gfc_charlen_t): New typedef. (gfc_expr): Use gfc_charlen_t for character lengths. (gfc_size_kind): New extern variable. (gfc_extract_hwi): New prototype. (gfc_get_character_expr): Use gfc_charlen_t for character length. (gfc_get_int_expr): Use HOST_WIDE_INT type for value argument. * gfortran.texi: Update description of hidden string length argument. * iresolve.c (check_charlen_present): Use gfc_charlen_int_kind. (gfc_resolve_char_achar): Likewise. (gfc_resolve_repeat): Pass string length directly without temporary, use gfc_charlen_int_kind. (gfc_resolve_transfer): Use gfc_charlen_int_kind. * match.c (select_intrinsic_set_tmp): Use HOST_WIDE_INT for charlen. * misc.c (gfc_mpz_get_hwi): New function. (gfc_mpz_set_hwi): New function. * module.c (atom_int): Change type from int to HOST_WIDE_INT. (parse_integer): Don't complain about large integers. (write_atom): Use HOST_WIDE_INT for integers. (mio_integer): Handle integer type mismatch. (mio_hwi): New function. (mio_intrinsic_op): Use HOST_WIDE_INT. (mio_array_ref): Likewise. (mio_expr): Likewise. * primary.c (match_substring): Use gfc_charlen_int_kind. * resolve.c (resolve_substring_charlen): Use gfc_charlen_int_kind. (resolve_character_operator): Likewise. (resolve_assoc_var): Likewise. (resolve_select_type): Use HOST_WIDE_INT for charlen, use snprintf. (resolve_charlen): Use mpz_sgn to determine sign
[Bug fortran/66310] Problems with intrinsic repeat for large number of copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66310 --- Comment #17 from Janne Blomqvist --- Author: jb Date: Fri Jan 5 19:01:12 2018 New Revision: 256284 URL: https://gcc.gnu.org/viewcvs?rev=256284&root=gcc&view=rev Log: PR 78534 Change character length from int to size_t In order to handle large character lengths on (L)LP64 targets, switch the GFortran character length from an int to a size_t. This is an ABI change, as procedures with character arguments take hidden arguments with the character length. I also changed the _size member in vtables from int to size_t, as there were some cases where character lengths and sizes were apparently mixed up and caused regressions otherwise. Although I haven't tested, this might enable very large derived types as well. Also, as there are some places in the frontend were negative character lengths are used as special flag values, in the frontend the character length is handled as a signed variable of the same size as a size_t, although in the runtime library it really is size_t. I haven't changed the character length variables for the co-array intrinsics, as this is something that may need to be synchronized with OpenCoarrays. This is v5 of the patch. v4 was applied but caused breakage on big endian targets. These have been fixed and tested, thanks to access to the GCC compile farm. Overview of v4 of the patch: v3 was applied but had to reverted due to breaking bootstrap. The fix is in resolve.c:resolve_charlen, where it's necessary to check that an expression is constant before using mpz_sgn. Overview of v3 of the patch: All the issues pointed out by FX's review of v2 have been fixed. In particular, there are now new functions gfc_mpz_get_hwi and gfc_mpz_set_hwi, similar to the GMP functions mpz_get_si and mpz_set_si, except that they get/set a HOST_WIDE_INT instead of a long value. Similarly, gfc_get_int_expr now takes a HOST_WIDE_INT instead of a long, gfc_extract_long is replaced by gfc_extract_hwi. Also, the preliminary work to handle gfc_charlen_type_node being unsigned has been removed. Regtested on x86_64-pc-linux-gnu, i686-pc-linux-gnu and powerpc64-unknown-linux-gnu. Also regtested all three targets by modifying gfortran-dg.exp to also test with "-g -flto", no new failures observed. frontend: 2018-01-05 Janne Blomqvist PR fortran/78534 PR fortran/66310 * array.c (got_charlen): Use gfc_charlen_int_kind. * class.c (gfc_find_derived_vtab): Use gfc_size_kind instead of hardcoded kind. (find_intrinsic_vtab): Likewise. * decl.c (match_char_length): Use gfc_charlen_int_kind. (add_init_expr_to_sym): Use gfc_charlen_t and gfc_charlen_int_kind. (gfc_match_implicit): Use gfc_charlen_int_kind. * dump-parse-tree.c (show_char_const): Use gfc_charlen_t and size_t. (show_expr): Use HOST_WIDE_INT_PRINT_DEC. * expr.c (gfc_get_character_expr): Length parameter of type gfc_charlen_t. (gfc_get_int_expr): Value argument of type HOST_WIDE_INT. (gfc_extract_hwi): New function. (simplify_const_ref): Make string_len of type gfc_charlen_t. (gfc_simplify_expr): Use HOST_WIDE_INT for substring refs. * frontend-passes.c (optimize_trim): Use gfc_charlen_int_kind. * gfortran.h (gfc_mpz_get_hwi): New prototype. (gfc_mpz_set_hwi): Likewise. (gfc_charlen_t): New typedef. (gfc_expr): Use gfc_charlen_t for character lengths. (gfc_size_kind): New extern variable. (gfc_extract_hwi): New prototype. (gfc_get_character_expr): Use gfc_charlen_t for character length. (gfc_get_int_expr): Use HOST_WIDE_INT type for value argument. * gfortran.texi: Update description of hidden string length argument. * iresolve.c (check_charlen_present): Use gfc_charlen_int_kind. (gfc_resolve_char_achar): Likewise. (gfc_resolve_repeat): Pass string length directly without temporary, use gfc_charlen_int_kind. (gfc_resolve_transfer): Use gfc_charlen_int_kind. * match.c (select_intrinsic_set_tmp): Use HOST_WIDE_INT for charlen. * misc.c (gfc_mpz_get_hwi): New function. (gfc_mpz_set_hwi): New function. * module.c (atom_int): Change type from int to HOST_WIDE_INT. (parse_integer): Don't complain about large integers. (write_atom): Use HOST_WIDE_INT for integers. (mio_integer): Handle integer type mismatch. (mio_hwi): New function. (mio_intrinsic_op): Use HOST_WIDE_INT. (mio_array_ref): Likewise. (mio_expr): Likewise. * primary.c (match_substring): Use gfc_charlen_int_kind. * resolve.c (resolve_substring_charlen): Use gfc_charlen_int_kind. (resolve_character_operator): Likewise. (resolve_assoc_var): Likewise. (resolve_select_type): Use HOST_WIDE_INT for charlen, use snprintf. (resolve_charlen): Use mpz_sgn to determine sign
[Bug rtl-optimization/83575] [8 Regression] ICE: verify_flow_info failed (error: multiple hot/cold transitions found)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83575 --- Comment #4 from Jakub Jelinek --- Honza, can you please have a look? It is unclear to me what is supposed to fix up the aux chain after fixup_partitions turns some previously hot bbs into cold ones.
[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83633 --- Comment #3 from Thomas Koenig --- Also, this does not ICE: integer :: A(command_argument_count()) a = 1 write (*,*) A end
[Bug target/82439] Missing (x | y) == x simplifications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82439 Wilco changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Wilco --- Confirmed fixed
[Bug rtl-optimization/83500] gcc.dg/tree-prof/switch-case-1.c fails on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83500 Steve Ellcey changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from Steve Ellcey --- Since the test is now passing I will close this defect as fixed.
[Bug fortran/83700] [Meta-bug] Fortran Coarray issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700 --- Comment #2 from Damian Rouson --- Thanks for this! For anyone looking at this, I'll be glad to assist with parallel execution testing via -fcoarray=lib.
[Bug middle-end/83699] [8 regression] Many 64-bit SPARC gcc.dg/vect tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83699 --- Comment #5 from rsandifo at gcc dot gnu.org --- Created attachment 43048 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43048&action=edit Patch to check REGMODE_NATURAL_SIZE
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-05 Ever confirmed|0 |1 --- Comment #7 from Jakub Jelinek --- BTW, I can reproduce it even with latest trunk: ./cc1.256283 -quiet -O2 -fmodulo-sched -fno-tree-ter -fno-tree-coalesce-vars -mcpu=476 pr83507.c -nostdinc -m32
[Bug debug/83480] [8 Regression] ICE in create_block_for_bookkeeping, at sel-sched.c:4557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83480 --- Comment #9 from Alexandre Oliva --- didn't we print a warning if we found VTA and sel-sched enabled at the same time, too? I guess that might be useful in this case as well. (thanks for taking care of this!)
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507 Jakub Jelinek changed: What|Removed |Added CC||zaks at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- As SMS pass is before reload, another option would be punt on sets to hard registers. But I really know next to nothing about SMS. Is modulo-sched.c maintained at all? I've seen lately only changes to it being changes where something is changed in the whole compiler including modulo-sched.c.
[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83633 Thomas Koenig changed: What|Removed |Added Keywords||ice-on-valid-code CC||tkoenig at gcc dot gnu.org --- Comment #2 from Thomas Koenig --- The code is valid; F2003 7.6.1 "Specification expression" says R729 specification-expr is scalar-int-expr C710 (R729) The scalar-int-expr shall be a restricted expression. A restricted expression is an expression in which each operation is intrinsic and each primary is [...] (8) A reference to any other standard intrinsic function where each argument is a restricted expression, One possible workaround: program main integer :: n n = command_argument_count() block integer :: A(n) A = 1 write (*,*) A end block end
[Bug lto/81004] [7/8 Regression] linking failed with -flto and static libboost_program_options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81004 --- Comment #16 from Matt Godbolt --- I see the target milestone is 7.3, but this bug is still marked NEW. Has there been any further thought on this? I realise this is a tough one, but we've had to either disable LTO, or roll back to c++14 on our projects. It would be amazing if we could get this fixed :)
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507
--- Comment #5 from Jakub Jelinek ---
Likely just latent before. The ICE is because modulo-sched.c in
for (i_reg_move = 0; i_reg_move < nreg_moves; i_reg_move++)
{
ps_reg_move_info *move = ps_reg_move (ps, first_move + i_reg_move);
move->def = i_reg_move > 0 ? first_move + i_reg_move - 1 : i;
move->uses = sbitmap_alloc (first_move + nreg_moves);
move->old_reg = old_reg;
move->new_reg = gen_reg_rtx (GET_MODE (prev_reg));
move->num_consecutive_stages = distances[0] && distances[1] ? 2 : 1;
move->insn = gen_move_insn (move->new_reg, copy_rtx (prev_reg));
bitmap_clear (move->uses);
prev_reg = move->new_reg;
}
creates a move instruction from the ca register but rs6000 doesn't support such
a move, and apparently nothing attempts to recog that instruction and bail if
it is non-existent (or if gen_move_insn emits more than one instruction).
I think e.g. insn_latency can be only called on successfully recognized
instructions...
[Bug libstdc++/83626] std::experimental::filesystem::remove_all throws exception instead of returning 0 if path doesn't exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83626 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Fri Jan 5 18:02:18 2018 New Revision: 256283 URL: https://gcc.gnu.org/viewcvs?rev=256283&root=gcc&view=rev Log: PR libstdc++/83626 handle ENOENT due to filesystem race PR libstdc++/83626 * src/filesystem/ops.cc (remove(const path&, error_code&)): Do not report an error for ENOENT. (remove_all(const path&)): Fix type of result variable. (remove_all(const path&, error_code&)): Use non-throwing increment for directory iterator. Call POSIX remove directly to avoid redundant calls to symlink_status. Do not report errors for ENOENT. * src/filesystem/std-ops.cc: Likewise. * testsuite/27_io/filesystem/operations/remove_all.cc: Test throwing overload. * testsuite/experimental/filesystem/operations/remove_all.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/filesystem/ops.cc trunk/libstdc++-v3/src/filesystem/std-ops.cc trunk/libstdc++-v3/testsuite/27_io/filesystem/operations/remove_all.cc trunk/libstdc++-v3/testsuite/experimental/filesystem/operations/remove_all.cc
[Bug tree-optimization/83698] bogus offset in -Wrestrict messages for strcat of unknown strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83698
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-01-05
Component|c |tree-optimization
Summary|[8 Regression] -Wrestrict |bogus offset in -Wrestrict
|oddities|messages for strcat of
||unknown strings
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
Confirmed, though I don't consider it a regression. Here's a test case for the
bogus strcat offset:
$ cat b.c && gcc -O2 -S -Wall b.c
extern char* strcat (char*, const char*);
extern char d[];
void f (unsigned i)
{
strcat (d + 36, d + 20);
}
b.c: In function ‘f’:
b.c:7:3: warning: ‘strcat’ accessing 0 or more bytes at offsets 36 and 20 may
overlap 1 byte at offset [36, -9223372036854775773] [-Wrestrict]
The weird looking upper bound of the offset range is due to converting a very
large offset_int value that the pass computes offsets and sizes in to
HOST_WIDE_INT for printing. This conversion is necessary because GCC's pretty
printer has no formatting directive for any of the wide int flavors. There are
likely other issues like this one that will disappear once the pretty printer
is enhanced to format wide ints and the conversions removed from -Wrestrict
code. I'll try to find the time to fix this one for GCC 8.
I also tend to agree with the comment about the redundancy. I considered
avoiding it when I wrote the code but decided it wasn't worthwhile. To help
you appreciate the challenges in producing meaningful messages from the
-Wrestrict pass (and others like it) I invite you to look at the code in the
maybe_diag_overlap function in gimple-ssa-warn-restrict.c and consider the
different forms of warnings it already issues. Avoiding the redundancy would
nearly double the number of messages the function issues, from 20 to 40. That
said, I am interested in making the messages more useful and informative so if
you have suggestions for how to rephrase them without unduly growing their
number or losing detail I'd love to hear them. Until some good ideas surface I
don't expect to make a change here.
PS Even to the author of a feature it's not terribly helpful to just paste a
random warning message without a test case. I know the numbers in some of the
warnings could be improved so a report without one doesn't tell me anything
new.
[Bug fortran/83700] [Meta-bug] Fortran Coarray issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-05 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Thanks!
[Bug middle-end/83699] [8 regression] Many 64-bit SPARC gcc.dg/vect tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83699 --- Comment #4 from Eric Botcazou --- > The expmed.c patch is probably a pessimisation in this case. > extract_bit_field_as_Subreg should probably check that the > REGMODE_NATURAL_SIZE of the inner and outer modes are the same. > I'll do that as well, but we should probably fix the LRA > problem while it's visible. But then we wouldn't have caught the pessimization if there is one. In cases like this, I think that it's OK, if not better, to fix only the pessimization. Thanks for looking into this in any case.
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Started with r253530. Bisecting when it went away.
[Bug tree-optimization/83701] New: missing -Wrestrict on strcat to an array depending on offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83701
Bug ID: 83701
Summary: missing -Wrestrict on strcat to an array depending on
offset
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Calling strcat to append to the same string as the source always overlaps
exactly 1 byte: the terminating NUL. This is true regardless of the source and
destination offsets. The test case below shows that the -Wrestict warning
doesn't detect this problem with complete consistency.
$ cat b.c && gcc -O2 -S -Wall b.c
extern char* stpcpy (char*, const char*);
extern char* strcat (char*, const char*);
extern char* strcpy (char*, const char*);
void f1 (char *d)
{
strcpy (d, "01234");
strcat (d + 2, d + 1); // -Wrestrict (good)
}
void f2 (char *d)
{
strcpy (d, "12345");
strcat (d + 2, d + 1); // -Wrestrict (good)
}
extern char d[];
void f3 (void)
{
strcpy (d, "23456");
strcat (d + 2, d + 1); // missing -Wrestrict
}
void f4 (void)
{
strcpy (d, "34567");
strcat (d + 2, d + 1); // missing -Wrestrict
}
void f5 (void)
{
strcpy (d, "23456");
strcat (d + 1, d + 2); // -Wrestrict (good)
}
b.c: In function ‘f1’:
b.c:8:3: warning: ‘strcat’ accessing 5 bytes at offsets 2 and 1 overlaps 1 byte
at offset 5 [-Wrestrict]
strcat (d + 2, d + 1); // -Wrestrict (good)
^
b.c: In function ‘f2’:
b.c:14:3: warning: ‘strcat’ accessing 5 bytes at offsets 2 and 1 overlaps 1
byte at offset 5 [-Wrestrict]
strcat (d + 2, d + 1); // -Wrestrict (good)
^
b.c: In function ‘f5’:
b.c:35:3: warning: ‘strcat’ accessing 4 bytes at offsets 1 and 2 overlaps 1
byte at offset 5 [-Wrestrict]
strcat (d + 1, d + 2); // -Wrestrict (good)
^
[Bug middle-end/83699] [8 regression] Many 64-bit SPARC gcc.dg/vect tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83699 --- Comment #3 from rsandifo at gcc dot gnu.org --- The expmed.c patch is probably a pessimisation in this case. extract_bit_field_as_Subreg should probably check that the REGMODE_NATURAL_SIZE of the inner and outer modes are the same. I'll do that as well, but we should probably fix the LRA problem while it's visible.
[Bug middle-end/83699] [8 regression] Many 64-bit SPARC gcc.dg/vect tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83699 --- Comment #2 from rsandifo at gcc dot gnu.org --- Created attachment 43047 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43047&action=edit Hacky patch In no-scevccp-outer-10.c, LRA enters a cycle trying to move (subreg:SI (reg:V2SI R) 0) into a GPR. It emits: (set (reg:SI tmp) (subreg:SI (reg:V2SI R) 0)) (set (reg:SI dest) (reg:SI tmp)) and sets the class of "tmp" to ALL_REGS. We then assign a GPR to it, creating the same problem again. The subreg is valid for SPARC because of REGMODE_NATURAL_SIZE. I think the problem is that TMP needs to be restricted to EXTRA_FP_REGS. The attached patch does that in a hacky way. I think a more correct way of achieving the same thing would be to make LRA take simplifiable_subregs into account when picking the register for a subreg reload, just as IRA does. I'm not sure whether this is the problem for all the mentioned tests or not.
[Bug target/83604] [8 Regression] ICE in copy_to_mode_reg, at explow.c:630
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83604 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug target/83604] [8 Regression] ICE in copy_to_mode_reg, at explow.c:630
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83604 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Jan 5 16:40:24 2018 New Revision: 256281 URL: https://gcc.gnu.org/viewcvs?rev=256281&root=gcc&view=rev Log: PR target/83604 * config/i386/i386-builtin.def (__builtin_ia32_vgf2p8affineinvqb_v64qi, __builtin_ia32_vgf2p8affineqb_v64qi, __builtin_ia32_vgf2p8mulb_v64qi): Require also OPTION_MASK_ISA_AVX512F in addition to OPTION_MASK_ISA_GFNI. (__builtin_ia32_vgf2p8affineinvqb_v16qi_mask, __builtin_ia32_vgf2p8affineqb_v16qi_mask): Require OPTION_MASK_ISA_AVX512VL instead of OPTION_MASK_ISA_SSE in addition to OPTION_MASK_ISA_GFNI. (__builtin_ia32_vgf2p8mulb_v32qi_mask): Require OPTION_MASK_ISA_AVX512VL in addition to OPTION_MASK_ISA_GFNI and OPTION_MASK_ISA_AVX512BW. (__builtin_ia32_vgf2p8mulb_v16qi_mask): Require OPTION_MASK_ISA_AVX512VL instead of OPTION_MASK_ISA_AVX512BW in addition to OPTION_MASK_ISA_GFNI. (__builtin_ia32_vgf2p8affineinvqb_v16qi, __builtin_ia32_vgf2p8affineqb_v16qi, __builtin_ia32_vgf2p8mulb_v16qi): Require OPTION_MASK_ISA_SSE2 instead of OPTION_MASK_ISA_SSE in addition to OPTION_MASK_ISA_GFNI. * config/i386/i386.c (def_builtin): Change to builtin isa/isa2 being a requirement for all ISAs rather than any of them with a few exceptions. (ix86_add_new_builtins): Clear OPTION_MASK_ISA_64BIT from isa before processing. (ix86_expand_builtin): Require all ISAs from builtin's isa and isa2 bitmasks to be enabled with 3 exceptions, instead of requiring any enabled ISA with lots of exceptions. * config/i386/sse.md (vgf2p8affineinvqb_, vgf2p8affineqb_, vgf2p8mulb_): Change avx512bw in isa attribute to avx512f. * config/i386/sgxintrin.h: Add license boilerplate. * config/i386/vaesintrin.h: Likewise. Fix macro spelling __AVX512F to __AVX512F__ and __AVX512VL to __AVX512VL__. (_mm256_aesdec_epi128, _mm256_aesdeclast_epi128, _mm256_aesenc_epi128, _mm256_aesenclast_epi128): Enable temporarily avx if __AVX__ is not defined. * config/i386/gfniintrin.h (_mm_gf2p8mul_epi8, _mm_gf2p8affineinv_epi64_epi8, _mm_gf2p8affine_epi64_epi8): Enable temporarily sse2 rather than sse if not enabled already. * gcc.target/i386/sse-26.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/sse-26.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/gfniintrin.h trunk/gcc/config/i386/i386-builtin.def trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/sgxintrin.h trunk/gcc/config/i386/sse.md trunk/gcc/config/i386/vaesintrin.h trunk/gcc/testsuite/ChangeLog
[Bug target/83604] [8 Regression] ICE in copy_to_mode_reg, at explow.c:630
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83604 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Fri Jan 5 16:38:17 2018 New Revision: 256280 URL: https://gcc.gnu.org/viewcvs?rev=256280&root=gcc&view=rev Log: PR target/83604 * config/i386/sse.md (VI248_VLBW): Rename to ... (VI248_AVX512VL): ... this. Don't guard V32HI with TARGET_AVX512BW. (vpshrd_, vpshld_, vpshrdv_, vpshrdv__mask, vpshrdv__maskz, vpshrdv__maskz_1, vpshldv_, vpshldv__mask, vpshldv__maskz, vpshldv__maskz_1): Use VI248_AVX512VL mode iterator instead of VI248_VLBW. * gcc.target/i386/pr83604.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr83604.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug c++/83504] incorrect attribute const interpretation on function overloads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83504
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #4 from Martin Sebor ---
Template specializations are handled correctly.
But the test case doesn't actually show a bug in how overloads are handled -- I
forgot that GCC eliminates the calls to the non-const function because it sees
its definition. My bad. With that fixed like below the test case shows that
GCC behaves correctly even for overloads.
$ cat u.C && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout u.C
int i;
int __attribute__ ((noclone, noinline)) f (int) { return i; }
int __attribute__ ((const)) f ();
void g (void)
{
i = 0;
int j = f (0);
i = 1;
if (j == f (0))
__builtin_abort ();
}
...
g ()
{
int j;
int _1;
[local count: 1073741825]:
i = 0;
j_4 = f (0);
i = 1;
_1 = f (0);
if (_1 == j_4)
goto ; [0.00%]
else
goto ; [99.96%]
[count: 0]:
__builtin_abort ();
[local count: 1073312327]:
return;
}
[Bug tree-optimization/83518] [8 Regression] Missing optimization: useless instructions should be dropped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83518 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- We do vectorize this and thus not unroll it since r253975. With -O3 -fno-vect-cost-model we've generated what GCC 8 emits or something similar for many years, including 4.4+ (r140264 already shows this behavior).
[Bug tree-optimization/83605] [6/7 Regression] ICE: verify_gimple failed (error: dead STMT in EH table)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83605 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[6/7/8 Regression] ICE: |[6/7 Regression] ICE: |verify_gimple failed|verify_gimple failed |(error: dead STMT in EH |(error: dead STMT in EH |table) |table) --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug rtl-optimization/83628] [8 Regression] performance regression when accessing arrays on alpha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83628 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- P4 unless it affects also primary/secondary targets.
[Bug middle-end/83699] [8 regression] Many 64-bit SPARC gcc.dg/vect tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83699 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-05 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from rsandifo at gcc dot gnu.org --- Seems to be an LRA problem.
[Bug c++/83690] [8 regression] spurious unused variable warings for variables used only in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83690 --- Comment #2 from Jakub Jelinek --- Created attachment 43046 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43046&action=edit gcc8-pr83690.patch This does seem to do the job.
[Bug c++/83690] [8 regression] spurious unused variable warings for variables used only in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83690 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-05 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r253266. Jason?
[Bug fortran/83525] open(newunit=funit, status="scratch") fails if an internal file (characters) was read previously.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83525 --- Comment #3 from Jerry DeLisle --- (In reply to Thomas Koenig from comment #2) > This looks very much like a dup of PR83436. > > Close as duplicate? I am going to add the test case and then close this.
[Bug debug/83480] [8 Regression] ICE in create_block_for_bookkeeping, at sel-sched.c:4557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83480 --- Comment #8 from Jakub Jelinek --- Created attachment 43045 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43045&action=edit gcc8-pr83480.patch In any case, I think this patch is a small step towards the right direction.
[Bug rtl-optimization/83480] [8 Regression] ICE in create_block_for_bookkeeping, at sel-sched.c:4557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83480 --- Comment #7 from Jakub Jelinek --- Apparently we only disable -fvar-tracking-assignments by default if sel-sched, not disable it unconditionally. So, while we could and should change: if (debug_nonbind_markers_p == AUTODETECT_VALUE) debug_nonbind_markers_p = optimize && debug_info_level >= DINFO_LEVEL_NORMAL && (write_symbols == DWARF2_DEBUG || write_symbols == VMS_AND_DWARF2_DEBUG); to if (debug_nonbind_markers_p == AUTODETECT_VALUE) debug_nonbind_markers_p = (optimize && debug_info_level >= DINFO_LEVEL_NORMAL && (write_symbols == DWARF2_DEBUG || write_symbols == VMS_AND_DWARF2_DEBUG) && !(flag_selective_scheduling || flag_selective_scheduling2)); the testcase would still ICE with -gstatement-frontiers.
[Bug target/83681] epiphany: config/epiphany/epiphany.h:883:8: error: unknown type name 'rtl_opt_pass'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83681 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-05 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Same issue as for nios2 and same fix if it works.
[Bug debug/83694] [8 Regression] New test case gcc.dg/pr83666.c from r256232 ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83694 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from Jakub Jelinek --- > Created attachment 43042 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43042&action=edit > gcc8-pr83694.patch > > Untested fix. I've just tried it on sparc-sun-solaris2.11 and (for good measure) i386-pc-solaris2.11. The failures are gone. Thanks. Rainer
[Bug rtl-optimization/83682] [8 Regression] ICE in simplify_subreg, at simplify-rtx.c:6296
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83682 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 43044 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43044&action=edit gcc8-pr83682.patch Untested fix.
[Bug rtl-optimization/83480] [8 Regression] ICE in create_block_for_bookkeeping, at sel-sched.c:4557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83480 --- Comment #6 from Alexandre Oliva --- It seems like sel-sched really can't deal with debug insns; I agree it makes sense to disable all sorts of debug insns when sel-sched is selected/enabled.
[Bug tree-optimization/83651] [7/8 regression] 20% slowdown of linux kernel AES cipher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651 --- Comment #1 from Arnd Bergmann --- Before posting a new workaround for PR83356 (the workaround is to use -Os instead of O2 for this file), I retested the performance numbers as well, and got slightly different numbers this time. I don't know what caused that difference, but now this is what I see is slightly different: -O2 -Os gcc-6.3.1 14.915.1 gcc-7.0.1 14.715.3 gcc-7.1.1 15.314.7 gcc-7.2.1 16.815.9 gcc-8.0.0 15.515.6 In particular, the gcc-7.1.1 results are a bit worse than they were, leading to a less significant regression from 7.1.1 to 7.2.2, and the numbers are now closer to what I saw with libressl. In both cases, we still have a 5% to 9% regression between gcc-7.1.1 (20170717) and gcc-7.2.1 (20180102), and a 14% to 23% regression between 6.3.1 and 7.2.1. I also found my mistake in the libressl numbers I showed in comment #1, they are listed exactly factor 3 higher than they should have been, and the actual results are close to the kernel implementation. I've measure these again now as well and come to the following results, using identical compilers as above: -O2 -Os gcc-6.3.1 16.716.7 gcc-7.0.1 17.516.0 gcc-7.1.1 17.516.0 gcc-7.2.1 17.616.0 gcc-8.0.0 16.815.5 To reproduce with libressl, one could use the following steps: $ git clone https://github.com/libressl-portable/portable.git $ cd portable $ ./autogen.sh $ sed -i 's/undef FULL_UNROLL/define FULL_UNROLL/' crypto/aes/aes_locl.h $ CC=x86_64-linux-gcc-7.2.1 ./configure --disable-asm $ make -sj8 $ ./apps/openssl/openssl speed aes-256-cbc The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256 cbc 168004.61k 174024.74k 174855.76k 176270.13k 176608.14k $ CC=x86_64-linux-gcc-6.3.1 ./configure --disable-asm $ touch crypto/aes/aes_core.c $ make -sj8 $ ./apps/openssl/openssl speed aes-256-cbc The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256 cbc 175366.81k 182261.29k 183131.80k 184369.21k 184611.37k
[Bug rtl-optimization/83682] [8 Regression] ICE in simplify_subreg, at simplify-rtx.c:6296
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83682
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Cleaned up testcase:
typedef float V __attribute__((__vector_size__(16)));
typedef double W __attribute__((__vector_size__(16)));
V b;
W c;
void
foo (void *p)
{
V e = __builtin_ia32_cvtsd2ss (b, c);
V g = e;
float f = g[0];
__builtin_memcpy (p, &f, sizeof (f));
}
Started with r254294.
[Bug fortran/83700] New: [Meta-bug] Fortran Coarray issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700 Bug ID: 83700 Summary: [Meta-bug] Fortran Coarray issues Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- There are quite a few, time to gather them...
[Bug c++/81327] [8 Regression] cast to void* does not suppress -Wclass-memaccess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81327 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Created attachment 43043 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43043&action=edit gcc8-pr81327.patch Untested fix.
[Bug preprocessor/83492] [7 Regression] Optimized search_line_fast breaks preprocessor on aarch64_be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83492 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from ktkachov at gcc dot gnu.org --- Fixed on GCC 7 branch too. Thank you for the report and your work on fixing this.
[Bug preprocessor/83492] [7 Regression] Optimized search_line_fast breaks preprocessor on aarch64_be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83492 --- Comment #7 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Fri Jan 5 13:58:54 2018 New Revision: 256278 URL: https://gcc.gnu.org/viewcvs?rev=256278&root=gcc&view=rev Log: [PATCH, PR83492] Fix selection of aarch64 big-endian shift parameters based on __AARCH64EB__ 2018-01-05 Michael Weiser Backport from trunk 2017-12-20 Michael Weiser PR preprocessor/83492 * lex.c (search_line_fast) [__ARM_NEON && __ARM_64BIT_STATE]: Fix selection of big-endian shift parameters by using __ARM_BIG_ENDIAN. Modified: branches/gcc-7-branch/libcpp/ChangeLog branches/gcc-7-branch/libcpp/lex.c
