On May 24, 2022, Martin Liška wrote:
> Allways install limits.h and syslimits.h header files
> to include folder.
typo: s/Allways/Always/
I'm a little worried about this bit, too. limitx.h includes
"syslimits.h", mentioning it should be in the same directory. Perhaps
it could be left in
Jiufu Guo via Gcc-patches writes:
Hi,
This patch is based on:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594252.html.
Compare with previous patch, this patch refined the comment and
rename one function, and support case: "*p == 0xc001".
When checking eq/neq with a constant
On Wed, May 25, 2022 at 11:39 AM liuhongt via Gcc-patches
wrote:
>
> Rigt now, mem_cost for separate mem alternative is 1 * frequency which
> is pretty small and caused the unnecessary SSE spill in the PR, I've tried
> to rework backend cost model, but RA still not happy with that(regress
>
Here is the patch to fix just what is described in PR 105714.
libstdc++: [_Hashtable] Insert range of types convertible to
value_type PR 105714
Fix insertion of range of types convertible to value_type.
libstdc++-v3/ChangeLog:
PR libstdc++/105714
*
Rigt now, mem_cost for separate mem alternative is 1 * frequency which
is pretty small and caused the unnecessary SSE spill in the PR, I've tried
to rework backend cost model, but RA still not happy with that(regress
somewhere else). I think the root cause of this is cost for separate 'm'
On Mon, May 23, 2022 at 3:32 PM David Malcolm via Gcc-patches
wrote:
>
> With C++11 we can add "final" and "override" to the decls of vfuncs
> in derived classes, which documents to both human and automated readers
> of the code that a decl is intended to override a vfunc in a base class,
> and
Hello,
two weeks ago I submitted the second version of the patch PR105387 for the bug
105387. Now I added a pointer-to-member exception test just to make sure that
it doesn't break in case RTTI is enabled. The test is disabled if RTTI is
disabled. I didn't receive any feedback so far regarding
On Tue, 24 May 2022 18:36:27 PDT (-0700), Vineet Gupta wrote:
On 5/24/22 18:32, Palmer Dabbelt wrote:
Ping, IMO this needs to be (re)considered for trunk.
This goes really nicely with riscv_slow_unaligned_access_p==false, to
elide the unrolled tail copies for trailer word/sword/byte
On 5/24/22 18:32, Palmer Dabbelt wrote:
Ping, IMO this needs to be (re)considered for trunk.
This goes really nicely with riscv_slow_unaligned_access_p==false, to
elide the unrolled tail copies for trailer word/sword/byte accesses.
@Kito, @Palmer ? Just from codegen pov this seems to be a
On Tue, 24 May 2022 17:55:24 PDT (-0700), Vineet Gupta wrote:
On 7/22/21 15:41, Christoph Muellner via Gcc-patches wrote:
This patch enables the overlap-by-pieces feature of the by-pieces
infrastructure for inlining builtins in case the target has set
riscv_slow_unaligned_access_p to false.
On 7/22/21 15:41, Christoph Muellner via Gcc-patches wrote:
This patch enables the overlap-by-pieces feature of the by-pieces
infrastructure for inlining builtins in case the target has set
riscv_slow_unaligned_access_p to false.
An example to demonstrate the effect for targets with fast
On Tue, May 24, 2022 at 3:57 PM Philipp Tomsich
wrote:
>
> The SINGLE_BIT_MASK_OPERAND() is overly restrictive, triggering for
> bits above 31 only (to side-step any issues with the negative SImode
> value 0x8000). This moves the special handling of this SImode
> value (i.e. the check for
The SINGLE_BIT_MASK_OPERAND() is overly restrictive, triggering for
bits above 31 only (to side-step any issues with the negative SImode
value 0x8000). This moves the special handling of this SImode
value (i.e. the check for -2147483648) to riscv.cc and relaxes the
SINGLE_BIT_MASK_OPERAND()
We avoid reassociating "(~(a >> BIT_NO)) & 1" into "((~a) >> BIT_NO) & 1"
by splitting it into a zero-extraction (bext) and an xori. This both
avoids burning a register on a temporary and generates a sequence that
clearly captures 'extract bit, then invert bit'.
This change improves the
For a straightforward application of bext for the following function
long bext64(long a, char bitno)
{
return (a & (1UL << bitno)) ? 0 : -1;
}
we generate
srl a0,a0,a1# 7 [c=4 l=4] lshrdi3
andia0,a0,1 # 8 [c=4 l=4]
Consider creating a polarity-reversed mask from a set-bit (i.e., if
the bit is set, produce all-ones; otherwise: all-zeros). Using Zbb,
this can be expressed as bexti, followed by an addi of minus-one. To
enable the combiner to discover this opportunity, we need to split the
canonical expression
On Tue, May 24, 2022 at 06:11:09PM +, Joseph Myers wrote:
> On Tue, 24 May 2022, Marek Polacek via Gcc-patches wrote:
>
> > I thought it'd be nice to have a table that documents our C support
> > status, like we have https://gcc.gnu.org/projects/cxx-status.html for C++.
> > We have
The current method of treating shifts of extended values on RISC-V
frequently causes sequences of 3 shifts, despite the presence of the
'zero_extendsidi2_shifted' pattern.
Consider:
unsigned long f(unsigned int a, unsigned long b)
{
a = a << 1;
unsigned long c =
When encountering a prescaled (biased) value as a candidate for
sh[123]add.uw, the combine pass will present this as shifted by the
aggregate amount (prescale + shift-amount) with an appropriately
adjusted mask constant that has fewer than 32 bits set.
E.g., here's the failing expression seen in
Provide an easy way to constrain for constants that are a a single,
consecutive run of ones.
gcc/ChangeLog:
* config/riscv/predicates.md (consecutive_bits_operand):
Implement new predicate.
Signed-off-by: Philipp Tomsich
---
gcc/config/riscv/predicates.md | 11 +++
Code-generation currently misses some opportunities for optimized
sequences when zero-extension is combined with shifts.
Philipp Tomsich (3):
RISC-V: add consecutive_bits_operand predicate
RISC-V: Split slli+sh[123]add.uw opportunities to avoid zext.w
RISC-V: Replace
Hello-
Now that we're back in stage 1, I thought it might be a better time to
ask for feedback on this pair of patches that tries to resolve PR53431
please?
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587357.html
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587358.html
On Linux/x86_64,
4fb2b4f7ea6b80ae75d3efb6f86e7c6179080535 is the first bad commit
commit 4fb2b4f7ea6b80ae75d3efb6f86e7c6179080535
Author: Tobias Burnus
Date: Tue May 24 10:41:43 2022 +0200
OpenMP: Support nowait with Fortran [PR105378]
caused
FAIL:
On 24/05/22 12:18, Jonathan Wakely wrote:
On Thu, 5 May 2022 at 18:38, François Dumont via Libstdc++
wrote:
Hi
Renewing my patch to fix PR 56112 but for the insert methods, I totally
change it, now works also with move-only key types.
I let you Jonathan find a better name than
On Tue, May 24, 2022 at 04:01:37PM -0400, Jason Merrill wrote:
> On 5/24/22 09:55, Marek Polacek wrote:
> > On Tue, May 24, 2022 at 08:36:39AM -0400, Jason Merrill wrote:
> > > On 5/16/22 11:36, Marek Polacek wrote:
> > > > +static tree
> > > > +replace_placeholders_for_class_temp_r (tree *tp, int
On Mon, May 23, 2022 at 11:42 PM Richard Biener
wrote:
>
> On Mon, May 23, 2022 at 8:34 PM H.J. Lu wrote:
> >
> > On Mon, May 23, 2022 at 12:38:06PM +0200, Richard Biener wrote:
> > > On Sat, May 21, 2022 at 5:02 AM H.J. Lu via Gcc-patches
> > > wrote:
> > > >
> > > > When recording store for
In constexpr-new3.C, the f7 function returns a deleted pointer, which we
were happily caching because the new and delete are balanced. Don't.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_call_expression): Check for
heap vars in the
A change I was working on made constexpr_searcher.cc start to fail, and when
I looked at it I wondered why it had been accepted before. This turned out
to be because we try to be more flexible about constant-evaluation of static
initializers, as allowed, but we were wrongly doing the same for
On 5/24/22 09:55, Marek Polacek wrote:
On Tue, May 24, 2022 at 08:36:39AM -0400, Jason Merrill wrote:
On 5/16/22 11:36, Marek Polacek wrote:
+static tree
+replace_placeholders_for_class_temp_r (tree *tp, int *, void *data)
+{
+ tree t = *tp;
+ tree full_expr = *static_cast(data);
+
+ /*
> >> gcc/testsuite/ChangeLog:
> >>
> >> * gcc.misc-tests/outputs.exp: Make the -gsplit-dwarf test
> >> a compile-and-link test rather than a compile-only test.
>
> OK, thanks.
Thank you Richard. Pushed to master.
--
Joel
The code in cxx_eval_call_expression to fold *this was doing the wrong thing
for array decay; we can use cxx_fold_indirect_ref instead.
This didn't end up being necessary to fix anything, but still seems like an
improvement.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
I've been thinking for a while that the 'lval' parameter needed a third
value for discarded-value expressions; most importantly,
cxx_eval_store_expression does extra work for an lvalue result, and we also
don't want to do the l->r conversion.
Mostly this is pretty mechanical. Apart from the
On Tue, 24 May 2022, Marek Polacek via Gcc-patches wrote:
> +
This actually looks like a mix of papers approved at the Oct 2020 meeting
and those approved at the Nov/Dec 2020 meeting, though I haven't checked
the lists in detail against those the minutes show as being approved as-is
or
Here calling the constructor for s.__size_ had ctx->ctor for s itself
because cxx_eval_store_expression doesn't create a ctor for the empty field.
Then cxx_eval_call_expression returned the s initializer, and my empty base
overhaul in r13-160 got confused because the type of init is not an empty
On 5/24/22 00:59, Kito Cheng wrote:
Committed, thanks!
Thx for the quick action Kito,
Can this be backported to gcc 12 as well ?
Thx,
-Vineet
On Tue, May 24, 2022 at 3:40 AM Philipp Tomsich
wrote:
Good catch!
On Mon, 23 May 2022 at 20:12, Vineet Gupta wrote:
Under extreme register
On Tue, 24 May 2022 at 14:50, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
> > index c5006afc00d..0a3c733ada9 100644
> > --- a/gcc/doc/tm.texi
> > +++ b/gcc/doc/tm.texi
> > @@ -6088,14 +6088,18 @@ for the given scalar type
On 5/24/22 16:33, Gerald Pfeifer wrote:
> Hi Martin,
>
> On Tue, 24 May 2022, Martin Liška wrote:
>> +AddressSanitizer defaults to
>> detect_stack_use_after_return=1 on Linux target.
>
> did you mean targets, or really just target?
>
> (And Linux or GNU/Linux, though that one is more
On Tue, 24 May 2022, Marek Polacek via Gcc-patches wrote:
> I thought it'd be nice to have a table that documents our C support
> status, like we have https://gcc.gnu.org/projects/cxx-status.html for C++.
> We have https://gcc.gnu.org/c99status.html, but that's C99 only.
>
> So here's a patch to
I thought it'd be nice to have a table that documents our C support
status, like we have https://gcc.gnu.org/projects/cxx-status.html for C++.
We have https://gcc.gnu.org/c99status.html, but that's C99 only.
So here's a patch to add just that. For C99, I used c99status.html but
added paper
This patch adds entries for the c++tools, gotools, libbacktrace,
libcc1, libcody, liboffloadmic, and libsanitizer directories into the
list of toplevel source directories in sourcebuild.texi. I also
removed the entry for boehm-gc (which is no longer in-tree), and fixed
the alphabetization for
On 24.05.22 18:44, Tobias Burnus wrote:
On 24.05.22 17:31, Andrew Stubbs wrote:
amdgcn: Add gfx90a support
Attached is an attempt to update invoke.texi
And to update the gcc-13/changes.html. Regarding the latter, I have to
versions – the first is more readable, the latter makes more clear
On 5/24/22 09:03, Yonghong Song wrote:
>
>
> On 5/24/22 8:53 AM, David Faust wrote:
>>
>>
>> On 5/24/22 04:07, Jose E. Marchesi wrote:
>>>
On 5/11/22 11:44 AM, David Faust wrote:
>
> On 5/10/22 22:05, Yonghong Song wrote:
>>
>>
>> On 5/10/22 8:43 PM, Yonghong Song
Increase the priority of the init_have_lse_atomics constructor so it runs
before other constructors. This improves chances that rr works when LSE
atomics are supported.
Regress and bootstrap pass, OK for commit?
2022-05-24 Wilco Dijkstra
libgcc/
PR libgcc/105708
*
On 24.05.22 17:31, Andrew Stubbs wrote:
amdgcn: Add gfx90a support
Attached is an attempt to update invoke.texi
And to update the gcc-13/changes.html. Regarding the latter, I have to
versions – the first is more readable, the latter makes more clear where
to use it, but reads much worse. –
The 05/13/2022 16:35, Richard Sandiford wrote:
> Szabolcs Nagy via Gcc-patches writes:
> > The RA_SIGN_STATE dwarf pseudo-register is normally only set using the
> > DW_CFA_AARCH64_negate_ra_state (== DW_CFA_window_save) operation which
> > toggles the return address signedness state (the default
On 5/24/22 8:53 AM, David Faust wrote:
On 5/24/22 04:07, Jose E. Marchesi wrote:
On 5/11/22 11:44 AM, David Faust wrote:
On 5/10/22 22:05, Yonghong Song wrote:
On 5/10/22 8:43 PM, Yonghong Song wrote:
On 5/6/22 2:18 PM, David Faust wrote:
On 5/5/22 16:00, Yonghong Song wrote:
Pushed to both gcc11 and gcc12.
thanks.
Qing
> On May 24, 2022, at 1:19 AM, Richard Biener wrote:
>
> On Mon, 23 May 2022, Qing Zhao wrote:
>
>> Hi,
>>
>> I have added the patch to GCC11 and GCC12 in my local area and bootstrapped
>> and regress tested on both x86 and aarch64, no any
On 5/24/22 04:07, Jose E. Marchesi wrote:
>
>> On 5/11/22 11:44 AM, David Faust wrote:
>>>
>>> On 5/10/22 22:05, Yonghong Song wrote:
On 5/10/22 8:43 PM, Yonghong Song wrote:
>
>
> On 5/6/22 2:18 PM, David Faust wrote:
>>
>>
>> On 5/5/22 16:00, Yonghong
On 5/24/22 4:07 AM, Jose E. Marchesi wrote:
On 5/11/22 11:44 AM, David Faust wrote:
On 5/10/22 22:05, Yonghong Song wrote:
On 5/10/22 8:43 PM, Yonghong Song wrote:
On 5/6/22 2:18 PM, David Faust wrote:
On 5/5/22 16:00, Yonghong Song wrote:
On 5/4/22 10:03 AM, David Faust
Richard Biener writes:
> On Sat, May 21, 2022 at 3:11 AM Gaius Mulley wrote:
>>
>>
>> Hi,
>>
>> Gaius wrote:
>>
>> > the changes do raise questions. The reason for the changes here are to
>> > allow easy linking for modula-2 users.
>>
>> > $ gm2 hello.mod
>>
>> > for example will compile and
I've committed this patch to add support for gfx90a AMD GPU devices.
The patch updates all the places that have architecture/ISA specific
code, tidies up the ISA naming and handling in the backend, and adds a
new multilib.
This is just lightly tested at this point, but there are no known
I've committed this patch to set the minimum required LLVM version, for
the assembler and linker, to 13.0.1. An upgrade from LLVM 9 is a
prerequisite for the gfx90a support, and 13.0.1 is now the oldest
version not known to have compatibility issues.
The patch removes all the obsolete feature
Excerpts from David Malcolm's message of Mai 24, 2022 3:15 pm:
> On Tue, 2022-05-24 at 14:56 +0200, Iain Buclaw wrote:
>> Excerpts from David Malcolm via Gcc-patches's message of Mai 23, 2022
>> 9:28 pm:
>> > gcc/d/ChangeLog:
>> > * decl.cc: Add "final" and "override" to all "visit" vfunc
On Thu, Mar 24, 2022 at 9:27 AM David Seifert via Gcc-patches
wrote:
>
> On Mon, 2022-03-14 at 18:38 +0100, David Seifert wrote:
> > Use AC_CACHE_CHECK to store the result of the header check for
> > systemtap's "sys/sdt.h", which is similar in spirit to libstdc++'s
> > AC_CACHE_CHECK(...,
On Fri, Mar 18, 2022 at 09:26:50AM -0700, Julian Brown wrote:
> This patch implements OpenMP 5.0 "declare mapper" support for C++ --
> except for arrays of structs with mappers, which are TBD. I've taken cues
> from the existing "declare reduction" support where appropriate, though
> obviously the
On Mon, Mar 14, 2022 at 10:13 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Mon, Mar 14, 2022 at 09:26:57AM -0400, Marek Polacek via Gcc-patches wrote:
> > Thanks for the patch.
> >
> > The new configure option needs documenting in doc/install.texi, and
> > configure
> > needs to be
Hi Martin,
On Tue, 24 May 2022, Martin Liška wrote:
> +AddressSanitizer defaults to
> detect_stack_use_after_return=1 on Linux target.
did you mean targets, or really just target?
(And Linux or GNU/Linux, though that one is more disputed, I know.
Just following our own coding
On Fri, Mar 18, 2022 at 09:26:49AM -0700, Julian Brown wrote:
> This patch changes the representation of OMP array sections in the
> C++ front end to use the new OMP_ARRAY_SECTION tree code instead of a
> TREE_LIST. This is important for "declare mapper" support, because the
> array section
On Tue, May 24, 2022 at 8:42 AM Martin Liška wrote:
>
> Ready to be installed?
>
> Thanks,
> Martin
>
> ---
> htdocs/gcc-13/changes.html | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
> index 6c5b2a37..f7f6866d 100644
> ---
On Fri, Mar 18, 2022 at 09:26:47AM -0700, Julian Brown wrote:
> --- a/gcc/cp/parser.cc
> +++ b/gcc/cp/parser.cc
> @@ -4266,6 +4266,9 @@ cp_parser_new (cp_lexer *lexer)
>parser->omp_declare_simd = NULL;
>parser->oacc_routine = NULL;
>
> + /* Allow array slice in expression. */
Better
On Tue, May 24, 2022 at 4:10 PM David Malcolm wrote:
>
> On Tue, 2022-05-24 at 17:09 +0930, Alan Modra wrote:
> > On Mon, May 23, 2022 at 07:42:29PM -0400, David Malcolm via Binutils
> > wrote:
> > > Any objections, or is there a reason to keep these macros that I'm
> > > not aware of? (and did
On Tue, 2022-05-24 at 17:09 +0930, Alan Modra wrote:
> On Mon, May 23, 2022 at 07:42:29PM -0400, David Malcolm via Binutils
> wrote:
> > Any objections, or is there a reason to keep these macros that I'm
> > not aware of? (and did I send this to all the pertinent lists?)
>
> No objection from
On Tue, 2022-05-24 at 09:57 -0400, David Malcolm wrote:
> On Tue, 2022-05-24 at 09:25 +0200, Jakub Jelinek via Gcc-patches
> wrote:
> > Hi!
> >
> > On the following testcase (the first dg-error line) we emit a weird
> > diagnostics and even fixit on pointerpointer->member
> > where pointerpointer
On Tue, 2022-05-24 at 09:25 +0200, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> On the following testcase (the first dg-error line) we emit a weird
> diagnostics and even fixit on pointerpointer->member
> where pointerpointer is pointer to pointer to struct and we say
> 'pointerpointer' is a
On Tue, May 24, 2022 at 08:36:39AM -0400, Jason Merrill wrote:
> On 5/16/22 11:36, Marek Polacek wrote:
> > +static tree
> > +replace_placeholders_for_class_temp_r (tree *tp, int *, void *data)
> > +{
> > + tree t = *tp;
> > + tree full_expr = *static_cast(data);
> > +
> > + /* We're looking
"For every pessimization, there's an equal and opposite optimization".
In the review of my original patch for PR middle-end/98865, Richard
Biener pointed out that match.pd shouldn't be transforming X*Y into
X&-Y as the former is considered cheaper by tree-ssa's cost model
(operator count). A
On Tue, May 24, 2022 at 09:25:57AM +0200, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase (the first dg-error line) we emit a weird
> diagnostics and even fixit on pointerpointer->member
> where pointerpointer is pointer to pointer to struct and we say
> 'pointerpointer' is a pointer;
On Fri, Mar 18, 2022 at 09:26:46AM -0700, Julian Brown wrote:
> This patch relates to OpenMP mapping clauses containing struct members of
> reference type, e.g. "mystruct.myref.myptr[:N]". To be able to access
> the array slice through the reference in the middle, we need to perform
> an attach
On Fri, Mar 18, 2022 at 09:24:54AM -0700, Julian Brown wrote:
> 2022-03-17 Julian Brown
>
> gcc/c-family/
> * c-common.h (c_omp_address_inspector): New class.
> * c-omp.c (c_omp_address_inspector::get_deref_origin,
> c_omp_address_inspector::component_access_p,
>
On Fri, Mar 18, 2022 at 09:24:53AM -0700, Julian Brown wrote:
> 2022-03-17 Julian Brown
>
> gcc/fortran/
> * trans-openmp.cc (gfc_trans_omp_clauses): Don't create
> GOMP_MAP_TO_PSET mappings for class metadata, nor GOMP_MAP_POINTER
> mappings for POINTER_TYPE_P decls.
>
On Tue, 2022-05-24 at 14:56 +0200, Iain Buclaw wrote:
> Excerpts from David Malcolm via Gcc-patches's message of Mai 23, 2022
> 9:28 pm:
> > gcc/d/ChangeLog:
> > * decl.cc: Add "final" and "override" to all "visit" vfunc
> > decls
> > as appropriate.
> > * expr.cc:
On Fri, Mar 18, 2022 at 09:24:52AM -0700, Julian Brown wrote:
> This patch has been split out from the previous one to avoid a
> confusingly-interleaved diff. The two patches should probably be
> committed squashed together.
Agreed, LGTM.
>
> 2021-10-01 Julian Brown
>
> gcc/
> *
On Fri, Mar 18, 2022 at 09:24:51AM -0700, Julian Brown wrote:
> 2021-11-23 Julian Brown
>
> gcc/
> * gimplify.c (is_or_contains_p, omp_target_reorder_clauses): Delete
> functions.
> (omp_tsort_mark): Add enum.
> (omp_mapping_group): Add struct.
>
Committed with a few minor style fixes, thanks!
On Tue, May 10, 2022 at 11:26 AM wrote:
>
> From: yulong
>
> This patchset adds support for three recently ratified RISC-V extensions:
>
> - Zicbom (Cache-Block Management Instructions)
> - Zicbop (Cache-Block Prefetch hint instructions)
> -
Excerpts from David Malcolm via Gcc-patches's message of Mai 23, 2022 9:28 pm:
> gcc/d/ChangeLog:
> * decl.cc: Add "final" and "override" to all "visit" vfunc decls
> as appropriate.
> * expr.cc: Likewise.
> * toir.cc: Likewise.
> * typeinfo.cc: Likewise.
> *
On Tue, May 24, 2022 at 05:29:56PM +0530, Prathamesh Kulkarni wrote:
> On Fri, 29 Apr 2022 at 19:44, Marek Polacek via Gcc-patches
> wrote:
> >
> > This patch fixes crashes with invalid attributes. Arguably it could
> > make sense to assert seen_error() too.
> >
> > Bootstrapped/regtested on
Ready to be installed?
Thanks,
Martin
---
htdocs/gcc-13/changes.html | 3 +++
1 file changed, 3 insertions(+)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 6c5b2a37..f7f6866d 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -47,6 +47,9 @@
On 5/16/22 11:36, Marek Polacek wrote:
On Sat, May 14, 2022 at 11:13:28PM -0400, Jason Merrill wrote:
On 5/13/22 19:41, Marek Polacek wrote:
--- a/gcc/cp/typeck2.cc
+++ b/gcc/cp/typeck2.cc
@@ -1371,6 +1371,70 @@ digest_init_flags (tree type, tree init, int flags,
tsubst_flags_t complain)
On 4/29/22 10:12, Marek Polacek wrote:
This patch fixes crashes with invalid attributes. Arguably it could
make sense to assert seen_error() too.
So in this testcase we have TREE_CHAIN of a TREE_LIST pointing to
error_mark_node? Can we avoid that?
Bootstrapped/regtested on
On 5/23/22 16:25, Patrick Palka wrote:
On 5/18/22, Jason Merrill wrote:
On 5/16/22 15:58, Patrick Palka wrote:
When processing a class template specialization, lookup_template_class
uses structural equality for the specialized type whenever one of its
template arguments uses structural
Pushed to wwwdocs.
commit f55f35c86c68143a2b148c66e4b0b560c852ce6f
Author: Jonathan Wakely
Date: Tue May 24 13:06:11 2022 +0100
Document changes in libstdc++
diff --git a/htdocs/gcc-13/porting_to.html b/htdocs/gcc-13/porting_to.html
index b3e0895a..84a00f21 100644
---
On 5/9/22 11:02, Martin Liška wrote:
> |Ready to be installed?|
This patch should be replaced with:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595495.html
Martin
On 5/20/22 14:42, Alexandre Oliva wrote:
> On May 11, 2022, Martin Liška wrote:
>
>> Ready to be installed?
>
> Hmm... I don't like that --disable-fixincludes would still configure,
> build and even install fixincludes. This would be surprising, given
> that the semantics of disabling a
And link it from changes.html.
---
htdocs/gcc-13/changes.html| 2 --
htdocs/gcc-13/porting_to.html | 28
2 files changed, 28 insertions(+), 2 deletions(-)
create mode 100644 htdocs/gcc-13/porting_to.html
diff --git a/htdocs/gcc-13/changes.html
On Fri, 29 Apr 2022 at 19:44, Marek Polacek via Gcc-patches
wrote:
>
> This patch fixes crashes with invalid attributes. Arguably it could
> make sense to assert seen_error() too.
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk = GCC 13?
>
> PR c++/96637
>
>
Ping.
On Fri, Apr 29, 2022 at 10:12:33AM -0400, Marek Polacek via Gcc-patches wrote:
> This patch fixes crashes with invalid attributes. Arguably it could
> make sense to assert seen_error() too.
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk = GCC 13?
>
> PR c++/96637
>
Ping.
On Mon, May 16, 2022 at 11:36:27AM -0400, Marek Polacek wrote:
> On Sat, May 14, 2022 at 11:13:28PM -0400, Jason Merrill wrote:
> > On 5/13/22 19:41, Marek Polacek wrote:
> > > --- a/gcc/cp/typeck2.cc
> > > +++ b/gcc/cp/typeck2.cc
> > > @@ -1371,6 +1371,70 @@ digest_init_flags (tree type,
PING^1
On 5/5/22 20:15, Martin Liška wrote:
> On 5/5/22 15:49, Jan Hubicka wrote:
>> Hi,
>>> The patch simplifies usage of the profile_{count,probability} types.
>>>
>>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>>
>>> Ready to be installed?
>>
>> The reason I
On 5/16/22 11:27, Martin Liška wrote:
> On 5/12/22 09:00, Richard Biener via Gcc-patches wrote:
>> On Wed, May 11, 2022 at 5:10 PM Bruno Haible wrote:
>>>
>>> The patch that was so far added for documenting --with-zstd is pretty
>>> minimal:
>>> - it refers to undocumented options
> On 5/11/22 11:44 AM, David Faust wrote:
>>
>> On 5/10/22 22:05, Yonghong Song wrote:
>>>
>>>
>>> On 5/10/22 8:43 PM, Yonghong Song wrote:
On 5/6/22 2:18 PM, David Faust wrote:
>
>
> On 5/5/22 16:00, Yonghong Song wrote:
>>
>>
>> On 5/4/22 10:03 AM, David
Hi,
some time ago we were requested to implement a -finstrument-functions-once
switch in the compiler, with the semantics that the profiling functions be
called only once per instrumented function. The goal was to make it possible
to use it in (large) production binaries to do function-level
On Tue, 24 May 2022 at 11:22, Jonathan Wakely wrote:
>
> On Tue, 24 May 2022 at 11:18, Jonathan Wakely wrote:
> >
> > On Thu, 5 May 2022 at 18:38, François Dumont via Libstdc++
> > wrote:
> > >
> > > Hi
> > >
> > > Renewing my patch to fix PR 56112 but for the insert methods, I totally
> > >
On Sat, May 21, 2022 at 3:11 AM Gaius Mulley wrote:
>
>
> Hi,
>
> Gaius wrote:
>
> > the changes do raise questions. The reason for the changes here are to
> > allow easy linking for modula-2 users.
>
> > $ gm2 hello.mod
>
> > for example will compile and link with all dependent modules
On Tue, 24 May 2022 at 11:18, Jonathan Wakely wrote:
>
> On Thu, 5 May 2022 at 18:38, François Dumont via Libstdc++
> wrote:
> >
> > Hi
> >
> > Renewing my patch to fix PR 56112 but for the insert methods, I totally
> > change it, now works also with move-only key types.
> >
> > I let you
On Thu, 5 May 2022 at 18:38, François Dumont via Libstdc++
wrote:
>
> Hi
>
> Renewing my patch to fix PR 56112 but for the insert methods, I totally
> change it, now works also with move-only key types.
>
> I let you Jonathan find a better name than _ValueTypeEnforcer as usual :-)
>
> libstdc++:
On Tue, 24 May 2022, Richard Sandiford wrote:
> Richard Biener writes:
> > This is another place where we fail to pass down the mode of a
> > CONST_INT.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
> >
> > Thanks,
> > Richard.
> >
> > 2022-05-24 Richard Biener
> >
> >
On Mon, May 23, 2022 at 4:27 PM Roger Sayle wrote:
>
>
> Hi Richard,
>
> Currently for pr96912, we end up with:
>
> W foo (W x, W y, V m)
> {
> W t;
> vector(16) _1;
> vector(16) signed char _2;
> W _7;
> vector(2) long long int _9;
> vector(2) long long int _10;
>
>[local count:
Richard Biener writes:
> This is another place where we fail to pass down the mode of a
> CONST_INT.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
>
> Thanks,
> Richard.
>
> 2022-05-24 Richard Biener
>
> PR middle-end/105711
> * expmed.cc
This is another place where we fail to pass down the mode of a
CONST_INT.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
Thanks,
Richard.
2022-05-24 Richard Biener
PR middle-end/105711
* expmed.cc (extract_bit_field_as_subreg): Add op0_mode parameter
and
Prathamesh Kulkarni writes:
> diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
> index c5006afc00d..0a3c733ada9 100644
> --- a/gcc/doc/tm.texi
> +++ b/gcc/doc/tm.texi
> @@ -6088,14 +6088,18 @@ for the given scalar type @var{type}.
> @var{is_packed} is false if the scalar
> access using
1 - 100 of 123 matches
Mail list logo
