[Bug middle-end/107355] [13 Regression] ICE: in lower_bound, at value-range.h:350 with -fsanitize=float-cast-overflow since r13-3231-g706d8583706475fb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107355 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-10-24 Ever confirmed|0 |1 CC||aldyh at gcc dot gnu.org, ||marxin at gcc dot gnu.org Target Milestone|--- |13.0 Summary|[13 Regression] ICE: in |[13 Regression] ICE: in |lower_bound, at |lower_bound, at |value-range.h:350 with |value-range.h:350 with |-fsanitize=float-cast-overf |-fsanitize=float-cast-overf |low |low since ||r13-3231-g706d8583706475fb Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Started with r13-3231-g706d8583706475fb.
[Bug libstdc++/107371] New: __adaptor::_RangeAdaptor rejects the explicit move constructor case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107371
Bug ID: 107371
Summary: __adaptor::_RangeAdaptor rejects the explicit move
constructor case
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
libstdc++ rejects the following code:
#include
struct A {
A() = default;
explicit A(A&&) { }
operator int() { return 5; }
};
int main() {
auto r = std::views::iota(0) | std::views::take(A{});
}
https://godbolt.org/z/EEarj7he8
[Bug analyzer/107366] -fanalyzer with -fdiagnostics-format=sarif-file or sarif-stderr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107366
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
CC||marxin at gcc dot gnu.org
Last reconfirmed||2022-10-24
Status|UNCONFIRMED |NEW
--- Comment #1 from Martin Liška ---
Reduced test-case:
$ cat pr107366.c
typedef enum {
HWLOC_TOPOLOGY_DIFF_OBJ_ATTR_INFO
} hwloc_topology_diff_obj_attr_type_t;
enum { HWLOC_TOPOLOGY_DIFF_OBJ_ATTR } hwloc_apply_diff_one_diff_0_0;
void
hwloc_apply_diff_one() {
switch (hwloc_apply_diff_one_diff_0_0)
case HWLOC_TOPOLOGY_DIFF_OBJ_ATTR: {
hwloc_topology_diff_obj_attr_type_t obj_attr_2_0_0;
switch (obj_attr_2_0_0)
case HWLOC_TOPOLOGY_DIFF_OBJ_ATTR_INFO: {
unsigned ii = 0;
}
}
}
[Bug analyzer/107366] -fanalyzer with -fdiagnostics-format=sarif-file or sarif-stderr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107366
--- Comment #2 from Martin Liška ---
Happens for the following location:
(gdb) p /x loc
$7 = 0x8008
when I expand it:
(gdb) p x
$8 = {
file = 0x0,
line = 0,
column = 0,
data = 0x77769480,
sysp = false
}
it likely corresponds to (5):
gcc -Wfatal-errors pr107366.c -c -fanalyzer
In function ‘hwloc_apply_diff_one’:
cc1: warning: use of uninitialized value ‘obj_attr_2_0_0’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
‘hwloc_apply_diff_one’: events 1-4
|
|pr107366.c:10:41:
|8 | switch (hwloc_apply_diff_one_diff_0_0)
| | ~~
| | |
| | (3) following ‘true’ branch...
|9 | case HWLOC_TOPOLOGY_DIFF_OBJ_ATTR: {
| |
| | |
| | (4) ...to here
| 10 | hwloc_topology_diff_obj_attr_type_t obj_attr_2_0_0;
| | ^~
| | |
| | (1) region created on
stack here
| | (2) capacity: 4 bytes
|
‘hwloc_apply_diff_one’: event 5
|
|cc1:
| (5): use of uninitialized value ‘obj_attr_2_0_0’ here
|
[Bug analyzer/107366] -fanalyzer with -fdiagnostics-format=sarif-file or sarif-stderr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107366
--- Comment #3 from Martin Liška ---
Potential fix:
diff --git a/gcc/diagnostic-format-sarif.cc b/gcc/diagnostic-format-sarif.cc
index fc28d160c38..7110db4edd6 100644
--- a/gcc/diagnostic-format-sarif.cc
+++ b/gcc/diagnostic-format-sarif.cc
@@ -595,7 +595,7 @@ sarif_builder::make_location_object (const diagnostic_event
&event)
json::object *
sarif_builder::maybe_make_physical_location_object (location_t loc)
{
- if (loc <= BUILTINS_LOCATION)
+ if (loc <= BUILTINS_LOCATION || LOCATION_FILE (loc) == NULL)
return NULL;
json::object *phys_loc_obj = new json::object ();
[Bug tree-optimization/107372] New: Loop distribution create memcpy between structs with different storage order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107372
Bug ID: 107372
Summary: Loop distribution create memcpy between structs with
different storage order
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
For t.c with "gcc -O3 t.c":
struct L
{
unsigned int val[256];
} __attribute__((scalar_storage_order ("little-endian")));
struct B
{
unsigned int val[256];
} __attribute__((scalar_storage_order ("big-endian")));
void
foo (struct L *restrict l, struct B *restrict b)
{
int i;
for (i = 0; i < 256; i++)
l->val[i] = b->val[i];
}
The loop distribution pass currently generates a memcpy although it recognizes
correctly that both sides of the assignment have different storage order:
Analyzing # of iterations of loop 1
exit condition [255, + , 4294967295] != 0
bounds on difference of bases: -255 ... -255
result:
# of iterations 255, bounded by 255
Creating dr for *b_5(D).val[i_11]
analyze_innermost: t.c:16:23: missed: failed: reverse storage order.
...
void foo (struct L * restrict l, struct B * restrict b)
{
int i;
[local count: 10737416]:
__builtin_memcpy (l_6(D), b_5(D), 1024);
return;
}
[Bug tree-optimization/107372] Loop distribution create memcpy between structs with different storage order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107372 --- Comment #1 from Andreas Krebbel --- Created attachment 53764 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53764&action=edit Experimental Fix Looks like the error while analyzing the data ref is not propagated to the upper layers to actually prevent the optimization. This patch fixes this for me.
[Bug target/107364] [10/11/12/13 Regression] ICE on Via Nehemiah with --march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107364
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
Last reconfirmed||2022-10-24
--- Comment #1 from Martin Liška ---
Can you please run the following code snippet on the machine:
$ cat cpuid.c
#include "cpuid.h"
int main()
{
int eax, ebx, ecx, edx;
__get_cpuid (0, &eax, &ebx, &ecx, &edx);
__builtin_printf ("__get_cpuid(0): eax=%ld, ebx=%ld, ecx=%ld, edx=%ld\n",
eax, ebx, ecx, edx);
__get_cpuid (1, &eax, &ebx, &ecx, &edx);
__builtin_printf ("__get_cpuid(1): eax=%ld, ebx=%ld, ecx=%ld, edx=%ld\n",
eax, ebx, ecx, edx);
}
$ gcc cpuid.c && ./a.out
and paste the output here?
[Bug tree-optimization/107368] [13 Regression] ICE: 'verify_gimple' failed (error: non-trivial conversion in 'var_decl')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107368 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Last reconfirmed||2022-10-24 Status|UNCONFIRMED |NEW
[Bug tree-optimization/107369] [13 Regression] ICE: verify_flow_info failed (error: label 'l1' has incorrect context in bb 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107369 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Last reconfirmed||2022-10-24
[Bug c++/107327] internal compiler error: in tsubst_pack_expansion, at cp/pt.c:12930
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107327 --- Comment #10 from Martin Liška --- Can't reproduce the ICE with any GCC release I have: gcc-bisect.py 'g++ -O3 -pedantic -std=c++2a -g -Wall -Wextra -Wno-unused-parameter -Wno-sign-compare -Wno-address -Wno-init-list-lifetime pr107327.ii -c' Releases 10.1.0 (6e6e3f144a33ae50)(07 May 2020 10:50): [took: 0.02 s] result: OK 10.2.0 (ee5c3db6c5b2c333)(23 Jul 2020 06:35): [took: 0.01 s] result: OK 10.3.0 (f00b5710a30f22ef)(08 Apr 2021 11:56): [took: 0.01 s] result: OK 10.4.0 (7ff47281ce4f3699)(28 Jun 2022 08:37): [took: 0.02 s] result: OK 11.1.0 (50bc9185c2821350)(27 Apr 2021 11:39): [took: 0.02 s] result: OK 11.2.0 (7ca388565af176bd)(28 Jul 2021 06:55): [took: 0.02 s] result: OK 11.3.0 (2d280e7eafc086e9)(21 Apr 2022 07:59): [took: 0.02 s] result: OK 12.1.0 (1ea978e3066ac565)(06 May 2022 07:07): [took: 0.02 s] result: OK 12.2.0 (2ee5e4300186a92a)(19 Aug 2022 08:10): [took: 0.02 s] result: OK 13.0 (6bfea64164c3f198)(24 Oct 2022 10:31): [took: 0.02 s] result: OK
[Bug target/107315] support 128bit long double on aarch64 darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107315 --- Comment #3 from Iain Sandoe --- As Andrew says, we cannot alter the type of "long double" since the ABI specifies it is the same as double ... but .. we can (and have) add 16byte float support. -- The development branch for aarch64-darwin is here: https://github.com/iains/gcc-darwin-arm64 (this work will be upstreamed when I have some spare time) The issue of a 16byte float value was discussed here: https://github.com/iains/gcc-darwin-arm64/issues/5 Primarily, this was motivated by Fortran where support for REAL*16 is needed for at least some applications. The feedback from Apple was "if we were to implement 16byte float support, we'd use the ABI from AAPCS64". So, in the development branches, we have implemented the following type support (IEEE754, but of course, soft floating point) _Float128 __float128 REAL*16 In c-family and Fortran respectively.
[Bug tree-optimization/107176] [10/11/12/13 Regression] Wrong code at -Os on x86_64-pc-linux-gnu since r7-2012-g43aabfcfd4139e4c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107176 --- Comment #6 from Richard Biener --- Hmm, and interestingly this fix causes PR66375 to regress again: FAIL: gcc.dg/torture/pr66375.c -O2 execution test ... OK, so that's because my suggested fix is exactly an (incomplete) reversal of the fix for PR66375 (r6-1346-gb9b79ba4264cf6) :/
[Bug fortran/107373] New: Unexpected result with loop optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107373 Bug ID: 107373 Summary: Unexpected result with loop optimisation Product: gcc Version: 8.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: raphael.monod at wanadoo dot fr Target Milestone: --- Created attachment 53765 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53765&action=edit Source of test producing the bug (MWE) The attached test show the vector "tab_int_from_logical" contains -1, although +1 are expected. Compiler option -O3 is required to get this bug. Adding a print in the loop go around it. Degreasing the dimension 'IDIM' from 16 to 15 go around it. I do not have test all GCC releases, but I met this bug with release : 7.3.0, 8.2.0, 8.5.0, 9.4.0. Everything is good with releases 6.3.0, 11.3.0, 12.1.0 I known that releases used to produce this bug are no longer supported, bug I think that debian 10 (which is again supported) use 8.x GCC release.
[Bug target/107315] support 128bit long double on aarch64 darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107315 --- Comment #4 from hengxu010 --- Hi Iain , thank you very much! I'm very happy to hear that you have'd already implement the support for 16 bite float type in the development version of gcc, I can try that later. Hope the official version can be online soon. And thank you for taking time for answering these questions.
[Bug bootstrap/107120] [13 Regression] trunk fails to bootstrap on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107120 Matthias Klose changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED
[Bug c++/105725] [ICE] segfault with `-Wmismatched-tags`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105725 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:bd0c76a2329e7fe6d6612c2259647bbb67f5866a commit r11-10332-gbd0c76a2329e7fe6d6612c2259647bbb67f5866a Author: Marek Polacek Date: Fri May 27 10:51:30 2022 -0400 c++: Fix ICE with -Wmismatched-tags [PR105725] Here we ICE with -Wmismatched-tags on something like template bool B>>; Specifically, the "class T::foo" bit. There, class_decl_loc_t::add gets a TYPENAME_TYPE as TYPE, rather than a class/union type, so checking TYPE_BEING_DEFINED will crash. I think it's OK to allow a TYPENAME_TYPE to slip into that function; we just shouldn't consider the 'class' tag redundant (which works as a 'typename'). In fact, every other compiler *requires* it. PR c++/105725 gcc/cp/ChangeLog: * parser.c (class_decl_loc_t::add): Check CLASS_TYPE_P. gcc/testsuite/ChangeLog: * g++.dg/warn/Wmismatched-tags-10.C: New test. (cherry picked from commit d822f4bbd714c6595f70cc6dcebecfb6662d)
[Bug tree-optimization/107369] [13 Regression] ICE: verify_flow_info failed (error: label 'l1' has incorrect context in bb 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107369 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Created attachment 53766 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53766&action=edit gcc13-pr107369.patch Untested fix.
[Bug c++/105725] [ICE] segfault with `-Wmismatched-tags`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105725 Richard Biener changed: What|Removed |Added Known to fail||10.4.0, 11.3.0 Known to work||11.3.1 --- Comment #7 from Richard Biener --- And eleven based on request.
[Bug tree-optimization/107368] [13 Regression] ICE: 'verify_gimple' failed (error: non-trivial conversion in 'var_decl')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107368 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #1 from Jakub Jelinek --- Created attachment 53767 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53767&action=edit gcc13-pr107368.patch Untested fix.
[Bug sanitizer/107374] New: Please expand the size of flag_sanitize to uint64_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107374 Bug ID: 107374 Summary: Please expand the size of flag_sanitize to uint64_t Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: ashimida at linux dot alibaba.com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Currently, the size of flag_sanitize is 32 bits, and new options such as -fsanitize=kcfi cannot be accommodated in sanitize_code. Could it be scaled up to 64 bit? Thanks, Dan. Ref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107048
[Bug c/107048] GCC lacks -fsanitize=kcfi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107048 --- Comment #1 from ashimida --- (In reply to peterz from comment #0) > Please implement -fsanitize=kcfi to match llvm/clang: > > > https://github.com/samitolvanen/llvm-project/commit/ > f7bf6a87c4fd945800115a17b8b61390541fabd0 > > The Linux kernel patches are queued and slated for the next merge window. > Things like FineIBT rely on having this feature enabled. A related issue: Bug 107374 - Please expand the size of flag_sanitize to uint64_t Ref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107374
[Bug sanitizer/107374] Please expand the size of flag_sanitize to uint64_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107374 --- Comment #1 from Jakub Jelinek --- We don't do such things just for case, rather changes like that are done as part of a patch that adds the first thing that needs it.
[Bug sanitizer/107374] Please expand the size of flag_sanitize to uint64_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107374 --- Comment #2 from ashimida --- (In reply to Jakub Jelinek from comment #1) > We don't do such things just for case, rather changes like that are done as > part of a patch that adds the first thing that needs it. Ok, got it, thanks a lot :) Dan.
[Bug libstdc++/107371] __adaptor::_RangeAdaptor rejects the explicit move constructor case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107371
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
--- Comment #1 from Jonathan Wakely ---
This would fix it, but I don't know if there's a reason we pass by value here.
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -960,7 +960,7 @@ namespace views::__adaptor
_Arg _M_arg;
constexpr
- _Partial(_Arg __arg)
+ _Partial(_Arg&& __arg)
: _M_arg(std::move(__arg))
{ }
[Bug libstdc++/107371] __adaptor::_RangeAdaptor rejects the explicit move constructor case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107371 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2022-10-24 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug tree-optimization/107176] [10/11/12/13 Regression] Wrong code at -Os on x86_64-pc-linux-gnu since r7-2012-g43aabfcfd4139e4c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107176
--- Comment #7 from Richard Biener ---
(In reply to Richard Biener from comment #2)
> final value replacement:
> b_lsm.8_26 = PHI
> with expr: 1
> final stmt:
> b_lsm.8_26 = 1;
>
> where
>
> (get_scalar_evolution
> (scalar = b_lsm.8_15)
> (scalar_evolution = {0, +, 1}_1))
> (chrec_apply
> (varying_loop = 1)
> (chrec = {0, +, 1}_1)
> (x = 1)
> (res = 1))
>
> and
>
>[local count: 955630225]:
> _1 = (unsigned int) b_lsm.8_15;
> _2 = _1 + 4294967206;
> # RANGE [irange] long int [0, 4294967295] NONZERO 0x
> _12 = (long int) _2;
> # RANGE [irange] long int [91, 4294967386] NONZERO 0x1
> _3 = _12 + 91;
>
>[local count: 1073741824]:
> # b_lsm.8_15 = PHI <0(2), _3(3)>
For comparison in PR66375 we have
:
# c_6 = PHI <0(2), c_12(3)>
a.1_5 = a;
if (a.1_5 <= 12)
goto ; [INV]
else
goto ; [INV]
:
_1 = (signed char) c_6;
_2 = (int) _1;
c_12 = _2 + -11;
_4 = a.1_5 + 1;
a = _4;
goto ;
so the backedge definition is
(long)((unsigned)IV + -90u) + 91
vs.
(int)(signed char)IV + -11
I think the issue is the CONVERT_EXPR handling in follow_ssa_edge_expr where
it isn't all that clear in which case we can analyze the evolution in the
narrower or the wider type. In the case in this PR we mishandled the
middle conversion while in the older case we mishandle the "initial"
conversion. I suspect that trying to optimize things on-the-fly is
difficult (and reasoning about the relevant cases there).
I've tried (again) to more correctly have the current evolution tentative
until we hit the loop PHI again when following the use-def chain from the
latch definition, but then we don't even know whether we will have an
evolution in the end (tried { initial, +, scev_not_known }). Going fully
symbolic will lead to the issue pointed out in comment 6 of PR66375,
we'd get { (int)(signed char)0, +, -11 } which isn't what we want.
If, as in this bug, we have two evolutions in different types, we probably
have to give up. Maybe we need to think of a PLUS as { unknown, +, val }
and instead fend off "wrongly" typed evolutions when we reach the
loop PHI node again. But then the PR66375 case _does_ have an expression
correctly describing the evolution of the IV. Just in this PRs case there
is none I think. Or rather, I guess it would be
{ (long){ 0u, +, -90u }_1, +, 90 }_1 but that wouldn't be affine at least.
[Bug tree-optimization/107365] ICE in verify_range, at value-range.cc:726
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107365 --- Comment #3 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:1e9d9ed095df3d064cf9d91d46f3e5426c2a05a7 commit r13-3453-g1e9d9ed095df3d064cf9d91d46f3e5426c2a05a7 Author: Aldy Hernandez Date: Sun Oct 23 16:51:17 2022 +0200 Check HONOR_NANS instead of flag_finite_math_only in frange:verify_range. [Jakub and other FP experts, would this be OK, or am I missing something?] Vax does not seem to have !flag_finite_math_only, but float_type_node does not HONOR_NANS. The check in frange::verify_range dependend on flag_finite_math_only, which is technically not correct since frange::set_varying() checks HONOR_NANS instead of flag_finite_math_only. I'm actually getting tired of flag_finite_math_only and !flag_finite_math_only discrepancies in the selftests (Vax and rx-elf come to mind). I think we should just test both alternatives in the selftests as in this patch. We could also check flag_finite_math_only=0 with a float_type_node that does not HONOR_NANs, but I have no idea how to twiddle FLOAT_MODE_FORMAT temporarily, and that may be over thinking it. PR tree-optimization/107365 gcc/ChangeLog: * value-range.cc (frange::verify_range): Predicate NAN check in VARYING range on HONOR_NANS instead of flag_finite_math_only. (range_tests_floats): Same. (range_tests_floats_various): New. (range_tests): Call range_tests_floats_various.
[Bug tree-optimization/107365] ICE in verify_range, at value-range.cc:726
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107365 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Aldy Hernandez --- fixed
[Bug middle-end/107355] [13 Regression] ICE: in lower_bound, at value-range.h:350 with -fsanitize=float-cast-overflow since r13-3231-g706d8583706475fb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107355 --- Comment #2 from Aldy Hernandez --- Created attachment 53768 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53768&action=edit untested
[Bug fortran/107375] New: CFI_cdesc_t incorrectly reports non-interoperable C structure as such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107375
Bug ID: 107375
Summary: CFI_cdesc_t incorrectly reports non-interoperable C
structure as such
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jeff.science at gmail dot com
Target Milestone: ---
Interoperable C structs are not permitted to contain allocatable members, among
other things.
The compiler should report that types containing allocatable members are
CFI_type_other, not CFI_type_struct.
I was not sure if the Fortran code was illegal or if the CFI_cdesc_t was
populated incorrectly, but another member of WG5 said it was the latter.
% gcc-12 -g -std=c11 -c foo.c -o foo.o
% gfortran-12 -g -std=f2018 class.F90 foo.o -o class.x
% ./class.x
CFI_cdesc_t.type = interoperable C structure
==> foo.c <==
#include
#include
#include "ISO_Fortran_binding.h"
char * get_type(CFI_type_t t)
{
switch(t) {
case CFI_type_cptr : return "void *";break;
case CFI_type_struct : return "interoperable C structure"; break;
case CFI_type_other : return "Not otherwise specified"; break;
default : abort();
}
}
void foo(CFI_cdesc_t * d)
{
printf("CFI_cdesc_t.type = %s\n", get_type(d->type));
}
==> class.F90 <==
module m
type :: t
integer :: i
double precision :: d
integer :: j(10)
real :: r(100)
real, allocatable :: z(:)
end type t
interface
subroutine foo(t) bind(C)
implicit none
type(*), dimension(..) :: t
end subroutine foo
end interface
end module m
program main
use m
implicit none
type(t) :: x
call foo(x)
end program main
% gfortran-12 -v
Using built-in specs.
COLLECT_GCC=gfortran-12
COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc/12.2.0/bin/../libexec/gcc/aarch64-apple-darwin21/12/lto-wrapper
Target: aarch64-apple-darwin21
Configured with: ../configure --prefix=/opt/homebrew/opt/gcc
--libdir=/opt/homebrew/opt/gcc/lib/gcc/current --disable-nls
--enable-checking=release --with-gcc-major-version-only
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-12
--with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr
--with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl
--with-zstd=/opt/homebrew/opt/zstd --with-pkgversion='Homebrew GCC 12.2.0'
--with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--with-system-zlib --build=aarch64-apple-darwin21
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Homebrew GCC 12.2.0)
[Bug driver/71850] @file should be used to cc1/cc1plus when @file is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71850
Costas Argyris changed:
What|Removed |Added
CC||costas.argyris at gmail dot com
--- Comment #6 from Costas Argyris ---
A few things have changed since the last update:
cc1 is no longer the problem, and it is not the subprocess that breaks for >
32k worth of command line arguments, but the bug has not gone away completely
because another subprocess still breaks after cc1, and that is the assembler
(as) this time.
At the time the bug was reported (version 6.1.0), the specs language did not
have the %@{...} feature, and include paths were handled in cpp_unique_options
as %{I*&F*}
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/gcc.c;h=7460f6af148969734c6cffeef870388355ef76cf;hb=HEAD#l1105
This was causing the include path arguments to get passed to cc1 verbatim, i.e.
without being stored in a temporary @file and that file being passed to cc1
instead (assuming a @file was given to gcc in the first place).Note that
there existed ways to create temporary @files back then (as pointed out by
Andrew), but they were not backed by the specs language itself through %@{...}.
Same for the assembler with %{I*}
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/gcc.c;h=7460f6af148969734c6cffeef870388355ef76cf;hb=HEAD#l1151
but it never got to that point because it was crashing earlier in cc1 when the
include paths were more than 32k bytes.
The %@{...} syntax didn't exist back then because it doesn't show up neither in
the source code above nor in the 6.1.0 doc
https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/Spec-Files.htmland search for
%@, no hits
Some time between then and now %@{...} was added in the specs language
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Spec-Files.html %@ has a hit
now
and is now being used for the linker -L flags
https://github.com/gcc-mirror/gcc/blob/releases/gcc-12/gcc/gcc.cc#L1162
and preprocessor include paths -I
https://github.com/gcc-mirror/gcc/blob/releases/gcc-12/gcc/gcc.cc#L1238
The latter silently fixed the problem with cc1 because it now takes a temporary
file instead of the raw include paths (assuming a @file was given to gcc to
begin with).But now we just hit the same problem with the assembler,
because that one did not get updated to use %@{I*} and still uses %{I*}
https://github.com/gcc-mirror/gcc/blob/releases/gcc-12/gcc/gcc.cc#L1294
So right now it is 'as' that is breaking due to the 32k limit on Windows, not
'cc1'.Simply adding the @ symbol for the include args in asm_options fixes
the issue.See the experiments below for more details.
$ gcc --version
gcc.exe (Rev4, Built by MSYS2 project) 12.2.0
sample response file with > 32k worth of include paths
$ head -n3 rsp
-I/akjdhaskjdhfskjdfhakjsdhfkjlsahdfkjashdfasdkjfsadfasdkfjhsdakfjhds/asdkljfhsadkjfhaskjdfhkjasdhfkjashdfkjashfsdklafhdskjfhjkfhskjfhsakdjfh/LJHFDJKHSDKJFHASKDJdkjfghskdjfhgksdjfg/fgsdklfjghskdjfhgdksjfghdskjfgh
-I/akjdhaskjdhfskjdfhakjsdhfkjlsahdfkjashdfasdkjfsadfasdkfjhsdakfjhds/asdkljfhsadkjfhaskjdfhkjasdhfkjashdfkjashfsdklafhdskjfhjkfhskjfhsakdjfh/LJHFDJKHSDKJFHASKDJdkjfghskdjfhgksdjfg/fgsdklfjghskdjfhgdksjfghdskjfgh
-I/akjdhaskjdhfskjdfhakjsdhfkjlsahdfkjashdfasdkjfsadfasdkfjhsdakfjhds/asdkljfhsadkjfhaskjdfhkjasdhfkjashdfkjashfsdklafhdskjfhjkfhskjfhsakdjfh/LJHFDJKHSDKJFHASKDJdkjfghskdjfhgksdjfg/fgsdklfjghskdjfhgdksjfghdskjfgh
$ wc --chars rsp
37914 rsp
$ gcc -v @rsp src.c
...
...
...
C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.2.0/cc1.exe -quiet -v
@C:\msys64\tmp\ccHiOua0 -D_REENTRANT src.c -quiet -dumpdir a- -dumpbase src.c
-dumpbase-ext .c -mtune=generic -march=x86-64 -version -o
C:\msys64\tmp\ccsGuieQ.s
...
...
...
C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/as.exe
-v -I
/akjdhaskjdhfskjdfhakjsdhfkjlsahdfkjashdfasdkjfsadfasdkfjhsdakfjhds/asdkljfhsadkjfhaskjdfhkjasdhfkjashdfkjashfsdklafhdskjfhjkfhskjfhsakdjfh/LJHFDJKHSDKJFHASKDJdkjfghskdjfhgksdjfg/fgsdklfjghskdjfhgdksjfghdskjfgh
-I
/akjdhaskjdhfskjdfhakjsdhfkjlsahdfkjashdfasdkjfsadfasdkfjhsdakfjhds/asdkljfhsadkjfhaskjdfhkjasdhfkjashdfkjashfsdklafhdskjfhjkfhskjfhsakdjfh/LJHFDJKHSDKJFHASKDJdkjfghskdjfhgksdjfg/fgsdklfjghskdjfhgdksjfghdskjfgh
-I -o C:\msys64\tmp\ccy7bVd1.o C:\msys64\tmp\ccsGuieQ.s
gcc.exe: fatal error: cannot execute
'C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/as.exe':
CreateProcess: No such file or directory
compilation terminated.
cc1.exe is OK because it takes a temporary @file, but as.exe takes the include
paths so it breaks.Confirm this by observing how include args are handled
in the two subprocesses.
$ gcc -dumpspecs | grep "{I" -C1
*asm_options:
%{-target-help:%:print-asm-header()} %{v} %{w:-W} %{I*} %(asm_debug_option)
%{gz|gz=zlib-gnu:--compress-debug-sections}
%{gz=none:--nocompress-deb
[Bug fortran/107373] Unexpected result with loop optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107373 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-10-24 CC||marxin at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Fixed on master with r10-5067-gce19a48227949920.
[Bug fortran/107373] Unexpected result with loop optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107373 Martin Liška changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #2 from Martin Liška --- And started with r7-5505-ga388bdc777f58251.
[Bug fortran/107373] Unexpected result with loop optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107373 --- Comment #3 from Janne Blomqvist --- 63ee540430c3 might be related wrt fixing it?
[Bug libstdc++/107376] New: regex executor requires allocator to be default constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107376
Bug ID: 107376
Summary: regex executor requires allocator to be default
constructible
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: listcrawler at gmail dot com
Target Milestone: ---
To recreate problem:
#include
#include
template
struct Alloc
{
using value_type = T;
T* allocate(std::size_t n)
{
return std::allocator{}.allocate(n);
}
void deallocate(T* p, std::size_t n)
{
std::allocator{}.deallocate(p, n);
}
~Alloc() = default;
//explicit Alloc() = default;
explicit Alloc(int) {}
Alloc(Alloc const&) = default;
Alloc(Alloc && rhs) = default;
Alloc& operator=(Alloc const&) = default;
Alloc& operator=(Alloc && rhs) = default;
template Alloc(Alloc const& rhs) {}
template Alloc(Alloc && rhs) {}
template Alloc& operator=(Alloc const& rhs) {}
template Alloc& operator=(Alloc && rhs) {}
};
template
bool operator==(Alloc const&, Alloc const&)
{
return true;
}
template
bool operator!=(Alloc const&, Alloc const&)
{
return false;
}
// ===
template using A = Alloc;
using S= std::string;
using SIt = typename S::const_iterator;
using SubMatch = std::sub_match;
using Match= std::match_results>;
int main()
{
S s {"foo"};
Match m {A{0}};
std::regex r {"foo"};
std::regex_match(s, m, r);
}
Suggested patch:
diff --git a/libstdc++-v3/include/bits/regex_executor.h
b/libstdc++-v3/include/bits/regex_executor.h
index dc0878ce6..080a1134e 100644
--- a/libstdc++-v3/include/bits/regex_executor.h
+++ b/libstdc++-v3/include/bits/regex_executor.h
@@ -71,7 +71,8 @@ namespace __detail
_ResultsVec&__results,
const _RegexT& __re,
_FlagT __flags)
- : _M_begin(__begin),
+ : _M_cur_results(__results.get_allocator())
+ , _M_begin(__begin),
_M_end(__end),
_M_re(__re),
_M_nfa(*__re._M_automaton),
[Bug tree-optimization/102516] [12/13 regression] pr65947-13.c and vect-alias-check-18.c fail on armeb since r12-3893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102516 --- Comment #9 from Christophe Lyon --- Indeed it works again on trunk, I bisected and it started with one of our commits: r12-3958-g4c7731081647c22cbd249dc0faa20c3df9ed6411 Author: Richard Biener Date: Wed Sep 29 11:18:23 2021 +0200 Fix peeling for alignment with negative step The following fixes a regression causing us to no longer peel negative step loops for alignment. With dr_misalignment now applying the bias for negative step we have to do the reverse when adjusting the misalignment for peeled DRs. 2021-09-29 Richard Biener * tree-vect-data-refs.c (vect_dr_misalign_for_aligned_access): New helper. (vect_update_misalignment_for_peel): Use it to update misaligned to the value necessary for an aligned access. (vect_get_peeling_costs_all_drs): Likewise. (vect_enhance_data_refs_alignment): Likewise. * gcc.target/i386/vect-alignment-peeling-1.c: New testcase. * gcc.target/i386/vect-alignment-peeling-2.c: Likewise. We still have FAIL: gcc.dg/vect/pr65947-13.c scan-tree-dump-times vect "condition expression based on integer induction." 2 but based on the original report, this was already present
[Bug other/107353] [13 regression] Numerous ICEs after r13-3416-g1d561e1851c466
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107353 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0 Priority|P3 |P1
[Bug middle-end/107355] [13 Regression] ICE: in lower_bound, at value-range.h:350 with -fsanitize=float-cast-overflow since r13-3231-g706d8583706475fb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107355 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/107358] [13 Regression] i686-linux: Since r13-3290-g98e341130f8798 code fails to build libjxl-0/7.0 (vector float code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107358 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |13.0
[Bug target/107364] [10/11/12/13 Regression] ICE on Via Nehemiah with --march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107364 --- Comment #2 from Thomas Capricelli --- Sure, easy chopin /tmp # ./cpuid __get_cpuid(0): eax=1, ebx=1953391939, ecx=193648, edx=1215460705 __get_cpuid(1): eax=1683, ebx=0, ecx=0, edx=58765629 I't not better in hexa ? : __get_cpuid(0): eax=1, ebx=746e6543, ecx=736c7561, edx=48727561 __get_cpuid(1): eax=693, ebx=0, ecx=0, edx=380b13d (what would be a lot less easy, is to recompile gcc.. it takes days on this machine) there's also this command available: CPU 0: vendor_id = "CentaurHauls" version information (1/eax): processor type = primary processor (0) family = 0x6 (6) model = 0x9 (9) stepping id = 0x3 (3) extended family = 0x0 (0) extended model = 0x0 (0) (family synth) = 0x6 (6) (model synth) = 0x9 (9) (simple synth) = VIA C3 / Eden ESP 7000/8000/1 (Nehemiah C5XL), .13um miscellaneous (1/ebx): process local APIC physical ID = 0x0 (0) maximum IDs for CPUs in pkg= 0x0 (0) CLFLUSH line size = 0x0 (0) brand index= 0x0 (0) brand id = 0x00 (0): unknown feature information (1/edx): x87 FPU on chip= true VME: virtual-8086 mode enhancement = false DE: debugging extensions = true PSE: page size extensions = true TSC: time stamp counter= true RDMSR and WRMSR support= true PAE: physical address extensions = false MCE: machine check exception = false CMPXCHG8B inst.= true APIC on chip = false SYSENTER and SYSEXIT = false MTRR: memory type range registers = true PTE global bit = true MCA: machine check architecture= false CMOV: conditional move/compare instr = true PAT: page attribute table = false PSE-36: page size extension= false PSN: processor serial number = false CLFLUSH instruction= false DS: debug store= false ACPI: thermal monitor and clock ctrl = false MMX Technology = true FXSAVE/FXRSTOR = true SSE extensions = true SSE2 extensions= false SS: self snoop = false hyper-threading / multi-core supported = false TM: therm. monitor = false IA64 = false PBE: pending break event = false feature information (1/ecx): PNI/SSE3: Prescott New Instructions = false PCLMULDQ instruction= false DTES64: 64-bit debug store = false MONITOR/MWAIT = false CPL-qualified debug store = false VMX: virtual machine extensions = false SMX: safer mode extensions = false Enhanced Intel SpeedStep Technology = false TM2: thermal monitor 2 = false SSSE3 extensions= false context ID: adaptive or shared L1 data = false SDBG: IA32_DEBUG_INTERFACE = false FMA instruction = false CMPXCHG16B instruction = false xTPR disable= false PDCM: perfmon and debug = false PCID: process context identifiers = false DCA: direct cache access= false SSE4.1 extensions = false SSE4.2 extensions = false x2APIC: extended xAPIC support = false MOVBE instruction = false POPCNT instruction = false time stamp counter deadline = false AES instruction = false XSAVE/XSTOR states = false OS-enabled XSAVE/XSTOR = false AVX: advanced vector extensions = false F16C half-precision convert instruction = false RDRAND instruction = false hypervisor guest status = false extended processor signature (0x8001/eax): generation = 0x0 (0) model = 0x0 (0) stepping = 0x0 (0) (simple synth) = unknown extended feature flags (0x8001/edx): x87 FPU on chip = false virtual-8086 mode enhancement = false debugging extensions = false page size extensions = false time stamp counter= false RDMSR and WRMSR suppor
[Bug fortran/107373] Unexpected result with loop optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107373 --- Comment #4 from Martin Liška --- (In reply to Janne Blomqvist from comment #3) > 63ee540430c3 might be related wrt fixing it? r8-4424-g63ee540430c32a
[Bug tree-optimization/107368] [13 Regression] ICE: 'verify_gimple' failed (error: non-trivial conversion in 'var_decl')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107368 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |13.0
[Bug tree-optimization/107369] [13 Regression] ICE: verify_flow_info failed (error: label 'l1' has incorrect context in bb 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107369 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0 Keywords||error-recovery
[Bug middle-end/107236] [OpenMP] ICE for reverse offload: in expand_GOMP_TARGET_REV, at internal-fn.cc:376
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107236 --- Comment #2 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:178ac530fe67e4f2fc439cc4ce89bc19d571ca31 commit r13-3455-g178ac530fe67e4f2fc439cc4ce89bc19d571ca31 Author: Tobias Burnus Date: Mon Oct 24 15:19:00 2022 +0200 OpenMP: Fix reverse offload GOMP_TARGET_REV IFN corner cases [PR107236] For 'target parallel' and similarly nested directives, cgraph_node's calls_declare_variant_alt was not set in the parent region node but in cfun->decl. Hence, pass_omp_device_lower did not process handle the internal function GOMP_TARGET_REV. - Solution is to set it to the DECL_CONTEXT, which is set in adjust_context_and_scope. The cgraph_node::create_clone issue is exposed with -O2 for the existing libgomp.fortran/reverse-offload-1.f90. PR middle-end/107236 gcc/ChangeLog: * omp-expand.cc (expand_omp_target): Set calls_declare_variant_alt in DECL_CONTEXT and not to cfun->decl. * cgraphclones.cc (cgraph_node::create_clone): Copy also the node's calls_declare_variant_alt value. gcc/testsuite/ChangeLog: * gfortran.dg/gomp/target-device-ancestor-6.f90: New test.
[Bug tree-optimization/107372] Loop distribution creates memcpy between structs with different storage order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107372 --- Comment #2 from Richard Biener --- (In reply to Andreas Krebbel from comment #1) > Created attachment 53764 [details] > Experimental Fix > > Looks like the error while analyzing the data ref is not propagated to the > upper layers to actually prevent the optimization. This patch fixes this for > me. But that's on purpose I think. create_data_ref does never "fail", the caller has to check for proper analysis of the DR though. For loop distribution we should FAIL looking at DR_STEP? Ah, for example compute_access_range performs its own analysis so it needs to check for the storage order itself I think or the callers need to match up storage order of source and destination. Your patch leaks memory.
[Bug fortran/107373] Unexpected result with loop optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107373 Richard Biener changed: What|Removed |Added Known to fail||9.4.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Richard Biener --- In any case it's fixed in all still maintained GCC releases.
[Bug middle-end/107236] [OpenMP] ICE for reverse offload: in expand_GOMP_TARGET_REV, at internal-fn.cc:376
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107236 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tobias Burnus --- FIXED on GCC 13/mainline.
[Bug tree-optimization/107176] [10/11/12/13 Regression] Wrong code at -Os on x86_64-pc-linux-gnu since r7-2012-g43aabfcfd4139e4c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107176
Richard Biener changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=42512
--- Comment #8 from Richard Biener ---
PR42512 is also related and its "fix" is even worse... it's worse in that
it hides wrong cases but also throws away correct ones. But it also
shows that we still mishandle that testcase with or without the fix(es).
It seems that the intent of the SCC analysis in interpret_loop_phi is to
look at the linear operation (or the chain of linear operations) associated
in a way that it matches
(T2)(init + ev)
from which then (T2) { init, +, ev } follows.
So when
PHI' = (int)(signed char)PHI + 11
we directly match (int)(signed char){ init, +, 11 }
and for
PHI' = (long)((unsigned)PHI + -90u) + 91
we'd have to associate the outer + 91 which we can't do (but effectively
do due to the present bug).
[Bug middle-end/107355] [13 Regression] ICE: in lower_bound, at value-range.h:350 with -fsanitize=float-cast-overflow since r13-3231-g706d8583706475fb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107355 --- Comment #3 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:5bcd92d0d4029f3d1d2eacc0e2bff1685545b74f commit r13-3456-g5bcd92d0d4029f3d1d2eacc0e2bff1685545b74f Author: Aldy Hernandez Date: Mon Oct 24 12:37:25 2022 +0200 [PR tree-optimization/107355] Handle NANs in abs range-op entry. The problem here is that the threader is coming up with a path where the only valid result is a NAN. When the abs op1_range entry is trying to add the negative posibility, it attempts to get the bounds of the working range. NANs don't have bounds so they need to be special cased. PR tree-optimization/107355 gcc/ChangeLog: * range-op-float.cc (foperator_abs::op1_range): Handle NAN. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/pr107355.c: New test.
[Bug middle-end/107355] [13 Regression] ICE: in lower_bound, at value-range.h:350 with -fsanitize=float-cast-overflow since r13-3231-g706d8583706475fb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107355 --- Comment #4 from Aldy Hernandez --- fixed
[Bug middle-end/107355] [13 Regression] ICE: in lower_bound, at value-range.h:350 with -fsanitize=float-cast-overflow since r13-3231-g706d8583706475fb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107355 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Aldy Hernandez --- ...and closed :-).
[Bug target/107364] [10/11/12/13 Regression] ICE on Via Nehemiah with --march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107364 --- Comment #3 from Martin Liška --- Created attachment 53769 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53769&action=edit Tentative patch Have a patch for the ICE. Can you please output what you see with -march=native now? Ideally if you use --verbose argument for the GCC compiler.
[Bug c/107377] New: Warn about duplicate enum values?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107377
Bug ID: 107377
Summary: Warn about duplicate enum values?
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
Target Milestone: ---
Noticed that while investigating PR107364:
enum processor_vendor
{
VENDOR_INTEL = 1,
VENDOR_AMD,
VENDOR_ZHAOXIN,
VENDOR_OTHER,
VENDOR_CENTAUR,
VENDOR_CYRIX,
VENDOR_NSC,
BUILTIN_VENDOR_MAX = VENDOR_OTHER,
VENDOR_MAX
};
As one can see VENDOR_CENTAUR == 5, but VENDOR_MAX is also == 5 as
BUILTIN_VENDOR_MAX points to 4 and thus VENDOR_MAX == 5.
Maybe we can warn about 2 enum values that have the same value and none of them
is defined with '= some_value'. What do you think?
[Bug target/107364] [10/11/12/13 Regression] ICE on Via Nehemiah with --march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107364 --- Comment #4 from Martin Liška --- > there's also this command available: What command does produce that?
[Bug c++/105774] Bogus overflow in constant expression with signed char++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105774
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:da8c362c4c18cff2f2dfd5c4706bdda7576899a4
commit r13-3458-gda8c362c4c18cff2f2dfd5c4706bdda7576899a4
Author: Jakub Jelinek
Date: Mon Oct 24 16:25:29 2022 +0200
c++: Fix up constexpr handling of char/signed char/short pre/post
inc/decrement [PR105774]
signed char, char or short int pre/post inc/decrement are represented by
normal {PRE,POST}_{INC,DEC}REMENT_EXPRs in the FE and only gimplification
ensures that the {PLUS,MINUS}_EXPR is done in unsigned version of those
types:
case PREINCREMENT_EXPR:
case PREDECREMENT_EXPR:
case POSTINCREMENT_EXPR:
case POSTDECREMENT_EXPR:
{
tree type = TREE_TYPE (TREE_OPERAND (*expr_p, 0));
if (INTEGRAL_TYPE_P (type) && c_promoting_integer_type_p (type))
{
if (!TYPE_OVERFLOW_WRAPS (type))
type = unsigned_type_for (type);
return gimplify_self_mod_expr (expr_p, pre_p, post_p, 1, type);
}
break;
}
This means during constant evaluation we need to do it similarly (either
using unsigned_type_for or using widening to integer_type_node).
The following patch does the latter.
2022-10-24 Jakub Jelinek
PR c++/105774
* constexpr.cc (cxx_eval_increment_expression): For signed types
that promote to int, evaluate PLUS_EXPR or MINUS_EXPR in int type.
* g++.dg/cpp1y/constexpr-105774.C: New test.
[Bug analyzer/107345] - -Wanayzer-null-dereference false positive with giving weird path infomation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107345 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-10-24 --- Comment #1 from David Malcolm --- Thanks for filing this bug. The analyzer is seeing NULL == &e and fails to treat this as being false; the logic for spotting comparison of &VAR against NULL was only looking for NULL on the right-hand side. I'm working on a fix.
[Bug target/106583] Suboptimal immediate generation on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106583 --- Comment #2 from CVS Commits --- The master branch has been updated by Wilco Dijkstra : https://gcc.gnu.org/g:a096036589d82175a0f729c2dab73c9a527d075d commit r13-3459-ga096036589d82175a0f729c2dab73c9a527d075d Author: Wilco Dijkstra Date: Mon Oct 24 15:14:14 2022 +0100 [AArch64] Improve immediate expansion [PR106583] Improve immediate expansion of immediates which can be created from a bitmask immediate and 2 MOVKs. Simplify, refactor and improve efficiency of bitmask checks. Move various immediate handling functions together to avoid forward declarations. This reduces the number of 4-instruction immediates in SPECINT/FP by 10-15%. gcc/ PR target/106583 * config/aarch64/aarch64.cc (aarch64_internal_mov_immediate) Add support for a bitmask immediate with 2 MOVKs. (aarch64_check_bitmask): New function after refactorization. (aarch64_bitmask_imm): Simplify replication of small modes. Split function into 64-bit only version for efficiency. (aarch64_move_imm): Move near other immediate functions. (aarch64_uimm12_shift): Likewise. (aarch64_clamp_to_uimm12_shift): Likewise. (aarch64_movk_shift): Likewise. (aarch64_replicate_bitmask_imm): Likewise. (aarch64_and_split_imm1): Likewise. (aarch64_and_split_imm2): Likewise. (aarch64_and_bitmask_imm): Likewise. (aarch64_movw_imm): Likewise. gcc/testsuite/ PR target/106583 * gcc.target/aarch64/pr106583.c: Add new test.
[Bug libstdc++/95048] [10/11/12/13 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048 Ulf Lorenz changed: What|Removed |Added CC||ulf.lorenz at ptvgroup dot com --- Comment #15 from Ulf Lorenz --- I have submitted a patch to the patch mailing list on 19th. I assume it needs someone to review.
[Bug analyzer/107366] ICE with -fanalyzer with -fdiagnostics-format=sarif-file or sarif-stderr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107366 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from David Malcolm --- Rainer: thanks for filing this bug. Martin: thanks for reducing it and identifying the fix. I believe it's correct, and am bootstrapping a patch containing it.
[Bug target/107370] long double precision is wrong in ARM 64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107370 --- Comment #2 from Andrew Pinski --- I get the following output from ubuntu 1804's gcc and the trunk of gcc from 20220808: ubuntu@ubuntu:~/src/upstream-gcc\# ~/upstream-gcc/bin/gcc t54.c -O2 ubuntu@ubuntu:~/src/upstream-gcc\# ./a.out 1.4142135623730950488 trunk gcc: .LC1: .word 325511829 .word -922176773 .word -429395012 .word 1073703433 ubuntu gcc: .LC0: .word 325511829 .word 3372790523 .word 3865572284 .word 1073703433 Both of these are the same, just unsigned vs signed output. As far as I can tell, this is not a GCC issue. It might be a binutils issue or a glibc issue with printf.
[Bug driver/107007] libiberty's win32_spawn error handling is poor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107007 Costas Argyris changed: What|Removed |Added CC||costas.argyris at gmail dot com --- Comment #1 from Costas Argyris --- A potential improvement in the win32_spawn function could be to check the length of cmdline https://github.com/gcc-mirror/gcc/blob/master/libiberty/pex-win32.c#L625 before passing it to CreateProcess https://github.com/gcc-mirror/gcc/blob/master/libiberty/pex-win32.c#L630 because we know from https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa#parameters that the second argument cannot be more than 32,767 characters. So if we can check that before even making the call to CreateProcess, why bother doing a call that we know will fail? Perhaps the check could be done inside the argv_to_cmdline function itself. This function mentions the 32k limit in its comments https://github.com/gcc-mirror/gcc/blob/master/libiberty/pex-win32.c#L350 but doesn't actually consider it in the code.Looks like the length has been decided by the time we reach https://github.com/gcc-mirror/gcc/blob/master/libiberty/pex-win32.c#L385 in the cmdline_len variable, so it should be just a simple numerical check that this value is less than or equal to 32,767 before doing the memory allocation. If greater, it could just return NULL without allocating any memory and the (single) caller at https://github.com/gcc-mirror/gcc/blob/master/libiberty/pex-win32.c#L625 already deals with NULL.
[Bug c/107377] Warn about duplicate enum values?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107377 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c/107377] Warn about duplicate enum values?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107377 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of much older bug 16186. *** This bug has been marked as a duplicate of bug 16186 ***
[Bug c/16186] gcc should have an option to warn about enumerations with duplicate values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16186 Andrew Pinski changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- *** Bug 107377 has been marked as a duplicate of this bug. ***
[Bug libstdc++/107378] New: `get_if` implementation "is not a constant expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107378
Bug ID: 107378
Summary: `get_if` implementation "is not a constant expression"
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
Target Milestone: ---
See https://godbolt.org/z/cf1T7q6Tj.
```C++
#include
static_assert([v = std::variant{}] { return get_if<0>(&v); }());
```
```
:2:67: error: non-constant condition for static assertion
2 | static_assert([v = std::variant{}] { return get_if<0>(&v); }());
| ^~
In file included from :1:
:2:67: in 'constexpr' expansion of '{std::variant{std::__detail::__variant::_Variant_base{std::__detail::__variant::_Move_assign_base{std::__detail::__variant::_Copy_assign_base{std::__detail::__variant::_Move_ctor_base{std::__detail::__variant::_Copy_ctor_base{std::__detail::__variant::_Variant_storage{std::__detail::__variant::_Variadic_union{std::__detail::__variant::_Uninitialized{0}}, 0.()'
:2:60: in 'constexpr' expansion of 'std::get_if<0, int*>((& v))'
/opt/compiler-explorer/gcc-trunk-20221024/include/c++/13.0.0/variant:1183:11:
error: '((&.::__v) != 0)' is not a constant expression
1183 | if (__ptr && __ptr->index() == _Np)
| ^
Compiler returned: 1
```
[Bug c++/107358] [13 Regression] i686-linux: Since r13-3290-g98e341130f8798 code fails to build libjxl-0/7.0 (vector float code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107358 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:65e3274e363cb2c6bfe6b5e648916eb7696f7e2f commit r13-3461-g65e3274e363cb2c6bfe6b5e648916eb7696f7e2f Author: Jakub Jelinek Date: Mon Oct 24 17:53:16 2022 +0200 c, c++: Fix up excess precision handling of scalar_to_vector conversion [PR107358] As mentioned earlier in the C++ excess precision support mail, the following testcase is broken with excess precision both in C and C++ (though just in C++ it was triggered in real-world code). scalar_to_vector is called in both FEs after the excess precision promotions (or stripping of EXCESS_PRECISION_EXPR), so we can then get invalid diagnostics that say float vector + float involves truncation (on ia32 from long double to float). The following patch fixes that by calling scalar_to_vector on the operands before the excess precision promotions, let scalar_to_vector just do the diagnostics (it does e.g. fold_for_warn so it will fold EXCESS_PRECISION_EXPR around REAL_CST to constants etc.) but will then do the actual conversions using the excess precision promoted operands (so say if we have vector double + (float + float) we don't actually do vector double + (float) ((long double) float + (long double) float) but vector double + (double) ((long double) float + (long double) float) 2022-10-24 Jakub Jelinek PR c++/107358 gcc/c/ * c-typeck.cc (build_binary_op): Pass operands before excess precision promotions to scalar_to_vector call. gcc/cp/ * typeck.cc (cp_build_binary_op): Pass operands before excess precision promotions to scalar_to_vector call. gcc/testsuite/ * c-c++-common/pr107358.c: New test. * g++.dg/cpp1y/pr68180.C: Remove -fexcess-precision=fast from dg-options.
[Bug c++/107358] [13 Regression] i686-linux: Since r13-3290-g98e341130f8798 code fails to build libjxl-0/7.0 (vector float code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107358 --- Comment #5 from Jakub Jelinek --- Should be fixed now on the trunk. I'll backport the C part later.
[Bug c++/107378] `get_if` implementation "is not a constant expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107378 Andrew Pinski changed: What|Removed |Added Component|libstdc++ |c++ --- Comment #1 from Andrew Pinski --- I suspect this is a front-end issue and not a library issue.
[Bug c++/85043] -Wuseless-cast false positive for temporary objects; add separate -Wcast-to-the-same-type to cover that case instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85043 --- Comment #18 from Marek Polacek --- The casts that are still warned about should really be useless so I don't plan to add another warning.
[Bug c++/107378] `get_if` implementation "is not a constant expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107378 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Last reconfirmed||2022-10-24 Status|UNCONFIRMED |NEW
[Bug c++/107363] Wrong caret location for "redundant move in return statement" and nvo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107363 Marek Polacek changed: What|Removed |Added Last reconfirmed||2022-10-24 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Marek Polacek --- (In reply to Daniel Bertalan from comment #0) > As an aside, it's a bit annoying to have this warning when the moved type > depends on a template parameter in library code. We are forced to either > silence this warning with a #pragma, or use concepts to have a variant of > the release_value method that does not call std::move for const-qualified T. Understood, I thought I'd fixed cases like that in https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=6602a2b2dee16af6e2d451c704789356042b5881 Something's not right here. I need to take a closed look. Thanks for reporting the bug.
[Bug other/107379] New: [13 regression] g++.dg/modules/adl-3_c.C and adl-4_b.C break as of r13-2887-gb04208895fed34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107379 Bug ID: 107379 Summary: [13 regression] g++.dg/modules/adl-3_c.C and adl-4_b.C break as of r13-2887-gb04208895fed34 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:b04208895fed34171eac6bafb60c90048eb1cb0c, r13-2887-gb04208895fed34 These failures occur on a powerpc64 system that is using IEEE128. Note that this commit is also the one that broke trunk for powerpc64 and some later patches are needed to get the compiler to build. It does still fail with current trunk where the compiler builds OK. FAIL: g++.dg/modules/adl-3_c.C -std=c++2a (test for errors, line 28) FAIL: g++.dg/modules/adl-3_c.C -std=c++2a (test for warnings, line 32) FAIL: g++.dg/modules/adl-3_c.C -std=c++2a dg-regexp 31 not found: "\n[^\n]*adl-3_b.C:8:13: error: 'fn' was not declared in this scope$" FAIL: g++.dg/modules/adl-3_c.C -std=c++2a (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/adl-3_c.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/adl-3_c.C -std=c++2b (test for errors, line 28) FAIL: g++.dg/modules/adl-3_c.C -std=c++2b (test for warnings, line 32) FAIL: g++.dg/modules/adl-3_c.C -std=c++2b dg-regexp 31 not found: "\n[^\n]*adl-3_b.C:8:13: error: 'fn' was not declared in this scope$" FAIL: g++.dg/modules/adl-3_c.C -std=c++2b (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/adl-3_c.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/adl-4_b.C -std=c++2a dg-regexp 36 not found: "[^\n]*/adl-4_a.C:14:[0-9]*: error: 'fn' was not declared in this scope\n" FAIL: g++.dg/modules/adl-4_b.C -std=c++2a (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/adl-4_b.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/adl-4_b.C -std=c++2b dg-regexp 36 not found: "[^\n]*/adl-4_a.C:14:[0-9]*: error: 'fn' was not declared in this scope\n" FAIL: g++.dg/modules/adl-4_b.C -std=c++2b (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/adl-4_b.C -std=c++2b (test for excess errors) commit b04208895fed34171eac6bafb60c90048eb1cb0c (HEAD) Author: Jakub Jelinek Date: Tue Sep 27 08:04:06 2022 +0200 c++: Implement P1467R9 - Extended floating-point types and standard names compiler part except for bfloat16 [PR106652] Excess errors: /home/seurer/gcc/git/gcc-regress/gcc/testsuite/g++.dg/modules/adl-3_c.C:6:11: internal compiler error: Segmentation fault 0x10fed563 crash_signal /home/seurer/gcc/git/gcc-regress/gcc/toplev.cc:314 0x104f91dc get_fixed_binding_slot /home/seurer/gcc/git/gcc-regress/gcc/cp/name-lookup.cc:242 0x10508ca7 make_namespace_finish /home/seurer/gcc/git/gcc-regress/gcc/cp/name-lookup.cc:8454 0x1051ae53 push_namespace(tree_node*, bool) /home/seurer/gcc/git/gcc-regress/gcc/cp/name-lookup.cc:8600 0x105ad147 cp_parser_namespace_definition /home/seurer/gcc/git/gcc-regress/gcc/cp/parser.cc:21524 0x105ae0fb cp_parser_declaration /home/seurer/gcc/git/gcc-regress/gcc/cp/parser.cc:15090 0x105aeabb cp_parser_toplevel_declaration /home/seurer/gcc/git/gcc-regress/gcc/cp/parser.cc:15131 0x105aeabb cp_parser_translation_unit /home/seurer/gcc/git/gcc-regress/gcc/cp/parser.cc:5069 0x105aeabb c_parse_file() /home/seurer/gcc/git/gcc-regress/gcc/cp/parser.cc:48615 0x107d6c7f c_common_parse_file() /home/seurer/gcc/git/gcc-regress/gcc/c-family/c-opts.cc:1255
[Bug other/107379] [13 regression] g++.dg/modules/adl-3_c.C and adl-4_b.C break as of r13-2887-gb04208895fed34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107379 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |13.0
[Bug analyzer/107349] [13 Regression] ICE in get_va_copy_arg, at analyzer/varargs.cc:175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107349 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-10-24 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from David Malcolm --- Confirmed; am working on a fix. Sorry for the breakage.
[Bug c++/107378] `get_if` implementation "is not a constant expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107378
--- Comment #2 from Andrew Pinski ---
Reduced testcase without any headers:
```
struct g
{
char a;
};
constexpr bool f(const char *a) { return a != nullptr; }
static_assert([v = g{}] { return f(&v.a); }());
```
This works with clang.
But MSVC rejects it ...
[Bug target/105778] Shift by register --- unnecessary AND instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105778 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0 Severity|normal |enhancement Keywords||missed-optimization
[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 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug fortran/107380] New: ICE in coarray_check, at fortran/check.cc:694
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107380 Bug ID: 107380 Summary: ICE in coarray_check, at fortran/check.cc:694 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : $ cat z1.f90 program p class(*), allocatable :: x codimension :: x[:] allocate (real :: x[*]) print *, image_index(x, [1]) end $ cat z2.f90 program p class(*), allocatable :: x[:] allocate (real :: x[*]) print *, image_index(x, [1]) end $ gfortran-13-20221023 -c z2.f90 -fcoarray=lib $ $ gfortran-13-20221023 -c z1.f90 -fcoarray=lib z1.f90:4:24: 4 |allocate (real :: x[*]) |1 Error: Unexpected coarray designator at (1) f951: internal compiler error: Segmentation fault 0xf43b3f crash_signal ../../gcc/toplev.cc:314 0x7ca22f coarray_check ../../gcc/fortran/check.cc:694 0x7d2482 gfc_check_image_index(gfc_expr*, gfc_expr*) ../../gcc/fortran/check.cc:5943 0x811b09 do_check ../../gcc/fortran/intrinsic.cc:4792 0x811b09 check_specific ../../gcc/fortran/intrinsic.cc:4805 0x819b94 gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.cc:5042 0x870468 resolve_unknown_f ../../gcc/fortran/resolve.cc:2990 0x870468 resolve_function ../../gcc/fortran/resolve.cc:3347 0x870468 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.cc:7194 0x8766cc gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.cc:7161 0x8766cc gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.cc:11980 0x8751ff gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.cc:10978 0x875558 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.cc:11970 0x878307 resolve_codes ../../gcc/fortran/resolve.cc:17624 0x8783ce gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.cc:17659 0x860194 resolve_all_program_units ../../gcc/fortran/parse.cc:6631 0x860194 gfc_parse_file() ../../gcc/fortran/parse.cc:6887 0x8aec0f gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:229
[Bug c/107381] New: ICE in scan_omp_target, at omp-low.cc:3126
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107381
Bug ID: 107381
Summary: ICE in scan_omp_target, at omp-low.cc:3126
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with r10, using file c-c++-common/gomp/target-is-device-ptr-2.c :
$ cat z1.c
void
foo ()
{
int *x, *y;
#pragma omp target data map(x, y) use_device_ptr(x, y)
#pragma omp target is_device_ptr(x, y)
{
*x = 42;
}
}
$ gcc-13-20221023 -c z1.c -m32 -fopenmp -fsanitize=address
during GIMPLE pass: omplower
z1.c: In function 'foo':
z1.c:5:11: internal compiler error: in scan_omp_target, at omp-low.cc:3126
5 | #pragma omp target data map(x, y) use_device_ptr(x, y)
| ^~~
0xd5e749 scan_omp_target
../../gcc/omp-low.cc:3126
0xd5f57a scan_omp_1_stmt
../../gcc/omp-low.cc:4327
0xb80ef6 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.cc:608
0xb81110 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.cc:51
0xb81051 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.cc:671
0xb81110 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.cc:51
0xb80fb1 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.cc:635
0xb81110 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.cc:51
0xd4ab8d scan_omp
../../gcc/omp-low.cc:4377
0xd7055a execute_lower_omp
../../gcc/omp-low.cc:14669
0xd7055a execute
../../gcc/omp-low.cc:14733
[Bug c++/107382] New: [13 Regression] ICE in cp_common_type, at cp/typeck.cc:436
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107382
Bug ID: 107382
Summary: [13 Regression] ICE in cp_common_type, at
cp/typeck.cc:436
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20221009 and 20221016, with -m16 or -m32 :
$ cat z1.cc
void f (float a, int* b) {
a -= b;
}
$ gcc-13-20221023 -c z1.cc -m32 -std=c++11
z1.cc: In function 'void f(float, int*)':
z1.cc:2:8: internal compiler error: in cp_common_type, at cp/typeck.cc:436
2 | a -= b;
|^
0x959f32 cp_common_type
../../gcc/cp/typeck.cc:434
0x96114d cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
../../gcc/cp/typeck.cc:6182
0x96a2cd cp_build_modify_expr(unsigned int, tree_node*, tree_code, tree_node*,
int)
../../gcc/cp/typeck.cc:9539
0x7a88e6 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
../../gcc/cp/call.cc:7054
0x96afa8 build_x_modify_expr(unsigned int, tree_node*, tree_code, tree_node*,
tree_node*, int)
../../gcc/cp/typeck.cc:9746
0x8ac37c cp_parser_assignment_expression
../../gcc/cp/parser.cc:10468
0x8ad862 cp_parser_expression
../../gcc/cp/parser.cc:10597
0x8b0b27 cp_parser_expression_statement
../../gcc/cp/parser.cc:12702
0x8bd6d5 cp_parser_statement
../../gcc/cp/parser.cc:12491
0x8be724 cp_parser_statement_seq_opt
../../gcc/cp/parser.cc:12853
0x8be7df cp_parser_compound_statement
../../gcc/cp/parser.cc:12805
0x8de708 cp_parser_function_body
../../gcc/cp/parser.cc:25179
0x8de708 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.cc:25230
0x8debc6 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.cc:31387
0x8dfd49 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.cc:31304
0x8dfd49 cp_parser_init_declarator
../../gcc/cp/parser.cc:22633
0x8bb8a2 cp_parser_simple_declaration
../../gcc/cp/parser.cc:15284
0x8e5aa8 cp_parser_declaration
../../gcc/cp/parser.cc:14970
0x8e6480 cp_parser_translation_unit
../../gcc/cp/parser.cc:5076
0x8e6480 c_parse_file()
../../gcc/cp/parser.cc:48856
[Bug c++/107383] New: [13 Regression] ICE in cp_build_binary_op, at cp/typeck.cc:6181
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107383
Bug ID: 107383
Summary: [13 Regression] ICE in cp_build_binary_op, at
cp/typeck.cc:6181
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20221009 and 20221016, with file gcc.dg/pr69627.c :
$ cat z1.cc
void
foo ()
{
float t[2] = { 1, 2 };
int const *s = 0;
t[1] / s;
}
void
bar ()
{
float t[2] = { 1, 2 };
int const *s[2] = { 0, 0 };
t[1] / s[0];
}
$ g++-13-20221023 -c z1.cc -m32 -std=c++0x
z1.cc: In function 'void foo()':
z1.cc:6:10: internal compiler error: in cp_build_binary_op, at
cp/typeck.cc:6181
6 | t[1] / s;
| ^
0xb45e49 cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
../../gcc/cp/typeck.cc:6181
0x81f755 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
../../gcc/cp/call.cc:7094
0xb2e48d build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
../../gcc/cp/typeck.cc:4722
0x9ec893 cp_parser_binary_expression
../../gcc/cp/parser.cc:10266
0x9ed404 cp_parser_assignment_expression
../../gcc/cp/parser.cc:10427
0x9efa02 cp_parser_expression
../../gcc/cp/parser.cc:10597
0x9f3b87 cp_parser_expression_statement
../../gcc/cp/parser.cc:12702
0xa03a44 cp_parser_statement
../../gcc/cp/parser.cc:12491
0xa04c34 cp_parser_statement_seq_opt
../../gcc/cp/parser.cc:12853
0xa04d17 cp_parser_compound_statement
../../gcc/cp/parser.cc:12805
0xa2d220 cp_parser_function_body
../../gcc/cp/parser.cc:25179
0xa2d220 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.cc:25230
0xa2d89a cp_parser_function_definition_after_declarator
../../gcc/cp/parser.cc:31387
0xa2eddc cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.cc:31304
0xa2eddc cp_parser_init_declarator
../../gcc/cp/parser.cc:22633
0xa01892 cp_parser_simple_declaration
../../gcc/cp/parser.cc:15284
0xa3679b cp_parser_declaration
../../gcc/cp/parser.cc:14970
0xa372b8 cp_parser_translation_unit
../../gcc/cp/parser.cc:5076
0xa372b8 c_parse_file()
../../gcc/cp/parser.cc:48856
0xbcfb01 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1247
[Bug c++/107384] New: [13 Regression] ICE tree check: expected non_lvalue_expr or static_cast_expr, have error_mark in set_implicit_rvalue_p, at cp/cp-tree.h:8689
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107384
Bug ID: 107384
Summary: [13 Regression] ICE tree check: expected
non_lvalue_expr or static_cast_expr, have error_mark
in set_implicit_rvalue_p, at cp/cp-tree.h:8689
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20220925 and 20221009 :
(gcc configured with --enable-checking=yes)
$ cat z1.cc
auto a = [] { b; return b; };
$ gcc-13-20221023 -c z1.cc -std=c++2b
z1.cc: In lambda function:
z1.cc:1:15: error: 'b' was not declared in this scope
1 | auto a = [] { b; return b; };
| ^
z1.cc:1:25: internal compiler error: tree check: expected non_lvalue_expr or
static_cast_expr, have error_mark in set_implicit_rvalue_p, at
cp/cp-tree.h:8689
1 | auto a = [] { b; return b; };
| ^
0x7016f0 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.cc:8836
0xb31e9a tree_check2(tree_node*, char const*, int, char const*, tree_code,
tree_code)
../../gcc/tree.h:3545
0xb31e9a set_implicit_rvalue_p(tree_node*)
../../gcc/cp/cp-tree.h:8689
0xb31e9a treat_lvalue_as_rvalue_p(tree_node*, bool)
../../gcc/cp/typeck.cc:10729
0xa5fb27 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../gcc/cp/pt.cc:30472
0xb4fdd4 check_return_expr(tree_node*, bool*)
../../gcc/cp/typeck.cc:11002
0xad660e finish_return_stmt(tree_node*)
../../gcc/cp/semantics.cc:1230
0xa0449d cp_parser_jump_statement
../../gcc/cp/parser.cc:14311
0xa0449d cp_parser_statement
../../gcc/cp/parser.cc:12288
0xa04c34 cp_parser_statement_seq_opt
../../gcc/cp/parser.cc:12853
0xa04d17 cp_parser_compound_statement
../../gcc/cp/parser.cc:12805
0xa054da cp_parser_function_body
../../gcc/cp/parser.cc:25179
0xa054da cp_parser_lambda_body
../../gcc/cp/parser.cc:11762
0xa054da cp_parser_lambda_expression
../../gcc/cp/parser.cc:11085
0xa054da cp_parser_primary_expression
../../gcc/cp/parser.cc:5766
0xa08d9e cp_parser_postfix_expression
../../gcc/cp/parser.cc:7717
0xa20fef cp_parser_unary_expression
../../gcc/cp/parser.cc:9081
0x9ebd2f cp_parser_cast_expression
../../gcc/cp/parser.cc:9985
0x9ec65f cp_parser_binary_expression
../../gcc/cp/parser.cc:10087
0x9ed404 cp_parser_assignment_expression
../../gcc/cp/parser.cc:10427
[Bug c++/107383] [13 Regression] ICE in cp_build_binary_op, at cp/typeck.cc:6181
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107383 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-10-24 Target Milestone|--- |13.0 Ever confirmed|0 |1 CC||jakub at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- -m32 -fexcess-precision=standard So most likely caused by r13-3290-g98e341130f8798 . Confirmed.
[Bug c++/107382] [13 Regression] ICE in cp_common_type, at cp/typeck.cc:436
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107382 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=107383 --- Comment #1 from Andrew Pinski --- Most likely very similar to PR 107383 on what introduced the bug and maybe even the fix ...
[Bug c++/107382] [13 Regression] ICE in cp_common_type, at cp/typeck.cc:436
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107382 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug c++/107276] ICE Deducing return type from ill-formed structured binding name since r13-2905-g772d532e0ba1e4b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107276 --- Comment #5 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:f7d8ccfda2d5c90dac97b1a3ede8b10391a3cc40 commit r13-3462-gf7d8ccfda2d5c90dac97b1a3ede8b10391a3cc40 Author: Marek Polacek Date: Thu Oct 20 15:55:28 2022 -0400 c++: ICE with invalid structured bindings [PR107276] This test ICEs in C++23 because we reach the new code in do_auto_deduction: 30468 if (cxx_dialect >= cxx23 30469 && context == adc_return_type 30470 && (!AUTO_IS_DECLTYPE (auto_node) 30471 || !unparenthesized_id_or_class_member_access_p (init)) 30472 && (r = treat_lvalue_as_rvalue_p (maybe_undo_parenthesized_ref (init), 30473 /*return*/true))) where 'init' is "VIEW_CONVERT_EXPR error (y)", and then the move in treat_lvalue_as_rvalue_p returns error_mark_node whereupon set_implicit_rvalue_p crashes. I don't think such V_C_Es are useful so let's not create them. But that won't fix the ICE so I'm checking the return value of move. A structured bindings decl can have an error type, that is set in cp_finish_decomp: 8908 TREE_TYPE (first) = error_mark_node; therefore I think treat_lvalue_as_rvalue_p just needs to cope. PR c++/107276 gcc/cp/ChangeLog: * typeck.cc (treat_lvalue_as_rvalue_p): Check the return value of move. gcc/ChangeLog: * tree.cc (maybe_wrap_with_location): Don't create a location wrapper when the type is erroneous. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/decomp4.C: New test.
[Bug c++/107384] [13 Regression] ICE tree check: expected non_lvalue_expr or static_cast_expr, have error_mark in set_implicit_rvalue_p, at cp/cp-tree.h:8689
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107384 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Marek Polacek --- Just fixed by r13-3462.
[Bug c++/107276] ICE Deducing return type from ill-formed structured binding name since r13-2905-g772d532e0ba1e4b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107276 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Fixed.
[Bug target/107364] [10/11/12/13 Regression] ICE on Via Nehemiah with --march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107364 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:f751bf4c5d1aaa1aacfcbdec62881c5ea1175dfb commit r13-3463-gf751bf4c5d1aaa1aacfcbdec62881c5ea1175dfb Author: Martin Liska Date: Mon Oct 24 15:34:39 2022 +0200 x86: fix VENDOR_MAX enum value PR target/107364 gcc/ChangeLog: * common/config/i386/i386-cpuinfo.h (enum processor_vendor): Reorder enum values as BUILTIN_VENDOR_MAX should not point in the middle of the valid enum values.
[Bug target/107364] [10/11/12 Regression] ICE on Via Nehemiah with --march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107364 Martin Liška changed: What|Removed |Added Summary|[10/11/12/13 Regression]|[10/11/12 Regression] ICE |ICE on Via Nehemiah with|on Via Nehemiah with |--march=native |--march=native --- Comment #6 from Martin Liška --- Fixed on master so far.
[Bug target/107370] long double precision is wrong in ARM 64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107370 --- Comment #3 from jacob navia --- 1 trunk gcc: 2 .LC1: 3.word 325511829 # 0x1366EA95 <<<--- SHOULD BE 325508205 4.word -922176773 # 0xC908B2FB OK 5.word -429395012 # 0xE667F3BC OK 6.word 1073703433 # 0x3FFF6A09 OK This data is wrong, I repeat, the first number (line 3) should be 325508205 or 0x1366DC6D. It CAN'T be a printf issue because when you use my "nsqrt" function IT PRINTS CORRECTLY. THEN printf is able to print correctly when the input is correct. The sqrtl function under ARM 64 bits produces only double precision, instead of quadruple precision. That's all I am saying. And the intention here (from my side) is to help you correct this problem, not to minimize the quality of gcc, a great software! jacob
[Bug c/107381] ICE in scan_omp_target, at omp-low.cc:3126 since r10-2307-g8860d2706d9bd21d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107381 Martin Liška changed: What|Removed |Added Summary|ICE in scan_omp_target, at |ICE in scan_omp_target, at |omp-low.cc:3126 |omp-low.cc:3126 since ||r10-2307-g8860d2706d9bd21d Ever confirmed|0 |1 CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Last reconfirmed||2022-10-24 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Started with r10-2307-g8860d2706d9bd21d.
[Bug c/16186] gcc should have an option to warn about enumerations with duplicate values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16186
--- Comment #3 from Marek Polacek ---
FWIW, Clang implements this warning:
$ xclang++ -c -xc j.c -Wduplicate-enum
j.c:1:33: warning: element 'foo' has been implicitly assigned 0 which another
element has been assigned [-Wduplicate-enum]
enum status { ok = 0, err = -1, foo, bar };
^~~
j.c:1:15: note: element 'ok' also has value 0
enum status { ok = 0, err = -1, foo, bar };
^~
I suppose we could do a binary search when adding a new enumerator in
build_enumerator, see if an enumerator with the same value is already present,
and warn if so.
[Bug c/107385] New: [asm goto] "=r" vs "+r" for outputs along indirect edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107385
Bug ID: 107385
Summary: [asm goto] "=r" vs "+r" for outputs along indirect
edges
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ndesaulniers at google dot com
CC: isanbard at gmail dot com
Target Milestone: ---
I was playing around with adding support for outputs along indirect edges of
asm goto in clang. When I was comparing codegen between various cases, I
noticed a case that looked like a bug to me:
int foo (void) {
int x;
asm goto ("": "=r"(x) ::: bar);
x = 6;
bar:
return x;
}
in gcc 12.2 with `-O2` produces:
foo:
ret
The write to x from the inline asm should be dead along the fallthough or
default path out of the asm goto. We should have one edge that assigns 6 to
the output.
Changing the output constraint modifier from =r to +r seems to produce the
expected code.
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended-Asm mentions
> Be careful when you set output operands inside asm goto only on some possible
> control flow paths. If you don’t set up the output on given path and never
> use it on this path, it is okay. Otherwise, you should use ‘+’ constraint
> modifier meaning that the operand is input and output one. With this modifier
> you will have the correct values on all possible paths from the asm goto.
I'm not sure if that comment is alluding to this behavior, but it might be nice
to not have to pass in any prior value for output only variables?
[Bug c++/107382] [13 Regression] ICE in cp_common_type, at cp/typeck.cc:436
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107382 Martin Liška changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Last reconfirmed||2022-10-24 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Martin Liška --- (In reply to Andrew Pinski from comment #1) > Most likely very similar to PR 107383 on what introduced the bug and maybe > even the fix ... Yes, started with very same revision r13-3290-g98e341130f87984a.
[Bug middle-end/107370] long double sqrtl constant folding is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107370
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords||wrong-code
Ever confirmed|0 |1
Component|target |middle-end
Summary|long double precision is|long double sqrtl constant
|wrong in ARM 64 |folding is wrong
Last reconfirmed||2022-10-24
--- Comment #4 from Andrew Pinski ---
Hmm, this might be a bug in mpfr though. GCC uses MPFR to do constant folding.
Without constant folding libm produces:
1.4142135623730950488
That is:
```
#include
#include
int main(void) { volatile long double a = 2.0L; printf("%.20Lg \n",sqrtl(a)); }
```
[Bug c/16186] gcc should have an option to warn about enumerations with duplicate values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16186 --- Comment #4 from Martin Liška --- (In reply to Marek Polacek from comment #3) > FWIW, Clang implements this warning: Oh, I was unable to find the option (only tried -Werror and -Wextra). @Marek: please add it!
[Bug c/16186] gcc should have an option to warn about enumerations with duplicate values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16186 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #5 from Marek Polacek --- (In reply to Martin Liška from comment #4) > @Marek: please add it! Anything to oblige ye, my fellow.
[Bug target/87832] AMD pipeline models are very costly size-wise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87832 --- Comment #1 from Alexander Monakov --- Suggested partial fix for the integer-pipe side of the blowup: https://inbox.sourceware.org/gcc-patches/4549f27b-238a-7d77-f72b-cc77df8ae...@ispras.ru/
