[Bug target/118184] [15 regression] glibc regression on aarch64 due to early_ra deleting movti instruction since r15-5422-g279475fd7236a9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118184 Sam James changed: What|Removed |Added Summary|[15 regression] glibc |[15 regression] glibc |regression on aarch64 due |regression on aarch64 due |to early_ra deleting movti |to early_ra deleting movti |instruction |instruction since ||r15-5422-g279475fd7236a9 --- Comment #8 from Sam James --- (In reply to Andrew Pinski from comment #7) > Created attachment 59959 [details] > Reduced/runtime testcase r15-5422-g279475fd7236a9
[Bug libstdc++/118022] : _Copy_awaiter should explicitly construct _Yielded_decvref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118022 Arsen Arsenović changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-12-24 --- Comment #1 from Arsen Arsenović --- confirmed. thanks for the report.
[Bug rtl-optimization/117951] FAIL: 20_util/variant/run.cc -std=gnu++17 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117951 --- Comment #4 from John David Anglin --- run.cc compiles okay if I add -fno-gcse to compile command. dave@mx3210:~/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/testsuite$ cat xxx.sh /home/dave/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc -B/home/dave/gnu/gcc/objdir/./gcc -nostdinc++ -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.libs -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/dave/opt/gnu/gcc/gcc-15/hppa-linux-gnu/bin/ -B/home/dave/opt/gnu/gcc/gcc-15/hppa-linux-gnu/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-15/hppa-linux-gnu/include -isystem /home/dave/opt/gnu/gcc/gcc-15/hppa-linux-gnu/sys-include -fchecking=1 -B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/20_util/variant/run.cc -std=gnu++17 -include bits/stdc++.h -fdiagnostics-plain-output ./libtestc++.a -Wl,--gc-sections -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/filesystem/.libs -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/experimental/.libs -lm -o ./run.exe -fno-gcse -mlra
[Bug target/118174] [15 Regression] AArch64: Miscompilation at -O3 since r15-5943-gdc0dea98c96e02
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118174 Sam James changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Summary|[15 Regression] AArch64:|[15 Regression] AArch64: |Miscompilation at -O3 |Miscompilation at -O3 since ||r15-5943-gdc0dea98c96e02 Keywords|needs-bisection | --- Comment #3 from Sam James --- r15-5943-gdc0dea98c96e02
[Bug c/118191] New: missing option to read __float128 from command line argument or string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118191 Bug ID: 118191 Summary: missing option to read __float128 from command line argument or string Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: newbie-02 at gmx dot de Target Milestone: --- hello @ all, hope me wrong, but all search failed ... How to write code that reads a __float128 value from command line argument or string? In 'vanilla-c, not cpp, c++ or the like. Tried different strtoxx and sscanxx, best strtold, but that castrates to ~20 digit precision. Anybody an idea? P.S. don't need that for 'real work', but want to compare performance of all available datatypes, and for that need an option to set different values.
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 118059, which changed state. Bug 118059 Summary: [15 Regression] ubsan instrumented gcc: valid value for type 'expr_t' in gcc/fortran/trans-expr.cc https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118059 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/118186] [15 regression] FAIL: gcc.dg/field-merge-16.c scan-tree-dump-times ifcombine "optimizing" 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118186 Sam James changed: What|Removed |Added Summary|FAIL: |[15 regression] FAIL: |gcc.dg/field-merge-16.c |gcc.dg/field-merge-16.c |scan-tree-dump-times|scan-tree-dump-times |ifcombine "optimizing" 6|ifcombine "optimizing" 6 Target Milestone|--- |15.0
[Bug fortran/118059] [15 Regression] ubsan instrumented gcc: valid value for type 'expr_t' in gcc/fortran/trans-expr.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118059 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Paul Thomas --- Fixed - thanks for the report. Paul
[Bug fortran/116254] new test case gfortran.dg/class_transformational_2.f90 from r15-2739-g4cb07a38233aad fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116254 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Paul Thomas --- I believe that this is now fixed. Please reopen if this is not the case. Thanks for the report. Seasons greetings to you all! Paul
[Bug c/118191] missing option to read __float128 from command line argument or string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118191 Andreas Schwab changed: What|Removed |Added Resolution|WORKSFORME |INVALID
[Bug c++/118192] New: ICE: in build_data_member_initialization, at cp/constexpr.cc:453
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118192
Bug ID: 118192
Summary: ICE: in build_data_member_initialization, at
cp/constexpr.cc:453
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wangbopku15 at gmail dot com
Target Milestone: ---
The following invalid code triggers an ICE on x86-64 gcc trunk:
template
struct base
{
int y;
base() = delete;
constexpr base(int a) : base{}
{ y = a; }
};
struct foo : base<1>
{
constexpr foo(int a) : base<1>{a}
{
}
};
int main()
{
constexpr foo bar1{1};
}
It's invalid because the ` constexpr base(int a) : base{}` tries to call the
deleted default ctor of `base`. Please note that the crash will not appear if
the ctor does nothing in its function body like:
template
struct base
{
base() = delete;
constexpr base(int a) : base{}{}
};
Please check https://godbolt.org/z/8Pj76MdoT for more information.
$ g++ -freport-bug of3468.cpp
: In instantiation of 'constexpr base< >::base(int) [with
int = 1]':
:12:35: required from here
12 | constexpr foo(int a) : base<1>{a}
| ^
:19:23: in 'constexpr' expansion of '((foo*)(& bar1))->foo::foo(1)'
:6:32: error: use of deleted function 'base< >::base() [with
int = 1]'
6 | constexpr base(int a) : base{}
|^
:5:3: note: declared here
5 | base() = delete;
| ^~~~
:6:32: note: use '-fdiagnostics-all-candidates' to display considered
candidates
6 | constexpr base(int a) : base{}
|^
: In function 'int main()':
:19:23: in 'constexpr' expansion of '((foo*)(& bar1))->foo::foo(1)'
:12:35: error: 'constexpr base< >::base(int) [with int
= 1]' called in a constant expression
12 | constexpr foo(int a) : base<1>{a}
| ^
:6:13: note: 'constexpr base< >::base(int) [with int
= 1]' is not usable as a 'constexpr' function because:
6 | constexpr base(int a) : base{}
| ^~~~
:6:13: internal compiler error: in build_data_member_initialization, at
cp/constexpr.cc:453
0x2931885 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2948656 internal_error(char const*, ...)
???:0
0xac9dee fancy_abort(char const*, int, char const*)
???:0
0xb42a60 explain_invalid_constexpr_fn(tree_node*)
???:0
0xdc5bde store_init_value(tree_node*, tree_node*, vec**, int)
???:0
0xbbeb4e cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int,
cp_decomp*)
???:0
0xce1f2a c_parse_file()
???:0
0xe41159 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See
[Bug c++/118193] New: ICE: in verify_ctor_sanity, at cp/constexpr.cc:5362
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118193
Bug ID: 118193
Summary: ICE: in verify_ctor_sanity, at cp/constexpr.cc:5362
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wangbopku15 at gmail dot com
Target Milestone: ---
The following code triggers an ICE on gcc since version 12.2.0:
struct empty{
};
struct NoMut1 : empty{ int a, b; };
struct NoMut3 : NoMut1 {
constexpr NoMut3(int a, int b){}
};
void mutable_subobjects() {
constexpr NoMut3 nm3 = {1, 2};
struct A{
void f() {
static_assert(nm3.a == 1, "");
}
};
}
Please see Compiler Explorer: https://godbolt.org/z/rbhrPhvor.
It's also worth noting that the empty base class here is necessary to trigger
the bug.
Compiler Output:
: In member function 'void mutable_subobjects()::A::f()':
:12:25: internal compiler error: in verify_ctor_sanity, at
cp/constexpr.cc:5362
12 | static_assert(nm3.a == 1, "");
| ^
0x2938075 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x294ee76 internal_error(char const*, ...)
???:0
0xacaf50 fancy_abort(char const*, int, char const*)
???:0
0xb444f2 maybe_constant_value(tree_node*, tree_node*, mce_value)
???:0
0xdb2c47 cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
???:0
0xb03c74 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
???:0
0xda41e2 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
???:0
0xce5603 c_parse_file()
???:0
0xe450d9 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c/118194] New: spurious warning with -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118194
Bug ID: 118194
Summary: spurious warning with -Wmaybe-uninitialized
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sshannin at gmail dot com
Target Milestone: ---
There are a number of other open bug reports about this warning, but none of
them seemed quite the same. This is different in that:
- doesn't rely on C++ constructs such as lambdas
- occurs at all optimization levels -O0 through -O3
- very simple path with no control flow
#include
#include
void *foo(int sz) {
void *p = malloc(sz);
mlock(p, sz);
return p;
}
The above minimal example triggers a maybe-uninitialized warning:
: In function 'foo':
:6:5: warning: 'p' may be used uninitialized [-Wmaybe-uninitialized]
6 | mlock(p, sz);
| ^~~~
In file included from :2:
/usr/include/x86_64-linux-gnu/sys/mman.h:103:12: note: by argument 1 of type
'const void *' to 'mlock' declared here
103 | extern int mlock (const void *__addr, size_t __len) __THROW;
|^
It looks like this was introduced starting in 11.1 and is present up through
trunk.
[Bug c/118191] missing option to read __float128 from command line argument or string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118191 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- This is a question about how to use GCC, not a bug report. Please use the gcc-help mailing list for such questions. But this isn't a GCC problem anyway, since the function you're looking for would be part of the C library, and GCC is just a compiler and doesn't include a C library. Glibc has strtof128 for this purpose.
[Bug tree-optimization/118032] [15 regression] Bootstrap slowdown for risc-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032 --- Comment #30 from Filip Kastl --- (In reply to Mark Wielaard from comment #28) > I haven't tried yet, but do you mean something like the following? > - /* Note: l + 1 is the number of cases of the switch. */ > - if (l + 1 > (unsigned) param_switch_lower_slow_alg_max_cases) > -return clusters.copy (); Yes. Exactly that. (In reply to ak from comment #29) > We could also implement greedy switch clustering for jump tables I think. > Right now it's only for the switch bitmap clustering. Yes, that would be nice to have. Though maybe that can wait for Stage 1.
[Bug libstdc++/118022] : _Copy_awaiter should explicitly construct _Yielded_decvref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118022 Arsen Arsenović changed: What|Removed |Added Target Milestone|--- |15.0 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |arsen at gcc dot gnu.org --- Comment #2 from Arsen Arsenović --- testing a patch
[Bug c/118191] missing option to read __float128 from command line argument or string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118191 newbie-02 changed: What|Removed |Added Resolution|INVALID |WORKSFORME --- Comment #2 from newbie-02 --- (In reply to Jonathan Wakely from comment #1) hello and thanks to @Jonathan Wakely, > Glibc has strtof128 for this purpose. sorry for my shortcoming in knowledge about the workbench structure, it works, I see a shortcoming that it's not 'findable' in actual search engines, and ... for whatever reason the function is named: >>> strto**d**128 <<< on my system, would have been unusual if something in IT would be constructed without unusual idiosyncrasies ... again, many many thanks as well for fast! as for qualified! answer, thumbs up, merry X-mas, b.s.
[Bug c++/118195] New: accepted template member definition with a different template-head
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118195
Bug ID: 118195
Summary: accepted template member definition with a different
template-head
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ing.russomauro at gmail dot com
Target Milestone: ---
With this example:
https://godbolt.org/z/YMxbrY5rP
I had previously posted what I supposed to be a bug for clang (and MVSC) ->
https://github.com/llvm/llvm-project/issues/119745 (don't care the MVSC link)
but clang team notified that the code rejection matches the standard
requirements.
In the linked example, there is a template class A2,
for which a function member A2::f is declared:
template
class A2{
template Tnest>
void f();
};
which is lated defined outside the class
template
template
requires C2>
void A2::f(){};
in a way such that the same concept C2 is applied to the type-parameter Tnest,
but in a different position.
gcc accepts it (please, note it happens also after having added the suggested
flags "-Wall -Wextra -fno-strict-aliasing -fwrapv"),
but clang team notified that the template-head should be the same between
declaration and definition, isn't it ?
[Bug fortran/117643] F_C_STRING from F23 is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #14 from kargls at comcast dot net ---
(In reply to Jerry DeLisle from comment #12)
> The following additional patch from Harald posted on the gfortran list:
>
> https://gcc.gnu.org/pipermail/fortran/2024-December/061452.html
>
> diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc
> index 2370b6dad55..886f999f206 100644
> --- a/gcc/fortran/trans-intrinsic.cc
> +++ b/gcc/fortran/trans-intrinsic.cc
> @@ -10220,6 +10220,16 @@ conv_isocbinding_function (gfc_se *se, gfc_expr
> *expr)
>
> gfc_init_se (&asis_se, se);
> gfc_conv_expr (&asis_se, asis);
> + if (asis->expr_type == EXPR_VARIABLE
> + && asis->symtree->n.sym->attr.dummy
> + && asis->symtree->n.sym->attr.optional)
> + {
> + tree present = gfc_conv_expr_present (asis->symtree->n.sym);
> + asis_se.expr = build3_loc (input_location, COND_EXPR,
> +logical_type_node, present,
> +asis_se.expr,
> +build_int_cst
> (logical_type_node, 0));
> + }
> gfc_add_block_to_block (&se->pre, &asis_se.pre);
> tmp = fold_build3_loc (input_location, COND_EXPR,
> void_type_node,
> asis_se.expr, then_branch, else_branch);
>
> I will put this altogether in one patch.
>
> Steve, any further comments?
No comments from me. I'm still trying to determine how gfc_conv_expr_present()
works, and what 'gfc_conv_expr (&asis_se, asis)' gives when the optional
argument
is not present.
If Harald signs off on the patch, the ChangeLog should likely note the group
effort that went into the patch as Mikael, FX, and Harald deserve some
recognition (or blame!).
[Bug fortran/117643] F_C_STRING from F23 is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #16 from Jerry DeLisle ---
Needed a minor tweak:
+ if (string->ts.type != BT_CHARACTER
+ || (string->ts.type == BT_CHARACTER
// && on the inner paren instead of ||
+ && (string->ts.kind != 1 && string->ts.is_c_interop != 1))) //
+{
+ gfc_error ("%qs argument of %qs intrinsic at %L shall have "
+"a type of CHARACTER(KIND=C_CHAR)",
+gfc_current_intrinsic_arg[0]->name, gfc_current_intrinsic,
+&string->where);
+ return false;
+}
[Bug target/70557] uint64_t zeroing on 32-bit hardware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557
Siarhei Volkau changed:
What|Removed |Added
CC||lis8215 at gmail dot com
--- Comment #9 from Siarhei Volkau ---
Created attachment 59964
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59964&action=edit
RV patch
Observing same issue in GCC 14.2 but for RV32.
for example:
void clear64(uint64_t *ull)
{
*ull = 0;
}
RV32 emits:
li a5,0
li a6,0
sw a5,0(a0)
sw a6,4(a0)
ret
Hopefully, the fix is trivial (one symbol).
[Bug target/70557] uint64_t zeroing on 32-bit hardware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557 --- Comment #10 from Siarhei Volkau --- Created attachment 59965 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59965&action=edit MIPS patch Ditto for 32-bit MIPS. MIPS emits: move$3,$0 move$2,$0 sw $3,4($4) jr $31 sw $2,0($4)
[Bug libstdc++/118196] The assignment operator for std::generator does not return, so generators cannot be reassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118196 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-12-24 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |arsen at gcc dot gnu.org
[Bug fortran/117643] F_C_STRING from F23 is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #17 from kargls at comcast dot net ---
On 12/24/24 10:03, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
>
> --- Comment #15 from Jerry DeLisle ---
> From Harald's post. "There is another case I found while playing which is
> rejected:
>
> print *, f_c_string(c_char_"abc", asis)"
>
> I bet the parsing does not handle c_char_ with the two underscores. I have not
> actually tried that case yet. (I wanted to capture it here.)
>
Looks like a more general problem than just my patch. In gdb, I see
(gdb) p *string
$11 = {expr_type = EXPR_CONSTANT, ts = {type = BT_CHARACTER, kind = 1,
u = {derived = 0x80426fba0, cl = 0x80426fba0, pad = 69663648},
interface = 0x0, is_c_interop = 0, is_iso_c = 0,
f90_type = BT_UNKNOWN, deferred = false, interop_kind = 0x0},
...}
It seems parsing of a c_char_'string_constant' is setting neither
is_c_interop nor is_iso_c. I would assume is_c_interop should be
set.
I suppose the error in check.cc(gfc_check_f_c_string) that starts
with
if (string->ts.type != BT_CHARACTER
|| (string->ts.type == BT_CHARACTER
&& (string->ts.kind != 1 || string->ts.is_c_interop != 1)))
can be suppressed for (string.expr_type == EXPR_CONSTANT &&
string->ts.type == BT_CHARACTER && string->ts.kind == 1)
[Bug fortran/117643] F_C_STRING from F23 is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643 Jerry DeLisle changed: What|Removed |Added Attachment #59960|0 |1 is obsolete|| --- Comment #18 from Jerry DeLisle --- Created attachment 59969 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59969&action=edit Finalized patch with a new test case. This is the final patch with a new test case. This takes care of everything I am aware of. A good team effort.
[Bug tree-optimization/118194] [12/13/14/15 regression] spurious warning with -Wmaybe-uninitialized with mlock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118194 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #1 from Xi Ruoyao --- I suppose Glibc should add __attribute__((access(1, none))) for mlock.
[Bug libstdc++/118196] New: The assignment operator for std::generator does not return, so generators cannot be reassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118196
Bug ID: 118196
Summary: The assignment operator for std::generator does not
return, so generators cannot be reassigned
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: florintulba at yahoo dot com
Target Milestone: ---
Created attachment 59966
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59966&action=edit
archived version of 'test.ii' from -save-temps
The program from below crashes when reassigning the generator 'g =
iotaGen(5);':
"
Generator created!
/usr/include/c++/14/generator:713:7: runtime error: execution reached the end
of a value-returning function without returning a value
"
Expected output:
"
Generator created!
Same generator reassigned successfully!
"
test.cpp:
```cpp
#include
#include
std::generator iotaGen(int end) {
for (int x{}; x < end; ++x)
co_yield x;
}
int main() {
auto g{iotaGen(10)};
std::println("Generator created!");
g = iotaGen(5);
std::println("Same generator reassigned successfully!");
return 0;
}
```
After adding "return *this;" at the end of the "generator&
generator::operator=(generator)" into the header and saving the
file as "generator" next to "test.cpp" and changing the include to '#include
"generator"', the program compiles and runs fine.
The used command was:
g++-14 -std=c++23 -D_GLIBCXX_ASSERTIONS -D_GLIBCXX_DEBUG -Wall -Wextra
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations
-fsanitize=undefined -save-temps -o ./build/test test.cpp && ./build/test
Output of 'g++-14 -v':
"
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/14/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
14.2.0-4ubuntu2~24.04' --with-bugurl=file:///usr/share/doc/gcc-14/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr
--with-gcc-major-version-only --program-suffix=-14
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-libstdcxx-backtrace
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-14-ig5ci0/gcc-14-14.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-14-ig5ci0/gcc-14-14.2.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.2.0 (Ubuntu 14.2.0-4ubuntu2~24.04)
"
The generated "test.ii" is attached as 'tbz' archive.
[Bug c++/118195] accepted template member definition with a different template-head
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118195 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #1 from Sam James --- Created attachment 59967 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59967&action=edit YMxbrY5rP.cxx I've attached the contents of the godbolt source.
[Bug middle-end/118050] [15 Regression] timevar.cc:163:18: error: 'CLOCK_MONOTONIC' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118050 Andi Kleen changed: What|Removed |Added CC||andi-gcc at firstfloor dot org --- Comment #2 from Andi Kleen --- The ifdef patch should be fine. Can you just submit/commit it?
[Bug middle-end/118050] [15 Regression] timevar.cc:163:18: error: 'CLOCK_MONOTONIC' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118050 --- Comment #3 from John David Anglin --- Will do.
[Bug debug/118198] GCC wrong debug information bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118198 --- Comment #3 from Chuncai --- Got it, thank you.
[Bug middle-end/91883] Division by a constant could be optimized for known variables value range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91883
David Stone changed:
What|Removed |Added
CC||davidfromonline at gmail dot
com
--- Comment #2 from David Stone ---
Here's another example:
```c++
int baseline(int x) {
return x / 3;
}
int assumed(int x) {
[[assume(x >= 0)]];
return x / 3;
}
int goal(unsigned x) {
return x / 3;
}
```
when compiled with gcc at -O3 generates
```
baseline(int):
movsx rax, edi
sar edi, 31
imulrax, rax, 1431655766
shr rax, 32
sub eax, edi
ret
assumed(int):
movsx rax, edi
sar edi, 31
imulrax, rax, 1431655766
shr rax, 32
sub eax, edi
ret
goal(unsigned int):
mov eax, edi
mov edx, 2863311531
imulrax, rdx
shr rax, 33
ret
```
See it live: https://godbolt.org/z/nMPfxchM4
[Bug middle-end/91883] Division by a constant could be optimized for known variables value range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91883 --- Comment #3 from Andrew Pinski --- (In reply to David Stone from comment #2) > Here's another example: That is a regression on the trunk, see PR 115910 for that issue. The original issue here is unrelated to that.
[Bug target/118197] ICE: SIGSEGV in emit_move_insn (expr.cc:4635) at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118197 Zdenek Sojka changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code Known to fail||13.3.1, 14.2.1, 15.0 --- Comment #1 from Zdenek Sojka --- Compiler output: $ riscv64-unknown-linux-gnu-gcc -O1 testcase.c -wrapper valgrind,-q ==10719== Invalid read of size 2 ==10719==at 0x13E8E6D: emit_move_insn(rtx_def*, rtx_def*) (expr.cc:4635) ==10719==by 0x1CC3393: riscv_lshift_subword(machine_mode, rtx_def*, rtx_def*, rtx_def**) (riscv.cc:11753) ==10719==by 0x26AD397: gen_lrsc_atomic_fetch_andhi(rtx_def*, rtx_def*, rtx_def*, rtx_def*) (sync.md:355) ==10719==by 0x24EA6E4: gen_atomic_fetch_andhi(rtx_def*, rtx_def*, rtx_def*, rtx_def*) (sync.md:310) ==10719==by 0x16DA853: maybe_expand_insn (optabs.cc:8237) ==10719==by 0x16DA853: maybe_emit_op(atomic_op_functions const*, rtx_def*, rtx_def*, rtx_def*, bool, memmodel, bool) (optabs.cc:7664) ==10719==by 0x16E9D76: expand_atomic_fetch_op_no_fallback(rtx_def*, rtx_def*, rtx_def*, rtx_code, memmodel, bool) (optabs.cc:7732) ==10719==by 0x16E9F00: expand_atomic_fetch_op(rtx_def*, rtx_def*, rtx_def*, rtx_code, memmodel, bool) (optabs.cc:7787) ==10719==by 0x12672FE: expand_builtin_atomic_fetch_op(machine_mode, tree_node*, rtx_def*, rtx_code, bool, bool, built_in_function) (builtins.cc:6946) ==10719==by 0x12733CA: expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) (builtins.cc:8907) ==10719==by 0x13E3D8C: expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) (expr.cc:12454) ==10719==by 0x12A1980: expand_expr (expr.h:323) ==10719==by 0x12A1980: expand_call_stmt (cfgexpand.cc:2902) ==10719==by 0x12A1980: expand_gimple_stmt_1 (cfgexpand.cc:3975) ==10719==by 0x12A1980: expand_gimple_stmt(gimple*) (cfgexpand.cc:4122) ==10719==by 0x12A224F: expand_gimple_basic_block(basic_block_def*, bool) (cfgexpand.cc:6185) ==10719== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==10719== during RTL pass: expand testcase.c: In function 'foo': testcase.c:8:3: internal compiler error: Segmentation fault 8 | __atomic_and_fetch(&s, s, 0); | ^~ ... $ riscv64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-20241221205213-r15-6409-g7d83a32aacd600-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/15.0.0/lto-wrapper Target: riscv64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-isa-spec=2.2 --with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu --with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld --with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib --enable-libsanitizer --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-20241221205213-r15-6409-g7d83a32aacd600-checking-yes-rtl-df-extra-riscv64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 15.0.0 20241221 (experimental) (GCC)
[Bug target/118197] New: ICE: SIGSEGV in emit_move_insn (expr.cc:4635) at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118197 Bug ID: 118197 Summary: ICE: SIGSEGV in emit_move_insn (expr.cc:4635) at -O1 and above Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: riscv64-unknown-linux-gnu Created attachment 59968 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59968&action=edit reduced testcase Compiler output: $
[Bug tree-optimization/118194] [12/13/14/15 regression] spurious warning with -Wmaybe-uninitialized with mlock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118194 Sam James changed: What|Removed |Added Summary|spurious warning with |[12/13/14/15 regression] |-Wmaybe-uninitialized with |spurious warning with |mlock |-Wmaybe-uninitialized with ||mlock Keywords||false-positive Target Milestone|--- |12.5
[Bug fortran/117643] F_C_STRING from F23 is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643 --- Comment #15 from Jerry DeLisle --- >From Harald's post. "There is another case I found while playing which is rejected: print *, f_c_string(c_char_"abc", asis)" I bet the parsing does not handle c_char_ with the two underscores. I have not actually tried that case yet. (I wanted to capture it here.)
[Bug c/118198] New: GCC wrong debug information bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118198 Bug ID: 118198 Summary: GCC wrong debug information bug Product: gcc Version: 14.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: imchuncai at gmail dot com Target Milestone: --- Created attachment 59970 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59970&action=edit the preprocessed file 1. the exact version of GCC gcc version 14.2.1 20240912 (Red Hat 14.2.1-3) (GCC) 2. the system type x86_64-redhat-linux 3. the options given when GCC was configured/built gcc -std=gnu23 -O3 -g -Wall -Wextra -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -fsanitize=undefined main.c 4. the complete command line that triggers the bug; ./a.out gdb a.out 5. the compiler output (error messages, warnings, etc.) the first run is fine, the second run will crash, and the debug info shows as follow: #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x776a86d3 in __pthread_kill_internal (threadid=, signo=6) at pthread_kill.c:78 #2 0x7764fc4e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x77637902 in __GI_abort () at abort.c:79 #4 0x004010b5 in must (x=) at main.c:9 #5 main () at main.c:41 6. what is wrong the actual crash is occurred at line 47, which is address is already in use.
[Bug debug/118198] GCC wrong debug information bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118198 --- Comment #1 from Andrew Pinski --- must has been inlined and mostly optimized. In that the several copies of abort has been merged together. There is not much to be done here.
[Bug debug/24490] [4.1 Regression] gcc / gdb backtrace problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24490 Andrew Pinski changed: What|Removed |Added Known to work|| Resolution|INVALID |MOVED
[Bug debug/118198] GCC wrong debug information bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118198 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Andrew Pinski --- main.cold: .LFSB14: .L16: .cfi_def_cfa_offset 16 .cfi_offset 3, -16 .LBB17: .LBB12: .loc 1 9 3 is_stmt 1 view -0 callabort .LVL22: .LBE12: .LBE17: .cfi_endproc .LFE14: .uleb128 0x24 # (DIE (0xa81) DW_TAG_inlined_subroutine) .long 0xc95 # DW_AT_abstract_origin .quad .LBI10 # DW_AT_entry_pc .byte .LVU50 # DW_AT_GNU_entry_view .long .LLRL6 # DW_AT_ranges .byte 0x1 # DW_AT_call_file (main.c) .byte 0x29# DW_AT_call_line .byte 0x2 # DW_AT_call_column .long 0xab5 # DW_AT_sibling .uleb128 0x14 # (DIE (0xa9a) DW_TAG_formal_parameter) .long 0xca2 # DW_AT_abstract_origin .long .LLST7 # DW_AT_location .long .LVUS7 # DW_AT_GNU_locviews .uleb128 0x25 # (DIE (0xaa7) DW_TAG_call_site) .quad .LVL22 # DW_AT_call_return_pc .long 0xa10 # DW_AT_call_origin .byte 0 # end of children of DIE 0xa81 There is not much to be done here as GCC with optimization is combining all of the abort functions into one. There is no way with optimizations to represent this. The best option is use assert instead of abort which then will print out the line # instead.
[Bug fortran/117643] F_C_STRING from F23 is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #19 from Jerry DeLisle ---
(In reply to kargls from comment #17)
> On 12/24/24 10:03, jvdelisle at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
> >
> > --- Comment #15 from Jerry DeLisle ---
> > From Harald's post. "There is another case I found while playing which is
> > rejected:
> >
> > print *, f_c_string(c_char_"abc", asis)"
> >
> > I bet the parsing does not handle c_char_ with the two underscores. I have
> > not
> > actually tried that case yet. (I wanted to capture it here.)
> >
>
> Looks like a more general problem than just my patch. In gdb, I see
>
> (gdb) p *string
> $11 = {expr_type = EXPR_CONSTANT, ts = {type = BT_CHARACTER, kind = 1,
> u = {derived = 0x80426fba0, cl = 0x80426fba0, pad = 69663648},
> interface = 0x0, is_c_interop = 0, is_iso_c = 0,
> f90_type = BT_UNKNOWN, deferred = false, interop_kind = 0x0},
> ...}
>
> It seems parsing of a c_char_'string_constant' is setting neither
> is_c_interop nor is_iso_c. I would assume is_c_interop should be
> set.
>
> I suppose the error in check.cc(gfc_check_f_c_string) that starts
> with
>
> if (string->ts.type != BT_CHARACTER
>|| (string->ts.type == BT_CHARACTER
> && (string->ts.kind != 1 || string->ts.is_c_interop != 1)))
>
> can be suppressed for (string.expr_type == EXPR_CONSTANT &&
> string->ts.type == BT_CHARACTER && string->ts.kind == 1)
Of course after posting what I just did in Comment #18 I see Steve's comment in
17. Maybe I have my logic all wrong on the error message. I saw the kind = 1
and did not expect is_c_interop to be set since c_char_'string_constant' is
equivalent to 1_'string_constant'.
[Bug tree-optimization/118032] [15 regression] Bootstrap slowdown for risc-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032 --- Comment #31 from Mark Wielaard --- (In reply to Filip Kastl from comment #30) > (In reply to Mark Wielaard from comment #28) > > I haven't tried yet, but do you mean something like the following? > > - /* Note: l + 1 is the number of cases of the switch. */ > > - if (l + 1 > (unsigned) param_switch_lower_slow_alg_max_cases) > > -return clusters.copy (); > > Yes. Exactly that. OK, with just those 3 lines reverted (on top of commit gcc-15-6430-g27af1a14f3a) compiling insn-attrtab.cc took just 60 seconds. Total make -j64 took: real139m44.774s user2015m35.598s sys 131m40.992s
