Hi Thomas,
>> Both of these functions are new with Fortran 2018, could you add
>> a standards version check?
>
> Thanks Thomas, I will do that and post here the commit diff. The check will
> not be perfect, though, because the warning/error cannot be emitted when
> loading the module (because
On Fri, 9 Sep 2022, 18:25 Patrick Palka via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> PR libstdc++/106798
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (adjacent_view::_Iterator::_Iterator): Fix
> typo.
> * testsuite/std/ranges/adaptors/adjacent/1.cc
Tested on x86_64-pc-linux-gnu, does this series look OK for trunk?
PR libstdc++/106803
libstdc++-v3/ChangeLog:
* include/std/ranges (views::_ZipTransform::operator()): Fix
return type in the empty case.
(views::_AdjacentTransform::operator()): Likewise.
---
make_unsigned_t can't give us the unsigned version of an integer-class
difference type, so use __make_unsigned_like_t / __to_unsigned_like
instead.
PR libstdc++/106766
libstdc++-v3/ChangeLog:
* include/std/ranges (zip_view::_Iterator::operator-): Use
__to_unsigned_like
On Fri, 9 Sep 2022, 18:27 Patrick Palka via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> Tested on x86_64-pc-linux-gnu, does this series look OK for trunk?
>
All three are OK, thanks.
> PR libstdc++/106803
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges
s/__weak/__is_weak/g perhaps?
On Fri, Sep 9, 2022 at 11:46 AM Iain Sandoe via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
>
>
> > On 9 Sep 2022, at 19:36, Rainer Orth
> wrote:
> >
>
> >> Here's a complete patch that combines the various incremental patches
> >> that have been going around. I'm
On Mon, Aug 29, 2022 at 08:43:26PM +0200, Tobias Burnus wrote:
> Slightly revised version, fixing some issues in mkoffload.cc. Otherwise, the
> same applies:
>
> On 25.08.22 19:30, Tobias Burnus wrote:
> On 25.08.22 16:54, Tobias Burnus wrote:
>
> The attached patch prepare for reverse-offload
On Thu, 8 Sep 2022, Kwok Cheung Yeung wrote:
> The sin and cos instructions for some reason are scaled by 2*PI radians (i.e.
> 1.0 == 2*PI radians/360 degrees), so their inputs need to be scaled by
> 1/(2*PI) first. I've implemented this as an expander to two instructions - one
C2x has sinpi and
On Fri, Aug 26, 2022 at 01:15:24PM +0200, Tobias Burnus wrote:
> For reverse-offload data handling, we need to support:
> (a) device fn addr -> host fn address
> (b) finding already mapped host -> device vars via their device address
>
> For (a), the functions addrs, we need some extra code (cf.
On Thu, 8 Sept 2022 at 18:51, François Dumont via Libstdc++
wrote:
>
> On 05/09/22 20:30, Will Hawkins wrote:
> > Based on Jonathan's work, here is a patch for the implementation of
> > operator+
> > on std::string that makes sure we always use the best allocation strategy.
> >
> > I have
On Thu, Aug 25, 2022 at 04:54:51PM +0200, Tobias Burnus wrote:
> Technically, this patch is stand alone, but conceptually it based on the
> submitted but not reviewed patch:
> "[Patch] OpenMP: Support reverse offload (middle end part)"
>
Hi Jonathan,
> Here's a complete patch that combines the various incremental patches
> that have been going around. I'm testing this now.
>
> Please take a look.
unfortunately, this patch broke macOS bootstrap (seen on
x86_64-apple-darwin11.4.2):
In file included from
The macro ATOMIC_VAR_INIT, previously declared obsolete,
is removed completely in C2x; disable it for C2x in GCC's
implementation. (Although ATOMIC_* are reserved names for this
header, disabling the macro for C2x still seems appropriate.)
Bootstrapped with no regressions for
On Fri, Aug 26, 2022 at 11:07:28AM +0200, Tobias Burnus wrote:
> @Tom and Alexander: Better suggestions are welcome for the busy loop in
> libgomp/plugin/plugin-nvptx.c regarding the variable placement and checking
> its value.
I'm afraid you need Alexander or Tom here, I don't feel I can review
On Fri, 9 Sept 2022 at 20:01, Thomas Rodgers wrote:
>
> s/__weak/__is_weak/g perhaps?
Yes, that'll do. Fixed by the attached, with a test to avoid it happening again.
Tested x86_64-linux, pushed to trunk.
>
> On Fri, Sep 9, 2022 at 11:46 AM Iain Sandoe via Libstdc++
> wrote:
>>
>>
>>
>> >
On Thu, Aug 25, 2022 at 05:38:58PM +0200, Tobias Burnus wrote:
> On 25.08.22 16:54, Tobias Burnus wrote:
>
> The attached patch prepare for reverse-offload device->host
> function-address lookup by requesting (if needed) the on-device address.
>
>
> This patch adds the actual implementation for
Martin Liška writes:
>> gm2.texi. I see a few missing options (missing from gm2.texi) and also
>
> Do you have an example, please?
-fscaffold-main was missing from gcc/doc/gm2.texi. I've git pushed a
correction (and alphabetically sorted all options).
>> I see problems with the libraries -
On Fri, Aug 26, 2022 at 05:56:09PM +0300, Alexander Monakov via Gcc-patches
wrote:
>
> On Fri, 26 Aug 2022, Tobias Burnus wrote:
>
> > @Tom and Alexander: Better suggestions are welcome for the busy loop in
> > libgomp/plugin/plugin-nvptx.c regarding the variable placement and checking
> > its
On Thu, Sep 08, 2022 at 01:59:02PM +0800, HAO CHEN GUI wrote:
> In rs6000-overload.def, the vsx_ version built-ins are overridden to vec_
> version.
How? Where?
Instead, afaics they are defined in rs6000-builtins.def:
const vd __builtin_vsx_extract_exp_dp (vd);
VEEDP xvxexpdp {}
const
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-2571-g084dc9a0c6cec1.
gcc/testsuite/ChangeLog:
PR analyzer/98247
* gcc.dg/analyzer/flexible-array-member-1.c: New test.
Signed-off-by: David Malcolm
---
This is a less ambitious version of:
[PATCH 0/6] RFC: adding support to GCC for detecting trust boundaries
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584372.html
Earlier versions of this patch attempted:
(a) various ways of identifying "untrusted" memory regions
(b) providing a
On 9/9/22 8:27 AM, Kewen.Lin wrote:
> __attribute__((noipa))
> int foo(c){
> return 0;
> }
>
> int main ()
> {
> const __vector_quad c;
> int r = foo(c);
> return r;
> }
>
> Checking during LTO WPA, verify_type only gets type "const
> __vector_quad", no type "__vector_quad".
>
> btw, it
On 9/9/22 8:47 PM, Segher Boessenkool wrote:
> On Fri, Sep 09, 2022 at 07:56:42PM -0500, Peter Bergner wrote:
>> On 9/9/22 8:27 AM, Kewen.Lin wrote:
>>> btw, it needs some hacking in rs6000_function_arg to make this
>>> opaque type valid for function arg.
>>
>> We don't allow (at this time)
This patch adds the ability for plugins to register "known functions"
with the analyzer, identified by name. If -fanalyzer sees a call to
such a function (with no body), it will use a plugin-provided subclass
of the new known_function abstract base class to model the possible
outcomes of the
On Thu, Sep 8, 2022 at 2:38 PM Takayuki 'January June' Suwa
wrote:
>
> Changes from v3:
> (xtensa_expand_prologue): Changed to exclude debug insns from DF use chain
> analysis.
>
> ---
>
> In the example below, 'x' is once placed on the stack frame and then read
> into registers as the
On May 10, 2022, at 6:31 PM, Kito Cheng via Gcc-patches
wrote:
>
> LGTM, that's only added a new option for RISC-V and won't affect all
> other targets, so I assume I can approve that.
Yes. Usual and customary for ports.
Hi!
On Wed, 2022-09-07 14:00:25 +0200, Richard Biener
wrote:
> On Wed, Sep 7, 2022 at 12:58 PM Jan-Benedict Glaw wrote:
> > ../../gcc/gcc/tree-ssa-forwprop.cc:1258:42: error: array subscript 1 is
> > outside array bounds of 'tree_node* [1]' [-Werror=array-bounds]
> > 1258 | op[i
Hi Jakub,
> On Wed, Aug 31, 2022 at 12:56:25PM +0200, Marcel Vollweiler wrote:
>> libgomp/ChangeLog:
[...]
>> (initialize_env): Extended to parse the new syntax of environment
>> variables.
this patch broke Darwin bootstrap:
Undefined symbols for architecture x86_64:
"_environ",
> On 9 Sep 2022, at 23:08, Jakub Jelinek wrote:
>
> On Fri, Sep 09, 2022 at 10:50:19PM +0200, Rainer Orth wrote:
>> Hi Jakub,
>>
>>> On Wed, Aug 31, 2022 at 12:56:25PM +0200, Marcel Vollweiler wrote:
libgomp/ChangeLog:
>> [...]
(initialize_env): Extended to parse the new syntax
On Wed, Aug 31, 2022 at 10:50 PM Takayuki 'January June' Suwa
wrote:
>
> This patch eliminates all clobbers for complex hard registers that will
> be overwritten entirely afterwards (supersedence of
> 3867d414bd7d9e5b6fb2a51b1fb3d9e9e1eae9).
>
> gcc/ChangeLog:
>
> *
Ok.
> On Aug 24, 2022, at 4:59 AM, herron.phi...@googlemail.com wrote:
>
> From: Philip Herron
>
> This copy's over code from other front-end testsuites to enable testing
> for the rust front-end specifically.
>
> Co-authored-by: Marc Poulhiès
> Co-authored-by: Thomas Schwinge
> ---
>
On Fri, Sep 09, 2022 at 10:50:19PM +0200, Rainer Orth wrote:
> Hi Jakub,
>
> > On Wed, Aug 31, 2022 at 12:56:25PM +0200, Marcel Vollweiler wrote:
> >> libgomp/ChangeLog:
> [...]
> >>(initialize_env): Extended to parse the new syntax of environment
> >>variables.
>
> this patch broke
On Fri, Sep 09, 2022 at 11:13:52PM +0100, Iain Sandoe wrote:
> We already have such a header …
> include/environ.h
Ah, ok, then please just use it. Seems libgomp Makefile.am
already includes -I$(top_srcdir)/../include
So just include that and remove the extern char **environ;
from the
On Fri, Sep 09, 2022 at 07:56:42PM -0500, Peter Bergner wrote:
> On 9/9/22 8:27 AM, Kewen.Lin wrote:
> > btw, it needs some hacking in rs6000_function_arg to make this
> > opaque type valid for function arg.
>
> We don't allow (at this time) __vector_pair or __vector_quad to be
> used as actual
PR libstdc++/106798
libstdc++-v3/ChangeLog:
* include/std/ranges (adjacent_view::_Iterator::_Iterator): Fix
typo.
* testsuite/std/ranges/adaptors/adjacent/1.cc (test04): New test.
---
libstdc++-v3/include/std/ranges | 2 +-
ping
> Le 1 sept. 2022 à 23:02, FX a écrit :
>
> Attached patch adds __builtin_iseqsig() to the middle-end and C family
> front-ends.
> Testing does not currently check whether the signaling part works, because
> with optimisation is actually does not (preexisting compiler bug:
>
On Fri, 9 Sep 2022, 18:25 Patrick Palka via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> make_unsigned_t can't give us the unsigned version of an integer-class
> difference type, so use __make_unsigned_like_t / __to_unsigned_like
> instead.
>
OK, thanks
> PR libstdc++/106766
>
>
> On 9 Sep 2022, at 19:36, Rainer Orth wrote:
>
>> Here's a complete patch that combines the various incremental patches
>> that have been going around. I'm testing this now.
>>
>> Please take a look.
>
> unfortunately, this patch broke macOS bootstrap (seen on
>
How did you test that?
../../gcc/common/config/riscv/riscv-common.cc: In function 'const char*
riscv_multi_lib_check(int, const char**)':
../../gcc/common/config/riscv/riscv-common.cc:1451:11: error: bare apostrophe
''' in format [-Werror=format-diag]
1451 | "Can't find suitable multilib
On Thu, Sep 8, 2022 at 9:32 PM Joseph Myers wrote:
>
> C2x adds a macro unreachable to stddef.h, with the same semantics as
> __builtin_unreachable. Define this macro accordingly.
>
> Bootstrapped with no regressions for x86_64-pc-linux-gnu. OK to commit?
OK.
> gcc/
> *
Hi Richi,
Thanks for the review comments!
on 2022/9/8 15:36, Richard Biener wrote:
>
>
>> Am 08.09.2022 um 07:53 schrieb Kewen.Lin :
>>
>> Hi,
>>
>> As PR106833 shows, cv-qualified opaque type can cause ICE
>> during LTO. It exposes that we missd to handle OPAQUE_TYPE
>> well in type
On Fri, Sep 9, 2022 at 8:51 AM Kewen.Lin wrote:
>
> Hi Richi,
>
> Thanks for the review comments!
>
> on 2022/9/8 15:36, Richard Biener wrote:
> >
> >
> >> Am 08.09.2022 um 07:53 schrieb Kewen.Lin :
> >>
> >> Hi,
> >>
> >> As PR106833 shows, cv-qualified opaque type can cause ICE
> >> during
This is a backport from trunk to gcc-12.
Several MVE builtins incorrectly use the same predicate/constraint
pair for several modes, which does not match the specification.
This patch uses the appropriate iterator instead.
2022-09-06 Christophe Lyon
gcc/
* config/arm/mve.md
../../gcc/common/config/riscv/riscv-common.cc: In function 'const char*
riscv_multi_lib_check(int, const char**)':
../../gcc/common/config/riscv/riscv-common.cc:1451:11: error: bare apostrophe
''' in format [-Werror=format-diag]
1451 | "Can't find suitable multilib set for
On 2022/8/26 4:15 PM, Chung-Lin Tang wrote:
> On 2022/8/4 9:31 PM, Koning, Paul wrote:
>>
>>
>>> On Aug 4, 2022, at 9:17 AM, Chung-Lin Tang wrote:
>>>
>>> On 2022/6/28 10:06 PM, Jakub Jelinek wrote:
On Thu, Jun 23, 2022 at 11:47:59PM +0800, Chung-Lin Tang wrote:
> with the way that
If CXXFLAGS contains something unsupported by the build CXX, we see
build failures (e.g. using -fmacro-prefix-map for the target). Ensure
that CXXFLAGS_FOR_BUILD is passed where appropriate so that the correct
flags are used.
ChangeLog:
* Makefile.in: Regenerate.
* Makefile.tpl: Add
On Fri, 9 Sep 2022, Tobias Burnus wrote:
> On 09.09.22 10:10, Andrew Stubbs wrote:
> On 08.09.22 22:38, Kwok Cheung Yeung wrote:
> The instructions for the transcendental functions are documented to have
> limited numerical precision, so they are only used if
> unsafe_math_optimizations are
When testing a cross toolchain outside the build tree, the binary name
for gcov is prefixed with the tripplet.
gcc/testsuite/ChangeLog:
* g++.dg/gcov/gcov.exp: Respect tripplet when looking for gcov
* gcc.misc-tests/gcov.exp: Likewise
Signed-off-by: Torbjörn SVENSSON
---
on 2022/9/9 15:25, Richard Biener wrote:
> On Fri, Sep 9, 2022 at 8:51 AM Kewen.Lin wrote:
>>
>> Hi Richi,
>>
>> Thanks for the review comments!
>>
>> on 2022/9/8 15:36, Richard Biener wrote:
>>>
>>>
Am 08.09.2022 um 07:53 schrieb Kewen.Lin :
Hi,
As PR106833 shows,
On Thu, Sep 8, 2022 at 2:05 PM Jonathan Wakely wrote:
>
>
>
> On Thu, 8 Sep 2022, 18:51 François Dumont via Libstdc++,
> wrote:
>>
>> On 05/09/22 20:30, Will Hawkins wrote:
>> > Based on Jonathan's work, here is a patch for the implementation of
>> > operator+
>> > on std::string that makes
On Mon, 5 Sept 2022 at 15:51, Richard Sandiford
wrote:
>
> Sorry for the slow reply. I wrote a response a couple of weeks ago
> but I think it get lost in a machine outage.
>
> Prathamesh Kulkarni writes:
> > Hi,
> > The attached prototype patch extends fold_vec_perm to fold VEC_PERM_EXPR
> >
On 08/09/2022 21:38, Kwok Cheung Yeung wrote:
Hello
This patch adds support for some additional floating-point operations,
in scalar and vector modes, which are natively supported by the AMD GCN
instruction set, but haven't been implemented in GCC yet. With the
exception of frexp, these
Pushed to wwwdocs.
---
htdocs/gcc-12/changes.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index c6dae27a..2cb5a654 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -988,7 +988,7 @@
On 09.09.22 10:10, Andrew Stubbs wrote:
On 08.09.22 22:38, Kwok Cheung Yeung wrote:
The instructions for the transcendental functions are documented to have
limited numerical precision, so they are only used if unsafe_math_optimizations
are enabled for now.
-funsafe-math-optimizations implies
This fixes f19a327077e ("Support -fexcess-precision=16 which will enable
FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16 when backend supports _Float16.") on
RISC-V targets.
gcc/ChangeLog
PR target/106815
* config/riscv/riscv.cc (riscv_excess_precision): Add support
for
I just happened to stuble on this one while trying to sort out the
RISC-V bits.
gcc/ChangeLog
* doc/tm.texi (TARGET_C_EXCESS_PRECISION): Add 16.
---
gcc/doc/tm.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index
This adjusts simple_control_dep_chain in the same way I adjusted
compute_control_dep_chain_pdom to avoid adding fallthru edges to
the predicate chain.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/106881
* gimple-predicate-analysis.cc
LGTM, seems like you have landed now, see you soon :)
On Fri, Sep 9, 2022 at 5:44 PM Palmer Dabbelt wrote:
>
> This fixes f19a327077e ("Support -fexcess-precision=16 which will enable
> FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16 when backend supports _Float16.") on
> RISC-V targets.
>
> gcc/ChangeLog
>
Hi Andreas:
Hm, I should change my default gcc on Ubuntu, I didn't got this
when build with GCC 7, and can be reproduced by GCC 11,
Will summit patch once I test done.
On Fri, Sep 9, 2022 at 3:21 PM Andreas Schwab wrote:
>
> How did you test that?
>
>
On Wed, Aug 31, 2022 at 12:56:25PM +0200, Marcel Vollweiler wrote:
> + case PARSE_BIND:
> + *(char *) (host_envvars[omp_var].dest[0])
> + = *(char *) params[0];
> + *(char *) (host_envvars[omp_var].dest[1])
> + = *(char *) params[1];
> +
On 9/8/22 17:52, Gaius Mulley wrote:
> Martin Liška writes:
>
>> Note I've just converted the current Modula-2 manual to RST (Sphinx):
>> https://splichal.eu/scripts/sphinx/
>>
>> It contains some minor issues, but in general it should be pretty fine. Note
>> pygments
>> contains a
On 09.09.22 12:16, Richard Biener wrote:
On Fri, 9 Sep 2022, Tobias Burnus wrote:
-funsafe-math-optimizations implies -fno-signed-zeros, -fno-trapping-math,
-fassociative-math,
and -freciprocal-math. All of them reduce precision and my violate IEEE or
ISO/language standards.
However, I think
When predictive commoning builds a reference for iteration N it
prematurely associates a constant offset into the MEM_REF offset
operand which can be invalid if the base pointer then points
outside of an object which alias-analysis does not consider valid.
Bootstrapped and tested on
On 09/09/2022 13:20, Tobias Burnus wrote:
However, the pre-existing 'sqrt' problem still is real. It also applies
to reverse sqrt ("v_rsq"), but that's for whatever reason not used for GCN.
This patch now adds a commandline flag - off by default - to choose
whether this behavior is wanted. I
PR/95720
When the status wrapper is used, the gluefile need to be prefixed with
-Wl, in order for the test cases to have the dump files with the
expected names.
gcc/testsuite/ChangeLog:
* gcc/testsuite/lib/g++.exp: Moved gluefile block to after
flags have been prefixed for the
On 9/9/22 12:27, Torbjörn SVENSSON wrote:
> When testing a cross toolchain outside the build tree, the binary name
> for gcov is prefixed with the tripplet.
Ok, thanks!
Martin
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/gcov/gcov.exp: Respect tripplet when looking for gcov
> *
Hi Torbjörn,
> When testing a cross toolchain outside the build tree, the binary name
> for gcov is prefixed with the tripplet.
here and below: the beast is called triplet.
> gcc/testsuite/ChangeLog:
>
> * g++.dg/gcov/gcov.exp: Respect tripplet when looking for gcov
> *
> -Original Message-
> I agree - for example powerpc has -mrecip= to control which instructions
> to use (float/double rsqrt or inverse) and -mrecip-precision to
> specify whether further iteration is done or not.
>
> x86 has similar but does always perform newton raphson iteration,
>
Each of the following functions
instantiate_non_dependent_expr
get_target_expr
require_complete_type
abstract_virtuals_error
cxx_constant_value
is (presumably for historical reasons) just a non-SFINAE-enabled wrapper
for the corresponding SFINAE-enabled version that's suffixed by
When testing a cross toolchain outside the build tree, the binary name
for gcov is prefixed with the triplet.
gcc/testsuite/ChangeLog:
* g++.dg/gcov/gcov.exp: Respect triplet when looking for gcov.
* gcc.misc-tests/gcov.exp: Likewise.
Signed-off-by: Torbjörn SVENSSON
---
On Tue, Aug 09, 2022 at 02:23:50PM +0100, Andrew Stubbs wrote:
>
> There has been support for generating "inbranch" SIMD clones for a long time,
> but nothing actually uses them (as far as I can see).
Thanks for working on this.
Note, there is another case where the inbranch SIMD clones could
71 matches
Mail list logo
