[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #23 from harper at msor dot vuw.ac.nz --- Given what "undefined" means in Fortran, I see no bug now. On Fri, 3 Jun 2022, jvdelisle at gcc dot gnu.org wrote: > Date: Fri, 3 Jun 2022 21:04:22 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug fortran/105473] semicolon allowed when list-directed read > integer with decimal='point' > Resent-Date: Sat, 4 Jun 2022 09:04:35 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 > > --- Comment #22 from Jerry DeLisle --- > 12.11.2 (6) says "if the statement is a READ statement or the error > condition occurs in a wait operation for a transfer initiated by a READ > statement, all input items or namelist group objects in the statement that > initiated the transfer become undefined;" > > By undefined, it means you cant rely on it whether or not it has a value read > into it or not. It is undefined by the standard and to the user, so it could > be anything, > > There was one last place I am going to check in the code before I am done. > (maybe ;)) > > Regarding NAG, yes we always use to like to see that interpretation. > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276
[Bug bootstrap/105831] Nonportable syntax in "test" and "[" commands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105831 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- Hi, please send the patch to the gcc-patches mailing list for review.
[Bug libstdc++/105844] std::lcm(50000, 49999) is UB but accepted in a constexpr due to cast to unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105844 --- Comment #2 from Goswin von Brederlow --- I know the patch doesn't work yet, the static_asserts aren't constexpr. But hopefully it gives someone enough of an idea to fix it.
[Bug libstdc++/105844] std::lcm(50000, 49999) is UB but accepted in a constexpr due to cast to unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105844 Goswin von Brederlow changed: What|Removed |Added CC||goswin-v-b at web dot de --- Comment #1 from Goswin von Brederlow --- Created attachment 53081 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53081=edit Patch for numeric Patch for the proposed changes
[Bug libstdc++/105844] New: std::lcm(50000, 49999) is UB but accepted in a constexpr due to cast to unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105844
Bug ID: 105844
Summary: std::lcm(5, 4) is UB but accepted in a
constexpr due to cast to unsigned
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
Target Milestone: ---
Running "gcc-12.1 -std=c++20 -O2 -W -Wall" on
#include
constinit int t = std::lcm(5, 4);
produces
t:
.long -1795017296
The standard says:
> The behavior is undefined if |m|, |n|, or the least common multiple of |m|
> and |n| is not representable as a value of type std::common_type_t.
Which is the case here, the lvm overflows and is undefined. The negative number
produced is not correct and the compile should fail.
The problem is the __absu function in casting the arguments to an
unsigned type:
// std::abs is not constexpr, doesn't support unsigned integers,
// and std::abs(std::numeric_limits::min()) is undefined.
template
constexpr _Up
__absu(_Tp __val)
{
static_assert(is_unsigned<_Up>::value, "result type must be unsigned");
static_assert(sizeof(_Up) >= sizeof(_Tp),
"result type must be at least as wide as the input type");
return __val < 0 ? -(_Up)__val : (_Up)__val;
}
/// Least common multiple
template
constexpr common_type_t<_Mn, _Nn>
lcm(_Mn __m, _Nn __n) noexcept
{
static_assert(is_integral_v<_Mn>, "std::lcm arguments must be integers");
static_assert(is_integral_v<_Nn>, "std::lcm arguments must be integers");
static_assert(_Mn(2) == 2, "std::lcm arguments must not be bool");
static_assert(_Nn(2) == 2, "std::lcm arguments must not be bool");
using _Up = make_unsigned_t>;
return __detail::__lcm(__detail::__absu<_Up>(__m),
__detail::__absu<_Up>(__n));
}
__lvm is called with unsigned arguments which do not overflow for the given
numbers. And any unsigned overflow would not be undefined behavior. The result
of __lcm is then converted back to the signed type, which is not UB.
I suggest the following changes:
// LCM implementation
template
constexpr _Tp
__lcm(_Tp __m, _Tp __n)
{
static_assert(__m == 0 || __n == 0 || __m / __detail::__gcd(__m, __n) <=
std::numeric_limits<_Tp>::max() / __n, "std::lcm not representable in commont
type");
return (__m != 0 && __n != 0)
? (__m / __detail::__gcd(__m, __n)) * __n
: 0;
}
/// Least common multiple
template
constexpr common_type_t<_Mn, _Nn>
lcm(_Mn __m, _Nn __n) noexcept
{
static_assert(is_integral_v<_Mn>, "std::lcm arguments must be integers");
static_assert(is_integral_v<_Nn>, "std::lcm arguments must be integers");
static_assert(_Mn(2) == 2, "std::lcm arguments must not be bool");
static_assert(_Nn(2) == 2, "std::lcm arguments must not be bool");
using _Cp = common_type_t<_Mn, _Nn>;
using _Up = make_unsigned_t>;
_Up t = __detail::__lcm(__detail::__absu<_Up>(__m),
__detail::__absu<_Up>(__n));
static_assert(t <= (_Up)std::numeric_limits<_Cp>::max(), "std::lcm not
representable in commont type");
return t;
}
[Bug translation/105843] pt_BR: wrong translation for "integer constant is so large that it is unsigned"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105843 --- Comment #1 from Andrew Pinski --- The translation project is the upstream for the translations really. https://translationproject.org/team/index.html has the list of emails for the translation team and you should send an email to them.
[Bug c/105843] New: pt_BR: wrong translation for "integer constant is so large that it is unsigned"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105843 Bug ID: 105843 Summary: pt_BR: wrong translation for "integer constant is so large that it is unsigned" Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: hugo_musso_gualandi at hotmail dot com Target Milestone: --- The current Brazilian Portuguese translation is translating "unsigned" as if had to do with signatures. It is saying that the number is so big that it doesn't have a signature... I suggest not translating the "unsigned" part, because it is a C keyword. msgid "integer constant is so large that it is unsigned" msgstr "constante inteira é tão grande que não está assinada"
[Bug c++/105842] New: rejects-valid: static member function overload set constrained by concepts for class template results in ambiguous call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105842
Bug ID: 105842
Summary: rejects-valid: static member function overload set
constrained by concepts for class template results in
ambiguous call
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joeloser at fastmail dot com
Target Milestone: ---
In the following snippet,
```
#include
#include
template
struct S {
static constexpr auto f(const std::unsigned_integral auto value) ->
std::size_t {
return {};
}
static constexpr auto f(const std::signed_integral auto value) -> std::size_t
{
return f(static_cast(value));
}
};
```
The second `f` overload results in a compilation error:
```
error: call of overloaded ‘f(std::size_t)’ is ambiguous
... list of the two candidates
```
This appears to be a GCC bug, but only if S is a class template (regardless of
whether the template parameter list is a type or a non-type). Note that clang
trunk compiles the code fine as-is. If `S` is a class and not a class template,
then GCC accepts the code.
See it live at https://godbolt.org/z/oddxEWGMv
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #22 from Jerry DeLisle --- 12.11.2 (6) says "if the statement is a READ statement or the error condition occurs in a wait operation for a transfer initiated by a READ statement, all input items or namelist group objects in the statement that initiated the transfer become undefined;" By undefined, it means you cant rely on it whether or not it has a value read into it or not. It is undefined by the standard and to the user, so it could be anything, There was one last place I am going to check in the code before I am done. (maybe ;)) Regarding NAG, yes we always use to like to see that interpretation.
[Bug c++/105756] [12/13 Regression] ICE in cxx_eval_constant_expression at cp/constexpr.cc:7586: unexpected expression ‘ElemSize’ of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105756 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:0ecb6b906f215ec56df1a555139abe9ad95414fb commit r13-986-g0ecb6b906f215ec56df1a555139abe9ad95414fb Author: Patrick Palka Date: Fri Jun 3 14:58:22 2022 -0400 c++: value-dep but not type-dep decltype expr [PR105756] Here during ahead of time instantiation of the value-dependent but not type-dependent decltype expression (5 % N) == 0, cp_build_binary_op folds the operands of the == via cp_fully_fold, which performs speculative constexpr evaluation, and from which we crash for (5 % N) due to the value-dependence. Since the operand folding performed by cp_build_binary_op appears to be solely for sake of diagnosing overflow, and since these diagnostics are suppressed when in an unevaluated context, this patch avoids this crash by suppressing cp_build_binary_op's operand folding accordingly. PR c++/105756 gcc/cp/ChangeLog: * typeck.cc (cp_build_binary_op): Don't fold operands when c_inhibit_evaluation_warnings. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/decltype82.C: New test.
[Bug c++/105761] [11/12/13 Regression] ICE on hidden friend definition defined in base type since r11-388-gc4bff4c230c8d341
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105761 Jason Merrill changed: What|Removed |Added Known to work||11.3.1, 12.1.1, 13.0 Target Milestone|--- |11.4 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jason Merrill --- Fixed.
[Bug c++/105761] [11/12/13 Regression] ICE on hidden friend definition defined in base type since r11-388-gc4bff4c230c8d341
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105761 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:c27cbeb985f7b6e1759399971b4fe2773e91ca71 commit r11-10047-gc27cbeb985f7b6e1759399971b4fe2773e91ca71 Author: Jason Merrill Date: Fri Jun 3 12:35:12 2022 -0400 c++: redeclared hidden friend [PR105761] Here, when we see the second declaration of f we match it with the first one, copy over DECL_TEMPLATE_INFO, and then try to use it when parsing the definition, leading to confusion. PR c++/105761 gcc/cp/ChangeLog: * decl.c (duplicate_decls): Don't copy DECL_TEMPLATE_INFO from a hidden friend. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/auto-fn64.C: New test.
[Bug c++/105840] confusing diagnostic when naming the wrong class in a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105840 --- Comment #3 from Marek Polacek --- Ah, that sounds great to me.
[Bug c++/105761] [11/12/13 Regression] ICE on hidden friend definition defined in base type since r11-388-gc4bff4c230c8d341
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105761 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2843bfa21073dd1ac222540e189e8bcf40afc2c0 commit r12-8456-g2843bfa21073dd1ac222540e189e8bcf40afc2c0 Author: Jason Merrill Date: Fri Jun 3 12:35:12 2022 -0400 c++: redeclared hidden friend [PR105761] Here, when we see the second declaration of f we match it with the first one, copy over DECL_TEMPLATE_INFO, and then try to use it when parsing the definition, leading to confusion. PR c++/105761 gcc/cp/ChangeLog: * decl.cc (duplicate_decls): Don't copy DECL_TEMPLATE_INFO from a hidden friend. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/auto-fn64.C: New test.
[Bug c++/105841] New: Change in behavior of CTAD for alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105841 Bug ID: 105841 Summary: Change in behavior of CTAD for alias templates Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: avemilia at protonmail dot com Target Milestone: --- Created attachment 53080 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53080=edit repro Since GCC 12, this code does not compile: https://godbolt.org/z/sWvh7P4co The code used to compile on GCC 10 and 11. If this is incorrect code, please explain what is wrong.
[Bug c++/105840] confusing diagnostic when naming the wrong class in a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105840 --- Comment #2 from Barry Revzin --- I think something to this effect maybe? :9:7: error: attempting to declare constructor for unrelated class 'A'; did you mean to use 'B'? 9 | A(int i); | ^~ | B
[Bug c++/105840] confusing diagnostic when naming the wrong class in a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105840 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Keywords||diagnostic CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-06-03 --- Comment #1 from Marek Polacek --- Thanks for the report. Do you have any ideas about what kind of wording would be appropriate here?
[Bug c++/105840] New: confusing diagnostic when naming the wrong class in a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105840
Bug ID: 105840
Summary: confusing diagnostic when naming the wrong class in a
constructor
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
In this code:
template struct X { };
struct A {
A(int i);
A(X x);
};
struct B {
A(int i);
A(X x);
};
I was copying the constructors from A into B, and forgot to change the name.
This is, indeed, ill-formed.
However, this is what gcc tells me:
:9:7: error: expected unqualified-id before 'int'
9 | A(int i);
| ^~~
:9:7: error: expected ')' before 'int'
9 | A(int i);
| ~^~~
| )
:10:14: error: invalid declarator before 'x'
10 | A(X x);
| ^
:10:13: error: expected ')' before 'x'
10 | A(X x);
| ~ ^~
| )
Clang does at least point me to the A, but otherwise provides a
differently-confusing diagnostic about the parentheses?
:9:7: error: expected member name or ';' after declaration specifiers
A(int i);
~ ^
:9:7: error: expected ')'
:9:6: note: to match this '('
A(int i);
^
:10:14: error: expected ')'
A(X x);
^
:10:6: note: to match this '('
A(X x);
^
:10:7: error: member 'X' cannot have template arguments
A(X x);
^~
[Bug c++/105761] [11/12/13 Regression] ICE on hidden friend definition defined in base type since r11-388-gc4bff4c230c8d341
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105761 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:284ae8b46f5eef74c0b660a87a7169497f559e73 commit r13-985-g284ae8b46f5eef74c0b660a87a7169497f559e73 Author: Jason Merrill Date: Fri Jun 3 12:35:12 2022 -0400 c++: redeclared hidden friend [PR105761] Here, when we see the second declaration of f we match it with the first one, copy over DECL_TEMPLATE_INFO, and then try to use it when parsing the definition, leading to confusion. PR c++/105761 gcc/cp/ChangeLog: * decl.cc (duplicate_decls): Don't copy DECL_TEMPLATE_INFO from a hidden friend. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/auto-fn64.C: New test.
[Bug c++/105839] internal compiler error: in tsubst_omp_for_iterator, at cp/pt.cc:18122 (instantiate_pending_templates -> instantiate_decl -> tsubst_lambda_expr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105839
--- Comment #1 from Jakub Jelinek ---
Adjusted testcase, so that it is already valid C++17:
template
void
foo (const T )
{
[&] (auto&& y)
{
#pragma omp parallel for
for (auto&& [v1, v2] : x)
;
} ([]{});
}
void
bar ()
{
int a[10];
foo (a);
}
[Bug libgomp/105839] New: internal compiler error: in tsubst_omp_for_iterator, at cp/pt.cc:18122 (instantiate_pending_templates -> instantiate_decl -> tsubst_lambda_expr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105839
Bug ID: 105839
Summary: internal compiler error: in tsubst_omp_for_iterator,
at cp/pt.cc:18122 (instantiate_pending_templates ->
instantiate_decl -> tsubst_lambda_expr)
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: northon_patrick3 at yahoo dot ca
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Created attachment 53079
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53079=edit
Result from -freport-bug
The code:
```
void test(const auto )
{
const auto loopImpl = [&](auto&& fc)
{
#pragma omp parallel for
for(auto&& [v1, v2] : b1);
};
loopImpl([]{});
}
void test2()
{
int a[10];
test(a);
}
```
The command line:
```
g++ -fopenmp test.cpp
```
The error:
```
internal compiler error: in tsubst_omp_for_iterator, at cp/pt.cc:18126
11 | for(auto&& [v1, v2] : b1);
| ^~~
0x1ac4724 internal_error(char const*, ...)
???:0
0x663b55 fancy_abort(char const*, int, char const*)
???:0
0x81d054 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x80614a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
???:0
0x7fedbe instantiate_decl(tree_node*, bool, bool)
???:0
0x81e704 instantiate_pending_templates(int)
???:0
0x7173d1 c_parse_final_cleanups()
???:0
```
GCC is configured with:
```
configure --prefix=/opt/pat-gcc --libdir=/opt/pat-gcc/lib
--libexecdir=/opt/pat-gcc/lib --enable-languages=c,c++,lto --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/opt/pat-gcc/include/dlang/gdc
```
It happens from version 10.1 to latest commit at this date.
It no longer crash if:
- I don't use structured bindings.
- b1 isn't a template.
- I remove `auto&& fc`.
[Bug c++/105761] [11/12/13 Regression] ICE on hidden friend definition defined in base type since r11-388-gc4bff4c230c8d341
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105761 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/105838] New: g++ 12.1.0 runs out of memory or time when building const std::vector of std::strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838
Bug ID: 105838
Summary: g++ 12.1.0 runs out of memory or time when building
const std::vector of std::strings
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eisjmbjdfcukqlaely at nthrl dot com
Target Milestone: ---
Created attachment 53078
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53078=edit
Output of "g++ -E tmp_in.cpp > tmp_in.ii"
While porting a Wordle-like game from an interpreted language to C++
(ironically, in an attempt at getting better performance from a compiled
language!) it was found that g++ 12.1.0 cannot even initialize a const
std::vector of known fixed-length words.
Here is g++ 12.1.0 running out of memory (16GB RAM + 8GB swap) with -O1, after
about a minute:
```
$ g++ tmp_in.cpp -O1
g++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
```
If optimization is disabled in an attempt to save memory, g++ takes
unreasonably long and gets killed after 300 seconds:
```
$ timeout 300 g++ tmp_in.cpp # gets killed after 300 seconds with no a.out
```
Output of g++ -v:
```
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-linker-build-id --enable-lto
--enable-multilib --enable-plugin --enable-shared --enable-threads=posix
--disable-libssp --disable-libstdcxx-pch --disable-werror
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (GCC)
```
For comparison, here is clang++ 13.0.1 building in about 5 seconds without
optimization:
```
$ /usr/bin/time --verbose clang++ tmp_in.cpp
tmp_in.cpp:1797:19: warning: format specifies type 'int' but the argument has
type 'std::vector::size_type' (aka 'unsigned long') [-Wformat]
printf ("%d\n", lst.size());
~~ ^~
%zu
1 warning generated.
Command being timed: "clang++ tmp_in.cpp"
User time (seconds): 4.69
System time (seconds): 0.17
$ ./a.out
21437
```
If optimization is enabled with -O1, clang++ 13.0.1 still successfully compiles
it, though it takes just over 2 minutes and almost 4GB RAM:
```
$ /usr/bin/time --verbose clang++ tmp_in.cpp -O1
tmp_in.cpp:1797:19: warning: format specifies type 'int' but the argument has
type 'std::vector::size_type' (aka 'unsigned long') [-Wformat]
printf ("%d\n", lst.size());
~~ ^~
%zu
1 warning generated.
Command being timed: "clang++ tmp_in.cpp -O1"
User time (seconds): 125.31
System time (seconds): 0.81
Maximum resident set size (kbytes): 3675076
$ ./a.out
21437
```
Output of clang++ -v for completeness:
```
clang++ -v
clang version 13.0.1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation:
/usr/bin/../lib/gcc/x86_64-pc-linux-gnu/12.1.0
Found candidate GCC installation:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.0
Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
```
[Bug c++/105637] [12 Regression] Wrong overload selected in base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105637 --- Comment #6 from Rob Lefebvre --- Thank you!
[Bug c++/105637] [12 Regression] Wrong overload selected in base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105637 --- Comment #5 from Ted Lyngmo --- Excellent and thanks!
[Bug c++/105637] [12 Regression] Wrong overload selected in base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105637 Patrick Palka changed: What|Removed |Added Summary|[12/13 Regression] Wrong|[12 Regression] Wrong |overload selected in base |overload selected in base |class |class --- Comment #4 from Patrick Palka --- Fixed on trunk so far.
[Bug c++/105637] [12/13 Regression] Wrong overload selected in base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105637 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:44a5bd6d933d86ed988fc4695aa00f122cf83eb4 commit r13-984-g44a5bd6d933d86ed988fc4695aa00f122cf83eb4 Author: Patrick Palka Date: Fri Jun 3 12:06:59 2022 -0400 c++: cv-quals of dummy obj for non-dep memfn call [PR105637] In non-dependent23.C below we expect the Base::foo calls to resolve to the second, third and fourth overloads respectively in light of the cv-qualifiers of 'this' in each case. But ever since r12-6075-g2decd2cabe5a4f, the calls incorrectly resolve to the first overload at instantiation time. This happens because the calls to Base::foo are all deemed non-dependent (ever since r7-755-g23cb72663051cd made us ignore 'this' dependence when considering the dependence of a non-static memfn call), hence we end up checking the call ahead of time, using as the object argument a dummy object of type Base. Since this object argument is cv-unqualified, the calls in turn resolve to the unqualified overload of baseDevice. Before r12-6075 this incorrect result would just get silently discarded and we'd end up redoing OR at instantiation time using 'this' as the object argument. But after r12-6075 we now reuse this incorrect result at instantiation time. This patch fixes this by making maybe_dummy_object respect the cv-quals of (the non-lambda) 'this' when returning a dummy object. Thus, ahead of time OR using a dummy object will give us the right answer that's consistent with the instantiation time answer. An earlier version of this patch didn't handle 'this'-capturing lambdas correctly, which broke lambda-this22.C below. PR c++/105637 gcc/cp/ChangeLog: * tree.cc (maybe_dummy_object): When returning a dummy object, respect the cv-quals of 'this' if available. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/lambda/lambda-this22.C: New test. * g++.dg/template/non-dependent23.C: New test.
[Bug tree-optimization/105835] Dead Code Elimination Regression at -O1 (trunk vs. 12.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105835
Roger Sayle changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-06-03
Ever confirmed|0 |1
--- Comment #1 from Roger Sayle ---
Hmm. There might be something missing in CCP (with -O1)...
# RANGE [0, 1] NONZERO 1
_3 = (intD.6) _2;
# RANGE [0, 65535] NONZERO 65535
_10 = _3 * 65535;
d_11 = (short unsigned intD.18) _10;
if (d_11 != 1)
goto ; [67.00%]
else
goto ; [33.00%]
So it knows _10 is either 0 or 65535, so if it knew d_11 had the
range {0 or -1}, i.e. [-1,0] it would know d_11 != 1, and hence
goto .
[Bug testsuite/105837] New: New test c-c++-common/diagnostic-format-sarif-file-4.c in r13-967-g6cf276ddf22066 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105837 Bug ID: 105837 Summary: New test c-c++-common/diagnostic-format-sarif-file-4.c in r13-967-g6cf276ddf22066 fails Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:6cf276ddf22066af780335cd0072d2c27aabe468, r13-967-g6cf276ddf22066 make -k check-gcc RUNTESTFLAGS="dg.exp=c-c++-common/diagnostic-format-sarif-file-4.c" FAIL: c-c++-common/diagnostic-format-sarif-file-4.c -Wc++-compat scan-sarif-file "text": " int \\u6587\\u5b57\\u5316\\u3051 = FAIL: c-c++-common/diagnostic-format-sarif-file-4.c -std=gnu++98 scan-sarif-file "text": " int \\u6587\\u5b57\\u5316\\u3051 = FAIL: c-c++-common/diagnostic-format-sarif-file-4.c -std=gnu++14 scan-sarif-file "text": " int \\u6587\\u5b57\\u5316\\u3051 = FAIL: c-c++-common/diagnostic-format-sarif-file-4.c -std=gnu++17 scan-sarif-file "text": " int \\u6587\\u5b57\\u5316\\u3051 = FAIL: c-c++-common/diagnostic-format-sarif-file-4.c -std=gnu++20 scan-sarif-file "text": " int \\u6587\\u5b57\\u5316\\u3051 = commit 6cf276ddf22066af780335cd0072d2c27aabe468 (HEAD, refs/bisect/bad) Author: David Malcolm Date: Thu Jun 2 15:40:22 2022 -0400 gcc/testsuite/ChangeLog: * c-c++-common/diagnostic-format-sarif-file-4.c: New test.
[Bug c++/105797] [11/12 Regression] Internal compiler error: Segmentation fault ( fn_type_unification -> satisfaction_cache::satisfaction_cache -> iterative_hash_template_arg )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105797 Patrick Palka changed: What|Removed |Added Summary|[11/12/13 Regression] |[11/12 Regression] Internal |Internal compiler error:|compiler error: |Segmentation fault (|Segmentation fault ( |fn_type_unification -> |fn_type_unification -> |satisfaction_cache::satisfa |satisfaction_cache::satisfa |ction_cache -> |ction_cache -> |iterative_hash_template_arg |iterative_hash_template_arg |) |) --- Comment #4 from Patrick Palka --- Fixed on trunk so far.
[Bug fortran/105836] New: [OpenMP] segfault when assigning after firstprivate + allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105836 Bug ID: 105836 Summary: [OpenMP] segfault when assigning after firstprivate + allocate Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: openmp, wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Created attachment 53077 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53077=edit Testcase (test.f90) - compile (-fopenmp) + run Testcase – see attachment or (reduced from) testsuite/libgomp.fortran/allocate-1.f90 with a 'x = ...' added at the end of 'subroutine foo'. !$omp parallel !$omp task firstprivate(x) allocate(h: x) ... !$omp end task !$omp end parallel x = 5 ! segfault at runtime The C code works, i.e. libgomp.c-c++-common/allocate-1.c
[Bug tree-optimization/105835] New: Dead Code Elimination Regression at -O1 (trunk vs. 12.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105835
Bug ID: 105835
Summary: Dead Code Elimination Regression at -O1 (trunk vs.
12.1.0)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
cat case.c
void foo();
static int b;
static short a(short c, unsigned short d) { return c - d; }
int main() {
int e = -(0 < b);
if (a(1, e))
b = 0;
else
foo();
}
`gcc-1982fe2692b6c3b7f969ffc4edac59f9d4359e91 (trunk) -O1` can not eliminate
`foo` but `gcc-releases/gcc-12.1.0 -O1` can.
`gcc-1982fe2692b6c3b7f969ffc4edac59f9d4359e91 (trunk) -O1 -S -o /dev/stdout
case.c`
- OUTPUT -
main:
.LFB1:
.cfi_startproc
cmpl$0, b(%rip)
movl$65535, %eax
movl$0, %edx
cmovle %edx, %eax
cmpw$1, %ax
je .L2
movl$0, b(%rip)
movl$0, %eax
ret
.L2:
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$0, %eax
callfoo
movl$0, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -
`gcc-releases/gcc-12.1.0 -O1 -S -o /dev/stdout case.c`
- OUTPUT -
main:
.LFB1:
.cfi_startproc
movl$0, b(%rip)
movl$0, %eax
ret
-- END OUTPUT -
Bisects to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8fb94fc6097c0a934aac0d89c9c5e2038da67655
[Bug c++/100374] Type-constraints of member function templates should not be substituted into during implicit instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100374 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:43c013df02fdb07f9b7a5e7e6669e6d69769d451 commit r13-981-g43c013df02fdb07f9b7a5e7e6669e6d69769d451 Author: Patrick Palka Date: Fri Jun 3 09:29:12 2022 -0400 c++: don't substitute TEMPLATE_PARM_CONSTRAINTS [PR100374] This patch makes us avoid substituting into the TEMPLATE_PARM_CONSTRAINTS of each template parameter except as necessary for declaration matching, like we already do for the other constituent constraints of a declaration. This patch also improves the CA104 implementation of explicit specialization matching of a constrained function template inside a class template, by considering the function's combined constraints instead of just its trailing constraints. This allows us to correctly handle the first three explicit specializations in concepts-spec2.C below, but because we compare the constraints as a whole, it means we incorrectly accept the fourth explicit specialization which writes #3's constraints in a different way. For complete correctness here, determine_specialization should use tsubst_each_template_parm_constraints and template_parameter_heads_equivalent_p. PR c++/100374 gcc/cp/ChangeLog: * pt.cc (determine_specialization): Compare overall constraints not just the trailing constraints. (tsubst_each_template_parm_constraints): Define. (tsubst_friend_function): Use it. (tsubst_friend_class): Use it. (tsubst_template_parm): Don't substitute TEMPLATE_PARM_CONSTRAINTS. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-spec2.C: New test. * g++.dg/cpp2a/concepts-template-parm11.C: New test.
[Bug tree-optimization/105834] New: Dead Code Elimination Regression at -O2 (trunk vs. 12.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105834
Bug ID: 105834
Summary: Dead Code Elimination Regression at -O2 (trunk vs.
12.1.0)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
cat case.c
static int a, b;
void foo();
int main() {
for (int c = 0; c < 2; c = c + (unsigned)3)
if (a)
for (;;)
if (c > 0)
b = 0;
if (b)
foo();
}
`gcc-1982fe2692b6c3b7f969ffc4edac59f9d4359e91 (trunk) -O2` can not eliminate
`foo` but `gcc-releases/gcc-12.1.0 -O2` can.
`gcc-1982fe2692b6c3b7f969ffc4edac59f9d4359e91 (trunk) -O2 -S -o /dev/stdout
case.c`
- OUTPUT -
main:
.LFB0:
.cfi_startproc
movlb(%rip), %ecx
testl %ecx, %ecx
jne .L8
xorl%eax, %eax
ret
.L8:
pushq %rax
.cfi_def_cfa_offset 16
xorl%eax, %eax
callfoo
xorl%eax, %eax
popq%rdx
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -
`gcc-releases/gcc-12.1.0 -O2 -S -o /dev/stdout case.c`
- OUTPUT -
main:
.LFB0:
.cfi_startproc
xorl%eax, %eax
ret
-- END OUTPUT -
Bisects to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98e475a8f58ca3ba6e9bd5c9276efce4236f5d26
[Bug tree-optimization/105833] New: Dead Code Elimination Regression at -O2 (trunk vs. 12.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105833
Bug ID: 105833
Summary: Dead Code Elimination Regression at -O2 (trunk vs.
12.1.0)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
cat case.c #4
void foo();
static int b;
static int **c;
static int ***d =
static int e =
static char(a)(char g, int h) { return h >= 2 ? g : g << h; }
int main() {
**e == 0;
b = b ? 4 : 0;
if (!a(*e != 0, b))
foo();
}
`gcc-1982fe2692b6c3b7f969ffc4edac59f9d4359e91 (trunk) -O2` can not eliminate
`foo` but `gcc-releases/gcc-12.1.0 -O2` can.
`gcc-1982fe2692b6c3b7f969ffc4edac59f9d4359e91 (trunk) -O2 -S -o /dev/stdout
case.c`
- OUTPUT -
main:
.LFB1:
.cfi_startproc
movlb(%rip), %ecx
xorl%eax, %eax
testl %ecx, %ecx
setne %al
sall$2, %eax
cmpq$0, d(%rip)
movl%eax, b(%rip)
je .L8
xorl%eax, %eax
ret
.L8:
pushq %rax
.cfi_def_cfa_offset 16
xorl%eax, %eax
callfoo
xorl%eax, %eax
popq%rdx
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -
`gcc-releases/gcc-12.1.0 -O2 -S -o /dev/stdout case.c`
- OUTPUT -
main:
.LFB1:
.cfi_startproc
movlb(%rip), %edx
xorl%eax, %eax
testl %edx, %edx
setne %al
sall$2, %eax
movl%eax, b(%rip)
xorl%eax, %eax
ret
-- END OUTPUT -
Bisects to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b7501739f3b14ac7749aace93f636d021fd607f7
[Bug c++/105797] [11/12/13 Regression] Internal compiler error: Segmentation fault ( fn_type_unification -> satisfaction_cache::satisfaction_cache -> iterative_hash_template_arg )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105797 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:df4f95dbd4764ffc1e8270e5b3c0fd71b6724562 commit r13-980-gdf4f95dbd4764ffc1e8270e5b3c0fd71b6724562 Author: Patrick Palka Date: Fri Jun 3 09:08:41 2022 -0400 c++: find_template_parameters and PARM_DECLs [PR105797] As explained in r11-4959-gde6f64f9556ae3, the atom cache assumes two equivalent expressions (according to cp_tree_equal) must use the same template parameters (according to find_template_parameters). This assumption turned out to not hold for TARGET_EXPR, which was addressed by that commit. But this assumption apparently doesn't hold for PARM_DECL either: find_template_parameters walks its DECL_CONTEXT but cp_tree_equal by default doesn't consider DECL_CONTEXT unless comparing_specializations is set. Thus in the first testcase below, the atomic constraints of #1 and #2 are equivalent according to cp_tree_equal, but according to find_template_parameters the former uses T and the latter uses both T and U (surprisingly). We could fix this assumption violation by setting comparing_specializations in the atom_hasher, which would make cp_tree_equal return false for the two atoms, but that seems overly pessimistic here. Ideally the atoms should continue being considered equivalent and we instead fix find_template_paremeters to return just T for #2's atom. To that end this patch makes for_each_template_parm_r stop walking the DECL_CONTEXT of a PARM_DECL. This should be safe to do because tsubst_copy / tsubst_decl only substitutes the TREE_TYPE of a PARM_DECL and doesn't bother substituting the DECL_CONTEXT, thus the only relevant template parameters are those used in its type. any_template_parm_r is currently responsible for walking its TREE_TYPE, but I suppose it now makes sense for for_each_template_parm_r to do so instead. In passing this patch also makes for_each_template_parm_r stop walking the DECL_CONTEXT of a VAR_/FUNCTION_DECL since doing so after walking DECL_TI_ARGS is redundant, I think. I experimented with not walking DECL_CONTEXT for CONST_DECL, but the second testcase below demonstrates it's necessary to walk it. PR c++/105797 gcc/cp/ChangeLog: * pt.cc (for_each_template_parm_r) : Don't walk DECL_CONTEXT. : Likewise. Walk TREE_TYPE. : Simplify. (any_template_parm_r) : Don't walk TREE_TYPE. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-decltype4.C: New test. * g++.dg/cpp2a/concepts-memfun3.C: New test.
[Bug target/105292] [10/11/12/13 regression] ICE in expand_expr_real_2 when compiling with -mvis2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105292 Eric Botcazou changed: What|Removed |Added CC||sumbera at volny dot cz --- Comment #12 from Eric Botcazou --- *** Bug 105792 has been marked as a duplicate of this bug. ***
[Bug target/105792] SPARC GCC 12.1.0 fails with internal compiler error: in expand_expr_real_2, at expr.cc:10160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105792 Eric Botcazou changed: What|Removed |Added Target Milestone|--- |12.2 CC||ebotcazou at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #5 from Eric Botcazou --- . *** This bug has been marked as a duplicate of bug 105292 ***
[Bug c++/87656] Useful flags to enable with -Wall or -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87656
--- Comment #17 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #16)
> Note, what is most important with this are configure scripts, if we start
> warning on something still widely used in configure snippets, we'll get
> silently different results of configure checks.
A configure check that isn't specifically for some warning) that gives
different
results if some random warning happens, is fundamentally broken already. I
would
hope existing checks are more robust (but I certainly believe they are not :-(
)
> For old style definitions, the question is if we want to warn about
> void foo () {} style of functions or just those which actually have some
> arguments.
We can have a =2 to warn for everything, and =1 for just the more serious
things?
Easy to switch default for -Wall and -W that way, too.
[Bug target/105825] [13 Regression] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105825 --- Comment #1 from Jakub Jelinek --- Started with r13-927-gdcfdd2851b297e0005a8490b7f867ca45d1ad340
[Bug tree-optimization/105832] New: Dead Code Elimination Regression at -O3 (trunk vs. 12.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105832
Bug ID: 105832
Summary: Dead Code Elimination Regression at -O3 (trunk vs.
12.1.0)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
cat case.c #2
void foo(void);
static struct {
short a;
char b;
} c;
static char d;
int main() {
char g = c.b > 4U ? c.b : c.b << 2;
for (int h = 0; h < 5; h++) {
d = (g >= 2 || 1 >> g) ? g : g << 1;
if (d && 1 == g)
foo();
c.a = 0;
}
}
`gcc-1982fe2692b6c3b7f969ffc4edac59f9d4359e91 (trunk) -O3` can not eliminate
`foo` but `gcc-releases/gcc-12.1.0 -O3` can.
`gcc-1982fe2692b6c3b7f969ffc4edac59f9d4359e91 (trunk) -O3 -S -o /dev/stdout
case.c`
- OUTPUT -
main:
.LFB0:
.cfi_startproc
movsbl c+2(%rip), %edx
movl%edx, %eax
sall$2, %edx
cmpb$5, %al
cmovb %edx, %eax
cmpb$1, %al
jle .L3
.L13:
xorl%eax, %eax
movw%ax, c(%rip)
xorl%eax, %eax
ret
.L3:
movsbl %al, %edx
addl%edx, %edx
testb %al, %al
cmove %eax, %edx
testb %dl, %dl
je .L13
subb$1, %al
jne .L13
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movl$5, %ebx
.L6:
callfoo
movw$0, c(%rip)
subl$1, %ebx
jne .L6
xorl%eax, %eax
popq%rbx
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -
`gcc-releases/gcc-12.1.0 -O3 -S -o /dev/stdout case.c`
- OUTPUT -
main:
.LFB0:
.cfi_startproc
xorl%eax, %eax
movw%ax, c(%rip)
xorl%eax, %eax
ret
-- END OUTPUT -
Bisects to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a1c9f779f75283427316b5c670c1e01ff8ce9ced
[Bug middle-end/105777] Failure to optimize __builtin_mul_overflow with constant operand to add+cmp check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105777 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed now.
[Bug bootstrap/105831] New: Nonportable syntax in "test" and "[" commands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105831 Bug ID: 105831 Summary: Nonportable syntax in "test" and "[" commands. Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: micha at NetBSD dot org Target Milestone: --- Created attachment 53076 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53076=edit Patches for portable string comparison (POSIX shell) Nonportable string comparisons in files "gcc/configure.ac" and "gcc/config/nvptx/gen-opt.sh". Patches attached for portable POSIX syntax.
[Bug middle-end/30314] optimize multiply-by-constant overflow (wrap) test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30314 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:1982fe2692b6c3b7f969ffc4edac59f9d4359e91 commit r13-979-g1982fe2692b6c3b7f969ffc4edac59f9d4359e91 Author: Jakub Jelinek Date: Fri Jun 3 11:41:21 2022 +0200 match.pd: Optimize __builtin_mul_overflow_p (x, cst, (stype)0) [PR105777] The following patch is an incremental change to the PR30314 enhancement, this one handles signed types. For signed types (but still, the same for 1st and result element type and non-zero constant that fits into that type), we actually need to watch for overflow in direction to positive and negative infinity and it also depends on whether the cst operand is positive or negative. For __builtin_mul_overflow_p (x, cst, (stype) 0): For cst > 0, we can simplify it to: x > INT_MAX / cst || x < INT_MIN / cst aka: x + (unsigned) (INT_MIN / cst) > (unsigned) (INT_MAX / cst) - (unsigned) (INT_MIN / cst) and for cst < 0 to: x < INT_MAX / cst || x > INT_MIN / cst aka: x + (unsigned) (INT_MAX / cst) > (unsigned) (INT_MIN / cst) - (unsigned) (INT_MAX / cst) Additionally, I've added executable testcases, so we don't just check for the optimization to be performed, but also that it is correct (done that even for the other PR's testcase). 2022-06-03 Jakub Jelinek PR middle-end/30314 PR middle-end/105777 * match.pd (__builtin_mul_overflow_p (x, cst, (stype) 0) -> x > stype_max / cst || x < stype_min / cst): New simplification. * gcc.dg/tree-ssa/pr30314.c: Add noipa attribute to all functions. * gcc.dg/tree-ssa/pr105777.c: New test. * gcc.c-torture/execute/pr30314.c: New test. * gcc.c-torture/execute/pr105777.c: New test.
[Bug middle-end/105777] Failure to optimize __builtin_mul_overflow with constant operand to add+cmp check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105777 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:1982fe2692b6c3b7f969ffc4edac59f9d4359e91 commit r13-979-g1982fe2692b6c3b7f969ffc4edac59f9d4359e91 Author: Jakub Jelinek Date: Fri Jun 3 11:41:21 2022 +0200 match.pd: Optimize __builtin_mul_overflow_p (x, cst, (stype)0) [PR105777] The following patch is an incremental change to the PR30314 enhancement, this one handles signed types. For signed types (but still, the same for 1st and result element type and non-zero constant that fits into that type), we actually need to watch for overflow in direction to positive and negative infinity and it also depends on whether the cst operand is positive or negative. For __builtin_mul_overflow_p (x, cst, (stype) 0): For cst > 0, we can simplify it to: x > INT_MAX / cst || x < INT_MIN / cst aka: x + (unsigned) (INT_MIN / cst) > (unsigned) (INT_MAX / cst) - (unsigned) (INT_MIN / cst) and for cst < 0 to: x < INT_MAX / cst || x > INT_MIN / cst aka: x + (unsigned) (INT_MAX / cst) > (unsigned) (INT_MIN / cst) - (unsigned) (INT_MAX / cst) Additionally, I've added executable testcases, so we don't just check for the optimization to be performed, but also that it is correct (done that even for the other PR's testcase). 2022-06-03 Jakub Jelinek PR middle-end/30314 PR middle-end/105777 * match.pd (__builtin_mul_overflow_p (x, cst, (stype) 0) -> x > stype_max / cst || x < stype_min / cst): New simplification. * gcc.dg/tree-ssa/pr30314.c: Add noipa attribute to all functions. * gcc.dg/tree-ssa/pr105777.c: New test. * gcc.c-torture/execute/pr30314.c: New test. * gcc.c-torture/execute/pr105777.c: New test.
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #21 from harper at msor dot vuw.ac.nz --- I have only one problem here, and it's with the f2018 standard seeming to contradict itself in two places that both apply to this program. 12.11.1 begins "The set of input/output error conditions is processor dependent. Except as otherwise specified, when an error condition occurs or is detected is processor dependent." 12.11.2 (6) says "if the statement is a READ statement or the error condition occurs in a wait operation for a transfer initiated by a READ statement, all input items or namelist group objects in the statement that initiated the transfer become undefined;" In the 3rd case below, the output i== 2 input="2;5," with point x = 2.0 999.0 ERR seems to me OK by 12.11.1 (error condition occurring after reading x(1) as 2.0) but 12.11.2 seems to imply that neither x(1) nor x(2) should be read, making the output i= 2 input="2;5," with point x = 666.0 999.0 ERR That is what ifort did with the program, but if the standard is ambiguous I can't complain if gfortran and ifort interpret it differently. There is of course also the cop-out that if the program is not standard-compliant then compilers can do what they like with it. The other cases where gfortran and ifort disagreed are listed below. They all involve point and ERR. I give the gfortran result first then the ifort result. i= 5 input="2,5;" with point x =2.05.0 ERR i= 5 input="2,5;" with point x =2.0 999.0 ERR i= 6 input="2;5;" with point x =2.0 999.0 ERR i= 6 input="2;5;" with point x = 666.0 999.0 ERR i= 7 input="2 5;" with point x =2.05.0 ERR i= 7 input="2 5;" with point x =2.0 999.0 ERR i= 8 input="2.5;" with point x =2.5 999.0 ERR i= 8 input="2.5;" with point x = 666.0 999.0 ERR i=10 input="2;5 " with point x =2.0 999.0 ERR i=10 input="2;5 " with point x = 666.0 999.0 ERR i=14 input="2;5." with point x =2.0 999.0 ERR i=14 input="2;5." with point x = 666.0 999.0 ERR Oddly, there was one point and ERR case where gfortran agreed with ifort: i=16 input="2.5." with point x = 666.0 999.0 ERR I wish I still had access to the NAG compiler! > Date: Fri, 3 Jun 2022 04:33:33 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug fortran/105473] semicolon allowed when list-directed read > integer with decimal='point' > Resent-Date: Fri, 3 Jun 2022 16:33:45 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 > > --- Comment #20 from Jerry DeLisle --- > Please check this. Second pair of eyes needed. > > $ ./a.out > i= 1 input="2,5," with point x =2.05.0 OK > i= 1 input="2,5," with comma x = 666.0 999.0 ERR > > i= 2 input="2;5," with point x =2.0 999.0 ERR > i= 2 input="2;5," with comma x =2.05.0 OK > > i= 3 input="2 5," with point x =2.05.0 OK > i= 3 input="2 5," with comma x =2.05.0 OK > > i= 4 input="2.5," with point x =2.5 999.0 end > i= 4 input="2.5," with comma x = 666.0 999.0 ERR > > i= 5 input="2,5;" with point x =2.05.0 ERR > i= 5 input="2,5;" with comma x =2.5 999.0 end > > i= 6 input="2;5;" with point x =2.0 999.0 ERR > i= 6 input="2;5;" with comma x =2.05.0 OK > > i= 7 input="2 5;" with point x =2.05.0 ERR > i= 7 input="2 5;" with comma x =2.05.0 OK > > i= 8 input="2.5;" with point x =2.5 999.0 ERR > i= 8 input="2.5;" with comma x = 666.0 999.0 ERR > > i= 9 input="2,5 " with point x =2.05.0 OK > i= 9 input="2,5 " with comma x =2.5 999.0 end > > i=10 input="2;5 " with point x =2.0 999.0 ERR > i=10 input="2;5 " with comma x =2.05.0 OK > > i=11 input="2 5 " with point x =2.05.0 OK > i=11 input="2 5 " with comma x =2.05.0 OK > > i=12 input="2.5 " with point x =2.5 999.0 end > i=12 input="2.5 " with comma x = 666.0 999.0 ERR > > i=13 input="2,5." with point x =2.05.0 OK > i=13 input="2,5." with comma x = 666.0 999.0 ERR > > i=14 input="2;5." with point x =2.0 999.0 ERR > i=14 input="2;5." with comma x =2.0 999.0 ERR > > i=15 input="2 5." with point x =2.05.0 OK > i=15 input="2 5." with comma x =2.0 999.0 ERR > > i=16 input="2.5." with point x = 666.0 999.0 ERR > i=16 input="2.5." with comma x = 666.0 999.0 ERR > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276
[Bug target/105825] [13 Regression] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105825 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2022-06-03 Target Milestone|--- |13.0
[Bug middle-end/100810] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100810 --- Comment #16 from CVS Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:be2861fe8c527a5952257462ceca899bb43b1452 commit r13-972-gbe2861fe8c527a5952257462ceca899bb43b1452 Author: Alexandre Oliva Date: Fri Jun 3 03:59:03 2022 -0300 [PR105665] ivopts: check defs of names in base for undefs The patch for PR 100810 tested for undefined SSA_NAMEs appearing directly in the base expression of the potential IV candidate, but that's not enough. The testcase for PR105665 shows an undefined SSA_NAME has the same ill effect if it's referenced as an PHI_NODE arg in the referenced SSA_NAME. The variant of that test shows it can be further removed from the referenced SSA_NAME. To avoid deep recursion, precompute maybe-undefined SSA_NAMEs: start from known-undefined nonvirtual default defs, and propagate them to any PHI nodes reached by a maybe-undefined arg, as long as there aren't intervening non-PHI uses, that would imply the maybe-undefined name must be defined at that point, otherwise it would invoke undefined behavior. Also test for intervening non-PHI uses of DEFs in the base expr. The test for intervening uses implemented herein relies on dominance; this could be further extended, regarding conditional uses in every path leading to a point as an unconditional use dominating that point, but I haven't implemented that. for gcc/ChangeLog PR tree-optimization/105665 PR tree-optimization/100810 * tree-ssa-loop-ivopts.cc (ssa_name_maybe_undef_p, ssa_name_set_maybe_undef): New. (ssa_name_any_use_dominates_bb_p, mark_ssa_maybe_undefs): New. (find_ssa_undef): Check precomputed flag and intervening uses. (tree_ssa_iv_optimize): Call mark_ssa_maybe_undefs. for gcc/testsuite/ChangeLog PR tree-optimization/105665 PR tree-optimization/100810 * gcc.dg/torture/pr105665.c: New.
[Bug tree-optimization/105665] [12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-397-gda9e6e63d1ae22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105665 --- Comment #6 from CVS Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:be2861fe8c527a5952257462ceca899bb43b1452 commit r13-972-gbe2861fe8c527a5952257462ceca899bb43b1452 Author: Alexandre Oliva Date: Fri Jun 3 03:59:03 2022 -0300 [PR105665] ivopts: check defs of names in base for undefs The patch for PR 100810 tested for undefined SSA_NAMEs appearing directly in the base expression of the potential IV candidate, but that's not enough. The testcase for PR105665 shows an undefined SSA_NAME has the same ill effect if it's referenced as an PHI_NODE arg in the referenced SSA_NAME. The variant of that test shows it can be further removed from the referenced SSA_NAME. To avoid deep recursion, precompute maybe-undefined SSA_NAMEs: start from known-undefined nonvirtual default defs, and propagate them to any PHI nodes reached by a maybe-undefined arg, as long as there aren't intervening non-PHI uses, that would imply the maybe-undefined name must be defined at that point, otherwise it would invoke undefined behavior. Also test for intervening non-PHI uses of DEFs in the base expr. The test for intervening uses implemented herein relies on dominance; this could be further extended, regarding conditional uses in every path leading to a point as an unconditional use dominating that point, but I haven't implemented that. for gcc/ChangeLog PR tree-optimization/105665 PR tree-optimization/100810 * tree-ssa-loop-ivopts.cc (ssa_name_maybe_undef_p, ssa_name_set_maybe_undef): New. (ssa_name_any_use_dominates_bb_p, mark_ssa_maybe_undefs): New. (find_ssa_undef): Check precomputed flag and intervening uses. (tree_ssa_iv_optimize): Call mark_ssa_maybe_undefs. for gcc/testsuite/ChangeLog PR tree-optimization/105665 PR tree-optimization/100810 * gcc.dg/torture/pr105665.c: New.
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 Andrew Pinski changed: What|Removed |Added CC||hiraditya at msn dot com --- Comment #44 from Andrew Pinski --- *** Bug 105830 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/105830] call to memcpy when -nostdlib -nodefaultlibs flags provided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105830 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 56888. *** This bug has been marked as a duplicate of bug 56888 ***
[Bug tree-optimization/105830] New: call to memcpy when -nostdlib -nodefaultlibs flags provided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105830
Bug ID: 105830
Summary: call to memcpy when -nostdlib -nodefaultlibs flags
provided
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
https://godbolt.org/z/jTEa6ajn3
```
// test.c
// Type your code here, or load an example.
/* Nonzero if either X or Y is not aligned on a "long" boundary. */
#define UNALIGNED(X, Y) \
(((unsigned long)X & (sizeof (unsigned long) - 1)) | ((unsigned long)Y &
(sizeof (unsigned long) - 1)))
#define UNALIGNED1(a) \
((unsigned long)(a) & (sizeof(unsigned long)-1))
/* How many bytes are copied each iteration of the 4X unrolled loop. */
#define BIGBLOCKSIZE(sizeof (unsigned long) * 4)
/* How many bytes are copied each iteration of the word copy loop. */
#define LITTLEBLOCKSIZE (sizeof (unsigned long))
/* Threshhold for punting to the byte copier. */
#define TOO_SMALL(LEN) ((LEN) < BIGBLOCKSIZE)
void * memcpy (void *__restrict dst0,
const void *__restrict src0,
unsigned long len0)
{
unsigned char *dst = dst0;
const unsigned char *src = src0;
/* If the size is small, or either SRC or DST is unaligned,
then punt into the byte copy loop. This should be rare. */
if (len0 >= LITTLEBLOCKSIZE && !UNALIGNED (src, dst))
{
unsigned long *aligned_dst;
const unsigned long *aligned_src;
aligned_dst = (unsigned long*)dst;
aligned_src = (const unsigned long*)src;
/* Copy one long word at a time if possible. */
/* Copy one long word at a time if possible. */
do
{
*aligned_dst++ = *aligned_src++;
len0 -= LITTLEBLOCKSIZE;
} while (len0 >= LITTLEBLOCKSIZE);
/* Pick up any residual with a byte copier. */
dst = (unsigned char*)aligned_dst;
src = (const unsigned char*)aligned_src;
}
for (; len0; len0--)
*dst++ = *src++;
return dst0;
}
// ARM gcc trunk
gcc -O3 -nostdlib -nodefaultlibs -S -o -
memcpy:
push{r3, r4, r5, r6, r7, lr}
cmp r2, #3
mov r4, r2
mov r5, r0
mov r6, r1
bls .L5
orr r3, r0, r1
lslsr3, r3, #30
beq .L9
.L3:
mov r2, r4
mov r1, r6
bl memcpy ; <- call to memcpy
mov r0, r5
pop {r3, r4, r5, r6, r7, pc}
.L9:
subsr7, r2, #4
and r4, r2, #3
bic r7, r7, #3
addsr7, r7, #4
mov r2, r7
add r6, r6, r7
bl memcpy ; <- call to memcpy
addsr0, r5, r7
.L5:
cmp r4, #0
bne .L3
mov r0, r5
pop {r3, r4, r5, r6, r7, pc}
