[Bug bootstrap/93962] bootstrap fails with gcc/value-prof.c:268:28 : error: format '%lld' expects argument of type 'long long int', but argument 3 hastype 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93962
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment #10 from Eric Botcazou ---
There is another abs at line 746 which causes a bootstrap failure on Solaris
11:
/homes/botcazou/gcc-head/src/gcc/value-prof.c: In function 'bool
get_nth_most_common_value(gimple*, const char*, histogram_value, gcov_type*,
gcov_type*, gcov_type*, unsigned int)':
/homes/botcazou/gcc-head/src/gcc/value-prof.c:746:53: error: call of overloaded
'abs(gcov_type&)' is ambiguous
gcov_type read_all = abs (hist->hvalue.counters[0]);
^
/homes/botcazou/gcc-head/src/gcc/value-prof.c:746:53: note: candidates are:
In file included from /usr/include/stdlib.h:11:0,
from /homes/botcazou/gcc-head/src/gcc/system.h:258,
from /homes/botcazou/gcc-head/src/gcc/value-prof.c:21:
/usr/include/iso/stdlib_iso.h:154:23: note: long int std::abs(long int)
inline long abs(long _l) { return labs(_l); }
^
/usr/include/iso/stdlib_iso.h:108:12: note: int std::abs(int)
extern int abs(int);
^
gmake[3]: *** [value-prof.o] Error 1
[Bug middle-end/93961] gnat.dg/lto24.adb FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93961 Eric Botcazou changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-cvs/2020-March/27109 ||4.html Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Eric Botcazou --- .
[Bug rtl-optimization/94119] MIPS: Invalid use of branch delay slots leading to corrupt jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94119 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-03-11 Ever confirmed|0 |1 CC||ebotcazou at gcc dot gnu.org --- Comment #1 from Eric Botcazou --- Please post the output of 'gcc -v' for the affected compiler.
[Bug rtl-optimization/94119] MIPS: Invalid use of branch delay slots leading to corrupt jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94119 --- Comment #3 from Eric Botcazou --- > The addiu s0,s0,0 instruction must only be issued once but instead is in > several places. This leads to an invalid call at 9c. Duplicating the instruction is not a problem per se if it is executed only once on any execution path. Are you sure that the problem is for the call at 9c? > 8c: 3c10lui s0,0x0 > 8c: R_MIPS_HI16 memcmp_ > 90: 24060006li a2,6 > 94: 27a50014addiu a1,sp,20 > 98: 2610addiu s0,s0,0 > 98: R_MIPS_LO16 memcmp_ > 9c: 0200f809jalrs0 AFAICS there is only one "addiu s0,s0,0" executed after the "lui s0,0x0" in this basic block. Doesn't the problem occur for the call in the following basic block instead?
[Bug rtl-optimization/94119] [8/9/10 regression] invalid filling of branch delay slots leads to corrupt jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94119 Eric Botcazou changed: What|Removed |Added Target|Mips|mips*-*-* Target Milestone|--- |8.5 Status|WAITING |NEW Summary|MIPS: Invalid use of branch |[8/9/10 regression] invalid |delay slots leading to |filling of branch delay |corrupt jump|slots leads to corrupt jump --- Comment #5 from Eric Botcazou --- > You are right. I truncated the disassembly too early. OK, thanks, I can reproduce.
[Bug rtl-optimization/94119] [8/9/10 regression] invalid filling of branch delay slots leads to corrupt jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94119 Eric Botcazou changed: What|Removed |Added CC|ebotcazou at gcc dot gnu.org | Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from Eric Botcazou --- Fixing.
[Bug target/92071] [10 regression][ARM] ice in gen_movsi, at config/arm/arm.md:5378
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92071 --- Comment #13 from Eric Botcazou --- I'm leaning towards calling extract_bit_field instead of operand_subword_force on the value from store_integral_bit_field in order to generate the unaligned load. However, this triggers bad memories (see PR middle-end/50325).
[Bug middle-end/92071] [10 regression][ARM] ice in gen_movsi, at config/arm/arm.md:5378
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92071 Eric Botcazou changed: What|Removed |Added Component|target |middle-end --- Comment #14 from Eric Botcazou --- Recategorizing
[Bug middle-end/92071] [10 regression] ICE in gen_movsi, at config/arm/arm.md:5378
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92071 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Summary|[10 regression][ARM] ice in |[10 regression] ICE in |gen_movsi, at |gen_movsi, at |config/arm/arm.md:5378 |config/arm/arm.md:5378 URL||https://gcc.gnu.org/piperma ||il/gcc-cvs/2020-March/27168 ||1.html Resolution|--- |FIXED --- Comment #15 from Eric Botcazou --- Fixed in r10-7151.
[Bug rtl-optimization/94119] [8/9/10 regression] invalid filling of branch delay slots leads to corrupt jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94119 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Eric Botcazou --- Fixed on all active branches.
[Bug rtl-optimization/92303] [10 regression] gcc.target/sparc/ultrasp12.c times out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92303 Eric Botcazou changed: What|Removed |Added Component|target |rtl-optimization --- Comment #12 from Eric Botcazou --- Recategorizing.
[Bug rtl-optimization/94119] [8/9/10 regression] invalid filling of branch delay slots leads to corrupt jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94119 --- Comment #12 from Eric Botcazou --- > I noticed that you accidentially put the wrong year into the ChangeLog. Thanks, fixed.
[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359 --- Comment #10 from Eric Botcazou --- > No. I guess Eric (Cc'ed) is in a better position to answer that. Same as for PowerPC: look at the function_ok_for_sibcall predicate.
[Bug ada/94419] accepting wrong programs because compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94419 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-04-04 --- Comment #1 from Eric Botcazou --- > Please, note Ada is not C, Ada is about safety. A program should be checked > for corectness and any errors must be reported almost always, at runtime > also. There are also cases when checks would be too hard to implement, but > those cases are relatively rare, they ever need more arguments, than > implementation complexity. Well, GNAT passes 100% of the tests of the ACATS testsuites, which contain thousands of correctness tests, so finding some bugs cannot be a pretext for depreciating it as you do. Every complex software has bugs, a compiler is a complex software, ergo it has bugs. You don't cite the clauses of the Ada RM that would make your program illegal and you don't say which version of GNAT you use so there isn't much we can do. > Another bad thing in GNAT is implementation of "mutable" records, they > always need maximum memory. It is from GNAT manual: > type Rec (D : Positive := 15) is record >Name : String (1..D); > end record; > > Too_Large : Rec; > > is flagged by the compiler with a warning: an attempt to create > `Too_Large' will raise `Storage_Error', because the required size > includes `Positive'Last' bytes. > > It is bad. I think such records should be dynamically reallocatable. GNAT > manual says that such way is improper, but it is not that, it is right. No, it's just a trade off and GNAT has selected this implementation. But you can certainly write your own Ada compiler with another implementation.
[Bug ada/94419] missing errors for constraints on access types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94419 Eric Botcazou changed: What|Removed |Added Status|WAITING |NEW Summary|accepting wrong programs|missing errors for |because compiler error |constraints on access types --- Comment #5 from Eric Botcazou --- > Recently I test gcc 9.3.0 and it report some errors in the example code. But > I modify it slightly and it works with no errors. > I think the code is enough clear to see what exact clauses RM are violated. > For example there is conversion from access to constrained to access to > unconstrained type, and the type have a constrained partial view, while > legality rules for conversions requires for such case that any partial view > were unconstrained. There is also assignments of different subtypes (which > have no common values). Yes, some errors are indeed missing. The thing is, constraints on access types have been historically problematic in Ada from an implementation point of view and there even have been talks about removing them.
[Bug tree-optimization/94573] Optimizer produces suboptimal code related to -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94573 --- Comment #3 from Eric Botcazou --- > In particular, fixed with r10-3575-g629387a6586a753166f5cf53d587026a34362523 > I thought that commit was about store merging with non-call-expceptions, but > apparently it affects more. Possibly the adjust_bit_pos change.
[Bug tree-optimization/94717] [10 Regression] ICE: SIGSEGV in output_merged_store (gimple-ssa-store-merging.c:4307) with -O2 -fnon-call-exceptions -ftracer since r10-3575-g629387a6586a7531
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94717 Eric Botcazou changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Eric Botcazou --- The compiler is apparently not prepared for new trapping loads. Fixing...
[Bug tree-optimization/94717] [10 Regression] segfault with -O2 -fnon-call-exceptions -ftracer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94717 --- Comment #3 from Eric Botcazou --- > The compiler is apparently not prepared for new trapping loads. Fixing... No, just a missing check on landing pads: index a6687cd9c98..4ab8e0250ab 100644 --- a/gcc/gimple-ssa-store-merging.c +++ b/gcc/gimple-ssa-store-merging.c @@ -2680,6 +2680,7 @@ imm_store_chain_info::coalesce_immediate_stores () p[3] = data; using the bswap framework. */ if (info->bitpos == merged_store->start + merged_store->width + && info->lp_nr == merged_store->lp_nr && merged_store->stores.length () == 1 && merged_store->stores[0]->ins_stmt != NULL && info->ins_stmt != NULL)
[Bug tree-optimization/94717] [10 Regression] segfault with -O2 -fnon-call-exceptions -ftracer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94717 --- Comment #5 from Eric Botcazou --- > Shouldn't that be done in try_coalesce_bswap instead? > Because checking lp_nr above will only make sure it is the same between > merged_store and the first store after it, but we are trying to coalesce > often more than that. > By checking it in try_coalesce_bswap, in the first loop in that function, it > will verify all stores. OK, I didn't realize that try_coalesce_bswap has its own private loop. But this can be done in both places, like the check on ins_stmt.
[Bug tree-optimization/94717] [10 Regression] segfault with -O2 -fnon-call-exceptions -ftracer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94717 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Eric Botcazou --- .
[Bug c++/94896] [10/11 regression] ICE: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94896 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Target|sparc-sun-solaris2.11 |sparc-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2020-05-01 --- Comment #1 from Eric Botcazou --- I have them both on Linux and Solaris.
[Bug c++/94896] [10/11 regression] ICE: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94896 Eric Botcazou changed: What|Removed |Added CC||polacek at redhat dot com --- Comment #2 from Eric Botcazou --- This comes from: 2020-04-30 Marek Polacek PR c++/94775 * tree.c (check_base_type): Return true only if TYPE_USER_ALIGN match. (check_aligned_type): Check if TYPE_USER_ALIGN match. which is a rather risky change so close to a release if you ask me.
[Bug bootstrap/94918] [8/9/10/11 regression] Ada bootstrap errors on Cygwin64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94918 Eric Botcazou changed: What|Removed |Added Last reconfirmed||2020-05-04 Summary|Ada bootstrap errors on |[8/9/10/11 regression] Ada |Cygwin64|bootstrap errors on ||Cygwin64 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Eric Botcazou --- The g-sercom.adb failure is indeed a small oversight.
[Bug bootstrap/94918] [8/9/10/11 regression] Ada bootstrap errors on Cygwin64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94918 --- Comment #7 from Eric Botcazou --- The Ada bits have been installed, but approval from a global maintainer is needed for the libgcc bits.
[Bug rtl-optimization/94873] [8/9/10/11 Regression] wrong code with -O -fno-merge-constants -fno-split-wide-types -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873 --- Comment #13 from Eric Botcazou --- Since Richard kindly invited me to the party, I feel entitled to voice my personal opinion :-) which is apparently aligned with Richard's. I think that we should allow REG_EQUAL notes for insns with exactly one SET of a register, the contents of the note being the value present in this register after the execution of the insn at run time, and disregarding side effects. IMO that's the spirit of the current implementation and thus also probably the most straightforward way out.
[Bug rtl-optimization/94873] [8/9/10/11 Regression] wrong code with -O -fno-merge-constants -fno-split-wide-types -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873 --- Comment #15 from Eric Botcazou --- > So, hrm, we could in principle attach a REG_EQ* note to any single_set > instruction? Yes, I think that's what is currently implemented modulo bugs, although of course we do not create a REG_EQUAL note for every single_set insn in practice.
[Bug rtl-optimization/94873] [8/9/10/11 Regression] wrong code with -O -fno-merge-constants -fno-split-wide-types -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873 --- Comment #17 from Eric Botcazou --- > Ok, so what we do about this bug then if it ought to be combine.c that needs > changing? For REG_EQUAL notes in combine_instructions check for the > auto-incdec side-effects in the pattern (I'd hope we don't have them in > REG_EQUAL notes content) and if there are any, punt? At least for > backporting that seems like the right solution, and given that it seems > try_combine also punts on these if we remove or add any in the patterns, it > seems in line with what the rest of combiner does. At least the fix for the branches seems to be clear: do not do the temporary replacement in combine_instructions if the SET_SRC has side effects; there are a bunch of similar side_effects_p tests in the combiner. > Or, shall it e.g. queue the side-effects in some new argument to try_combine > and if the combination would succeed, add the side-effect as yet another > instruction (if it can match and is cheaper than what we have previously)? That seems overkill to me, even on the mainline, but others might disagree.
[Bug ada/65696] ASAN reports global-buffer-overrun for local tagged types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65696 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |10.0 Status|NEW |RESOLVED --- Comment #5 from Eric Botcazou --- You're welcome.
[Bug ada/95035] [11 regression] gnat.dg/sso/p10.adb FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95035 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-05-11 --- Comment #1 from Eric Botcazou --- I can reproduce.
[Bug ada/95035] [11 regression] gnat.dg/sso/p10.adb FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95035 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- Fixing.
[Bug ada/95035] [11 regression] gnat.dg/sso/p10.adb FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95035 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Eric Botcazou --- Thanks for reporting the problem.
[Bug bootstrap/95333] [11 Regression] error: number of counters in profile data for function ‘exp_attr__find_stream_subprogram’ does not match its profile data since r11-200-gdb4062a0cbe00ce4075a4d7f6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95333 Eric Botcazou changed: What|Removed |Added Target Milestone|--- |11.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Eric Botcazou --- Presumably.
[Bug ada/95452] Overflow Bug in GNAT Heapsort implementations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95452 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Last reconfirmed||2020-06-01 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Indeed, we should either detect the overflow or enlarge the type.
[Bug middle-end/95395] gcc.dg/builtin-bswap-11.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95395 Eric Botcazou changed: What|Removed |Added Last reconfirmed||2020-06-01 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Eric Botcazou --- Likewise on Linux.
[Bug middle-end/95395] gcc.dg/builtin-bswap-11.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95395 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou --- Fixing.
[Bug middle-end/95395] gcc.dg/builtin-bswap-11.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95395 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Eric Botcazou --- Thanks for reporting the problem.
[Bug tree-optimization/95433] Failure to completely optimize simple compare after operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95433 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #4 from Eric Botcazou --- > Hmm, are we supposed to solve/simplify arbitrary linear equations? > > 3 * x * x * x + 5 == 8 > > is equal to x == 1. > > 3 * x * x + 5 == 8 > > is equal to abs(x) == 1. Solving linear equations is at least tractable, which is not the case of general polynomial equations, especially if the degree is greater than 4. ;-)
[Bug bootstrap/95582] [11 Regression] LTO lean + PGO bootstrap is broken in Ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582 --- Comment #8 from Eric Botcazou --- Well, the middle-end provides build_nonstandard_boolean_type to build boolean types with arbitrary precision so it cannot assume they have precision 1.
[Bug bootstrap/95582] [11 Regression] LTO lean + PGO bootstrap is broken in Ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582 --- Comment #10 from Eric Botcazou --- > Yeah, that was for vector components. Not that I like it much. Can > the middle-end assume that the Ada boolean types only contain 0 or 1 > or are there other values that are supposed to be well-defined > true or false values? The only well-defined values are 0 and 1, but all the bits up to the precision need to be preserved in "nonlogical contexts". So it's a standard boolean type in "logical contexts" (with binary logic) and an integral type with precision 8 in "nonlogical contexts", the possibly issues arising of course at the transition. In practice this works fine without special handling in almost all cases, you just need to be careful when you're manipulating bit patterns.
[Bug target/95730] GCN offloading ICEs after commit fe7ebef7fe4f9acb79658ed9db0749b07efc3105 "Add support for __builtin_bswap128"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95730 Eric Botcazou changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-06-17 Status|UNCONFIRMED |NEW --- Comment #2 from Eric Botcazou --- The error_mark_node very likely comes from: DEF_PRIMITIVE_TYPE (BT_UINT128, uint128_type_node ? uint128_type_node : error_mark_node) but this is a standard idiom in builtin-types.def so rather strange indeed. I gather that targetm.scalar_mode_supported_p (TImode) returns false for GCN?
[Bug target/95637] Read-only data assigned to `.sdata' rather than `.rodata'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95637 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-06-28 --- Comment #5 from Eric Botcazou --- > Regardless, I think run-time enforcement of the immutability of constant > data is important for some use cases and possibly even required by some > programming languages (Ada?). No, not in Ada, and I don't really see how this could be done as languages are usually specified in terms of an abstract machine; it's pure ABI stuff.
[Bug ada/95664] link failure with abstract equality operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95664 Eric Botcazou changed: What|Removed |Added Last reconfirmed||2020-06-29 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Summary|generic instantiation fails |link failure with abstract |to detect abstract |equality operator |equality, builds with gcc-9 | |and fails to link with | |gcc-10 | --- Comment #3 from Eric Botcazou --- Please attach the concatenation of the source files next time.
[Bug ada/95691] Functions for case insensitive comparison of wide strings are not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95691 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||ebotcazou at gcc dot gnu.org Last reconfirmed||2020-06-29 Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Contributions welcome.
[Bug bootstrap/95940] [11 Regression] bootstrap broken by -Wmaybe-unintialized warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95940
Martin Sebor changed:
What|Removed |Added
Status|WAITING |NEW
Eric Botcazou changed:
What|Removed |Added
Summary|[11 Regression] |[11 Regression] bootstrap
|sparc64-linux bootstrap |broken by
|with gcc-9.3 broken |-Wmaybe-unintialized
||warnings
CC||ebotcazou at gcc dot gnu.org
--- Comment #4 from Martin Sebor ---
The first -Wmaybe-unintialized warning is issued for the read in this
statement:
SR.1076_294 = D.75512.D.16218.val[1];
in the following basic block:
[local count: 130803720]:
# SR.268_98 = PHI <_104(23), _75(39)>
D.75553 ={v} {CLOBBER};
D.75512 ={v} {CLOBBER};
xi ={v} {CLOBBER};
SR.1076_294 = D.75512.D.16218.val[1]; <<< warning
SR.1077_296 = D.75512.D.16218.val[2]; <<< warning
D.75512 ={v} {CLOBBER};
D.75513 ={v} {CLOBBER};
goto ; [100.00%]
Since D.75512 is clobbered just prior to the read from it I think the warning
is justified. Subsequent warnings follow a similar pattern:
[local count: 349243402]:
# SR.268_123 = PHI <_129(25), -1(41)>
D.75575 ={v} {CLOBBER};
D.75514 ={v} {CLOBBER};
xi ={v} {CLOBBER};
SR.1076_230 = D.75514.D.16218.val[1]; <<< warning
SR.1077_105 = D.75514.D.16218.val[2]; <<< warning
D.75514 ={v} {CLOBBER};
D.75515 ={v} {CLOBBER};
goto ; [100.00%]
...
[local count: 68586742]:
# SR.268_148 = PHI <_154(30), -1(40)>
D.75597 ={v} {CLOBBER};
D.75516 ={v} {CLOBBER};
xi ={v} {CLOBBER};
SR.1076_219 = D.75516.D.16218.val[1]; <<< warning
SR.1077_220 = D.75516.D.16218.val[2]; <<< warning
D.75516 ={v} {CLOBBER};
D.75517 ={v} {CLOBBER};
goto ; [100.00%]
--- Comment #5 from Martin Sebor ---
The first -Wmaybe-unintialized warning is issued for the read in this
statement:
SR.1076_294 = D.75512.D.16218.val[1];
in the following basic block:
[local count: 130803720]:
# SR.268_98 = PHI <_104(23), _75(39)>
D.75553 ={v} {CLOBBER};
D.75512 ={v} {CLOBBER};
xi ={v} {CLOBBER};
SR.1076_294 = D.75512.D.16218.val[1]; <<< warning
SR.1077_296 = D.75512.D.16218.val[2]; <<< warning
D.75512 ={v} {CLOBBER};
D.75513 ={v} {CLOBBER};
goto ; [100.00%]
Since D.75512 is clobbered just prior to the read from it I think the warning
is justified. Subsequent warnings follow a similar pattern:
[local count: 349243402]:
# SR.268_123 = PHI <_129(25), -1(41)>
D.75575 ={v} {CLOBBER};
D.75514 ={v} {CLOBBER};
xi ={v} {CLOBBER};
SR.1076_230 = D.75514.D.16218.val[1]; <<< warning
SR.1077_105 = D.75514.D.16218.val[2]; <<< warning
D.75514 ={v} {CLOBBER};
D.75515 ={v} {CLOBBER};
goto ; [100.00%]
...
[local count: 68586742]:
# SR.268_148 = PHI <_154(30), -1(40)>
D.75597 ={v} {CLOBBER};
D.75516 ={v} {CLOBBER};
xi ={v} {CLOBBER};
SR.1076_219 = D.75516.D.16218.val[1]; <<< warning
SR.1077_220 = D.75516.D.16218.val[2]; <<< warning
D.75516 ={v} {CLOBBER};
D.75517 ={v} {CLOBBER};
goto ; [100.00%]
--- Comment #6 from Eric Botcazou ---
> From the look of it, something is already miscompiled.
No, not at all, it's just warnings turned into errors.
[Bug c/96019] Optimization forgets non-default scalar_storage_order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96019 Eric Botcazou changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Eric Botcazou --- See the manual: Moreover, the use of type punning or aliasing to toggle the storage order is not supported; that is to say, a given scalar object cannot be accessed through distinct types that assign a different storage order to it.
[Bug c/96019] Optimization forgets non-default scalar_storage_order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96019
--- Comment #4 from Eric Botcazou ---
> So AFAIU
>
> int main(int argc, char *argv[]) {
> uint8_t raw[] = { 0xaa, 0xbb, 0xcc, 0xdd, 0x11, 0x22 };
> SS instance;
> memcpy (&instance, raw, sizeof (SS));
> printf("%x, %x\n", instance.a, instance.b);
> return 0;
> }
>
> would be OK(?)
Yes, this should work once the patch (or a variant thereof) I posted some time
ago to make memcpy a storage order barrier is installed. :-)
[Bug bootstrap/92002] [10/11 regression] -Wuninitialized warning in gcc/wide-int.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92002 Eric Botcazou changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #14 from Eric Botcazou --- *** Bug 95940 has been marked as a duplicate of this bug. ***
[Bug bootstrap/95940] [11 Regression] bootstrap broken by -Wmaybe-unintialized warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95940 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #8 from Eric Botcazou --- > Not obvious, but I see from the comments that people seem to be on the right > track. Some target-specific thing under the hood (not obvious to me in the > source) in tree-ssanames.c provoking this? Obvious for those who maintain the SPARC compiler. ;-) The warnings have been there for months in the 10.x series. In fact it's a duplicate. *** This bug has been marked as a duplicate of bug 92002 ***
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #18 from Eric Botcazou --- If the control flow goes through .L12: .L12: b .L3; return 0; (not interesting, fall through) ldi 1,%r28 the return value will be 1 since ldi is in the delay slot of the branch. What happens if you compile with -O2 -fno-delayed-branch instead?
[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 Eric Botcazou changed: What|Removed |Added Component|target |rtl-optimization Status|WAITING |ASSIGNED --- Comment #26 from Eric Botcazou --- I'm going to have a look.
[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #29 from Eric Botcazou ---
It's again __builtin_unreachable making a mess in the RTL stream:
(note 23 11 24 [bb 3] NOTE_INSN_BASIC_BLOCK)
(jump_insn:TI 24 23 15 (set (pc)
(if_then_else (leu (reg/v:SI 24 %r24 [orig:99 g ] [99])
(const_int 5 [0x5]))
(label_ref:SI 81)
(pc))) 30 {*pa.md:1413}
(int_list:REG_BR_PROB 536870916 (nil))
-> 81)
(code_label 15 24 17 4 (nil) [2 uses])
(barrier 17 15 16)
(note 16 17 81 [bb 4] NOTE_INSN_BASIC_BLOCK)
(code_label 81 16 43 12 (nil) [1 uses])
(note 43 81 25 [bb 5] NOTE_INSN_BASIC_BLOCK)
(jump_insn:TI 25 43 26 (parallel [
(set (pc)
(mem:SI (plus:SI (mult:SI (reg/v:SI 24 %r24 [orig:99 g ] [99])
(const_int 4 [0x4]))
(label_ref 26)) [0 S4 A32]))
(clobber (reg:SI 28 %r28))
]) 198 {casesi32}
(expr_list:REG_DEAD (reg/v:SI 24 %r24 [orig:99 g ] [99])
(expr_list:REG_UNUSED (reg:SI 28 %r28)
(nil)))
-> 26)
relax_delay_slots sees that jump_insn 24 jumps to the next active instruction
so it proceeds with removing it. Its target label 81 has only one use so it is
removed too. At this point delete_related_insns thinks that it can also remove
all the instructions after label 81 down to the next label because of the
presence of barrier 17:
/* If INSN was a label, delete insns following it if now unreachable. */
if (was_code_label && prev && BARRIER_P (prev))
{
enum rtx_code code;
while (next)
{
[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #30 from Eric Botcazou ---
Not clear what the right fix is... The hot spot in relax_delay_slots:
/* If this is a jump insn, see if it now jumps to a jump, jumps to
the next insn, or jumps to a label that is not the last of a
group of consecutive labels. */
if (is_a (insn)
&& (condjump_p (insn) || condjump_in_parallel_p (insn))
&& !ANY_RETURN_P (target_label = JUMP_LABEL (insn)))
{
rtx_jump_insn *jump_insn = as_a (insn);
target_label
= skip_consecutive_labels (follow_jumps (target_label, jump_insn,
&crossing));
if (ANY_RETURN_P (target_label))
target_label = find_end_label (target_label);
if (target_label
&& next_active_insn (as_a (target_label)) == next
&& ! condjump_in_parallel_p (jump_insn)
&& ! (next && switch_text_sections_between_p (jump_insn, next)))
{
delete_jump (jump_insn);
continue;
}
IIRC Jeff already dealt with this kind of issues in the past, so maybe he knows
what the best way out would be?
[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 Eric Botcazou changed: What|Removed |Added Assignee|ebotcazou at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #32 from Eric Botcazou --- OK, thanks, deferring to Jeff's judgment then.
[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #34 from Eric Botcazou --- > Eric, thoughts? Another possibility would be to remove the problematic barriers during the barriers pass that is run just before reorg: /* Some old code expects exactly one BARRIER as the NEXT_INSN of a non-fallthru insn. This is not generally true, as multiple barriers may have crept in, or the BARRIER may be separated from the last real insn by one or more NOTEs. This simple pass moves barriers and removes duplicates so that the old code is happy. */ static unsigned int cleanup_barriers (void) but this may void the fix for PR rtl-optimization/81025. In the end I think that the safest route is indeed probably to patch the hot spot in relax_delay_slots. There is already a similar guard for text section switches by means of switch_text_sections_between_p. The condition would be LABEL_NUSES of JUMP_LABEL equal to 1 and presence of a BARRIER between the jump and next insns.
[Bug tree-optimization/96167] fails to detect ROL pattern in simple case, but succeeds when operand goes through memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96167 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Severity|normal |enhancement Last reconfirmed||2020-07-15 Ever confirmed|0 |1 --- Comment #2 from Eric Botcazou --- store-merging certainly has the infrastructure and does it job until: /* A complete byte swap should make the symbolic number to start with the largest digit in the highest order byte. Unchanged symbolic number indicates a read with same endianness as target architecture. */ if (n.n != cmpnop && n.n != cmpxchg) return false; where it of course realizes that this is not a proper 64-bit bswap.
[Bug middle-end/96228] -Wstack-usage does not understand constant __builtin_alloca calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96228
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment #3 from Eric Botcazou ---
The reason is rather that no flow analysis is performed by -Wstack-usage, which
means that it cannot distinguish:
int main(void) {
char *a = __builtin_alloca(4);
a[0] = 0;
__builtin_printf("%c", a[0]);
return 0;
}
from
int main(void) {
while (1) {
char *a = __builtin_alloca(4);
a[0] = 0;
__builtin_printf("%c", a[0]);
}
return 0;
}
so it assumes the worst.
[Bug target/95730] GCN offloading ICEs after commit fe7ebef7fe4f9acb79658ed9db0749b07efc3105 "Add support for __builtin_bswap128"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95730 --- Comment #5 from Eric Botcazou --- > Therefore int128_t does not exist, as far as users are concerned. I'm not > sure how that translates to the GCC internals, but trying to use TImode for > anything other than moves is not going to work on GCN. Yes, the code precisely makes sure it is not used in this case, but it looks like something causes it to be nevertheless streamed.
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #12 from Eric Botcazou --- > So with the attached 'updated patch' I see > > === gnat tests === > > > Running target unix/ > FAIL: gnat.dg/debug11_pkg.adb scan-assembler-not foreign_imported_func > FAIL: gnat.dg/debug9.adb scan-assembler-times (DIE (0x[a-f0-9]*) > DW_ > TAG_type_unit) 0 > > where the first FAIL seems obvious from the name of 'foreign_imported_func' > and the changed outcome is expected and OK? The annoying thing is the discrepancy with the variable case; in other words, the patch is undercutting gnat_write_global_declarations (utils.c:5913). > For the second FAIL I see type units for system__secondary_stack_* types > and the extra subroutines are likely the invoked system__secondary_stack_* > functions like > > <1><77>: Abbrev Number: 38 (DW_TAG_subprogram) > <78> DW_AT_external: 1 > <78> DW_AT_name: (indirect string, offset: 0x47): > system__secondar > y_stack__ss_release > <7c> DW_AT_decl_file : 2 > <7d> DW_AT_decl_line : 95 > <7e> DW_AT_decl_column : 14 > <7f> DW_AT_sibling : <0x8e> > <2><83>: Abbrev Number: 39 (DW_TAG_formal_parameter) > <84> DW_AT_name: m > <86> DW_AT_decl_file : 2 > <87> DW_AT_decl_line : 95 > <88> DW_AT_decl_column : 26 > <89> DW_AT_type: <0x8e> > <2><8d>: Abbrev Number: 0 > > note they are not DECL_ARTIFICIAL and also not DECL_IGNORED. Now the > testcase tries to test sth else than no type units at all as its > comment explains. Yes, I agree that there is probably a missing DECL_IGNORED here.
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #16 from Eric Botcazou --- > So, for Ada, would you like to preserve current behavior rather than what > Richard's patch does? > If so, can't we have a langhook that decides that? > I don't know much about Ada, but would think that having the prototypes even > for functions defined in other shared libraries if they are called or > referenced in the TU is useful even for Ada. This yields useless duplication in 99.99% of the cases though and the debug info is already large enough. Can't you do this from the front-end instead, for the c-family of compilers?
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #22 from Eric Botcazou --- On the other hand, if all it takes to avoid the new DIEs is to set the DECL_IGNORED_P flag, then it might be simpler to go ahead with the change and set the flag in Ada more often.
[Bug ada/96344] 3rdd case of gnat.dg/opt86a.adb fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96344
Eric Botcazou changed:
What|Removed |Added
Summary|[11 regerssion] |3rdd case of
|gnat.dg/opt86a.adb fails|gnat.dg/opt86a.adb fails
|starting with r11-1675 |
Target Milestone|11.0|---
Last reconfirmed||2020-07-31
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #2 from Eric Botcazou ---
I can reproduce: the third optimization does not work
[local count: 1070914630]:
if (_40 == 1)
goto ; [0.04%]
else
goto ; [99.96%]
[local count: 1070486265]:
_65 = s3_41 + 252;
_73 = _65 & 251;
if (_73 == 0)
goto ; [0.04%]
else
goto ; [99.96%]
[local count: 1284581]:
.gnat_rcheck_PE_Explicit_Raise ("opt86a.adb", 27);
but that's not a regression, just a missed optimization.
[Bug target/96607] GCC feeds SPARC/Solaris linker with unrecognized TLS sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607 Eric Botcazou changed: What|Removed |Added CC|ebotcazou at gcc dot gnu.org | Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #4 from Eric Botcazou --- Fixing.
[Bug target/96607] GCC feeds SPARC/Solaris linker with unrecognized TLS sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-09-02 --- Comment #3 from Eric Botcazou --- It looks like the logic has been flawed since day #1 and we should be testing the insn which *has* the delay slot instead of the insn which is in the delay slot.
[Bug tree-optimization/97053] [10/11 Regression] an O2, O3 codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97053
--- Comment #2 from Eric Botcazou ---
The statement generated by DSE
MEM [(struct Data *)&data + 8B] = {};
looks nonsensical and I guess store-merging is not prepared for it.
[Bug middle-end/97078] [11 Regression] ICE in set_rtl building glibc tests with -ffloat-store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97078
--- Comment #1 from Eric Botcazou ---
The following few lines are enough on SPARC at -O2:
extern void foo (long double);
void bar (long double d)
{
foo (d);
}
[Bug middle-end/97078] [11 Regression] ICE in set_rtl building glibc tests with -ffloat-store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97078 Eric Botcazou changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-09-17 Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- Fixing.
[Bug middle-end/97078] [11 Regression] ICE in set_rtl building glibc tests with -ffloat-store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97078 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Eric Botcazou --- Thanks for reporting the problem.
[Bug bootstrap/96378] ICE: Solaris/SPARCv9 bootstrap stage2 segfault compiling stdc++.h.gch/O2ggnu++0x.gch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96378 Eric Botcazou changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-09-18 CC||ebotcazou at gcc dot gnu.org Status|UNCONFIRMED |WAITING --- Comment #1 from Eric Botcazou --- What does 'gcc -v' print exactly? It looks like you're trying to bootstrap a 64-bit compiler with a 32-bit toolchain.
[Bug tree-optimization/92131] [8/9/10 Regression] incorrect assumption that (ao >= 0) is always false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #18 from Eric Botcazou --- Investigating.
[Bug middle-end/92170] Incorrect function names output when using -fstack-usage on C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92170 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-22 Ever confirmed|0 |1 --- Comment #4 from Eric Botcazou --- > This appears to be caused by code in output_stack_usage in toplev.c > searching for "." in the function name and only outputting after that point. > It is unclear to me what the intent was originally, but it dates back to the > original stack usage support commit (990495a75cd7). It's intended to keep only the unqualified name, in particular for Ada. > I achieved the expected output shown above by applying the below patch to > disable the checks: OK, but this workaround is not acceptable of course.
[Bug middle-end/92170] Incorrect function names output when using -fstack-usage on C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92170 --- Comment #6 from Eric Botcazou --- > I wasn't sure what the purpose of splitting at "." was (in particular since > I think of GCC as a C/C++ compiler and the "." would not normally appear in > qualified names as a separator). Yet there is a comment just above the code. > With the context that this is something specific for Ada, I think maybe the > correct thing to do would be to make this filtering a language hook that can > be customized to do the right thing for each language. This sounds a bit overkill, we can probably print the fully qualified name.
[Bug tree-optimization/92131] [8/9/10 Regression] incorrect assumption that (ao >= 0) is always false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131 --- Comment #19 from Eric Botcazou --- Created attachment 47084 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47084&action=edit Tentative fix
[Bug tree-optimization/92131] [8/9/10 Regression] incorrect assumption that (ao >= 0) is always false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131 --- Comment #20 from Eric Botcazou --- Author: ebotcazou Date: Wed Oct 23 11:34:48 2019 New Revision: 277314 URL: https://gcc.gnu.org/viewcvs?rev=277314&root=gcc&view=rev Log: PR tree-optimization/92131 * tree-vrp.c (extract_range_from_plus_minus_expr): If the resulting range would be symbolic, drop to varying for any explicit overflow in the constant part or if neither range is a singleton. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20191023-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/92131] [8/9/10 Regression] incorrect assumption that (ao >= 0) is always false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131 --- Comment #21 from Eric Botcazou --- Author: ebotcazou Date: Wed Oct 23 11:37:28 2019 New Revision: 277315 URL: https://gcc.gnu.org/viewcvs?rev=277315&root=gcc&view=rev Log: PR tree-optimization/92131 * tree-vrp.c (extract_range_from_plus_minus_expr): If the resulting range would be symbolic, drop to varying for any explicit overflow in the constant part or if neither range is a singleton. Added: branches/gcc-9-branch/gcc/testsuite/gcc.c-torture/execute/20191023-1.c - copied unchanged from r277314, trunk/gcc/testsuite/gcc.c-torture/execute/20191023-1.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/tree-vrp.c
[Bug tree-optimization/92131] [8/9/10 Regression] incorrect assumption that (ao >= 0) is always false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131 --- Comment #22 from Eric Botcazou --- Author: ebotcazou Date: Wed Oct 23 11:38:41 2019 New Revision: 277316 URL: https://gcc.gnu.org/viewcvs?rev=277316&root=gcc&view=rev Log: PR tree-optimization/92131 * tree-vrp.c (extract_range_from_plus_minus_expr): If the resulting range would be symbolic, drop to varying for any explicit overflow in the constant part or if neither range is a singleton. Added: branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/execute/20191023-1.c - copied unchanged from r277314, trunk/gcc/testsuite/gcc.c-torture/execute/20191023-1.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-vrp.c
[Bug tree-optimization/92131] [8/9/10 Regression] incorrect assumption that (ao >= 0) is always false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Version|9.1.0 |8.3.0 Resolution|--- |FIXED --- Comment #24 from Eric Botcazou --- Thanks for reporting the problem.
[Bug tree-optimization/92131] [8/9/10 Regression] incorrect assumption that (ao >= 0) is always false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131 --- Comment #23 from Eric Botcazou --- Author: ebotcazou Date: Wed Oct 23 13:17:34 2019 New Revision: 277331 URL: https://gcc.gnu.org/viewcvs?rev=277331&root=gcc&view=rev Log: PR tree-optimization/92131 * tree-vrp.c (extract_range_from_plus_minus_expr): If the resulting range would be symbolic, drop to varying for any explicit overflow in the constant part or if neither range is a singleton. Added: branches/gcc-7-branch/gcc/testsuite/gcc.c-torture/execute/20191023-1.c - copied unchanged from r277330, trunk/gcc/testsuite/gcc.c-torture/execute/20191023-1.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/tree-vrp.c
[Bug target/92227] Optimizations on constant integer overflow checks lead to incorrect results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92227 Eric Botcazou changed: What|Removed |Added Status|WAITING |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Eric Botcazou --- Right, there is no requirement on the implementation of __builtin_sadd_overflow, it just needs to produce correct results.
[Bug rtl-optimization/92095] ICE on sparc-gcc -O1 -mcpu=niagara2 -fPIE: validize_mem(rtx_def*): gcc/gcc/explow.c:521
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92095 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-27 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Eric Botcazou --- I can reproduce.
[Bug rtl-optimization/92095] ICE on sparc-gcc -O1 -mcpu=niagara2 -fPIE: validize_mem(rtx_def*): gcc/gcc/explow.c:521
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92095 Eric Botcazou changed: What|Removed |Added CC|ebotcazou at gcc dot gnu.org, | |ebotcazou at libertysurf dot fr| Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #4 from Eric Botcazou --- Investigating.
[Bug middle-end/92170] Incorrect function names output when using -fstack-usage on C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92170 --- Comment #9 from Eric Botcazou --- > Is there a reason why -fstack-usage doesn't output mangled name ? Yes, the output was supposed to be human-readable, that's why the location of the function is also output. > Wouldn't it better if it was consistent with other tools and as such could > be compared ? This would break backward compatibility though. > The patch is very simple, just bypass any demangling here since I don't > think it's the role of this method to demangle for you. Probably worth discussing so please post it on gcc-patches@
[Bug target/92302] [10 regression] gcc.target/sparc/sparc-ret-3.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92302 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-31 Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Then change looks benign and I'm skeptical about the purported cause.
[Bug target/92303] [10 regression] gcc.target/sparc/ultrasp12.c times out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92303 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-31 Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- In my experience, LRA is getting slower and slower since GCC 8.
[Bug rtl-optimization/92095] [8/9/10 regression] internal error with -O1 -mcpu=niagara2 -fPIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92095 Eric Botcazou changed: What|Removed |Added Target Milestone|--- |8.4 Summary|ICE on sparc-gcc -O1|[8/9/10 regression] |-mcpu=niagara2 -fPIE: |internal error with -O1 |validize_mem(rtx_def*): |-mcpu=niagara2 -fPIE |gcc/gcc/explow.c:521|
[Bug testsuite/92302] [10 regression] gcc.target/sparc/sparc-ret-3.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92302 Eric Botcazou changed: What|Removed |Added Component|target |testsuite --- Comment #2 from Eric Botcazou --- Recategorizing.
[Bug testsuite/92302] [10 regression] gcc.target/sparc/sparc-ret-3.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92302 --- Comment #3 from Eric Botcazou --- Author: ebotcazou Date: Mon Nov 4 18:30:23 2019 New Revision: 277787 URL: https://gcc.gnu.org/viewcvs?rev=277787&root=gcc&view=rev Log: PR testsuite/92302 * gcc.target/sparc/sparc-ret-3.c: Accept more registers in address. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/sparc/sparc-ret-3.c
[Bug testsuite/92302] [10 regression] gcc.target/sparc/sparc-ret-3.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92302 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Eric Botcazou --- .
[Bug ada/92362] [9/10 regression] double elaboration of expression with Address aspect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92362 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-07 CC||ebotcazou at gcc dot gnu.org Target Milestone|--- |9.3 Summary|Compiler generates 2|[9/10 regression] double |function calls in a 'with |elaboration of expression |Address' aspect |with Address aspect |specification that uses a | |function| Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Really stupid mistake.
[Bug ada/92362] [9/10 regression] double elaboration of expression with Address aspect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92362 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED CC|ebotcazou at gcc dot gnu.org | Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- Fixing.
[Bug c/92088] aggregates with VLAs and nested functions are broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92088 --- Comment #9 from Eric Botcazou --- > I don't think the inliner should work around this - this hasn't been > necessary for Ada which is a good sign here. Eric - how does GiGi handle > this > case? VLAs are always passed by reference in Ada.
[Bug c/92088] aggregates with VLAs and nested functions are broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92088 --- Comment #10 from Eric Botcazou --- > VLAs are always passed by reference in Ada. And, more generally, any type with variable size is too.
[Bug target/92095] [8/9/10 regression] internal error with -O1 -mcpu=niagara2 -fPIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92095 --- Comment #5 from Eric Botcazou --- Author: ebotcazou Date: Fri Nov 8 12:30:47 2019 New Revision: 277966 URL: https://gcc.gnu.org/viewcvs?rev=277966&root=gcc&view=rev Log: PR target/92095 * config/sparc/sparc-protos.h (output_load_pcrel_sym): Declare. * config/sparc/sparc.c (sparc_cannot_force_const_mem): Revert latest change. (got_helper_needed): New static variable. (output_load_pcrel_sym): New function. (get_pc_thunk_name): Remove after inlining... (load_got_register): ...here. Rework the initialization of the GOT register and of the GOT helper. (save_local_or_in_reg_p): Test the REGNO of the GOT register. (sparc_file_end): Test got_helper_needed to decide whether the GOT helper must be emitted. Use output_asm_insn instead of fprintf. (sparc_init_pic_reg): In PIC mode, always initialize the PIC register if optimization is enabled. * config/sparc/sparc.md (load_pcrel_sym): Emit the assembly by calling output_load_pcrel_sym. Added: trunk/gcc/testsuite/gcc.c-torture/compile/20191108-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc-protos.h trunk/gcc/config/sparc/sparc.c trunk/gcc/config/sparc/sparc.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/sparc/overflow-3.c trunk/gcc/testsuite/gcc.target/sparc/overflow-4.c trunk/gcc/testsuite/gcc.target/sparc/overflow-5.c
[Bug target/92095] [8/9/10 regression] internal error with -O1 -mcpu=niagara2 -fPIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92095 --- Comment #6 from Eric Botcazou --- Author: ebotcazou Date: Fri Nov 8 12:33:48 2019 New Revision: 277967 URL: https://gcc.gnu.org/viewcvs?rev=277967&root=gcc&view=rev Log: PR target/92095 * config/sparc/sparc-protos.h (output_load_pcrel_sym): Declare. * config/sparc/sparc.c (sparc_cannot_force_const_mem): Revert latest change. (got_helper_needed): New static variable. (output_load_pcrel_sym): New function. (get_pc_thunk_name): Remove after inlining... (load_got_register): ...here. Rework the initialization of the GOT register and of the GOT helper. (save_local_or_in_reg_p): Test the REGNO of the GOT register. (sparc_file_end): Test got_helper_needed to decide whether the GOT helper must be emitted. Use output_asm_insn instead of fprintf. (sparc_init_pic_reg): In PIC mode, always initialize the PIC register if optimization is enabled. * config/sparc/sparc.md (load_pcrel_sym): Emit the assembly by calling output_load_pcrel_sym. Added: branches/gcc-9-branch/gcc/testsuite/gcc.c-torture/compile/20191108-1.c - copied unchanged from r277966, trunk/gcc/testsuite/gcc.c-torture/compile/20191108-1.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/sparc/sparc-protos.h branches/gcc-9-branch/gcc/config/sparc/sparc.c branches/gcc-9-branch/gcc/config/sparc/sparc.md branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/testsuite/gcc.target/sparc/overflow-3.c branches/gcc-9-branch/gcc/testsuite/gcc.target/sparc/overflow-4.c branches/gcc-9-branch/gcc/testsuite/gcc.target/sparc/overflow-5.c
[Bug target/92095] [8/9/10 regression] internal error with -O1 -mcpu=niagara2 -fPIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92095 --- Comment #7 from Eric Botcazou --- Author: ebotcazou Date: Fri Nov 8 12:38:03 2019 New Revision: 277968 URL: https://gcc.gnu.org/viewcvs?rev=277968&root=gcc&view=rev Log: PR target/92095 * config/sparc/sparc-protos.h (output_load_pcrel_sym): Declare. * config/sparc/sparc.c (sparc_cannot_force_const_mem): Revert latest change. (got_helper_needed): New static variable. (output_load_pcrel_sym): New function. (get_pc_thunk_name): Remove after inlining... (load_got_register): ...here. Rework the initialization of the GOT register and of the GOT helper. (save_local_or_in_reg_p): Test the REGNO of the GOT register. (sparc_file_end): Test got_helper_needed to decide whether the GOT helper must be emitted. Use output_asm_insn instead of fprintf. (sparc_init_pic_reg): In PIC mode, always initialize the PIC register if optimization is enabled. * config/sparc/sparc.md (load_pcrel_sym): Emit the assembly by calling output_load_pcrel_sym. Added: branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/compile/20191108-1.c - copied unchanged from r277967, trunk/gcc/testsuite/gcc.c-torture/compile/20191108-1.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/sparc/sparc-protos.h branches/gcc-8-branch/gcc/config/sparc/sparc.c branches/gcc-8-branch/gcc/config/sparc/sparc.md branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gcc.target/sparc/overflow-3.c branches/gcc-8-branch/gcc/testsuite/gcc.target/sparc/overflow-4.c branches/gcc-8-branch/gcc/testsuite/gcc.target/sparc/overflow-5.c
[Bug target/92095] [8/9/10 regression] internal error with -O1 -mcpu=niagara2 -fPIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92095 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Eric Botcazou --- This should compile again.
[Bug ada/92489] [9 regression] internal error on Invalid_Value Attribute attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92489 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-18 CC||ebotcazou at gcc dot gnu.org Known to work||10.0, 8.3.0 Target Milestone|--- |9.3 Summary|GNAT Bug for Invalid_Value |[9 regression] internal |Attribute |error on Invalid_Value ||Attribute attribute Ever confirmed|0 |1 Known to fail||9.2.0 --- Comment #2 from Eric Botcazou --- Present on the 9 branch only.
[Bug ada/92489] [9 regression] internal error on Invalid_Value Attribute attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92489 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou --- Investigating.
[Bug ada/92575] couple of suspicious assignments in expect.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92575 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-21 CC||ebotcazou at gcc dot gnu.org Summary|trunk/gcc/ada/expect.c: 2 * |couple of suspicious |suspicious assignments ?|assignments in expect.c Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Ugh.
[Bug ada/92575] couple of suspicious assignments in expect.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92575 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org
[Bug ada/92575] couple of suspicious assignments in expect.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92575 --- Comment #2 from Eric Botcazou --- Author: ebotcazou Date: Mon Nov 25 10:29:51 2019 New Revision: 278671 URL: https://gcc.gnu.org/viewcvs?rev=278671&root=gcc&view=rev Log: PR ada/92575 * expect.c (__gnat_expect_poll [VMS, HPUX]): Fix typo. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/expect.c
