[Bug libfortran/108056] backward compatibility issue between 11 and 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108056 --- Comment #3 from Gilles Gouaillardet --- For the sake of completeness, debian/ubuntu ships libgfortran.a (read, the static library) from gfortran-11, so I can get this reproducer work if compiling with -static-libgfortran. I also manually rebuilt gfortran-11 on debian (I did my best to reuse debian patches) and it worked. It took me some time to figure out it worked because I then implicitly used libgfortran-11.
[Bug libfortran/108056] backward compatibility issue between 11 and 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108056
--- Comment #2 from Gilles Gouaillardet
---
ubuntu does not ship libgfortran.so from gfortran-11.
I tried on a RedHat box, and the issue only occurs when
- I compile with gfortran-11
- *and* I force libgfortran-12
(so if i use the same gfortran and libgfortran versions, there is no issue).
Here is a stack trace in these conditions:
#0 0x2ba2dd70 in _exit () from /lib64/libc.so.6
#1 0x2b9a1cab in __run_exit_handlers () from /lib64/libc.so.6
#2 0x2b9a1d37 in exit () from /lib64/libc.so.6
#3 0x2acf0976 in _gfortrani_exit_error (status=3) at
../../../../src/gcc-12.1.0/libgfortran/runtime/error.c:218
#4 0x2acf12af in _gfortrani_internal_error (cmp=0x0,
message=0x2afdf2a5 "Invalid type in descriptor") at
../../../../src/gcc-12.1.0/libgfortran/runtime/error.c:534
#5 0x2af787e2 in _gfortran_gfc_desc_to_cfi_desc (d_ptr=0x7fffcfa8,
s=0x7fffcfd0) at
../../../../src/gcc-12.1.0/libgfortran/runtime/ISO_Fortran_binding.c:219
#6 0x00400808 in pub_f08ts (a=,
b=) at /home/usersup/gilles/y.f90:29
#7 0x004007ad in bugsub (a=1, b=-3.67578065e-13) at
/home/usersup/gilles/y.f90:35
#8 0x004008d0 in bug () at /home/usersup/gilles/y.f90:43
#9 0x00400907 in main (argc=1, argv=0x7fffd4cd) at
/home/usersup/gilles/y.f90:44
#10 0x2b98a555 in __libc_start_main () from /lib64/libc.so.6
#11 0x00400699 in _start ()
FWIW, here is the value of s when _gfortran_gfc_desc_to_cfi_desc is invoked
(gdb) p *s
$6 = {base_addr = 0x7fffd04c, offset = 38, dtype = {elem_len = 4, version =
0, rank = 0 '\000', type = 11 '\v', attribute = 2}, span = 4, dim =
0x7fffcff8}
I also noted that if the reproducer is built with gcc-12,
_gfortran_gfc_desc_to_cfi_desc() is not invoked at all.
[Bug libfortran/108056] backward compatibility issue between 11 and 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108056 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- If you compile with gfortran-11 and link with the library that comes with that version of gfortran does it crash? If you compile with gfortran-12 and link with the library that comes with that version of gfortran does it crash? Can you get an actual backtrace?
[Bug libfortran/108056] New: backward compatibility issue between 11 and 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108056 Bug ID: 108056 Summary: backward compatibility issue between 11 and 12 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: gilles.gouaillardet at gmail dot com Target Milestone: --- Created attachment 54062 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54062=edit a simple reproducer The attached program crashes when compiled on ubuntu 22.04 (jammy) based on debian bookworm with gfortran-11: $ gfortran bug.f90 $ ./a.out Internal Error: Invalid type in descriptor Error termination. Backtrace: #0 0x7f04aefe9ad0 in ??? #1 0x7f04aefea649 in ??? #2 0x7f04aefeae38 in ??? #3 0x7f04af22c8a4 in ??? #4 0x56490815c24e in ??? #5 0x56490815c1f3 in ??? #6 0x56490815c316 in ??? #7 0x56490815c352 in ??? #8 0x7f04aedc7d8f in __libc_start_call_main at ../sysdeps/nptl/libc_start_call_main.h:58 #9 0x7f04aedc7e3f in __libc_start_main_impl at ../csu/libc-start.c:392 #10 0x56490815c0c4 in ??? #11 0x in ??? After some investigations, I found gfortran-11 uses libgfortran built for gfortran-12. I guess the fine folks at debian chose to do so since the version library for libgfortran in 5.0.0 (from gfortran-8 up to gfortran-12, I did not test gfortran-13) and they assume or expect ABI and semantic compatibility. The issue can be reproduced by compiling the attached reproducer with gfortran-11, and running it after tweaking LD_LIBRARY_PATH so it uses libgfortran from gfortran-12. I think there are basically two ways to see this issue: - it should work, this is a bug in libfrotran-12 - libgfortran does not ensure such backward compatibility, and because of the semantic change, the library version should be/have been bumped ( e.g. 5.1.0 or 6.0.0) from gfortran-12. Once it is decided on how to move forward, I will be more than happy to report this to the debian folks. For the records, this issue came to my attention at https://stackoverflow.com/questions/74738981/the-use-mpi-f08-statement-causes-fortran-mpi-programs-to-crash-on-ubuntu-22-04/74742760#74742760
[Bug middle-end/104958] missing -Wdangling-pointer leaking local address through struct member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104958
--- Comment #2 from Andrew Pinski ---
A C++ example with lamdbas which shows the same issue here (the IR is basically
the same):
int outer;
auto fn1(int val = 0){
return [&]{
outer = val; // invalid
};
}
[Bug middle-end/104958] missing -Wdangling-pointer leaking local address through struct member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104958 Andrew Pinski changed: What|Removed |Added CC||ozixtheorange at gmail dot com --- Comment #1 from Andrew Pinski --- *** Bug 106508 has been marked as a duplicate of this bug. ***
[Bug middle-end/104077] [meta-bug] bogus/missing -Wdangling-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104077 Bug 104077 depends on bug 106508, which changed state. Bug 106508 Summary: Extra warnings with lambda captures https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106508 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/106508] Extra warnings with lambda captures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106508 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 104958. *** This bug has been marked as a duplicate of bug 104958 ***
[Bug c++/106508] Extra warnings with lambda captures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106508
--- Comment #1 from Andrew Pinski ---
The first case you use default capturing as reference, therefor this will be
captured just fine.
The second case is similar to:
struct f1{int *a;};
struct f1 f(int t)
{
struct f1 t1 = {};
return t1;
}
Which I thought we warned about but it looks like I was wrong.
[Bug fortran/106911] ICE in gfc_convert_mpz_to_signed, at fortran/simplify.cc:193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106911 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |13.0 Resolution|--- |FIXED --- Comment #6 from anlauf at gcc dot gnu.org --- Fixed for gcc-13. Closing. Thanks for the report!
[Bug fortran/106911] ICE in gfc_convert_mpz_to_signed, at fortran/simplify.cc:193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106911 --- Comment #5 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:ae4438537fbc2ed04f3b0fb32d4e02b0ed6977a1 commit r13-4595-gae4438537fbc2ed04f3b0fb32d4e02b0ed6977a1 Author: Harald Anlauf Date: Sat Dec 10 22:05:15 2022 +0100 Fortran: reject bad SIZE argument while simplifying ISHFTC [PR106911] gcc/fortran/ChangeLog: PR fortran/106911 * simplify.cc (gfc_simplify_ishftc): If the SIZE argument is known to be outside the allowed range, terminate simplification. gcc/testsuite/ChangeLog: PR fortran/106911 * gfortran.dg/pr106911.f90: New test.
[Bug fortran/107995] ICE: Segmentation fault, without backtrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107995 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-December/058614.html
[Bug fortran/106911] ICE in gfc_convert_mpz_to_signed, at fortran/simplify.cc:193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106911 --- Comment #4 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-December/058613.html
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #8 from James McKelvey --- Okay I backed out the fix to t-cygwin-w64 and tried to build again with --disable-multilib and stil got the "no dirname" error. So that fix is definitely needed.
[Bug fortran/107995] ICE: Segmentation fault, without backtrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107995 --- Comment #3 from Steve Kargl --- On Sat, Dec 10, 2022 at 07:37:06PM +, anlauf at gcc dot gnu.org wrote: > (In reply to kargl from comment #1) > > This patch prevents the ICE. > > The patch is mostly good, but does not set the errmsg variable, which > leads to garbage in the printed error message. > > We could do the following (haven't found a better one yet): > Don't see the point in complicating the patch as there is at least one earlier error message. But, since I won't be committing a chnage, I certainly won't object to your patch.
[Bug fortran/106911] ICE in gfc_convert_mpz_to_signed, at fortran/simplify.cc:193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106911 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from anlauf at gcc dot gnu.org --- This is better: diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc index aff9a1b8ced..2c75605ca08 100644 --- a/gcc/fortran/simplify.cc +++ b/gcc/fortran/simplify.cc @@ -3955,6 +3955,9 @@ gfc_simplify_ishftc (gfc_expr *e, gfc_expr *s, gfc_expr *sz) return NULL; gfc_extract_int (sz, ); + + if (ssize > isize || ssize <= 0) + return _bad_expr; } else ssize = isize; Regtested OK. Taking.
[Bug c++/108052] forward-declared constexpr variable template unusable in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108052 --- Comment #1 from Andrew Pinski --- Note clang also rejects the double case just as GCC does and accepts the int case too. MSVC accepts both the int and double case.
[Bug d/108055] New: d: Undefined reference to nested lambda in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108055
Bug ID: 108055
Summary: d: Undefined reference to nested lambda in template
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
issue.d:
---
import std.conv;
void main()
{
float* zis ;
static if (is(typeof(to!string(*zis
to!string(*zis);
}
---
std/conv.d:
---
T toStr(T, S)(S src)
{
static if (is(typeof(T.init[0]) E))
{
struct Appender
{
inout(E)[] data;
}
import std.format.spec;
import std.format.write;
auto w = Appender();
FormatSpec!E f;
formatValue(w, src, f);
return w.data;
}
}
T to(T, A)(A args)
{
return toStr!T(args);
}
---
std/format/spec.d:
---
module std.format.spec;
template Unqual(T : const U, U)
{
alias Unqual = U;
}
template FormatSpec(Char)
if (!is(Unqual!Char == Char))
{
alias FormatSpec = FormatSpec!(Unqual!Char);
}
struct FormatSpec(Char)
if (is(Unqual!Char == Char))
{
const(Char)[] nested;
}
---
std/format/write.d:
---
module std.format.write;
import std.format.spec;
void formatValueImpl(Writer, T, Char)(ref Writer , const(T) ,
scope const ref FormatSpec!Char )
{
T val;
char spec;
(ref val) @trusted {
return (cast(const char*) )[0 .. val.sizeof];
}(val);
}
void formatValue(Writer, T, Char)(Writer w, T val, Char f)
{
formatValueImpl(w, val, f);
}
---
[Bug c/108054] C2X auto with struct defined in statement expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108054 --- Comment #1 from Andrew Pinski --- Statement expressions are an extension after all. Gcc could define it any way it wants.
[Bug c/108054] New: C2X auto with structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108054
Bug ID: 108054
Summary: C2X auto with structs
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
GCC rejects the following code. The C2X spec does not allow declarations in the
assignment expression for auto. But this breaks macros that define structs
inside ({ }), so this does not seem desirable in combination with ({ }). It
this is intentional, is also not clear why other non-ordinary identifiers are
still allowed.
void foo(void)
{
auto b = ({ struct foo { int x; } a = { }; a; });
auto c = ({ out: 0 });
}
:5:22: error: 'struct foo' defined in underspecified object initializer
I would argue that we should also extend the language and allow
void foo(void)
{
auto a = (struct foo { int x; }){ 0 };
typeof(a) b = a;
}
as there is not clear reason I could see to forbid this and the limitation is
surprising. (and with the new tag compatibility rules such code wiould also
become very useful);
[Bug fortran/107995] ICE: Segmentation fault, without backtrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107995
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> This patch prevents the ICE.
The patch is mostly good, but does not set the errmsg variable, which
leads to garbage in the printed error message.
We could do the following (haven't found a better one yet):
diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index 73799c175b7..ad4182a01ae 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -1334,6 +1334,12 @@ gfc_check_dummy_characteristics (gfc_symbol *s1,
gfc_symbol *s2,
if (s1 == NULL || s2 == NULL)
return s1 == s2 ? true : false;
+ if (s1->attr.proc == PROC_ST_FUNCTION || s2->attr.proc == PROC_ST_FUNCTION)
+{
+ strncpy (errmsg, "Statement function", err_len);
+ return false;
+}
+
/* Check type and rank. */
if (type_must_agree)
{
This prints:
pr107995-z1.f90:4:3:
4 | n(n) = 1
| 1
Error: Self-referential argument 'n' at (1) is not allowed
pr107995-z1.f90:5:13:
5 | print *, n(n)
| 1
Error: Statement function 'n' at (1) is not allowed as an actual argument
pr107995-z1.f90:5:13:
5 | print *, n(n)
| 1
Error: Interface mismatch in dummy procedure 'n' at (1): Statement function
[Bug libstdc++/108053] New: std::visit_format_arg should hide __int128 and other extensions behind a handle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108053 Bug ID: 108053 Summary: std::visit_format_arg should hide __int128 and other extensions behind a handle Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- As an extension we store some additional types directly in the basic_format_arg type, rather than indirection through a handle type. But this is observable to users because std::visit_format_arg is called with the stored type. We should have an internal __visit_format_arg which visits the real stored type, and then a user-facing std::visit_format_arg which only visits the types that the standard says should be there. The other types should be wrapped in a temporary handle when passed to the visitor.
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #7 from James McKelvey --- That fix let the build proceed until it hit a #error much later. See 108011. Cygwin seems to be removing support for 32-bit, so although multilib has built for years, it won't anymore. That's my take. I'm not an expert on Cygwin or g++, I just build gcc-13 every snapshot and report bugs.
[Bug c++/108052] New: forward-declared constexpr variable template unusable in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108052 Bug ID: 108052 Summary: forward-declared constexpr variable template unusable in constexpr context Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: webrown.cpp at gmail dot com Target Milestone: --- Similar to bug 59123, the following code compiles with no complaint: extern const double e; // a fwd-declaration constexpr double e = 2.71; // its corresponding def'n static_assert( e == 2.71 ); // verification But the following analogous, templatized, code...: template< class T > extern const T pi; // a fwd-declaration template< class T > constexpr T pi = 3.14; // its corresponding def'n static_assert( pi == 3.14 ); // verification ... produces the following unexpected diagnostics: error: non-constant condition for static assertion error: the value of 'pi' is not usable in a constant expression note: 'pi' was not declared 'constexpr' ...when compiling with gcc version 13.0.0 20221122 and any of: -std=c++17, -std=c++20, or -std=c++23. However, further experimentation reveals that the following int variation of the above static_assert does compile (although an expected float-conversion warning is produced if enabled): template< class T > extern const T pi; // a fwd-declaration Finally, bug 92576 and bug 68012 seem tangentially related. template< class T > constexpr T pi = 3.14; // its corresponding def'n static_assert( pi == 3 ); // verification A knowledgeable CWG colleague conjectures that the double-vs-int difference may be "somehow related to the special rule for 'const integral types' vs. 'constexpr any type'." Finally, bug 68012, bug 84255, and bug 92576 seem tangentially related, although these do not involve any extern declaration.
[Bug c/108051] New: Missing array-bounds warning when not using -ftracer flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108051 Bug ID: 108051 Summary: Missing array-bounds warning when not using -ftracer flag Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: drfiemost at email dot it Target Milestone: --- Created attachment 54061 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54061=edit test program Compiling the attached program, where the key pointer might be unreferenced when NULL, the warning only shows when using the -ftracer flag. Tested with gcc version 12.2.0 and 11.3.0. $ gcc -O2 -Wall -Werror geometry.i In function ‘HandleOverlayDef’, inlined from ‘HandleSectionBody’ at geometry.c:2789:18, inlined from ‘HandleSectionDef’ at geometry.c:2829:10, inlined from ‘HandleGeometryFile’ at geometry.c:2875:18: geometry.c:2580:9: error: ‘strncpy’ output may be truncated copying 4 bytes from a string of length 4 [-Werror=stringop-truncation] 2580 | } geometry.c:2581:9: error: ‘strncpy’ output may be truncated copying 4 bytes from a string of length 4 [-Werror=stringop-truncation] 2581 | return False; cc1: all warnings being treated as errors $ gcc -O2 -ftracer -Wall -Werror geometry.i In function ‘HandleOverlayDef’, inlined from ‘HandleSectionBody’ at geometry.c:2789:18, inlined from ‘HandleSectionDef’ at geometry.c:2829:10, inlined from ‘HandleGeometryFile’ at geometry.c:2875:18: geometry.c:2580:9: error: ‘strncpy’ output may be truncated copying 4 bytes from a string of length 4 [-Werror=stringop-truncation] 2580 | } geometry.c:2581:9: error: ‘strncpy’ output may be truncated copying 4 bytes from a string of length 4 [-Werror=stringop-truncation] 2581 | return False; geometry.c:2580:9: error: ‘strncpy’ offset [0, 3] is out of the bounds [0, 0] [-Werror=array-bounds] 2580 | } geometry.c:2581:9: error: ‘strncpy’ offset [0, 3] is out of the bounds [0, 0] [-Werror=array-bounds] 2581 | return False; cc1: all warnings being treated as errors As a side note the warning message is also a bit cryptic, as the out of bound would happen only in case the pointer is NULL and not in normal conditions, but sure is better than no message at all. See https://gitlab.freedesktop.org/xorg/app/xkbcomp/-/issues/21 for reference.
[Bug d/108050] d: internal compiler error: in visit, at d/imports.cc:72
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108050 --- Comment #1 from Iain Buclaw --- Doesn't even need to be a template that's imported. Two or more overloadable functions will trigger the ICE as well.
[Bug d/108050] New: d: internal compiler error: in visit, at d/imports.cc:72
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108050
Bug ID: 108050
Summary: d: internal compiler error: in visit, at
d/imports.cc:72
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
ice.d:
---
import std : split;
---
std/package.d
---
module std;
public import std.array;
public import std.regex;
---
std/array.d
---
module std.array;
S[] split()() { }
---
std/regex.d
---
module std.regex;
S[] split()() { }
---
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #6 from Christophe Lyon --- (In reply to James McKelvey from comment #5) > This works: > > $ diff gcc/config/i386/t-cygwin-w64~ gcc/config/i386/t-cygwin-w64 > 2c2 > < MULTILIB_DIRNAMES = 64 > --- > > MULTILIB_DIRNAMES = 64 32 I guess this has an impact on the multilib layout (dirnames changes), is that OK? Did you understand how the build succeeded previously? Is there a risk to break other packages depending on this one?
[Bug c++/107768] Bogus -Wzero-as-null-pointer-constant in coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107768 --- Comment #8 from Iain Sandoe --- posted: https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608262.html
[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997 --- Comment #11 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7676235f690e624b7ed41a22b22ce8ccfac1492f commit r13-4594-g7676235f690e624b7ed41a22b22ce8ccfac1492f Author: Jakub Jelinek Date: Sat Dec 10 16:50:39 2022 +0100 ivopts: Fix IP_END handling for asm goto [PR107997] The following testcase ICEs, because the latch bb ends with asm goto which has both fallthrough to the header and one or more labels in the header too. In that case there is just a single edge out of the latch block, but still the asm goto is stmt_ends_bb_p statement, yet ivopts decides to emit an IV bump at the IP_END position and inserts it into the same bb as the asm goto after it, which then fails verification (control flow in the middle of bb). The following patch fixes it by splitting the latch -> header edge in that case and inserting into the newly created bb, where split_edge -> redirect_edge_and_branch is able to deal with this case correctly. 2022-12-10 Jakub Jelinek PR tree-optimization/107997 * tree-ssa-loop-ivopts.cc: Include cfganal.h. (create_new_iv) : If ip_end_pos bb is non-empty and ends with a stmt which ends bb, instead of adding iv update after it split the latch edge and insert iterator into the new latch bb. * gcc.c-torture/compile/pr107997.c: New test.
[Bug c++/107768] Bogus -Wzero-as-null-pointer-constant in coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107768 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #7 from Iain Sandoe --- (In reply to Andrew Pinski from comment #6) > This should fix the issue (just like what was done in PR 51045): yes, as far as my testing goes it does, without regressing our testsuite, cppcoro or folly. however, I cannot approve - so it will have to be posted.
[Bug target/108049] s390: Compiler adds extra zero extend after xoring 2 zero extended values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108049 --- Comment #1 from Jens Seifert --- Sample above got compiled with -march=z196
[Bug target/108049] New: s390: Compiler adds extra zero extend after xoring 2 zero extended values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108049
Bug ID: 108049
Summary: s390: Compiler adds extra zero extend after xoring 2
zero extended values
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
Same issue for PPC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107949
extern unsigned char magic1[256];
unsigned int hash(const unsigned char inp[4])
{
const unsigned long long INIT = 0x1ULL;
unsigned long long h1 = INIT;
h1 = magic1[((unsigned long long)inp[0]) ^ h1];
h1 = magic1[((unsigned long long)inp[1]) ^ h1];
h1 = magic1[((unsigned long long)inp[2]) ^ h1];
h1 = magic1[((unsigned long long)inp[3]) ^ h1];
return h1;
}
hash(unsigned char const*):
llgc%r4,1(%r2) <= zero extends to 64-bit
lgrl%r1,.LC0
llgc%r3,0(%r2) <= zero extends to 64-bit
xilf%r3,1
llgc%r3,0(%r3,%r1)
xr %r3,%r4 <= should be 64-bit xor
llgc%r4,2(%r2) <= zero extends to 64-bit
llgcr %r3,%r3 <= unnecessary
llgc%r2,3(%r2)
llgc%r3,0(%r3,%r1)
xr %r3,%r4 <= should be 64-bit xor
llgcr %r3,%r3 <= unnecessary
llgc%r3,0(%r3,%r1) <= zero extends to 64-bit
xrk %r2,%r3,%r2 <= should be 64-bit xor
llgcr %r2,%r2 <= unnecessary
llgc%r2,0(%r2,%r1)
br %r14
Smaller sample:
unsigned long long tiny2(const unsigned char *inp)
{
unsigned long long a = inp[0];
unsigned long long b = inp[1];
return a ^ b;
}
tiny2(unsigned char const*):
llgc%r1,0(%r2)
llgc%r2,1(%r2)
xrk %r2,%r1,%r2
llgcr %r2,%r2
br %r14
[Bug libstdc++/108046] The dot in the floating-point alternative form has wrong position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108046 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |13.0 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-12-10
[Bug rtl-optimization/107949] PPC: Unnecessary rlwinm after lbzx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107949 --- Comment #3 from Jens Seifert --- *** Bug 108048 has been marked as a duplicate of this bug. ***
[Bug target/108048] PPCLE: gcc does not recognize that lbzx does zero extend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108048 Jens Seifert changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jens Seifert --- duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107949 *** This bug has been marked as a duplicate of bug 107949 ***
[Bug target/108048] New: PPCLE: gcc does not recognize that lbzx does zero extend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108048
Bug ID: 108048
Summary: PPCLE: gcc does not recognize that lbzx does zero
extend
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
extern unsigned char magic1[256];
unsigned int hash(const unsigned char inp[4])
{
const unsigned long long INIT = 0x1ULL;
unsigned long long h1 = INIT;
h1 = magic1[((unsigned long long)inp[0]) ^ h1];
h1 = magic1[((unsigned long long)inp[1]) ^ h1];
h1 = magic1[((unsigned long long)inp[2]) ^ h1];
h1 = magic1[((unsigned long long)inp[3]) ^ h1];
return h1;
}
Generates:
hash(unsigned char const*):
.LCF0:
addi 2,2,.TOC.-.LCF0@l
lbz 9,0(3)
addis 10,2,.LC0@toc@ha
ld 10,.LC0@toc@l(10)
lbz 6,1(3)
lbz 7,2(3)
lbz 8,3(3)
xori 9,9,0x1
lbzx 9,10,9
xor 9,9,6
rlwinm 9,9,0,0xff <= unnecessary
lbzx 9,10,9
xor 9,9,7
rlwinm 9,9,0,0xff <= unnecessary
lbzx 9,10,9
xor 9,9,8
rlwinm 9,9,0,0xff <= unnecessary
lbzx 3,10,9
blr
All XOR operations are done in unsigned long long (64-bit). gcc adds
unnecessary rlwinm. lbz and lbzx does zero extension (no cleanup of upper bits
required).
[Bug c++/105373] miscompile involving lambda coroutines and an object bitwise copied instead of via the copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373 --- Comment #19 from Iain Sandoe --- (In reply to Avi Kivity from comment #17) > Please consider backporting > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576, this is a subtle code > generation bug. Noted, that a back-port is needed, unfortunately the one-line fix for master is not applicable to the branches (they do not have the code that marks TARGET_EXPRESSIONS that will be elided). We will have to figure out how to make a stand-alone implementation of that for GCC-12, 11 etc.
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 105373, which changed state. Bug 105373 Summary: miscompile involving lambda coroutines and an object bitwise copied instead of via the copy constructor https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/105373] miscompile involving lambda coroutines and an object bitwise copied instead of via the copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Iain Sandoe --- reported fixed by r13-4479-g58a7b1e354530d.
[Bug c++/108047] New: ice: unexpected expression of kind implicit_conv_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108047
Bug ID: 108047
Summary: ice: unexpected expression of kind implicit_conv_expr
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C++ source code:
namespace std {
template class initializer_list;
struct Trans_NS___cxx11_basic_string;
struct vector {
vector(initializer_list);
};
struct Trans_NS___cxx11_basic_string {
Trans_NS___cxx11_basic_string(const char *);
};
} // namespace std
constexpr auto kBufVecX = "";
template struct TestXswap {
std::vector BuffersIn() { return {kBufVecX}; }
};
does this
$ ~/gcc/results.20221208.asan.ubsan/bin/g++ -c -w bug866.cc
bug866.cc: In member function ‘std::vector TestXswap<
>::BuffersIn()’:
bug866.cc:13:45: internal compiler error: unexpected expression
‘(std::Trans_NS___cxx11_basic_string)kBufVecX’ of kind implicit_conv_expr
13 | std::vector BuffersIn() { return {kBufVecX}; }
| ^
0x7386ae cxx_eval_constant_expression(constexpr_ctx const*, tree_node*,
value_cat, bool*, bool*, tree_node**)
../../trunk.d1/gcc/cp/constexpr.cc:8013
It was ok the day before:
$ ~/gcc/results.20221207.asan.ubsan/bin/g++ -c -w bug866.cc
$
The git hashes are 3ad0f470c16d5528 and 7410032a772a9e77, a range
of 24 commits.
[Bug libstdc++/108046] New: The dot in the floating-point alternative form has wrong position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108046
Bug ID: 108046
Summary: The dot in the floating-point alternative form has
wrong position
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
#include
#include
int main() {
std::cout << std::format("{:#.0}\n", 10.);
std::cout << std::format("{:#.1}\n", 10.);
std::cout << std::format("{:#.0g}\n", 10.);
}
libstdc++ gives:
1e+01.
1e+01.
1e+01
But they should all be "1.e+01"
https://godbolt.org/z/Y41ve6E7W
[Bug target/108044] [13 Regression] ICE: in extract_constrain_insn, at recog.cc:2692 (insn does not satisfy its constraints) at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108044 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |13.0 Ever confirmed|0 |1 Last reconfirmed||2022-12-10 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Priority|P3 |P1
[Bug c++/85952] Bogus -Wunused-but-set-variable warning with array structured binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85952 Andrew Pinski changed: What|Removed |Added Known to fail||7.3.0, 8.1.0 Target Milestone|--- |7.4 Known to work||7.4.0, 8.2.0, 9.0
