[Bug inline-asm/93981] No EH information generated for asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93981 --- Comment #15 from jwjagersma at gmail dot com --- Created attachment 47970 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47970&action=edit alternative patch v3 Alternative to last patch. Inserts the debug stmt across the fallthrough edge. Let me know which patch would be preferable, and I'll submit it.
[Bug inline-asm/93981] New: No EH information generated for asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93981
Bug ID: 93981
Summary: No EH information generated for asm statements
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: jwjagersma at gmail dot com
Target Milestone: ---
No exception handling information is generated for asm statements:
```
$ cat unwind.cpp
void f()
{
try { asm ("nop #try"); }
catch (...) { asm ("nop #catch"); }
}
$ g++-9 -fnon-call-exceptions unwind.cpp -S -dA -o -
.file "unwind.cpp"
.text
.globl _Z1fv
.type _Z1fv, @function
_Z1fv:
.LFB0:
.cfi_startproc
# BLOCK 2 seq:0
# PRED: ENTRY (FALLTHRU)
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
#APP
# 3 "unwind.cpp" 1
nop #try
# 0 "" 2
#NO_APP
nop
popq%rbp
.cfi_def_cfa 7, 8
# SUCC: EXIT [always]
ret
.cfi_endproc
.LFE0:
.size _Z1fv, .-_Z1fv
.ident "GCC: (Ubuntu 9.2.1-17ubuntu1~18.04.1) 9.2.1 20191102"
.section.note.GNU-stack,"",@progbits
```
Since asms may contain trapping instructions, they should be covered by
an EH region in the unwind tables when compiling with
-fnon-call-exceptions.
[Bug inline-asm/93981] No EH information generated for asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93981 --- Comment #1 from jwjagersma at gmail dot com --- Created attachment 47936 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47936&action=edit proposed patch
[Bug inline-asm/93981] No EH information generated for asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93981 --- Comment #3 from jwjagersma at gmail dot com --- I don't think it needs to. The user can do this manually with .cfi directives.
[Bug inline-asm/93981] No EH information generated for asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93981 --- Comment #5 from jwjagersma at gmail dot com --- (In reply to Segher Boessenkool from comment #4) > Pretending any asm can throw would be a pretty serious code degradation. > > Any asm that is not volatile cannot throw (and be correct code). But > most volatile asm in the wild can never throw, either. The intention is to only produce EH info for volatile asms, and only if -fnon-call-exceptions is given. Asms that take volatile memory operands should be covered too. There are multiple instances in the gcc code that suggest this should be possible, but it seems it was never implemented fully. For example this comment in stmt_could_throw_p: ``` /* The only statements that can throw an exception are assignments, conditionals, calls, resx, and asms. */ ``` And the fact that tree_could_trap_p, stmt_could_throw_p, may_trap_p_1 have cases that return true for asm. Do note that the proposed patch is still incomplete, I ran into an ICE while building libgcc with -fnon-call-exceptions: ``` during GIMPLE pass: ehcleanup ../../../gnu/gcc-9.2.0/libgcc/config/i386/sfp-exceptions.c: In function '__sfp_handle_exceptions': ../../../gnu/gcc-9.2.0/libgcc/config/i386/sfp-exceptions.c:107:1: internal compiler error: in mark_reachable_handlers, at tree-eh.c:3929 107 | } | ^ libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. See <https://gcc.gnu.org/bugs/> for instructions. ``` However I am not knowledgable enough about gcc's inner workings to know what exactly is missing. I'm hoping someone can help me out with this.
[Bug inline-asm/93981] No EH information generated for asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93981 jwjagersma at gmail dot com changed: What|Removed |Added Attachment #47936|0 |1 is obsolete|| --- Comment #6 from jwjagersma at gmail dot com --- Created attachment 47941 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47941&action=edit patch v2 Small change; only call make_eh_edges for asm statements if the asm could throw (is volatile). This does not solve the ICE however, which is caused by a throwing statement that appears before the end of a basic block. It seems that, at some point, extra statements are added after the asm in a bb? But I can't find where that happens.
[Bug inline-asm/93981] No EH information generated for asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93981
--- Comment #8 from jwjagersma at gmail dot com ---
(In reply to Segher Boessenkool from comment #7)
> Ah right, only for -fnon-call-exceptions, I missed that; that is implied
> by stmt_can_throw_internal.
>
> Why only volatile memory operands, btw? Can't *all* memory accesses throw?
Memory access from a known valid pointer (eg. stack variables) can
reasonably be expected not to throw. So I didn't mean 'volatile' in the
literal sense but more in general, pointers that cannot be know to be
valid at compile-time.
> Is that handled somewhere else, or does it need special-casing for asm?
For general memory access I think this is checked in tree_could_trap_p.
The case for ASM_EXPR there would need to be expanded to check if any
of its operands could trap.
> Please use trunk ("master") for development, not an older release?
I was having trouble building a native (mingw-w64) compiler from git,
so I tried using 9.2.0 sources. I'm working on trunk now using an
Ubuntu VM.
> I would think the problem here is caused by your modifications to tree-eh.c,
> but that is not based on understanding this code at all ;-)
To me it seems that some part of the code does not realize that a
throwing asm must be kept at a bb boundary, and inserts statements
after it. That would need to be patched too, if I could find where that
happens.
[Bug inline-asm/93981] No EH information generated for asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93981
--- Comment #9 from jwjagersma at gmail dot com ---
ICE can be replicated with:
```
$ ./cc1plus -O -g -fnon-call-exceptions -I../../gcc/libgcc
../../gcc/libgcc/config/i386/sfp-exceptions.c
void __sfp_handle_exceptions(int)
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data>
../../gcc/libgcc/config/i386/sfp-exceptions.c:107:1: error: statement marked
for throw in middle of block
107 | }
| ^
# VUSE <.MEM_31>
__asm__ __volatile__("fdivs %1" : "=t" f_32 : "m" g, "0" f_30);
../../gcc/libgcc/config/i386/sfp-exceptions.c:107:1: error: statement marked
for throw in middle of block
# VUSE <.MEM_46>
__asm__ __volatile__("fdivs %1" : "=t" f_47 : "m" g, "0" f_45);
during GIMPLE pass: ssa
../../gcc/libgcc/config/i386/sfp-exceptions.c:107:1: internal compiler error:
verify_gimple failed
```
The error message is different but it's the same problem.
When I break there in gdb:
```
(gdb) break tree-cfg.c:5439
Breakpoint 5 at 0xf93816: file ../../gcc/gcc/tree-cfg.c, line 5439.
(gdb) r
Starting program: D:\vmshare\gcc-build\gcc\cc1plus.exe -O -g
-fnon-call-exceptions -I../../gcc/libgcc
../../gcc/libgcc/config/i386/sfp-exceptions.c
void __sfp_handle_exceptions(int)
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data>
Breakpoint 5, verify_gimple_in_cfg (fn=0x3b9e10b8,
verify_nothrow=verify_nothrow@entry=true) at ../../gcc/gcc/tree-cfg.c:5439
warning: Source file is more recent than executable.
5439 error ("statement marked for throw in middle of
block");
=> 0x00f93816 : 48 8d
0d 83 44 1c 01learcx,[rip+0x11c4483]#0x2157ca0 <(anonymous
namespace)::pass_data_call_cdce+14848>
0x00f9381d : e8 86
00 de 00 call 0x1d738a8
(gdb) pp bb
:
# DEBUG BEGIN_STMT
f_30 = 1.0e+0;
# DEBUG f => f_30
g = 0.0;
# DEBUG BEGIN_STMT
__asm__ __volatile__("fdivs %1" : "=t" f_32 : "m" g, "0" f_30);
# DEBUG f => f_32
(gdb) c
Continuing.
../../gcc/libgcc/config/i386/sfp-exceptions.c:107:1: error: statement marked
for throw in middle of block
107 | }
| ^
# VUSE <.MEM_31>
__asm__ __volatile__("fdivs %1" : "=t" f_32 : "m" g, "0" f_30);
Breakpoint 5, verify_gimple_in_cfg (fn=0x3b9e10b8,
verify_nothrow=verify_nothrow@entry=true) at ../../gcc/gcc/tree-cfg.c:5439
5439 error ("statement marked for throw in middle of
block");
=> 0x00f93816 : 48 8d
0d 83 44 1c 01learcx,[rip+0x11c4483]#0x2157ca0 <(anonymous
namespace)::pass_data_call_cdce+14848>
0x00f9381d : e8 86
00 de 00 call 0x1d738a8
(gdb) pp bb
:
# DEBUG BEGIN_STMT
f_45 = 1.0e+0;
# DEBUG f => f_45
g = 3.0e+0;
# DEBUG BEGIN_STMT
__asm__ __volatile__("fdivs %1" : "=t" f_47 : "m" g, "0" f_45);
# DEBUG f => f_47
```
So the problem is that DEBUG stmts are inserted after a throwing asm.
[Bug inline-asm/93981] No EH information generated for asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93981 --- Comment #11 from jwjagersma at gmail dot com --- (In reply to Richard Biener from comment #10) > Some stmt-ends-BB predicates are probably off for asms. For stmt_ends_bb_p (tree-cfg.c:2763) the call chain looks like this: stmt_ends_bb_p -> is_ctrl_altering_stmt -> stmt_can_throw_internal -> stmt_could_throw_p -> gimple_asm_volatile_p So volatile asms are considered bb-enders, now that they have a landing pad, which stmt_can_throw_internal checks for. I am not sure how that works actually, do all throwing statements get a landing pad at first, even if there is no try block? Because that looks to be the case, I assume these are eliminated in some later pass. Using gdb I found that the DEBUG stmt is added in rewrite_stmt (tree-into-ssa.c:1417) which does so without considering if the bb has an EH edge or not. How does this work for other throwing statements?
[Bug inline-asm/93981] No EH information generated for asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93981 --- Comment #13 from jwjagersma at gmail dot com --- Is there some point at which debug statements are supposed to be copied over to the next BBs? That appears to be what maybe_move_debug_stmts_to_successors (tree-inline.c:2799) does, but it is only called for inlined functions. Or alternatively, should mark_reachable_handlers and verify_gimple_in_cfg be made to ignore the debug statement, by using gsi_last_nondebug_bb?
[Bug inline-asm/93981] No EH information generated for asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93981 jwjagersma at gmail dot com changed: What|Removed |Added Attachment #47941|0 |1 is obsolete|| --- Comment #14 from jwjagersma at gmail dot com --- Created attachment 47951 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47951&action=edit proposed patch v3 I went with the option to ignore these debug statements. This works for me now, I am able to build target libraries and some of my own code with -fnon-call-exceptions. However I still think it's strange that this used to work for other throwing or control statements. I feel like I'm missing something here.
[Bug lto/86651] New: lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86651
Bug ID: 86651
Summary: lto-wrapper.exe: fatal error:
simple_object_copy_lto_debug_sections not implemented:
Invalid argument
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: jwjagersma at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Compiling anything with '-flto -g' yields the following error message during
linking:
$ echo "void main(){}" > nop.c
$ i586-pc-msdosdjgpp-gcc -flto -g nop.c
lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not
implemented: Invalid argument
compilation terminated.
collect2.exe: fatal error: lto-wrapper returned 1 exit status
compilation terminated.
$ i586-pc-msdosdjgpp-gcc -v
Using built-in specs.
COLLECT_GCC=D:\msys64\usr\local\cross\bin\i586-pc-msdosdjgpp-gcc.exe
COLLECT_LTO_WRAPPER=D:/msys64/usr/local/cross/libexec/gcc/i586-pc-msdosdjgpp/8.1.0/lto-wrapper.exe
Target: i586-pc-msdosdjgpp
Configured with: ../gnu/gcc-8.10/configure --disable-plugin --enable-lto
--enable-libstdcxx-filesystem-ts --disable-nls --enable-libquadmath-support
--enable-version-specific-runtime-libs --enable-fat --disable-libstdcxx-pch
--target=i586-pc-msdosdjgpp --prefix=/usr/local/cross --enable-languages=c,c++
Thread model: single
gcc version 8.1.0 (GCC)
This appears to be the same bug as pr85238, which is marked FIXED / RESOLVED.
[Bug lto/86651] lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86651 --- Comment #2 from jwjagersma at gmail dot com --- (In reply to U.Mutlu from comment #1) > Do you get the same error if you leave out the --disable-plugin ? Yes, same error.
[Bug target/86651] [8/9 Regression] lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86651 --- Comment #4 from jwjagersma at gmail dot com --- Created attachment 44439 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44439&action=edit Proposed patch I cloned the fix that was applied to cygwin/mingw targets in SVN r259347. There didn't seem to be any way to identify COFF targets for use in dwarf2out.c, so I defined a new macro TARGET_COFF. I hope this is the right way to do it. This patch works for me, please review and merge if possible.
[Bug target/86651] [8/9 Regression] lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86651 --- Comment #6 from jwjagersma at gmail dot com --- (In reply to Richard Biener from comment #5) After building a more complex program with the above patch (applied to gcc 8.1.0 release sources), this ICE appears during linking: lto1.exe: internal compiler error: in gen_subprogram_die, at dwarf2out.c:22668 libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. See <https://gcc.gnu.org/bugs/> for instructions. lto-wrapper.exe: fatal error: D:\msys64\usr\local\cross\bin\i586-pc-msdosdjgpp-g++.exe returned 1 exit status compilation terminated. collect2.exe: fatal error: lto-wrapper returned 1 exit status compilation terminated. Being entirely unfamiliar with gcc internals, I'm not sure what went wrong here.
[Bug target/86651] [8/9 Regression] lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86651 --- Comment #8 from jwjagersma at gmail dot com --- (In reply to rguent...@suse.de from comment #7) > There are latent bugs that now affect darwin, mingw and djgpp (after your > patch) by default when compiling with -g0 and linking with -g > (which is basically what those patches enforce). > > Some of them have been fixed on the GCC 8 branch already so I suggest > you use the GCC 8.2 release candidate tarball to see if it works there. > (ftp://gcc.gnu.org/pub/gcc/snapshots/8.2.0-RC-20180719/) I successfully built the snapshot you linked with this patch applied, but compiling my c++ program still generated the same ICE.
[Bug target/86651] [8/9 Regression] lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86651 --- Comment #10 from jwjagersma at gmail dot com --- Created attachment 2 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=2&action=edit preprocessed source to trigger ICE (In reply to rguent...@suse.de from comment #9) > Thanks for checking. Do you maybe can make preprocessed source of required > CUs available? You can reduce the set of needed inputs by using -shared at > link time so unresolved symbols are considered OK. I've attached the entire preprocessed source (djgpp does not support -shared). Compile/link with: i586-pc-msdosdjgpp-g++ -std=gnu++17 -fconcepts -masm=intel -flto -g *.i
[Bug target/86651] [8/9 Regression] lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86651 --- Comment #17 from jwjagersma at gmail dot com --- If anyone opens a new PR, please cc me. I am unable to contribute right now due to some health issues.
[Bug c++/70387] New: -fnon-call-exceptions has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70387
Bug ID: 70387
Summary: -fnon-call-exceptions has no effect
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jwjagersma at gmail dot com
Target Milestone: ---
I wrote some code to trap a hardware exception, and transfer control to a
signal handler which throws a C++ exception.
From the documentation, I believe '-fnon-call-exceptions' (and/or
'-fasynchronous-unwind-tables') should allow me to do this, but it doesn't
work.
It appears that gcc doesn't consider that non-call instructions may throw, and
silently omits the try/catch block around it. The exception is only caught when
the trapped instruction appears in a (non-inlined) function, or inbetween two
function calls.
--- Output from 'gcc -v':
Using built-in specs.
COLLECT_GCC=D:\msys64\usr\local\djgpp\i586-pc-msdosdjgpp\bin\gcc.exe
COLLECT_LTO_WRAPPER=D:/msys64/usr/local/djgpp/lib/gcc/../../libexec/gcc/i586-pc-msdosdjgpp/5.3.0/lto-wrapper.exe
Target: i586-pc-msdosdjgpp
Configured with: ../gnu/gcc-5.30/configure --host= --build=x86_64-w64-mingw32
--target=i586-pc-msdosdjgpp --program-prefix=i586-pc-msdosdjgpp-
--prefix=/usr/local/djgpp --disable-nls --disable-plugin --disable-lto
--enable-lto --enable-libquadmath-support
--with-gmp=/home/JW/build-djgpp/build/djcross-gcc-5.3.0/tmpinst
--with-mpfr=/home/JW/build-djgpp/build/djcross-gcc-5.3.0/tmpinst
--with-mpc=/home/JW/build-djgpp/build/djcross-gcc-5.3.0/tmpinst
--enable-version-specific-runtime-libs --enable-languages=c,c++
Thread model: single
gcc version 5.3.0 (GCC)
--- Example code: (implementation details omitted)
void throw_exception()
{
throw std::runtime_error("Division by zero!");
}
__attribute__((noinline))
void try_div0()
{
cout << 1 / 0 << endl;
}
void nop() { asm(""); }
int main()
{
// this class traps a hardware exception (division by zero, in this case)
and calls the supplied lambda function.
exception_wrapper div0_exc { 0, [] (exception_frame* frame, bool)
{
// only handle exceptions that occured in our own code
if (frame->address.segment != get_cs()) return false;
// sub , 4;
frame->stack.offset -= 4;
// get pointer to []
auto* stack = reinterpret_cast(frame->stack.offset);
// mov [], ;
*stack = frame->address.offset;
// resume at throw_exception()
frame->address.offset =
reinterpret_cast(throw_exception);
return true;
} };
try
{ // thrown from inside a function, this exception is caught.
try_div0();
}
catch (std::exception& e) { cout << "oops: " << e.what() << endl; }
try
{ // thrown inbetween two function calls, this exception is caught.
nop();
cout << 1 / 0 << endl;
nop();
}
catch (std::exception& e) { cout << "oops: " << e.what() << endl; }
try
{ // throws, but is NOT CAUGHT!
cout << 1 / 0 << endl;
}
catch (std::exception& e) { cout << "oops: " << e.what() << endl; }
}
[Bug c++/70387] -fnon-call-exceptions has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70387 --- Comment #2 from jwjagersma at gmail dot com --- Created attachment 38077 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38077&action=edit Test case I reduced my code to the bare minimum required to reproduce this issue. Compile with djgpp: "g++ -std=gnu++14 -fnon-call-exceptions -fasynchronous-unwind-tables -o traptest.exe traptest.cpp"
[Bug c++/70387] -fnon-call-exceptions has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70387
--- Comment #3 from jwjagersma at gmail dot com ---
Possibly interesting observation; the exception can be caught when using a
pointer as divisor:
int i = 0;
int* volatile p = &i;
try
{
std::cout << 1 / *p << std::endl;
}
catch (std::exception& e)
{
std::cout << "oops: " << e.what() << std::endl;
}
[Bug c++/70387] -fnon-call-exceptions has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70387 --- Comment #4 from jwjagersma at gmail dot com --- Created attachment 38096 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38096&action=edit Test case 2 Generic test case, which doesn't require djgpp or a DOS machine. (Assuming throwing from inline asm is similar enough) compile with: "g++ -std=gnu++14 -fnon-call-exceptions throw_from_asm.cpp"
[Bug target/79935] New: DJGPP: misaligned stack in static constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79935 Bug ID: 79935 Summary: DJGPP: misaligned stack in static constructors Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jwjagersma at gmail dot com Target Milestone: --- Created attachment 40901 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40901&action=edit test case See included test case. The aligned_t variables are meant to be aligned on a 16-byte boundary, but the alignment is 8 bytes off when used in static constructors. GCC version: $ g++ -v Using built-in specs. COLLECT_GCC=D:\msys64\usr\local\djgpp\i586-pc-msdosdjgpp\bin\g++.exe COLLECT_LTO_WRAPPER=D:/msys64/usr/local/djgpp/lib/gcc/../../libexec/gcc/i586-pc-msdosdjgpp/6.1.0/lto-wrapper.exe Target: i586-pc-msdosdjgpp Configured with: ../gnu/gcc-6.10/configure --build=x86_64-w64-mingw32 --target=i586-pc-msdosdjgpp --program-prefix=i586-pc-msdosdjgpp- --prefix=/usr/local/djgpp --disable-nls --disable-plugin --enable-lto --enable-libquadmath-support --with-gmp=/home/JW/build-djgpp/build/djcross-gcc-6.1.0/tmpinst --with-mpfr=/home/JW/build-djgpp/build/djcross-gcc-6.1.0/tmpinst --with-mpc=/home/JW/build-djgpp/build/djcross-gcc-6.1.0/tmpinst --enable-version-specific-runtime-libs --enable-languages=c,c++ Thread model: single gcc version 6.1.0 (GCC)
[Bug target/79935] DJGPP: misaligned stack in static constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79935 --- Comment #4 from jwjagersma at gmail dot com --- > More likely, DJGPP just doesn't support more than 8-byte alignment. I just had the same problem in a normal function too, so I suppose that is the case then. I do think djgpp should support 16-byte alignment since programs compiled with it could potentially use SSE instructions (which is what I'm trying to do, using -O3 -march=pentium3) which cause GP faults on misaligned memory access. Where do I submit this to the djgpp list? The bug tracker on delorie.com seems very inactive.
[Bug inline-asm/80225] New: ICE when using =cc output operand incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80225
Bug ID: 80225
Summary: ICE when using =cc output operand incorrectly
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: jwjagersma at gmail dot com
Target Milestone: ---
Invalid code, but the error message is less than helpful. The following
triggers an ICE:
int main()
{
bool z;
int ar;
asm("lar %0, %1;" : "=@ccz"(z), "=r"(ar) : "rm"(0x1234));
if (!z) return -1;
return ar;
}
$ g++ -masm=intel asm_flags.cpp
asm_flags.cpp: In function 'int main()':
asm_flags.cpp:8:1: internal compiler error: in print_reg, at
config/i386/i386.c:16601
}
^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://sourceforge.net/projects/msys2> for instructions.
Version info:
$ g++ -v
Using built-in specs.
COLLECT_GCC=D:\msys64\mingw64\bin\g++.exe
COLLECT_LTO_WRAPPER=D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-6.3.0/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
--libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64
--with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada
--enable-shared --enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check
--enable-lto --enable-libgomp --disable-multilib --enable-checking=release
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64
--with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64
--with-pkgversion='Rev2, Built by MSYS2 project'
--with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as
--with-gnu-ld
Thread model: posix
gcc version 6.3.0 (Rev2, Built by MSYS2 project)
[Bug target/80225] ICE when using =@cc output operand incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80225 jwjagersma at gmail dot com changed: What|Removed |Added Target|x86_64-w64-mingw32 |x86_64-w64-mingw32, ||i686-w64-mingw32, ||i586-pc-msdosdjgpp --- Comment #1 from jwjagersma at gmail dot com --- I should mention I also reproduced this issue on i686-w64-mingw32 and i586-pc-msdosdjgpp (where I first encountered it). Since the error occurs in a function called "print_reg", I imagine this would be reproducible on any x86/amd64 target, as the flags register doesn't have a printable name.
[Bug c++/70387] -fnon-call-exceptions has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70387 --- Comment #5 from jwjagersma at gmail dot com --- Bumping this, I hope it will be resolved someday. I found a reference to the same issue, with another test case using posix signal handlers: https://cygwin.com/ml/cygwin/2010-07/msg00195.html This claims it used to work on 3.3.4, and failed from 4.3.4 on.
[Bug c++/80363] New: #'vec_cond_expr' not supported by dump_expr#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80363 Bug ID: 80363 Summary: #'vec_cond_expr' not supported by dump_expr# Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jwjagersma at gmail dot com Target Milestone: --- Created attachment 41157 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41157&action=edit test case Not sure if this is valid code, see attached source file. (I was kinda hoping std::max would use the maxps sse instruction. that was a wild guess...) In any case, the error message here seems wrong: $ g++ vectest.cpp In file included from D:/msys64/mingw64/include/c++/6.3.0/algorithm:61:0, from vectest.cpp:1: D:/msys64/mingw64/include/c++/6.3.0/bits/stl_algobase.h: In instantiation of 'constexpr const _Tp& std::max(const _Tp&, const _Tp&) [with _Tp = __vector(4) float]': vectest.cpp:16:22: required from here D:/msys64/mingw64/include/c++/6.3.0/bits/stl_algobase.h:224:7: error: could not convert '#'vec_cond_expr' not supported by dump_expr#' from '__vector(4) int' to 'bool' if (__a < __b) ^~
[Bug target/80367] New: internal compiler error: in print_reg, at config/i386/i386.c:16549
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80367 Bug ID: 80367 Summary: internal compiler error: in print_reg, at config/i386/i386.c:16549 Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jwjagersma at gmail dot com Target Milestone: --- I got this ICE yesterday and I haven't been able to figure out what caused it, or how to reduce the code to a small test case. The only information I can provide right now is the full program: https://github.com/jwt27/jwdpmi_test.git checkout commit 88431be254cb414fb6499cefe0caf584a6c316f4 (should be the last one, as of now) I believe this error occured after I changed function pixel::max() (include/jw/video/pixel.h:202) to return std::int32_t (previously std::int16_t). This would make the vector functions in the pixel class use a vector type of 4*int. But I don't see how that is directly related, since it looks like the ICE originates from the inline asm in src/vbe.cpp. I also tried changing the return type back to std::int16_t but the error is still there. Also it only happens with some -march= options. pentium2 and earlier compiles fine, core2 and later work too, anything inbetween (pentium3 to prescott) fails. $ make make -C lib/libjwdpmi/ make[1]: Entering directory '/home/JW/projects/jwdpmi_test/lib/libjwdpmi' g++ -pipe -masm=intel -MD -MP -O3 -flto=24 -flto-odr-type-merging -mmmx -msse -march=pentium3 -ffast-math -mfpmath=both -std=gnu++17 -Wall -Wextra -Wno-attributes -Wsuggest-override -Wattributes -ggdb -fnon-call-exceptions -fasynchronous-unwind-tables -mcld -mpreferred-stack-boundary=4 -mstackrealign -DNDEBUG -save-temps -masm=intel -std=gnu++17 -Wall -Wextra -fasynchronous-unwind-tables -fnon-call-exceptions -mcld -mpreferred-stack-boundary=4 -MD -MP -MF obj/vbe.d -o obj/vbe.o -Iinclude -c src/vbe.cpp g++.exe: warning: -pipe ignored because -save-temps specified src/vbe.cpp: In member function 'jw::video::vbe2::set_palette(jw::video::pixel const*, jw::video::pixel const*, unsigned long, bool)': src/vbe.cpp:647:9: internal compiler error: in print_reg, at config/i386/i386.c:16549 } ^ libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. make[1]: *** [makefile:39: obj/vbe.o] Error 1 make[1]: Leaving directory '/home/JW/projects/jwdpmi_test/lib/libjwdpmi' make: *** [makefile:65: libjwdpmi] Error 2 $ g++ -v Using built-in specs. COLLECT_GCC=D:\msys64\usr\local\djgpp\i586-pc-msdosdjgpp\bin\g++.exe COLLECT_LTO_WRAPPER=D:/msys64/usr/local/djgpp/lib/gcc/../../libexec/gcc/i586-pc-msdosdjgpp/6.1.0/lto-wrapper.exe Target: i586-pc-msdosdjgpp Configured with: ../gnu/gcc-6.10/configure --build=x86_64-w64-mingw32 --target=i586-pc-msdosdjgpp --program-prefix=i586-pc-msdosdjgpp- --prefix=/usr/local/djgpp --disable-nls --disable-plugin --enable-lto --enable-libquadmath-support --with-gmp=/home/JW/build-djgpp/build/djcross-gcc-6.1.0/tmpinst --with-mpfr=/home/JW/build-djgpp/build/djcross-gcc-6.1.0/tmpinst --with-mpc=/home/JW/build-djgpp/build/djcross-gcc-6.1.0/tmpinst --enable-version-specific-runtime-libs --enable-languages=c,c++ Thread model: single gcc version 6.1.0 (GCC)
[Bug target/80367] internal compiler error: in print_reg, at config/i386/i386.c:16549
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80367 --- Comment #2 from jwjagersma at gmail dot com --- Created attachment 41161 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41161&action=edit vbe.ii gzipped
[Bug target/80367] internal compiler error: in print_reg, at config/i386/i386.c:16549
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80367 --- Comment #3 from jwjagersma at gmail dot com --- Here's an interesting observation: The ICE doesn't occur when I remove the "esp" clobber from inline asm in vbe2::set_palette() (vbe.cpp:621, vbe.ii:66207). But that's obviously not a solution since it produces wrong code.
[Bug target/80367] internal compiler error: in print_reg, at config/i386/i386.c:16549
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80367 --- Comment #4 from jwjagersma at gmail dot com --- I fixed my code by changing the first two asm inputs to memory operands (should've done that anyway since I'm potentially modifying ds, so that could have caused issues at runtime). No longer triggers an ICE now, but still I don't think that should've happened in the first place with "rm" constraints. I'm guessing it ran out of registers maybe? But then that should've caused an "impossible constraints" error instead.
[Bug c++/80371] New: std::is_integral and std::is_floating_point fail with vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80371 Bug ID: 80371 Summary: std::is_integral and std::is_floating_point fail with vector types Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jwjagersma at gmail dot com Target Milestone: --- Testing with std::is_integral or std::is_floating_point fails for vector types. I don't think that's supposed to happen. $ cat vectest.cpp #include using Vi [[gnu::vector_size(4 * sizeof(int))]] = int; using Vf [[gnu::vector_size(4 * sizeof(float))]] = float; static_assert(std::is_integral::value, ""); static_assert(std::is_floating_point::value, ""); $ g++ vectest.cpp vectest.cpp:6:1: error: static assertion failed static_assert(std::is_integral::value, ""); ^ vectest.cpp:7:1: error: static assertion failed static_assert(std::is_floating_point::value, ""); ^ $ g++ -v Using built-in specs. COLLECT_GCC=D:\msys64\mingw64\bin\g++.exe COLLECT_LTO_WRAPPER=D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../gcc-6.3.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev2, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld Thread model: posix gcc version 6.3.0 (Rev2, Built by MSYS2 project)
[Bug target/80367] internal compiler error: in print_reg, at config/i386/i386.c:16549
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80367 --- Comment #6 from jwjagersma at gmail dot com --- So "esp" is not a valid register to clobber? I thought it would only make the compiler use ebp instead to reference stack memory operands. After all esp-relative operands wouldn't be valid after a push/pop in inline asm. Also, I identified the minimum compiler flags required to reproduce this issue: $ /usr/local/djgpp/bin/i586-pc-msdosdjgpp-g++ -march=pentium3 -masm=intel -mstackrealign -O3 vbe.ii src/vbe.cpp: In member function 'virtual void jw::video::vbe2::set_palette(const px32*, const px32*, std::size_t, bool)': src/vbe.cpp:647:9: internal compiler error: in print_reg, at config/i386/i386.c:16549
[Bug target/80367] internal compiler error: in print_reg, at config/i386/i386.c:16549
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80367 --- Comment #7 from jwjagersma at gmail dot com --- Created attachment 41167 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41167&action=edit test case Here is a reduced test case that causes a similar (likely the same?) ICE on i686-w64-mingw32. The line number in print_reg is different, but then this is a different gcc version (6.3.0). Interestingly, compiling with -O3 here prints a more sensible error message. $ g++ -masm=intel -march=pentium3 -mstackrealign -O3 ice_print_reg.cpp ice_print_reg.cpp: In function 'int main()': ice_print_reg.cpp:19:30: error: 'asm' operand has impossible constraints : "esi", "esp", "cc"); ^ $ g++ -masm=intel -march=pentium3 -mstackrealign ice_print_reg.cpp ice_print_reg.cpp: In function 'int main()': ice_print_reg.cpp:20:1: internal compiler error: in print_reg, at config/i386/i386.c:16601 } ^ This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. ice_print_reg.cpp:20:1: internal compiler error: Aborted This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. g++.exe: internal compiler error: Aborted (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See <https://sourceforge.net/projects/msys2> for instructions. $ g++ -v Using built-in specs. COLLECT_GCC=D:\msys64\mingw32\bin\g++.exe COLLECT_LTO_WRAPPER=D:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.3.0/lto-wrapper.exe Target: i686-w64-mingw32 Configured with: ../gcc-6.3.0/configure --prefix=/mingw32 --with-local-prefix=/mingw32/local --build=i686-w64-mingw32 --host=i686-w64-mingw32 --target=i686-w64-mingw32 --with-native-system-header-dir=/mingw32/i686-w64-mingw32/include --libexecdir=/mingw32/lib --enable-bootstrap --with-arch=i686 --with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw32 --with-mpfr=/mingw32 --with-mpc=/mingw32 --with-isl=/mingw32 --with-pkgversion='Rev2, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld --disable-sjlj-exceptions --with-dwarf2 Thread model: posix gcc version 6.3.0 (Rev2, Built by MSYS2 project)
[Bug inline-asm/98096] New: Inconsistent operand numbering for asm goto with in-out operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98096
Bug ID: 98096
Summary: Inconsistent operand numbering for asm goto with
in-out operands
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: jwjagersma at gmail dot com
Target Milestone: ---
For the following code:
asm goto ("# %0 %1 %2" : "+r" (i) ::: jmp);
Two registers are printed before the label name, because the in-out operand is
split internally. This is somewhat surprising from a user perspective.
But then:
asm goto ("# %l[jmp]" : "+r" (i) ::: jmp);
Produces an error: '%l' operand isn't a label.
So label operands are numbered after the in-out operand is split, but %l is
evaluated without this split taken into account. Docs suggest it should be
possible to use asm goto with both in-outs and %l operands simultaneously.
[Bug c++/107280] New: ICE: tree check: expected constructor, have view_convert_expr in cxx_eval_store_expression, at cp/constexpr.cc:5928
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107280
Bug ID: 107280
Summary: ICE: tree check: expected constructor, have
view_convert_expr in cxx_eval_store_expression, at
cp/constexpr.cc:5928
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jwjagersma at gmail dot com
Target Milestone: ---
Created attachment 53710
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53710&action=edit
output from -freport-bug
Ran into this today, while trying to do some basic string manipulation:
$ cat ~/ice.cpp
struct string
{
char str[8] = " ";
const char* data() { return str; }
};
template
consteval string test()
{
string str { };
char* p = str.str;
auto append = [&p](const char* s)
{
while (*s != '\0') *p++ = *s++;
++p;
};
if (a) append("abc");
if (b) append("xyz");
return str;
}
auto f() { return test(); }
$ g++ -std=c++20 ~/ice.cpp
/home/jw/ice.cpp: In function 'auto f()':
/home/jw/ice.cpp:24:34: in 'constexpr' expansion of 'test()'
/home/jw/ice.cpp:19:16: in 'constexpr' expansion of 'append.test()::(((const char*)"abc"))'
/home/jw/ice.cpp:24:34: internal compiler error: tree check: expected
constructor, have view_convert_expr in cxx_eval_store_expres
sion, at cp/constexpr.cc:5928
24 | auto f() { return test(); }
| ~~~^~
...
[Bug c++/69549] Named Address Spaces does not compile in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69549 --- Comment #8 from jwjagersma at gmail dot com --- Created attachment 51808 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51808&action=edit basic implementation Tentative patch. Produces working code but could use some (many) checks to diagnose incorrect usage, eg. AS-qualified struct fields, function parameters, non-type template parameters. Assigning an AS-qualified pointer to non-qualified is already diagnosed correctly, but the inverse is not. I don't know if mangling address-space-qualified member functions would be covered by ABI version 10, or if the version number needs to be bumped.
[Bug c++/69549] Named Address Spaces does not compile in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69549 --- Comment #9 from jwjagersma at gmail dot com --- Created attachment 51840 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51840&action=edit diagnostics This patch adds checks for: - Top-level AS-qualifiers on fields, local variables, function parameters and function return types. - Assignment of pointers and references to different address spaces. - Combining AS-qualifiers in template substitution. An appropriate error message is emitted in each case. Not detected: AS-qualifiers on non-type template parameters (but they are stripped and ignored, of course). I think this covers most invalid uses. Am I missing anything?
[Bug c++/107417] New: g++ fails to recognize parameter pack in requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107417
Bug ID: 107417
Summary: g++ fails to recognize parameter pack in
requires-expression
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jwjagersma at gmail dot com
Target Milestone: ---
Given the following code:
$ cat fold.cpp
template
requires (requires (T x) { x; } and ...)
auto func(T...) { }
g++ seems to forget that T is a parameter pack:
$ g++ -std=c++20 fold.cpp
fold.cpp:2:11: error: operand of fold expression has no unexpanded parameter
packs
2 | requires (requires (T x) { x; } and ...)
| ^
This issue is present on both 12.2 and latest 13.0. Clang and msvc do accept
it.
[Bug c++/107429] New: misdiagnosed "constraint depends on itself" in overloaded functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107429
Bug ID: 107429
Summary: misdiagnosed "constraint depends on itself" in
overloaded functions
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jwjagersma at gmail dot com
Target Milestone: ---
Given the following code:
struct tag_foo { } inline constexpr foo;
struct tag_bar { } inline constexpr bar;
template
auto f(tag_foo, T... x)
{
return (x + ...);
}
template
concept fooable = requires (T... x) { f(foo, x...); };
template requires (fooable)
auto f(tag_bar, T... x)
{
return f(foo, x...);
}
auto test()
{
return f(bar, 1, 2, 3);
}
g++ claims that "satisfaction of atomic constraint [...] depends on itself",
but the overload of 'f()' that is checked by 'fooable' is not constrained in
any way.
I am not 100% sure if this is valid code, but clang and msvc do not make the
same complaint, so I'm inclined to believe g++ is in error here.
[Bug c++/107429] misdiagnosed "constraint depends on itself" in overloaded functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107429 --- Comment #2 from jwjagersma at gmail dot com --- Thanks, I thought I searched but somehow missed that PR. >From a user perspective it seems very surprising that this workaround compiles, but the obvious implementation doesn't. I do hope it gets addressed someday.
[Bug c++/107439] New: use of static member function in requires-expression depends on declaration order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107439
Bug ID: 107439
Summary: use of static member function in requires-expression
depends on declaration order
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jwjagersma at gmail dot com
Target Milestone: ---
The following example fails to compile, as g++ complains that a declaration of
'check' is not available. Reordering it so that 'check' is declared before
its use in the requires-expression makes it work. This seems inconsistent, as
member functions are normally expected to be usable anywhere within the class
definition.
$ cat requires-memfn.cpp
struct A
{
template requires (check())
auto func(T) { }
template
static consteval bool check() { return true; }
};
$ g++ -std=c++20 requires-memfn.cpp
requires-memfn.cpp:3:34: error: there are no arguments to ‘check’ that depend
on a template parameter, so a declaration of ‘check’
must be available [-fpermissive]
3 | template requires (check())
| ^~~~
requires-memfn.cpp:3:34: note: (if you use ‘-fpermissive’, G++ will accept
your code, but allowing the use of an undeclared name is deprecated)
[Bug c++/107496] New: [Feature request] Conditional attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107496
Bug ID: 107496
Summary: [Feature request] Conditional attributes
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jwjagersma at gmail dot com
Target Milestone: ---
I'd like to request a new extension feature: the ability to enable or disable
attributes based on a conditional expression.
This could be implemented either via a sort of meta-attribute:
template
[[gnu::conditional(A, always_inline), gnu::conditional(B, noinline)]]
auto f() { /* ... */ }
Or by reusing the template syntax:
template
[[gnu::always_inline, gnu::noinline]]
auto f() { /* ... */ }
Although maybe the latter should only be allowed via the __attribute__ syntax,
which is already a GNU extension.
I did recently send in a small patch to allow selecting a string conditionally
in the i386 'target' attribute (no responses yet though). I really need it for
that particular case, and it would be nice if that could make it in gcc 13, if
there are no objections.
For the longer term though, I think being able to apply this to all attributes
would be a very useful feature to have.
[Bug c++/69549] Named Address Spaces does not compile in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69549 --- Comment #12 from jwjagersma at gmail dot com --- (In reply to Xi Ruoyao from comment #11) > Generally a patch should be sent to gcc-patc...@gcc.gnu.org. See > https://gcc.gnu.org/contribute.html. The patches attached to a Bugzilla > ticket are considered prototypes and for discussion only. This patch isn't complete yet, I posted it here in hopes of receiving some comments. It works for simple structs that are managed externally (eg, from inline asm). But other than that it doesn't integrate with the C++ type system so well. There is no way to make AS-qualified ctors/dtors (in fact, calling a dtor on an AS-qualified ptr/ref is currently allowed - that's very bad), and also no placement-new for AS-qualified pointers. Granted, I don't think clang implements that either, but it does provide stuff like __builtin_memcpy(). That is missing from this patch. I also recall running into one bug where it generated code to access a stack variable via fs:[esp]. I think it was something to do with rvalue references? But it disappeared when I attempted to write a smaller test case, couldn't figure that one out.
[Bug c++/110128] New: copy attribute does not copy from template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110128
Bug ID: 110128
Summary: copy attribute does not copy from template
specializations
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jwjagersma at gmail dot com
Target Milestone: ---
Given the following example:
template
void check_num();
template<> [[gnu::warning("unlucky number")]]
void check_num<13>();
template<> [[gnu::error("evil number")]]
void check_num<666>();
template [[gnu::copy(check_num)]]
int num() { return I; }
int main()
{
return num<42>() + num<13>() + num<666>();
}
GCC only produces a number of -Wattributes warnings:
$ g++ test-copy.cpp
test-copy.cpp: In substitution of ‘template int num() [with int I =
42]’:
test-copy.cpp:16:19: required from here
test-copy.cpp:12:5: warning: ‘copy’ attribute ignored on a declaration of a
different kind than referenced symbol [-Wattributes]
12 | int num() { return I; }
| ^~~
test-copy.cpp: In substitution of ‘template int num() [with int I =
13]’:
test-copy.cpp:16:31: required from here
test-copy.cpp:12:5: warning: ‘copy’ attribute ignored on a declaration of a
different kind than referenced symbol [-Wattributes]
test-copy.cpp: In substitution of ‘template int num() [with int I =
666]’:
test-copy.cpp:16:44: required from here
test-copy.cpp:12:5: warning: ‘copy’ attribute ignored on a declaration of a
different kind than referenced symbol [-Wattributes]
PR89309 claims these are only spurious, but in this case they are not. The
attributes are not copied.
[Bug c++/110128] copy attribute does not copy from template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110128
--- Comment #1 from jwjagersma at gmail dot com ---
Additionally, the following example does not produce any -Wattributes warnings
at all, but the attributes are still not copied:
template
struct check_num
{
static void check();
};
template<>
struct check_num<13>
{
[[gnu::warning("unlucky number")]]
static void check();
};
template<>
struct check_num<666>
{
[[gnu::error("evil number")]]
static void check();
};
template [[gnu::copy(check_num::check)]]
int num() { return I; }
int main()
{
return num<42>() + num<13>() + num<666>();
}
[Bug target/116869] New: Profiler count register conflicts with regparm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116869
Bug ID: 116869
Summary: Profiler count register conflicts with regparm
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jwjagersma at gmail dot com
Target Milestone: ---
On i386 targets that pass a profiler count address in EDX, the second
argument to a regparm function is clobbered:
$ cat test.c
__attribute((regparm(2)))
int add (int a, int b)
{
return a + b;
}
$ i386-pc-msdosdjgpp-gcc -S test.c -O -pg -o -
.file "test.c"
.section .text
.globl _add
_add:
pushl %ebp
movl%esp, %ebp
.section .data
.p2align 2
LP0:
.long 0
.section .text
movl$LP0, %edx
1: call_mcount
addl%edx, %eax
popl%ebp
ret
.ident "GCC: (GNU) 14.2.0"
[Bug target/116869] Profiler count register conflicts with regparm for i386-pc-msdosdjgpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116869 --- Comment #3 from jwjagersma at gmail dot com --- (In reply to Andrew Pinski from comment #1) > msdosdjgpp might be the only target which does not define > NO_PROFILE_COUNTERS . I figured as much, but wasn't sure. From briefly poking around in config/i386 I got the impression that there could be more such targets.
