[Bug rtl-optimization/107167] It looks like GCC wastes registers on trivial computations when result can be cached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107167 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization --- Comment #1 from Andrew Pinski --- This is a reassociation, scheduling issue and register allocation issue. Plus your example might be slower due to dependencies. Without a full example of where gcc ra goes wrong, gcc actually produces much better code for this example due to register renaming in hw. Note many x86_64 also does register renaming for the stack too
[Bug rtl-optimization/107167] New: It looks like GCC wastes registers on trivial computations when result can be cached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107167
Bug ID: 107167
Summary: It looks like GCC wastes registers on trivial
computations when result can be cached
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: unlvsur at live dot com
Target Milestone: ---
I do not know whether it is a big issue or not with targets that provide tons
of available registers (like aarch64 or loongarch64). However, this looks like
a big issue for x86_64 which only provides 16 general purpose registers (plus
%rsp is reserved, so 15 available registers)
Take the example like this:
https://godbolt.org/z/77rEsr1PG
#include
unsigned Sigma1(unsigned x) noexcept
{
return std::rotr(x,6)^std::rotr(x,11)^std::rotr(x,25);
}
GCC generates code like this to avoid dependencies.
Sigma1m(unsigned int):
movl%edi, %eax
movl%edi, %edx
roll$7, %edi
rorl$6, %eax
rorl$11, %edx
xorl%edx, %eax
xorl%edi, %eax
ret
However:
mySigma1m(unsigned int):
movl%edi, %eax
rorl$6, %edi
rorl$11, %eax
xorl%edi, %eax
rorl$19, %edi
xorl%edi, %eax
ret
Saves one register in this task. That becomes a huge problem when tons of
computation are involved where registers are in a position of shortage.
1st one also generates 1 more instruction and it can affect the code cache.
Aggressively utilizing all registers may not give the best results. Local
maximum =/= Global maximum.
I don't know.
[Bug c/107166] "useless type name in empty declaration" diagnostic may refer to wrong location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107166 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-10-06 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Known to fail||4.7.1 --- Comment #1 from Andrew Pinski --- Confirmed. The C++ front-end does a better job here. Though gets the last one wrong: :3:6: error: declaration does not declare anything [-fpermissive] 3 | long long; | ^~~~ clang does even better job and underlines all parts: :1:1: warning: declaration does not declare anything [-Wmissing-declarations] static int; ^~ :2:1: warning: declaration does not declare anything [-Wmissing-declarations] _Alignas(int) char; ^~ :3:1: warning: declaration does not declare anything [-Wmissing-declarations] long long; ^
[Bug c/107166] "useless type name in empty declaration" diagnostic may refer to wrong location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107166 Andrew Pinski changed: What|Removed |Added Severity|normal |minor
[Bug c++/55578] Disabling warnings inside macro definition doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578 Lewis Hyatt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Lewis Hyatt --- (In reply to Vadim Zeitlin from comment #12) > Thanks for looking at this! I'm happy to hear that the problem is fixed in > 11.2, but I'm probably not going to change our code anyhow, especially as > we're going to finally drop support for C++98 very soon and so will be able > to just use "override" unconditionally anyhow. > > I.e. from my point of view there is no real problem any more, I just replied > here to give more information about the problem in case it could be useful. Thanks, yes it was useful. Hopefully, issues with warning suppression will be increasingly rare going forward.
[Bug c++/55578] Disabling warnings inside macro definition doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578 --- Comment #12 from Vadim Zeitlin --- Thanks for looking at this! I'm happy to hear that the problem is fixed in 11.2, but I'm probably not going to change our code anyhow, especially as we're going to finally drop support for C++98 very soon and so will be able to just use "override" unconditionally anyhow. I.e. from my point of view there is no real problem any more, I just replied here to give more information about the problem in case it could be useful.
[Bug c/107166] New: "useless type name in empty declaration" diagnostic may refer to wrong location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107166 Bug ID: 107166 Summary: "useless type name in empty declaration" diagnostic may refer to wrong location Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: stephenheumann at gmail dot com Target Milestone: --- GCC seems to give a "useless type name in empty declaration" diagnostic for any empty declaration containing a type, but it always just points to the first token of the declaration, which is not necessarily the type (or may only be a part of it). E.g.: static int; _Alignas(int) char; long long; gives the following diagnostics: :1:1: warning: useless type name in empty declaration 1 | static int; | ^~ :2:1: warning: useless type name in empty declaration 2 | _Alignas(int) char; | ^~~~ :3:1: warning: useless type name in empty declaration 3 | long long; | ^~~~ These could be changed to actually refer to the location of the type specifier(s), or they could be changed to different diagnostics that already exist for empty declarations without a type, such as "useless storage class specifier in empty declaration".
[Bug c++/107165] Downcasting in constexpr, error: "accessing value of `...Derived::’ through a ‘Derived’ glvalue in a constant expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107165 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 103879. See bug 103879 comment #6 which is exactly the same testcase as comment #0 here. *** This bug has been marked as a duplicate of bug 103879 ***
[Bug c++/103879] error: accessing value of variant::_Copy_ctor_base through a 'const variant' glvalue in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103879 Andrew Pinski changed: What|Removed |Added CC||petr.azmanov at wartsila dot com --- Comment #13 from Andrew Pinski --- *** Bug 107165 has been marked as a duplicate of this bug. ***
[Bug c++/107165] Downcasting in constexpr, error: "accessing value of `...Derived::’ through a ‘Derived’ glvalue in a constant expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107165 --- Comment #1 from Andrew Pinski --- Note since it was fixed in GCC 12.1.0 and it does not look like a regression, this will be closed as fixed for GCC 12 after bisecting to the patch which fixed it and the fix won't be backported to GCC 11.x.
[Bug c++/107165] New: Downcasting in constexpr, error: "accessing value of `...Derived::’ through a ‘Derived’ glvalue in a constant expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107165
Bug ID: 107165
Summary: Downcasting in constexpr, error: "accessing value of
`...Derived::’ through a ‘Derived’ glvalue
in a constant expression"
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petr.azmanov at wartsila dot com
Target Milestone: ---
Created attachment 53670
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53670=edit
copy of the test case from the comment
Downcasting in constexpr context is broken if derived class is wrapped in
another structure.
Tested locally with g++ (Ubuntu 11.2.0-19ubuntu1) 11.2.0
Reproduced with g++ 11.3.0 in Godbolt (https://godbolt.org/z/fvoWhrh41)
Isn't reproduced with 12.1 or 12.2.
```
struct Base
{
int b = 0;
};
struct Derived : Base
{
int d = 2;
constexpr bool foo(int x)
{
return x > d;
}
};
int main()
{
constexpr auto test = []()
{
struct Dummy
{
Derived derived;
};
Dummy d;
Base & base = d.derived;
static_cast(base).foo(1);
// Derived d;
// Base & base = d;
// static_cast(base).foo(1);
return true;
}();
return test;
}
```
[Bug c++/55578] Disabling warnings inside macro definition doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578 --- Comment #11 from Lewis Hyatt --- (In reply to Vadim Zeitlin from comment #10) > There definitely was a change in behaviour in gcc 11 because I had to make > this change > > https://github.com/wxWidgets/wxWidgets/commit/ > 95c98a0b5ff71caca6654327bf341719c6587766 Thanks for that. I made a bisectable test that compiles allheaders.cpp (without your GCC 11-specific workaround in place) and counts the number of -Wsuggest-override warnings, which does indeed change in GCC 11.1 vs older and newer versions. The bisect confirmed that this issue was the same as that of PR100796. It existed only in GCC 11.1, as it was introduced by r11-7179 and was fixed by r12-1538, which was also backported to GCC 11.2. This particular issue only materializes with a sufficiently large source file, so I don't think you should find any "reasonably" sized testcase to reproduce it. All basic examples I tried work fine in 11.1 as well. As far as I can tell, I think your workaround should be needed only for sufficiently large translation units (approx 10 lines or more), not for typical size user code, and I think it should be needed only for 11.1 and no other version. If you know otherwise, please advise... otherwise, I think this is resolved.
[Bug c/107164] No pedantic warning for declaration just referring to a previously-declared enum type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107164
--- Comment #1 from Andrew Pinski ---
clang says it is a GCC extension:
:2:6: warning: redeclaration of already-defined enum 'E' is a GNU
extension [-Wgnu-redeclared-enum]
enum E;
^
:1:6: note: previous definition is here
enum E {a,b,c};
^
GCC does have a forward declaration extension for enum types so it makes sense
to allow this as an extension too.
That is:
```
enum E;
enum E {a,b,c};
```
(which GCC does have a pedantic diagnostic about).
[Bug c/107164] New: No pedantic warning for declaration just referring to a previously-declared enum type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107164
Bug ID: 107164
Summary: No pedantic warning for declaration just referring to
a previously-declared enum type
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: stephenheumann at gmail dot com
Target Milestone: ---
gcc -std=c17 -pedantic accepts this without any diagnostics:
enum E {a,b,c};
enum E;
C17 section 6.7.2.3 p9 says that an "enum identifier" type specifier using a
tag with an existing declaration visible "specifies the same type as that other
declaration, and does not redeclare the tag". Accordingly, the second line
above does not declare a declarator, a tag, or the members of an enumeration,
and so it violates the constraint in C17 section 6.7 p2.
(The relevant standard text is basically the same from C99 through draft C23.
C90 is less explicit, but I think is intended to behave the same.)
This should at least give a pedantic warning. Perhaps it could be an
always-enabled warning, but I'm not sure if code like the above is supposed to
be allowed as a GCC extension.
[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 --- Comment #23 from anlauf at gcc dot gnu.org --- (In reply to Steve Kargl from comment #22) > In looking at the patch, there is a > >gcc_assert (op1->ts.type != BT_UNKNOWN); > > in reduce_binary_ac() near line 1334 and > >gcc_assert (op2->ts.type != BT_UNKNOWN); > > in reduce_binary_ca() near line 1386 that > I think can go away. You're probably right, although I'm not entirely sure that there is a corner case that we haven't covered yet... I think it doesn't really harm to leave it there for now. Gerhard will tell (fingers crossed...).
[Bug c++/107163] [10/11/12/13 Regression] huge Compile time increase when using templated base classes, virtual method, and Wall since r10-2823-g6a07489267e55084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107163 --- Comment #2 from Jonathan Wakely --- Yes, using -std=gnu++14 makes GCC 11 as fast as GCC 8.
[Bug analyzer/107158] False postives from -Wanalyzer-malloc-leak on tin-2.6.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107158 --- Comment #5 from urs at akk dot org --- Now (git @ e99dcbb54e07b798c3353124f38336f96a826d43; same $CFLAGS and source file) during IPA pass: analyzer ./makecfg.c: In function ‘parse_tbl’: ./makecfg.c:150:25: internal compiler error: in bind_key, at analyzer/store.cc:1356 150 | store_data(buffer, s); | ^ 0x7fec3b172d8f __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 0x7fec3b172e3f __libc_start_main_impl ../csu/libc-start.c:392
[Bug middle-end/107047] load introduced of struct fields after assigning it to a local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107047 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Andrew Pinski --- Mine but for GCC 14.
[Bug c++/107163] [10/11/12/13 Regression] huge Compile time when using templated base classes, virtual method, and Wall since r10-2823-g6a07489267e55084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107163 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.5 Summary|Compile time regression |[10/11/12/13 Regression] |when using templated base |huge Compile time when |classes, virtual method,|using templated base |and Wall since |classes, virtual method, |r10-2823-g6a07489267e55084 |and Wall since ||r10-2823-g6a07489267e55084
[Bug c++/107163] Compile time regression when using templated base classes, virtual method, and Wall since r10-2823-g6a07489267e55084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107163 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-10-05 Summary|Compile time regression |Compile time regression |when using templated base |when using templated base |classes, virtual method,|classes, virtual method, |and Wall|and Wall since ||r10-2823-g6a07489267e55084 Ever confirmed|0 |1 CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- With -std=c++17 likely started with r10-2823-g6a07489267e55084.
[Bug c++/107163] New: Compile time regression when using templated base classes, virtual method, and Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107163
Bug ID: 107163
Summary: Compile time regression when using templated base
classes, virtual method, and Wall
Product: gcc
Version: 11.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cfsteefel at arista dot com
Target Milestone: ---
When using templates to create a recursive base class structure, if the base
class uses a virtual method and -Wall is enabled, g++-11 shows much worse
compile time compared to g++-8.
Consider the following code:
# 0 "test.cpp"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "test.cpp"
class BaseType {
virtual int doSomething() {
return 1;
}
};
template< int Seq >
class DerivedType : public DerivedType< Seq - 1 > {
};
template<>
class DerivedType< -1 > : public BaseType {
};
int main() {
auto * d = new DerivedType< COUNT >();
delete d;
return 0;
}
Compiled as:
g++-11 test.cpp -Wall -DCOUNT=200
g++-8 test.cpp -Wall -DCOUNT=200
In g++-11, with COUNT=100, the time to compile is around 2 seconds, while with
COUNT=200, the time is around 1 minute, and COUNT=400 took around 28 minutes.
For comparison, compiling the same code with g++-8 took around .3 seconds, 1.6
seconds, and 22 seconds, respectively.
Removing the virtual will lead to the compile time being near instant again, as
will removing the Wall flag (with g++-11).
Other details:
Compiler versions:
g++ (GCC) 11.3.1 20220421 (Red Hat 11.3.1-2)
g++ (GCC) 8.4.0 20200304 (Red Hat 8.4.0-4)
System:
Centos7 based linux
Compiler output:
test.cpp: In function 'int main()':
test.cpp:20:4: warning: deleting object of polymorphic class type
'DerivedType<100>' which has non-virtual destructor might cause undefined
behavior [-Wdelete-non-virtual-dtor]
20 |delete d;
|^~~~
(fixing the warning changes nothing, and seemed to double the compile time).
extra g++-11/8 configuration options:
%{O*:%{!fomit-frame-pointer:-fno-omit-frame-pointer}} \
%{O*:%{!fno-wrapv:-fwrapv}} \
%{O*:%{!freorder-blocks-and-partition:-fno-reorder-blocks-and-partition}} \
%{mfpmath=sse:-msse2} \
%{!fsemantic-interposition:-fno-semantic-interposition} \
%{g:%{!g0:-gdwarf-4}} \
Using godbolt, I can see similar timing for g++-10 and g++-8, so this seems to
be a g++-11 specific regression.
[Bug c/107162] New: -Wmisleading-indentation is blinded by comments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107162
Bug ID: 107162
Summary: -Wmisleading-indentation is blinded by comments
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
Hi,
Similar to this bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106528
-Wmissing-indentation is blinded by comments:
int square(int num) {
if (num == 1)
goto fail;
//if (num == 0)
goto fail;
if (num > 20)
return num * num;
else
return num + num;
fail:
return -1;
}
The above case does not warn in GCC, but does in Clang:
https://godbolt.org/z/bMG5jM9Ga
[Bug analyzer/107060] -fanalyzer unbearably slow when compiling GNU Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107060 --- Comment #8 from David Malcolm --- The patch for PR analyzer/107072 and the above patch mean that we get more reasonable summaries when using -fanalyzer-call-summaries. Unfortunately: - it actually slows down the analysis for PR 107060 on my box, from 10 minutes to 22 minutes at -O2, and - leads to lots of diagnostics. Given e.g. the false positives seen in PR analyzer/107158, I don't trust these diagnostics. Hence I don't recommend turning on -fanalyzer-call-summaries yet.
[Bug analyzer/107158] False postives from -Wanalyzer-malloc-leak on tin-2.6.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107158 David Malcolm changed: What|Removed |Added Summary|internal compiler error: in |False postives from |get_or_create_cluster, at |-Wanalyzer-malloc-leak on |analyzer/store.cc:2832 |tin-2.6.2 Blocks||99390 --- Comment #4 from David Malcolm --- The ICE should be fixed by the above patch. As noted above, although the ICE is fixed, there are two false positives from -Wanalyzer-malloc-leak on the test case, so I'm going to reuse this bug for tracking those; retitling accordingly, and adding to the call summarization tracker bug. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99390 [Bug 99390] [meta-bug] tracker bug for call summaries in -fanalyzer
[Bug target/106562] PRU: Inefficient code for zero check of 64-bit (boolean) AND result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106562 --- Comment #2 from Dimitar Dimitrov --- With cbranchdi4 defined, the generated code is now 10 instructions: test: qbne.L5, r15, 0 qbeq.L4, r14, 0 .L5: rsb r0, r16, 0 rsc r1, r17, 0 or r0, r0, r16 or r1, r1, r17 lsr r14, r1, 31 ret .L4: ldi r14, 0 ret Defining BRANCH_COST=0, as avr backend does, shrinks the above to only 7 instructions.
[Bug analyzer/107158] internal compiler error: in get_or_create_cluster, at analyzer/store.cc:2832
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107158 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:ef878564140cbcf23f479da88e07e5a996cec6bb commit r13-3096-gef878564140cbcf23f479da88e07e5a996cec6bb Author: David Malcolm Date: Wed Oct 5 14:07:47 2022 -0400 analyzer: add regression test for PR 107158 PR analyzer/107158 reports an ICE when using -fanalyzer -fanalyzer-call-summaries on a particular source file. It turns out I just fixed this ICE in r13-3094-g6832c95c0e1a58. This followup patch adds a somewhat reduced reproducer as a regression test. Unfortunately, although the ICE is fixed, there are two false positives from -Wanalyzer-malloc-leak on the test case, so I'm going to use PR analyzer/107158 for tracking those false positives. gcc/testsuite/ChangeLog: PR analyzer/107158 * gcc.dg/analyzer/call-summaries-pr107158.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/107060] -fanalyzer unbearably slow when compiling GNU Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107060 --- Comment #7 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:6832c95c0e1a58ba4d342ec002000f9d9d7db5ca commit r13-3094-g6832c95c0e1a58ba4d342ec002000f9d9d7db5ca Author: David Malcolm Date: Wed Oct 5 13:52:59 2022 -0400 analyzer: fix ICEs seen with call summaries on PR 107060 This doesn't fix the various false positives seen with -fanalyzer-call-summaries on PR 107060, but stops it crashing at -O2. gcc/analyzer/ChangeLog: PR analyzer/107060 * call-summary.cc (call_summary_replay::convert_svalue_from_summary_1): Handle NULL results from convert_svalue_from_summary in SK_UNARY_OP and SK_BIN_OP. * engine.cc (impl_region_model_context::on_unknown_change): Bail out on svalues that can't have associated state. * region-model-impl-calls.cc (region_model::impl_call_analyzer_get_unknown_ptr): New. * region-model.cc (region_model::on_stmt_pre): Handle "__analyzer_get_unknown_ptr". * region-model.h (region_model::impl_call_analyzer_get_unknown_ptr): New decl. * store.cc (store::replay_call_summary_cluster): Avoid trying to create binding clusters for base regions that shouldn't have them. gcc/ChangeLog: PR analyzer/107060 * doc/analyzer.texi (__analyzer_get_unknown_ptr): Document. gcc/testsuite/ChangeLog: PR analyzer/107060 * gcc.dg/analyzer/analyzer-decls.h (__analyzer_get_unknown_ptr): New decl. * gcc.dg/analyzer/call-summaries-2.c (test_summarized_writes_param_to_ptr_unknown): New test. Signed-off-by: David Malcolm
[Bug c++/107161] gcc doesn't constant fold member if any other member is mutable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107161 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization
[Bug c++/107161] New: gcc doesn't constant fold member if any other member is mutable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107161
Bug ID: 107161
Summary: gcc doesn't constant fold member if any other member
is mutable
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
Target Milestone: ---
On this code:
struct mytype
{
int a;
mutable int b;
};
extern mytype const p = {1, 2};
int foo()
{
return p.a + 10;
}
int bar()
{
return p.b + 10;
}
GCC -O2 generates:
foo():
mov eax, DWORD PTR p[rip]
add eax, 10
ret
bar():
mov eax, DWORD PTR p[rip+4]
add eax, 10
ret
While clang folds "p.a + 10" into 11:
foo():# @foo()
mov eax, 11
ret
bar():# @bar()
mov eax, dword ptr [rip + p+4]
add eax, 10
ret
I think GCC should do the same.
[Bug c++/107097] Implement floating point excess precision in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107097 --- Comment #6 from Jakub Jelinek --- Perhaps try to look up the implicit conversion using the semantic type (i.e. with EXCESS_PRECISION_EXPR not stripped) and then if it is a standard conversion (which exact?) from EXCESS_PRECISION to arithmetic/enumeral type or so, strip away the excess precision and actually convert from the excess precision?
[Bug analyzer/107158] internal compiler error: in get_or_create_cluster, at analyzer/store.cc:2832
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107158 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2022-10-05 --- Comment #2 from David Malcolm --- Thanks for filing this bug. Confirmed; am investigating.
[Bug target/103109] madd not used for multiply add on POWER9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103109 --- Comment #3 from Peter Bergner --- (In reply to HaoChen Gui from comment #2) > Fixed by r13-2107. This is marked version = GCC 12. Were you planning on backporting this?
[Bug c++/107097] Implement floating point excess precision in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107097 --- Comment #5 from Jakub Jelinek --- Seems in that case we loose the precision in: #0 fold_convert_loc (loc=0, type=, arg=) at ../../gcc/fold-const.cc:2436 #1 0x0049c414 in cxx_eval_constant_expression (ctx=0x7fffcc90, t=, lval=vc_prvalue, non_constant_p=0x7fffcdaf, overflow_p=0x7fffcdae, jump_target=0x0) at ../../gcc/cp/constexpr.cc:7541 #2 0x0049e566 in cxx_eval_outermost_constant_expr (t=, allow_non_constant=true, strict=true, manifestly_const_eval=false, constexpr_dtor=false, object=) at ../../gcc/cp/constexpr.cc:7970 #3 0x0049f3b3 in maybe_constant_value (t=, decl=, manifestly_const_eval=false) at ../../gcc/cp/constexpr.cc:8240 #4 0x004e0a81 in cp_fully_fold (x=) at ../../gcc/cp/cp-gimplify.cc:2367 #5 0x004ef3ad in cp_convert_and_check (type=, expr=, complain=3) at ../../gcc/cp/cvt.cc:666 #6 0x0042b4e1 in convert_like_internal (convs=0x3b516a0, expr=, fn=, argnum=0, issue_conversion_warnings=true, c_cast_p=false, complain=3) at ../../gcc/cp/call.cc:8549 #7 0x0042b765 in convert_like (convs=0x3b516a0, expr=, fn=, argnum=0, issue_conversion_warnings=true, c_cast_p=false, complain=3) at ../../gcc/cp/call.cc:8604 #8 0x0042b7d8 in convert_like (convs=0x3b516a0, expr=, complain=3) at ../../gcc/cp/call.cc:8616 #9 0x0043da51 in perform_implicit_conversion_flags (type=, expr=, complain=3, flags=262149) at ../../gcc/cp/call.cc:12999 #10 0x00845343 in convert_for_assignment (type=, rhs=, errtype=ICR_INIT, fndecl=, parmnum=0, complain=3, flags=262149) at ../../gcc/cp/typeck.cc:10332 #11 0x008459f4 in convert_for_initialization (exp=, type=, rhs=, flags=262149, errtype=ICR_INIT, fndecl=, parmnum=0, complain=3) at ../../gcc/cp/typeck.cc:10423 #12 0x0085075d in digest_init_r (type=, init=, nested=0, flags=262149, complain=3) at ../../gcc/cp/typeck2.cc:1276 #13 0x00850e84 in digest_init_flags (type=, init=, flags=262149, complain=3) at ../../gcc/cp/typeck2.cc:1380 #14 0x0084eaff in store_init_value (decl=, init=, cleanups=0x7fffd668, flags=262149) at ../../gcc/cp/typeck2.cc:829 #15 0x005270c3 in check_initializer (decl=, init=, flags=5, cleanups=0x7fffd668) at ../../gcc/cp/decl.cc:7466 #16 0x0052d248 in cp_finish_decl (decl=, init=, init_const_expr_p=true, asmspec_tree=, flags=5) at ../../gcc/cp/decl.cc:8468 Supposedly we should somewhere (temporarily) strip away the EXCESS_PRECISION_EXPR and readd it after conversion, but it is unclear to me where and under what conditions. Somewhere where we know it is an implicit conversion (because explicit conversion should round to semantic type)? And only when converting (implicitly) to some other REAL_TYPE/COMPLEX_TYPE? I mean, if we say try to initialize a class from some floating point value, we should determine that conversion from the semantic type. On the other side, e.g. for implicit conversion to bool, shouldn't we do the != 0 comparison in excess precision? The C patch strips EXCESS_PRECISION_EXPR unconditionally at the start of the function. So perhaps strip it in convert_for_assignment or perform_implicit_conversion_flags if type is arithmetic type (dunno about enums) only?
[Bug c++/107097] Implement floating point excess precision in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107097 Jakub Jelinek changed: What|Removed |Added Attachment #53667|0 |1 is obsolete|| --- Comment #4 from Jakub Jelinek --- Created attachment 53669 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53669=edit gcc13-pr107097-wip.patch Updated patch that handles ?:. excess-precision-1.C now passes at runtime... Next problem is excess-precision-2.C, where we rely on volatile long double ld11f = 1.1f; actually being the same as volatile long double ld11f = 1.1L;
[Bug target/107160] New: [13 regression] r13-2641-g0ee1548d96884d causes verification failure in spec2006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107160 Bug ID: 107160 Summary: [13 regression] r13-2641-g0ee1548d96884d causes verification failure in spec2006 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:0ee1548d96884d2689482054d925967a9a21d697, r13-2641-g0ee1548d96884d commit 0ee1548d96884d2689482054d925967a9a21d697 Author: Kewen Lin Date: Tue Sep 13 04:13:10 2022 -0500 rs6000: Suggest unroll factor for loop vectorization This commit is causing a verification error in a spec2006 test. 447.dealII 11440322 35.5 * 11440 10.6VE Build successes: 447.dealII(base), 447.dealII(peak) Setting Up Run Directories Setting up 447.dealII ref base ppc64 default: created (run_base_ref_ppc64.) Setting up 447.dealII ref peak ppc64 default: created (run_peak_ref_ppc64.) Running Benchmarks Running 447.dealII ref base ppc64 default /home/seurer/gcc/cpu2006/bin/specinvoke -d /home/seurer/gcc/cpu2006/benchspec/CPU2006/447.dealII/run/run_base_ref_ppc64. -e speccmds.err -o speccmds.stdout -f speccmds.cmd -C -q /home/seurer/gcc/cpu2006/bin/specinvoke -E -d /home/seurer/gcc/cpu2006/benchspec/CPU2006/447.dealII/run/run_base_ref_ppc64. -c 1 -e compare.err -o compare.stdout -f compare.cmd *** Miscompare of grid-1.eps; for details see /home/seurer/gcc/cpu2006/benchspec/CPU2006/447.dealII/run/run_base_ref_ppc64./grid-1.eps.mis Invalid run; unable to continue. 0004: %%BoundingBox: 0 0 301 289 %%BoundingBox: 0 0 301 286 ^ 0012: b 30.6779 58.2976 m 68.5015 87.3442 x b 121.58 122.428 m 137.988 136.638 x ^ 0013: b 68.5015 87.3442 m 106.325 116.391 x b 178.42 162.86 m 194.829 177.071 x ^ 0014: b 30.6779 58.2976 m 96.5094 10.9581 x b 121.58 179.269 m 137.988 193.479 x ^ 0015: b 30.6779 58.2976 m 3.86089 130.352 x b 137.988 136.638 m 166.408 128.434 x ^ 0016: b 30.6779 58.2976 m 57.3515 84.0277 x b 137.988 136.638 m 137.988 165.059 x ^ 0017: b 57.3515 84.0277 m 118.028 133.945 x b 137.988 165.059 m 137.988 193.479 x ^ 0018: b 189.158 76.8613 m 181.972 165.917 x b 194.829 148.65 m 194.829 177.071 x ^ 0019: b 181.972 165.917 m 171.837 160.85 x b 137.988 193.479 m 166.408 185.275 x ^ 0020: b 171.837 160.85 m 161.703 155.782 x b 166.408 185.275 m 194.829 177.071 x ^
[Bug other/107159] New: x86_64-elf freestanding target should by default build -mno-red-zone and -m32 multi-lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107159 Bug ID: 107159 Summary: x86_64-elf freestanding target should by default build -mno-red-zone and -m32 multi-lib Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- This wiki says x86_64-elf needs no red zone multilibs for writing the operating system kernel. I suggest adding -m32 and -mno-red-zone multilibs. https://wiki.osdev.org/Libgcc_without_red_zone
[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 --- Comment #22 from Steve Kargl --- On Tue, Oct 04, 2022 at 09:20:33PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 > > --- Comment #21 from anlauf at gcc dot gnu.org --- > Submitted: https://gcc.gnu.org/pipermail/fortran/2022-October/058280.html > Thanks Harald! In looking at the patch, there is a gcc_assert (op1->ts.type != BT_UNKNOWN); in reduce_binary_ac() near line 1334 and gcc_assert (op2->ts.type != BT_UNKNOWN); in reduce_binary_ca() near line 1386 that I think can go away.
[Bug c++/107085] __reference_constructs_from_temporary does not detect static up-cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107085
--- Comment #10 from Marek Polacek ---
Even more simplified:
struct X {
virtual void f();
};
struct Z : X {};
constexpr X x = X(Z());
I guess we shouldn't try to force_elide X::X(X&&) here because X is a
potentially-overlapping subobject.
[Bug libgcc/104833] disable-threads don't work for x86_64-linux-gnu target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104833 cqwrteur changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from cqwrteur --- sometimes it is right sometimes it is not
[Bug libstdc++/107139] Time to remove #if _GLIBCXX_HOSTED guard for coroutine for freestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107139 cqwrteur changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from cqwrteur --- Jwakely has fixed that
[Bug analyzer/107158] internal compiler error: in get_or_create_cluster, at analyzer/store.cc:2832
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107158 --- Comment #1 from urs at akk dot org --- Created attachment 53668 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53668=edit internal compiler error: in get_or_create_cluster, at analyzer/store.cc:2832
[Bug analyzer/107158] New: internal compiler error: in get_or_create_cluster, at analyzer/store.cc:2832
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107158 Bug ID: 107158 Summary: internal compiler error: in get_or_create_cluster, at analyzer/store.cc:2832 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: urs at akk dot org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Build: x86_64-pc-linux-gnu gcc build from git @ 49192c41de94b2746cd33366134b6aeaefa6ca2a with configure --program-suffix=-13 --enable-languages=c,lto --enable-lto --disable-multilib make -j 4 BOOT_CFLAGS='-pipe -O0 -w' bootstrap on x86_64-pc-linux-gnu (Intel(R) Core(TM) i7-6700T); Ubuntu 22.04.1 LTS; GLIBC 2.35-0ubuntu3.1 gcc-13 -v -save-temps -freport-bug -I. -I../include -DHAVE_CONFIG_H -g -std=c11 -O2 -Wextra -Wpedantic -Wall -Winline -Wshadow -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wbad-function-cast -Wnested-externs -Wcast-align -Wpointer-arith -Waggregate-return -Wcast-qual -Wwrite-strings -Wundef -Wpacked -Wfloat-equal -Wunused-macros -Wold-style-definition -Winit-self -Wmissing-include-dirs -Wlogical-op -Wjump-misses-init -Wformat=2 -Wshift-overflow=2 -Wnull-dereference -Wduplicated-cond -Walloc-zero -Walloca -Wstringop-overflow=2 -Wduplicated-branches -Wno-format-nonliteral -Wno-stringop-truncation -Wno-format-truncation -fanalyzer -Wno-analyzer-fd-use-without-check -fanalyzer-call-summaries -o makecfg ./makecfg.c results in during IPA pass: analyzer ./makecfg.c: In function ‘parse_tbl’: ./makecfg.c:140:25: internal compiler error: in get_or_create_cluster, at analyzer/store.cc:2832 140 | store_data(buffer, ""); | ^~ 0x7f3d31181d8f __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 0x7f3d31181e3f __libc_start_main_impl ../csu/libc-start.c:392 without "-fanalyzer-call-summaries" it works as expected, but "complains": /makecfg.c: In function ‘parse_tbl’: ./makecfg.c:116:1: warning: leak of ‘’ [CWE-401] [-Wanalyzer-malloc-lea k] 116 | } [...]
[Bug c++/107085] __reference_constructs_from_temporary does not detect static up-cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107085
--- Comment #9 from Marek Polacek ---
A distilled test that ICEs with the patch:
struct X {
virtual void f();
};
struct Z : X {};
constexpr auto x = sizeof((X(Z(;
s.C:5:33: internal compiler error: in build_over_call, at cp/call.cc:9987
5 | constexpr auto x = sizeof((X(Z(;
| ^
0xb54c2a build_over_call
/home/mpolacek/src/gcc/gcc/cp/call.cc:9987
[Bug c++/89997] Garbled expression in error message with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89997 --- Comment #6 from Mathias Stearn --- > I think this is probably not concepts-specific, and just another variant of > PR 49152. Perhaps the busted pretty printer is a general problem, but at least in this case I think the fix may be in concepts code. It looks like the error is generated at https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/gcc/cp/constraint.cc#L3300 (or the similar call 7 lines lower). Given that gcc already prints the source loc with the invalid expression, I think you can just remove the %qE to improve the diagnostic output. (I don't know the gcc codebase at all, so I could be wrong about this, I just grepped for the string "the required expression")
[Bug fortran/107157] New: Weird out-of-bounds error with multiple move_alloc's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107157
Bug ID: 107157
Summary: Weird out-of-bounds error with multiple move_alloc's
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.perini at gmail dot com
Target Milestone: ---
I'm in trouble reducing this problem to a minimum viable example, so I'm asking
for help - I have a nested derived type that contains allocatable components,
like:
type :: string
character(len=1), allocatable :: t(:)
end type string
type :: data_point
type(string) :: name
real(real64), allocatable :: data(:)
end type data_point
type :: data_set
type(data_point), allocatable :: data(:)
end type data_set
Now, I read in type(data_set) from several input files, and I grow that using a
move_alloc, this way:
subroutine read_dataset(this,fileName)
class(data_set), intent(inout) :: this
character(*), intent(in) :: fileName
type(data_point), allocatable :: tmp(:)
type(data_point) :: this_file
[...]
read_data: do
n = n+1
! Read one
call this_file%read(blabla)
! Extend & copy
allocate(tmp(n))
if (n>1) tmp(1:n-1) = this%data(1:n-1)
tmp(n) = this_file
call move_alloc(from=tmp,to=this%data)
end do read_data
end subroutine
Starting from n>=2, after the routine exits, I have this error:
```
Fortran runtime error: Index '1' of dimension 1 of array '_F.DA0' outside of
expected range (0:0)
```
- the error points to the end line of the module ("end module blabla")
- I have no structures with that '_F.DA0' name, nor I can find anything like
that in a text search in the .mod file (after unzipping it)
- No error if move_alloc is called at most once
I would like to reduce the problem to a simpler case I can post but I haven't
been able to reproduce this so I'm asking for help:
is there any compiler flags I can turn on to produce more output and/or
understand better what's going on?
Thank you in advance,
Federico
[Bug c++/89997] Garbled expression in error message with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89997 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=49152 --- Comment #5 from Jonathan Wakely --- I think this is probably not concepts-specific, and just another variant of PR 49152.
[Bug c++/89997] Garbled expression in error message with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89997 Jonathan Wakely changed: What|Removed |Added Resolution|WORKSFORME |--- Ever confirmed|0 |1 Status|RESOLVED|NEW Last reconfirmed||2022-10-05 --- Comment #4 from Jonathan Wakely --- N.B. the reporter can reopen the bug themselves (which is sometimes annoying :-)
[Bug c/107156] ICE in lookup_attribute_by_prefix, at attribs.h:239 since r13-2976-g3a3516bc4a0a0307
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107156 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Martin Liška --- Fixed.
[Bug c/107156] ICE in lookup_attribute_by_prefix, at attribs.h:239 since r13-2976-g3a3516bc4a0a0307
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107156 --- Comment #4 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:0afa9dfb8fb3302db7f104add5654436927dcb56 commit r13-3088-g0afa9dfb8fb3302db7f104add5654436927dcb56 Author: Martin Liska Date: Wed Oct 5 12:34:30 2022 +0200 c: support the attribute starting with '_' PR c/107156 gcc/ChangeLog: * attribs.h (lookup_attribute_by_prefix): Support the attribute starting with underscore (_Noreturn).
[Bug c++/89997] Garbled expression in error message with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89997
--- Comment #3 from Mathias Stearn ---
Please reopen. It still seems to be broken with -std=c++20 as the only flag:
https://godbolt.org/z/bWMq4s6xb (trunk) https://godbolt.org/z/W3xWjWaGe (12.2)
Output:
: In function 'void test()':
:16:15: error: no matching function for call to 'check()'
16 | check(); // mangled error
| ~~^~
:12:6: note: candidate: 'template void check() requires
requires(X x, T val) {x.X::operator<<(const char*)("hello") << val;}'
12 | void check() requires requires (X x, T val) { x << "hello" << val; } {}
| ^
:12:6: note: template argument deduction/substitution failed:
:12:6: note: constraints not satisfied
: In substitution of 'template void check() requires
requires(X x, T val) {x.X::operator<<(const char*)("hello") << val;} [with T =
int]':
:16:15: required from here
:12:6: required by the constraints of 'template void check()
requires requires(X x, T val) {x.X::operator<<(const char*)("hello") << val;}'
:12:23: in requirements with 'X x', 'T val' [with T = int]
:12:60: note: the required expression '("hello"->x.X::operator<<() <<
val)' is invalid
12 | void check() requires requires (X x, T val) { x << "hello" << val; } {}
| ~^~
cc1plus: note: set '-fconcepts-diagnostics-depth=' to at least 2 for more
detail
Compiler returned: 1
The last line with still says "the required expression
'("hello"->x.X::operator<<() << val)' is invalid". It should not be trying to
apply -> to a string literal. The following line with carrot and underline is
very helpful and shows what the problem is. But the "note" line seems actively
harmful since it is showing an expression that would never be valid for any
type. It seems like it would be better to remove that line than attempting to
show it if you can't reproduce the correct expression.
[Bug tree-optimization/107052] Range of __builtin_popcount can be improved with nonzerobits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107052 --- Comment #6 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:ae56d600d223e996054483d7d7033ec8e258d39d commit r13-3085-gae56d600d223e996054483d7d7033ec8e258d39d Author: Aldy Hernandez Date: Tue Oct 4 17:03:54 2022 +0200 [PR tree-optimization/107052] range-ops: Pass nonzero masks through cast. Track nonzero masks through a cast in range-ops. PR tree-optimization/107052 gcc/ChangeLog: * range-op.cc (operator_cast::fold_range): Set nonzero mask.
[Bug tree-optimization/107052] Range of __builtin_popcount can be improved with nonzerobits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107052 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Aldy Hernandez --- fixed
[Bug tree-optimization/107052] Range of __builtin_popcount can be improved with nonzerobits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107052 --- Comment #7 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:4c451631f722c9939260a5c2fc209802a47e525f commit r13-3086-g4c451631f722c9939260a5c2fc209802a47e525f Author: Aldy Hernandez Date: Tue Oct 4 17:05:10 2022 +0200 [PR tree-optimization/107052] range-ops: Take into account nonzero mask in popcount. PR tree-optimization/107052 gcc/ChangeLog: * gimple-range-op.cc (cfn_popcount::fold_range): Take into account nonzero bit mask.
[Bug target/107076] ICE in gen_untyped_call, at config/i386/i386.md:15992
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107076 Martin Liška changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #2 from Martin Liška --- Crashes here: 15992 for (i = 0; i < XVECLEN (operands[2], 0); i++) (gdb) pp operands[2] (parallel []) Anyway, leaving for now as __builtin_apply is likely quite a rare construct..
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 106698, which changed state. Bug 106698 Summary: bogus -Wstringop-overflow warning on Ada code with LTO https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106698 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/106698] bogus -Wstringop-overflow warning on Ada code with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106698 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |13.0 Resolution|--- |FIXED --- Comment #4 from Eric Botcazou --- Fixed on the mainline.
[Bug c/107156] ICE in lookup_attribute_by_prefix, at attribs.h:239 since r13-2976-g3a3516bc4a0a0307
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107156 Martin Liška changed: What|Removed |Added Target Milestone|--- |13.0
[Bug tree-optimization/106698] bogus -Wstringop-overflow warning on Ada code with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106698 --- Comment #3 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:853ce8eea4ff97850a987167e603387b3d0f1401 commit r13-3084-g853ce8eea4ff97850a987167e603387b3d0f1401 Author: Eric Botcazou Date: Wed Oct 5 12:21:03 2022 +0200 Fix bogus -Wstringop-overflow warning in Ada It comes from a discrepancy between get_offset_range, which uses a signed type, and handle_array_ref, which uses an unsigned one, to do computations. gcc/ PR tree-optimization/106698 * pointer-query.cc (handle_array_ref): Fix handling of low bound. gcc/testsuite/ * gnat.dg/lto26.adb: New test. * gnat.dg/lto26_pkg1.ads, gnat.dg/lto26_pkg1.adb: New helper. * gnat.dg/lto26_pkg2.ads, gnat.dg/lto26_pkg2.adb: Likewise.
[Bug c/107156] ICE in lookup_attribute_by_prefix, at attribs.h:239 since r13-2976-g3a3516bc4a0a0307
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107156 Martin Liška changed: What|Removed |Added Keywords||patch --- Comment #3 from Martin Liška --- Patch candidate: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602860.html
[Bug c/107156] ice in lookup_attribute_by_prefix, at attribs.h:239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107156 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-10-05 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started with r13-2976-g3a3516bc4a0a0307, anyway, I'm going to fix it as it comes from IPA ICF pass.
[Bug target/107155] ppc_intrinsics is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107155 --- Comment #3 from Iain Sandoe --- The discussion in the duplicate issue revolves around whether the header in the sources was suitable (i.e. for something != cell). The Apple header (which presumably does not have these contraints, since it was deployed with Apple GCC-4.x) was committed to the Apple branch on the FSF server. my understanding of the rules (we have used this policy before) is that any sources actually committed to an FSF server are considered to be contributed - so that we could forward-port that header. It's a question of finding some time to fish it out and adjust the install to add it and test .. (I have other GCC items much higher on the TODO).
[Bug tree-optimization/106679] [13 regression] gcc.dg/tree-prof/cmpsf-1.c fails after r13-2098-g5adfb6540db95d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106679 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED CC||marxin at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #7 from Martin Liška --- Marked as xfailing.
[Bug tree-optimization/106679] [13 regression] gcc.dg/tree-prof/cmpsf-1.c fails after r13-2098-g5adfb6540db95d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106679 --- Comment #6 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:233c966dba5012938a1f84e14c26b52d507b2aae commit r13-3082-g233c966dba5012938a1f84e14c26b52d507b2aae Author: Martin Liska Date: Wed Oct 5 12:14:40 2022 +0200 testsuite: mark a test with xfail PR tree-optimization/106679 gcc/testsuite/ChangeLog: * gcc.dg/tree-prof/cmpsf-1.c: Mark as a known limitation.
[Bug tree-optimization/106698] `-O2 -flto` cause linker warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106698 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org
[Bug tree-optimization/106698] `-O2 -flto` cause linker warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106698 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-10-05 Ever confirmed|0 |1 --- Comment #2 from Eric Botcazou --- > I suspect the diagnostic code does not handle negative lower bounds arrays > correctly. Yes, see https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599820.html
[Bug c/107156] ice in lookup_attribute_by_prefix, at attribs.h:239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107156 David Binderman changed: What|Removed |Added CC||joseph at codesourcery dot com --- Comment #1 from David Binderman --- Looking at the list of commits, I add the author of the code.
[Bug c/107156] New: ice in lookup_attribute_by_prefix, at attribs.h:239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107156 Bug ID: 107156 Summary: ice in lookup_attribute_by_prefix, at attribs.h:239 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: --- For testsuite file ./gcc.dg/c2x-attr-noreturn-1.c, with recent gcc, I get this: [/home/dcb/gcc/trunk.git/gcc/testsuite] $ /home/dcb/gcc/results/bin/gcc -c -w -O2 ./gcc.dg/c2x-attr-noreturn-1.c during IPA pass: icf ./gcc.dg/c2x-attr-noreturn-1.c:56:1: internal compiler error: in lookup_attribute_by_prefix, at attribs.h:239 56 | [[noreturn]] int main (); | ^ 0x1bd9afe lookup_attribute_by_prefix(char const*, tree_node*) ../../trunk.git/gcc/attribs.h:239 Please not I am not using any -std= flag. The bug first seems to occur sometime between git hash f758d447d7f46992 and 43faf3e5445b5717, which is about 50 commits.
[Bug c++/107151] Specializing a concepted template can emit bogus assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107151 --- Comment #2 from Jonathan Wakely --- I think this is PR 100825
[Bug c++/89997] Garbled expression in error message with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89997 Jonathan Wakely changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #1) > Is this good enoug now? I'm going to assume the answer's yes.
[Bug c++/107151] Specializing a concepted template can emit bogus assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107151 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-10-05 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Note clang rejects the code: clang++ pr107151.C -c -std=c++20 -S pr107151.C:14:6: error: definition with same mangled name '_Z3funIcEvT_' as another definition void fun(I i) ^ pr107151.C:8:6: note: previous definition is here void fun(char c) ^ 1 error generated.
Xingwu Factory
Dear customer My name is Liu Qi. nice to meet you. Xingwu Factory is a foundry from Hebei Province, China, with a history of 28 years. The company produces nodular cast iron and gray cast iron, and has three 2-ton electric furnaces with an annual output of 2 tons of castings. Our factory mainly produces cast iron well covers and pipe fittings. Our customers are from China, Europe and Canada. The factory has three fully automatic production lines, a complete laboratory, a CNC machining center and a complete technical team. The factory has a long history of cooperation with Canadian customers and is familiar with the technical requirements of some provinces and cities. We hope to communicate and cooperate with you. We look forward to your reply
Xingwu Factory
Dear customer My name is Liu Qi. nice to meet you. Xingwu Factory is a foundry from Hebei Province, China, with a history of 28 years. The company produces nodular cast iron and gray cast iron, and has three 2-ton electric furnaces with an annual output of 2 tons of castings. Our factory mainly produces cast iron well covers and pipe fittings. Our customers are from China, Europe and Canada. The factory has three fully automatic production lines, a complete laboratory, a CNC machining center and a complete technical team. The factory has a long history of cooperation with Canadian customers and is familiar with the technical requirements of some provinces and cities. We hope to communicate and cooperate with you. We look forward to your reply.
[Bug c++/107085] __reference_constructs_from_temporary does not detect static up-cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107085 --- Comment #8 from Jonathan Wakely --- (In reply to Marek Polacek from comment #6) > where we bind 'b' to the Base subobject of a temporary Derived object, yes? Yes, exactly right.
