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/
> * ginclude/stddef
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 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 LTO.
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 imple
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 @@ funct
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 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 (mv
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 EXCESS_PRECISIO
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 858bfb80cec..75
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 (simple_co
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?
>
> ../../gcc/common/config/riscv/riscv-com
../../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 %<-march=%s%>/%<
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 chu
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 missi
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 enable
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
---
gcc/te
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
> * gc
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];
> + *(u
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
> * gcc.misc-
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 corresponding
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 it
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 x86_64-unknown
> -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,
> docu
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 d
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 '_sfin
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
---
gcc/te
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 t
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, cv-qua
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 sur
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
> > in
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 be
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)"
> https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598662.ht
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
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 d
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 - m
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 v
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 i
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. p
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
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.
---
libst
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 in
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 +-
.../testsuite/std/
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 i
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:
> https://gcc
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, 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
>
> libstd
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 (test
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 (views::_ZipTransfo
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
/var/gcc/regression/master
> 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
> x86_64-apple-darwin11.4.2):
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 te
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, 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 attempt
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 x86_64-pc-linux-gnu
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", refe
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
---
.../gcc.dg/analyzer/flexible-array-membe
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 funct
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 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 Darwi
> 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 o
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 constructo
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 argument
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:
>
> * config/xtensa/xtensa.md
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 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 ar
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) __vecto
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
> ---
> gcc/te
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 -
On Linux/x86_64,
9f2fca56593a2b87026b399d26adcdca90705685 is the first bad commit
commit 9f2fca56593a2b87026b399d26adcdca90705685
Author: Marcel Vollweiler
Date: Thu Sep 8 10:01:33 2022 -0700
OpenMP, libgomp: Environment variable syntax extension
caused
FAIL: libgomp.c/affinity-2.c execu
On Linux/x86_64,
157236dbd621644b3cec50b6cf38811959f3e78c is the first bad commit
commit 157236dbd621644b3cec50b6cf38811959f3e78c
Author: Thomas Rodgers
Date: Thu Aug 25 12:11:40 2022 +0200
libstdc++: Clear padding bits in atomic compare_exchange
caused
FAIL: 29_atomics/atomic_ref/compar
72 matches
Mail list logo
