> But this doesn't fix
>
> case TRUTH_NOT_EXPR:
> case BIT_NOT_EXPR:
> op = DW_OP_not;
> goto do_unop;
Revised patch attached, using Jakub's suggestion. The original (buggy) DWARF
procedure for the Ada testcase I previously posted is:
.uleb128 0x8# (DIE (0x5b) D
On Mon, May 16, 2022 at 9:06 AM Eric Botcazou wrote:
>
> > But this doesn't fix
> >
> > case TRUTH_NOT_EXPR:
> > case BIT_NOT_EXPR:
> > op = DW_OP_not;
> > goto do_unop;
>
> Revised patch attached, using Jakub's suggestion. The original (buggy) DWARF
> procedure for the Ada te
Fixes:
opts-global.cc:75:15: runtime error: store to address 0x0bc9be70 with
insufficient space for an object of type 'char'
which happens when mask == 0, len == 0 and we allocate zero elements.
Eventually, result[0] is called which triggers the UBSAN.
It's newly discovered after the Siddhesh
On Mon, May 16, 2022 at 09:45:18AM +0200, Richard Biener via Gcc-patches wrote:
> > * dwarf2out.c (loc_list_from_tree_1) : Do a logical
> > instead of a bitwise negation.
> > : Swap the operands if the condition is TRUTH_NOT_EXPR.
>
> LGTM.
It won't work for types larger t
> -Original Message-
> From: Richard Biener
> Sent: Monday, May 16, 2022 7:31 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; jeffreya...@gmail.com;
> Richard Sandiford
> Subject: Re: [PATCH 1/3]middle-end: Add the ability to let the target decide
> the method of argument
On Mon, May 16, 2022 at 2:38 PM Alexander Monakov wrote:
>
> On Mon, 16 May 2022, Rui Ueyama wrote:
>
> > If it is a guaranteed behavior that GCC of all versions that support
> > only get_symbols_v2 don't leave a temporary file behind if it is
> > suddenly disrupted during get_symbols_v2 execution
It's the warning I see every time I build GCC:
In file included from /home/marxin/Programming/gcc/gcc/coretypes.h:478,
from /home/marxin/Programming/gcc/gcc/expmed.cc:26:
In function ‘poly_uint16 mode_to_bytes(machine_mode)’,
inlined from ‘typename if_nonpoly::type
GET_MODE_S
On 5/11/22 10:17, Martin Liška wrote:
> On 5/9/22 14:03, Richard Biener wrote:
>> On Thu, May 5, 2022 at 4:30 PM Martin Liška wrote:
>>>
>>> On 5/5/22 14:58, Iain Buclaw wrote:
This D front-end change doesn't look right to me, besides the slight
>>>
>>> Hello.
>>>
>>> Sorry, I've re-read the
Routines Is_Enabled and Is_Enabled_Pragma are identical (except for
comments); remove this duplication.
Cleanup related to handling of volatile refinement aspects in SPARK;
behaviour is unaffected.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_util.adb (Is_Enabled): R
Routine Type_Or_Variable_Has_Enabled_Property handles either types or
objects; replace negation with an explicit positive condition.
Cleanup related to handling of volatile refinement aspects in SPARK;
behaviour is unaffected.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
*
Volatile refinement properties (e.g. Async_Writers), which refine the
Volatile aspect in SPARK, are inherited by subtypes from their base
types. In particular, this patch fixes handling of those properties for
subtypes of private types.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
This aligns Analyze_Negation and Analyze_Unary_Op with the other similar
procedures in Sem_Ch4. No functional changes.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_ch4.adb (Analyze_Negation): Minor tweak.
(Analyze_Unary_Op): Likewise.diff --git a/gcc/ada/sem_
This is an incremental change towards supporting shared libraries
for VxWorks on aarch64.
The aarch64-vx7r2 compiler supports compilation with -fpic/PIC. This
change adds aarch64 to the list of CPUs for which GNATLIB_SHARED maps to
gnatlib-shared-dual for vxworks7r2, so "make gnatlib-shared" actu
The problem is that Install_Limited_With_Clause does not fully implement
AI05-0129, in the case where a regular with clause is processed before a
limited_with clause of the same package: the visible "shadow" entity is
that of the incomplete type, instead of that of the full type per the AI.
This r
When checking components of a record type for their own user-defined
equality function it is enough to find just one such a component.
Cleanup related to handling of user-defined equality in GNATprove.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_ch3.adb (Build_Untag
Cleanup related to handling of user-defined equality in GNATprove.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_ch3.adb (User_Defined_Eq): Replace duplicated code with a
call to Get_User_Defined_Eq.diff --git a/gcc/ada/exp_ch3.adb b/gcc/ada/exp_ch3.adb
--- a/g
Finalization of a record object is required to finalize any components
that have an access discriminant constrained by a per-object expression
before other components. This includes the case of a type extension;
"early finalization" components of the parent type are required to be
finalized before
This moves the implementation of AI12-0101 + AI05-0123 from the expander
to the semantic analyzer and completes the implementation of AI12-0413,
which are both binding interpretations in Ada 2012, fixing a few bugs in
the process and removing a fair amount of duplicated code throughout.
Tested on
The semantic analysis of predicates involves a fair amount of tree
copying because of both semantic and implementation considerations, and
there is a difficulty with quantified expressions since they declare a
new entity that cannot be shared between the various copies of the tree.
This change imp
The key is that the protected type is a (limited) private type, which
fools a test in Cleanup_Scopes.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* inline.adb (Cleanup_Scopes): Test the underlying type.diff --git a/gcc/ada/inline.adb b/gcc/ada/inline.adb
--- a/gcc/ada/inli
Fix a regression in the support for Ada 2022's treatment of calls to
abstract subprograms in pre/post-conditions (thanks to Javier Miranda
for producing this patch).
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_disp.adb (Check_Dispatching_Context): When checking to se
The front-end drops the declaration of a temporary on the floor because
Insert_Actions fails to climb up out of an N_Iterated_Component_Association
when the temporary is created during the analysis of its Discrete_Choices.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_
Fix the escaping of the loop variable from the loop scope in both forms
of iterated element associations (i.e. "for J in ..." and "for J of
..."). Create a dedicated scope around the analyses of both loops. Also
create a copy of the Loop_Parameter_Specification instead of analyzing
(and modifying)
bzero is marked as legacy in POSIX.1-2001, and using it triggers a
deprecation warnings on some systems such as QNX. This change adjusts
the one place where we use it in terminals.c to use memset instead.
This, in turns, allows us to get rid of a hack for HP/UX and Solaris.
Tested on x86_64-pc-lin
The functions in subpackage Storage_Model_Support (apart from the
Has_*_Aspect functions) are revised to have assertions that will fail
when passed a parameter that doesn't specify the appropriate aspect
(either aspect Storage_Model_Type or Designated_Storage_Model), instead
of returning Empty for
When building the GNAT runtime for QNX, we get the following warning:
| cstreams.c: In function '__gnat_full_name':
| cstreams.c:209:5: warning: implicit declaration of function 'realpath'
| [-Wimplicit-function-declaration]
| 209 | realpath (nam, buffer);
| | ^~~
On QNX, the sigaction handler is incorrectly installed via the
sa_handler field of struct sigaction, rather than the sa_sigaction
field. This triggers a compilation warning due to a mismatch between the
function's signature and the field's type.
| init.c:2614:18: warning: assignment to 'void (
The QNX version of __gnat_install_handler calls sigaction for a number
of signals, and then prints an error message when the the call failed.
But unfortunately, except for the first call, we forgot to store
sigaction's return value, so the check that ensues uses a potentially
uninitialized variable
Setting this parameter to zero when calling the Configure procedure has
the effect of disabling completely the tracking of the biggest memory
users, which wasn't clear from the current documentation. So this patch
enhances the documentation of both the Configure procedure as well as
the Dump proce
Before this commit, a GNAT compiled with assertions would crash when
attempting to emit CUDA symbols in ALI files for spark_mode/ghost
packages, whose content is a single null statement.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* lib-writ.adb (Output_CUDA_Symbols): Chec
Proof of an assertion is not automatic anymore. Add two assertions
before it to guide the prover.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* libgnat/s-aridou.adb (Double_Divide): Add intermediate
assertions.diff --git a/gcc/ada/libgnat/s-aridou.adb b/gcc/ada/lib
An object declaration (other than a deferred constant declaration)
causes freezing where it occurs (13.14(6)), which means every name
occurring within it causes freezing (13.14(4/1)), and when the name in a
subtype_mark causes freezing, the denoted subtype is frozen (13.14(11)).
Hence, one needs to
This patch corrects an error in the compiler whereby a function
requiring the generation of a postconditions procedure may cause an
uninitialized memory read when the return type
Has_Unconstrained_Elements or is an unconstrained array.
The error occurs because evaluation of postconditions happens
The current value propagation applies only to assignable objects and
doesn't make sense for subprogram entities. This was a mistake
introduced when extending the current value propagation years ago.
Cleanup related to fixing interference between expansion of attribute
Loop_Entry and current value
When expanding attribute Loop_Entry we create constant object
declarations and put them just before the loop. The current values of
variables at the point of Loop_Entry attribute must not be used when
analysing the initialization expressions of these constants, because
they might be different from
The problem is that the resolution of expanded names implicitly assumes
that the visible and private homonyms in a given scope are segregated on
the homonym chain, and this was no longer the case for equality operators
in the specific case at stake.
Tested on x86_64-pc-linux-gnu, committed on trun
> It won't work for types larger than size of address, it would need to use
> dwarf_OP (DW_OP_const_type) instead of DW_OP_lit0 in that case.
> But maybe TRUTH_NOT_EXPR will be never seen for such types and after all,
> even the loc_list_from_tree_1 INTEGER_CST case doesn't handle that
> (the RTL c
On Mon, May 16, 2022 at 10:47:53AM +0200, Eric Botcazou wrote:
> > It won't work for types larger than size of address, it would need to use
> > dwarf_OP (DW_OP_const_type) instead of DW_OP_lit0 in that case.
> > But maybe TRUTH_NOT_EXPR will be never seen for such types and after all,
> > even the
Martin Liška writes:
> It's the warning I see every time I build GCC:
>
> In file included from /home/marxin/Programming/gcc/gcc/coretypes.h:478,
> from /home/marxin/Programming/gcc/gcc/expmed.cc:26:
> In function ‘poly_uint16 mode_to_bytes(machine_mode)’,
> inlined from ‘type
On Mon, May 16, 2022 at 9:53 AM Martin Liška wrote:
>
> Fixes:
> opts-global.cc:75:15: runtime error: store to address 0x0bc9be70 with
> insufficient space for an object of type 'char'
> which happens when mask == 0, len == 0 and we allocate zero elements.
> Eventually, result[0] is called wh
On Sat, May 7, 2022 at 7:05 AM liuhongt wrote:
>
> This is adjusted patch only for OImode.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk?
>
> gcc/ChangeLog:
>
> PR target/104610
> * config/i386/i386-expand.cc (ix86_expand_branch): Use ptest
>
On Mon, May 16, 2022 at 10:37 AM Rui Ueyama via Gcc-patches
wrote:
>
> On Mon, May 16, 2022 at 2:38 PM Alexander Monakov wrote:
> >
> > On Mon, 16 May 2022, Rui Ueyama wrote:
> >
> > > If it is a guaranteed behavior that GCC of all versions that support
> > > only get_symbols_v2 don't leave a tem
On Mon, 16 May 2022, Richard Biener wrote:
> Is there an API document besides the header itself somewhere?
It's on the wiki: https://gcc.gnu.org/wiki/whopr/driver
(sadly the v3 entrypoint was added there without documentation)
Alexander
The following tries to correct get_origin_and_offset_r not handling
non-constant sizes of array elements in ARRAY_REFs and non-constant
offsets of COMPONENT_REFs. It isn't exactly clear how such failures
should be treated in this API and existing handling isn't consistent
here either. The followi
>
> Sure having a 'plugin was compiled from sources of the GCC N.M compiler'
> is useful if bugs are discovered in old versions that you by definition cannot
> fix but can apply workarounds to. Note the actual compiler used might still
> differ. Note that still isn't clean API documentation / ex
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 --with-zstd-include and
>> --with-zstd-lib;
>> - it s
On 5/16/22 11:25, Jan Hubicka via Gcc-patches wrote:
>>
>> Sure having a 'plugin was compiled from sources of the GCC N.M compiler'
>> is useful if bugs are discovered in old versions that you by definition
>> cannot
>> fix but can apply workarounds to. Note the actual compiler used might still
>
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}
Ok for trunk?
gcc/ChangeLog:
PR tree-optimization/105591
* tree-ssa-forwprop.cc (simplify_bitfield_ref): Clamp
vec_perm_expr index.
gcc/testsuite/ChangeLog:
* gcc.dg/pr105591.c: New test.
---
gcc/testsuite
Hi all,
small update (interdiff): s/s/S/ for consistency, missed one GCC 13 commit, and
improved wording of the enter/exit change. (New wording better captures the
effect; I was thinking too much of the changed spec wording not of the effective
result.)
Plus added some cross-ref hyperlinks to mak
> On 5/16/22 11:25, Jan Hubicka via Gcc-patches wrote:
> >>
> >> Sure having a 'plugin was compiled from sources of the GCC N.M compiler'
> >> is useful if bugs are discovered in old versions that you by definition
> >> cannot
> >> fix but can apply workarounds to. Note the actual compiler used m
Version handshaking is doable, but it feels like we are over-designing
an API, given that the real providers of this plugin API are only GCC
and LLVM and the users of the API are BFD ld, gold and mold. It is
unlikely that we'll have dozens of more compilers or linkers in the
near future. So, I pers
Hi Tobias,
On Sat, 14 May 2022, Tobias Burnus wrote:
> Jakub and I discussed the other day that it would be useful
> to have a page similar to
> https://gcc.gnu.org/projects/cxx-status.html
> to provide by-GCC-version information of the which OpenMP are supported.
this looks like a great idea,
Tested on x86_64-unknown-linux-gnu, pushed.
2022-05-16 Richard Biener
PR rtl-optimization/105577
* g++.dg/torture/pr105577.C: New testcase.
---
gcc/testsuite/g++.dg/torture/pr105577.C | 156
1 file changed, 156 insertions(+)
create mode 100644 gcc/t
On Mon, May 16, 2022 at 11:50 AM Jan Hubicka wrote:
>
> > On 5/16/22 11:25, Jan Hubicka via Gcc-patches wrote:
> > >>
> > >> Sure having a 'plugin was compiled from sources of the GCC N.M compiler'
> > >> is useful if bugs are discovered in old versions that you by definition
> > >> cannot
> > >>
On Sat, 14 May 2022, Palmer Dabbelt wrote:
> > Hmm, should we? We only support `-misa-spec=<2.2|20190608|20191213>'
> > already and this update is fine for r.2.2+. If someone has pre-r.2.2 hw,
> > then it's been already unsupported even before this change (as from GCC 11
> > AFAICS). Have I mi
While 'vendor' and 'kind' is well defined, 'arch' and 'isa' isn't.
When looking at an 'metadirective' testcase (which oddly uses 'arch(amd)'),
I noticed that LLVM uses 'arch(amdgcn)' while we use 'gcn', cf. e.g.
'clang/lib/Headers/openmp_wrappers/math.h'.
(Side note: we use the target triplet amd
On Mon, May 16, 2022 at 11:58 AM Rui Ueyama wrote:
>
> Version handshaking is doable, but it feels like we are over-designing
> an API, given that the real providers of this plugin API are only GCC
> and LLVM and the users of the API are BFD ld, gold and mold. It is
> unlikely that we'll have doze
On Mon, May 16, 2022 at 11:18 AM Richard Sandiford via Gcc-patches
wrote:
>
> Martin Liška writes:
> > It's the warning I see every time I build GCC:
> >
> > In file included from /home/marxin/Programming/gcc/gcc/coretypes.h:478,
> > from /home/marxin/Programming/gcc/gcc/expmed.c
Christophe Lyon via Gcc-patches writes:
> These tests exercise exception handling with Decimal Floating-Point
> type.
>
> dfp-1.C and dfp-2.C check that thrown objects of such types are
> properly caught, whether when using C++ classes (decimalXX) or via GCC
> mode attributes.
>
> dfp-saves-aarch6
tree.h already contains combined_fn handling at the top and moving
code_helper away from gimple-match.h makes improving the gimple_build
API easier.
Bootstrapped on x86_64-unknown-linux-gnu.
Will push this if there are no comments when I've finished
enhancing the gimple_build API (and moving piec
On Mon, May 16, 2022 at 6:28 PM Richard Biener
wrote:
>
> On Mon, May 16, 2022 at 11:58 AM Rui Ueyama wrote:
> >
> > Version handshaking is doable, but it feels like we are over-designing
> > an API, given that the real providers of this plugin API are only GCC
> > and LLVM and the users of the A
Richard Biener writes:
> tree.h already contains combined_fn handling at the top and moving
> code_helper away from gimple-match.h makes improving the gimple_build
> API easier.
Nice. Thanks for doing this.
Richard
>
> Bootstrapped on x86_64-unknown-linux-gnu.
>
> Will push this if there are n
Hi all,
I would like to ping the following patches from Frederik's
"[PATCH 00/40] OpenACC "kernels" Improvements" series
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586901.html
patch set thread link:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/thread.html#586901
(A)
On 16/05/2022 11:28, Tobias Burnus wrote:
While 'vendor' and 'kind' is well defined, 'arch' and 'isa' isn't.
When looking at an 'metadirective' testcase (which oddly uses 'arch(amd)'),
I noticed that LLVM uses 'arch(amdgcn)' while we use 'gcn', cf. e.g.
'clang/lib/Headers/openmp_wrappers/math.h'
On 5/11/22 18:43, Joseph Myers wrote:
There are various coding style issues in the patch; at least missing space
before '(' and '&&' at end of line (should be at start of line). It will
also need to be updated for .c files having been renamed to .cc in the GCC
source tree.
Thanks, I've fixed
On Mon, 16 May 2022, Tobias Burnus wrote:
> Hi all,
>
> I would like to ping the following patches from Frederik's
> "[PATCH 00/40] OpenACC "kernels" Improvements" series
> https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586901.html
> patch set thread link:
> https://gcc.gnu.org/pipe
Tamar Christina writes:
> Hi All,
>
> Some targets require function parameters to be promoted to a different
> type on expand time because the target may not have native instructions
> to work on such types. As an example the AArch64 port does not have native
> instructions working on integer 8-
This finishes the remaining parts of the gimple_build API enhancement,
converting the remaining workers to receive a gimple_stmt_iterator,
direction and update argument. It also moves the code_helper
receiving functions from gimple-match.h to gimple-fold.h.
Bootstrapped and tested on x86_64-unkno
"Pop, Sebastian" writes:
> Please see attached the patch back-ported to branches 12, 11, 10, and 9.
> Tested on aarch64-linux with bootstrap and regression test.
> Ok to commit to the GCC active branches?
OK, thanks. Only very safe patches are supposed to be going into GCC 9
at this stage, and I
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, May 16, 2022 12:36 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de;
> jeffreya...@gmail.com
> Subject: Re: [PATCH 1/3]middle-end: Add the ability to let the target decide
> the method of argume
On 5/16/22 12:28, Richard Biener wrote:
> On Mon, May 16, 2022 at 11:58 AM Rui Ueyama wrote:
>>
>> Version handshaking is doable, but it feels like we are over-designing
>> an API, given that the real providers of this plugin API are only GCC
>> and LLVM and the users of the API are BFD ld, gold a
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Monday, May 16, 2022 12:36 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de;
>> jeffreya...@gmail.com
>> Subject: Re: [PATCH 1/3]middle-end: Add the ability to let the target
On 5/13/22 18:35, Richard Sandiford wrote:
Christophe Lyon via Gcc-patches writes:
@@ -19352,7 +19363,9 @@ aarch64_legitimate_constant_p (machine_mode mode, rtx x)
{
/* Support CSE and rematerialization of common constants. */
if (CONST_INT_P (x)
- || (CONST_DOUBLE_P (x) && GE
Richard Sandiford via Gcc-patches writes:
> Tamar Christina writes:
>>> -Original Message-
>>> From: Richard Sandiford
>>> Sent: Monday, May 16, 2022 12:36 PM
>>> To: Tamar Christina
>>> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de;
>>> jeffreya...@gmail.com
>>> Subject: Re: [PAT
This goes away with the selection operand allowed to be a GENERIC
tcc_comparison tree. It keeps those for vectorizer pattern recog,
those are short lived and removing this instance is a bigger task.
The patch doesn't yet remove dead code and functionality, that's
left for a followup. Instead the
This removes is_gimple_condexpr, note the vectorizer via patterns
still creates COND_EXPRs with embedded GENERIC conditions and has
a reference to the function in comments. Otherwise is_gimple_condexpr
is now equal to is_gimple_val.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Rich
A generous [snip], as this has been getting a bit long.
On Sun, 15 May 2022 at 03:21, Palmer Dabbelt wrote:
> I am worried about bad
> actors leveraging any policy to make a bunch of noise, as that's a
> pretty persistent problem in RISC-V land and it looks like things are
> going to get worse b
On Mon, 16 May 2022, liuhongt wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}
> Ok for trunk?
OK.
Thanks,
Richard.
> gcc/ChangeLog:
>
> PR tree-optimization/105591
> * tree-ssa-forwprop.cc (simplify_bitfield_ref): Clamp
> vec_perm_expr index.
>
> gcc/testsu
As requested by Richard: Rediffed patch.
Changes: s/.c/.cc/ + some whitespace changes.
(At least in my email reader, some were lost. I also fixed too-long line
issues.)
In addition, FOR_EACH_LOOP was replaced by 'for (auto loop : ...'
(macro was removed late in GCC 12 development → r12-2605-ge
Rediffed Frederik's patch. Actual change is just s/.c/.cc/ but also a
missing space → tab.
On 15.12.21 16:54, Frederik Harwath wrote:
The SSA names for which this function gets used are always SCoP
parameters and hence "isl_id_for_parameter" is a better name. It also
explains the prefix "P_" fo
Another comment-only change.
Otherwise, just re-diffed Frederik's patch. Mostly s/.c/.cc/, but I
added one '. ' that got lost.
On 15.12.21 16:54, Frederik Harwath wrote:
* graphite-sese-to-poly.c (build_poly_sr_1): Fix a typo and
a reference to a variable which does not exist.
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, May 16, 2022 1:18 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de;
> jeffreya...@gmail.com
> Subject: Re: [PATCH 1/3]middle-end: Add the ability to let the target decide
> the method of argument
On Mon, May 16, 2022 at 8:04 PM Martin Liška wrote:
>
> On 5/16/22 12:28, Richard Biener wrote:
> > On Mon, May 16, 2022 at 11:58 AM Rui Ueyama wrote:
> >>
> >> Version handshaking is doable, but it feels like we are over-designing
> >> an API, given that the real providers of this plugin API are
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Monday, May 16, 2022 1:18 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de;
>> jeffreya...@gmail.com
>> Subject: Re: [PATCH 1/3]middle-end: Add the ability to let the target
On Mon, 16 May 2022, Rui Ueyama wrote:
> > @Rui: Am I correct that you're interested in thread-safe claim_file? Is
> > there any
> > other function being called paralely?
>
> Yes, I want a thread-safe claim_file. And that function seems to be
> the only function in mold that is called in paralle
This patch adds support for trunc and extend operations between HF
mode (_Float16) and Decimal Floating Point formats (_Decimal32,
_Decimal64 and _Decimal128).
For simplicity we rely on the implicit conversions inserted by the
compiler between HF and SD/DF/TF modes. The existing bid*_to_binary*
a
Pushed to trunk. Backports to all branches needed.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/html/manual/status.html: Regenerate.
* doc/xml/manual/status_cxx2020.xml: Fix supported version for
C++20 bit operations.
---
libstdc++-v3/doc/html/manual/status.html | 2 +-
Pushed to trunk. Backports to gcc-11 and gcc-12 to follow.
-- >8 --
These are the C++23 proposals already supported in the gcc-11 branch.
libstdc++-v3/ChangeLog:
* doc/xml/manual/intro.xml: Include new chapter.
* doc/xml/manual/status_cxx2020.xml: Tweak release numbers.
Pushed to trunk. Backports to follow.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/prerequisites.xml: Fix attributes for external
hyperlink.
* doc/html/manual/setup.html: Regenerate.
---
libstdc++-v3/doc/html/manual/setup.html | 2 +-
libstdc++-v3/doc/xml/manu
Pushed to trunk. Backport to gcc-12 to follow.
-- >8 --
These are the C++23 proposals supported in the gcc-12 branch.
libstdc++-v3/ChangeLog:
* doc/xml/manual/status_cxx2023.xml: Update with gcc-12 support.
* doc/html/*: Regenerate.
---
libstdc++-v3/doc/html/manual/status.html
This documents the partial support for P2231 in the gcc-11 branch,
pushed to that branch.
commit 5d418194ccb39346d2ad022c5b143fe00b2340ac
Author: Jonathan Wakely
Date: Mon May 16 15:33:06 2022
libstdc++: Document support for constexpr optional (P2231R1)
The changes for std::variant
A warning about target-nesting inside target makes sense,
but not if the inner target is one for reverse offload ("device(ancestor:1)").
Thus, silence the warning in this case.
OK for mainline?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 8063
Ping.
On 5/10/22 16:48, Jason Merrill wrote:
Ping?
On 5/5/22 14:07, Jason Merrill wrote:
In my patch for PR100545 I added an assert to check for broken
typedefs in
set_underlying_type, and it found one in this case:
rs6000_handle_altivec_attribute had the same problem as
handle_mode_attribute
On Mon, 16 May 2022, Martin Liška wrote:
> I've implemented first version of the patch, please take a look.
I'll comment on the patch, feel free to inform me when I should back off
with forcing my opinion in this thread :)
> --- a/include/plugin-api.h
> +++ b/include/plugin-api.h
> @@ -483,6 +48
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, May 16, 2022 2:24 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de;
> jeffreya...@gmail.com
> Subject: Re: [PATCH 1/3]middle-end: Add the ability to let the target decide
> the method of argument
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)
> > return digest_init_r (
On Mon, 9 May 2022, Jan Hubicka wrote:
> > On second thought, it might be better to keep the assert, and place the loop
> > under 'if (optimize)'?
>
> The problem is that at IPA level it does not make sense to check
> optimize flag as it is function specific. (shlib is OK to check it
> anywhere
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Monday, May 16, 2022 2:24 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de;
>> jeffreya...@gmail.com
>> Subject: Re: [PATCH 1/3]middle-end: Add the ability to let the target
Hi,
Upstream dmd has now released v2.100.0, this patch merges in the
latest bug fixes since the last sync-up of the release branch, as well
as all new feature changes on development branch.
D front-end changes:
- Import dmd v2.100.0.
- Add bit fields to D, enabled via the -fpreview=bitfi
dynamic_cast can legally return nullptr, so I don't think it's helpful
for -Waddress to warn for
if (dynamic_cast(&ref))
// ...
More generally, it's likely not useful to warn for the artificial
POINTER_PLUS_EXPRs created by build_base_path.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok
1 - 100 of 118 matches
Mail list logo
