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
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
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
++
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
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
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 h
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
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
: 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 #9 from jwjagersma at gmail dot com ---
Created attachment 51840
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51840=edit
diagnostics
This patch adds checks for:
- Top-level AS-qualifiers on fields, local variables, funct
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=edit
basic implementation
Tentative patch.
Produces working code but could use some (many) che
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
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=edit
alternative patch v3
Alternative to last patch. Inserts the debug stmt across the fallthrough edge.
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
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
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 #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 #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
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 #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
--- 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 #1 from jwjagersma at gmail dot com ---
Created attachment 47936
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47936=edit
proposed patch
: 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=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.
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=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 #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 #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 #4 from jwjagersma at gmail dot com ---
Created attachment 44439
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44439=edit
Proposed patch
I cloned the fix that was applied to cygwin/mingw targets in SVN r259347. There
did
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.
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
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=edit
test case
Here is a reduced test case that causes a similar (likely the same?) ICE on
i686-w64-ming
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 v
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
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
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
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=edit
vbe.ii gzipped
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
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=edit
test case
Not sure if this is valid code, see attached source f
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
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
: 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=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
: 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=edit
test case
See included test case. The aligned_t variables are meant to be alig
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=edit
Test case 2
Generic test case, which doesn't require djgpp or a DOS machine. (Assuming
throwing f
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 =
try
{
std::cout << 1 / *p << std::endl;
}
catch (st
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=edit
Test case
I reduced my code to the bare minimum required to reproduce this issue.
Compile with dj
++
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
47 matches
Mail list logo
