[Bug web/87050] Bump wwwdocs to html5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87050 --- Comment #2 from Janne Blomqvist --- The validation script that runs upon committing a change and sends email likely needs to change too. There is https://validator.github.io/validator/ that can be run as a batch script (needs java), or one can use a publically available hosted service (a few listed on the page above).
[Bug middle-end/63155] [6/7/8/9 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155 Richard Biener changed: What|Removed |Added Last reconfirmed|2014-09-03 00:00:00 |2018-8-22 Known to fail||8.2.0 --- Comment #16 from Richard Biener --- Re-confirmed.
[Bug middle-end/87055] New: Unoptimal address calculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87055
Bug ID: 87055
Summary: Unoptimal address calculation
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
Following testcase:
--cut here--
int a[256];
int foo (int i)
{
return a[i+1];
}
--cut here--
compiles on x86_64 (-O2) to:
addl$1, %edi
movslq %edi, %rdi
movla(,%rdi,4), %eax
ret
clang merges the addition with the address:
movslq %edi, %rax
movla+4(,%rax,4), %eax
retq
Related: PR54589
[Bug target/54589] struct offset add should be folded into address calculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589 --- Comment #4 from Uroš Bizjak --- clang generates for x86_64: movzbl (%rsi), %eax shlq$4, %rax movl16(%rdi,%rax), %eax movl%eax, (%rdx) retq and for i?86: movl8(%esp), %edx movl4(%esp), %ecx movl12(%esp), %eax movzbl (%edx), %edx shll$4, %edx movl16(%ecx,%edx), %ecx movl%ecx, (%eax) retl for the later case (-m32), gcc generates: movl8(%esp), %eax movzbl (%eax), %eax addl$1, %eax sall$4, %eax addl4(%esp), %eax movl(%eax), %edx movl12(%esp), %eax movl%edx, (%eax) ret so, two extra additions.
[Bug target/86947] Erroneous code generated with O2 and O3 for PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86947 Richard Biener changed: What|Removed |Added Target||powerpc Status|UNCONFIRMED |WAITING Last reconfirmed||2018-08-22 CC||rguenth at gcc dot gnu.org Component|c |target Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Can you possibly provide a driver (main() function) that calls abort() when the miscompilation occurs and exits without error if not?
[Bug c++/86953] [6/7/8/9 Regression] compiler crashes with constexpr operator== and specific struct (cxx_eval_bit_field_ref, at cp/constexpr.c:2704)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86953 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||5.4.0 Target Milestone|--- |6.5
[Bug gcov-profile/86957] gcc should warn about missing profiles for a compilation unit or a new function with -fprofile-use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86957 --- Comment #2 from Richard Biener --- I wonder if for assessing the quality of a profile it is somehow possible to dump all functions that got never executed during training? Because all those functions will be optimized as cold by GCC AFAIK.
[Bug c++/86960] [8/9 Regression] internal compiler error: in coerce_template_parms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86960 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P2 Known to work||7.3.0 Target Milestone|--- |8.3 Summary|[Regression] internal |[8/9 Regression] internal |compiler error: in |compiler error: in |coerce_template_parms |coerce_template_parms
[Bug fortran/86837] [8/9 Regression] Optimization breaks an unformatted read with implicit loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86837 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |8.3 Summary|Optimization breaks an |[8/9 Regression] |unformatted read with |Optimization breaks an |implicit loop on Mac OS X |unformatted read with ||implicit loop Build|x86_64-darwin | --- Comment #4 from Dominique d'Humieres --- The change occurred between revisions r248853 (2017-06-03, OK) and r249632 (2017-06-25, wrong code), r249092 (pr80988) or r248877 (pr35339)?
[Bug debug/86964] Too many debug symbols included, especially for extern globals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-22 CC||rguenth at gcc dot gnu.org, ||vries at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. Debug info is now more complete. Note -feliminate-unused-debug-symbols is only implemented for STABS debugging, not for DWARF and from my reading implementing it for DWARF is what you'd like to see. If you use GCC 8 or newer and LTO and apply dwarf compression using the dwz tool the final debug info will be smaller than with GCC 4.9. Unfortunately dwarf compression doesn't help when not using LTO as it seems to be "confused" by location attributes. Let's make this bug a request for implementing -feliminate-unused-debug-symbols for DWARF.
[Bug c++/86969] [8/9 Regression] ICE (in tsubst_copy) for a generic recursive lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86969 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.3
[Bug c++/86970] Rejected constexpr expression involving lambdas and inheritance, "use of this in a constant expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86970 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-22 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- clang accepts it.
[Bug fortran/86945] [8/9 Regression] BUG with optimisation of select case statement in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86945 --- Comment #9 from Richard Biener --- Author: rguenth Date: Wed Aug 22 08:07:36 2018 New Revision: 263761 URL: https://gcc.gnu.org/viewcvs?rev=263761&root=gcc&view=rev Log: 2018-08-22 Richard Biener PR tree-optimization/86945 * tree-cfg.c (generate_range_test): Use unsigned arithmetic. * gcc.dg/torture/pr86945.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr86945.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c
[Bug c++/86971] -Wabi warns it will not warn about anything.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86971 --- Comment #4 from Richard Biener --- (In reply to Alexander Monakov from comment #2) > I think the wording of the opening line can be made unambiguous, which is > probably nice for translators. Can we change it to say e.g.: > > cc1plus: warning: -Wabi by itself does not issue any warnings Maybe cc1plus: warning: -Wabi without specified version does not issue any warnings ? Btw, is that true when I use -fabi-version=11 -Wabi?
[Bug target/86973] [6/7/8/9 Regression] ICE in expand_call, at calls.c:4217
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86973 Richard Biener changed: What|Removed |Added Priority|P3 |P2 CC||matz at gcc dot gnu.org Target Milestone|--- |6.5
[Bug tree-optimization/86945] [8 Regression] BUG with optimisation of select case statement in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86945 Richard Biener changed: What|Removed |Added Component|fortran |tree-optimization Known to work||9.0 Summary|[8/9 Regression] BUG with |[8 Regression] BUG with |optimisation of select case |optimisation of select case |statement in gfortran |statement in gfortran Known to fail|9.0 | --- Comment #10 from Richard Biener --- Fixed on trunk sofar.
[Bug c++/86974] Support Clang's require_constant_initialization attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86974 --- Comment #1 from Richard Biener --- Hmm, can't the thing be just marked constexpr?
[Bug middle-end/86979] [9 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2348 with -m32 on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86979 Richard Biener changed: What|Removed |Added Target||x86_64-apple-darwin Target Milestone|--- |9.0
[Bug c/86983] documentation inconsistent with always_inline diagnostics for computed goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86983
Richard Biener changed:
What|Removed |Added
Keywords||documentation
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-08-22
CC||hubicka at gcc dot gnu.org,
||jsm28 at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
case GIMPLE_GOTO:
t = gimple_goto_dest (stmt);
/* We will not inline a function which uses computed goto. The
addresses of its local labels, which may be tucked into
global storage, are of course not constant across
instantiations, which causes unexpected behavior. */
if (TREE_CODE (t) != LABEL_DECL)
{
inline_forbidden_reason
= G_("function %q+F can never be inlined "
"because it contains a computed goto");
*handled_ops_p = true;
return t;
}
we have to assume that the goto is to labels of the function or functions
inlined into it. We do not seem to compute whether any of those escape
(your testcase returns them though).
So the wording is correct and the Labels-as-Values documentation is
wrong.
Of course if we get enough analysis GCC might decide to inline, all the
wording always applies to a concrete implementation and is not to be
treated as language specification.
[Bug c++/86974] Support Clang's require_constant_initialization attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86974 --- Comment #2 from Jonathan Wakely --- No because that also makes it const, i.e. immutable. It's useful for non-const globals.
[Bug target/86984] invalid relocation accessing a const char array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86984 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed I assume.
[Bug debug/86985] Generated DWARF does not distinguish between zero-length and flexible array types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86985 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-22 CC||vries at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- Confirmed.
[Bug c++/86986] [6/7/8/9 Regression] Unexpected errors for template parameter pack in a template template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86986 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |6.5
[Bug c++/86971] -Wabi warns it will not warn about anything.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86971 --- Comment #5 from Jonathan Wakely --- (In reply to Richard Biener from comment #4) > ? Btw, is that true when I use -fabi-version=11 -Wabi? That will give warnings. -Wabi (with no =n value) is only useless without an explicit -fabi-version, because it means "warn about incompatibilities with the default -fabi-version". If you don't use -fabi-version then you're using the default, and so there are no differences.
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #20 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #19 from qinzhao at gcc dot gnu.org --- > which sparc machine was used to repeat the failure, and what's the configure > and make options? I just saw there are gcc210 and gcc211 in the compile farm running Solaris 10 and 11 respectively. No specific configure options should be necessary to reproduce this.
[Bug tree-optimization/86988] [7/9 Regression] ICE: tree check: expected integer_cst, have var_decl in get_len, at tree.h:5563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86988 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-08-22 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |7.4 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Testing diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c index 24e089b019b..ead19f15996 100644 --- a/gcc/tree-vrp.c +++ b/gcc/tree-vrp.c @@ -4581,6 +4581,7 @@ vrp_prop::check_mem_ref (location_t location, tree ref, tree reftype = TREE_TYPE (arg); if (POINTER_TYPE_P (reftype) || !COMPLETE_TYPE_P (reftype) + || TREE_CODE (TYPE_SIZE_UNIT (reftype)) != INTEGER_CST || RECORD_OR_UNION_TYPE_P (reftype)) return; for trunk.
[Bug tree-optimization/86990] [9 Regression] wrong code at -O2 on x86_64-linux-gnu in 64-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86990 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/86991] [8/9 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6919
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86991 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- I will have a look.
[Bug c++/86993] [6/7/8/9 Regression] assignment of read-only variable error reported at wrong location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86993 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |6.5
[Bug middle-end/86995] [9 regression] c-c++-common/torture/builtin-arith-overflow-17.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86995 Richard Biener changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1 CC||law at gcc dot gnu.org --- Comment #1 from Richard Biener --- From looking at svn log it must be caused by r263591 | law | 2018-08-16 18:33:43 +0200 (Thu, 16 Aug 2018) | 8 lines * expmed.h (canonicalize_comparison): New declaration. * expmed.c (canonicalize_comparison, equivalent_cmp_code): New function. * expmed.c (emit_store_flag_1): Add call to canonicalize_comparison. * optabs.c (prepare_cmp_insn): Likewise. * rtl.h (unsigned_condition_p): New function which checks if a comparison operator is unsigned. * gcc.target/aarch64/imm_choice_comparison.c: New test. Vlad doesn't seem to have a bugzilla account.
[Bug driver/87056] New: [9 Regression] GCC does not work when using -pipe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87056
Bug ID: 87056
Summary: [9 Regression] GCC does not work when using -pipe
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Probably starting from r263679 I see:
$ gcc /tmp/empty.c -c -pipe
gcc: error: close: No such file or directory
abuild@kunlun:~> /tmp/empty.c:1:1: fatal error: error closing -: Broken pipe
1 | int main() {}
| ^~~
compilation terminated.
when running in GDB:
Breakpoint 1, 0x77b03520 in close () from /lib64/libc.so.6
(gdb) bt
#0 0x77b03520 in close () from /lib64/libc.so.6
#1 0x00445f21 in pex_run_in_environment (err=0x7fffe71c,
errname=, orig_outname=, env=0x0, argv=, executable=, flags=, obj=0x53fbe0) at
../../libiberty/pex-common.c:359
#2 pex_run (obj=0x53fbe0, flags=, executable=,
argv=, orig_outname=, errname=,
err=0x7fffe71c) at ../../libiberty/pex-common.c:374
#3 0x0045534d in execute() () at ../../gcc/gcc.c:3166
#4 0x00453e29 in do_spec(char const*) () at ../../gcc/gcc.c:4957
#5 0x004535bc in driver::do_spec_on_infiles() const () at
../../gcc/gcc.c:8107
#6 0x00447ae6 in driver::main(int, char**) () at ../../gcc/gcc.c:7334
#7 0x00447cb4 in main (argc=4, argv=0x7fffea38) at
../../gcc/gcc-main.c:47
[Bug driver/87056] [9 Regression] GCC does not work when using -pipe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87056 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-08-22 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Would be related to: gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I/home/marxin/Programming/gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local -pedantic -D_GNU_SOURCE /home/marxin/Programming/gcc/libiberty/pex-unix.c -o pex-unix.o /home/marxin/Programming/gcc/libiberty/pex-unix.c: In function ‘pex_unix_exec_child’: /home/marxin/Programming/gcc/libiberty/pex-unix.c:659:6: warning: declaration of ‘err’ shadows a parameter [-Wshadow=local] int err = errno; ^~~ /home/marxin/Programming/gcc/libiberty/pex-unix.c:569:47: note: shadowed declaration is here int toclose, const char **errmsg, int *err) ~^~~ I'm going to fix it.
[Bug tree-optimization/86999] missed FMA optimization with -fassociative-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86999 Richard Biener changed: What|Removed |Added Keywords|wrong-code | Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-22 CC||rguenth at gcc dot gnu.org Component|middle-end |tree-optimization Summary|Incorrect code generation |missed FMA optimization |and missing optimization|with -fassociative-math |with -fno-signed-zeros. | Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- So as far as I understand comment#1 remains. The FMA pass should handle (x +- 1)*y and (1 - x)*y.
[Bug libstdc++/77854] std::deque doesn't use allocator's size_type and difference_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77854 Jonathan Wakely changed: What|Removed |Added Keywords||documentation Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #1 from Jonathan Wakely --- Our other containers do the same, which is OK. The standard requires that difference_type "is identical to the difference type of X::iterator and X::const_iterator" and "size_type can represent any non-negative value of difference_type". So in fact they need to correspond to the container's iterators, not come from the allocator. We do need to document the types though, because they're implementation-defined.
[Bug target/87006] Stack Protection with Large File support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87006 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Richard Biener --- .
[Bug target/87007] [8/9 Regression] 10% slowdown with -march=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87007 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |8.3
[Bug tree-optimization/87008] [8/9 Regression] gimple mem-to-mem assignment badly optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87008
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-08-22
CC||jamborm at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Target Milestone|--- |8.3
Ever confirmed|0 |1
--- Comment #3 from Richard Biener ---
(In reply to Marc Glisse from comment #2)
> Or just:
>
> struct A { double a, b; };
> struct B : A {};
> double f(B x){
> B y;
> A*px=&x;
> A*py=&y;
> *py=*px;
> return y.a;
> }
>
> MEM[(struct A *)&y] = MEM[(const struct A &)&x];
> y_6 = MEM[(struct A *)&y];
> y ={v} {CLOBBER};
> return y_6;
>
> where y_6 should be read directly from x. SRA doesn't dare touch it. SCCVN
> does see that reading from y is equivalent to reading from x, but unless
> something else is already reading from x, it keeps the read from y.
Yeah, SCCVN doesn't change the read to one from x because generally it
cannot know y will go away and reading from x possibly enlarges its
lifetime (no stack sharing).
To really handle this we need to expose the way we'd expand such aggregate
copies to RTL already at GIMPLE stage. SRA could be the pass that should
eventually do that (but of course avoid exposing copy loops or calls to
memcpy we might expand to ...). So it boils down to heuristics again...
[Bug driver/87056] [9 Regression] GCC does not work when using -pipe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87056 Martin Liška changed: What|Removed |Added Status|ASSIGNED|NEW CC||nathan at gcc dot gnu.org Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #2 from Martin Liška --- No, the warning was here even before..
[Bug tree-optimization/87008] [8/9 Regression] gimple mem-to-mem assignment badly optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87008
--- Comment #4 from Richard Biener ---
(In reply to Marc Glisse from comment #1)
> struct A { double a, b; };
> struct B : A {};
> templatevoid cp(T&a,T const&b){a=b;}
> double f(B x){
> B y; cp(y,x);
> B z; cp(z,x);
> return y.a - z.a;
> }
>
> This is not quite equivalent because RTL manages to optimize this case, but
> gimple, with -Ofast, still gets the ugly:
>
> ISRA.1 = MEM[(const struct A &)&x];
> SR.9_9 = MEM[(struct A *)&ISRA.1];
> ISRA.1 = MEM[(const struct A &)&x];
> SR.8_10 = MEM[(struct A *)&ISRA.1];
> _3 = SR.9_9 - SR.8_10;
> return _3;
>
> Writing cp instead of cp makes it work, and the main difference starts
> in SRA. I expect (didn't check) this is another victim of r255510 .
The initial IL is too convoluted for early FRE to figure out the equivalences.
For the above which is visible to the late FRE the issue is that the
redundant aggregate copy gets in the way which isn't detected in early FRE
and FRE also doesn't try to remove or detect redundant aggregate copies
because we don't really "value-number" aggregate stores.
To sum up it - aggregate copies are bad ;) But they also sometimes
help - all the vn_reference_op_lookup_3 tricks wouldn't work without
them unless you end up with store pieces that always fully cover all
downstream loads.
[Bug middle-end/87009] Can't find XOR pattern applying De Morgan sequentially
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87009 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-22 Component|tree-optimization |middle-end Ever confirmed|0 |1
[Bug tree-optimization/87011] [9 Regression] partially dead memset before strcpy not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87011 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug c++/87012] [7/8/9 Regression] ICE in verify_unstripped_args_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87012 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Priority|P3 |P2 Target Milestone|--- |7.4 Summary|[Regression] ICE in |[7/8/9 Regression] ICE in |verify_unstripped_args_1|verify_unstripped_args_1
[Bug c++/87057] New: in compilation error, gcc should note about deleted copy-constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87057
Bug ID: 87057
Summary: in compilation error, gcc should note about deleted
copy-constructor
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
When, in a code, a copy-constructor deleted but used, GCC issues an absolutely
unhelpful message that it couldn't convert the argument. "Why can't it?". It's
extremely difficult to diagnose — e.g. in my case I had to go down from a
project code to the minimal example below before I could figure it out. There's
really no other way, except as of magically guessing that some of fields used
in the struct being copied has its copy-constructor deleted.
FTR: to fix the code below you need to replace `return {ret}` with `return
{move(ret)}`.
# Steps to reproduce:
$ cat test.cpp
#include
#include
struct PacketErr {
std::unique_ptr failed_devices;
};
std::variant deserialize(){
PacketErr ret;
return {ret};
}
int main() {}
$ g++ test.cpp -std=c++17
test.cpp: In function ‘std::variant
deserialize()’:
test.cpp:10:16: error: could not convert ‘{ret}’ from ‘’ to ‘std::variant’
return {ret};
# Expected
GCC should mention that a copy is not possible since there's a copy-constructor
deleted.
# Actual
GCC basically says there's some error at the line — go figure what problem is
it.
[Bug target/86947] Erroneous code generated with O2 and O3 for PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86947 --- Comment #3 from Vinay Kumar --- Created attachment 44572 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44572&action=edit Testcase t2.c
[Bug target/86947] Erroneous code generated with O2 and O3 for PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86947 Vinay Kumar changed: What|Removed |Added CC||vinay.m.engg at gmail dot com --- Comment #2 from Vinay Kumar --- Created attachment 44571 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44571&action=edit Testcase t1.c
[Bug target/86947] Erroneous code generated with O2 and O3 for PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86947 --- Comment #4 from Vinay Kumar --- Hi Richard, Thanks for checking the bug. Please find attached the testcase that would exit with message "Should NOT BE here" on miscompilation. The behavior is same with other targets as well. We have checked it with latest X86 and Aarch64 targets. gcc t1.c t2.c -O2 -m64 -lm
[Bug bootstrap/87013] Error: junk at end of line, first unrecognized character is `i'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87013 Richard Biener changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #3 from Richard Biener --- .loc 1 15 1 is_stmt 0 we don't seem to have an assembler test for is_stmt support. Alex? Martin, can you attach gcc/config.log?
[Bug c++/87015] [8/9 Regression] miscompilation of template heavy Boost Spirit code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87015 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Target Milestone|--- |8.3 Summary|[8 Regression] |[8/9 Regression] |miscompilation of template |miscompilation of template |heavy Boost Spirit code |heavy Boost Spirit code --- Comment #3 from Richard Biener --- Can you check with a snapshot of the GCC 8 branch after 2018-08-17 (including the fix for PR86763)?
[Bug tree-optimization/87022] [8/9 Regression] miscompilation with -ftree-loop-distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87022 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||7.3.0 Version|unknown |8.2.1 Target Milestone|--- |8.3
[Bug c++/4898] adding an option to verify exception specifications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4898 --- Comment #5 from Eric Gallager --- (In reply to Jonathan Wakely from comment #4) > Dynamic exception specifications are no longer part of the C++ language > anyway. Well, in newer standards at least, but they were at one point in an older standard, right?
[Bug c++/79695] spurious -Wunused-variable on a static global of a type declared unused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79695 Eric Gallager changed: What|Removed |Added CC||dodji at gcc dot gnu.org --- Comment #4 from Eric Gallager --- (In reply to Martin Sebor from comment #1) > Let me correct that: GCC warns on the first two variables, not on the local > one defined in function g(). It used to warn on it until r145440. cc-ing Dodji who did that commit
[Bug ipa/87024] ICE in fold_stmt_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87024 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Version|unknown |9.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Testing patch.
[Bug ipa/87024] [6/7/8/9 Regression] ICE in fold_stmt_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87024 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |6.5 Summary|ICE in fold_stmt_1 |[6/7/8/9 Regression] ICE in ||fold_stmt_1
[Bug target/87026] [9 Regression] ICE in extract_constrain_insn_cached, at recog.c:2218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87026 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug tree-optimization/87025] [9 Regression] ICE in add_record, at optinfo-emit-json.cc:175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87025 Richard Biener changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org Version|unknown |9.0 Target Milestone|--- |9.0
[Bug c++/43454] warning with -Wall despite __attribute__ ((__unused__))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43454 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org, ||dodji at gcc dot gnu.org --- Comment #3 from Eric Gallager --- cc-ing diagnostics maintainers
[Bug ada/87058] New: FAIL: gnat.dg/slice7.adb (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87058 Bug ID: 87058 Summary: FAIL: gnat.dg/slice7.adb (test for excess errors) Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- I see this extra fail when running the testsuite with --enable-checking=yes on the branch. It is +===GNAT BUG DETECTED==+^M | 8.2.1 20180822 (x86_64-pc-linux-gnu) in add_expr, at tree.c:7277 |^M | Error detected around /space/rguenther/src/svn/gcc-8-branch/gcc/testsuite/gnat.dg/slice7.adb:35:3|^M | Please submit a bug report; see https://gcc.gnu.org/bugs/ . |^M | Use a subject line meaningful to you and us to track the bug.|^M | Include the entire contents of this bug box in the report. |^M | Include the exact command that you entered. |^M | Also include sources listed below. |^M +==+^M case INTEGER_CST: gcc_checking_assert (!(flags & OEP_ADDRESS_OF)); for (i = 0; i < TREE_INT_CST_EXT_NUNITS (t); i++)
[Bug tree-optimization/87031] nios2 optimization for size - two cases of regression relatively to 5.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87031 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-22 CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Component|target |tree-optimization Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- size: 24-3, last_iteration: 19-3 Loop size: 24 Estimated size after unrolling: 24 so GCC estimates that unrolling doesn't change size. It arrives here by applying it's "unrolling saves 1/3 of insns" heuristic. First of all this isn't controlled by a --param but hard-coded. Second, it wasn't reduced after we improved estimates of what is optimized away. Third, we probably shouldn't apply this when optimizing the loop for size (aka UL_NO_GROWTH). Honza? Any opinion on the above? Did you ever try removing that * 2/3 completely?
[Bug target/87033] The compiler does not generate the LWAX instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87033 Richard Biener changed: What|Removed |Added Keywords||missed-optimization --- Comment #3 from Richard Biener --- fixed?
[Bug tree-optimization/87034] [9 Regression] missing -Wformat-overflow on a sprintf %s with a wide string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87034 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038 --- Comment #5 from Richard Biener --- I think even -Wall makes sense.
[Bug debug/87039] [8/9 Regression] DW_OP_fbreg used without a frame base on a C++ code w/ -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87039 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.3
[Bug middle-end/87041] [8/9 Regression] GCC 8 regression: -Wformat "reading through null pointer" on unreachable code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87041 Richard Biener changed: What|Removed |Added Keywords||diagnostic Target Milestone|--- |8.3 Summary|GCC 8 regression: -Wformat |[8/9 Regression] GCC 8 |"reading through null |regression: -Wformat |pointer" on unreachable |"reading through null |code|pointer" on unreachable ||code
[Bug tree-optimization/87042] UBSAN: poly-int.h:1095:5: runtime error: signed integer overflow: 9223372036854775807 * 8 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87042 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-22 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Hmm. Those poly_offset params should have got poly_offset_int instead of poly_uint64 (they were HOST_WIDE_INT though, not offset_int). Well, we should fix it nevertheless, but fixing comes at a cost :/ The particular case might be fixed by simply guarding the fold_ctor_reference call for too big offset.
[Bug fortran/87043] maybe-uninitialized warning for initialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87043
--- Comment #1 from Richard Biener ---
In .original I see
if (world_rank == 0)
{
...
stat.0 = 0;
error_messages.data = (void * restrict) __builtin_malloc
(MAX_EXPR );
if (__builtin_expect ((integer(kind=8))
(error_messages.data == 0B), 0, 40))
{
stat.0 = 5014;
}
}
}
if (stat.0 == 0)
{
error_messages.dim[0].lbound = 1;
error_messages.dim[0].ubound = (integer(kind=8)) world_size;
error_messages.dim[0].stride = 1;
error_messages.offset = -1;
}
if (__builtin_expect ((integer(kind=8)) (stat.0 != 0), 0, 40)) goto
L.2;
L.2:;
allocstat = stat.0;
}
...
L.1:;
if (world_rank == 0)
{
{
integer(kind=4) limit.4;
character(kind=1)[0:][1:80] * restrict D.3813;
integer(kind=8) D.3814;
integer(kind=8) D.3815;
integer(kind=8) D.3816;
limit.4 = -2147483648;
D.3813 = (character(kind=1)[0:][1:80] * restrict)
error_messages.data;
D.3814 = error_messages.offset;
D.3815 = error_messages.dim[0].lbound;
D.3816 = error_messages.dim[0].ubound;
so when error_messages allocation fails then you access uninitialized
error_messages.
Not sure if
allocate(error_messages(world_size), stat=allocstat)
max_err_len = maxval(len_trim(error_messages))
is well-defined fortran iff allocation fails? I suppose not, so
warning is correct, testcase is broken?
[Bug tree-optimization/87046] Incorrect vectorization of fma with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87046 Richard Biener changed: What|Removed |Added Keywords||needs-bisection CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Martin, can you bisect what fixed this?
[Bug tree-optimization/86988] [7/9 Regression] ICE: tree check: expected integer_cst, have var_decl in get_len, at tree.h:5563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86988 --- Comment #2 from Richard Biener --- Author: rguenth Date: Wed Aug 22 11:01:58 2018 New Revision: 263762 URL: https://gcc.gnu.org/viewcvs?rev=263762&root=gcc&view=rev Log: 2018-08-22 Richard Biener PR tree-optimization/86988 * tree-vrp.c (vrp_prop::check_mem_ref): Bail out on VLAs. * g++.dg/pr86988.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/pr86988.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug target/87047] [7/8/9 Regression] performance regression because of if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87047 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Component|rtl-optimization|target Target Milestone|--- |7.4
[Bug libfortran/87048] [9 Regression] array_constructor_8.f90 failure on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87048 Richard Biener changed: What|Removed |Added Target||armeb --- Comment #1 from Richard Biener --- Odd bisection result so not exact revision?
[Bug middle-end/87049] __clear_cache() prototype confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87049 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-22 CC||daney at gcc dot gnu.org Component|c |middle-end Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- probably easiest to rectify the builtin type.
[Bug target/87033] The compiler does not generate the LWAX instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87033 Segher Boessenkool changed: What|Removed |Added Target|powerpc64-linux-gnu-*, |powerpc*-*-* |powerpc64le-linux-gnu-* | Host|powerpc64-linux-gnu-*, | |powerpc64le-linux-gnu-* | Build|powerpc64-linux-gnu-*, | |powerpc64le-linux-gnu-* | --- Comment #4 from Segher Boessenkool --- Backports are wanted still.
[Bug middle-end/87054] misaligned asm output is turned into dereferenced pointer-to-aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87054
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-08-22
CC||rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
there's no member 'unpacked'. With chaning 'c' to unpacked and using "+x" on
x86_64 I see
_2 = &b[i].unpacked;
_3 = *_2;
__asm__("" : "=x" *_2 : "0" _3);
which is probably what you refer to.
Can you test the following? The code indeed seems to be overly simplistic...
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index e35137aec2c..117e5fcedc9 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -12540,9 +12540,15 @@ gimplify_expr (tree *expr_p, gimple_seq *pre_p,
gimple_seq *post_p,
/* An lvalue will do. Take the address of the expression, store it
in a temporary, and replace the expression with an INDIRECT_REF of
that temporary. */
+ tree ref_alias_type = reference_alias_ptr_type (*expr_p);
+ unsigned int ref_align = get_object_alignment (*expr_p);
+ tree ref_type = TREE_TYPE (*expr_p);
tmp = build_fold_addr_expr_loc (input_location, *expr_p);
gimplify_expr (&tmp, pre_p, post_p, is_gimple_reg, fb_rvalue);
- *expr_p = build_simple_mem_ref (tmp);
+ if (TYPE_ALIGN (ref_type) != ref_align)
+ ref_type = build_aligned_type (ref_type, ref_align);
+ *expr_p = build2 (MEM_REF, ref_type,
+ tmp, build_zero_cst (ref_alias_type));
}
else if ((fallback & fb_rvalue) && is_gimple_reg_rhs_or_call (*expr_p))
{
[Bug tree-optimization/87046] Incorrect vectorization of fma with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87046 --- Comment #3 from Martin Liška --- Fixed in r259840.
[Bug target/52795] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE on {x86_64,i386}-apple-darwin{10,11} at -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52795 --- Comment #10 from Iain Sandoe --- Author: iains Date: Wed Aug 22 11:37:02 2018 New Revision: 263763 URL: https://gcc.gnu.org/viewcvs?rev=263763&root=gcc&view=rev Log: Fix FDE labels for Darwin gcc/ PR bootstrap/81033 PR target/81733 PR target/52795 * gcc/dwarf2out.c (FUNC_SECOND_SECT_LABEL): New. (dwarf2out_switch_text_section): Generate a local label for the second function sub-section and apply it as the second FDE start label. * gcc/final.c (final_scan_insn_1): Emit second FDE label after the second sub-section start. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/final.c
[Bug target/81733] stage1 libgcc_s.dylib fails to link on Darwin 11/x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81733 --- Comment #18 from Iain Sandoe --- Author: iains Date: Wed Aug 22 11:37:02 2018 New Revision: 263763 URL: https://gcc.gnu.org/viewcvs?rev=263763&root=gcc&view=rev Log: Fix FDE labels for Darwin gcc/ PR bootstrap/81033 PR target/81733 PR target/52795 * gcc/dwarf2out.c (FUNC_SECOND_SECT_LABEL): New. (dwarf2out_switch_text_section): Generate a local label for the second function sub-section and apply it as the second FDE start label. * gcc/final.c (final_scan_insn_1): Emit second FDE label after the second sub-section start. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/final.c
[Bug bootstrap/81033] [8/9 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033 --- Comment #45 from Iain Sandoe --- Author: iains Date: Wed Aug 22 11:37:02 2018 New Revision: 263763 URL: https://gcc.gnu.org/viewcvs?rev=263763&root=gcc&view=rev Log: Fix FDE labels for Darwin gcc/ PR bootstrap/81033 PR target/81733 PR target/52795 * gcc/dwarf2out.c (FUNC_SECOND_SECT_LABEL): New. (dwarf2out_switch_text_section): Generate a local label for the second function sub-section and apply it as the second FDE start label. * gcc/final.c (final_scan_insn_1): Emit second FDE label after the second sub-section start. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/final.c
[Bug bootstrap/87013] Error: junk at end of line, first unrecognized character is `i'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87013 Alexandre Oliva changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #4 from Alexandre Oliva --- Created attachment 44573 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44573&action=edit untested candidate patch Yeah, it looks like we never checked for is_stmt support; we had it in unconditionally, but it was never exercised, so it didn't come up. This patch should be enough to avoid the problem, provided that gcc/configure and gcc/config.in are regenerated after putting the configure.ac change in. I'll turn that into a proper patch eventually, but I'd appreciate confirmation that it does solve the problem indeed. Thanks,
[Bug tree-optimization/87046] Incorrect vectorization of fma with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87046 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Richard Biener --- Dup. *** This bug has been marked as a duplicate of bug 85597 ***
[Bug tree-optimization/85597] [6 Regression] internal compiler error: in compute_live_loop_exits, at tree-ssa-loop-manip.c:229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85597 Richard Biener changed: What|Removed |Added CC||yates at cscs dot ch --- Comment #9 from Richard Biener --- *** Bug 87046 has been marked as a duplicate of this bug. ***
[Bug c++/4898] adding an option to verify exception specifications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4898 --- Comment #6 from Jonathan Wakely --- Yes, but IMHO it would be a huge waste of time to add a ton of new machinery to the compiler to check for "correct" usage of an obsolete feature. Most C++98 code didn't even use them, because they were not useful. Most code still using them should never have used them in the first place, because they don't work the way people think. C++ is not Java. From the original rationale: (In reply to luc.maisonobe from comment #0) > C++ allows to specify exceptions in the function declaration > but do not enforces it. When lots of classes and methods are > involved, maintaining up-to-date specifications is very > difficult, and every missed exception create runtime > problems (unexpected exception -> abort -> core dumped). For That's a reason to avoid using them, not a reason to complicate the compiler. > the moment the lack of support tools prevents developers > from using these specifications effectively. Even with tooling they can't be used effectively.
[Bug c++/4898] adding an option to verify exception specifications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4898
--- Comment #7 from Jonathan Wakely ---
(In reply to Martin Sebor from comment #2)
> I agree a new warning would be useful. For example, the following code should
> be diagnosed:
>
> struct S { S () throw () { throw 0; } };
This is still relevant in current standards, where throw() is equivalent to
noexcept.
Clang warns:
throw.cc:1:28: warning: 'S' has a non-throwing exception specification but can
still throw [-Wexceptions]
struct S { S () throw () { throw 0; } };
^
throw.cc:1:12: note: function declared non-throwing here
struct S { S () throw () { throw 0; } };
^
1 warning generated.
GCC only warns if we replace throw() with noexcept:
struct S { S () noexcept { throw 0; } };
throw.cc: In constructor 'S::S()':
throw.cc:1:34: warning: throw will always call terminate() [-Wterminate]
1 | struct S { S () noexcept { throw ""; } };
| ^~
We should warn for the equivalent throw() as well.
> as should this:
>
> struct S { S () throw (int) { throw ""; } };
Clang doesn't bother warning about this, with -std=c++98 or any other mode.
[Bug middle-end/87055] Unoptimal address calculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87055
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target||x86_64-*-*, i?86-*-*
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-08-22
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Isn't that a target (cost) issue?
Failed to match this instruction:
(set (reg:SI 94)
(mem:SI (plus:DI (sign_extract:DI (mult:DI (subreg:DI (plus:SI (reg/v:SI 89
[ i ])
(const_int 1 [0x1])) 0)
(const_int 4 [0x4]))
(const_int 34 [0x22])
(const_int 0 [0]))
(symbol_ref:DI ("a") [flags 0x2] )) [1
a S4 A32]))
looks like the usual type issue to me since it works with i being long where
combine then successfully matches
(set (reg:SI 93)
(mem:SI (plus:DI (mult:DI (reg/v:DI 89 [ i ])
(const_int 4 [0x4]))
(const:DI (plus:DI (symbol_ref:DI ("a") [flags 0x2] )
(const_int 4 [0x4] [1 a S4 A32]))
I guess we need to exploit the undefined overflow of i+1 on GIMPLE though
which would mean handling this in a IVOPTs-like pass (SLSR?). Or we need
to promote address computation parts (array indexes) earlier. Or we need
to avoid using a DImode multiply for SImode indexes... (we only need
a widening multiply).
Anyway, clang correctly doesn't optimize
int a[256];
int foo (unsigned int i)
{
return a[i+1];
}
I think we have a duplicate of this bug somewhere.
[Bug driver/87056] [9 Regression] GCC does not work when using -pipe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87056 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug target/87059] New: internal compiler error: in set_value_range, at tree-vrp.c:289
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87059
Bug ID: 87059
Summary: internal compiler error: in set_value_range, at
tree-vrp.c:289
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
CC: meissner at gcc dot gnu.org, segher at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-linux
The following test case:
#include
void d(void);
char *a, *b;
void c(void) {
if (b == a)
return;
if (strncmp(a, "", b - a))
d();
}
hits an ICE on trunk:
gcc -O2 test.c
during RTL pass: expand
test.c: In function ‘c’:
test.c:9:7: internal compiler error: in set_value_range, at tree-vrp.c:289
9 | if (strncmp(a, "", b - a))
| ^
0x10d3ceb7 set_value_range(value_range*, value_range_type, tree_node*,
tree_node*, bitmap_head*)
../../gcc/gcc/tree-vrp.c:289
0x10d4106f extract_range_from_binary_expr_1(value_range*, tree_code,
tree_node*, value_range*, value_range*)
../../gcc/gcc/tree-vrp.c:1893
0x10d43a2b determine_value_range_1
../../gcc/gcc/tree-vrp.c:6866
0x10d43cbf determine_value_range(tree_node*,
generic_wide_int*, generic_wide_int*)
../../gcc/gcc/tree-vrp.c:6901
0x1036385b get_size_range(tree_node*, tree_node**, bool)
../../gcc/gcc/calls.c:1258
0x10369c5b maybe_warn_nonstring_arg(tree_node*, tree_node*)
../../gcc/gcc/calls.c:1617
0x1036c003 initialize_argument_information
../../gcc/gcc/calls.c:2197
0x1036d367 expand_call(tree_node*, rtx_def*, int)
../../gcc/gcc/calls.c:3577
0x103454ef expand_builtin_strncmp
../../gcc/gcc/builtins.c:4793
0x10355f5b expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/gcc/builtins.c:7445
0x1052816f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:10943
0x10542cc3 expand_expr
../../gcc/gcc/expr.h:279
0x10542cc3 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/gcc/expr.c:8456
0x10528703 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:11230
0x1053958f expand_expr
../../gcc/gcc/expr.h:279
0x1053958f store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc/gcc/expr.c:5556
0x1053b6a3 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/gcc/expr.c:5420
0x10388133 expand_call_stmt
../../gcc/gcc/cfgexpand.c:2685
0x10388133 expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3575
0x10388133 expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3734
The CI that tripped up on this started failing at:
commit 9e4ef9eec6c786e3edbdcb7f26a1d735c9d7f4b9
Author: aldyh
Date: Tue Aug 21 06:27:14 2018 +
* wide-int-range.cc (wide_int_range_abs): New.
(wide_int_range_order_set): Rename from wide_int_range_min_max.
* wide-int-range.h (wide_int_range_abs): New.
(wide_int_range_min_max): New.
* tree-vrp.c (extract_range_from_unary_expr): Rewrite ABS_EXPR
case to call wide_int_range_abs.
Rewrite MIN/MAX_EXPR to call wide_int_range_min_max.
(extract_range_from_abs_expr): Delete.
[Bug c++/87057] in compilation error, gcc should note about deleted copy-constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87057
--- Comment #1 from Jonathan Wakely ---
(In reply to Konstantin Kharlamov from comment #0)
> When, in a code, a copy-constructor deleted but used, GCC issues an
> absolutely unhelpful message that it couldn't convert the argument. "Why
> can't it?". It's extremely difficult to diagnose — e.g. in my case I had to
> go down from a project code to the minimal example below before I could
> figure it out. There's really no other way, except as of magically guessing
> that some of fields used in the struct being copied has its copy-constructor
> deleted.
>
> FTR: to fix the code below you need to replace `return {ret}` with `return
> {move(ret)}`.
>
> # Steps to reproduce:
>
> $ cat test.cpp
> #include
> #include
>
> struct PacketErr {
> std::unique_ptr failed_devices;
> };
>
> std::variant deserialize(){
> PacketErr ret;
> return {ret};
> }
>
> int main() {}
> $ g++ test.cpp -std=c++17
> test.cpp: In function ‘std::variant
> deserialize()’:
> test.cpp:10:16: error: could not convert ‘{ret}’ from ‘ initializer list>’ to ‘std::variant’
>return {ret};
>
> # Expected
>
> GCC should mention that a copy is not possible since there's a
> copy-constructor deleted.
I don't think that's really plausible. If fails because you cannot construct
the variant type from a PacketErr lvalue, because it fails the SFINAE
constraints.
For the compiler to tell you why it fails them it would have to analyse those
constraints and tell you that __is_accepted_index returns variant_npos, because
none of the alternatives can be constructed from PacketErr&. It would then have
to look at each alternative and see why each one fails, and then whether that
is worth reporting to the user. So it would have to try to convert PacketErr&
to monostate, and decide if any of the reasons for failure was useful to
report. Then it would have to try to convert PacketErr& to PacketErr, and see
if any of the reasons for failure was useful to report.
That would require a lot of special-casing just for std::variant.
Clang does print a lot more info, including this:
/home/jwakely/gcc/latest/lib/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../include/c++/9.0.0/variant:1093:2:
note: candidate template ignored: substitution failure [with _Tp = PacketErr &,
$1 = void, $2 = void]: implicit instantiation of undefined template
'std::variant::__to_type_impl<18446744073709551615, false>'
variant(_Tp&& __t)
^
But that still doesn't come close to telling you that the type is not copyable.
N.B. If you just write "return ret;" it will compile fine. In general "return
x;" is better than "return {x};" because it doesn't prevent NRVO.
[Bug c++/87057] in compilation error, gcc should note about deleted copy-constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87057
--- Comment #2 from Konstantin Kharlamov ---
(In reply to Jonathan Wakely from comment #1)
> That would require a lot of special-casing just for std::variant.
Well, I think, in place of std::variant there could be any struct-wrapper; but
I get it.
> Clang does print a lot more info, including this:
>
> /home/jwakely/gcc/latest/lib/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../
> include/c++/9.0.0/variant:1093:2: note: candidate template ignored:
> substitution failure [with _Tp = PacketErr &, $1 = void, $2 = void]:
> implicit instantiation of undefined template
> 'std::variant PacketErr>::__to_type_impl<18446744073709551615, false>'
> variant(_Tp&& __t)
> ^
>
> But that still doesn't come close to telling you that the type is not
> copyable.
Actually, GCC does give the like output if you'd replace `return {ret}` with
explicit `return std::variant{ret}`, though it
doesn't hint about the type being non-copyable either.
> N.B. If you just write "return ret;" it will compile fine. In general
> "return x;" is better than "return {x};" because it doesn't prevent NRVO.
Thanks, I prefer the `{x}` to just `x` because in the latter I'm being explicit
that the `x` is not the type I'm returning, but there's some other type that
it's being wrapped to.
As far as such trivial optimizations concerned, I'd prefer to rely on the
compiler figuring that out — in the end, that's why we don't write assembly,
right? =)
[Bug libstdc++/77854] std::deque doesn't use allocator's size_type and difference_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77854 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Wed Aug 22 12:11:17 2018 New Revision: 263767 URL: https://gcc.gnu.org/viewcvs?rev=263767&root=gcc&view=rev Log: PR libstdc++/77854 document size_type for containers PR libstdc++/77854 * doc/xml/manual/status_cxx1998.xml: Document size_type and difference_type for containers. * doc/html/*: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/html/manual/abi.html trunk/libstdc++-v3/doc/html/manual/bugs.html trunk/libstdc++-v3/doc/html/manual/status.html trunk/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
[Bug c++/87057] in compilation error, gcc should note about deleted copy-constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87057
--- Comment #3 from Konstantin Kharlamov ---
(In reply to Konstantin Kharlamov from comment #2)
> Thanks, I prefer the `{x}` to just `x` because in the latter I'm being
*"in the former", sorry.
[Bug libstdc++/77854] std::deque doesn't use allocator's size_type and difference_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77854 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #3 from Jonathan Wakely --- Done.
[Bug other/704] --help and --version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=704 --- Comment #15 from Iain Sandoe --- Author: iains Date: Wed Aug 22 12:12:46 2018 New Revision: 263768 URL: https://gcc.gnu.org/viewcvs?rev=263768&root=gcc&view=rev Log: Make the gcc-ar,nm, strip tools respond correctly to --help and --version when there's no plugin built. gcc/ PR other/704 * gcc-ar.c (main): Don’t try to invoke the plug-in if we’re not building it. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc-ar.c
[Bug fortran/87043] maybe-uninitialized warning for initialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87043 --- Comment #2 from Peter Vitt --- Oh, I see your point. But then still the question is why this warning is not shown when compiling with -Og.
[Bug middle-end/87049] __clear_cache() prototype confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87049 --- Comment #2 from Richard Earnshaw --- But won't that give problems for C++ because now you'll need to cast the pointers?
[Bug target/87047] [7/8/9 Regression] performance regression because of if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87047
--- Comment #3 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #2)
> I suspect it is treating cost 0 as being free rather than unknown cost. And
> the x86 backend is returning 0 cost for the upper multiple.
There is no truncate RTX present in the dumps.
But in any case, moving 10+ insns out of THEN block seems excessive:
IF-THEN-JOIN block found, pass 1, test 34, then 35, join 15
scanning new insn with uid = 320.
scanning new insn with uid = 321.
scanning new insn with uid = 322.
scanning new insn with uid = 323.
scanning new insn with uid = 324.
scanning new insn with uid = 325.
scanning new insn with uid = 326.
scanning new insn with uid = 327.
scanning new insn with uid = 328.
scanning new insn with uid = 329.
scanning new insn with uid = 330.
if-conversion succeeded through noce_try_cmove_arith
Removing jump 225.
deleting insn with uid = 225.
deleting insn with uid = 235.
deleting insn with uid = 286.
deleting insn with uid = 232.
deleting insn with uid = 231.
deleting insn with uid = 230.
deleting insn with uid = 229.
deleting insn with uid = 284.
deleting insn with uid = 227.
deleting block 35
Conversion succeeded on pass 1.
...
* 224: flags:CCZ=cmp(r245:SI,0)
* REG_DEAD r245:SI
225: pc={(flags:CCZ!=0)?L222:pc}
REG_DEAD flags:CCZ
REG_BR_PROB 536870916
226: NOTE_INSN_BASIC_BLOCK 40
227: {r246:TI=zero_extend(r91:DI)*zero_extend(r136:DI);clobber flags:CC;}
REG_UNUSED flags:CC
284: r262:DI=r246:TI#8
REG_DEAD r246:TI
229: r249:DI=0xf
230: {r248:DI=r249:DI-r262:DI;clobber flags:CC;}
REG_DEAD r262:DI
REG_DEAD r249:DI
REG_UNUSED flags:CC
231: {r250:DI=r248:DI<<0x2c;clobber flags:CC;}
REG_DEAD r248:DI
REG_UNUSED flags:CC
232: {r251:TI=zero_extend(r250:DI)*zero_extend(r91:DI);clobber flags:CC;}
REG_DEAD r250:DI
REG_DEAD r91:DI
REG_UNUSED flags:CC
286: r264:DI=r251:TI#8
REG_DEAD r251:TI
235: {r91:DI=r264:DI<<0x1;clobber flags:CC;}
REG_DEAD r264:DI
REG_UNUSED flags:CC
...
is moved to:
...
* 224: flags:CCZ=cmp(r245:SI,0)
* REG_DEAD r245:SI
320: {r246:TI=zero_extend(r91:DI)*zero_extend(r136:DI);clobber flags:CC;}
321: r262:DI=r246:TI#8
322: r249:DI=0xf
323: {r248:DI=r249:DI-r262:DI;clobber flags:CC;}
324: {r250:DI=r248:DI<<0x2c;clobber flags:CC;}
325: {r251:TI=zero_extend(r250:DI)*zero_extend(r91:DI);clobber flags:CC;}
326: r264:DI=r251:TI#8
327: {r270:DI=r264:DI<<0x1;clobber flags:CC;}
328: {r269:DI=r243:DI<<0xf;clobber flags:CC;}
* 329: flags:CCZ=cmp(r245:SI,0)
330: r91:DI={(flags:CCZ!=0)?r269:DI:r270:DI}
...
(not to mention that (insn 224) in front should be removed as well, it is
duplicated as (insn 329)).
I don't think x86 declares all moved insn costs as 0.
[Bug debug/86964] Too many debug symbols included, especially for extern globals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964 --- Comment #2 from Joe Lorenz --- (In reply to Richard Biener from comment #1) > Confirmed. Debug info is now more complete. Note > -feliminate-unused-debug-symbols is only implemented for STABS debugging, > not for DWARF and from > my reading implementing it for DWARF is what you'd like to see. > > If you use GCC 8 or newer and LTO and apply dwarf compression using the dwz > tool the final debug info will be smaller than with GCC 4.9. Unfortunately > dwarf compression doesn't help when not using LTO as it seems to be > "confused" > by location attributes. > > Let's make this bug a request for implementing > -feliminate-unused-debug-symbols > for DWARF. If implementing that option for DWARF will achieve the same behavior as the 4.9 version, then yes, I think that would be exactly what I'm after. I think it's fine if the default behavior (with no added option) stays as it is. But having control over it is essential when working with the nature of the source tree I am saddled with. I'm grateful for your focus and effort and I hesitate to ask, but what sort of time frame are we talking for a change like this?
[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to Richard Biener from comment #5) > I think even -Wall makes sense. Maybe eventually, but I think a good compromise would be to put it in -Wextra for gcc 9, and then move it to -Wall for gcc 10, so people have time to adjust to the gradual strictening
[Bug debug/86964] Too many debug symbols included, especially for extern globals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964 --- Comment #3 from rguenther at suse dot de --- On Wed, 22 Aug 2018, znerol at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964 > > --- Comment #2 from Joe Lorenz --- > (In reply to Richard Biener from comment #1) > > Confirmed. Debug info is now more complete. Note > > -feliminate-unused-debug-symbols is only implemented for STABS debugging, > > not for DWARF and from > > my reading implementing it for DWARF is what you'd like to see. > > > > If you use GCC 8 or newer and LTO and apply dwarf compression using the dwz > > tool the final debug info will be smaller than with GCC 4.9. Unfortunately > > dwarf compression doesn't help when not using LTO as it seems to be > > "confused" > > by location attributes. > > > > Let's make this bug a request for implementing > > -feliminate-unused-debug-symbols > > for DWARF. > > If implementing that option for DWARF will achieve the same behavior as the > 4.9 > version, then yes, I think that would be exactly what I'm after. I think it's > fine if the default behavior (with no added option) stays as it is. But having > control over it is essential when working with the nature of the source tree I > am saddled with. > > I'm grateful for your focus and effort and I hesitate to ask, but what sort of > time frame are we talking for a change like this? Well, implementing shouldn't take more than a day or so but that day has to be carved out of somebodies spare time to work on GCC. Eventually Tom can help out.
[Bug tree-optimization/86725] ICE: Segmentation fault (in vect_get_vec_def_for_operand_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86725 --- Comment #2 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Wed Aug 22 13:02:39 2018 New Revision: 263773 URL: https://gcc.gnu.org/viewcvs?rev=263773&root=gcc&view=rev Log: [1/2] Fix bogus double reduction (PR 86725) This patch is the first part of the fix for PR 86725. We would treat x_1 in: outer1: x_1 = PHI ; ... inner: x_2 = ...x_1...; ... x_3 = ...; ... outer2: x_4 = PHI ; ... as a double reduction without checking what kind of statement x_2 is. In practice it has to be a phi, since for other x_2, x_1 would simply be a loop invariant that gets used for every inner loop iteration. The idea with doing this patch first is that, by checking x_2 really is a phi, we can hand off the validation of the rest of the reduction to the phi analysis in the inner loop. The test case is a variant of the one in the PR. 2018-08-22 Richard Sandiford gcc/ PR tree-optimization/86725 * tree-vect-loop.c (vect_is_simple_reduction): When treating an outer loop phi as a double reduction, make sure that the single user of the phi result is an inner loop phi. gcc/testsuite/ PR tree-optimization/86725 * gcc.dg/vect/no-scevccp-pr86725-1.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/no-scevccp-pr86725-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/86725] ICE: Segmentation fault (in vect_get_vec_def_for_operand_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86725
--- Comment #3 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Wed Aug 22 13:02:48 2018
New Revision: 263774
URL: https://gcc.gnu.org/viewcvs?rev=263774&root=gcc&view=rev
Log:
[2/2] Fix bogus inner induction (PR 86725)
This patch is the second part of the fix for PR 86725. The problem
in the original test is that for:
outer1:
x_1 = PHI ;
...
inner:
x_2 = PHI ;
...
x_3 = ...;
...
outer2:
x_4 = PHI ;
...
there are corner cases in which it is possible to classify the
inner phi as an induction but not the outer phi. The -4.c test
is a more direct example.
After failing to classify x_1 as an induction, we go on to
classify it as a double reduction (which is basically true).
But we still classified the inner phi as an induction rather
than as part of a reduction, leading to an ICE when trying
to vectorise the outer phi.
We analyse the phis for outer loops first, so the simplest
fix is not to classify the phi as an induction if outer loop
analysis said that it should be a reduction.
The -2.c test is from the original PR. The -3.c test is a
version in which "wo" really is used a reduction; this was
already correctly rejected, but for the wrong reason ("inner-loop
induction only used outside of the outer vectorized loop").
The -4.c test is another way of tickling the original problem
without relying on the undefinedness of signed overflow.
The -5.c test shows an (uninteresting) example in which the
patch prevents a spurious failure to vectorise the outer loop.
2018-08-22 Richard Sandiford
gcc/
PR tree-optimization/86725
* tree-vect-loop.c (vect_inner_phi_in_double_reduction_p): New
function.
(vect_analyze_scalar_cycles_1): Check it.
gcc/testsuite/
PR tree-optimization/86725
* gcc.dg/vect/no-scevccp-pr86725-2.c: New test.
* gcc.dg/vect/no-scevccp-pr86725-3.c: Likewise.
* gcc.dg/vect/no-scevccp-pr86725-4.c: Likewise.
* gcc.dg/vect/no-scevccp-pr86725-5.c: Likewise.
Added:
trunk/gcc/testsuite/gcc.dg/vect/no-scevccp-pr86725-2.c
trunk/gcc/testsuite/gcc.dg/vect/no-scevccp-pr86725-3.c
trunk/gcc/testsuite/gcc.dg/vect/no-scevccp-pr86725-4.c
trunk/gcc/testsuite/gcc.dg/vect/no-scevccp-pr86725-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/86725] ICE: Segmentation fault (in vect_get_vec_def_for_operand_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86725 --- Comment #4 from rsandifo at gcc dot gnu.org --- Fixed on trunk so far.
[Bug tree-optimization/87059] [9 Regression] internal compiler error: in set_value_range, at tree-vrp.c:289
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87059 Richard Biener changed: What|Removed |Added CC||aldyh at gcc dot gnu.org Component|target |tree-optimization Version|unknown |9.0 Target Milestone|--- |9.0 Summary|internal compiler error: in |[9 Regression] internal |set_value_range, at |compiler error: in |tree-vrp.c:289 |set_value_range, at ||tree-vrp.c:289
