[Bug driver/78772] -fstrict-aliasing should turn on Wstrict-aliasing automaticly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78772 --- Comment #7 from ma.jiang at zte dot com.cn --- (In reply to Markus Trippelsdorf from comment #5) Hi Markus, > These optimizations are not dangerous if you use standard conforming code. I think these optimizations are dangerous because they create wrong binaries silently, even if we use standard conforming codes. Let us just look at the "-fstrict-aliasing". This optimization assume "In particular, an object of one type is assumed never to reside at the same address as an object of a different type, unless the types are almost the same". But this restriction *IS NOT* required by the C-standard. So codes that conformed to C-standard could also be translated to wrong binaries by GCC with "-fstrict-aliasing", in silence... > > We could have a discussion if it might be better to enable some -Wall > warnings > by default like Clang. But I'm not sure if this gives huge benefits to users. I do not know whether it's a good idea to enable warnings such as Wstrict-aliasing by default. But I believe we should enable these warnings when corresponding optimizations are turned on, this do give huge benefits to users.
[Bug libstdc++/65434] Memory leak in pool constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65434 Markus Eisenmann changed: What|Removed |Added CC||meisenmann.lba@fh-salzburg. ||ac.at --- Comment #6 from Markus Eisenmann --- Created attachment 40318 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40318&action=edit Provide optional "static" memory-allocation in eh_alloc.cc (on demand) This patch provides a minor extension to allocate the emergency-buffer from BSS, if the needed size is bellow a limit (macro LIMIT_EMERGENCY_BSS_MEM, e.g. 4096 Byte).
[Bug ipa/77905] [5/6/7 Regression] ICE at -Os and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in ipa_comdats, at ipa-comdats.c:352)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77905
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Tue Dec 13 08:48:45 2016
New Revision: 243596
URL: https://gcc.gnu.org/viewcvs?rev=243596&root=gcc&view=rev
Log:
PR ipa/77905
* ipa-pure-const.c (cdtor_p): Return true for
DECL_STATIC_{CON,DE}STRUCTOR even when it is
DECL_LOOPING_CONST_OR_PURE_P.
* g++.dg/ipa/pr77905.C: New test.
Added:
trunk/gcc/testsuite/g++.dg/ipa/pr77905.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-pure-const.c
trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/65434] Memory leak in pool constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65434 --- Comment #7 from Markus Eisenmann --- Hi! My motivation to use/implement this patch (comment #6) is to prevent using malloc to allocate the needed emergency-buffer region, if the needed overall size is bellow a (configurable) limit; e.g., embedded targets without threading-support. It does not change the behaviour of the sub-allocator (pool), but will allow to apply/use a static memory-region (from BSS), which will solve this kind of memory-leak (if the second - I.e, static - memory-provider template will choosen). Best regards from Salzburg, Markus
[Bug fortran/78757] [7 Regression] ICE with function returning a pointer to a character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78757 Richard Biener changed: What|Removed |Added Version|unknown |7.0 --- Comment #2 from Richard Biener --- Both are latent issues even before that revision (not causing ICEs but at least wrong-debug, eventually wrong-code).
[Bug tree-optimization/78731] [5 Regression] Possible bug with switch when optimization is turned on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78731 --- Comment #5 from rguenther at suse dot de --- On Fri, 9 Dec 2016, law at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78731 > > Jeffrey A. Law changed: > >What|Removed |Added > > CC||law at redhat dot com > > --- Comment #4 from Jeffrey A. Law --- > I'm convinced that a table based jump threader that traverses backedges is > fundamentally a bad idea. That's why I ripped it out and we rely on > Sebastian's code to handle those cases -- Sebastian's code doesn't have to > deal > with table invalidation. > > You might consider just disabling threading across the backedges. There'll be > testsuite fallout, but in the end the layers upon layers of complexity to deal > with invalidation just isn't worth it. I don't think that's appropriate on the branch. So I appreciate review of the patch I posted.
[Bug tree-optimization/78742] [5/6/7 Regression] internal compiler error: in int_cst_value, at tree.c:10782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78742 --- Comment #10 from Richard Biener --- Author: rguenth Date: Tue Dec 13 09:17:42 2016 New Revision: 243598 URL: https://gcc.gnu.org/viewcvs?rev=243598&root=gcc&view=rev Log: 2016-12-13 Richard Biener PR middle-end/78742 * tree.c (cst_and_fits_in_hwi): Look if the actual value fits. * tree-object-size.c (compute_builtin_object_size): Use tree_fits_shwi_p. * tree-data-ref.c (initialize_matrix_A): Remove excess assert. * gcc.dg/torture/pr78742.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr78742.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-data-ref.c trunk/gcc/tree-object-size.c trunk/gcc/tree.c
[Bug tree-optimization/78699] [7 Regression] ICE (segfault) on powerpc64le-linux-gnu (memory-hog)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78699 --- Comment #6 from Richard Biener --- Author: rguenth Date: Tue Dec 13 09:19:19 2016 New Revision: 243599 URL: https://gcc.gnu.org/viewcvs?rev=243599&root=gcc&view=rev Log: 2016-12-13 Richard Biener PR tree-optimization/78699 * tree-vect-data-refs.c (vect_analyze_group_access_1): Limit group size. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug tree-optimization/78742] [5/6 Regression] internal compiler error: in int_cst_value, at tree.c:10782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78742 Richard Biener changed: What|Removed |Added Known to work||7.0 Summary|[5/6/7 Regression] internal |[5/6 Regression] internal |compiler error: in |compiler error: in |int_cst_value, at |int_cst_value, at |tree.c:10782|tree.c:10782 Known to fail||6.2.0 --- Comment #11 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/78699] [7 Regression] ICE (segfault) on powerpc64le-linux-gnu (memory-hog)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78699 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/78788] New: [7 Regression] ICE (segfault) on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78788 Bug ID: 78788 Summary: [7 Regression] ICE (segfault) on s390x-linux-gnu Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- Created attachment 40319 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40319&action=edit unreduced test case seen with r243559 on s390x-linux-gnu, cc1 eats up all memory and then is killed. works with -O1. also seen on powerpc64le-linux-gnu. $ gdb --args /usr/lib/gcc/s390x-linux-gnu/7/cc1 -fpreprocessed ghosts.i -quiet -dumpbase ghosts.i -march=zEC12 -m64 -mzarch -auxbase ghosts -O2 -Wno-format-security -version -fno-aggressive-loop-optimizations -fstack-protector-strong -Wformat -o /tmp/ccaLbok3.s #0 sext_hwi (prec=, src=) at ../../src/gcc/hwint.h:292 #1 wide_int_storage::set_len (is_sign_extended=false, l=1, this=0x3ffd558) at ../../src/gcc/wide-int.h:1090 #2 wi::mask (precision=32, negate_p=false, width=31) at ../../src/gcc/wide-int.h:3200 #3 wi::max_value (precision=precision@entry=32, sgn=sgn@entry=SIGNED) at ../../src/gcc/wide-int.cc:326 #4 0x0199056e in generic_simplify_92 (loc=loc@entry=0, type=type@entry=0x3fffd513b28, op1=op1@entry=0x3fffc8d0408, captures=captures@entry=0x3ffd6a8, cmp=cmp@entry=GE_EXPR, op0=0x3fffc96f630) at generic-match.c:3761 #5 0x0199482c in generic_simplify_GE_EXPR (loc=, type=type@entry=0x3fffd513b28, op0=op0@entry=0x3fffc96f630, op1=op1@entry=0x3fffc8d0408, code=GE_EXPR) at generic-match.c:27866 #6 0x019b8d92 in generic_simplify (loc=loc@entry=0, code=code@entry=GE_EXPR, type=type@entry=0x3fffd513b28, op0=op0@entry=0x3fffc96f630, op1=op1@entry=0x3fffc8d0408) at generic-match.c:33804 #7 0x013a8386 in fold_binary_loc (loc=loc@entry=0, code=code@entry=GE_EXPR, type=type@entry=0x3fffd513b28, op0=op0@entry=0x3fffc96f630, op1=op1@entry=0x3fffc8d0408) at ../../src/gcc/fold-const.c:9055 #8 0x013af5e2 in fold_build2_stat_loc (loc=loc@entry=0, code=code@entry=GE_EXPR, type=type@entry=0x3fffd513b28, op0=op0@entry=0x3fffc96f630, op1=op1@entry=0x3fffc8d0408) at ../../src/gcc/fold-const.c:12183 #9 0x0198adbc in generic_simplify_174 (loc=loc@entry=0, type=type@entry=0x3fffd513b28, captures=captures@entry=0x3ffdd10, acmp=acmp@entry=GE_EXPR, cmp=GT_EXPR, op1=0x3fffd501ba0, op0=0x3fffc96f630) at generic-match.c:7226 #10 0x019957a6 in generic_simplify_GT_EXPR (loc=, type=type@entry=0x3fffd513b28, op0=op0@entry=0x3fffc96f630, op1=op1@entry=0x3fffd501ba0, code=GT_EXPR) at generic-match.c:28230 #11 0x019b8dac in generic_simplify (loc=loc@entry=0, code=code@entry=GT_EXPR, type=type@entry=0x3fffd513b28, op0=op0@entry=0x3fffc96f630, op1=op1@entry=0x3fffd501ba0) at generic-match.c:33806 #12 0x013a8386 in fold_binary_loc (loc=loc@entry=0, code=code@entry=GT_EXPR, type=type@entry=0x3fffd513b28, op0=op0@entry=0x3fffc96f630, op1=op1@entry=0x3fffd501ba0) at ../../src/gcc/fold-const.c:9055 #13 0x013af5e2 in fold_build2_stat_loc (loc=, code=, type=0x3fffd513b28, op0=0x3fffc96f630, op1=0x3fffd501ba0) at ../../src/gcc/fold-const.c:12183 #14 0x013a833c in fold_binary_loc (loc=loc@entry=0, code=LT_EXPR, type=0x3fffd513b28, op0=op0@entry=0x3fffd501ba0, op1=op1@entry=0x3fffc96f630) at ../../src/gcc/fold-const.c:9053 #15 0x013bd2ee in fold_binary_to_constant (code=code@entry=LT_EXPR, type=, op0=op0@entry=0x3fffd501ba0, op1=op1@entry=0x3fffc96f630) at ../../src/gcc/fold-const.c:13533 #16 0x0183fb7e in operand_less_p (val=0x3fffd501ba0, val2=0x3fffc96f630) at ../../src/gcc/tree-vrp.c:1187 #17 0x0184461e in intersect_ranges (vr1max=0x3fffd501bb8, vr1min=0x3fffd501ba0, vr1type=VR_RANGE, vr0max=0x3ffe8b8, vr0min=0x3ffe8b0, vr0type=0x3ffe8a8) at ../../src/gcc/tree-vrp.c:8536 #18 vrp_intersect_ranges_1 (vr1=0x3ffe788, vr0=0x3ffe8a8) at ../../src/gcc/tree-vrp.c:8653 #19 vrp_intersect_ranges (vr0=0x3ffe8a8, vr1=0x3ffe788) at ../../src/gcc/tree-vrp.c:8691 #20 0x01844c3e in update_value_range (var=0x3fffc85ff78, new_vr=0x3ffe8a8) at ../../src/gcc/tree-vrp.c:802 #21 0x01854928 in vrp_visit_phi_node (phi=) at ../../src/gcc/tree-vrp.c:9024 #22 0x01785042 in simulate_stmt (stmt=stmt@entry=0x3fffc85ab00) #23 0x01786174 in process_ssa_edge_worklist () at ../../src/gcc/tree-ssa-propagate.c:341 #24 ssa_propagate (visit_stmt=visit_stmt@entry=0x1857b50 , visit_phi=visit_phi@entry=0x18548f8 ) at ../../src/gcc/tree-ssa-propagate.c:813 #25 0x0184e714 in execute_vrp (warn_array_bounds_p=false) at ../../src/gcc/tree-vrp.c:11247 #26 (anonymous namespace)::pass_vrp::exe
[Bug gcov-profile/48361] gcov freezes when using --all-blocks (-a) flag.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48361 Luca Ingianni changed: What|Removed |Added CC||luca at ingianni dot eu --- Comment #8 from Luca Ingianni --- Well, DOESNTWORKFORME. I observed it in gcc (Debian 4.9.2-10) 4.9.2 In fact IIRC I tried with GCC 6 and was able to reproduce - this is a pretty longstanding bug. I'll try to isolate a testcase for you, and re-check the behaviour on newer GCCs
[Bug c++/78767] [7 Regression] ICE when inheriting constructor of base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78767 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Version|6.2.0 |7.0
[Bug target/77933] Stack corruption on ARM when using high registers and __builtin_return_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77933 --- Comment #8 from Thomas Preud'homme --- Author: thopre01 Date: Tue Dec 13 09:39:02 2016 New Revision: 243600 URL: https://gcc.gnu.org/viewcvs?rev=243600&root=gcc&view=rev Log: Fix PR77933: stack corruption on ARM when using high registers and LR 2016-12-13 Thomas Preud'homme Backport from mainline 2016-11-17 Thomas Preud'homme gcc/ PR target/77933 * config/arm/arm.c (thumb1_expand_prologue): Distinguish between lr being live in the function and lr needing to be saved. Distinguish between already saved pushable registers and registers to push. Check for LR being an available pushable register. gcc/testsuite/ PR target/77933 * gcc.target/arm/pr77933-1.c: New test. * gcc.target/arm/pr77933-2.c: Likewise. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/pr77933-1.c branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/pr77933-2.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/arm/arm.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug c/78768] -Walloca-larger-than and -Wformat-length warnings disabled by -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78768 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-13 Component|lto |c Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- You need to add LTO to the list of languages allowed for the warning options in c-family/c.opt
[Bug c++/78771] [5/6/7 Regression] ICE when using inherited constructors (instantiate_template_1 in gcc/cp/pt.c:17391)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78771 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |5.5 Summary|ICE when using inherited|[5/6/7 Regression] ICE when |constructors|using inherited |(instantiate_template_1 in |constructors |gcc/cp/pt.c:17391) |(instantiate_template_1 in ||gcc/cp/pt.c:17391)
[Bug go/78789] New: Error: no such instruction: `aesenc %xmm0,%xmm2' when compiling libgo/runtime/aeshash.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78789 Bug ID: 78789 Summary: Error: no such instruction: `aesenc %xmm0,%xmm2' when compiling libgo/runtime/aeshash.c Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ubizjak at gmail dot com CC: cmang at google dot com Target Milestone: --- libgo build currently fails on CentOS 5.11 with: libtool: compile: /home/uros/gcc-build/./gcc/xgcc -B/home/uros/gcc-build/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../git/gcc/libgo -I ../../../git/gcc/libgo/runtime -I../../../git/gcc/libgo/../libffi/include -I../libffi/include -pthread -fexceptions -fnon-call-exceptions -fplan9-extensions -Wall -Wextra -Wwrite-strings -Wcast-qual -Werror -minline-all-stringops -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I ../../../git/gcc/libgo/../libgcc -I ../../../git/gcc/libgo/../libbacktrace -I ../../gcc/include -g -O2 -MT aeshash.lo -MD -MP -MF .deps/aeshash.Tpo -c ../../../git/gcc/libgo/runtime/aeshash.c -fPIC -DPIC -o .libs/aeshash.o /tmp/ccxm8ECk.s: Assembler messages: /tmp/ccxm8ECk.s:63: Error: no such instruction: `aesenc %xmm0,%xmm2' /tmp/ccxm8ECk.s:177: Error: no such instruction: `aesenc %xmm1,%xmm3' <... many more ...> /tmp/ccxm8ECk.s:1337: Error: no such instruction: `aesenc %xmm3,%xmm3' /tmp/ccxm8ECk.s:1343: Error: no such instruction: `aesenc %xmm2,%xmm2' gmake[2]: *** [aeshash.lo] Error 1 gmake[2]: Leaving directory `/home/uros/gcc-build/x86_64-pc-linux-gnu/libgo' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/uros/gcc-build/x86_64-pc-linux-gnu/libgo' gmake: *** [all] Error 2 Binutils 2.17 can't assemble aesenc insn. $ as --version GNU assembler 2.17.50.0.6-26.el5 20061020 The libgo build should check if AES instructions can be compiled before trying to compile runtime/aeshash.c file.
[Bug target/77933] Stack corruption on ARM when using high registers and __builtin_return_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77933 Thomas Preud'homme changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||5.4.1 Resolution|--- |FIXED Known to fail|5.4.1 |5.4.0 --- Comment #9 from Thomas Preud'homme --- Fixed in all supported branches.
[Bug gcov-profile/48361] gcov freezes when using --all-blocks (-a) flag.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48361 Martin Liška changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME |--- --- Comment #9 from Martin Liška --- Ok, reopening. I will resolve that having a test-case ;)
[Bug tree-optimization/18438] vectorizer failed for vector matrix multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18438 --- Comment #13 from Richard Biener --- (In reply to Maxim Kuvyrkov from comment #9) > I've looked into another case where inability to handle stores with gaps > generates sub-optimal code. I'm interested in spending some time on fixing > this, provided some guidance in the vectorizer. > > Is it substantially more difficult to handle stores with gaps compared to > loads with gaps? It has the complication that we can't actually store to the gaps because that creates store data races (and we'd need a load-modify-write cycle). So we have to emit either scalar stores (which is what we currently do), emit masked stores (not implemented yet) or something you suggest (I suppose that's a store-lanes kind?). A slight complication is that we have to avoid detecting the store group if we want to end up with scalar stores (well, that's a vectorizer implementation limit). This is why we simply split all groups at gap boundaries. Cost-based selection of the kind of store (or even load) implementation is not implemented.
[Bug ipa/78790] New: Disable IPA-VRP for noclone functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78790
Bug ID: 78790
Summary: Disable IPA-VRP for noclone functions.
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Even with attributes noclone + noinline, gcc propagates function arguments into
functions like with the following test case and gcc-7:
__attribute__ ((noinline,noclone))
int add (int a, int b)
{
return a + b;
}
int main (void)
{
if (1 + 2 != add (1, 2))
__builtin_abort();
return 0;
}
Compile this test case with
$ gcc -save-temps ipa-cprop.c -o ipa-cprop -O3 -flto
The dump ipa-cprop.ltrans0.s then reads (x86_64)
add:
.LFB0:
.cfi_startproc
movl$3, %eax
ret
.cfi_endproc
noclone should keep gcc from generating such "clones". One problem is that
noinlone + noclone is a common idiom writing GCC tests, and the expectation is
that no such propagations are performed (no matter if it's a "real" propagation
of values or just a propagation of ranges with IPA-VRP).
There was some discussion on the gcc mailing list about this like
https://gcc.gnu.org/ml/gcc-help/2016-12/msg00036.html
== configure ==
Target: x86_64-pc-linux-gnu
Configured with: ../../gcc.gnu.org/trunk/configure
--prefix=/local/gnu/install/gcc-7-host --enable-languages=c,c++
--enable-checking=release --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161202 (experimental) [trunk revision 227650] (GCC)
[Bug middle-end/78684] [7 Regression] ICE in create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78684 amker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from amker at gcc dot gnu.org --- (In reply to Marek Polacek from comment #10) > So fixed? Yes, I think so.
[Bug rtl-optimization/78559] [7 Regression] wrong code due to tree if-conversion?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78559 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||segher at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- So do you think combiner should throw away the REG_EQUAL note in that case, or something different?
[Bug fortran/55814] Missed optimization with short-circuit evaluation of always evaluated comparisons/loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55814
Richard Biener changed:
What|Removed |Added
Component|middle-end |fortran
--- Comment #5 from Richard Biener ---
So the testcase with the loop boils down to optimizing
_Bool foo (int *p, int n, _Bool q)
{
_Bool any = false;
for (i = 0; i < n; ++i)
any |= p[i];
return any || q;
}
where we want swapping of the operands (and its computations) of || (or &&).
Nothing in GCC does this kind of transform and I don't see where it would
fit best. I think that
logical function bar(a,b,c)
logical, intent(in) :: a, b
logical, intent(in), dimension(3) :: c
bar = a .and. b .and. any(c)
end
is translated in a bad way by the fortran FE, not honoring left-to-right
evaluation. So "optimized source" is pessimized here. Even when writing
logical function bar(a,b,c)
logical, intent(in) :: a, b
logical, intent(in), dimension(32) :: c
bar = any (c) .and. (a .and. b)
end
I get the same -- any () is evaluated first and only then the scalar variant.
The original C testcase shows we eventually miss a scalar-to-CFG pass on GIMPLE
before RTL expansion so we can run sinking on that.
That said, the any() thing is a frontend issue IMHO.
[Bug c++/78774] [6/7 Regression] ICE in constexpr string literals and templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78774 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/78786] GCC hangs/out of memory calling sprintf with large precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78786 --- Comment #2 from Vincent Lefèvre --- With "%.*f", the problem comes from GMP (and possibly glibc) since MPFR calls the GMP functions to handle non-MPFR format specifiers. But the patch seems to use "%.*Rf", for which I cannot reproduce the problem with MPFR 3.1.5.
[Bug tree-optimization/78775] [7 Regression] ICE in maybe_warn_alloc_args_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78775 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Version|unknown |7.0
[Bug rtl-optimization/78778] non-atomic load moved to before atomic load with std::memory_order_acquire
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78778 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-13 Ever confirmed|0 |1 Known to fail||6.2.1 --- Comment #3 from Richard Biener --- I don't think this is a speculative load. GIMPLE with more details: : pretmp_14 = &MEM[(const struct __atomic_base *)seq_3(D)]._M_i; : # .MEM_1 = PHI <.MEM_13(3), .MEM_2(D)(2), .MEM_13(4)> # .MEM_12 = VDEF <.MEM_1> _11 = __atomic_load_8 (pretmp_14, 2); # VUSE <.MEM_12> copy_5 = *value_4(D); # .MEM_13 = VDEF <.MEM_12> _9 = __atomic_load_8 (pretmp_14, 2); if (_9 == _11) goto ; else goto ; : _6 = _9 & 1; if (_6 == 0) goto ; else goto ; : _7 = (int) copy_5; # VUSE <.MEM_13> return _7; this shows that the atomic loads have memory side-effects (they have a VDEF). It appears that on RTL this critical piece is missing as we simply expand to ;; Generating RTL for gimple basic block 3 ;; _11 = __atomic_load_8 (pretmp_14, 2); (insn 9 8 0 (set (reg:DI 90 [ _11 ]) (mem/v:DI (reg/f:DI 91 [ pretmp_14 ]) [-1 S8 A64])) /usr/include/c++/6/bits/atomic_base.h:396 -1 (nil)) ;; copy_5 = *value_4(D); (insn 10 9 0 (set (reg/v:DF 87 [ copy ]) (mem:DF (reg/v/f:DI 94 [ value ]) [2 *value_4(D)+0 S8 A64])) t.c:9 -1 (nil)) ;; _9 = __atomic_load_8 (pretmp_14, 2); (insn 11 10 0 (set (reg:DI 89 [ _9 ]) (mem/v:DI (reg/f:DI 91 [ pretmp_14 ]) [-1 S8 A64])) /usr/include/c++/6/bits/atomic_base.h:396 -1 (nil)) so any notion of "atomicity" is lost (it looks like the MEM is volatile though?) Confirmed.
[Bug lto/78787] O Color, Where Art Thou? (with -flto)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78787 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-13 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Hmm: fdiagnostics-color= Driver Common Joined RejectNegative Var(flag_diagnostics_show_color) Enum(diagnostic_color_rule) Init(DIAGNOSTICS_COLOR_NO) -fdiagnostics-color=[never|always|auto] Colorize diagnostics. and color is initialized via toplev.c. So I don't see how it doesn't work. But yes, it doesn't work. Looks like the environment is not passed through properly: > GCC_COLORS=yes gcc-6 t.c -Wall -O2 -Wextra -B /abuild/rguenther/trunk-g/gcc > -flto -v -save-temps shows the effect, repeating the LTRANs command with > GCC_COLORS=yes /abuild/rguenther/trunk-g/gcc/lto1 -quiet -dumpbase > ccXMeVxA.ltrans0.o -mtune=generic -march=x86-64 -auxbase-strip > /tmp/ccXMeVxA.ltrans0.ltrans.o -O2 -O2 -Wextra -version -fmath-errno > -fsigned-zeros -ftrapping-math -fno-trapv -fno-openmp -fno-openacc > -fltrans-output-list=/tmp/ccXMeVxA.ltrans.out -fltrans @/tmp/ccKhkQlz -o > ccXMeVxA.ltrans0.s colors the output. Not sure how you get your "default" coloring (your .profile and a login vs. non-login shell and the way we execute sub-commands from the driver and/or the linker?)
[Bug ipa/78790] Disable IPA-VRP for noclone functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78790 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-13 CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Similar for alignment propagation I guess. I don't think they should be considered "clones"..., but up to IPA maintainers to decide.
[Bug tree-optimization/78788] [7 Regression] ICE (segfault) on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78788 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-12-13 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed on ppc64le, hangs in VRP. I'll have a look (testcase reduction appreciated...).
[Bug target/59874] Missing builtin (__builtin_clzs) when compiling with g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59874 --- Comment #6 from Uroš Bizjak --- (In reply to Allan Jensen from comment #5) > This is more problematic to fix in Qt itself. How can we determine if we > should/can use __builtin_clzs or __lzcnt16? > > Note the former is practically standard being supported by both older gcc > and clang. There is also the problem that we need to call a builtin, because > the C-intrinsics don't work as constexpr. Well, if the change makes so much pain, let's put these intrinsics back.
[Bug libstdc++/65434] Memory leak in pool constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65434 --- Comment #8 from Jonathan Wakely --- Please send patches to the libstdc++@ and gcc-patches@ mailing lists, rather than attaching them to closed bugs. https://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html
[Bug tree-optimization/78788] [7 Regression] ICE (segfault) on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78788 --- Comment #2 from Richard Biener --- Found new range for msgcnt_138: [-2147483646, +INF] Found new range for msgcnt_228: [-2147483646, +INF] Found new range for msgcnt_172: [-INF, 2147483645] Found new range for msgcnt_138: [-2147483646, +INF(OVF)] Found new range for msgcnt_228: [-2147483646, +INF(OVF)] Found new range for msgcnt_172: [-INF(OVF), 2147483645] Found new range for msgcnt_138: [-2147483646, +INF] Found new range for msgcnt_228: [-2147483646, +INF] Found new range for msgcnt_172: [-INF, 2147483645] Found new range for msgcnt_138: [-2147483646, +INF(OVF)] Found new range for msgcnt_228: [-2147483646, +INF(OVF)] Found new range for msgcnt_172: [-INF(OVF), 2147483645] Found new range for msgcnt_138: [-2147483646, +INF] Found new range for msgcnt_228: [-2147483646, +INF] Found new range for msgcnt_172: [-INF, 2147483645] another case... (bah). And the issue is: Visiting PHI node: msgcnt_138 = PHI Argument #0 (40 -> 36 executable) msgcnt_7: [0, +INF(OVF)] Argument #1 (35 -> 36 executable) msgcnt_172: [-INF(OVF), 2147483645] Meeting [0, +INF(OVF)] and [-INF(OVF), 2147483645] to VARYING Intersecting [-2147483646, msgcnt_7] and [-INF, +INF] Applying pattern match.pd:2941, generic-match.c:6568 Applying pattern match.pd:2931, generic-match.c:6507 Applying pattern match.pd:2244, generic-match.c:4056 Applying pattern match.pd:2953, generic-match.c:6645 Applying pattern match.pd:2238, generic-match.c:3532 Applying pattern match.pd:2957, generic-match.c:6665 to [-2147483646, +INF] Found new range for msgcnt_138: [-2147483646, +INF]
[Bug target/78791] New: [7.0 regression] ACATS cxf2001 failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78791 Bug ID: 78791 Summary: [7.0 regression] ACATS cxf2001 failure Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ebotcazou at gcc dot gnu.org Target Milestone: --- Target: ix86-*-* Created attachment 40320 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40320&action=edit Self-contained testcase ACATS cxf2001 fails on 32-bit x86 because Double_Divide of s-arit64.adb is miscompiled at -O2 by the STV pass. Self-contained testcase to be attached. eric@polaris:~/build/gcc/native> gnatchop adatest.txt splitting adatest.txt into: opt61.adb opt61_pkg.ads opt61_pkg.adb eric@polaris:~/build/gcc/native> gnatmake opt61 -O2 -m32 gcc -c -O2 -m32 --RTS=32 opt61.adb gcc -c -O2 -m32 --RTS=32 opt61_pkg.adb gnatbind --RTS=32 -x opt61.ali gnatlink opt61.ali -O2 -m32 eric@polaris:~/build/gcc/native> ./opt61 raised PROGRAM_ERROR : opt61.adb:19 explicit raise The testcase can be added to the gnat.dg testsuite as-is.
[Bug target/78791] [7.0 regression] ACATS cxf2001 failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78791 --- Comment #1 from Eric Botcazou --- > ACATS cxf2001 fails on 32-bit x86 because Double_Divide of s-arit64.adb is > miscompiled at -O2 by the STV pass. Self-contained testcase to be attached. AFAICS the issue is the management of stack slots by assign_386_stack_local.
[Bug tree-optimization/78788] [7 Regression] ICE (segfault) on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78788
--- Comment #3 from Richard Biener ---
Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c (revision 243599)
+++ gcc/tree-vrp.c (working copy)
@@ -365,10 +365,6 @@ set_value_range (value_range *vr, enum v
cmp = compare_values (min, max);
gcc_assert (cmp == 0 || cmp == -1 || cmp == -2);
-
- if (needs_overflow_infinity (TREE_TYPE (min)))
- gcc_assert (!is_overflow_infinity (min)
- || !is_overflow_infinity (max));
}
if (flag_checking
@@ -506,14 +502,9 @@ set_and_canonicalize_value_range (value_
}
}
- /* Drop [-INF(OVF), +INF(OVF)] to varying. */
- if (needs_overflow_infinity (TREE_TYPE (min))
- && is_overflow_infinity (min)
- && is_overflow_infinity (max))
-{
- set_value_range_to_varying (vr);
- return;
-}
+ /* Do not drop [-INF(OVF), +INF(OVF)] to varying. (OVF) has to be sticky
+ to make sure VRP iteration terminates, otherwise we can get into
+ oscillations. */
set_value_range (vr, t, min, max, equiv);
}
[Bug gcov-profile/78792] New: gfortran + gcov confused by #line directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78792 Bug ID: 78792 Summary: gfortran + gcov confused by #line directive Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: patrick.seewald at gmail dot com Target Milestone: --- $ cat example.in PROGRAM example PRINT *, "example" END PROGRAM $ cat example.f90 #line 1 "example.in" PROGRAM example PRINT *, "example" END PROGRAM $ gfortran -fprofile-arcs -ftest-coverage -cpp example.f90 -o example.out $ ./example.out $ gcov example.in File 'example.f90' Lines executed:100.00% of 3 Creating 'example.f90.gcov' $ cat example.f90.gcov -:0:Source:example.f90 -:0:Graph:example.gcno -:0:Data:example.gcda -:0:Runs:1 -:0:Programs:1 1:1:#line 1 "example.in" 1:2:PROGRAM example 2:3:PRINT *, "example" -:4:END PROGRAM The output example.f90.gcov refers to example.f90 instead of example.in. Note that the line statistics are shifted by one line, I guess they really refer to the line numbers of example.in. For some reason, the coverage report is correct if an #include statement is present: $ touch inc $ cat example2.in #include "inc" PROGRAM example2 PRINT *, "example2" END PROGRAM $ cat example2.f90 #line 1 "example2.in" #include "inc" PROGRAM example2 PRINT *, "example2" END PROGRAM $ gfortran -fprofile-arcs -ftest-coverage -cpp example2.f90 -o example2.out $ ./example2.out $ gcov example2.in File 'example2.in' Lines executed:100.00% of 3 Creating 'example2.in.gcov' $ cat example2.in.gcov -:0:Source:example2.in -:0:Graph:example2.gcno -:0:Data:example2.gcda -:0:Runs:1 -:0:Programs:1 -:1:#include "inc" 1:2:PROGRAM example2 1:3:PRINT *, "example2" 2:4:END PROGRAM
[Bug libgcc/78779] libgcc/soft-fp/op-common.h:900: possible missing break ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78779 --- Comment #1 from David Binderman --- Same thing a few lines further down in the same file: trunk/libgcc/soft-fp/op-common.h:913:10: warning: this statement may fall through [-Wimplicit-fallthrough=] Source code is case _FP_CLS_COMBINE (FP_CLS_INF, FP_CLS_NAN): \ case _FP_CLS_COMBINE (FP_CLS_ZERO, FP_CLS_NAN): \ R##_s = Y##_s;\ \ case _FP_CLS_COMBINE (FP_CLS_NORMAL, FP_CLS_INF): \ case _FP_CLS_COMBINE (FP_CLS_NORMAL, FP_CLS_ZERO): \ And a third case in the same file, line 1200: case _FP_CLS_COMBINE (FP_CLS_NORMAL, FP_CLS_ZERO): \ FP_SET_EXCEPTION (FP_EX_DIVZERO); \ case _FP_CLS_COMBINE (FP_CLS_INF, FP_CLS_ZERO): \
[Bug target/78791] [7.0 regression] ACATS cxf2001 failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78791
--- Comment #2 from Eric Botcazou ---
> AFAICS the issue is the management of stack slots by assign_386_stack_local.
In .combine:
(call_insn 181 180 182 22 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:SI ("__udivmoddi4") [flags 0x41]) [0 S1 A8])
(const_int 32 [0x20]))) 658 {*call_value}
(expr_list:REG_CALL_DECL (symbol_ref:SI ("__udivmoddi4") [flags 0x41])
(expr_list:REG_EH_REGION (const_int -2147483648 [0x8000])
(nil)))
(expr_list (use (mem:SI (plus:SI (reg/f:SI 7 sp)
(scratch:SI)) [0 S4 A8]))
(nil)))
(insn 182 181 183 22 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int 32 [0x20])))
(clobber (reg:CC 17 flags))
]) 210 {*addsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_ARGS_SIZE (const_int 0 [0])
(nil
(insn 183 182 184 22 (set (reg:DI 113 [ divmod_tmp_66 ])
(reg:DI 0 ax)) 81 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 0 ax)
(nil)))
(insn 184 183 185 22 (set (reg:DI 114 [ divmod_tmp_66+8 ])
(mem/c:DI (plus:SI (reg/f:SI 20 frame)
(const_int -8 [0xfff8])) [0 S8 A64])) 81
{*movdi_internal}
(nil))
In .stv2:
(call_insn 181 180 182 22 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:SI ("__udivmoddi4") [flags 0x41]) [0 S1 A8])
(const_int 32 [0x20]))) 658 {*call_value}
(expr_list:REG_CALL_DECL (symbol_ref:SI ("__udivmoddi4") [flags 0x41])
(expr_list:REG_EH_REGION (const_int -2147483648 [0x8000])
(nil)))
(expr_list (use (mem:SI (plus:SI (reg/f:SI 7 sp)
(scratch:SI)) [0 S4 A8]))
(nil)))
(insn 182 181 183 22 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int 32 [0x20])))
(clobber (reg:CC 17 flags))
]) 210 {*addsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_ARGS_SIZE (const_int 0 [0])
(nil
(insn 183 182 305 22 (set (reg:DI 113 [ divmod_tmp_66 ])
(reg:DI 0 ax)) 81 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 0 ax)
(nil)))
(insn 305 183 306 22 (set (mem/c:SI (plus:SI (reg/f:SI 20 frame)
(const_int -8 [0xfff8])) [0 S4 A64])
(subreg:SI (reg:DI 113 [ divmod_tmp_66 ]) 0)) -1
(nil))
(insn 306 305 307 22 (set (mem/c:SI (plus:SI (reg/f:SI 20 frame)
(const_int -4 [0xfffc])) [0 S4 A32])
(subreg:SI (reg:DI 113 [ divmod_tmp_66 ]) 4)) -1
(nil))
(insn 307 306 184 22 (set (reg:DI 197)
(mem/c:DI (plus:SI (reg/f:SI 20 frame)
(const_int -8 [0xfff8])) [0 S8 A64])) -1
(nil))
(insn 184 307 185 22 (set (reg:DI 114 [ divmod_tmp_66+8 ])
(mem/c:DI (plus:SI (reg/f:SI 20 frame)
(const_int -8 [0xfff8])) [0 S8 A64])) 81
{*movdi_internal}
(nil))
[Bug libfortran/78793] New: list_read.c: 7 * possible unintended fallthrough ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78793 Bug ID: 78793 Summary: list_read.c: 7 * possible unintended fallthrough ? Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- I just tried a build of trunk fortran and got this: 1. trunk/libgfortran/io/list_read.c:975:10: warning: this statement may fall through [-Wimplicit-fallthrough=] Source code is case '!': if (!dtp->u.p.namelist_mode) goto bad_integer; CASE_SEPARATORS:/* Single null. */ Suggest either document the fallthrough or add a possible missing break. 2. ../../../trunk/libgfortran/io/list_read.c:1033:10: warning: this statement may fall through [-Wimplicit-fallthrough=] ../../../trunk/libgfortran/io/list_read.c:852:10: warning: this statement may fall through [-Wimplicit-fallthrough=] ../../../trunk/libgfortran/io/list_read.c:1646:10: warning: this statement may fall through [-Wimplicit-fallthrough=] ../../../trunk/libgfortran/io/list_read.c:1705:7: warning: this statement may fall through [-Wimplicit-fallthrough=] ../../../trunk/libgfortran/io/list_read.c:1524:10: warning: this statement may fall through [-Wimplicit-fallthrough=] ../../../trunk/libgfortran/io/list_read.c:1401:7: warning: this statement may fall through [-Wimplicit-fallthrough=] Duplicates.
[Bug libgcc/78779] libgcc/soft-fp/op-common.h:900: possible missing break ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78779 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- soft-fp is part of the GNU C Library so should be fixed there.
[Bug tree-optimization/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78529 James Greenhalgh changed: What|Removed |Added CC||jgreenhalgh at gcc dot gnu.org --- Comment #19 from James Greenhalgh --- That this only happens for LTO builds is the key here. gcc/testsuite/gcc.c-torture/execute/builtins/strcat-chk-lib.c includes gcc/testsuite/gcc.c-torture/execute/builtins/lib/chk.c which defines a memset. In an LTO build, that definition of memset is visible, here is what it looks like after code generation: memset: sub x3, x2, #1 cbz x2, .L158 and w1, w1, 255 .p2align 2 .L159: strbw1, [x0, x3] sub x3, x3, #1 cmn x3, #1 bne .L159 .L158: adr x1, .LANCHOR0 ldr w1, [x1, 2096] ret Clearly x4 is not going to be clobbered there, so ipa-ra can assume it isn't used and is safe to clobber. At final link time, on aarch64-none-elf builds with specs files that are pulling in start-up and tear-down code which uses a library memset, the linker may pull in the library memset before it sees the memset from lib/chk.c . That would be an error: /tmp/ccpefK3l.ltrans0.ltrans.o: In function `memset': :(.text+0x4a0): multiple definition of `memset' .../aarch64-none-elf/lib/libc.a(lib_a-memset.o): .../newlib/libc/machine/aarch64/memset.S:90: first defined here Were it not for the flag added to resolve PR55994 -Wl,--allow-multiple-definition . So, in my opinion, the testcase is broken and could always have failed in this way. The combination of register allocation, LTO and order the linker sees symbols explains why this is hard to reproduce.
[Bug c++/78765] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: in cp_build_addr_expr_1, at cp/typeck.c:5708)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78765 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- The new code in cp_build_addr_expr_1 says CASE_CONVERT: case FLOAT_EXPR: case FIX_TRUNC_EXPR: /* We should have handled this above in the lvalue_kind check. */ we arrived here with NOP_EXPR, but we hadn't issued an error in this block: /* Anything not already handled and not a true memory reference is an error. */ if (TREE_CODE (argtype) != FUNCTION_TYPE && TREE_CODE (argtype) != METHOD_TYPE) because strict_lvalue is false. ARG is (const struct ValueType) doubleval.
[Bug bootstrap/78756] Missing prefix in the name of gfortran.info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78756
--- Comment #1 from Mojca Miklavec ---
In the meantime I realized that the part of our build system that supports
compiling cross-tools does the following:
---> Extracting gcc-6.2.0.tar.bz2
---> Patching cpp.texi: s|setfilename cpp.info|setfilename
x86_64-w64-mingw32-cpp.info|g
---> Patching cpp.texi: s|(cpp)|(x86_64-w64-mingw32-cpp)|g
---> Patching cpp.texi: s|@file{cpp}|@file{x86_64-w64-mingw32-cpp}|g
---> Patching Makefile.in:
s:[[:<:]]cpp\.(info|pod|texi):x86_64-w64-mingw32-&:g
---> Patching Makefile.in:
s|--info-dir=$(DESTDIR)$(infodir)|--dir-file=$(DESTDIR)$(infodir)/x86_64-w64-mingw32-gcc-dir|g
---> Patching cppinternals.texi: s|setfilename cppinternals.info|setfilename
x86_64-w64-mingw32-cppinternals.info|g
---> Patching cppinternals.texi:
s|(cppinternals)|(x86_64-w64-mingw32-cppinternals)|g
---> Patching cppinternals.texi:
s|@file{cppinternals}|@file{x86_64-w64-mingw32-cppinternals}|g
---> Patching Makefile.in:
s:[[:<:]]cppinternals\.(info|pod|texi):x86_64-w64-mingw32-&:g
---> Patching Makefile.in:
s|--info-dir=$(DESTDIR)$(infodir)|--dir-file=$(DESTDIR)$(infodir)/x86_64-w64-mingw32-gcc-dir|g
---> Patching gcc.texi: s|setfilename gcc.info|setfilename
x86_64-w64-mingw32-gcc.info|g
---> Patching gcc.texi: s|(gcc)|(x86_64-w64-mingw32-gcc)|g
---> Patching gcc.texi: s|@file{gcc}|@file{x86_64-w64-mingw32-gcc}|g
---> Patching Makefile.in:
s:[[:<:]]gcc\.(info|pod|texi):x86_64-w64-mingw32-&:g
---> Patching Makefile.in:
s|--info-dir=$(DESTDIR)$(infodir)|--dir-file=$(DESTDIR)$(infodir)/x86_64-w64-mingw32-gcc-dir|g
---> Patching gccint.texi: s|setfilename gccint.info|setfilename
x86_64-w64-mingw32-gccint.info|g
---> Patching gccint.texi: s|(gccint)|(x86_64-w64-mingw32-gccint)|g
---> Patching gccint.texi: s|@file{gccint}|@file{x86_64-w64-mingw32-gccint}|g
---> Patching Makefile.in:
s:[[:<:]]gccint\.(info|pod|texi):x86_64-w64-mingw32-&:g
---> Patching Makefile.in:
s|--info-dir=$(DESTDIR)$(infodir)|--dir-file=$(DESTDIR)$(infodir)/x86_64-w64-mingw32-gcc-dir|g
---> Patching gccinstall.info: s|setfilename gccinstall.info|setfilename
x86_64-w64-mingw32-gccinstall.info|g
---> Patching gccinstall.info:
s|(gccinstall)|(x86_64-w64-mingw32-gccinstall)|g
---> Patching gccinstall.info:
s|@file{gccinstall}|@file{x86_64-w64-mingw32-gccinstall}|g
---> Patching Makefile.in:
s:[[:<:]]gccinstall\.(info|pod|info):x86_64-w64-mingw32-&:g
---> Patching Makefile.in:
s|--info-dir=$(DESTDIR)$(infodir)|--dir-file=$(DESTDIR)$(infodir)/x86_64-w64-mingw32-gcc-dir|g
---> Patching libquadmath.info: s|setfilename libquadmath.info|setfilename
x86_64-w64-mingw32-libquadmath.info|g
---> Patching libquadmath.info:
s|(libquadmath)|(x86_64-w64-mingw32-libquadmath)|g
---> Patching libquadmath.info:
s|@file{libquadmath}|@file{x86_64-w64-mingw32-libquadmath}|g
---> Patching Makefile.in:
s:[[:<:]]libquadmath\.(info|pod|info):x86_64-w64-mingw32-&:g
---> Patching Makefile.in:
s|--info-dir=$(DESTDIR)$(infodir)|--dir-file=$(DESTDIR)$(infodir)/x86_64-w64-mingw32-gcc-dir|g
---> Patching Makefile.in: /^install:/s/ .*//
---> Configuring x86_64-w64-mingw32-gcc-bootstrap
So maybe "proper" names of info files come from our build system after all and
nobody bothered ever testing the patches for fortran. I need to dig a bit
further.
It would of course be awesome if none of that patching was needed, but ...
[Bug tree-optimization/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78529 --- Comment #20 from Jakub Jelinek --- Unless you do something very nasty in the spec files (in which case you should just avoid those tests), the user specified objects should always appear before stuff coming from -lc unless -lc is specified first on the command line.
[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516 Peter Bergner changed: What|Removed |Added Attachment #40317|0 |1 is obsolete|| --- Comment #5 from Peter Bergner --- Created attachment 40321 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40321&action=edit Updated fix (In reply to Peter Bergner from comment #4) > (define_insn "*mov_si_e500_subreg0_2_be" > - [(set (match_operand:SI 0 "rs6000_nonimmediate_operand" "+r,m") > - (subreg:SI (match_operand:SPE64TF 1 "register_operand" "+r,&r") 0))] > + [(set (match_operand:SI 0 "rs6000_nonimmediate_operand" "=r,&m") > + (subreg:SI (match_operand:SPE64TF 1 "register_operand" "r,r") 0))] >"WORDS_BIG_ENDIAN > && ((TARGET_E500_DOUBLE && (mode == DFmode || mode == > TFmode)) > || (TARGET_SPE && mode != DFmode && mode != TFmode))" >"@ > - evmergehi %0,%0,%1 > + evmergelohi %0,%1,%1 > evmergelohi %1,%1,%1\;stw%U0%X0 %1,%0" >[(set_attr "length" "4,8")]) Of course now that I've had time to think of this, I think the correct thing here isn't to move the earlyclobber to the 'm' constraint, but to add the '+' modifier to the '&r' constraint to show that is is not only an input, but it is modified as well. ...and '+' has to be at the beginning of the constraint string, hence why it was located where it was originally. :-) So that leaves us with this smaller change: (define_insn "*mov_si_e500_subreg0_2_be" - [(set (match_operand:SI 0 "rs6000_nonimmediate_operand" "+r,m") + [(set (match_operand:SI 0 "rs6000_nonimmediate_operand" "=r,m") (subreg:SI (match_operand:SPE64TF 1 "register_operand" "+r,&r") 0))] "WORDS_BIG_ENDIAN && ((TARGET_E500_DOUBLE && (mode == DFmode || mode == TFmode)) || (TARGET_SPE && mode != DFmode && mode != TFmode))" "@ - evmergehi %0,%0,%1 + evmergelohi %0,%1,%1 evmergelohi %1,%1,%1\;stw%U0%X0 %1,%0" [(set_attr "length" "4,8")]) Joseph, ignore the last patch and try this one.
[Bug target/78794] New: [7 Regression] We noticed ~9% regression in 32-bit mode for 462.libquntum on Avoton after r243202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78794 Bug ID: 78794 Summary: [7 Regression] We noticed ~9% regression in 32-bit mode for 462.libquntum on Avoton after r243202 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ysrumyan at gmail dot com Target Milestone: --- STV phase does not recognize some patterns after this revision, regression can be reproduced with attached simple test-case. Note that before this revision the following code has been produced for loop body: .L4: movq(%eax), %xmm1 movdqa %xmm1, %xmm4 pand%xmm2, %xmm4 movdqa %xmm4, %xmm0 pxor%xmm2, %xmm0 punpcklqdq %xmm0, %xmm0 ptest %xmm0, %xmm0 jne .L3 pxor%xmm3, %xmm1 movq%xmm1, (%eax) .L3: addl$12, %eax cmpl%edx, %eax jne .L4 but after we see .L4: movl4(%eax), %edi movl(%eax), %esi movl%edi, %ebx movl%esi, %ecx notl%ebx andl4(%esp), %ebx notl%ecx andl(%esp), %ecx movl%ebx, %ebp orl %ecx, %ebp jne .L3 xorl8(%esp), %esi xorl12(%esp), %edi movl%esi, (%eax) movl%edi, 4(%eax) .L3: addl$12, %eax cmpl%edx, %eax jne .L4
[Bug target/78794] [7 Regression] We noticed ~9% regression in 32-bit mode for 462.libquntum on Avoton after r243202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78794 --- Comment #1 from Yuri Rumyantsev --- Created attachment 40322 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40322&action=edit test-case to reproduce Compile with -O2 -march=slm -m32 options to reproduce.
[Bug target/78794] [7 Regression] We noticed ~9% regression in 32-bit mode for 462.libquntum on Avoton after r243202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78794 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Target Milestone|--- |7.0
[Bug target/78791] [7 regression] ACATS cxf2001 failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78791 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0 Summary|[7.0 regression] ACATS |[7 regression] ACATS |cxf2001 failure |cxf2001 failure
[Bug middle-end/78786] GCC hangs/out of memory calling sprintf with large precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78786
--- Comment #3 from Vincent Lefèvre ---
Well, concerning "%.*Rf", indeed, mpfr_snprintf allocates 2 GB for a short
period. But I notice that glibc is much worse. Consider the following program.
#include
#include
#include
#include
int main (int argc, char **argv)
{
mpfr_t x;
int i, m, r;
if (argc != 3)
exit (1);
i = atoi (argv[1]);
m = atoi (argv[2]);
if (i <= 0)
i = INT_MAX + i;
mpfr_init2 (x, 64);
mpfr_set_ui (x, 0, MPFR_RNDN);
r =
m == 0 ? snprintf (0, 0, "%.*f", i, 0.0) :
m == 1 ? gmp_snprintf (0, 0, "%.*f", i, 0.0) :
m == 2 ? mpfr_snprintf (0, 0, "%.*f", i, 0.0) :
m == 3 ? mpfr_snprintf (0, 0, "%.*Rf", i, x) :
(fprintf (stderr, "bad value of m\n"), -2);
printf ("%d\n", r);
mpfr_clear (x);
return 0;
}
On -33 0, this program outputs:
2147483616
10487712
i.e. glibc uses 10 GB (and it takes much time).
On -33 3, this program outputs:
2147483616
2099120
i.e. MPFR only uses 2 GB.
If I replace the number 0 by 0.5 and use the size 2000, then MPFR still
takes less memory than glibc; this time, MPFR is much slower than glibc, but
this was expected (the very specific case small-precision input with
large-precision output is just not optimized).
Now, in both cases, it seems that both glibc and MPFR compute the result even
though it will not be used (in the worst cases, this may be necessary in order
to distinguish between 9.999...99 and 10.000...00, which have different sizes,
but not in the average case). Is this a problem in practice? If this is done to
obtain the size of a buffer for a new snprintf call with the result, then not
really.
An easier improvement that could be done in MPFR is to detect early int
overflow, but this is here a corner case and the user could have first done
optimizations on his side. Note that glibc is buggy in this respect:
https://sourceware.org/bugzilla/show_bug.cgi?id=17829
[Bug middle-end/78786] GCC hangs/out of memory calling sprintf with large precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78786 --- Comment #4 from Vincent Lefèvre --- (In reply to Vincent Lefèvre from comment #3) > On -33 0, this program outputs: > > 2147483616 > 10487712 I forgot to say that I used "/usr/bin/time -f %M ..." to get the second output number, which is the peak memory, where /usr/bin/time is GNU time.
[Bug libstdc++/65434] Memory leak in pool constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65434 --- Comment #9 from Jonathan Wakely --- (Although I have a simpler patch that does something similar, as well as allowing the arena size to be controlled form the environment).
[Bug tree-optimization/78788] [7 Regression] ICE (segfault) on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78788
--- Comment #4 from Matthias Klose ---
$ cat ghosts.i
int a;
long b;
long c;
void d() {
int e = 0;
for (; b; b++)
if (c) {
e++;
e++;
}
while (e)
a = e -= 2;
}
[Bug target/78794] [7 Regression] We noticed ~9% regression in 32-bit mode for 462.libquntum on Avoton after r243202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78794
--- Comment #2 from Uroš Bizjak ---
Previously we entered STV pass with:
(insn 32 31 33 4 (parallel [
(set (reg:DI 118)
(and:DI (reg:DI 88 [ _5 ])
(reg:DI 97 [ _24 ])))
(clobber (reg:CC 17 flags))
]) pr78794-1.c:24 391 {*anddi3_doubleword}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 33 32 34 4 (parallel [
(set (reg:DI 119)
(xor:DI (reg:DI 97 [ _24 ])
(reg:DI 118)))
(clobber (reg:CC 17 flags))
]) pr78794-1.c:24 415 {*xordi3_doubleword}
(expr_list:REG_DEAD (reg:DI 118)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
and the gain was calculated for two instructions.
After the mentioned revision, we enter STV pass with:
(note 32 31 33 4 NOTE_INSN_DELETED)
(insn 33 32 34 4 (parallel [
(set (reg:DI 119)
(and:DI (not:DI (reg:DI 88 [ _5 ]))
(reg:DI 97 [ _24 ])))
(clobber (reg:CC 17 flags))
]) "pr78794.c":24 395 {*andndi3_doubleword}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
And the gain calculated is considerably lower, since we convert one insn only.
The patch in the mentioned revision is beneficial, but the cost for andn should
be adjusted, since one insn replaces:
notl%ebx
andl4(%esp), %ebx
notl%ecx
andl(%esp), %ecx
Yuri, can you please adjust the costs?
[Bug debug/59171] pretty printers: reverse iterator off by one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59171 Jan Kratochvil changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #2 from Jan Kratochvil --- valid for: gcc-6.2.1-2.fc26.x86_64
[Bug debug/59170] pretty printers: end iterator invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170 Jan Kratochvil changed: What|Removed |Added CC||redi at gcc dot gnu.org Version|4.8.2 |6.2.1 --- Comment #4 from Jan Kratochvil --- gcc-6.2.1-2.fc26.x86_64
[Bug target/78794] [7 Regression] We noticed ~9% regression in 32-bit mode for 462.libquntum on Avoton after r243202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78794
--- Comment #3 from Uroš Bizjak ---
Perhaps as simple as:
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 1cd1cd8..6899d4f 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3424,7 +3424,7 @@ dimode_scalar_chain::compute_convert_gain ()
}
else if (GET_CODE (src) == NEG
|| GET_CODE (src) == NOT)
- gain += ix86_cost->add - COSTS_N_INSNS (1);
+ gain += ix86_cost->add - COSTS_N_INSNS (2);
else if (GET_CODE (src) == COMPARE)
{
/* Assume comparison cost is the same. */
[Bug debug/59161] GDB pretty printers: iterator->reference not printed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59161 Jan Kratochvil changed: What|Removed |Added CC||redi at gcc dot gnu.org Component|libstdc++ |debug Version|4.9.0 |6.2.1 --- Comment #3 from Jan Kratochvil --- valid for: gcc-6.2.1-2.fc26.x86_64
[Bug target/78794] [7 Regression] We noticed ~9% regression in 32-bit mode for 462.libquntum on Avoton after r243202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78794
--- Comment #4 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #3)
> Perhaps as simple as:
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 1cd1cd8..6899d4f 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -3424,7 +3424,7 @@ dimode_scalar_chain::compute_convert_gain ()
> }
>else if (GET_CODE (src) == NEG
>|| GET_CODE (src) == NOT)
> - gain += ix86_cost->add - COSTS_N_INSNS (1);
> + gain += ix86_cost->add - COSTS_N_INSNS (2);
>else if (GET_CODE (src) == COMPARE)
> {
> /* Assume comparison cost is the same. */
Bah, totally wrong patch.
pandn gain is not modelled at all.
[Bug c++/70909] Libiberty Demangler segfaults (4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909 --- Comment #42 from Mark Wielaard --- (In reply to Markus Trippelsdorf from comment #41) > (In reply to Mark Wielaard from comment #40) > > But I still haven't figured out why we need to allow 2 levels of recursion > > for some of the cases. See the XXX in the patch. I don't feel I can propose > > this unless we figure out why the level needs to be 2 (and not 3 or...) > > > > If we figure that out we should add the explanation to the comment. Then we > > can propose it on gcc-patches. > > Well, then just use one level of recursion in the patch. And increase the > level > in a possible follow-up patch later on. This will fix most stack overflows. > If we fail to demangle some weird symbols at first, so be it. That would break demangling of symbols from e.g. bug 68700 _ZN8futurizeI13frozen_schemaE5applyIRZN7seastar7shardedIN7service13storage_proxyEE9invoke_onIZZNS6_22init_messaging_serviceEvENKUljN5utils4UUIDEE8_clEjSA_EUlOT_E_6futureIJS0_T0_jSD_EUlvE_JEEESG_SD_DpOT0_ or bug #70517 _ZSt4moveIRZN11tconcurrent6futureIvE4thenIZ5awaitIS2_EDaOT_EUlRKS6_E_EENS1_INSt5decayIDTclfp_defpTEEE4typeEEES7_EUlvE_EONSt16remove_referenceIS6_E4typeES7_ I just haven't had time to analyze why. If someone could trace through these and see why some components have to be printed up to 3 times (or more?) that would be helpful.
[Bug libstdc++/59170] pretty printers: end iterator invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-13 Component|debug |libstdc++ Ever confirmed|0 |1
[Bug libstdc++/59171] pretty printers: reverse iterator off by one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59171 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-13 Component|debug |libstdc++ Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely --- (In reply to Jan Kratochvil from comment #0) > reverse_iterator seems unimplemented to me. This is correct. There's no #2 really. There is no pretty printer for reverse iterators (which is #1), so it prints the object's members one-by-one. The 'current' member is an iterator to the previous position, which does have a pretty-printer, and so gets dereferenced and printed. IMHO printing an iterator should not print the thing it points to automatically, because that assumes it's a valid iterator (bug 59170). If we add a pretty printer for reference_iterator we could make it do something more sensible.
[Bug target/78794] [7 Regression] We noticed ~9% regression in 32-bit mode for 462.libquntum on Avoton after r243202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78794
--- Comment #5 from Uroš Bizjak ---
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 1cd1cd8..f718040 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3417,7 +3417,10 @@ dimode_scalar_chain::compute_convert_gain ()
|| GET_CODE (src) == AND)
{
gain += ix86_cost->add;
- if (CONST_INT_P (XEXP (src, 0)))
+ /* Additional gain for andnot. */
+ if (GET_CODE (XEXP (src, 0)) == NOT)
+ gain += ix86_cost->add;
+ else if (CONST_INT_P (XEXP (src, 0)))
gain -= vector_const_cost (XEXP (src, 0));
if (CONST_INT_P (XEXP (src, 1)))
gain -= vector_const_cost (XEXP (src, 1));
results in:
.L4:
movq(%eax), %xmm1
movdqa %xmm1, %xmm4
pandn %xmm2, %xmm4
movdqa %xmm4, %xmm0
punpcklqdq %xmm4, %xmm0
ptest %xmm0, %xmm0
jne .L3
pxor%xmm3, %xmm1
movq%xmm1, (%eax)
.L3:
addl$12, %eax
cmpl%edx, %eax
jne .L4
Please note pandn that replaces pand/pxor.
Can you please test the patch on your codebase?
[Bug libstdc++/59170] pretty printers: end iterator invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170 --- Comment #5 from Jonathan Wakely --- I think it's simply wrong to automatically dereference iterators. GDB doesn't do that when printing pointers, so why do the pretty printers do it for iterators? There are loads of cases where it does the wrong thing, not only for past-the-end iterators but also for default-constructed ones that might contain uninitialized pointers.
[Bug libstdc++/65434] Memory leak in pool constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65434 --- Comment #10 from Jonathan Wakely --- See https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01158.html
[Bug target/59874] Missing builtin (__builtin_clzs) when compiling with g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59874
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2016-12-13
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
Ever confirmed|0 |1
--- Comment #7 from Uroš Bizjak ---
Created attachment 40323
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40323&action=edit
Patch that adds __builtin_{clzs,ctzs}
Does the attached patch (vs gcc-7) works for you?
[Bug debug/59161] GDB pretty printers: iterator->reference not printed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59161 --- Comment #4 from Jonathan Wakely --- This seems like a GDB bug, since all the pretty printer does is: def to_string(self): return self.val['_M_current'].dereference() So stringifying that is done by GDB, and should produce the "ref = @x" part. It does the right thing if we do: def to_string(self): return str(self.val['_M_current'].dereference()) But I don't think that should be necessary.
[Bug tree-optimization/78725] [7 Regression] wrong code at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78725 --- Comment #6 from Michael Matz --- Author: matz Date: Tue Dec 13 14:14:41 2016 New Revision: 243606 URL: https://gcc.gnu.org/viewcvs?rev=243606&root=gcc&view=rev Log: Fix pr78725 PR tree-optimization/78725 * tree-ssa-loop-split.c (split_at_bb_p): Check for overflow and at correct use point. testsuite/ PR tree-optimization/78725 * gcc.dg/pr78725.c: New test. * gcc.dg/pr78725-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr78725-2.c trunk/gcc/testsuite/gcc.dg/pr78725.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-split.c
[Bug libstdc++/59170] pretty printers: end iterator invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170 --- Comment #6 from Jan Kratochvil --- (In reply to Jonathan Wakely from comment #5) > I think it's simply wrong to automatically dereference iterators. GDB > doesn't do that when printing pointers, so why do the pretty printers do it > for iterators? The difference is that pointer is memory-unmanaged and this is not fixable. But C++ data structures have memory management (at least they should have). > There are loads of cases where it does the wrong thing, not only for > past-the-end iterators but also for default-constructed ones that might > contain uninitialized pointers. Default-constructed iterators can be detected by _M_sequence==nullptr (-D_GLIBCXX_DEBUG). This all depends more on a different non-pretty-printers feature I plan to file for libstdc++ for years but I have never done so yet. With -D_GLIBCXX_DEBUG the iterators could be memory-managed - they already track their container by _M_sequence. The container could also track all its live iterators, elements could track iterators pointing at them (and properly invalidate them upon container updates) etc. Deleting the container would invalidate all its iterators etc. Accessing an invalidated iterator would then immediately assert. Then it is safe to pretty print any iterator as the iterator itself knows whether it has been invalidated or not.
[Bug c++/77830] internal compiler error: in output_constructor_regular_field, at varasm.c:4968, when using constexpr (with testcase)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77830 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 40324 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40324&action=edit gcc7-pr77830.patch Untested fix.
[Bug target/78794] [7 Regression] We noticed ~9% regression in 32-bit mode for 462.libquntum on Avoton after r243202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78794
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
(In reply to Uroš Bizjak from comment #5)
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 1cd1cd8..f718040 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -3417,7 +3417,10 @@ dimode_scalar_chain::compute_convert_gain ()
>|| GET_CODE (src) == AND)
> {
> gain += ix86_cost->add;
> - if (CONST_INT_P (XEXP (src, 0)))
> + /* Additional gain for andnot. */
> + if (GET_CODE (XEXP (src, 0)) == NOT)
> + gain += ix86_cost->add;
> + else if (CONST_INT_P (XEXP (src, 0)))
Shouldn't that take into account whether there is a scalar andn or not?
I.e. only bump the gain if !TARGET_BMI?
[Bug fortran/78737] [OOP] linking error with deferred, undefined user-defined derived-type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78737 --- Comment #25 from janus at gcc dot gnu.org --- Author: janus Date: Tue Dec 13 14:28:17 2016 New Revision: 243609 URL: https://gcc.gnu.org/viewcvs?rev=243609&root=gcc&view=rev Log: 2016-12-13 Janus Weil Paul Thomas PR fortran/78737 * gfortran.h (gfc_find_typebound_dtio_proc): New prototype. * interface.c (gfc_compare_interfaces): Whitespace fix. (gfc_find_typebound_dtio_proc): New function. (gfc_find_specific_dtio_proc): Use it. Improve error recovery. * trans-io.c (get_dtio_proc): Implement polymorphic calls to DTIO procedures. 2016-12-13 Janus Weil Paul Thomas PR fortran/78737 * gfortran.dg/dtio_19.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/dtio_19.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/ChangeLog
[Bug target/78794] [7 Regression] We noticed ~9% regression in 32-bit mode for 462.libquntum on Avoton after r243202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78794 --- Comment #7 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #6) > Shouldn't that take into account whether there is a scalar andn or not? > I.e. only bump the gain if !TARGET_BMI? Yes, this is a good idea.
[Bug libstdc++/59170] pretty printers: end iterator invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170
--- Comment #7 from Jonathan Wakely ---
(In reply to Jan Kratochvil from comment #6)
> (In reply to Jonathan Wakely from comment #5)
> > I think it's simply wrong to automatically dereference iterators. GDB
> > doesn't do that when printing pointers, so why do the pretty printers do it
> > for iterators?
>
> The difference is that pointer is memory-unmanaged and this is not fixable.
> But C++ data structures have memory management (at least they should have).
That doesn't help:
std::vector::iterator it;
{
std::vector v{1};
it = v.begin();
}
The iterator is safely initialized, safely updated to a valid value, but is not
dereferenceable after the last statement.
"print it" should not automatically dereference.
> > There are loads of cases where it does the wrong thing, not only for
> > past-the-end iterators but also for default-constructed ones that might
> > contain uninitialized pointers.
>
> Default-constructed iterators can be detected by _M_sequence==nullptr
> (-D_GLIBCXX_DEBUG).
It works for the example above as well, and I'll make the printers do that. But
most code isn't compiled with debug mode enabled.
[Bug tree-optimization/78725] [7 Regression] wrong code at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78725 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed.
[Bug fortran/78737] [OOP] linking error with deferred, undefined user-defined derived-type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78737 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|pault at gcc dot gnu.org |janus at gcc dot gnu.org Target Milestone|--- |7.0 --- Comment #26 from janus at gcc dot gnu.org --- AFAICS r243609 fixes all the various example codes posted here. Apart from one exception: Comment 9 is rejected with these errors: c9.f90:28:13: procedure :: write_formatted 1 Error: Argument ‘this’ of ‘write_formatted’ with PASS(this) at (1) must be of the derived-type ‘non_abstract_child2’ c9.f90:36:13: procedure :: write_formatted 1 Error: Argument ‘this’ of ‘write_formatted’ with PASS(this) at (1) must be of the derived-type ‘non_abstract_child3’ However, those already appear with version 6.2, and I hope they are correct. Can anyone confirm this suspicion? If yes, this PR can be closed ...
[Bug libstdc++/59170] pretty printers: end iterator invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170
--- Comment #8 from Jan Kratochvil ---
(In reply to Jonathan Wakely from comment #7)
> That doesn't help:
>
> std::vector::iterator it;
> {
> std::vector v{1};
> it = v.begin();
> }
>
> The iterator is safely initialized, safely updated to a valid value, but is
> not dereferenceable after the last statement.
At the "}" line container gets destructed which should invalidate "it"
according to my last paragraph of Comment 6 and then "print it" would print a
message "invalidated iterator". Sure fully-managed iterators are a larger
feature request than this PR.
> "print it" should not automatically dereference.
This is GCC maintainers opinion; not mine.
> But most code isn't compiled with debug mode enabled.
IMO all code for debugging with pretty printers is compiled with debug mode
enabled. The other case are Linux system -O2 -g packages which are not really
debuggable up to the level of C++ containers at all. One is glad to get a
partially readable backtrace for a crash of a system package.
[Bug target/78794] [7 Regression] We noticed ~9% regression in 32-bit mode for 462.libquntum on Avoton after r243202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78794
--- Comment #8 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #7)
> Yes, this is a good idea.
Also, since pandn on non-BMI target replaces four arith insns with one, the
gain should be raised for 2 * ix86_cost->add for a total of 3 * ix86_cost->add.
The final patch is thus:
--cut here--
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 1cd1cd8..6a746b2 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3417,7 +3417,11 @@ dimode_scalar_chain::compute_convert_gain ()
|| GET_CODE (src) == AND)
{
gain += ix86_cost->add;
- if (CONST_INT_P (XEXP (src, 0)))
+ /* Additional gain for andnot for targets without BMI. */
+ if (GET_CODE (XEXP (src, 0)) == NOT
+ && !TARGET_BMI)
+ gain += 2 * ix86_cost->add;
+ else if (CONST_INT_P (XEXP (src, 0)))
gain -= vector_const_cost (XEXP (src, 0));
if (CONST_INT_P (XEXP (src, 1)))
gain -= vector_const_cost (XEXP (src, 1));
--cut here-
Please also note that on BMI targets, the attached testcase won't be converted,
which is a good thing - the loop on BMI targets looks like:
.L4:
movl4(%eax), %edi
andn4(%esp), %edi, %ebx
movl(%eax), %esi
movl%ebx, %ebp
andn(%esp), %esi, %ecx
orl %ecx, %ebp
jne .L3
xorl8(%esp), %esi
xorl12(%esp), %edi
movl%esi, (%eax)
movl%edi, 4(%eax)
.L3:
addl$12, %eax
cmpl%edx, %eax
jne .L4
[Bug c++/69953] [5/6/7 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 Vincent Lefèvre changed: What|Removed |Added CC||vincent-gcc at vinc17 dot net --- Comment #22 from Vincent Lefèvre --- I get the same kind of errors with "make check" for GMP 6.1.1 by using GCC 6.2.1 and LTO (-flto=jobserve -fuse-linker-plugin), e.g. /tmp/ccZvS3pG.ltrans0.ltrans.o: In function `main': :(.text.startup+0xc): undefined reference to `tests_start' :(.text.startup+0x17): undefined reference to `mp_trace_base' :(.text.startup+0x43): undefined reference to `__gmpn_random' [...] but this is plain C, not C++. Is this the same bug? (I'm wondering because this bug is attributed to the c++ component.)
[Bug c++/69953] [5/6/7 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 --- Comment #23 from Markus Trippelsdorf --- (In reply to Vincent Lefèvre from comment #22) > I get the same kind of errors with "make check" for GMP 6.1.1 by using GCC > 6.2.1 and LTO (-flto=jobserve -fuse-linker-plugin), e.g. > > /tmp/ccZvS3pG.ltrans0.ltrans.o: In function `main': > :(.text.startup+0xc): undefined reference to `tests_start' > :(.text.startup+0x17): undefined reference to `mp_trace_base' > :(.text.startup+0x43): undefined reference to `__gmpn_random' > [...] > > but this is plain C, not C++. Is this the same bug? (I'm wondering because > this bug is attributed to the c++ component.) No, this must be a different issue.
[Bug lto/78795] New: LTO causes undefined reference errors when linking with GMP "make check"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78795 Bug ID: 78795 Summary: LTO causes undefined reference errors when linking with GMP "make check" Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: vincent-gcc at vinc17 dot net Target Milestone: --- With GCC 4.9.4 and 6.2.1 under GNU/Linux (Debian/sid), when I build GMP 6.1.1 with --disable-shared CFLAGS="-march=native -O3 -flto=jobserve -fuse-linker-plugin" then "make check", I get errors like: /tmp/ccw6C9Xr.ltrans0.ltrans.o: In function `main': :(.text.startup+0xb): undefined reference to `tests_start' :(.text.startup+0x11): undefined reference to `mp_trace_base' :(.text.startup+0x35): undefined reference to `__gmpn_random' :(.text.startup+0x3f): undefined reference to `ref_bswap_limb' :(.text.startup+0x74): undefined reference to `mpn_trace' :(.text.startup+0x88): undefined reference to `mpn_trace' :(.text.startup+0x9c): undefined reference to `mpn_trace' :(.text.startup+0xa6): undefined reference to `tests_end' collect2: error: ld returned 1 exit status These errors are similar to those from bug 69953, but with 2 differences: bug 69953 is about C++ (compiled with g++, vs gcc here) and it is known to work with GCC 4.9.2.
[Bug fortran/78781] [7 Regression] [Coarray] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1588
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78781 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Summary|[7 Regression] ICE in |[7 Regression] [Coarray] |gfc_deallocate_scalar_with_ |ICE in |status, at |gfc_deallocate_scalar_with_ |fortran/trans.c:1588|status, at ||fortran/trans.c:1588 --- Comment #2 from janus at gcc dot gnu.org --- This slightly simpler test case (without polymorphism) runs into the same ICE: module m type t integer, pointer :: z end type contains function f(x) type(t) :: x[*] if ( associated(x%z) ) deallocate(x%z) end end
[Bug c++/69953] [5/6/7 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 --- Comment #24 from Vincent Lefèvre --- Thanks for confirming. And indeed, I also get a failure with GCC 4.9.4, so that it is really different. For the reference, I've reported bug 78795.
[Bug bootstrap/78756] Missing prefix in the name of gfortran.info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78756 --- Comment #2 from Mojca Miklavec --- I just wanted to confirm that doing the same kind of replacement for gfortran as our package manager does for gcc, I get the expected result. So gfortran's info file doesn't seem to behave any different from others. I could change this into a request to make the names configurable, but well ... You can probably close this ticket as invalid.
[Bug bootstrap/78756] Missing prefix in the name of gfortran.info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78756 --- Comment #3 from Mojca Miklavec --- And just for the reference, here's the commit that fixed the behaviour for us: https://github.com/macports/macports-ports/commit/0b41554b5c627dcd5d095b1b432f554993df4c90
[Bug lto/78795] LTO causes undefined reference errors when linking with GMP "make check"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78795 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf --- GMP uses lots of asm statements that don't mix well with -flto.
[Bug tree-optimization/78428] [5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 64-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78428 Martin Liška changed: What|Removed |Added Summary|[5/6/7 Regression] wrong|[5/6 Regression] wrong code |code at -O2 and -O3 on |at -O2 and -O3 on |x86_64-linux-gnu in 64-bit |x86_64-linux-gnu in 64-bit |mode|mode --- Comment #8 from Martin Liška --- Fixed on trunk sofar.
[Bug libstdc++/59170] pretty printers: end iterator invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170 --- Comment #9 from Jonathan Wakely --- (In reply to Jan Kratochvil from comment #8) > (In reply to Jonathan Wakely from comment #7) > > But most code isn't compiled with debug mode enabled. > > IMO all code for debugging with pretty printers is compiled with debug mode > enabled. That's absolutely not true. Most developers don't even know the debug mode exists. Most C++ code being debugged with GDB is compiled with -O0 -g or with -Og -g, but not debug mode. In that scenario the pretty printers will be enabled, but won't be able to detect invalid iterators. I don't know what "code for debugging with pretty printers" means. Users don't do anything special for debugging with pretty printers, they just use GDB and the printers are automatically active. And they automatically dereference iterators, with unpleasant results.
[Bug libstdc++/59170] pretty printers: end iterator invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170 --- Comment #10 from Jonathan Wakely --- (In reply to Jan Kratochvil from comment #6) > This all depends more on a different non-pretty-printers feature I plan to > file for libstdc++ for years but I have never done so yet. With > -D_GLIBCXX_DEBUG the iterators could be memory-managed - they already track > their container by _M_sequence. The container could also track all its live > iterators, elements could track iterators pointing at them (and properly > invalidate them upon container updates) etc. Deleting the container would > invalidate all its iterators etc. Accessing an invalidated iterator would > then immediately assert. This is all already done, isn't it? Containers keep a list of active iterators (see _Safe_sequence_base::_M_iterators) which are automatically invalidated by the relevant container operations.
[Bug lto/78795] LTO causes undefined reference errors when linking with GMP "make check"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78795 --- Comment #2 from Vincent Lefèvre --- Do you mean that's a bug in GMP? Note that when I used the same options in the past (2012), there were no problems with GCC 4.7.1 and GMP 5.0.5.
[Bug lto/78795] LTO causes undefined reference errors when linking with GMP "make check"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78795 --- Comment #3 from Markus Trippelsdorf --- Also make sure that nm, ar and ranlib use the liblto_plugin, by either using wrappers (gcc-ar, etc.) or setting up a symlink to the plugin in lib/bfd-plugins/.
[Bug target/78794] [7 Regression] We noticed ~9% regression in 32-bit mode for 462.libquntum on Avoton after r243202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78794
--- Comment #9 from Yuri Rumyantsev ---
Hi Uros,
I checked thta with your patch performance is recovered on Avoton machine:
before after
462.libquantum18.400020.9000 +13.58%
Best regards.
Yuri.
2016-12-13 17:54 GMT+03:00 ubizjak at gmail dot com :
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78794
>
> --- Comment #8 from Uroš Bizjak ---
> (In reply to Uroš Bizjak from comment #7)
>
>> Yes, this is a good idea.
> Also, since pandn on non-BMI target replaces four arith insns with one, the
> gain should be raised for 2 * ix86_cost->add for a total of 3 *
> ix86_cost->add.
>
> The final patch is thus:
>
> --cut here--
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 1cd1cd8..6a746b2 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -3417,7 +3417,11 @@ dimode_scalar_chain::compute_convert_gain ()
>|| GET_CODE (src) == AND)
> {
> gain += ix86_cost->add;
> - if (CONST_INT_P (XEXP (src, 0)))
> + /* Additional gain for andnot for targets without BMI. */
> + if (GET_CODE (XEXP (src, 0)) == NOT
> + && !TARGET_BMI)
> + gain += 2 * ix86_cost->add;
> + else if (CONST_INT_P (XEXP (src, 0)))
> gain -= vector_const_cost (XEXP (src, 0));
> if (CONST_INT_P (XEXP (src, 1)))
> gain -= vector_const_cost (XEXP (src, 1));
> --cut here-
>
> Please also note that on BMI targets, the attached testcase won't be
> converted,
> which is a good thing - the loop on BMI targets looks like:
>
> .L4:
> movl4(%eax), %edi
> andn4(%esp), %edi, %ebx
> movl(%eax), %esi
> movl%ebx, %ebp
> andn(%esp), %esi, %ecx
> orl %ecx, %ebp
> jne .L3
> xorl8(%esp), %esi
> xorl12(%esp), %edi
> movl%esi, (%eax)
> movl%edi, 4(%eax)
> .L3:
> addl$12, %eax
> cmpl%edx, %eax
> jne .L4
>
> --
> You are receiving this mail because:
> You reported the bug.
[Bug libstdc++/78486] feature request: std::iu16stringstream std::ou16stringstream, and utf8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78486 --- Comment #3 from Jim Michaels --- also, u16strfuncs-nostr.cpp:612:3: error: 'u16out' is not a member of 'std' std::u16out<
[Bug target/78796] New: TLS fails to link on aarch64 with -mcmodel=large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78796
Bug ID: 78796
Summary: TLS fails to link on aarch64 with -mcmodel=large
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
/* { dg-do run } */
/* { dg-options "-O2" } */
/* { dg-additional-options "-mcmodel=large" { target aarch64-*-* } } */
/* { dg-require-effective-target tls } */
struct S { int a, b, c, d, e; };
struct S t;
__thread struct S s;
__attribute__((used, noinline, noclone)) void
foo (int *x, int *y)
{
asm volatile ("" : : "g" (x), "g" (y) : "memory");
if (*x != 1 || *y != 2)
__builtin_abort ();
}
__attribute__((used, noinline, noclone)) void
bar (void)
{
foo (&t.c, &s.c);
}
int
main ()
{
t.c = 1;
s.c = 2;
bar ();
return 0;
}
fails to link on aarch64, with:
/usr/bin/ld: /tmp/cctoEMbM.o(.text+0x40): R_AARCH64_ABS64 used with TLS symbol
.LANCHOR0
/usr/bin/ld: /tmp/cctoEMbM.o(.text.startup+0x40): R_AARCH64_ABS64 used with TLS
symbol .LANCHOR0
or with additional -fno-section-anchors just complaining that R_AARCH64_ABS64
used with TLS symbol s. The bug affects 4.8, 5, 6, I think it has been fixed
with r237607.
[Bug target/78796] TLS fails to link on aarch64 with -mcmodel=large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78796 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-12-13 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 40325 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40325&action=edit gcc6-pr78796.patch Untested fix.
[Bug target/78796] TLS fails to link on aarch64 with -mcmodel=large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78796 Jakub Jelinek changed: What|Removed |Added CC||ramana at gcc dot gnu.org, ||wilco at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I can bootstrap/regtest this on aarch64-linux, but 6.3 rc1 is planned for tomorrow. Could the aarch64 maintainers review it before then (if they want to see it in 6.3)?
[Bug lto/78795] LTO causes undefined reference errors when linking with GMP "make check"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78795 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Markus Trippelsdorf --- Just compiled GMP with -flto and I get no undefined reference errors. Instead I get an assembler error: setbit.c: Assembler messages: setbit.c:99: Error: operand type mismatch for `sub' But this is a GMP bug: "subq $8589934592, (%rbx)"
[Bug tree-optimization/78731] [5 Regression] Possible bug with switch when optimization is turned on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78731 --- Comment #6 from Jeffrey A. Law --- The patch is fine -- it can't hurt correctness and it's less invasive than pulling out all the backedge handling like we did for later releases. My only worry is that it's really a bandaid for code that is fundamentally broken. So we could well end revisiting this stuff again in the old releases.
