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 fall
: 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 (&
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
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.
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 cor
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
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 mem
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
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_b
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
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
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 '-fl
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.
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
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
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 w
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)
>
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.
++
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
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.
Compi
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::en
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. (Assum
: 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 mean
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 su
: 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;" : "
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
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
iority: 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 c
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
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
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
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).
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 happ
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
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
i
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
: 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/bugzi
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) ch
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 va
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
ty: 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;
templ
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
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.
++
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
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
&g
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")]]
v
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
: 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
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 po
49 matches
Mail list logo
