[Bug other/98375] [meta bug] GCC 12 pending patches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98375 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Andrew Pinski --- Stage1 is over so closing as fixed.
[Bug middle-end/98525] potential error in expand_call_inline error handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98525 --- Comment #1 from Andrew Pinski --- successfully_inlined = expand_call_inline (bb, stmt, id, to_purge); maybe_remove_unused_call_args (cfun, stmt); /* This used to return true even though we do fail to inline in some cases. See PR98525. */ goto egress; Since it is not so obvious from reading the code and even reading this bug report (but it was clear from the mailing list), the suggestion was to add an assert that successfully_inlined was true and the failures in comment #0 happen when the assert is added in the above code.
[Bug middle-end/98548] missing warning on strcmp with a nonstring member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98548 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Known to fail||11.2.0 Known to work||12.0 --- Comment #1 from Andrew Pinski --- Looks fixed on the trunk: : In function 'f': :11:15: warning: '__builtin_strcmp' argument 1 declared attribute 'nonstring' is smaller than the specified bound 8 [-Wstringop-overread] 11 | return 0 == __builtin_strcmp (a.a, a.b); // warning (good) | ^~~ :4:8: note: argument 'a' declared here 4 | char a[4] __attribute__ ((nonstring)); |^ : In function 'g': :16:15: warning: '__builtin_strcmp' argument 1 declared attribute 'nonstring' is smaller than the specified bound 8 [-Wstringop-overread] 16 | return 0 == __builtin_strcmp (p->a, p->b); // missing warning | ^ :4:8: note: argument 'a' declared here 4 | char a[4] __attribute__ ((nonstring)); |^
[Bug tree-optimization/69289] Compiling without --profile-generate causes longer execution time (-O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69289 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Known to work||11.2.0, 12.0 Component|middle-end |tree-optimization Known to fail||7.1.0, 8.1.0 --- Comment #6 from Andrew Pinski --- Looks to be fixed in GCC 11.2.0 and GCC 12+. That is the memset is detected and transformed.
[Bug c++/89870] C++ suggest header for abort()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89870 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Depends on||101052 Status|NEW |RESOLVED Target Milestone|--- |12.0 --- Comment #4 from Andrew Pinski --- Since r12-1435-g93bfadf3a1db (PR101052): : In function 'int main()': :4:5: error: 'abort' was not declared in this scope 4 | abort(); | ^ :1:1: note: 'abort' is defined in header ''; did you forget to '#include '? +++ |+#include 1 | So fixed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101052 [Bug 101052] Suggest stdlib.h when exit(1) is called
[Bug c++/89055] wrong location with macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89055 Andrew Pinski changed: What|Removed |Added Summary|wrong location with |wrong location with macros |predefined macros | --- Comment #2 from Andrew Pinski --- In this case it is just the macro in general, not really the predefined one that makes a difference: #define S_MAX (18446744073709551615UL) char a[~0LU << 1]; char b0[S_MAX << 1]; char b[__SIZE_MAX__ << 1]; CUT :2:13: error: size '18446744073709551614' of array 'a' exceeds maximum object size '9223372036854775807' 2 | char a[~0LU << 1]; |~^~~~ :3:15: error: size '18446744073709551614' of array 'b0' exceeds maximum object size '9223372036854775807' 3 | char b0[S_MAX << 1]; | ^ :4:21: error: size '18446744073709551614' of array 'b' exceeds maximum object size '9223372036854775807' 4 | char b[__SIZE_MAX__ << 1]; | ^
[Bug c++/103659] Declared function template can be deleted later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103659 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > Dup of bug 90703. The only reason I knew there was a dup is because I just saw it today when I was going through the C++ bug reports. So I was not doing any magical memory since it was only from today.
[Bug c++/90703] `=delete` accepted on a second declaration of the same function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90703 Andrew Pinski changed: What|Removed |Added CC||fchelnokov at gmail dot com --- Comment #2 from Andrew Pinski --- *** Bug 103659 has been marked as a duplicate of this bug. ***
[Bug c++/103659] Declared function template can be deleted later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103659 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 90703. *** This bug has been marked as a duplicate of bug 90703 ***
[Bug c++/103659] New: Declared function template can be deleted later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103659 Bug ID: 103659 Summary: Declared function template can be deleted later Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: fchelnokov at gmail dot com Target Milestone: --- This code ``` template int foo(T); template int foo(int); template int foo(T) = delete; ``` is currently accepted by GCC, but it must not by at least two reasons: * explicit instantiation of undefined function; * deletion of already declared function. Demo: https://gcc.godbolt.org/z/EW8fvba5f
[Bug c++/87429] Strange overload resolution with decltype in template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87429 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=85493 Blocks||54366 Known to work||11.1.0 Known to fail||10.3.0 --- Comment #2 from Andrew Pinski --- Seems fixed in GCC 11+. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54366 [Bug 54366] [meta-bug] decltype issues
[Bug c++/85493] decltype can use deleted constructor and deleted template function in template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85493 Andrew Pinski changed: What|Removed |Added Known to fail||10.1.0, 10.3.0, 7.2.0 Known to work||11.1.0, 12.0 Keywords||needs-bisection Blocks||54366 --- Comment #3 from Andrew Pinski --- The testcase in comment #0 seems to be fixed in GCC 11+. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54366 [Bug 54366] [meta-bug] decltype issues
[Bug c++/86697] decltype for lambda capture gives wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86697 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||wrong-code Last reconfirmed||2021-12-11 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug c++/81202] Concept parsing error for default template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81202
--- Comment #2 from Andrew Pinski ---
Full testcase:
#include
#include
template constexpr bool
IsPtrC=std::is_pointer_v&&(std::is_same_v
||std::is_same_v>);
template concept IsPtrC2=IsPtrC;
template using TEST=int;
int main(int argc,char*argv[]){
TEST> i;//OK
TEST> j;//error: parse error in template argument list
TEST> k;//OK
TEST<(IsPtrC2)> l;//OK
}
With -std=c++20 the above code works (as expected) but with -std=c++17
-fconcepts it fails (with GCC 10+).
I will let a C++ maintainer to decide if it should work with -std=c++17
-fconcepts or not.
The error message is:
: In function 'int main(int, char**)':
:10:19: error: type/value mismatch at argument 1 in template parameter
list for 'template using TEST = int'
10 | TEST> j;//error: parse error in template argument list
| ^~
:10:19: note: expected a constant of type 'bool', got 'auto [requires
IsPtrC2<, int>]'
Compiler returned: 1
[Bug c++/103534] [12 regression] Spurious -Wstringop-overflow warning with std::string concatencation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103534 --- Comment #10 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2e8067041d1d69da02bd7578f58abc11eb35a04b commit r12-5906-g2e8067041d1d69da02bd7578f58abc11eb35a04b Author: Jason Merrill Date: Fri Dec 10 11:21:50 2021 -0500 libstdc++: check length in string append [PR103534] In the testcase for 103534 we get a warning about append leading to memcpy of a very large number of bytes overflowing the buffer. This turns out to be because we weren't calling _M_check_length for string append. Rather than do that directly, let's go through the public pointer append that calls it. PR c++/103534 libstdc++-v3/ChangeLog: * include/bits/basic_string.h (append (basic_string)): Call pointer append instead of _M_append directly. gcc/testsuite/ChangeLog: * g++.dg/warn/Wstringop-overflow-8.C: New test.
[Bug c++/91622] Compiler internal error DJGPP GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91622 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- No attachment provided in over 2 years so closing as invalid.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 68858, which changed state. Bug 68858 Summary: Cannot use fold expression in requirements with two parameters packs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68858 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/68858] Cannot use fold expression in requirements with two parameters packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68858 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #3 from Andrew Pinski --- Fixed so closing.
[Bug c++/61726] Ambiguous overload resolution with inherited op()s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61726 Andrew Pinski changed: What|Removed |Added Blocks||12944 --- Comment #3 from Andrew Pinski --- ICC and GCC rejects this code while clang and MSVC accept it. If we change it to a normal function rather than an operator, then all 4 compilers reject it as ambiguous. Are operators handled differently here for namelookup? Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12944 [Bug 12944] [meta-bug] C++ name-lookup problems
[Bug c++/78722] noexcept and function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78722 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |7.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Andrew Pinski --- Fixed in GCC 7 by r7-4383-g51dc660315ef83d.
[Bug analyzer/101962] Analyzer NULL false positive with pointer manipulation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101962 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from David Malcolm --- Backported to gcc 11 by the above commit. I don't plan to backport to gcc 10; marking this as resolved.
[Bug jit/103562] Jitted code produces incorrect result when returning 3-member struct from internal function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103562 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by David Malcolm : https://gcc.gnu.org/g:1250dcee74985eaeacae3b85e5ec78937225d322 commit r11-9375-g1250dcee74985eaeacae3b85e5ec78937225d322 Author: David Malcolm Date: Fri Dec 10 09:28:48 2021 -0500 jit: set DECL_CONTEXT of RESULT_DECL [PR103562] libgccjit was failing to set the DECL_CONTEXT of function RESULT_DECLs, leading to them failing to be properly handled by the inlining machinery. Fixed thusly. gcc/jit/ChangeLog: PR jit/103562 * jit-playback.c (gcc::jit::playback::context::new_function): Set DECL_CONTEXT of the result_decl. gcc/testsuite/ChangeLog: PR jit/103562 * jit.dg/all-non-failing-tests.h: Add comment about... * jit.dg/test-pr103562.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/101962] Analyzer NULL false positive with pointer manipulation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101962 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by David Malcolm : https://gcc.gnu.org/g:de0656f98640a57cd9dfdb090264afaa06ba46cc commit r11-9374-gde0656f98640a57cd9dfdb090264afaa06ba46cc Author: David Malcolm Date: Mon Aug 23 14:07:39 2021 -0400 analyzer: assume that POINTER_PLUS_EXPR of non-NULL is non-NULL [PR101962] Backported from commit r12-3094-ge82e0f149b0aba660896ea9aa12c442c07a16d12, dropping the expected "use of uninitialized value" warning from pr101962.c gcc/analyzer/ChangeLog: PR analyzer/101962 * region-model.cc (region_model::eval_condition_without_cm): Refactor comparison against zero, adding a check for POINTER_PLUS_EXPR of non-NULL. gcc/testsuite/ChangeLog: PR analyzer/101962 * gcc.dg/analyzer/data-model-23.c: New test. * gcc.dg/analyzer/pr101962.c: New test. Signed-off-by: David Malcolm
[Bug middle-end/103614] Modulo equality optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103614 --- Comment #1 from getchar_gnu at hotmail dot com --- Not sure if related, but something like x%13==8 && x>17 && x<146 can also reduce some code
[Bug c++/96207] GCC accepts "delete" function definition inside a class member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96207 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-12-11 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/86430] ambiguous overload?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86430 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Known to fail||10.1.0, 10.3.0 Known to work||11.1.0, 12.0 --- Comment #2 from Andrew Pinski --- Seems fixed in GCC 11+.
[Bug c++/90529] suggest struct or class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90529 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2019-05-20 00:00:00 |2021-12-10 Severity|normal |enhancement
[Bug c++/70077] noexcept, inheriting constructors and the invalid use of an incomplete type that is actually complete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70077 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #6 from Andrew Pinski --- Seems to be fixed for GCC 10.
[Bug c++/82171] Cant use std::declval in concept testing map operator[]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82171 Andrew Pinski changed: What|Removed |Added Known to fail||11.1.0 Known to work||11.2.0, 12.0 Keywords||ice-on-valid-code --- Comment #5 from Andrew Pinski --- Starting with GCC 10.1.0, GCC would ICE also. The ICE was resolved in GCC 11.2.0 and on the trunk and GCC starts to accept the code at that point.
[Bug c++/89367] Constexpr expression is not constexpr in template, but is constexpr in non-template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89367 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=94716 --- Comment #8 from Andrew Pinski --- Very similar to PR 94716. The original code in comment #0 might be solved by https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586553.html (when it gets approved/applied). (In reply to Frank Secilia from comment #4) > Created attachment 45743 [details] > alternative repro case using pointers to method There is another bug recording pointer to method function comparisons too.
[Bug c++/97077] Missed loop unrolling with range for over initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97077 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2020-09-17 00:00:00 |2021-12-10 --- Comment #3 from Andrew Pinski --- Maybe we need to realize the induction variable __for_begin is constant memory so the read from it will be optimized away. That might help.
[Bug c++/87680] Small program produces 160 meg .o file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87680 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=92385 --- Comment #6 from Andrew Pinski --- Also very similar to PR 92385.
[Bug middle-end/103483] context-sensitive ranges change triggers stringop-overread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483
--- Comment #13 from Martin Sebor ---
The warning for the test case in comment #12 isn't directly related to ranges:
it's issued simply because the invalid statement is in the IL and not
eliminated by DCE (the secret functions don't let it). Similar warnings have
been issued in equivalent situations for constants propagated through inlining.
Here's one for -Wnonnull (issued since GCC 7):
char *sink;
__attribute__ ((noinline, noipa)) int
null_safe_strlen (const char *p) { return p ?__builtin_strlen (p) : 0; }
static inline void copy (const char *p)
{
int N = null_safe_strlen (p);
if (N) /* disabling this branch prevents the warning */
__builtin_memcpy (sink, p, N);
else
*sink = 0;
}
void f()
{
copy (0); // bogus warning
}
In function ‘copy’,
inlined from ‘f’ at z.c:17:3:
z.c:10:5: warning: argument 2 null where non-null expected [-Wnonnull]
10 | __builtin_memcpy (sink, p, N);
| ^
z.c:10:5: note: in a call to built-in function ‘__builtin_memcpy’
All GCC warnings trigger on invalid statements in the IL, regardless of whether
the statements are in reality reachable. This includes all warnings that
consider data flow like -Wnonnull, -Warray-bounds, and -Wformat-overflow among
many others. Ranges just let them find more invalid statements than constants
alone would. This is also the most basic reason why the -Wstringop- warnings
are issued for the test case in comment #0 or in or PR 103332.
Two changes are behind the spate of recent bug reports about these warnings for
std::string: 1) in GCC 11 we enabled a subset of warnings for code inlined from
system headers, and 2) in GCC 12 thanks to Ranger the range info has become
more accurate and tighter (larger lower bounds and smaller upper bounds).
Before Jonathan suppressed the warnings in r12-5874 in libstdc++, Andrew
MacLeod suggested temporarily (for GCC 12) disabling the context-sensitive
Ranger info and going back to global ranges, until we have a better way of
dealing with the increased accuracy. That would reduce the number of false
positives but it would also correspondingly increase false negatives, and so
defeat one of the main reasons for Ranger: better quality warnings. It might
still be a compromise to consider if the problem turns out to be sufficiently
severe and if we can think of a way of to handle the ranges better in the
future. But with the libstdc++ suppression I'm not convinced the problem is
severe enough anymore. And I also can't think of a solution that would let us
re-enable Ranger for warnings in the future. Nothing I've tried so far has
showed much promise, and neither seems anything anyone has suggested.
Independently, I have been thinking about adding -Wmaybe- forms of some of
these warnings analogous to -Wmaybe-uninitialized (or corresponding levels), to
diagnose conditional problems as in:
char a[4], b[8];
void f (int i)
{
__builtin_memset (i ? a : b, 0, 7); // okay for b, overflow for a: thus
"may overflow a"
}
but I have not been considering disabling the existing warnings (or removing it
from -Wall) and issuing them only under the new option or some new level. That
would in my mind be a drastic step back.
[Bug inline-asm/98096] Inconsistent operand numbering for asm goto with in-out operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98096 --- Comment #6 from Andrew Pinski --- (In reply to Nick Desaulniers from comment #5) > Was it ever consider that the behavior should be changed, rather than > documented? Seems like changing an already documented and released feature seems wrong. Gcc 11 was released back in April. Clang never documented this feature as far as I can tell. Plus it would be very inconsistent with the way the inout feature was handled without asm goto. That is all input constraints are grouped together, having the asm goto label in between the inputs seems wrong.
[Bug inline-asm/98096] Inconsistent operand numbering for asm goto with in-out operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98096 --- Comment #5 from Nick Desaulniers --- While the changes to gcc/stmt.c and the second asm goto statement in gcc/testsuite/gcc.c-torture/compile/pr98096.c in https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=72d78655a91bb2f89ac4432cfd6374380d6f9987 LGTM (they fix an actual bug with symbolic references), the changes to gcc/doc/extend.texi and the first asm goto statement in gcc/testsuite/gcc.c-torture/compile/pr98096.c seemed to have conflated the label bug with documenting curious behavior. Was it ever consider that the behavior should be changed, rather than documented?
[Bug jit/103562] Jitted code produces incorrect result when returning 3-member struct from internal function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103562 --- Comment #7 from David Malcolm --- Should be fixed by the above commit on trunk for gcc 12. Probably should backport this; keeping this open until that's done.
[Bug jit/103562] Jitted code produces incorrect result when returning 3-member struct from internal function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103562 --- Comment #6 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:a2f4b4b76cdd0a4150e82e69fae4a70c54b523d2 commit r12-5903-ga2f4b4b76cdd0a4150e82e69fae4a70c54b523d2 Author: David Malcolm Date: Fri Dec 10 09:28:48 2021 -0500 jit: set DECL_CONTEXT of RESULT_DECL [PR103562] libgccjit was failing to set the DECL_CONTEXT of function RESULT_DECLs, leading to them failing to be properly handled by the inlining machinery. Fixed thusly. gcc/jit/ChangeLog: PR jit/103562 * jit-playback.c (gcc::jit::playback::context::new_function): Set DECL_CONTEXT of the result_decl. gcc/testsuite/ChangeLog: PR jit/103562 * jit.dg/all-non-failing-tests.h: Add comment about... * jit.dg/test-pr103562.c: New test. Signed-off-by: David Malcolm
[Bug c++/79493] Bad diagnostic when referring to inner type that does not exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79493 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Known to work||12.0 --- Comment #2 from Andrew Pinski --- This seems to be fixed on the trunk: :3:10: error: 'A::nonexistent' has not been declared 3 | void f(A::nonexistent param); | ^ :4:11: error: 'A::nonexistent' has not been declared 4 | void* g(A::nonexistent param); | ^
[Bug c++/88493] Inconsistent error messages for unknown types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88493 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Severity|normal |enhancement Last reconfirmed||2021-12-10 --- Comment #1 from Andrew Pinski --- Confirmed, it looks like constructors don't get the same treatment as normal method functions when it comes to undefined types.
[Bug c++/88118] GCC keeps unnecessary calls to new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88118 --- Comment #8 from Andrew Pinski --- (In reply to Andrew Pinski from comment #7) > Fixed in GCC 10 by r10-2105-gcb50701ec2c7a (I found a slight missed > optimization but I will file that as a seperate issue). The slight missed optimization is due to main being marked as called only once so it is not really a missed one so I am not going to file it.
[Bug c++/88118] GCC keeps unnecessary calls to new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88118 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Known to fail||8.1.0, 9.1.0 Target Milestone|--- |10.0 --- Comment #7 from Andrew Pinski --- Fixed in GCC 10 by r10-2105-gcb50701ec2c7a (I found a slight missed optimization but I will file that as a seperate issue).
[Bug tree-optimization/102958] std::u8string suboptimal compared to std::string, triggers warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102958 --- Comment #5 from Jason Merrill --- Let's focus on the missed-optimization issues in this PR, and address the broader diagnostic issues in PR 103483.
[Bug middle-end/103483] context-sensitive ranges change triggers stringop-overread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=102958
--- Comment #12 from Jason Merrill ---
(In reply to Martin Sebor from comment #3)
> GCC 11 doesn't warn because it's unable to determine the range of the last
> memcpy() argument. Thanks to the Ranger improvements GCC 12 is able to do
> better. In some cases this should improve the S/N ratio of the middle end
> diagnostics that depend on ranges. Unfortunately, in others like this one
> where other optimizations are disabled it can make things worse.
It seems to me that if we don't warn when we have no information about the
range of the argument, we also shouldn't warn when we have only path-dependent
information about the range of the argument.
The testcase in comment #0 is definitely dubious for using an unbounded int d
to index into a bounded array, so let's consider a more reasonable C testcase
derived from PR102958 for which there is no missed-optimization issue.
char *sink;
/* Definitions unavailable to optimization. */
int secret_strlen (const char *p);
void secret_memcpy (char *, const char *, int);
inline void copy(const char *p)
{
int L = secret_strlen (p);
if (L < 16) /* disabling this branch prevents the warning */
secret_memcpy (sink, p, L);
else
__builtin_memcpy (sink, p, L);
}
void f()
{
copy ("12"); // bogus warning
}
At the __builtin_memcpy we have a constant string "12" and an unknown length L,
and we try to copy L bytes of the constant string into a buffer. We do this in
different ways depending on whether L is less than 16; on the latter path we
__builtin_memcpy L bytes from the constant string into the buffer.
And so -Wstringop-overread warns that we're reading 16 or more bytes from a
3-byte string.
But we still have no basis for concluding that L is actually >= 16, we don't
know its value at all. That this path is only taken for L >= 16 doesn't tell
us whether it's actually possible that L >= 16; we can't assume that just
because we don't know the value of len, it could therefore have any value, and
so all branches are reachable for a specific string argument.
We're able to propagate one constant value, and warning because an unknown
value might be incompatible with the known value. And with the recent changes
we're able to do more of this asymmetric constant propagation.
Perhaps it would be useful to have an optional mode for these (and other)
warnings that does assume that all branches are reachable, but it can't be the
default. -Wmaybe-stringop-overread? -Wstringop-overread=maybe?
My testcase above has given a false positive since GCC 8.
I'm nervous about people adding __builtin_unreachables to suppress these
warnings; forced assumptions can be big foot-guns.
[Bug c++/88118] GCC keeps unnecessary calls to new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88118 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement See Also||https://bugs.llvm.org/show_ ||bug.cgi?id=39731
[Bug c++/38172] warn_unused_result does not work with structs not containing a copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38172
--- Comment #16 from Andrew Pinski ---
(In reply to Martin Liška from comment #15)
> Can the bug be marked as resolved?
Not exactly with an empty struct we warn twice.
That is take:
struct MyClass{};
typedef struct MyClass MyClass;
MyClass Bar2( void ) __attribute__((warn_unused_result));
void Foo( void )
{
Bar2(); // warns twice
}
But the following only warns once:
struct MyClass{int t;};
typedef struct MyClass MyClass;
MyClass Bar2( void ) __attribute__((warn_unused_result));
void Foo( void )
{
Bar2();
}
The warning twice started with GCC 7.
[Bug fortran/103606] [9/10/11/12 Regression] ICE in resolve_fl_procedure, at fortran/resolve.c:13297 since r9-3324-g2b03b800d866d345
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103606 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2021-December/057155.html
[Bug analyzer/103658] missing -Wanalyzer-use-of-uninitialized-value at -O1 and below for an array access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103658
--- Comment #1 from Martin Sebor ---
Actually, what I was really after is trying to see if the analyzer would print
the conditionals involved in the subscript expressions. But in the simple test
case in comment #0 there are no conditionals. They are here:
int f (int i, int j)
{
int a[3];
a[0] = 1;
a[1] = 2;
if (i < 1 || 3 < i) i = 1;
if (j < 1 || 5 < j) j = 1;
return a[i + j];
}
but it doesn't print them even at -O2 when it does warn:
z.c: In function ‘f’:
z.c:9:11: warning: use of uninitialized value ‘a[]’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
9 | return a[i + j];
| ~^~~
‘f’: event 1
|
|9 | return a[i + j];
| | ~^~~
| | |
| | (1) use of uninitialized value ‘a[]’ here
|
[Bug c++/58950] Missing "statement has no effect"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950
--- Comment #26 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #25)
> (In reply to Marc Glisse from comment #6)
> > For:
> >
> > void f(){
> > int i = 2;
> > (i+i);
> > }
>
> This case is fixed on the trunk:
>
> : In function 'void f1()':
> :9:5: warning: statement has no effect [-Wunused-value]
> 9 | (i+i);
> | ~~^~~
I think it was fixed via r12-1804-g65870e75616ee4359d1c13b99 .
[Bug c++/58950] Missing "statement has no effect"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #25 from Andrew Pinski ---
(In reply to Marc Glisse from comment #6)
> For:
>
> void f(){
> int i = 2;
> (i+i);
> }
This case is fixed on the trunk:
: In function 'void f1()':
:9:5: warning: statement has no effect [-Wunused-value]
9 | (i+i);
| ~~^~~
[Bug analyzer/103658] New: missing -Wanalyzer-use-of-uninitialized-value at -O1 and below for an array access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103658
Bug ID: 103658
Summary: missing -Wanalyzer-use-of-uninitialized-value at -O1
and below for an array access
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
I came across this while comparing the middle end -Wuninitialized with
-Wanalyzer-use-of-uninitialized-value. They both trigger at -O2. At -O1, only
-Wuninitialized triggers, even though the IL looks the same between the two
levels (as far as I can tell).
$ cat z.c && gcc -O1 -S -Wall -fdump-tree-uninit=/dev/stdout -fanalyzer z.c
int f (int i, int j)
{
int a[3];
a[0] = 1;
a[1] = 2;
if (i < 1) i = 1;
if (j < 1) j = 1;
return a[i + j];
}
;; Function f (f, funcdef_no=0, decl_uid=1979, cgraph_uid=1, symbol_order=0)
z.c: In function ‘f’:
z.c:9:11: warning: ‘a’ is used uninitialized [-Wuninitialized]
9 | return a[i + j];
| ~^~~
z.c:3:7: note: ‘a’ declared here
3 | int a[3];
| ^
int f (int i, int j)
{
int a[3];
int _1;
int _6;
int _8;
int _9;
[local count: 1073741824]:
_8 = MAX_EXPR ;
_6 = MAX_EXPR ;
_1 = _6 + _8;
_9 = a[_1];
a ={v} {CLOBBER};
return _9;
}
[Bug c++/86870] Declaration disambiguation is too greedy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86870 --- Comment #2 from Andrew Pinski --- GCC, clang, MSVC and ICC all reject it.
[Bug ipa/103601] [12 Regression] ICE in insert_kill, at ipa-modref-tree.c:84 since r12-5244-g64f3e71c302b4a13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103601 Roger Sayle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Roger Sayle --- This should now be fixed on mainline.
[Bug fortran/103606] [9/10/11/12 Regression] ICE in resolve_fl_procedure, at fortran/resolve.c:13297 since r9-3324-g2b03b800d866d345
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103606
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #3 from anlauf at gcc dot gnu.org ---
Tentative semi-obvious patch:
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 0ed31970f8b..bff1b35446f 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -13294,7 +13294,8 @@ resolve_fl_procedure (gfc_symbol *sym, int mp_flag)
/* An elemental function is required to return a scalar 12.7.1 */
if (sym->attr.elemental && sym->attr.function
- && (sym->as || (sym->ts.type == BT_CLASS && CLASS_DATA (sym)->as)))
+ && (sym->as || (sym->ts.type == BT_CLASS && sym->attr.class_ok
+ && CLASS_DATA (sym)->as)))
{
gfc_error ("ELEMENTAL function %qs at %L must have a scalar "
"result", sym->name, &sym->declared_at);
[Bug c++/92053] Compilation fails or succeeds depending on the optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92053 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Last reconfirmed|2021-07-27 00:00:00 |2021-12-10 --- Comment #5 from Andrew Pinski --- On the trunk, we accept it no matter what optimization level now.
[Bug c++/78217] Duplicate decls handling with auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78217 Andrew Pinski changed: What|Removed |Added CC||lebedev.ri at gmail dot com --- Comment #5 from Andrew Pinski --- *** Bug 85932 has been marked as a duplicate of this bug. ***
[Bug c++/85932] GCC incorrectly rejects mismatch of types, instead of retrying after type deduction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85932 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 78217. *** This bug has been marked as a duplicate of bug 78217 ***
[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623 Peter Bergner changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-12-10 Status|UNCONFIRMED |ASSIGNED --- Comment #4 from Peter Bergner --- This is confirmed.
[Bug c/103645] Gimplifier does not remove empty struct stores in a few cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103645 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-12-10 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Mine.
[Bug objc/103639] [11/12 Regression] switch case with break in fast enumeration loop generates wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103639 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.3 CC||pinskia at gcc dot gnu.org
[Bug target/103657] GCC can no longer catch EH on x86_64-w64-mingw32 hosted 64 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103657 --- Comment #3 from cqwrteur --- https://sourceware.org/bugzilla/show_bug.cgi?id=28682
[Bug tree-optimization/103647] constant array comparison not always folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103647
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-12-10
Severity|normal |enhancement
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
So in fab GCC creates:
a = "ac";
b = "ab";
_8 = MEM [(char * {ref-all})&a];
_9 = MEM [(char * {ref-all})&b];
_10 = _8 != _9;
And:
a = "ab";
b = "abc";
_8 = MEM [(char * {ref-all})&a];
_9 = MEM [(char * {ref-all})&b];
_10 = _8 != _9;
But we don't have a FRE/DOM to optimize those MEM_REFs.
Confirmed.
[Bug tree-optimization/103647] constant array comparison not always folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103647 --- Comment #1 from Andrew Pinski --- well f should be optimized to return true while g should be optimized to return false.
[Bug fortran/103610] ICE in gfc_convert_mpz_to_signed, at fortran/simplify.c:193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103610 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:3459ef2e9f9cd4d3ed64c9bc44282534a24987b8 commit r11-9372-g3459ef2e9f9cd4d3ed64c9bc44282534a24987b8 Author: Harald Anlauf Date: Tue Dec 7 23:06:41 2021 +0100 Fortran: dimensions of an array have to be non-negative gcc/fortran/ChangeLog: PR fortran/103610 * array.c (spec_dimen_size): Fix simplification of SHAPE: dimensions must be non-negative. gcc/testsuite/ChangeLog: PR fortran/103610 * gfortran.dg/shape_11.f90: New test. (cherry picked from commit 5f7cdea34e118776d0ccd2ff3dda0f5acab18a94)
[Bug gcov-profile/100788] Internal compiler error related to #line macros(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100788 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.4 Known to work||10.3.1, 11.2.1
[Bug gcov-profile/100788] Internal compiler error related to #line macros(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100788 Andrew Pinski changed: What|Removed |Added CC||andre.schackier at gmail dot com --- Comment #18 from Andrew Pinski --- *** Bug 103651 has been marked as a duplicate of this bug. ***
[Bug gcov-profile/103651] Using "#Line 0" in a function with "-coverage" crashes the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103651 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 100788. *** This bug has been marked as a duplicate of bug 100788 ***
[Bug fortran/103607] [9/10/11/12 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2927
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103607 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed on all affected open branches. Closing. Thanks for the report!
[Bug target/103657] GCC can no longer catch EH on x86_64-w64-mingw32 hosted 64 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103657 --- Comment #2 from cqwrteur --- D:\hg\fast_io\tests\0017.error>g++ -o error error.cc -Ofast -std=c++2b -s -march=native -I../../include -lntdll -fuse-ld=lld D:\hg\fast_io\tests\0017.error>error errc:no_such_file_or_directory clang++ -o error error.cc -Ofast -std=c++2b -s -march=native -I../../include -lntdll D:\hg\fast_io\tests\0017.error>error Looks like it is GNU ld linker's issue. Need to report there probably.
[Bug c++/103657] GCC can no longer catch EH on x86_64-w64-mingw32 hosted 64 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103657 --- Comment #1 from cqwrteur --- D:\hg\fast_io\tests\0017.error>g++ -o error error.cc -Ofast -std=c++2b -s -flto -march=native -I../../include -lntdll D:\hg\fast_io\tests\0017.error>error D:\hg\fast_io\tests\0017.error>clang++ -o error error.cc -Ofast -std=c++2b -s -flto -march=native -I../../include -lntdll -fuse-ld=lld D:\hg\fast_io\tests\0017.error>error Hello EH
[Bug c++/103657] New: GCC can no longer throw EH on x86_64-w64-mingw32 hosted 64 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103657
Bug ID: 103657
Summary: GCC can no longer throw EH on x86_64-w64-mingw32
hosted 64 bits
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: ---
#include
int main()
try
{
throw 0;
}
catch(...)
{
puts("Hello EH\n");
return 1;
}
GCC cannot catch EH on windows anymore.
while clang and g++ -m32 all work
[Bug target/103656] make install-strip -j cannot find x86_64-w64-mingw32-strip for canadian compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103656 --- Comment #1 from cqwrteur --- rm -rf /home/cqwrteur/canadian/x86_64-w64-mingw32/libexec/gcc/x86_64-w64-mingw32/12.0.0/install-tools rm: cannot remove '/home/cqwrteur/canadian/x86_64-w64-mingw32/libexec/gcc/x86_64-w64-mingw32/12.0.0/install-tools/fixincl.exe': Permission denied
[Bug target/103656] New: make install-strip -j cannot find x86_64-w64-mingw32-strip for canadian compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103656 Bug ID: 103656 Summary: make install-strip -j cannot find x86_64-w64-mingw32-strip for canadian compilation Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- test -z 'x86_64-w64-mingw32-strip' || x86_64-w64-mingw32-strip /home/cqwrteur/canadian/x86_64-w64-mingw32/libexec/gcc/x86_64-w64-mingw32/12.0.0/install-tools/fixincl.exe /bin/bash: x86_64-w64-mingw32-strip: command not found make[1]: *** [Makefile:191: install-strip] Error 127 make[1]: Leaving directory '/home/cqwrteur/myhome/gcc_build/canadian/x86_64-w64-mingw32/gcc/fixincludes' make: *** [Makefile:4005: install-strip-fixincludes] Error 2 make: *** Waiting for unfinished jobs
[Bug fortran/103607] [9/10/11/12 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2927
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103607 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:8b1dae4d33285643c5f51d828aa6f31ffbfc33b7 commit r9-9863-g8b1dae4d33285643c5f51d828aa6f31ffbfc33b7 Author: Harald Anlauf Date: Tue Dec 7 21:34:31 2021 +0100 Fortran: perform array subscript checks only for valid INTEGER bounds gcc/fortran/ChangeLog: PR fortran/103607 * frontend-passes.c (do_subscript): Ensure that array bounds are of type INTEGER before performing checks on array subscripts. gcc/testsuite/ChangeLog: PR fortran/103607 * gfortran.dg/pr103607.f90: New test. (cherry picked from commit 9eec77c0df9e5c67454a2e8f83246104458ba4f0)
[Bug fortran/103607] [9/10/11/12 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2927
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103607 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:45cbfabe01878c3efd8b24f3fef06baf48983308 commit r10-10330-g45cbfabe01878c3efd8b24f3fef06baf48983308 Author: Harald Anlauf Date: Tue Dec 7 21:34:31 2021 +0100 Fortran: perform array subscript checks only for valid INTEGER bounds gcc/fortran/ChangeLog: PR fortran/103607 * frontend-passes.c (do_subscript): Ensure that array bounds are of type INTEGER before performing checks on array subscripts. gcc/testsuite/ChangeLog: PR fortran/103607 * gfortran.dg/pr103607.f90: New test. (cherry picked from commit 9eec77c0df9e5c67454a2e8f83246104458ba4f0)
[Bug libstdc++/103655] New: "x" does not exist on windows and dos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103655 Bug ID: 103655 Summary: "x" does not exist on windows and dos 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: --- In today's patch. https://github.com/gcc-mirror/gcc/commit/a219139e986a4200a9105d7c1fa63735d2945994 std::ios::noreplace uses "x". However, that is not correctly supported by msvcrt and dos djgpp. The correct way is to directly use CreateFileW (on windows NT) or NtCreateFile and CreateFileA on windows 9x. Then call _open_osfhandle to create an fd then call _wfdopen(on windows NT) or _fdopen(on windows 9x) on Windows Create an NT handle with NtCreateFile (You also need RtlNtStatusToDosError and RtlDosPathNameToNtPathName_U_WithStatus or RtlDosPathNameToNtPathName_U). https://github.com/tearosccebe/fast_io/blob/6081ae18b34820c3c69b81628f520f5fafcfb815/include/fast_io_hosted/platforms/nt.h#L67 Or create a win32 handle with CreateFileA (on Windows 9x) and CreateFileW (on Windows NT) https://github.com/tearosccebe/fast_io/blob/6081ae18b34820c3c69b81628f520f5fafcfb815/include/fast_io_hosted/platforms/win32.h#L201 Use win32 or nt handle to call _open_osfhandle to create a POSIX fd. https://github.com/tearosccebe/fast_io/blob/6081ae18b34820c3c69b81628f520f5fafcfb815/include/fast_io_hosted/platforms/posix.h#L58 https://github.com/tearosccebe/fast_io/blob/6081ae18b34820c3c69b81628f520f5fafcfb815/include/fast_io_hosted/platforms/posix.h#L961 Then use _wfdopen on Windows NT and _fdopen on Windows 9x to open a FILE* https://github.com/tearosccebe/fast_io/blob/6081ae18b34820c3c69b81628f520f5fafcfb815/include/fast_io_legacy_impl/c/impl.h#L29 Then construct a std::filebuf with FILE* https://github.com/tearosccebe/fast_io/blob/6081ae18b34820c3c69b81628f520f5fafcfb815/include/fast_io_legacy_impl/filebuf/filebuf_file.h#L60 On DOS. You need __dos_creat,__dos_creatnew,__dos_open https://github.com/tearosccebe/fast_io/blob/6081ae18b34820c3c69b81628f520f5fafcfb815/include/fast_io_hosted/platforms/posix.h#L1063 So libstdc++ using fdopen to open FILE* with fd is incorrect. On windows NT kernel, we MUST use _wfdopen since _fdopen involves locale, which is not thread-safe.
[Bug jit/103562] Jitted code produces incorrect result when returning 3-member struct from internal function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103562
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from David Malcolm ---
Thanks for filing this bug, and for the investigation.
After a couple of hours debugging, I think I've found the discrepancy between
cc1 and libgccjit, and have a candidate fix.
When tree-inline.c:remap_gimple_stmt is called to remap the stmt:
= *ptr_2(D);
cc1 returns:
D.1989 = *ptr_2(D);
whereas libgccjit returns this (copy):
= *ptr_2(D);
Putting a breakpoint on remap_gimple_op_r and singlestepping (in both cc1 and
libgccjit, side by side) shows the discrepancy happens in
tree-inline.c:remap_gimple_op_r here:
1036 else if (auto_var_in_fn_p (*tp, fn))
For cc1:
(gdb) p auto_var_in_fn_p (*tp, fn)
$28 = true
whereas for libgccjit:
(gdb) p auto_var_in_fn_p (*tp, fn)
$19 = false
and so libgccjit erroneously skips the remapping of locals vars and labels.
This turns out to be because the RESULT_DECL has a non-NULL DECL_CONTEXT in
cc1, set here by the C frontend:
(gdb) bt
#0 finish_function (end_loc=248384) at ../../src/gcc/c/c-decl.c:10271
#1 0x009db5f7 in c_parser_declaration_or_fndef (parser=0x77ffbbd0,
fndef_ok=true, static_assert_ok=true, empty_ok=true, nested=false,
start_attr_ok=true, objc_foreach_object_declaration=0x0,
omp_declare_simd_clauses=0x0, have_attrs=false, attrs=,
oacc_routine_data=0x0, fallthru_attr_p=0x0) at
../../src/gcc/c/c-parser.c:2563
#2 0x009d9925 in c_parser_external_declaration (parser=0x77ffbbd0)
at ../../src/gcc/c/c-parser.c:1779
#3 0x009d941d in c_parser_translation_unit (parser=0x77ffbbd0) at
../../src/gcc/c/c-parser.c:1652
#4 0x00a21267 in c_parse_file () at ../../src/gcc/c/c-parser.c:23280
#5 0x00abd0ab in c_common_parse_file () at
../../src/gcc/c-family/c-opts.c:1238
#6 0x010cab1a in compile_file () at ../../src/gcc/toplev.c:452
#7 0x0093eb7a in do_compile (no_backend=false) at
../../src/gcc/toplev.c:2156
#8 toplev::main (this=0x7fffde1a, argc=, argv=) at ../../src/gcc/toplev.c:2308
#9 0x0270339d in main (argc=24, argv=0x7fffdf28) at
../../src/gcc/main.c:39
(gdb) list
10266 /* Must mark the RESULT_DECL as being in this function. */
10267
10268 if (DECL_RESULT (fndecl) && DECL_RESULT (fndecl) != error_mark_node)
10269 DECL_CONTEXT (DECL_RESULT (fndecl)) = fndecl;
whereas the RESULT_DECL has NULL for its DECL_CONTEXT.
On trying this patch:
--- a/gcc/jit/jit-playback.c
+++ b/gcc/jit/jit-playback.c
@@ -473,6 +473,7 @@ new_function (location *loc,
DECL_ARTIFICIAL (resdecl) = 1;
DECL_IGNORED_P (resdecl) = 1;
DECL_RESULT (fndecl) = resdecl;
+ DECL_CONTEXT (resdecl) = fndecl;
if (builtin_id)
{
then remap_gimple_stmt in libgccjit correctly remaps the stmt to:
(gdb) call debug ($21)
D.88 = *ptr_2(D);
and I correctly get this output from the libgccjit testcase:
get_a(&s) is 1
i.e. the above patch seems to fix it.
I'm running some more thorough tests.
[Bug fortran/103418] random_number() does not accept pointer, intent(in) array argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103418 --- Comment #13 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:bb6a1ebb8585b85879735d0d6df9535885fad165 commit r12-5900-gbb6a1ebb8585b85879735d0d6df9535885fad165 Author: Harald Anlauf Date: Thu Dec 9 22:57:13 2021 +0100 Fortran: fix check for pointer dummy arguments with INTENT(IN) gcc/fortran/ChangeLog: PR fortran/103418 * check.c (variable_check): Replace previous check of procedure dummy arguments with INTENT(IN) attribute when passed to intrinsic procedures by gfc_check_vardef_context. * expr.c (gfc_check_vardef_context): Correct check of INTENT(IN) dummy arguments for the case of sub-components of a CLASS pointer. gcc/testsuite/ChangeLog: PR fortran/103418 * gfortran.dg/move_alloc_8.f90: Adjust error messages. * gfortran.dg/pointer_intent_9.f90: New test.
[Bug libgcc/103654] cannot correctly catch C++ exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103654 cqwrteur changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from cqwrteur --- Not a bug
[Bug libgcc/103654] cannot correctly catch C++ exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103654 --- Comment #4 from cqwrteur --- g++ -o error error.cc -Ofast -std=c++23 -s -flto -march=native
[Bug libgcc/103654] cannot correctly catch C++ exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103654 --- Comment #3 from cqwrteur --- Created attachment 51972 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51972&action=edit assembly gcc generates
[Bug libgcc/103654] cannot correctly catch C++ exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103654 --- Comment #2 from cqwrteur --- Created attachment 51971 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51971&action=edit Preprocessor file
[Bug libgcc/103654] cannot correctly catch C++ exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103654
cqwrteur changed:
What|Removed |Added
CC||unlvsur at live dot com
--- Comment #1 from cqwrteur ---
#include
#include
int main()
try
{
fast_io::ibuf_file ibf("not_exist.txt");
}
catch(fast_io::error e)
{
return 1;
}
catch(...)
{
return 1;
}
what's wrong here??
[Bug libgcc/103654] New: cannot correctly catch C++ exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103654 Bug ID: 103654 Summary: cannot correctly catch C++ exceptions Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- cqwrteur@Home-Server:~/fast_io_cleanup/fast_io/tests/0017.error$ ./error terminate called after throwing an instance of 'fast_io::error' Aborted (core dumped)
[Bug c++/103653] GCC rejected int x = 0; auto(x); in C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103653 康桓瑋 changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from 康桓瑋 --- Oh, should be +auto(x);
[Bug c++/103653] New: GCC rejected int x = 0; auto(x); in C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103653
Bug ID: 103653
Summary: GCC rejected int x = 0; auto(x); in C++23
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
int main() {
int x = 0;
auto(x);
}
Should this work? GCC rejects it with:
:3:3: error: declaration of 'auto x' has no initializer
3 | auto(x);
| ^~~~
Isn't this using auto to decay-copy the variable x? Please correct me if I am
wrong.
https://godbolt.org/z/TxorTr56o
[Bug c++/103534] [12 regression] Spurious -Wstringop-overflow warning with std::string concatencation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103534 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Also discussed in PR98465.
[Bug c++/103534] [12 regression] Spurious -Wstringop-overflow warning with std::string concatencation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103534 --- Comment #8 from Martin Sebor --- We discussed before (e.g., in PR 93971) the idea of annotating std::string with some attribute telling the optimizer the internal pointer doesn't alias with anything except for the this->_M_local_buf or the result of operator new(). Richi seemed open to it but was concerned about correctness. I'm experimenting with two things to improve the context of all these warnings. One is to print the folded condition under which the warning triggers. This would include the conditions involved in all the ranges used to make decisions. I posted the result for this warning here (I'm not sure it's complete, it's just a POC): https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586524.html Another is to print the path through the code (the CFG actually) leading up to the warning site, like the static analyzer does. This will show each GIMPLE_COND after optimization, so it won't correspond exactly to the original source. For libstdc++ code it will show libstdc++ internal conditions that may not be of much use to users. I'll have to see how bad it is to decide if it's a viable approach.
[Bug c++/103534] [12 regression] Spurious -Wstringop-overflow warning with std::string concatencation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103534 --- Comment #7 from Jason Merrill --- So it seems that this warning did find a real issue with the library, but one that was hard to connect to the actual wording of the message (and didn't affect the original testcase). In particular, "specified bound" doesn't make sense when we're considering values deduced from VRP. Is there any way to print the VRP "backtrace" as part of a warning?
[Bug c++/103534] [12 regression] Spurious -Wstringop-overflow warning with std::string concatencation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103534 --- Comment #6 from Jason Merrill --- Created attachment 51970 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51970&action=edit libstdc++ fix
[Bug c++/103534] [12 regression] Spurious -Wstringop-overflow warning with std::string concatencation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103534
Jason Merrill changed:
What|Removed |Added
Priority|P3 |P1
CC||aldyh at gcc dot gnu.org,
||jason at gcc dot gnu.org
--- Comment #5 from Jason Merrill ---
The dataflow analysis seems to be:
We set the length of one string to 0, and the other string to 16. Then we
store a char to the string buffer, which the compiler thinks could possibly
have clobbered the length we previously set to 0, so we reload it. And we add
the two together. So now we have a combined length about which we think we
know nothing
We should really somehow tell the compiler that stores to the string char
buffer can't alias other non-char objects. And maybe in general we could do
branch prediction based on assuming that char stores don't clobber values we
knew before? But let's put that missed-optimization issue in a separate PR.
So, let's focus away from that problem by making the second string unknown:
#include
std::string foo(std::string x)
{
return std::string("1234567890123456") + x;
}
I get the same surprising warning with this testcase.
Now, we have an unknown total length. We compare this length to the size of
the local buffer, which partitions the range at 16. On the path where the sum
of the lengths is <=16, we conclude that the length of string A must either be
0 or a number so large that adding 16 to it causes it to wrap around to [0,16]
(because integer overflow in unsigned arithmetic is defined). Which branch
prediction thinks is just as likely as 0.
So then along that branch we try to append this impossibly large hypothetical
string to this string we do know the length of, and we get this warning.
So, the warning seems to be that if we were to call _M_append with a
ridiculously large __n argument, we would get undefined behavior. In other
words, if x happened to be the longest possible string. It seems that we check
for unreasonable length arguments in the char* append functions, but not in the
string append function. Changing them to do that check silences the warning.
I'll attach a patch in a moment.
[Bug libstdc++/86976] [meta-bug] Issues with std::time_get, std::time_put etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86976 Bug 86976 depends on bug 86967, which changed state. Bug 86967 Summary: time_get fails to parse abbreviated weekday with %A format string https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86967 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/86967] time_get fails to parse abbreviated weekday with %A format string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86967 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I think this ought to be fixed with the PR78714 r12-5898-gc82e492616e343b6d6db218d2b498267bac899de fix.
[Bug libstdc++/79833] std::put_time has the wrong values for 2 digit years
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79833 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I think this isn't correct, the %C and %y parsing can happen in different _M_extract_via_format calls. So to fix this we really need to pass around a state object as mentioned in the r12-5898-gc82e492616e343b6d6db218d2b498267bac899de commit log, in which it will note the parsed %C value, whether %y has been parsed, among other things and let some finalization routine finalize it.
[Bug target/103646] -O2 -mstackrealign and inline-asm with ebp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103646
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Siddhesh Poyarekar ---
(In reply to Jakub Jelinek from comment #1)
> The driver does what it has been configured to.
> The default for x86_64-linux compiler is x86-64 arch even for 32-bit code,
> Fedora GCC is configured with --with-arch_32=i686 and therefore it defaults
> to -march=i686.
> I don't really see a bug here.
Right, sorry, I think I went off-track. I saw it in the Fedora build failure
but lost track when I tried to reduce the reproducer in a local build.
> With -O0 the testcase is rejected with either -march=i686 or -march=x86-64,
> similarly with -O0 -mstackrealign, with -O2 it is accepted for both, with
> -O2 -mstackrealign only for i686; all this depends on whether frame pointer
> is used or not. The reason why x86-64 rejects it and i686 doesn't in the
> last case is
> SLP vectorization of the
> t->tv_sec = 0;
> t->tv_usec = 1;
> stores, due to that we actually want to realign in the prologue and that
> results in %ebp being used as frame pointer and so can't be used in the
> local register variable.
> -mno-sse or -fno-tree-vectorize will make it compile.
The ebp use in glibc is to inline 6 argument syscalls. It looks like the
assumption in configure is that only -fno-omit-frame-pointer (or other compile
flags that fail a trivial program with asm("ebp")) will cause similar failures
in the build. With the vectorizer in play and the above semantics, it doesn't
seem like a reliable thing to do in gcc 12; the choice would be to either
sacrifice vectorization or 6 argument syscall inlining.
Either way it's a question for glibc, I'll take it there. Thanks for helping
me see this clearer.
[Bug libstdc++/45896] [C++0x] Facet time_get not reading dates according to the IEEE 1003 standard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45896 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek --- Partly changed by the PR78714 r12-5898-gc82e492616e343b6d6db218d2b498267bac899de commit, but only for non-year format.
[Bug gcov-profile/103652] New: Producing profile with -O2 -flto and trying to consume it with -O3 -flto leads to ICEs on indirect call profiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103652
Bug ID: 103652
Summary: Producing profile with -O2 -flto and trying to consume
it with -O3 -flto leads to ICEs on indirect call
profiling
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Building clang in the funny way (training with -O2 -flto -fprofile-generate)
and use with -O3 -flto -fprofile-generate I get ICE here:
Program received signal SIGSEGV, Segmentation fault.
compute_value_histograms (lineno_checksum=2372477078, cfg_checksum=4074682759,
values=...) at ../../gcc/profile.c:931
931 hist->hvalue.counters[j] = act_count[t][j];
(gdb) l
926 gimple_add_histogram_value (cfun, stmt, hist);
927 hist->n_counters = total_size;
928 hist->hvalue.counters = XNEWVEC (gcov_type,
hist->n_counters);
929 for (j = 0; j < hist->n_counters; j++)
930 if (act_count[t])
931 hist->hvalue.counters[j] = act_count[t][j];
932 else
933 hist->hvalue.counters[j] = 0;
934 act_count[t] += hist->n_counters;
935 sort_hist_values (hist);
(gdb) p hist
$1 = (histogram_value) 0x21e9d40
(gdb) p *hist
$2 = {hvalue = {value = 0x7fffea4b9e10, stmt = 0x7fffea4a4ab0, counters =
0x7ffdf13db010, next = 0x0}, type = HIST_TYPE_INDIR_CALL, n_counters =
1059049550, fun = 0x7fffed96ce40, hdata = {intvl = {int_start = 0, steps = 0}}}
(gdb) p hist->n_counters
$6 = 1059049550
and I also get ICE:
/home/jh/llvm-project/clang/lib/AST/ASTContext.cpp: At top level:
/home/jh/llvm-project/clang/lib/AST/ASTContext.cpp:11856:1: internal compiler
error: in stream_out_histogram_value, at value-prof.c:340
I think it is mismatched profile but I do not know - certainly the streaming
needs more sanity checks here
[Bug libstdc++/71367] std::time_get does not implement 'r' or 'p'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71367 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek --- Together with the previous PR78714 r12-5898-gc82e492616e343b6d6db218d2b498267bac899de commit I think this is partially fixed now, it will work fine if %I comes before %p, whether in user's format or from %r, but it doesn't work right now if %p comes before %I e.g. as in cmn_TW, en_HK, hak_TW, ja_JP, ko_KR, nan_TW, si_LK, ta_IN, te_IN, yue_HK, zh_CN, zh_HK and zh_TW glibc locales. For those we need some state and post-processing, mentioned as todo list in the r12-5898 commit message.
[Bug libstdc++/86976] [meta-bug] Issues with std::time_get, std::time_put etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86976 Bug 86976 depends on bug 78714, which changed state. Bug 78714 Summary: std::get_time / std::time_get::get does not accept full month name in %b https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78714 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/78714] std::get_time / std::time_get::get does not accept full month name in %b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78714 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Should be fixed now.
[Bug libstdc++/71367] std::time_get does not implement 'r' or 'p'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71367 --- Comment #9 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:982a2c9b7866558039df61b0596caad57c94c8c4 commit r12-5899-g982a2c9b7866558039df61b0596caad57c94c8c4 Author: Jakub Jelinek Date: Fri Dec 10 17:05:04 2021 +0100 libstdc++: Add std::time_get %r support [PR71367] This incremental patch adds std::time_get %r support (%p was added already in the previous patch). The _M_am_fm_format method previously in the header unfortunately had wrong arguments and so was useless, so the largest complication in this patch is exporting a new symbol in the right symbol version. 2021-12-10 Jakub Jelinek PR libstdc++/71367 * config/locale/dragonfly/time_members.cc (_M_initialize_timepunct): Initialize "C" _M_am_pm_format to %I:%M:%S %p rather than empty string. * config/locale/gnu/time_members.cc (_M_initialize_timepunct): Likewise. * config/locale/generic/time_members.cc (_M_initialize_timepunct): Likewise. * include/bits/locale_facets_nonio.h (_M_am_pm_format): New method. * include/bits/locale_facets_nonio.tcc (_M_extract_via_format): Handle %r. * config/abi/pre/gnu.ver (GLIBCXX_3.4.30): Export _M_am_pm_format with const _CharT** argument, ensure it isn't exported in GLIBCXX_3.4. * testsuite/22_locale/time_get/get/char/71367.cc: New test. * testsuite/22_locale/time_get/get/wchar_t/71367.cc: New test.
