Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629084.html
-- >8 --
This patch adds checks for attempting to change the active member of a
union by methods other than a member access expression.
To be able to properly distinguish `*(&u.a) = ` from `u.a = `, this
patch redoes t
On Wed, Aug 30, 2023 at 04:28:18PM -0400, Jason Merrill wrote:
> On 8/29/23 09:35, Nathaniel Shead wrote:
> > This is an attempt to improve the constexpr machinery's handling of
> > union lifetime by catching more cases that cause UB. Is this approach
> > OK?
> >
> > I'd also like some feedback on
This is an attempt to improve the constexpr machinery's handling of
union lifetime by catching more cases that cause UB. Is this approach
OK?
I'd also like some feedback on a couple of pain points with this
implementation; in particular, is there a good way to detect if a type
has a non-deleted t
Sorry, noticed I provided the wrong version of the test. Here is the
correct version (not relying on 'namespace std' being implicitly
defined). Bootstrapped + regtested on x86_64-pc-linux-gnu.
-- 8< --
This patch ensures that any errors raised by finish_id_expression when
parsing a decltype expre
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622681.html.
-- 8< --
This patch ensures that any errors raised by finish_id_expression when
parsing a decltype expression are properly reported, rather than
potentially going ignored and causing invalid code to be accepted.
We can als
This adds rudimentary lifetime tracking in C++ constexpr contexts,
allowing the compiler to report errors with using values after their
backing has gone out of scope. We don't yet handle other ways of
accessing values outside their lifetime (e.g. following explicit
destructor calls).
PR c+
Currently, when typeck discovers that a return statement will refer to a
local variable it rewrites to return a null pointer. This causes the
error messages for using the return value in a constant expression to be
unhelpful, especially for reference return values, and is also a visible
change to o
This patch updates 'input_location' during constant evaluation to ensure
that errors in subexpressions that lack location information still
provide accurate diagnostics.
By itself this change causes some small regressions in diagnostic
quality for circumstances where errors used 'input_location' b
This is an update of the patch series at
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625050.html
Changes since v4:
- Reordered patches to be more independent from each other (they don't need
to keep updating the new tests)
- Removed workaround for better locations in cxx_eval_store_exp
On Thu, Jul 20, 2023 at 10:42:29AM -0400, Jason Merrill wrote:
> On 7/20/23 05:35, Nathaniel Shead wrote:
> > This adds rudimentary lifetime tracking in C++ constexpr contexts,
> > allowing the compiler to report errors with using values after their
> > backing has gone out of scope. We don't yet h
On Fri, Jul 21, 2023 at 3:00 AM Jason Merrill wrote:
>
> On 7/20/23 05:37, Nathaniel Shead wrote:
> > This patch updates 'input_location' during constant evaluation to ensure
> > that errors in subexpressions that lack location information still
> > provide accurate diagnostics.
> >
> > By itself
On Fri, Jul 21, 2023 at 05:44:51PM -0400, Jason Merrill wrote:
> On 7/21/23 01:39, Nathaniel Shead wrote:
> > On Thu, Jul 20, 2023 at 11:46:47AM -0400, Jason Merrill wrote:
> > > On 7/20/23 05:36, Nathaniel Shead wrote:
> > > > Currently, when typeck discovers that a return statement will refer to
On Thu, Jul 20, 2023 at 11:46:47AM -0400, Jason Merrill wrote:
> On 7/20/23 05:36, Nathaniel Shead wrote:
> > Currently, when typeck discovers that a return statement will refer to a
> > local variable it rewrites to return a null pointer. This causes the
> > error messages for using the return val
This patch updates 'input_location' during constant evaluation to ensure
that errors in subexpressions that lack location information still
provide accurate diagnostics.
By itself this change causes some small regressions in diagnostic
quality for circumstances where errors used 'input_location' b
Currently, when typeck discovers that a return statement will refer to a
local variable it rewrites to return a null pointer. This causes the
error messages for using the return value in a constant expression to be
unhelpful, especially for reference return values.
This patch removes this "optimis
This adds rudimentary lifetime tracking in C++ constexpr contexts,
allowing the compiler to report errors with using values after their
backing has gone out of scope. We don't yet handle other ways of
accessing values outside their lifetime (e.g. following explicit
destructor calls).
PR c+
This is an update of the patch series at
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623375.html
Changes since v3:
- Use void_node in values map to indicate out-of-lifetime instead of a separate
hash set
- Remove tracking of temporaries for loops and calls
- Fix missed checks for uses o
On Fri, Jul 14, 2023 at 11:16:58AM -0400, Jason Merrill wrote:
> On 6/30/23 23:28, Nathaniel Shead via Gcc-patches wrote:
> > This adds rudimentary lifetime tracking in C++ constexpr contexts,
>
> Thanks!
>
> I'm not seeing either a copyright assignment or DCO certifica
This patch updates 'input_location' during constant evaluation to ensure
that errors in subexpressions that lack location information still
provide accurate diagnostics.
By itself this change causes some small regressions in diagnostic
quality for circumstances where errors used 'input_location' b
Currently, when typeck discovers that a return statement will refer to a
local variable it rewrites to return a null pointer. This causes the
error messages for using the return value in a constant expression to be
unhelpful, especially for reference return values.
This patch removes this "optimis
This adds rudimentary lifetime tracking in C++ constexpr contexts,
allowing the compiler to report errors with using values after their
backing has gone out of scope. We don't yet handle other ways of
accessing values outside their lifetime (e.g. following explicit
destructor calls).
PR c+
This is an update of the patch series at
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614811.html
Changes since v2:
- Use a separate 'hash_set' to track expired variables instead of
adding a flag to 'lang_decl_base'.
- Use 'iloc_sentinel' to propagate location information down to
sube
On Fri, Jun 23, 2023 at 01:09:14PM -0400, Patrick Palka wrote:
> On Wed, 29 Mar 2023, Nathaniel Shead via Gcc-patches wrote:
>
> > This patch caches the current expression's location information in the
> > constexpr_global_ctx struct, which allows subexpressions that
On Mon, Jun 26, 2023 at 03:37:32PM -0400, Patrick Palka wrote:
> On Sun, 25 Jun 2023, Nathaniel Shead wrote:
>
> > On Fri, Jun 23, 2023 at 12:43:21PM -0400, Patrick Palka wrote:
> > > On Wed, 29 Mar 2023, Nathaniel Shead via Gcc-patches wrote:
> > >
> >
On Thu, Jun 29, 2023 at 01:43:07PM -0400, Jason Merrill wrote:
> On 6/24/23 09:24, Nathaniel Shead wrote:
> > On Fri, Jun 23, 2023 at 11:59:51AM -0400, Patrick Palka wrote:
> > > Hi,
> > >
> > > On Sat, 22 Apr 2023, Nathaniel Shead via Gcc-patches wrote:
>
On Fri, Jun 23, 2023 at 12:43:21PM -0400, Patrick Palka wrote:
> On Wed, 29 Mar 2023, Nathaniel Shead via Gcc-patches wrote:
>
> > This adds rudimentary lifetime tracking in C++ constexpr contexts,
> > allowing the compiler to report errors with using values after their
> &
On Fri, Jun 23, 2023 at 12:15:32PM -0400, Patrick Palka wrote:
> On Sun, 30 Apr 2023, Nathaniel Shead via Gcc-patches wrote:
>
> > This patch ensures that any errors raised by finish_id_expression when
> > parsing a decltype expression are properly reported, rather than
>
On Fri, Jun 23, 2023 at 11:59:51AM -0400, Patrick Palka wrote:
> Hi,
>
> On Sat, 22 Apr 2023, Nathaniel Shead via Gcc-patches wrote:
>
> > Bootstrapped and tested on x86_64-pc-linux-gnu.
> >
> > -- 8< --
> >
> > This patch raises an error early whe
(Another) ping.
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616465.html
On Sat, Apr 22, 2023 at 04:25:13PM +1000, Nathaniel Shead wrote:
> Bootstrapped and tested on x86_64-pc-linux-gnu.
>
> -- 8< --
>
> This patch raises an error early when the decltype(auto) specifier is
> used as a
(Another) ping.
On Sun, Apr 30, 2023 at 12:00:05PM +1000, Nathaniel Shead wrote:
> This patch ensures that any errors raised by finish_id_expression when
> parsing a decltype expression are properly reported, rather than
> potentially going ignored and causing invalid code to be accepted.
>
> We
(Another) ping. I also have some more changes on top of this patch set
as well if this looks good as it is.
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614811.html
Thanks!
On Wed, Mar 29, 2023 at 01:32:55PM +1100, Nathaniel Shead wrote:
> This is an update of the patch series at
> https
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2023-April/617145.html
Also it looks like I forgot to mention, but this patch was bootstrapped
and regtested on x86_64-pc-linux-gnu.
On Sun, Apr 30, 2023 at 12:00:05PM +1000, Nathaniel Shead wrote:
> This patch ensures that any errors raised by fini
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616465.html
On Sat, Apr 22, 2023 at 04:25:13PM +1000, Nathaniel Shead wrote:
> Bootstrapped and tested on x86_64-pc-linux-gnu.
>
> -- 8< --
>
> This patch raises an error early when the decltype(auto) specifier is
> used as a parameter o
On Wed, May 17, 2023 at 10:05:59AM +0100, Jonathan Wakely wrote:
> On Wed, 17 May 2023 at 09:37, Nathaniel Shead wrote:
>
> > Now that GCC13.1 is released is it ok to merge? Thanks!
> >
>
> Yes, I've been testing this locally, but I think it needs more work (sorry!)
>
> Looking at it again, I'm
Now that GCC13.1 is released is it ok to merge? Thanks!
On Tue, Apr 18, 2023 at 6:48 PM Jonathan Wakely wrote:
>
> On Mon, 17 Apr 2023 at 09:11, Nathaniel Shead
> wrote:
> >
> > Hi, just checking whether there were any issues with this patch?
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-F
Just pinging in case this fix has fallen through the cracks.
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614811.html
On Wed, Mar 29, 2023 at 1:33 PM Nathaniel Shead
wrote:
>
> This is an update of the patch series at
> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614759.html
>
>
This patch ensures that any errors raised by finish_id_expression when
parsing a decltype expression are properly reported, rather than
potentially going ignored and causing invalid code to be accepted.
We can also now remove the separate check for templates without args as
this is also checked fo
Bootstrapped and tested on x86_64-pc-linux-gnu.
-- 8< --
This patch raises an error early when the decltype(auto) specifier is
used as a parameter of a function. This prevents any issues with an
unexpected tree type later on when performing the call.
PR 103497
gcc/cp/ChangeLog:
Hi, just checking whether there were any issues with this patch?
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612386.html
Otherwise I assume it won't be in GCC13.
Thanks,
Nathaniel
This patch caches the current expression's location information in the
constexpr_global_ctx struct, which allows subexpressions that have lost
location information to still provide accurate diagnostics. Also
rewrites a number of 'error' calls as 'error_at' to provide more
specific location informat
This adds rudimentary lifetime tracking in C++ constexpr contexts,
allowing the compiler to report errors with using values after their
backing has gone out of scope. We don't yet handle other ways of ending
lifetimes (e.g. explicit destructor calls).
PR c++/96630
PR c++/98675
This is an update of the patch series at
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614759.html
The main change is modifying the first patch to store the "expired" flag
in the C++-specific lang_decl_base struct instead of tree_decl_common.
The second and third patches to improve diagnost
Currently, when typeck discovers that a return statement will refer to a
local variable it rewrites to return a null pointer. This causes the
error messages for using the return value in a constant expression to be
unhelpful, especially for reference return values.
This patch removes this "optimis
On Tue, Mar 28, 2023 at 10:50 PM Jakub Jelinek wrote:
>
> On Tue, Mar 28, 2023 at 10:32:28PM +1100, Nathaniel Shead via Gcc-patches
> wrote:
> > * tree-core.h (struct tree_decl_common): New flag to check if
> > value lifetime has expired.
> > * tr
Currently, when typeck discovers that a return statement will refer to a
local variable it rewrites to return a null pointer. This causes the
error messages for using the return value in a constant expression to be
unhelpful, especially for reference return values.
This patch removes this "optimis
This adds rudimentary lifetime tracking in C++ constexpr contexts,
allowing the compiler to report errors with using values after their
backing has gone out of scope. We don't yet handle other ways of ending
lifetimes (e.g. explicit destructor calls).
PR c++/70331
PR c++/96630
This patch caches the current expression's location information in the
constexpr_global_ctx struct, which allows subexpressions that have lost
location information to still provide accurate diagnostics. Also
rewrites a number of 'error' calls as 'error_at' to provide more
specific location informa
The first patch fixes PR70331, PR96630, and PR98675 regarding
constexpr evaluation not correctly diagnosing uses of dangling
references and pointers. The following two patches clean up and improve
some of the errors that are generated by this change, but aren't
strictly necessary.
This is my first
On Sat, Mar 18, 2023 at 7:36 AM Jonathan Wakely via Libstdc++
wrote:
>
> Tested x86_64-linux. Pushed to trunk. gcc-12 backport needed too.
>
> -- >8 --
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/109165
> * include/std/coroutine (hash<>::operator()): Add const.
> * testsui
On Mon, Feb 20, 2023 at 12:08:38PM +, Jonathan Wakely wrote:
> On Mon, 20 Feb 2023 at 11:57, Nathaniel Shead
> wrote:
> >
> > On Mon, Feb 20, 2023 at 10:30 PM Jonathan Wakely wrote:
> > >
> > > On Mon, 20 Feb 2023 at 11:23, Nathaniel Shead via Libstdc++
> > > wrote:
> > > >
> > > > The comm
On Mon, Feb 20, 2023 at 10:30 PM Jonathan Wakely wrote:
>
> On Mon, 20 Feb 2023 at 11:23, Nathaniel Shead via Libstdc++
> wrote:
> >
> > The comments on PR79700 mentioned that it was somewhat ambiguous whether
> > these functions were supposed to exist for C++11 or not. I chose to add
> > them th
The comments on PR79700 mentioned that it was somewhat ambiguous whether
these functions were supposed to exist for C++11 or not. I chose to add
them there, since other resources (such as cppreference) seem to think
that C++11 should be the standard these functions were introduced, and I
don't know
These two patches implement P1413 (deprecate std::aligned_storage and
std::aligned_union) for C++23. Tested on x86_64-linux.
-- >8 --
Adds deprecated attributes for C++23, and makes use of it for
std::aligned_storage, std::aligned_storage_t, std::aligned_union, and
std::aligned_union_t.
libstdc+
These two patches implement P1413 (deprecate std::aligned_storage and
std::aligned_union) for C++23. Tested on x86_64-linux.
-- >8 --
Updates _GLIBCXX20_DEPRECATED to be defined and behave the same as the
versions for other standards (e.g. _GLIBCXX17_DEPRECATED).
libstdc++-v3/ChangeLog:
Thanks for that. I'll keep your comments in mind for the future.
On Fri, Nov 11, 2022 at 05:59:33PM +, Jonathan Wakely wrote:
> On Fri, 11 Nov 2022 at 17:55, Patrick Palka wrote:
> >
> > On Fri, 11 Nov 2022, Jonathan Wakely via Libstdc++ wrote:
> >
> > > On Fri, 11 Nov 2022 at 11:23, Nathanie
Hi,
Below is a patch to fix std::string in constexpr contexts on Clang. This
was originally fixed in the commits attached to PR103295, but a later
commit 98a0d72a seems to have mistakenly undone this.
Tested on x86_64-linux. Verified using clang-14 and clang-15 that the
fix works. I haven't added
56 matches
Mail list logo
