Hi!
My recent change to enable _Float{16,32,64,128,32x,64x,128x} for C++
apparently broke bootstrap on some Debian/Ubuntu setups.
Those multiarch targets put some headers into
/usr/include/x86_64-linux-gnu/bits/ etc. subdirectory instead of
/usr/include/bits/.
This is handled by
/* /usr/includ
On Tue, Sep 27, 2022 at 3:59 PM Robin Dapp wrote:
>
> > Yes, because the native_interpret always starts at offset zero
> > (we can't easily feed in a "shifted" RHS). So what I assumed is
> > that IFN_LEN_STORE always stores elements [0, len + adj].
>
> Hmm, but this assumption is not violated her
On Tue, Sep 27, 2022 at 9:54 PM Jeff Law wrote:
>
>
> This is another minor improvement to coremark. I suspect this only
> improves code size as the load-immediate was likely issuing with the ret
> statement on multi-issue machines.
>
>
> Basically we're failing to utilize conditional equivalenc
On Wed, Sep 28, 2022 at 5:06 PM Andrew Stubbs wrote:
>
> This patch is a prerequisite for some amdgcn patches I'm working on to
> support shorter vector lengths (having fixed 64 lanes tends to miss
> optimizations, and masking is not supported everywhere yet).
>
> The problem is that, unlike AArch
On Wed, Sep 28, 2022 at 7:32 PM Andre Vieira (lists) via Gcc-patches
wrote:
>
> Made the change and also created the ChangeLogs.
OK if bootstrap / testing succeeds.
Thanks,
Richard.
> gcc/ChangeLog:
>
> * tree-if-conv.cc (if_convertible_loop_p_1): Move ordering of
> loop bb's from here
Hi Kewen,
thanks for looking at this!
(I suspect it would also affect a 32b linux host with a 64b multilib)
quite likely powerpc-darwin is the only 32b ppc host in regular testing.
> On 29 Sep 2022, at 06:45, Kewen.Lin via Gcc-patches
> wrote:
>
> on 2022/9/29 03:09, Iain Sandoe wrote:
>> Hi
On Tue, Sep 27, 2022 at 5:48 PM Jeff Law via Gcc-patches
wrote:
>
>
> On 8/22/22 00:16, Richard Biener via Gcc-patches wrote:
> > The following fixes PR105646, not diagnosing
> >
> > int f1();
> > int f3(){
> > auto const & a = f1();
> > bool v3{v3};
> > return a;
> > }
> >
> > with
On Thu, 29 Sep 2022, Jakub Jelinek wrote:
> Hi!
>
> My recent change to enable _Float{16,32,64,128,32x,64x,128x} for C++
> apparently broke bootstrap on some Debian/Ubuntu setups.
> Those multiarch targets put some headers into
> /usr/include/x86_64-linux-gnu/bits/ etc. subdirectory instead of
>
From: Piotr Trojanek
When collecting package state declared in package body, we should only
recursively examine the visible part of nested packages while ignoring other
entities related to packages (e.g. package bodies or package renamings).
gcc/ada/
* sem_util.adb (Collect_Visible_Stat
From: Bob Duff
This patch improves the efficiency of slice assignment when the left- or
right-hand side is a slice of a component or a slice of a slice.
Previously, the optimization was disabled in these cases, just in
case there might be a volatile or independent component lurking.
Now we explic
From: Eric Botcazou
The original extended return statement is mandatory for functions whose
result type is limited in Ada 2005 and later.
gcc/ada/
* contracts.adb (Build_Subprogram_Contract_Wrapper): Put back the
extended return statement if the result type is built-in-place.
From: Ronan Desplanques
A documentation section was duplicated by mistake in r0-110752.
This commit removes the copy that was added by r0-110752, but
integrates the small editorial change that it brought to the
original.
gcc/ada/
* einfo.ads: remove documentation duplicate
Tested on x8
Hi Iain,
Thanks again for your help!!
on 2022/9/29 16:16, Iain Sandoe wrote:
> Hi Kewen,
>
> thanks for looking at this!
> (I suspect it would also affect a 32b linux host with a 64b multilib)
>
Quite reasonable suspicion.
> quite likely powerpc-darwin is the only 32b ppc host in regular test
On 29.09.22 09:06, Jakub Jelinek wrote:
My recent change to enable _Float{16,32,64,128,32x,64x,128x} for C++
apparently broke bootstrap on some Debian/Ubuntu setups.
Those multiarch targets put some headers into
/usr/include/x86_64-linux-gnu/bits/ etc. subdirectory instead of
/usr/include/bits/.
Richard Biener via Gcc-patches writes:
> On Wed, Sep 28, 2022 at 5:06 PM Andrew Stubbs wrote:
>>
>> This patch is a prerequisite for some amdgcn patches I'm working on to
>> support shorter vector lengths (having fixed 64 lanes tends to miss
>> optimizations, and masking is not supported everywhe
Jeff Law writes:
> On 9/28/22 09:04, Richard Sandiford wrote:
>> Tamar Christina writes:
Maybe the target could use (subreg:SI (reg:BI ...)) as argument. Heh.
>>> But then I'd still need to change the expansion code. I suppose this could
>>> prevent the issue with changes to code on other ta
On Thu, Sep 29, 2022 at 11:24 AM Richard Sandiford
wrote:
>
> Richard Biener via Gcc-patches writes:
> > On Wed, Sep 28, 2022 at 5:06 PM Andrew Stubbs wrote:
> >>
> >> This patch is a prerequisite for some amdgcn patches I'm working on to
> >> support shorter vector lengths (having fixed 64 lane
No, this is not RVV wanted.
There is the example that how RVV uses length and mask:
for (int i = 0; i < n; i++)
if (cond[i] == 0)
a[i] = b[i] + c[i];
The gimple IR should be this:
AVL = #number of element to be updated.
TVL = #number of total element to be updated
vect_0 = vector of cond[i
On Thu, 29 Sep 2022, Richard Sandiford wrote:
> Jeff Law writes:
> > On 9/28/22 09:04, Richard Sandiford wrote:
> >> Tamar Christina writes:
> Maybe the target could use (subreg:SI (reg:BI ...)) as argument. Heh.
> >>> But then I'd still need to change the expansion code. I suppose this cou
On 29/09/2022 08:52, Richard Biener wrote:
On Wed, Sep 28, 2022 at 5:06 PM Andrew Stubbs wrote:
This patch is a prerequisite for some amdgcn patches I'm working on to
support shorter vector lengths (having fixed 64 lanes tends to miss
optimizations, and masking is not supported everywhere yet)
On 29/09/2022 10:24, Richard Sandiford wrote:
Otherwise:
operand0[0] = operand1 < operand2;
for (i = 1; i < operand3; i++)
operand0[i] = operand0[i - 1] && (operand1 + i < operand2);
looks like a "length and mask" operation, which IIUC is also what
RVV wanted? (Wasn't at the Cauldro
Hi!
The following testcase ICEs on x86 as well as ppc64le (the latter
with -mabi=ieeelongdouble), because _Float64x there isn't mangled as
DF64x but e or u9__ieee128 instead.
Those are the mangling that should be used for the non-standard
types with the same mode or for long double, but not for _F
Andrew Stubbs writes:
> On 29/09/2022 10:24, Richard Sandiford wrote:
>> Otherwise:
>>
>>operand0[0] = operand1 < operand2;
>>for (i = 1; i < operand3; i++)
>> operand0[i] = operand0[i - 1] && (operand1 + i < operand2);
>>
>> looks like a "length and mask" operation, which IIUC is a
> -Original Message-
> From: Richard Biener
> Sent: Thursday, September 29, 2022 10:41 AM
> To: Richard Sandiford
> Cc: Jeff Law ; Tamar Christina
> ; gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional
> branches, give hint if argument is a
Sending V2 where I included new -gz=zstd option value.
Cheers,
MartinFrom 770ba230b34f698ec477dcef7ad207ab4e6be557 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Thu, 22 Sep 2022 15:03:34 +0200
Subject: [PATCH] changes: mentioned ignore -gz=zlib-gnu option
---
htdocs/gcc-13/changes.html | 5
On Wed, 28 Sep 2022 16:44:29 -0400
Nathan Sidwell via Gcc-patches wrote:
> + else if (TREE_CODE (arg) == VAR_DECL && DECL_NTTP_OBJECT_P (arg))
Cosmetics, but I think the first part of the condition could be spelled
as VAR_P (arg)
thanks,
This series of patches supposedly cleans up the definition of
the AArch64 ISA features. The main aims are:
- to make the naming more consistent
- to reduce the amount of boilerplate needed
- to avoid the need to maintain transitive closures by hand
- to enforce a sensible (topological) order on t
All AARCH64_ISA_* architecture-level macros except AARCH64_ISA_V8_R
are for the A profile: they cause __ARM_ARCH_PROFILE to be set to
'A' and they are associated with architecture names like armv8.4-a.
It's convenient for later patches if we make this explicit
by adding an "A" to the name. Also,
Following on from the previous AARCH64_ISA patch, this one adds the
profile name directly to the end of architecture-level AARCH64_FL_*
macros.
gcc/
* config/aarch64/aarch64.h (AARCH64_FL_V8_1, AARCH64_FL_V8_2)
(AARCH64_FL_V8_3, AARCH64_FL_V8_4, AARCH64_FL_V8_5, AARCH64_FL_V8_6)
This patch completes the renaming of architecture-level related
things by adding "V" to the name of the architecture in
aarch64-arches.def. Since the "V" is predictable, we can easily
drop it when we don't need it (as when matching /proc/cpuinfo).
Having a valid C identifier is necessary for late
This patch renames AARCH64_FL_FOR_ARCH* macros to follow the
same V names that we (now) use elsewhere.
The names are only temporary -- a later patch will move the
information to the .def file instead. However, it helps with
the sequencing to do this first.
gcc/
* config/aarch64/aarch64.h
The aarch64-option-extensions.def parsing in config.gcc had
some code left over from when it tried to parse the whole
macro definition. Also, config.gcc now only looks at the
first fields of the aarch64-arches.def entries.
gcc/
* config.gcc: Remove dead aarch64-option-extensions.def code.
AARCH64_FL_RCPC8_4 is an odd-one-out in that it has no associated
entry in aarch64-option-extensions.def. This means that, although
it is internally separated from AARCH64_FL_V8_4A, there is no
mechanism for turning it on and off individually, independently
of armv8.4-a.
The only place that the f
The flags fields of the aarch64-cores.def always start with
AARCH64_FL_FOR_. After previous changes, is always
identical to the previous field, so we can drop the explicit
AARCH64_FL_FOR_ and derive it programmatically.
This isn't a big saving in itself, but it helps with later patches.
gcc/
aarch64-option-extensions.def was topologically sorted except
for one case: crypto came before its aes and sha2 dependencies.
This patch moves crypto after sha2 instead.
gcc/
* config/aarch64/aarch64-option-extensions.def: Move crypto
after sha2.
gcc/testsuite/
* gcc.targe
Just a minor patch to avoid having to construct std::strings
in static data.
gcc/
* common/config/aarch64/aarch64-common.cc (processor_name_to_arch)
(arch_to_arch_name): Use const char * instead of std::string.
---
gcc/common/config/aarch64/aarch64-common.cc | 4 ++--
1 file chang
aarch64-option-extensions.def requires us to maintain the transitive
closure of options by hand. This patch fixes a few cases where a
flag was missed.
+noaes and +nosha2 now disable +crypto, which IMO makes more
sense and is consistent with the Clang behaviour.
gcc/
* config/aarch64/aarc
After previous changes, it's more convenient if the flags_on and
flags_off fields of all_extensions include the feature flag itself.
gcc/
* common/config/aarch64/aarch64-common.cc (all_extensions):
Include the feature flag in flags_on and flags_off.
(aarch64_parse_extension
Currently the aarch64-option-extensions.def entries, the
aarch64-cores.def entries, and the AARCH64_FL_FOR_* macros
have a transitive closure of dependencies that is maintained by hand.
This is a bit error-prone and is becoming less tenable as more features
are added. The main point of this patch
A previous patch added a aarch64_feature_flags typedef, to abstract
the representation of the feature flags. This patch makes existing
code use the typedef too. Hope I've caught them all!
gcc/
* common/config/aarch64/aarch64-common.cc: Use aarch64_feature_flags
for feature flags
-mgeneral-regs-only is effectively "+nofp for the compiler without
changing the assembler's ISA flags". Currently that's implemented
by making TARGET_FLOAT, TARGET_SIMD and TARGET_SVE depend on
!TARGET_GENERAL_REGS_ONLY and then making any feature that needs FP
registers depend (directly or indire
aarch64-common.cc has two arrays, one maintaining the original
definition order and one sorted by population count. Sorting
by population count was a way of ensuring topological ordering,
taking advantage of the fact that the entries are partially
ordered by the subset relation. However, the sort
Some of the option structures have all-const member variables.
That doesn't seem necessary: we can just use const on the objects
that are supposed to be read-only.
Also, with the new, more C++-heavy option handling, it seems
better to use constexpr for the static data, to make sure that
we're not
After previous patches, it's possible to remove TARGET_*
options that are redundant due to (IMO) obvious dependencies.
gcc/
* config/aarch64/aarch64.h (TARGET_CRYPTO, TARGET_SHA3, TARGET_SM4)
(TARGET_DOTPROD): Don't depend on TARGET_SIMD.
(TARGET_AES, TARGET_SHA2): Likewise
dr_may_alias_p rightly used poly_int_tree_p to guard a use of
ranges_maybe_overlap_p, but used the non-poly extractors.
This caused a few failures in the SVE ACLE asm tests.
Tested on aarch64-linux-gnu and x86_64-linux-gnu. Pushed as obvious.
Richard
gcc/
* tree-data-ref.cc (dr_may_ali
From: Ju-Zhe Zhong
gcc/ChangeLog:
* tree-vect-loop.cc (vect_phi_first_order_recurrence_p): New function.
(vect_analyze_scalar_cycles_1): Classify first-order recurrence phi.
(vect_analyze_loop_operations): Add first-order recurrence
autovectorization support.
(ve
> Am 29.09.2022 um 12:23 schrieb Tamar Christina via Gcc-patches
> :
>
>
>>
>> -Original Message-
>> From: Richard Biener
>> Sent: Thursday, September 29, 2022 10:41 AM
>> To: Richard Sandiford
>> Cc: Jeff Law ; Tamar Christina
>> ; gcc-patches@gcc.gnu.org; nd
>> Subject: Re: [PA
> On 8/5/22 05:41, Jose E. Marchesi via Gcc-patches wrote:
>> [Changes from V1:
>> - Added a test.]
>>
>> It is common for C BPF programs to use variables that are implicitly
>> set by the BPF loader and run-time. It is also necessary for these
>> variables to be stored in read-only storage so t
This adds smarts to the module machinery to handle NTTP object
VAR_DECLs. Like typeinfo objects, these must be ignored in the symbol
table, streamed specially and recreated on stream in.
Patrick, thanks for the testcase, I don't know how to attribute that to
you in the changelog anymore.
nat
This fixes libstdc++ for Clang and other non-GCC compilers.
Tested powerpc64le-linux. Pushed to trunk as r13-2954-gdf7f2736509cfe.
-- >8 --
I forgot that non-GCC compilers don't have this built-in yet.
For Clang we could do something like the check below (as described in
P2255), but for now I'm
On Wed, 28 Sep 2022 17:17:30 +0200
Tobias Burnus wrote:
> On 28.09.22 15:20, Julian Brown wrote:
>
> This patch fixes an ICE when both a complete struct variable and
> components of that struct are mapped on the same directive for
> OpenACC, using a modified version of the scheme used for OpenMP
On 29.09.22 14:59, Julian Brown wrote:
On Wed, 28 Sep 2022 17:17:30 +0200 Tobias Burnus
wrote:
I don't see immediately whether some cases can still reach
omp_accumulate_sibling_list – if so, a testcase would be nice, or
whether that error_at can now be removed.
This version of the patch remov
Hello,
We have, in vxworks.h:
/* linux64.h enables this, not supported in vxWorks. */
#undef TARGET_FLOAT128_ENABLE_TYPE
#define TARGET_FLOAT128_ENABLE_TYPE 0
We inherit linux64.h for a few reasons, but don't really support
float128 for vxworks, so the setting made sense.
Many tests rely
Hello,
This makes good sense in general anyway, and in particular
with forthcoming support for shared shared libraries, which will
work for mrtp alone but not yet for mrtp+mcmodel=large.
We have been using this in gcc-11 based development toolchains
for a while.
Committing to mainline.
Regards,
On Thu, Sep 29, 2022 at 12:17 PM Richard Sandiford
wrote:
>
> Andrew Stubbs writes:
> > On 29/09/2022 10:24, Richard Sandiford wrote:
> >> Otherwise:
> >>
> >>operand0[0] = operand1 < operand2;
> >>for (i = 1; i < operand3; i++)
> >> operand0[i] = operand0[i - 1] && (operand1 + i < o
Hello,
This adjusts vx-common.h to #define DWARF2_UNWIND_INFO to 0
when ARM_UNWIND_INFO is set, preventing defaults.h from
possibly setting DWARF2_UNWIND_INFO to 1 (as well) on its own
afterwards if the macro isn't defined.
We have been using this for a while in gcc-11 development
toolchains for
On Thu, Sep 29, 2022 at 1:07 PM wrote:
>
> From: Ju-Zhe Zhong
>
> gcc/ChangeLog:
>
> * tree-vect-loop.cc (vect_phi_first_order_recurrence_p): New function.
> (vect_analyze_scalar_cycles_1): Classify first-order recurrence phi.
> (vect_analyze_loop_operations): Add first-or
Hi Torbjörn,
On 9/23/22 10:43, Torbjörn SVENSSON via Gcc-patches wrote:
The cmse-15.c testcase fails at -Os because ICF means that we
generate
secure3:
b secure1
which is OK, but does not match the currently expected
secure3:
...
bx r[0-3]
gcc/testsuite/ChangeLog:
From: Sören Tempel
On glibc-based systems, off_t is a 32-bit type on 32-bit systems and a
64-bit type on 64-bit systems by default. However, on systems using musl
libc off_t is unconditionally a 64-bit type. As such, it is insufficient
to use a uintptr type for the mmap offset parameter.
Present
This was found when testing buildroot with linuxthreads enabled. In
this case, the build passes --disable-tls to the toolchain during
configuration. After building the OpenRISC toolchain it was still
generating TLS code sequences and causing linker failures such as:
/or1k-buildroot-linux-uc
These two tests have hardcoded q0 as destination/source of load/store
instructions, but it is actually used only under
-mfloat-abi=hard. When using -mfloat-abi=softfp, other registers
(eg. q3) can be used to transfer function arguments from core
registers to MVE registers, making the expected regex
Hi Christophe,
> -Original Message-
> From: Christophe Lyon
> Sent: Thursday, September 29, 2022 3:57 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Andre Simoes Dias Vieira
> ; Christophe Lyon
>
> Subject: [PATCH] testsuite: [arm] Relax expected register names in MVE tests
>
>
Adding a new builtin trait currently involves some boilerplate (as can
be seen in r13-2956-g9ca147154074a0) of defining corresponding RID_ and
CPTK_ enumerators and adding them to various switch statements across
many files. The exact switch statements we need to change is determined
by whether th
Hello,
This change simply adds a comment in vxworks.h, describing
our expectations wrt our use of HAVE_INITFINI_ARRAY_SUPPORT
from this header.
Committing to mainline shortly.
Cheers,
Olivier
2022-09-29 Olivier Hainque
gcc/
* config/vxworks.h: Add comment on our use of
HAVE
On Thu, 29 Sep 2022, Patrick Palka wrote:
> Adding a new builtin trait currently involves some boilerplate (as can
> be seen in r13-2956-g9ca147154074a0) of defining corresponding RID_ and
> CPTK_ enumerators and adding them to various switch statements across
> many files. The exact switch state
On 9/29/22 17:01, Kyrylo Tkachov wrote:
Hi Christophe,
-Original Message-
From: Christophe Lyon
Sent: Thursday, September 29, 2022 3:57 PM
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov ; Andre Simoes Dias Vieira
; Christophe Lyon
Subject: [PATCH] testsuite: [arm] Relax expected re
> -Original Message-
> From: Christophe Lyon
> Sent: Thursday, September 29, 2022 4:24 PM
> To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
> Cc: Andre Simoes Dias Vieira
> Subject: Re: [PATCH] testsuite: [arm] Relax expected register names in MVE
> tests
>
>
>
> On 9/29/22 17:01, Kyryl
Kyrylo Tkachov writes:
> Hi Andrea,
[...]
> diff --git a/gcc/config/arm/aarch-bti-insert.cc
> b/gcc/config/arm/aarch-bti-insert.cc
> index 2d1d2e334a9..8f045c247bf 100644
> --- a/gcc/config/arm/aarch-bti-insert.cc
> +++ b/gcc/config/arm/aarch-bti-insert.cc
> @@ -41,6 +41,7 @@
> #include "cfgr
Hi!
Here is more complete patch to add std::bfloat16_t support on
x86, AArch64 and (only partially) on ARM 32-bit. No BFmode optabs
are added by the patch, so for binops/unops it extends to SFmode
first and then truncates back to BFmode.
For {HF,SF,DF,XF,TF}mode -> BFmode conversions libgcc has i
Hello,
Preparing a set of changes to support shared libs for VxWorks (again),
this patch makes sure that shared libraries for this family of targets
are only built on explicit request, when configured with --enable-shared
(by passing down --disable-shared to subdirs otherwise).
This provides us w
Hi Kewen,
> On 29 Sep 2022, at 10:12, Kewen.Lin via Gcc-patches
> wrote:
> on 2022/9/29 16:16, Iain Sandoe wrote:
>>>
>>> I'm testing the attached diff which can be applied on top of the previous
>>> proposed patch
>>> on ppc64 and ppc64le, could you help to test it can fix the issue?
>>
>>
On 27/09/2022 14:16, Tobias Burnus wrote:
@@ -422,6 +428,12 @@ struct agent_info
if it has been. */
bool initialized;
+ /* Flag whether the HSA program that consists of all the modules has been
+ finalized. */
+ bool prog_finalized;
+ /* Flag whether the HSA OpenMP's requires
I've committed this small clean up. It silences a warning.
Andrewamdgcn: remove unused variable
This was left over from a previous version of the SIMD clone patch.
gcc/ChangeLog:
* config/gcn/gcn.cc (gcn_simd_clone_compute_vecsize_and_simdlen):
Remove unused elt_bits variable.
On Mon, 26 Sep 2022, Lulu Cheng wrote:
> +GTM_longjmp:
> +cfi_startproc
> +GPR_L $s0, $r5, 3*SZ_GPR
> +GPR_L $s1, $r5, 4*SZ_GPR
> +GPR_L $s2, $r5, 5*SZ_GPR
> +GPR_L $s3, $r5, 6*SZ_GPR
> +GPR_L $s4, $r5, 7*SZ_GPR
> +GPR_L $s5, $r5, 8*SZ_
Hello,
This change prepares the ground prior to the reintroduction of
shared libs support for VxWorks.
On this platform, the use of shared libraries involves unusual
steps compared to standard native systems and enforcing static
links by default improves user experience.
This change arranges for
Thanks for posting the patch.
juzhe.zh...@rivai.ai writes:
> From: Ju-Zhe Zhong
>
> gcc/ChangeLog:
>
> * tree-vect-loop.cc (vect_phi_first_order_recurrence_p): New function.
> (vect_analyze_scalar_cycles_1): Classify first-order recurrence phi.
> (vect_analyze_loop_operati
Hi!
On Thu, Sep 29, 2022 at 09:16:33AM +0100, Iain Sandoe wrote:
> OK. So one small wrinkle,
>
> Darwin already has
>
> if (TARGET_64BIT && ! TARGET_POWERPC64)
> {
> rs6000_isa_flags |= OPTION_MASK_POWERPC64;
> warning (0, "%qs requires PowerPC64 architecture, enabling", "-m6
On Thu, Sep 29, 2022 at 01:45:16PM +0800, Kewen.Lin wrote:
> I found this flag is mainly related to tune setting and spotted that we have
> some code
> for tune setting when no explicit cpu is given.
>
> ...
>
> else
> {
> size_t i;
> enum processor_type tune_proc
> = (T
On Thu, Sep 29, 2022 at 12:04:05AM +0100, Iain Sandoe wrote:
> > On 28 Sep 2022, at 22:30, Segher Boessenkool
> > wrote:
> > That works on Linux as well. What still does not work is user-mode
> > context switches in 32-bit processes (so setjmp and getcontext stuff).
>
> AFAIU the Darwin impl. i
On Thu, Sep 29, 2022 at 12:16:38AM +0100, Iain Sandoe wrote:
> > On 29 Sep 2022, at 00:04, Iain Sandoe wrote:
> > adding —with-tune=G5 to the configure line .. the cross-build then succeeded
> > (at "-O1 -g" as I was building to debug) - maybe that will provide a clue,
> > but I’m
> > out of time
When running the DejaGNU testsuite on a toolchain built for native
Windows, the path /dev/null can't be used to open a stream to void.
On native Windows, the resource is instead named "nul".
The error would look like this:
c:/arm-11.3.rel1/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-e
This introduces an ICE building libgcc for ia64-linux-gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107088
https://sourceware.org/pipermail/libc-testresults/2022q3/010294.html
--
Joseph S. Myers
jos...@codesourcery.com
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
When the sides of ?: are class prvalues, we wrap the COND_EXPR in a
TARGET_EXPR so that both sides will initialize the same temporary. But in
this case we were stripping the outer TARGET_EXPR and conditionally creating
different temporaries
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
When the gimplifier encounters the same TARGET_EXPR twice, it evaluates
TARGET_EXPR_INITIAL the first time and clears it so that the later
evaluation is just the temporary. With this testcase, using the extension
to treat an omitted middle
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
We were overlooking non-potentially-constant bits in variable initializer
because we didn't walk into DECL_INITIAL.
gcc/cp/ChangeLog:
* constexpr.cc (potential_constant_expression_1): Look into
DECL_INITIAL. Use location w
On Thu, Sep 29, 2022 at 11:05:04AM -0400, Patrick Palka via Gcc-patches wrote:
> Adding a new builtin trait currently involves some boilerplate (as can
> be seen in r13-2956-g9ca147154074a0) of defining corresponding RID_ and
> CPTK_ enumerators and adding them to various switch statements across
>
Hello,
This change augments the comment attached to the use of auto-host.h
in vxcrtstuff.c to better describe the reason for including it and
for the associated series of #undef directives.
It also augments the comment on dso_handle and removes a redundant
guard on HAVE_INITFINI_ARRAY_SUPPORT for
When the mapper can't be executed, Windows report the error like:
.../bad-mapper-1.C: error: failed CreateProcess mapper 'this-will-not-work'
On Linux, the same error is reported this way:
.../bad-mapper-1.C: error: failed execvp mapper 'this-will-not-work'
This patch allows both output forms to
Hi Segher
> On 29 Sep 2022, at 18:04, Segher Boessenkool
> wrote:
> On Thu, Sep 29, 2022 at 09:16:33AM +0100, Iain Sandoe wrote:
>> OK. So one small wrinkle,
>>
>> Darwin already has
>>
>> if (TARGET_64BIT && ! TARGET_POWERPC64)
>>{
>> rs6000_isa_flags |= OPTION_MASK_POWERPC64;
>>
Hi Segher
> On 29 Sep 2022, at 18:18, Segher Boessenkool
> wrote:
>
> On Thu, Sep 29, 2022 at 12:04:05AM +0100, Iain Sandoe wrote:
>>> On 28 Sep 2022, at 22:30, Segher Boessenkool
>>> wrote:
>>> That works on Linux as well. What still does not work is user-mode
>>> context switches in 32-bit
Hi!
On Thu, Sep 29, 2022 at 07:25:44PM +0100, Iain Sandoe wrote:
> > On 29 Sep 2022, at 18:04, Segher Boessenkool
> > wrote:
> > On Thu, Sep 29, 2022 at 09:16:33AM +0100, Iain Sandoe wrote:
> >> Which means that we do not report an error, but a warning, and then we
> >> force 64b on (taking
> >
On Thu, Sep 29, 2022 at 07:33:14PM +0100, Iain Sandoe wrote:
> > On 29 Sep 2022, at 18:18, Segher Boessenkool
> > wrote:
> > On Thu, Sep 29, 2022 at 12:04:05AM +0100, Iain Sandoe wrote:
> >>> On 28 Sep 2022, at 22:30, Segher Boessenkool
> >>> wrote:
> >>> That works on Linux as well. What stil
On Thu, 29 Sep 2022, Marek Polacek wrote:
> On Thu, Sep 29, 2022 at 11:05:04AM -0400, Patrick Palka via Gcc-patches wrote:
> > Adding a new builtin trait currently involves some boilerplate (as can
> > be seen in r13-2956-g9ca147154074a0) of defining corresponding RID_ and
> > CPTK_ enumerators an
Hi!
On Thu, Sep 29, 2022 at 02:16:04PM +0800, Kewen.Lin wrote:
> >> +/* { dg-error "'-m64' requires a PowerPC64 cpu" "PR106680" { target
> >> powerpc*-*-linux* powerpc-*-rtems* } 0 } */
> >
> > Everything except AIX even? So it will include Darwin as well (and the
> > BSDs, and powerpc*-elf, et
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
cxx20_pair is trivially copyable because it has a trivial copy constructor
and only a deleted copy assignment operator; the non-triviality of the
unsatisfied copy assignment overload is not considered.
gcc/cp/ChangeLog:
* class.cc
On Thu, 29 Sep 2022, Nathan Sidwell wrote:
>
> This adds smarts to the module machinery to handle NTTP object
> VAR_DECLs. Like typeinfo objects, these must be ignored in the symbol
> table, streamed specially and recreated on stream in.
>
> Patrick, thanks for the testcase, I don't know how to
On Thu, Sep 29, 2022 at 3:28 AM Martin Liška wrote:
> Sending V2 where I included new -gz=zstd option value.
>
> Cheers,
> Martin
At some point binutils will want to remove
--compress-debug-sections=zlib-gnu support as well.
I think the message can drop mentioning of
--compress-debug-sections=z
Hi!
On Wed, Aug 24, 2022 at 04:17:07PM +0800, Kewen.Lin wrote:
> --- a/gcc/config/rs6000/rs6000.cc
> +++ b/gcc/config/rs6000/rs6000.cc
> @@ -14771,18 +14771,9 @@ rs6000_print_patchable_function_entry (FILE *file,
> unsigned HOST_WIDE_INT patch_area_size,
>
On 9/27/22 09:12, Andrea Corallo via Gcc-patches wrote:
Hi all
this is to address PR 99723.
In the PR GCC crashes as the initialization of common trees is not
performed as no compilation is happening, this is because we raise an
error earlier while processing the arch flags.
This patch chang
On 9/29/22 03:37, Richard Sandiford wrote:
Jeff Law writes:
On 9/28/22 09:04, Richard Sandiford wrote:
Tamar Christina writes:
Maybe the target could use (subreg:SI (reg:BI ...)) as argument. Heh.
But then I'd still need to change the expansion code. I suppose this could
prevent the issue
1 - 100 of 119 matches
Mail list logo
