[Bug tree-optimization/103288] [12 Regression] ice during GIMPLE pass: phiopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103288 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-Novembe ||r/584675.html --- Comment #11 from Andrew Pinski --- Patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584675.html
[Bug middle-end/103163] [12 Regression] stack_limit_rtx is created too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103163 Andrew Pinski changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- *** Bug 101157 has been marked as a duplicate of this bug. ***
[Bug middle-end/101157] [12 regression] ICE compiling gcc.target/powerpc/stack-limit.c after r12-1702
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101157 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Andrew Pinski --- The reason for the failure is described in PR 103163 so closing as a dup. *** This bug has been marked as a duplicate of bug 103163 ***
[Bug middle-end/103163] [12 Regression] stack_limit_rtx is created too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103163 Andrew Pinski changed: What|Removed |Added Summary|stack_limit_rtx is created |[12 Regression] |too early |stack_limit_rtx is created ||too early Target Milestone|--- |12.0 Ever confirmed|0 |1 Last reconfirmed||2021-11-17 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > Looks like the powerpc folks did report PR 101157 (right after > r12-1702-g7232f7c4c2d727431096a) which was the failure of > gcc.target/powerpc/pr48344-1.c but they reported it was fixed not far after > the failure ... But still fails: https://gcc.gnu.org/pipermail/gcc-testresults/2021-November/735755.html The ICE is new on the trunk though.
[Bug middle-end/101157] [12 regression] ICE compiling gcc.target/powerpc/stack-limit.c after r12-1702
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101157 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|RESOLVED|NEW Resolution|WORKSFORME |--- Last reconfirmed||2021-11-17 --- Comment #8 from Andrew Pinski --- Actually it still fails: https://gcc.gnu.org/pipermail/gcc-testresults/2021-November/735755.html
[Bug middle-end/103163] stack_limit_rtx is created too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103163 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=48344, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=101157 --- Comment #1 from Andrew Pinski --- Hmm, looks like it has been a bug for a long time really. r6-6965-gecf835e90129 (PR48344) improved the situtation slightly. Looks like the powerpc folks did report PR 101157 (right after r12-1702-g7232f7c4c2d727431096a) which was the failure of gcc.target/powerpc/pr48344-1.c but they reported it was fixed not far after the failure ...
[Bug ipa/103171] [12 Regression] ICE Segmentation fault since r12-2523-g13586172d0b70c9d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103171 Andrew Pinski changed: What|Removed |Added Severity|normal |critical
[Bug target/103275] [11/12 Regression] don't generate kmov with IE model relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103275 --- Comment #9 from Jakub Jelinek --- Just those particular TLS UNSPECs. And, e.g. UNSPEC_NTPOFF should be fine in any insn that takes memory operands...
[Bug ipa/101941] [12 Regression] Linux kernel build failure due to retaining fnsplit fragment with __attribute__((__error__))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101941 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-Novembe ||r/584673.html --- Comment #24 from Andrew Pinski --- Patch sent https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584673.html .
[Bug c++/103273] [9/10/11/12 Regression] internal compiler error: in cp_parser_type_id_1, at cp/parser.c:24010
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103273 Andrew Pinski changed: What|Removed |Added Severity|normal |minor Known to work|10.3.1 |
[Bug libgomp/103276] [openacc] Trying to map already mapped data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103276
--- Comment #3 from Andrew Pinski ---
(In reply to Yuri Gribov from comment #0)
> Here hostaddrs[1] points to a spurious variable in current stack frame.
>
> Gimple code seems to be correct
> voidD.27 copyin_simple (struct simple & restrict varD.3961)
> {
> struct .omp_data_t.1D.3962 D.3965;
> ...
> # .MEM_4 = VDEF <.MEM_3>
> D.3965.varD.3964 = &varD.3961;
No the gimple is wrong. &var is taking the address of the argument. It should
just be var here if you what the reference points to rather than the address of
the decl holding the pointer.
[Bug ipa/103277] [12 Regression] ICE in branch_prob with -O1 -fbranch-probabilities -fno-ipa-pure-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103277 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-11-17 Summary|[12 Regression] ICE in |[12 Regression] ICE in |branch_prob, at |branch_prob with -O1 |profile.c:1208 |-fbranch-probabilities ||-fno-ipa-pure-const Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. DSE is able to remove the function as it does not have any side effects even though it has returns twice but : .ABNORMAL_DISPATCHER (0); is still there. -fno-ipa-pure-const is required because it will cause an override of the returns_twice attribute.
[Bug ipa/103277] [12 Regression] ICE in branch_prob, at profile.c:1208
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103277 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug tree-optimization/98956] Failure to optimize out boolean left shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98956 Navid Rahimi changed: What|Removed |Added CC||navidrahimi at microsoft dot com --- Comment #3 from Navid Rahimi --- I am sending a patch for this: /* cmp : ==, != */ /* ((B0 << CST) cmp 0) -> B0 cmp 0 */ (for cmp (eq ne) (simplify (cmp (lshift (convert @0) INTEGER_CST@1) integer_zerop@2) (if (TREE_CODE (TREE_TYPE (@0)) == BOOLEAN_TYPE) (cmp @0 @2 This does not apply to other arithmetic operations (at least it is not verifiable). and for cases that it does apply to other arithmetic operators, GCC already produces optimized code. You can play with the codegen I link below: Codegen: https://compiler-explorer.com/z/nj4PTrecW Proof: https://alive2.llvm.org/ce/z/jyJAoS
[Bug tree-optimization/86136] Modular multiplication optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86136 Navid Rahimi changed: What|Removed |Added CC||navidrahimi at microsoft dot com --- Comment #4 from Navid Rahimi --- We can close this bug. Transformation doesn't verify! Codegen: https://compiler-explorer.com/z/Waoz4qaz6 Proof: https://alive2.llvm.org/ce/z/5H9ahK
[Bug c++/103297] New: GCC cannot detect out of bounds in constexpr context.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103297
Bug ID: 103297
Summary: GCC cannot detect out of bounds in constexpr context.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: unlvsur at live dot com
Target Milestone: ---
inline constexpr void out_of_bounds_detector(char const*,char const*) noexcept
{}
inline constexpr bool test() noexcept
{
char buffer[]="abcde";
out_of_bounds_detector(buffer,buffer+7);//should give a hard error
return true;
}
static_assert(test());
while clang and msvc can all detect this correctly.
[Bug ipa/101941] [12 Regression] Linux kernel build failure due to retaining fnsplit fragment with __attribute__((__error__))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101941 Andrew Pinski changed: What|Removed |Added Attachment #51805|0 |1 is obsolete|| --- Comment #23 from Andrew Pinski --- Created attachment 51822 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51822&action=edit Full patch which I will bootstrap/test This is the full patch and includes two testcases. They both fail before the patch and still pass after the patch. Since the testcase that checks we still do the split is there too.
[Bug target/103275] [11/12 Regression] don't generate kmov with IE model relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103275 --- Comment #8 from H.J. Lu --- (In reply to Hongtao.liu from comment #7) > vmovd have same issue, for simplify should we disable 32bit load for > sse/mask register when memory_operand has PIC address. Please disable specific UNSPEC operands with mask register disallowed in this assembler change: https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=d7e3e627027fcf37d63e284144fe27ff4eba36b5
[Bug c++/87403] [Meta-bug] Issues that suggest a new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Bug 87403 depends on bug 103026, which changed state. Bug 103026 Summary: Implement warning for Unicode bidi override characters [CVE-2021-42574] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103026 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug preprocessor/103026] Implement warning for Unicode bidi override characters [CVE-2021-42574]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103026 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Marek Polacek --- Added to GCC 12.
[Bug preprocessor/103026] Implement warning for Unicode bidi override characters [CVE-2021-42574]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103026 --- Comment #4 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:51c500269bf53749b107807d84271385fad35628 commit r12-5331-g51c500269bf53749b107807d84271385fad35628 Author: Marek Polacek Date: Wed Oct 6 14:33:59 2021 -0400 libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026] From a link below: "An issue was discovered in the Bidirectional Algorithm in the Unicode Specification through 14.0. It permits the visual reordering of characters via control sequences, which can be used to craft source code that renders different logic than the logical ordering of tokens ingested by compilers and interpreters. Adversaries can leverage this to encode source code for compilers accepting Unicode such that targeted vulnerabilities are introduced invisibly to human reviewers." More info: https://nvd.nist.gov/vuln/detail/CVE-2021-42574 https://trojansource.codes/ This is not a compiler bug. However, to mitigate the problem, this patch implements -Wbidi-chars=[none|unpaired|any] to warn about possibly misleading Unicode bidirectional control characters the preprocessor may encounter. The default is =unpaired, which warns about improperly terminated bidirectional control characters; e.g. a LRE without its corresponding PDF. The level =any warns about any use of bidirectional control characters. This patch handles both UCNs and UTF-8 characters. UCNs designating bidi characters in identifiers are accepted since r204886. Then r217144 enabled -fextended-identifiers by default. Extended characters in C/C++ identifiers have been accepted since r275979. However, this patch still warns about mixing UTF-8 and UCN bidi characters; there seems to be no good reason to allow mixing them. We warn in different contexts: comments (both C and C++-style), string literals, character constants, and identifiers. Expectedly, UCNs are ignored in comments and raw string literals. The bidirectional control characters can nest so this patch handles that as well. I have not included nor tested this at all with Fortran (which also has string literals and line comments). Dave M. posted patches improving diagnostic involving Unicode characters. This patch does not make use of this new infrastructure yet. PR preprocessor/103026 gcc/c-family/ChangeLog: * c.opt (Wbidi-chars, Wbidi-chars=): New option. gcc/ChangeLog: * doc/invoke.texi: Document -Wbidi-chars. libcpp/ChangeLog: * include/cpplib.h (enum cpp_bidirectional_level): New. (struct cpp_options): Add cpp_warn_bidirectional. (enum cpp_warning_reason): Add CPP_W_BIDIRECTIONAL. * internal.h (struct cpp_reader): Add warn_bidi_p member function. * init.c (cpp_create_reader): Set cpp_warn_bidirectional. * lex.c (bidi): New namespace. (get_bidi_utf8): New function. (get_bidi_ucn): Likewise. (maybe_warn_bidi_on_close): Likewise. (maybe_warn_bidi_on_char): Likewise. (_cpp_skip_block_comment): Implement warning about bidirectional control characters. (skip_line_comment): Likewise. (forms_identifier_p): Likewise. (lex_identifier): Likewise. (lex_string): Likewise. (lex_raw_string): Likewise. gcc/testsuite/ChangeLog: * c-c++-common/Wbidi-chars-1.c: New test. * c-c++-common/Wbidi-chars-2.c: New test. * c-c++-common/Wbidi-chars-3.c: New test. * c-c++-common/Wbidi-chars-4.c: New test. * c-c++-common/Wbidi-chars-5.c: New test. * c-c++-common/Wbidi-chars-6.c: New test. * c-c++-common/Wbidi-chars-7.c: New test. * c-c++-common/Wbidi-chars-8.c: New test. * c-c++-common/Wbidi-chars-9.c: New test. * c-c++-common/Wbidi-chars-10.c: New test. * c-c++-common/Wbidi-chars-11.c: New test. * c-c++-common/Wbidi-chars-12.c: New test. * c-c++-common/Wbidi-chars-13.c: New test. * c-c++-common/Wbidi-chars-14.c: New test. * c-c++-common/Wbidi-chars-15.c: New test. * c-c++-common/Wbidi-chars-16.c: New test. * c-c++-common/Wbidi-chars-17.c: New test.
[Bug target/103275] [11/12 Regression] don't generate kmov with IE model relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103275 --- Comment #7 from Hongtao.liu --- vmovd have same issue, for simplify should we disable 32bit load for sse/mask register when memory_operand has PIC address.
[Bug rtl-optimization/103296] Select satisfied register for deleting noop move instruction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103296 --- Comment #1 from jojo --- My patch here: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584589.html
[Bug rtl-optimization/103296] New: Select satisfied register for deleting noop move instruction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103296
Bug ID: 103296
Summary: Select satisfied register for deleting noop move
instruction.
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rjiejie at me dot com
Target Milestone: ---
I found this case in my riscv vector test case, and following is snippets of
problematic RTL:
before register renamer :
=
(insn 64 62 109 4 (parallel [
(set (reg:VNx32HI 104 v8 [orig:148 _30 ] [148])
(unspec:VNx32HI [
(plus:VNx32HI (reg:VNx32HI 100 v4 [orig:149 _31 ]
[149])
(zero_extend:VNx32HI (reg:VNx32QI 108 v12 [orig:159
_41 ] [159])))
(reg:SI 66 vl)
] UNSPEC_USEVL))
(use (reg:VNx32QI 67 vtype))
])
"/$GCC/lib/gcc/riscv64-unknown-linux-gnu/10.2.0/include/riscv_vector.h":1865:1
23384 {*wadduvnx32qi_wv_nosetvl}
(nil))
(insn 109 64 67 4 (set (reg:VNx32HI 100 v4 [orig:147 _29 ] [147])
(reg:VNx32HI 104 v8 [orig:148 _30 ] [148]))
"/$GCC/lib/gcc/riscv64-unknown-linux-gnu/10.2.0/include/riscv_vector.h":2815:1
21247 {*movvnx32hi}
(nil))
(insn 67 109 69 4 (parallel [
(set (reg:VNx32HI 100 v4 [orig:147 _29 ] [147])
(unspec:VNx32HI [
(plus:VNx32HI (mult:VNx32HI (zero_extend:VNx32HI
(vec_duplicate:VNx32QI (reg:QI 10 a0 [184])))
(zero_extend:VNx32HI (reg:VNx32QI 98 v2
[orig:152 _34 ] [152])))
(reg:VNx32HI 100 v4 [orig:147 _29 ] [147]))
(reg:SI 66 vl)
] UNSPEC_USEVL))
(use (reg:VNx32QI 67 vtype))
])
"/$GCC/lib/gcc/riscv64-unknown-linux-gnu/10.2.0/include/riscv_vector.h":2815:1
27941 {*umaddvnx32qivnx32hi4_scalar_nosetvl}
(expr_list:REG_EQUAL (unspec:VNx32HI [
(plus:VNx32HI (mult:VNx32HI (zero_extend:VNx32HI (reg:VNx32QI
98 v2 [orig:152 _34 ] [152]))
(const_vector:VNx32HI [
(const_int 2 [0x2])
]))
(reg:VNx32HI 104 v8 [orig:148 _30 ] [148]))
(reg:SI 66 vl)
] UNSPEC_USEVL)
(nil)))
after register renamer :
(insn 64 62 109 4 (parallel [
(set (reg:VNx32HI 100 v4 [orig:148 _30 ] [148])
(unspec:VNx32HI [
(plus:VNx32HI (reg:VNx32HI 116 v20 [orig:149 _31 ]
[149])
(zero_extend:VNx32HI (reg:VNx32QI 108 v12 [orig:159
_41 ] [159])))
(reg:SI 66 vl)
] UNSPEC_USEVL))
(use (reg:VNx32QI 67 vtype))
])
"/$GCC/lib/gcc/riscv64-unknown-linux-gnu/10.2.0/include/riscv_vector.h":1865:1
23384 {*wadduvnx32qi_wv_nosetvl}
(expr_list:REG_DEAD (reg:VNx32QI 108 v12 [orig:159 _41 ] [159])
(expr_list:REG_DEAD (reg:VNx32HI 100 v4 [orig:149 _31 ] [149])
(nil
(insn:TI 109 64 67 4 (set (reg:VNx32HI 124 v28 [orig:147 _29 ] [147])
(reg:VNx32HI 100 v4 [orig:148 _30 ] [148]))
"/$GCC/lib/gcc/riscv64-unknown-linux-gnu/10.2.0/include/riscv_vector.h":2815:1
21247 {*movvnx32hi}
(expr_list:REG_DEAD (reg:VNx32HI 104 v8 [orig:148 _30 ] [148])
(nil)))
(insn 67 109 69 4 (parallel [
(set (reg:VNx32HI 124 v28 [orig:147 _29 ] [147])
(unspec:VNx32HI [
(plus:VNx32HI (mult:VNx32HI (zero_extend:VNx32HI
(vec_duplicate:VNx32QI (reg:QI 10 a0 [184])))
(zero_extend:VNx32HI (reg:VNx32QI 114 v18
[orig:152 _34 ] [152])))
(reg:VNx32HI 124 v28 [orig:147 _29 ] [147]))
(reg:SI 66 vl)
] UNSPEC_USEVL))
(use (reg:VNx32QI 67 vtype))
])
"/$GCC/lib/gcc/riscv64-unknown-linux-gnu/10.2.0/include/riscv_vector.h":2815:1
27941 {*umaddvnx32qivnx32hi4_scalar_nosetvl}
(expr_list:REG_DEAD (reg:VNx32HI 104 v8 [orig:148 _30 ] [148])
(expr_list:REG_DEAD (reg:VNx32QI 98 v2 [orig:152 _34 ] [152])
(expr_list:REG_DEAD (reg:VNx32QI 98 v2 [orig:152 _34 ] [152])
(expr_list:REG_EQUAL (unspec:VNx32HI [
(plus:VNx32HI (mult:VNx32HI (zero_extend:VNx32HI
(reg:VNx32QI 98 v2 [orig:152 _34 ] [152]))
(const_vector:VNx32HI [
(const_int 2 [0x2])
]))
(reg:VNx32HI 104 v8 [orig:148 _30 ] [148]))
(reg:SI 66 vl)
] UNSPEC_USEVL)
(nil))
>From rnreg pass RTL dump as following
[Bug analyzer/102695] missing -Wanalyzer-write-to-const for writing to string, function, label, or const member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102695 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- The above patch implements detection for all of the cases in comment #0 apart from write_const_member; I don't plan to implement detection of that, so marking this as resolved.
[Bug analyzer/102779] gcc.dg/analyzer/capacity-1.c etc.FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102779 David Malcolm changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #3 from David Malcolm --- Did the above patch fix the issue for you?
[Bug analyzer/102695] missing -Wanalyzer-write-to-const for writing to string, function, label, or const member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102695 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:111fd515f2894d7cddf62f80c69765c43ae18577 commit r12-5330-g111fd515f2894d7cddf62f80c69765c43ae18577 Author: David Malcolm Date: Tue Nov 16 10:36:49 2021 -0500 analyzer: fix missing -Wanalyzer-write-to-const [PR102695] This patch fixes -Wanalyzer-write-to-const so that it will complain about attempts to write to functions, to labels. It also "teaches" the analyzer about strchr, in that strchr can either return a pointer into the input area (and thus -Wanalyzer-write-to-const can now complain about writes into a string literal seen this way), or return NULL (and thus the analyzer can complain about NULL dereferences if the result is used without a check). gcc/analyzer/ChangeLog: PR analyzer/102695 * region-model-impl-calls.cc (region_model::impl_call_strchr): New. * region-model-manager.cc (region_model_manager::maybe_fold_unaryop): Simplify cast to pointer type of an existing pointer to a region. * region-model.cc (region_model::on_call_pre): Handle BUILT_IN_STRCHR and "strchr". (write_to_const_diagnostic::emit): Add auto_diagnostic_group. Add alternate wordings for functions and labels. (write_to_const_diagnostic::describe_final_event): Add alternate wordings for functions and labels. (region_model::check_for_writable_region): Handle RK_FUNCTION and RK_LABEL. * region-model.h (region_model::impl_call_strchr): New decl. gcc/testsuite/ChangeLog: PR analyzer/102695 * gcc.dg/analyzer/pr102695.c: New test. * gcc.dg/analyzer/strchr-1.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/102779] gcc.dg/analyzer/capacity-1.c etc.FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102779 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:a80d4e098b10d5cd161f55e4fce64a6be9683ed3 commit r12-5329-ga80d4e098b10d5cd161f55e4fce64a6be9683ed3 Author: David Malcolm Date: Mon Nov 15 18:23:08 2021 -0500 analyzer: don't assume target has alloca [PR102779] gcc/testsuite/ChangeLog: PR analyzer/102779 * gcc.dg/analyzer/capacity-1.c: Add dg-require-effective-target alloca. Use __builtin_alloca rather than alloca. * gcc.dg/analyzer/capacity-3.c: Likewise. Signed-off-by: David Malcolm
[Bug testsuite/103270] [12 regression] gcc.dg/vect/pr96698.c inner loop turned from hot to cold after r12-4526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103270
--- Comment #2 from luoxhu at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> So you say this is a problem with loop header copying, that would mean the
> issue is really latent and general, no? Header copying uses
> gimple_duplicate_sese_region and has no own profile updating. I guess its
> profile updating code isn't designed to cope with copying a region with
> "side"-entries (we are ignoring the backedge here). Not sure if we can
> somehow generally handle those (maybe we can learn from tracer or threader
> here).
>
> Honza?
Yes, it seems to be a general issue in gimple_duplicate_sese_region, the inner
loop cfg was:
8
|
3<--
| \ |
5 4
And it is modified by ch_base::copy_headers->gimple_duplicate_sese_region to(
entry edge is 8->3, exit edge is 3->4):
8
|
12
|
4<--
| |
3---
|
5
bb 12 is copied block from bb 3 as new preheader, bb 3 is rotated to be new
exit of the loop, bb 3 and bb 12 are adjusted count to "total_count -
entry_count" (354334800) and "entry_count"(719407024), at last bb 3 and bb 4
will be merged to one block by gimple_merge_blocks later by TODO_cleanup_cfg
with much smaller
count than preheader.
gimple_duplicate_sese_region:
if (total_count.initialized_p () && entry_count.initialized_p ())
{
scale_bbs_frequencies_profile_count (region, n_region,
total_count - entry_count,
total_count);
scale_bbs_frequencies_profile_count (region_copy, n_region, entry_count,
total_count);
}
Obviously, region of bb 3's profile count shouldn't be decreased from
"total_count" to "total_count - entry_count", it executes at every execution of
the loop. Simply adjust it back to total_count and region_copy to entry_count
will cause some other cases fail. And at the moment edge 3->4 is still not a
backedge now?
[Bug c/103292] [12 regression] xorg-server-1.20.13 -Werror=array-bounds false positive on unions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103292
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
Keywords||diagnostic
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=102151
CC||msebor at gcc dot gnu.org
--- Comment #1 from Martin Sebor ---
The warning is intended. The program allocates an object of a size that's
smaller than the size of the type used to access it:
pPicture->pSourcePict = (union _SourcePict*) malloc(sizeof(struct
_PictSolidFill));
pPicture->pSourcePict->type = 0;
It's not valid to access an object of one type using an lvalue of another. In
simple cases GCC diagnoses violations of this requirement by -Wstrict-aliasing.
-Warray-bounds doesn't detect aliasing violations but it does detect a subset
of the problem that's apparent when the size of the lvalue's type is greater
than the size of the object. The object must be big enough for the whole
lvalue, even if the accessed member is within the bounds of the smaller object.
The following is a smaller test case that should make the issue clearer. See
also pr102151 for a similar report.
$ cat a.c && gcc -O2 -S -Wall a.c
struct A { char a[1]; };
struct B { char a[2]; };
union U { struct A a; struct B b; };
void* f (void)
{
union U *p = __builtin_malloc (sizeof (struct A));
p->a.a[0] = 0;
return p;
}
a.c: In function ‘f’:
a.c:8:4: warning: array subscript ‘union U[0]’ is partly outside array bounds
of ‘unsigned char[1]’ [-Warray-bounds]
8 | p->a.a[0] = 0;
|^~
a.c:7:16: note: object of size 1 allocated by ‘__builtin_malloc’
7 | union U *p = __builtin_malloc (sizeof (struct A));
|^~~~
[Bug libstdc++/103295] constexpr std::string does not work for clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.0
[Bug libstdc++/103295] constexpr std::string does not work for clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-11-17 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #3) > This could be an unimplemented feature in clang with respect to C++23 by the > way. It's supposed to work in C++20, nothing from 23 should be needed.
[Bug libstdc++/103295] constexpr std::string does not work for clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295 --- Comment #5 from cqwrteur --- (In reply to Andrew Pinski from comment #3) > This could be an unimplemented feature in clang with respect to C++23 by the > way. The problem is that it has a silent undefined behavior in the code, the string does not give the union a storage, the lifetime of the sso buffer is not activated under constexpr context. (although a proposal is trying to fix that.)
[Bug ipa/101941] [12 Regression] Linux kernel build failure due to retaining fnsplit fragment with __attribute__((__error__))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101941
--- Comment #22 from Andrew Pinski ---
(In reply to Jan Hubicka from comment #21)
> Jakub: I see it is about error attributed call in the split out part of
> function. Then we really want to prevent the split. Keeping track of those
> should be possible in the recursive walk (where we keep track of SSA names
> used). Not sure how common it would be in practice though.
That is exactly what my patch does, we disallow splitting out the basic blocks
that lead to the basic block that contains a function call that has an
error/warning attribute on it.
Here is a testcase which shows that we still able to split out basic blocks
that would not lead into the function and all (and we did before my patch too):
struct crypto_aes_ctx {
char key_dec[128];
};
int rfc4106_set_hash_subkey_hash_subkey;
void __write_overflow(void)__attribute__((__error__("")));
void __write_overflow1(void);
void aes_encrypt(void*);
void fortify_panic(const char*) __attribute__((__noreturn__)) ;
char *rfc4106_set_hash_subkey(struct crypto_aes_ctx *ctx) {
void *a = &ctx->key_dec[0];
unsigned p_size = __builtin_object_size(a, 0);
if (p_size < 16) {
__write_overflow1();
fortify_panic(__func__);
}
if (p_size < 32) {
__write_overflow();
fortify_panic(__func__);
}
aes_encrypt(ctx);
return ctx->key_dec;
}
char *(*gg)(struct crypto_aes_ctx *) = rfc4106_set_hash_subkey;
void a(void)
{
struct crypto_aes_ctx ctx;
rfc4106_set_hash_subkey(&ctx);
}
void b(void)
{
struct crypto_aes_ctx ctx;
ctx.key_dec[0] = 0;
rfc4106_set_hash_subkey(&ctx);
}
[Bug libstdc++/103295] constexpr std::string does not work for clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295 --- Comment #4 from cqwrteur --- (In reply to Andrew Pinski from comment #3) > This could be an unimplemented feature in clang with respect to C++23 by the > way. Same code works with clang --target=x86_64-windows-msvc. D:\hg\fast_io\tests\0003.concat>clang++ -o constexpr_clang_msvcstl.exe constexpr.cc -Ofast -std=c++20 -s -flto -march=native -I../../include --target=x86_64-windows-msvc -fuse-ld=lld -D_DLL=1 -lmsvcrt
[Bug tree-optimization/102929] [missed optimization] two ways to rounddown-to-next-multiple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102929 Navid Rahimi changed: What|Removed |Added CC||navidrahimi at microsoft dot com --- Comment #2 from Navid Rahimi --- https://compiler-explorer.com/z/rMKnddh3G Seems the patch has been landed. We can close this bug.
[Bug libstdc++/103295] constexpr std::string does not work for clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295 --- Comment #3 from Andrew Pinski --- This could be an unimplemented feature in clang with respect to C++23 by the way.
[Bug libstdc++/103294] constexpr std::string does not work for clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103294
--- Comment #3 from cqwrteur ---
(In reply to Andrew Pinski from comment #1)
> GCC complains with -std=c++2b:
> : In function 'constexpr bool foo()':
> :7:33: error: call to non-'constexpr' function
> 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const
> _CharT*, const _Alloc&) [with =
> std::allocator; _CharT = char; _Traits = std::char_traits;
> _Alloc = std::allocator]'
> 7 | std::string str2{"abcwe"};
> | ^
> In file included from
> /opt/compiler-explorer/gcc-trunk-2026/include/c++/12.0.0/string:53,
> from :2:
> /opt/compiler-explorer/gcc-trunk-2026/include/c++/12.0.0/bits/
> basic_string.h:535:7: note: 'std::__cxx11::basic_string<_CharT, _Traits,
> _Alloc>::basic_string(const _CharT*, const _Alloc&) [with
> = std::allocator; _CharT = char; _Traits =
> std::char_traits; _Alloc = std::allocator]' declared here
> 535 | basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
> | ^~~~
> : At global scope:
> :11:18: error: non-constant condition for static assertion
>11 | static_assert(foo());
> | ~~~^~
> :11:18: error: 'constexpr bool foo()' called in a constant expression
> :5:16: note: 'constexpr bool foo()' declared here
> 5 | constexpr bool foo()
> |^~~
>
> Even libc++ fails to compile the code:
> :7:14: error: variable of non-literal type 'std::string' (aka
> 'basic_string, allocator>') cannot be defined
> in a constexpr function
> std::string str2{"abcwe"};
> ^
> /opt/compiler-explorer/clang-trunk-2026/bin/../include/c++/v1/string:679:
> 5: note: 'basic_string' is not literal because it is not an aggregate
> and has no constexpr constructors other than copy or move constructors
> basic_string
> ^
> 1 error generated.
Your gcc is old and needs update. This is a new feature added today. But it
does not work clang.
[Bug libstdc++/103295] constexpr std::string does not work for clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295 --- Comment #2 from cqwrteur --- *** Bug 103294 has been marked as a duplicate of this bug. ***
[Bug libstdc++/103294] constexpr std::string does not work for clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103294 cqwrteur changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from cqwrteur --- unintentional duplicated page. fixed *** This bug has been marked as a duplicate of bug 103295 ***
[Bug libstdc++/103294] constexpr std::string does not work for clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103294
--- Comment #1 from Andrew Pinski ---
GCC complains with -std=c++2b:
: In function 'constexpr bool foo()':
:7:33: error: call to non-'constexpr' function
'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const
_CharT*, const _Alloc&) [with = std::allocator;
_CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]'
7 | std::string str2{"abcwe"};
| ^
In file included from
/opt/compiler-explorer/gcc-trunk-2026/include/c++/12.0.0/string:53,
from :2:
/opt/compiler-explorer/gcc-trunk-2026/include/c++/12.0.0/bits/basic_string.h:535:7:
note: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const
_CharT*, const _Alloc&) [with = std::allocator;
_CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]' declared here
535 | basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
| ^~~~
: At global scope:
:11:18: error: non-constant condition for static assertion
11 | static_assert(foo());
| ~~~^~
:11:18: error: 'constexpr bool foo()' called in a constant expression
:5:16: note: 'constexpr bool foo()' declared here
5 | constexpr bool foo()
|^~~
Even libc++ fails to compile the code:
:7:14: error: variable of non-literal type 'std::string' (aka
'basic_string, allocator>') cannot be defined in
a constexpr function
std::string str2{"abcwe"};
^
/opt/compiler-explorer/clang-trunk-2026/bin/../include/c++/v1/string:679:5:
note: 'basic_string' is not literal because it is not an aggregate and
has no constexpr constructors other than copy or move constructors
basic_string
^
1 error generated.
[Bug ipa/103246] [12 Regression] 416.gamess miscompare with -O2 -g -flto=auto since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103246 --- Comment #12 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:8c693978dd64b16637577ebf50c760053d7d2165 commit r12-5328-g8c693978dd64b16637577ebf50c760053d7d2165 Author: Jan Hubicka Date: Wed Nov 17 01:43:57 2021 +0100 Fix clearing of to_info_lto in ipa_merge_modref_summary_after_inlining This patch fixes bug that caused some optimizations to be dropped with -fdump-ipa-inline. gcc/ChangeLog: 2021-11-17 Jan Hubicka PR ipa/103246 * ipa-modref.c (ipa_merge_modref_summary_after_inlining): Fix clearing of to_info_lto
[Bug c/101702] [12 Regression] ICE: in handle_argspec_attribute, at c-family/c-attribs.c:3623
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101702 --- Comment #5 from Martin Sebor --- (In reply to Jakub Jelinek from comment #4) > Martin clearly prefers some other fix, so I'll let him fix it himself. I think I just misread your change. It doesn't cause the problem I was concerned about. I've submitted a slightly enhanced version that avoids additional problems here: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584658.html
[Bug middle-end/103248] [12 Regression] ICE in operation_could_trap_helper_p, at tree-eh.c:2479
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103248 --- Comment #11 from joseph at codesourcery dot com --- Division by zero is undefined behavior for fixed-point types the same way as it is for integer types (but not floating point, at least when infinities and NaN are supported). Treating it like integer division in the compiler would seem reasonable.
[Bug libstdc++/103295] constexpr std::string does not work for clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295 cqwrteur changed: What|Removed |Added CC||unlvsur at live dot com --- Comment #1 from cqwrteur --- Created attachment 51821 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51821&action=edit clang error message
[Bug libstdc++/103295] New: constexpr std::string does not work for clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295
Bug ID: 103295
Summary: constexpr std::string does not work for clang
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: unlvsur at live dot com
Target Milestone: ---
#include
#include
constexpr bool foo()
{
std::string str2{"abcwe"};
return str2.size()==5;
}
static_assert(foo());
int main()
{
assert(foo());
}
[Bug libstdc++/103294] New: constexpr std::string does not work for clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103294
Bug ID: 103294
Summary: constexpr std::string does not work for clang
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: unlvsur at live dot com
Target Milestone: ---
Created attachment 51820
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51820&action=edit
error message from clang
#include
#include
constexpr bool foo()
{
std::string str2{"abcwe"};
return str2.size()==5;
}
static_assert(foo());
int main()
{
assert(foo());
}
[Bug tree-optimization/103288] [12 Regression] ice during GIMPLE pass: phiopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103288 --- Comment #10 from Andrew Pinski --- Created attachment 51819 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51819&action=edit Patch which is in testing Patch is now in full testing.
[Bug target/103275] [11/12 Regression] don't generate kmov with IE model relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103275 --- Comment #6 from Jason A. Donenfeld --- Working around this now downstream via https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=876602ee223c6c4225371b428a346f0b2d7f2020 which we'll revert whenever an upstream fix is available.
[Bug tree-optimization/103288] [12 Regression] ice during GIMPLE pass: phiopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103288 --- Comment #9 from Andrew Pinski --- (In reply to Andrew Pinski from comment #8) > I still need to test it a little bit. I get no failures in tree-ssa.exp. Running a full bootstrap/test.
[Bug tree-optimization/103288] [12 Regression] ice during GIMPLE pass: phiopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103288 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #8 from Andrew Pinski --- This fixes the problem: diff --git a/gcc/tree-ssa-phiopt.c b/gcc/tree-ssa-phiopt.c index 6b22f6bedd4..d96ca690d2f 100644 --- a/gcc/tree-ssa-phiopt.c +++ b/gcc/tree-ssa-phiopt.c @@ -1462,6 +1462,9 @@ value_replacement (basic_block cond_bb, basic_block middle_bb, prep_stmt[prep_cnt] = g; } + if (!single_pred_p (middle_bb)) +return 0; + /* Only transform if it removes the condition. */ if (!single_non_singleton_phi_for_edges (phi_nodes (gimple_bb (phi)), e0, e1)) return 0; I still need to test it a little bit.
[Bug tree-optimization/103278] [12 Regression] Recent change to cddce inhibits switch optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103278 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |12.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-11-16 --- Comment #2 from Andrew Pinski --- Confirmed. >;; Canonical GIMPLE case clusters: 9-10 12-13 32 48 I suspect there is some cost issue going on here. DCE is now able to combine empty bb's into one which causes iftoswitch to have a cost fit.
[Bug tree-optimization/103278] [12 Regression] Recent change to cddce inhibits switch optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103278 Andrew Pinski changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- *** Bug 103293 has been marked as a duplicate of this bug. ***
[Bug other/103293] [12 regression] gcc.dg/tree-ssa/if-to-switch-3.c fails after r12-5301
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103293 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 103278. *** This bug has been marked as a duplicate of bug 103278 ***
[Bug analyzer/103032] false positive diagnostic from -fanalyzer about double-free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103032 --- Comment #1 from David Malcolm --- I haven't yet reproduced the precise symptoms you reported, but FWIW I'm seeing this in got_gsd, which looks like a true warning for this code: | 1903 | psects[psectid] = strdup(name); | | | | | | | (43) this call could return NULL | 1904 | trim(psects[psectid++]); | | ~~~ | | | | | (44) calling ‘trim’ from ‘got_gsd’ | +--> ‘trim’: events 45-46 | | 1800 | void trim( | | ^~~~ | | | | | (45) entry to ‘trim’ |.. | 1805 | for (cp = buf + strlen(buf); cp > buf; cp--) | | ~~~ | | | | | (46) argument 1 (‘buf’) from (43) could be NULL where non-null expected | ../../src/gcc/testsuite/gcc.dg/analyzer/pr103032.c:1173:8: note: argument 1 of ‘strlen’ must be non-null 1173 | size_t strlen(const char *); |^~
[Bug other/103293] New: [12 regression] gcc.dg/tree-ssa/if-to-switch-3.c fails after r12-5301
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103293
Bug ID: 103293
Summary: [12 regression] gcc.dg/tree-ssa/if-to-switch-3.c fails
after r12-5301
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
g:045206450386bcd774db3bde0c696828402361c6, r12-5301
make -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
tree-ssa.exp=gcc.dg/tree-ssa/if-to-switch-3.c"
FAIL: gcc.dg/tree-ssa/if-to-switch-3.c scan-tree-dump iftoswitch "Condition
chain with [^\n\r]* BBs transformed into a switch statement."
# of expected passes1
# of expected passes2
# of expected passes3
# of unexpected failures1
# of unexpected failures1
I've only seen this fail on powerpc64 BE.
commit 045206450386bcd774db3bde0c696828402361c6
Author: Richard Biener
Date: Fri Nov 12 10:21:22 2021 +0100
tree-optimization/102880 - improve CD-DCE
[Bug tree-optimization/103288] [12 Regression] ice during GIMPLE pass: phiopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103288 --- Comment #7 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > Before phiopt, we have: > if (func_14_uli_8.0_1 != 0) > goto ; [50.00%] > else > goto ; [50.00%] > >[local count: 805306369]: > _11 = pretmp_13 & 5; > goto ; [100.00%] > >[local count: 536870913]: > if (pretmp_13 != 0) > goto ; [50.00%] > else > goto ; [50.00%] > >[local count: 1073741824]: > # prephitmp_12 = PHI <_11(3), 0(4)> So the bug is inside value_replacement where we move the definition of _11 to be inside bb 4: (gdb) p debug_bb(cond_bb) ;; basic block 4, loop depth 0, count 536870913 (estimated locally), maybe hot ;; prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED) ;; pred: 2 [50.0% (guessed)] count:536870912 (estimated locally) (FALSE_VALUE,EXECUTABLE) _11 = pretmp_13 & 5; if (pretmp_13 != 0) goto ; [50.00%] else goto ; [50.00%] ;; succ: 3 [50.0% (guessed)] count:268435457 (estimated locally) (TRUE_VALUE,EXECUTABLE) ;; 5 [50.0% (guessed)] count:268435457 (estimated locally) (FALSE_VALUE,EXECUTABLE)
[Bug tree-optimization/103288] [12 Regression] ice during GIMPLE pass: phiopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103288 Andrew Pinski changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #6 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > It actually worked at that point. r12-5301-g045206450386bcd77 did cause some > IR changes but I do think this just exposed a bug in r12-5300. Yes, if I revert either r12-5300 or r12-5301 the failure goes away.
[Bug tree-optimization/103288] [12 Regression] ice during GIMPLE pass: phiopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103288 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-11-16 Status|UNCONFIRMED |NEW --- Comment #5 from Andrew Pinski --- Before phiopt, we have: if (func_14_uli_8.0_1 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 805306369]: _11 = pretmp_13 & 5; goto ; [100.00%] [local count: 536870913]: if (pretmp_13 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 1073741824]: # prephitmp_12 = PHI <_11(3), 0(4)> There must be a missing check (In reply to Andrew Pinski from comment #1) > Most likely caused by r12-5300-gf98f373dd822b35c . It actually worked at that point. r12-5301-g045206450386bcd77 did cause some IR changes but I do think this just exposed a bug in r12-5300.
[Bug c/103292] New: [12 regression] xorg-server-1.20.13 -Werror=array-bounds false positive on unions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103292
Bug ID: 103292
Summary: [12 regression] xorg-server-1.20.13
-Werror=array-bounds false positive on unions
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Created attachment 51818
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51818&action=edit
a.c.c.orig
Initially observed build failure on xorg-server-1.20.13.
Looks like gcc detects out-of-bounds access on union of structs of different
sizes. Extracted example from unreduced a.c.c.orig (attached):
$ cat a.c.c
typedef long unsigned int size_t;
extern void *malloc (size_t __size) __attribute__ ((__nothrow__ ,
__leaf__)) __attribute__ ((__malloc__)) __attribute__ ((__alloc_size__ (1)))
__attribute__ ((__warn_unused_result__));
struct _PictSolidFill {
unsigned int type;
char foo[20];
};
struct _PictHuge {
unsigned int type;
char foo[200];
};
union _SourcePict {
// each union member has a type
unsigned int type;
struct _PictSolidFill maybePSF;
// presence of this field triggers an error
struct _PictHuge maybeHuge;
};
struct _Picture {
union _SourcePict* pSourcePict;
};
extern
void CreateSolidPicture(struct _Picture* pPicture);
void CreateSolidPicture(struct _Picture* pPicture)
{
pPicture->pSourcePict = (union _SourcePict*) malloc(sizeof(struct
_PictSolidFill));
pPicture->pSourcePict->type = 0;
}
$ gcc-12.0.0 -Werror=array-bounds -c a.c.c -O2
a.c.c: In function 'CreateSolidPicture':
a.c.c:47:30: error: array subscript 'union _SourcePict[0]' is partly outside
array bounds of 'unsigned char[24]' [-Werror=array-bounds]
47 | pPicture->pSourcePict->type = 0;
| ^~
a.c.c:46:54: note: object of size 24 allocated by 'malloc'
46 | pPicture->pSourcePict = (union _SourcePict*)
malloc(sizeof(struct _PictSolidFill));
|
^
cc1: some warnings being treated as errors
$ gcc-12.0.0 -v
Using built-in specs.
COLLECT_GCC=/nix/store/59jdmdy3ylrpmap1bjxic1fjaq8wf96s-gcc-12.0.0/bin/gcc
COLLECT_LTO_WRAPPER=/nix/store/59jdmdy3ylrpmap1bjxic1fjaq8wf96s-gcc-12.0.0/libexec/gcc/x86_64-unknown-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 2024 (experimental) (GCC)
[Bug ipa/103246] [12 Regression] 416.gamess miscompare with -O2 -g -flto=auto since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103246
--- Comment #11 from Jan Hubicka ---
Thanks for reducing the testcase.
I found the reason for build difference. There is misplaced code clearing
to_info_lto.
hubicka@lomikamen-jh:/aux/hubicka/trunk-git/build4/gcc$ cat ~/fix
diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index a70575bc807..1241e567266 100644
--- a/gcc/ipa-modref.c
+++ b/gcc/ipa-modref.c
@@ -5123,6 +5150,7 @@ ipa_merge_modref_summary_after_inlining (cgraph_edge
*edge)
fprintf (dump_file, "Removed mod-ref summary for %s\n",
to->dump_name ());
summaries_lto->remove (to);
+ to_info_lto = NULL;
}
else if (to_info_lto && dump_file)
{
@@ -5130,7 +5158,6 @@ ipa_merge_modref_summary_after_inlining (cgraph_edge
*edge)
fprintf (dump_file, "Updated mod-ref summary for %s\n",
to->dump_name ());
to_info_lto->dump (dump_file);
- to_info_lto = NULL;
}
if (callee_info_lto)
summaries_lto->remove (edge->callee);
[Bug c++/101405] [12 Regression] internal compiler error: in reshape_init_class, at cp/decl.c:6483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101405
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Priority|P1 |P2
Keywords|ice-on-valid-code |ice-on-invalid-code
--- Comment #2 from Marek Polacek ---
Invalid -> P2.
$ xg++-10 -c 101405.C
101405.C: In function ‘int main()’:
101405.C:19:3: error: could not convert ‘{10, 42}’ from ‘’ to ‘B’
19 | };
| ^
| |
|
[Bug c++/103291] [11/12 Regression] #pragma gcc visibility is lost for external decls declared inside a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103291 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- (In reply to Andrew Pinski from comment #1) > Most likely introduced by the same commit too (r11-3699-g4e62aca0e0). Yes. r11-3698: _Z12hidden_fetchv: .LFB0: pushq %rbp .LCFI0: movq%rsp, %rbp .LCFI1: movlhidden_global(%rip), %eax popq%rbp .LCFI2: ret r11-3699: _Z12hidden_fetchv: .LFB0: pushq %rbp .LCFI0: movq%rsp, %rbp .LCFI1: movqhidden_global@GOTPCREL(%rip), %rax movl(%rax), %eax popq%rbp .LCFI2: ret
[Bug c++/102740] [10/11/12 Regression] Data member not found in struct inside an unnamed union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102740 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #5 from Marek Polacek --- Started with r12-954. (Bug 101405 also started with that rev.)
[Bug c++/103291] [11/12 Regression] #pragma gcc visibility is lost for external decls declared inside a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103291 Andrew Pinski changed: What|Removed |Added Summary|[11/12 Regression] |[11/12 Regression] #pragma |visibility is lost for |gcc visibility is lost for |external decls declared |external decls declared |inside a function |inside a function --- Comment #2 from Andrew Pinski --- The attribute still works.
[Bug tree-optimization/103288] [12 Regression] ice during GIMPLE pass: phiopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103288 --- Comment #4 from Andrew Pinski --- For me it was working at r12-5290-g074ee8d9a91d7 .
[Bug c++/103291] [11/12 Regression] visibility is lost for external decls declared inside a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103291 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-11-16 Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102496 --- Comment #1 from Andrew Pinski --- Related to PR 102496 (which was about losing __thread). Confirmed. Most likely introduced by the same commit too (r11-3699-g4e62aca0e0).
[Bug c++/103291] [11/12 Regression] visibility is lost for external decls declared inside a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103291 Andrew Pinski changed: What|Removed |Added Known to work||10.3.0 Summary|gcc 11 regression with |[11/12 Regression] |#pragma GCC visibility vs |visibility is lost for |extern inside C++ functions |external decls declared ||inside a function Target Milestone|--- |11.3 Known to fail||11.1.0, 12.0 Keywords||missed-optimization
[Bug testsuite/103282] New test case gcc.dg/tree-ssa/modref-dse-5.c in r12-5292 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103282 Jan Hubicka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jan Hubicka --- Sorry, I pushed in patches in wrong order and modref-dse-5.c testcase requires the bytewise DSE patch (adding modref-dse-4.c) already in. I pushed it now and the failure is gone.
[Bug c++/103291] New: gcc 11 regression with #pragma GCC visibility vs extern inside C++ functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103291
Bug ID: 103291
Summary: gcc 11 regression with #pragma GCC visibility vs
extern inside C++ functions
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Target Milestone: ---
GCC 11 has a regression with:
```
#pragma GCC visibility push(hidden)
int hidden_fetch(void) {
extern const int hidden_global;
return hidden_global;
}
```
when compiled with -fpic. GCC 10 would always avoid the GOT for this case. GCC
11 avoids the GOT when it's compiled as C, but uses the GOT when it's compiled
as C++. Moving the extern decl outside the function makes it dtrt again in C++
as well.
Reproduced on trunk at 4cdf7db9a39d18bd536d816a5751d4d3cf23808b and on 11
branch at b52e2254b30445f3cd667ae0f0d99b183394e37b.
[Bug c++/102740] [10/11/12 Regression] Data member not found in struct inside an unnamed union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102740 Andrew Pinski changed: What|Removed |Added CC||roland at gnu dot org --- Comment #4 from Andrew Pinski --- *** Bug 103290 has been marked as a duplicate of this bug. ***
[Bug c++/103290] gcc 11 regression with C++ designated initializers, unions, anonymous struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103290 --- Comment #2 from Andrew Pinski --- Sorry it is a dup of bug 102740. Both are similar issues. *** This bug has been marked as a duplicate of bug 102740 ***
[Bug c++/101767] [10/11/12 Regression] Aggregate initialization fails for struct that has both unnamed struct and union fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101767 Andrew Pinski changed: What|Removed |Added CC||roland at gnu dot org --- Comment #2 from Andrew Pinski --- *** Bug 103290 has been marked as a duplicate of this bug. ***
[Bug c++/103290] gcc 11 regression with C++ designated initializers, unions, anonymous struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103290 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 101767. *** This bug has been marked as a duplicate of bug 101767 ***
[Bug c++/103290] New: gcc 11 regression with C++ designated initializers, unions, anonymous struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103290
Bug ID: 103290
Summary: gcc 11 regression with C++ designated initializers,
unions, anonymous struct
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Target Milestone: ---
```
struct S {
union {
struct {
unsigned short x;
} s;
};
};
S foo() {
S x = {.s = {.x = 1}};
return x;
}
```
with g++
produces error: 'S::' has no non-static data member named 'x'
This is a regression from GCC 10. The same code compiled as C still works.
Reproduced on trunk at 4cdf7db9a39d18bd536d816a5751d4d3cf23808b and on 11
branch at b52e2254b30445f3cd667ae0f0d99b183394e37b.
[Bug c++/103118] [modules] ICE tree check in get_merge_kind at cp/module.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103118 --- Comment #4 from Johel Ernesto Guerrero Peña --- With the setup in Comment 3, now I can also include `` in the GMF of a module. I don't think this worked last week. Though all I'm doing in the module is specializing a my-library type trait on some chrono date types.
[Bug tree-optimization/103288] [12 Regression] ice during GIMPLE pass: phiopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103288 --- Comment #3 from David Binderman --- (In reply to Andrew Pinski from comment #1) > Most likely caused by r12-5300-gf98f373dd822b35c . Strange. That git commit doesn't seem to be in the range of git hashes I specified. The one commit that does mention phi in that range is b7a23949b0dcc4205fcc2be6b84b91441faa384d, by Aldy Hernandez. I am unlikely to have the time to do a git bisect in the next 24 hours or so.
[Bug tree-optimization/103288] [12 Regression] ice during GIMPLE pass: phiopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103288
--- Comment #2 from David Binderman ---
Reduced C code seems to be
int ui_5;
long func_14_uli_8;
void func_14() {
ui_5 &= (func_14_uli_8 ? 60 : ui_5) ? 5 : 0;
}
[Bug tree-optimization/103288] [12 Regression] ice during GIMPLE pass: phiopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103288 Andrew Pinski changed: What|Removed |Added Summary|ice during GIMPLE pass: |[12 Regression] ice during |phiopt |GIMPLE pass: phiopt Component|c |tree-optimization CC||pinskia at gcc dot gnu.org Target Milestone|--- |12.0 Keywords||ice-on-valid-code --- Comment #1 from Andrew Pinski --- Most likely caused by r12-5300-gf98f373dd822b35c .
[Bug fortran/103289] New: OpenMP: Private Allocatable arrays not allowed inside 'parallel' with default(none)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103289 Bug ID: 103289 Summary: OpenMP: Private Allocatable arrays not allowed inside 'parallel' with default(none) Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vzborovsky at gmail dot com Target Milestone: --- Hello, This code does not compile: program t implicit none integer, allocatable :: a(:) integer :: j !$omp parallel default(none) !$omp do private(a) do j = 1, 1000 end do !$omp end do !$omp end parallel end program Compiler fails with the error: /app/example.f90:7:19: 7 | !$omp do private(a) | ^ Error: 'a' not specified in enclosing 'parallel' /app/example.f90:6:28: 6 | !$omp parallel default(none) |^ note: enclosing 'parallel' Compiler returned: 1 The code above was tested against gfortran versions 4.9.4, 7.3.0, 10.2, 11.2. Versions 4.9.4 and 11.2 were tested at godbolt.org site, https://godbolt.org/z/caEEsvxc6 All versions above produce the same error. But the code does compile when: a) either I change the type of 'a' variable to fixed-size array b) or declare 'a' as private in 'parallel' construct c) or use combined 'parallel do' construct d) or use Intel Fortran compiler I have tried to read OpenMP specification but haven't found anything prohibiting the code above. With best regards, Vadim Zborovskii
[Bug c/103288] New: ice during GIMPLE pass: phiopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103288 Bug ID: 103288 Summary: ice during GIMPLE pass: phiopt Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 51817 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51817&action=edit C source code For the attached C code, compiled with recent gcc trunk and compiler flag -O2, does this: $ /home/dcb/gcc/results/bin/gcc -w -O2 destDir/testFile.239.c destDir/testFile.239.c: In function ‘func_14’: destDir/testFile.239.c:38:9: error: definition in block 6 does not dominate use in block 5 38 | int32_t func_14(uint64_t uli_8, int8_t c_9, int8_t c_10, uint64_t uli_11) | ^~~ for SSA_NAME: _102 in statement: prephitmp_103 = PHI <_102(5), _102(6)> PHI argument _102 for PHI node prephitmp_103 = PHI <_102(5), _102(6)> during GIMPLE pass: phiopt The bug first seems to occur sometime between git hash 2f3d43a35155685b and 8a601f9bc45f9faa, a distance of 22 commits.
[Bug c++/101715] [11/12 Regression] ICE with noexcept and canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101715 Andrew Pinski changed: What|Removed |Added CC||slyfox at gcc dot gnu.org --- Comment #13 from Andrew Pinski --- *** Bug 103279 has been marked as a duplicate of this bug. ***
[Bug c++/103279] [12 regression] ICE on llvm-compiler-rt-13: internal compiler error: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103279 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- (In reply to Marek Polacek from comment #2) > Probably a dup of bug 101715, haven't verified yet. It is a dup. The noexcept part is the key there. *** This bug has been marked as a duplicate of bug 101715 ***
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug analyzer/102695] missing -Wanalyzer-write-to-const for writing to string, function, label, or const member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102695 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2021-11-16 --- Comment #1 from David Malcolm --- Am testing a fix
[Bug tree-optimization/103281] [9/10/12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103281 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > The only thing which PHIOPT does is change: > if (c_15 == 0) > goto ; [INV] > else > goto ; [INV] > >: > >: > # iftmp.1_10 = PHI <0(4), c_15(3)> > > to be: > iftmp.1_10 = c_15; > > This is a missed VRP: > # RANGE [0, 2] NONZERO 3 > c_9 = (charD.10) b.4_5; > _1 = c_9 <= 0; > # RANGE [0, 1] NONZERO 1 > _2 = (unsigned intD.14) _1; > if (_2 == b.4_5) Note it just happens that iftmp.1_10 case of being 0 is the only that matters to be "peeled" off and special cased. Plus it just happens: char a = c ? c : c << 1; Is hiding the relationship between a and c. GCC does optimize if we change the loop to: b >= 1 && b < 4 What we need to realize is that 0 needs to "peeled" off and tried seperately with the range. that is the following two ranges need to be done seperately for b.4_5: [0, 0] [1, 2] But how do GCC decides that is "hard". we know the range of _1 to be [0,1] so we need to figure out the ranges of c_9 which cause 0 and which one causes 1. This is not just a forward looking alogrothim but need to look back really. It can be very computational instensive too.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #42 from cqwrteur --- Created attachment 51816 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51816&action=edit patch after today's update to configure add a patch for today's update
[Bug tree-optimization/103281] [9/10/12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103281 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #3 from Andrew Pinski --- Would be interesting to know what "fixed" it for 11 and what broke it for 9 really.
[Bug ipa/103246] [12 Regression] 416.gamess miscompare with -O2 -g -flto=auto since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103246 --- Comment #10 from Martin Liška --- I isolated small reproducer: $ cat 1.f SUBROUTINE DENDD1(B,L2) IF(CITYPIPSI.EQ.1) CALL VADD(A1DB1DA,1,L2) END $ cat 2.f LOGICAL BSFDD L2 = 2 CALL DENDD1(X0X0,L2) IF(BSFDD) THEN CALL VCLR(X01NXYZ2*L2) CALL HFD(BSFDD) END IF END $ cat cmd FLAGS="-O2 -flto=16 -flto-partition=1to1 -fPIC" gfortran-11 *.f $FLAGS -c gfortran-11 *.o $FLAGS -o gamess1 -shared $OBJ gfortran-11 *.o $FLAGS -fdump-ipa-inline -o gamess2 -shared $OBJ objdump -d gamess1 > gamess1.txt objdump -d gamess2 > gamess2.txt diff -u gamess1 gamess2 if test $? = 1; then exit 0 else exit 1 fi $ ./cmd && diff gamess1.txt gamess2.txt ... @@ -76,91 +76,88 @@ 10d8: 31 c0 xor%eax,%eax 10da: 48 83 c4 18 add$0x18,%rsp 10de: c3 ret -10df: 66 0f ef c0 pxor %xmm0,%xmm0 -10e3: 48 8d 7c 24 0c lea0xc(%rsp),%rdi -10e8: f3 0f 2a 44 24 04 cvtsi2ssl 0x4(%rsp),%xmm0 -10ee: f3 0f 59 05 26 0f 00mulss 0xf26(%rip),%xmm0# 201c -10f5: 00 -10f6: f3 0f 11 44 24 0c movss %xmm0,0xc(%rsp) -10fc: e8 2f ff ff ff call 1030 -1101: 48 89 e7mov%rsp,%rdi ... but this got fixed on master with r12-5223-gecdf414bd89e6ba2. I'll try if it happens with the current master. Hope it helps.
[Bug tree-optimization/103281] [9/10/12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103281 Andrew Pinski changed: What|Removed |Added Summary|[9/12 Regression] Dead Code |[9/10/12 Regression] Dead |Elimination Regression at |Code Elimination Regression |-O3 (trunk vs 11.2.0) |at -O3 (trunk vs 11.2.0) --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > I want to say we should defer this until after GCC 12 because this was only > being optimized on accident. phiopt1 As you can see by this used to work between 4.9-8.0 and then regressed in GCC 9 and 10.
[Bug tree-optimization/103281] [9/12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103281
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
Keywords||missed-optimization
Ever confirmed|0 |1
Known to fail||10.1.0, 12.0, 4.7.1, 4.8.1,
||9.1.0
Summary|[12 Regression] Dead Code |[9/12 Regression] Dead Code
|Elimination Regression at |Elimination Regression at
|-O3 (trunk vs 11.2.0) |-O3 (trunk vs 11.2.0)
Last reconfirmed||2021-11-16
Known to work||11.1.0, 4.9.0, 4.9.4,
||5.1.0, 6.1.0, 7.1.0, 8.1.0
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
The only thing which PHIOPT does is change:
if (c_15 == 0)
goto ; [INV]
else
goto ; [INV]
:
:
# iftmp.1_10 = PHI <0(4), c_15(3)>
to be:
iftmp.1_10 = c_15;
This is a missed VRP:
# RANGE [0, 2] NONZERO 3
c_9 = (charD.10) b.4_5;
_1 = c_9 <= 0;
# RANGE [0, 1] NONZERO 1
_2 = (unsigned intD.14) _1;
if (_2 == b.4_5)
_1/_2 is true/1 only when c_9 is 0 and only when b.4_5 is 0.
- CUT -
We should be able to optimize:
void foo(void);
static unsigned b;
int main() {
for (; b < 3; b++) {
char c = b;
char a = c;
if (!((a < 1) ^ b))
foo();
}
}
Too.
We also miss:
void foo(void);
static unsigned b;
int main() {
for (; b < 3; b++) {
if (!((b < 1) ^ b))
foo();
}
}
_1 = b.2_6 == 0;
_2 = (unsigned int) _1;
if (_2 == b.2_6)
I want to say we should defer this until after GCC 12 because this was only
being optimized on accident. phiopt1
[Bug fortran/97896] [11/12 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896 --- Comment #13 from CVS Commits --- The releases/gcc-11 branch has been updated by Mikael Morin : https://gcc.gnu.org/g:92e549683e1f46ba419e40b12928dc8afe5dc967 commit r11-9243-g92e549683e1f46ba419e40b12928dc8afe5dc967 Author: Mikael Morin Date: Sun Nov 7 14:39:18 2021 +0100 fortran: Ignore unused args in scalarization [PR97896] The KIND argument of the INDEX intrinsic is a compile time constant that is used at compile time only to resolve to a kind-specific library function. That argument is otherwise completely ignored at runtime, and there is no code generated for it as the library procedure has no kind argument. This confuses the scalarizer which expects to see every argument of elemental functions used when calling a procedure. This change removes the argument from the scalarization lists at the beginning of the scalarization process, so that the argument is completely ignored. This also reverts the existing workaround (commit d09847357b965a2c2cda063827ce362d4c9c86f2 except for its testcase). PR fortran/97896 gcc/fortran/ChangeLog: * intrinsic.c (add_sym_4ind): Remove. (add_functions): Use add_sym4 instead of add_sym4ind. Donât special case the index intrinsic. * iresolve.c (gfc_resolve_index_func): Use the individual arguments directly instead of the full argument list. * intrinsic.h (gfc_resolve_index_func): Update the declaration accordingly. * trans-decl.c (gfc_get_extern_function_decl): Donât modify the list of arguments in the case of the index intrinsic. * trans-array.h (gfc_get_intrinsic_for_expr, gfc_get_proc_ifc_for_expr): New. * trans-array.c (gfc_get_intrinsic_for_expr, arg_evaluated_for_scalarization): New. (gfc_walk_elemental_function_args): Add intrinsic procedure as argument. Count arguments. Check arg_evaluated_for_scalarization. * trans-intrinsic.c (gfc_walk_intrinsic_function): Update call. * trans-stmt.c (get_intrinsic_for_code): New. (gfc_trans_call): Update call. gcc/testsuite/ChangeLog: * gfortran.dg/index_5.f90: New. (cherry picked from commit 68d62cb20637b2faf2c2cc1716a0786b07a6a76f)
[Bug fortran/103263] ICE in gfc_check_reshape, at fortran/check.c:4830
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103263 --- Comment #3 from anlauf at gcc dot gnu.org --- Likely a duplicate / variant of the old constructor bug for [array]. We have tons of these.
[Bug fortran/103286] ICE in resolve_select, at fortran/resolve.c:8848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103286 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from anlauf at gcc dot gnu.org --- Fixed on mainline. Closing. Thanks for the report!
[Bug tree-optimization/102981] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102981 --- Comment #5 from Aldy Hernandez --- *** Bug 103280 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/103280] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103280 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Aldy Hernandez --- Duplicate. There's a threading candidate in 2->6->3->5 that would elide the call to foo(), but doing so would peel off an iteration. This is another case of the first iteration of a loop having dead code. *** This bug has been marked as a duplicate of bug 102981 ***
[Bug fortran/103287] [12 Regression] ICE in argument_rank_mismatch, at fortran/interface.c:2240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103287 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug fortran/103286] ICE in resolve_select, at fortran/resolve.c:8848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103286 --- Comment #2 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:3b3c9932338650c9a402cf1bfbdf7dfc03e185e7 commit r12-5322-g3b3c9932338650c9a402cf1bfbdf7dfc03e185e7 Author: Harald Anlauf Date: Tue Nov 16 21:06:06 2021 +0100 Fortran: avoid NULL pointer dereference on invalid range in logical SELECT CASE gcc/fortran/ChangeLog: PR fortran/103286 * resolve.c (resolve_select): Choose appropriate range limit to avoid NULL pointer dereference when generating error message. gcc/testsuite/ChangeLog: PR fortran/103286 * gfortran.dg/pr103286.f90: New test.
[Bug fortran/103287] [12 Regression] ICE in argument_rank_mismatch, at fortran/interface.c:2240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103287
kargl at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-11-16
Ever confirmed|0 |1
CC||kargl at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #2 from kargl at gcc dot gnu.org ---
Change an assert to an if-statement and simply return.
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 30c99ef3938..8bd507be67c 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -2237,7 +2237,9 @@ argument_rank_mismatch (const char *name, locus *where,
}
else
{
- gcc_assert (rank2 != -1);
+ if (rank2 == -1)
+ return;
+
if (rank1 == 0)
gfc_error_opt (0, "Rank mismatch between actual argument at %L "
"and actual argument at %L (scalar and rank-%d)",
[Bug fortran/103286] ICE in resolve_select, at fortran/resolve.c:8848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103286
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-11-16
Ever confirmed|0 |1
--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.
Untested patch:
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 705d2326a29..f074a0ab3a1 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -8846,7 +8846,8 @@ resolve_select (gfc_code *code, bool select_type)
|| cp->low != cp->high))
{
gfc_error ("Logical range in CASE statement at %L is not "
-"allowed", &cp->low->where);
+"allowed",
+cp->low ? &cp->low->where : &cp->high->where);
t = false;
break;
}
