https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111536
Bug ID: 111536
Summary: -fanalyzer false positive with NRVO return
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537
Bug ID: 111537
Summary: ICE: in set_cell_span, at text-art/table.cc:148 with D
front-end and -fanalyzer
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111650
--- Comment #1 from Iain Buclaw ---
Reduced a bit more.
---
module object;
ref V require(K, V)(ref V[K] aa, K key, lazy V value);
struct Root
{
ulong[3] f;
}
Root[ulong] roots;
Root getRoot(int fd, ulong rootID)
{
return roots.requi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115295
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gdcproject dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116373
Iain Buclaw changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537
--- Comment #2 from Iain Buclaw ---
(In reply to David Malcolm from comment #1)
> Am trying to reproduce locally, but when I run this in my BUILDDIR/gcc:
> ./gdc -B. -S -fanalyzer oob.d
> I get:
> d21: error: cannot find source code for run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537
--- Comment #7 from Iain Buclaw ---
(In reply to David Malcolm from comment #5)
> Is D correctly building that string_cst? Are D strings 0-terminated?
Yes, D strings are 0-terminated.
The way I've done it is, the string is constructed using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537
--- Comment #8 from Iain Buclaw ---
Looking at C++ FE, I see they construct the string literal using
build_string (4, "foo")
because I can see the terminating 0 in the pretty-printed string.
---
unit-size
align:8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537
--- Comment #9 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #8)
> I see in the olden days when D sat outside of GCC, this is what was done too.
>
> https://github.com/D-Programming-GDC/gdc/commit/
> b9d36fc9d71ec4122d1c986599d87c6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96347
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110712
Bug ID: 110712
Summary: d: ICE: verify_gimple_failed (conversion of register
to a different size in 'view_convert_expr')
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110712
--- Comment #2 from Iain Buclaw ---
(In reply to Richard Biener from comment #1)
> this_2(D)->ap = VIEW_CONVERT_EXPR(ap_3(D));
>
> it looks odd since ap_3(D) is a is_gimple_reg but a struct[1] definitely
> would not. Maybe you are missing a de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110712
--- Comment #3 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #2)
> I think some extra errors during the D front-end codegen pass are likely the
> most appropriate thing to do here, as you say, such things are rejected by
> C/C++, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104739
--- Comment #6 from Iain Buclaw ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #5)
> > --- Comment #4 from Rainer Orth ---
> > I wonder how to handle this: while DejaGnu has an ucn effective-target
> > keyword,
> > the gdc.test te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113758
Bug ID: 113758
Summary: d: Callee destructor call invalidates the live object,
not the temporary
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #1 from Iain Buclaw ---
Isn't __atomic_is_lock_free tied to the __GCC_ATOMIC_XXX_T_LOCK_FREE macros?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #2 from Iain Buclaw ---
(In reply to Iain Sandoe from comment #0)
> I am now seeing this on both Darwin and Linux BE powerpc.
>
> The message is somewhat odd, since AFAICS from the core druntime code that
> pulls in builtins.def whi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #4 from Iain Buclaw ---
Looking at gcc/builtins.cc, I have a bad feeling that the only compile-time
values one can get out of this built-in are "true" and "defer to run-time"
---
/* Return a one or zero if it can be determined that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #7 from Iain Buclaw ---
(In reply to Iain Sandoe from comment #6)
> (In reply to Iain Buclaw from comment #4)
> > Looking at gcc/builtins.cc, I have a bad feeling that the only compile-time
>
>
> > /* If it isn't always lock free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #8 from Iain Buclaw ---
Created attachment 57329
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57329&action=edit
The quick fix to the lock-free test
The immediate thing that can be changed is turning the test into a
`__traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #9 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #8)
> Created attachment 57329 [details]
> The quick fix to the lock-free test
>
> The immediate thing that can be changed is turning the test into a
> `__traits(compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #11 from Iain Buclaw ---
(In reply to Iain Sandoe from comment #10)
> (In reply to Iain Buclaw from comment #8)
> > Created attachment 57329 [details]
> > The quick fix to the lock-free test
> >
> > The immediate thing that can be c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117002
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gdcproject dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117115
--- Comment #4 from Iain Buclaw ---
Upstream fix.
https://github.com/dlang/dmd/pull/17004
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117115
--- Comment #3 from Iain Buclaw ---
Introduced upstream by:
https://github.com/dlang/dmd/pull/15664
Before:
---
enum `object.Foo` enum `Foo` must have at least one member
---
After:
---
enum `object.Foo enum `Foo` must have at least one memb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117115
--- Comment #2 from Iain Buclaw ---
The assert hit is:
gcc_assert (!inbacktick);
One of the DMD front-end errors likely has an odd number of backticks in the
format string.
301 - 327 of 327 matches
Mail list logo
