Hi Jakub,
> This doesn't seem to handle the powerpc* IBM double double long double.
Do we support the IEEE Fortran modules on this target, despite having a
non-IEEE long double? I remember we talked about it when I first implemented
it, but can’t remember what choice we ended up making.
>
On Tue, 25 Jan 2022, Jiufu Guo wrote:
> Richard Biener writes:
>
> > On Tue, 25 Jan 2022, Jiufu Guo wrote:
> >
> >> Jiufu Guo writes:
> >>
> >> > Richard Biener writes:
> >> >
> >> >> On Thu, 13 Jan 2022, Jiufu Guo wrote:
> >> > ...
> >> >>
> >> >>> - /* No need to check sign of the new
Hi!
On 2022-01-24T12:54:27+, Hafiz Abid Qadeer wrote:
> On 24/01/2022 08:45, Tobias Burnus wrote:
>> On 21.01.22 18:15, Thomas Schwinge wrote:
>>> I'm seeing this test case randomly/non-deterministically FAIL to execute,
>>> differently on different systems and runs, for example: [...]
>>>
On Mon, Jan 24, 2022 at 11:26:27PM +0100, Jakub Jelinek via Gcc-patches wrote:
> Yet another short term solution might be not use DW_TAG_base_type
> for the IEEE quad long double, but instead pretend it is a DW_TAG_typedef
> with DW_AT_name "long double" to __float128 DW_TAG_base_type.
> I bet gdb
Dan Li writes:
>>> +
>>> if (flag_stack_usage_info)
>>>current_function_static_stack_size = constant_lower_bound
>>> (frame_size);
>>>
>>> @@ -9066,6 +9089,10 @@ aarch64_expand_epilogue (bool for_sibcall)
>>> RTX_FRAME_RELATED_P (insn) = 1;
>>>}
>>>
>>> +
On 25.01.22 10:19, Thomas Schwinge wrote:
I am trying to figure out if the problem you observed
is a general one or just specific to fortran testcase.
So, unless the '-fsanitize=thread' issues are bogus -- unlikely ;-) -- it
seems a latent issue generally, now fatal with
On Mon, Jan 17, 2022 at 12:11:59AM +0100, FX via Gcc-patches wrote:
> This patch is the third in my “signaling NaN” series. For targets with IEEE
> support but without the issignaling macro in libc (i.e., everywhere except
> glibc), this allows us to provide a fallback implementation. In order
On Mon, Jan 24, 2022 at 06:11:22PM +0100, Florian Weimer via Gcc-patches wrote:
> _dl_find_object returns success even if no unwind information has been
> found, and dlfo_eh_frame is NULL.
>
> libgcc/ChangeLog:
>
> PR libgcc/104207
> * unwind-dw2-fde-dip.c (_Unwind_Find_FDE): Add
When we have a pointer relational compare we have stronger guarantees
about overflow, in particular rewriting BASE0 + STEP0 cmp BASE1 + STEP1
as BASE0 + STEP0 - STEP1 cmp BASE1 is always valid and the new IV0
does not overflow. The patch basically reverts the previous change
when pointers are
Richard Biener writes:
> On Tue, 25 Jan 2022, Jiufu Guo wrote:
>
>> Jiufu Guo writes:
>>
>> > Richard Biener writes:
>> >
>> >> On Thu, 13 Jan 2022, Jiufu Guo wrote:
>> > ...
>> >>
>> >>> - /* No need to check sign of the new step since below code takes
>> >>> care
>> >>> - of
On Mon, Jan 24, 2022 at 11:55 PM Martin Sebor wrote:
>
> The pointer_query algorithm fails when it's unable to determine
> the provenance of an pointer SSA variable. A failure prevents it
> from making a record of the variable in the cache. Although this
> doesn't happen often, one common cause
On Tue, 25 Jan 2022, Richard Biener wrote:
> On Tue, 25 Jan 2022, Jiufu Guo wrote:
>
> > Richard Biener writes:
> >
> > > On Tue, 25 Jan 2022, Jiufu Guo wrote:
> > >
> > >> Jiufu Guo writes:
> > >>
> > >> > Richard Biener writes:
> > >> >
> > >> >> On Thu, 13 Jan 2022, Jiufu Guo wrote:
> >
Add -misa-spec to OPTION_DEFAULT_SPECS to make sure -misa-spec will
always pass that into assembler, that prevent GCC and binutils using
different way to interpret the ISA string.
gcc/ChangeLog:
PR target/104219
* config.gcc (riscv*-*-*): Normalize the with_isa_spec value.
This patch broke bootstrap on AIX. It may have broken Darwin. I have
applied the following patch. AIX doesn't need to distinguish between
different Linux libc implementations.
Bootstrapped on powerpc-ibm-aix7.2.3.0
Thanks, David
aix: AIX is not GLIBC.
A recent patch added tests for
See answers below.
Le lundi 24 janvier 2022 à 18:20 -0500, David Malcolm a écrit :
> On Sat, 2022-01-22 at 19:29 -0500, Antoni Boucher wrote:
> > Hi.
> >
> > Le mardi 18 janvier 2022 à 18:49 -0500, David Malcolm a écrit :
> > > On Mon, 2022-01-17 at 19:46 -0500, Antoni Boucher via Gcc-patches
>
Hi!
On 2021-09-17T01:01:39-0700, Andrew Pinski via Gcc-patches
wrote:
> On Fri, Sep 17, 2021 at 12:46 AM Thomas Schwinge
> wrote:
>> First, I appreciate you working through all these old PRs!
>>
>>
>> On 2021-09-15T13:56:37-0700, apinski--- via Gcc-patches
>> wrote:
>> > The error message is
On Tue, 25 Jan 2022, Patrick Palka wrote:
> Here when attempting to use B's implicitly deleted default constructor,
> mark_used rightfully returns false, but for the wrong reason: it
> tries to instantiate the implicit noexcept specifier, which only
> silently fails because get_defaulted_eh_spec
On Mon, Jan 24, 2022 at 11:35:47PM +0100, AL gcc-patches wrote:
> On Mon, Jan 24, 2022 at 06:24:11PM -0300, Raoni Fassina Firmino wrote:
> > On Mon, Jan 24, 2022 at 02:29:39PM -0600, Bill Schmidt wrote:
> > > Adding the patch author for his information.
> >
> > Thanks Bill.
> >
> > > On 1/24/22
Hi all,
attached patch fixes wrong code generation when broadcasting a derived type
containing allocatable and non-allocatable scalars. Furthermore does it prevent
broadcasting of coarray-tokens, which are always local this_image. Thus having
them on a different image makes no sense.
Here when attempting to use B's implicitly deleted default constructor,
mark_used rightfully returns false, but for the wrong reason: it
tries to instantiate the implicit noexcept specifier, which only
silently fails because get_defaulted_eh_spec suppresses diagnostics
for deleted functions. This
On Tue, Jan 25, 2022 at 01:28:29PM -0300, Raoni Fassina Firmino wrote:
> Below is a patch to do just that. In preliminary tests it seems to work.
> What do you think aboud it Jakub?
Ok for trunk.
> > These days the usual way of doing this is through
> > maybe_expand_insn and
On 1/25/22 06:02, Jakub Jelinek wrote:
On Mon, Jan 24, 2022 at 11:26:27PM +0100, Jakub Jelinek via Gcc-patches wrote:
Yet another short term solution might be not use DW_TAG_base_type
for the IEEE quad long double, but instead pretend it is a DW_TAG_typedef
with DW_AT_name "long double" to
On 1/25/22 12:33, Patrick Palka wrote:
On Tue, 25 Jan 2022, Patrick Palka wrote:
Here when attempting to use B's implicitly deleted default constructor,
mark_used rightfully returns false, but for the wrong reason: it
tries to instantiate the implicit noexcept specifier, which only
silently
Given build_this of a TARGET_EXPR, cp_build_fold_indirect_ref returns the
TARGET_EXPR. But that's the wrong value category for the result of the
defaulted class assignment operator, which returns an lvalue, so we need to
actually build the INDIRECT_REF.
Tested x86_64-pc-linux-gnu, applying to
On Tue, Jan 25, 2022 at 02:24:34PM -0500, Jason Merrill wrote:
> > + machine_mode mode, fmode;
> > + if (TREE_CODE (type) == COMPLEX_TYPE)
> > +mode = TYPE_MODE (TREE_TYPE (type));
> > + else
> > +mode = TYPE_MODE (type);
> > + if (known_eq (GET_MODE_SIZE (mode), 16) &&
Hello
I have backported and committed my metadirective patches onto the
current OpenMP development branch (devel/omp/gcc-11). These are:
f464df13a44b9814341659be631f051377a2ce25 openmp: Add C support for
parsing metadirectives
a238b6934b62ce3e8342047e41840c804d83b59d openmp: Add middle-end
Dear Fortranners,
committed as obvious after regtesting on x86_64-pc-linux-gnu.
We already had a check for the MOLD argument to the TRANSFER
intrinsic for having storage size 0, which failed if MOLD was
an EXPR_VARIABLE although having rank != 0. Duh.
Adjusting that check fixed the issue.
I
Tested x86_64-linux, pushed to trunk. Backports to follow.
This adds a new internal flag to the filesystem::directory_iterator
constructor that makes it fail if the path is a symlink that resolves to
a directory. This prevents filesystem::remove_all from following a
symlink to a directory,
The change to istream.tcc looks large but is just adding { and } and
re-indenting everything between them.
Tested x86_64-linux, pushed to trunk.
With -fno-exceptions we get a -Wmisleading-indentation warning for:
if (cond)
__try {}
__catch (...) {}
This is because the __catch(...)
On 1/25/22 04:15, Richard Biener wrote:
On Mon, Jan 24, 2022 at 11:55 PM Martin Sebor wrote:
The pointer_query algorithm fails when it's unable to determine
the provenance of an pointer SSA variable. A failure prevents it
from making a record of the variable in the cache. Although this
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587449.html
BR,
Kewen
> on 2021/12/29 下午5:36, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> When TARGET_AVOID_XFORM is set, we turn off VSX. But at least from
>> ISA3.0 (Power9), we support DQ form vector load/store. This
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587311.html
BR,
Kewen
> on 2021/12/23 上午10:12, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> There is one hunk checking for functions with target attribute/pragma
>> have the same altivec abi as the one of main_target_opt, it
on 2022/1/14 上午12:31, David Edelsohn wrote:
> On Thu, Jan 13, 2022 at 7:28 AM Kewen.Lin wrote:
>>
>> on 2022/1/13 上午11:56, Kewen.Lin via Gcc-patches wrote:
>>> on 2022/1/13 上午11:44, David Edelsohn wrote:
On Wed, Jan 12, 2022 at 10:38 PM Kewen.Lin wrote:
>
> Hi David,
>
> on
Since MIPS r2, the IPL section in Cause register has been expand
to 8bit instead of 6bit.
Since __attribute__((interrupt)) is only supported for r2+,
we don't need to detect the target.
gcc/ChangeLog:
* config/mips/mips.cc (mips_expand_prologue):
IPL is 8bit for r2+.
---
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587310.html
BR,
Kewen
> on 2021/12/23 上午10:09, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> As PR103627 shows, there is an unexpected case where !TARGET_VSX
>> and TARGET_MMA co-exist. As ISA3.1 claims, SIMD is a requirement
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587635.html
BR,
Kewen
>
> on 2022/1/5 下午3:34, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> This patch is to fix the inconsistent behaviors for non-LTO mode
>> and LTO mode. As Martin pointed out, currently the function
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587309.html
BR,
Kewen
> on 2021/12/23 上午10:06, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> This patch is to fix one wrong assertion which is too aggressive.
>> Vectorizer can do vec_construct costing for the vector type
From: Andrew Pinski
The problem here is that aarch64_expand_setmem does not change the alignment
for strict alignment case. This is version 3 of this patch, is is based on
version 2 and moves the check for the number of instructions from the
optimizing for size case to be always and change the
Tested x86_64-linux, pushed to trunk.
For GNU/Linux G++ defines _GNU_SOURCE automatically, but not for Cygwin.
This means secure_getenv is not declared by Cygwin's , even
though autoconf detected it is present in the library. Define it in the
source files that want to use secure_getenv.
On Tue, Jan 25, 2022 at 05:35:20PM -0700, Martin Sebor wrote:
> On 1/25/22 16:33, Marek Polacek via Gcc-patches wrote:
> > Here, -Wuse-after-free warns about using 'this' which, on ARM, cdtors
> > return, as mandated by the EABI. To be entirely correct, it only
> > requires it for C1 and C2 ctors
Hi Andre',
Am 25.01.22 um 17:32 schrieb Andre Vehreschild via Fortran:
Hi all,
attached patch fixes wrong code generation when broadcasting a derived type
containing allocatable and non-allocatable scalars. Furthermore does it prevent
broadcasting of coarray-tokens, which are always local
On 1/25/22 16:33, Marek Polacek via Gcc-patches wrote:
Here, -Wuse-after-free warns about using 'this' which, on ARM, cdtors
return, as mandated by the EABI. To be entirely correct, it only
requires it for C1 and C2 ctors and D2 and D1 dtors, but I don't feel
like changing that now and possibly
Here, -Wuse-after-free warns about using 'this' which, on ARM, cdtors
return, as mandated by the EABI. To be entirely correct, it only
requires it for C1 and C2 ctors and D2 and D1 dtors, but I don't feel
like changing that now and possibly running into issues later on.
This patch uses
Hi, all,
Sorry for bothering.
I'm trying to commit aarch64 scs code to the gcc and there is an issue
that I'm not sure about, could someone give me some suggestions?
(To avoid noise, I did't cc PING^3 [1] to the kernel mail list :) )
When clang enables scs, the following instructions are
On Wed, Jan 26, 2022 at 3:15 AM Kewen.Lin via Gcc-patches
wrote:
>
> Gentle ping:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587309.html
OK.
Thanks,
Richard.
> BR,
> Kewen
>
> > on 2021/12/23 上午10:06, Kewen.Lin via Gcc-patches wrote:
> >> Hi,
> >>
> >> This patch is to fix one
On 1/25/22 02:19, Richard Sandiford wrote:
Dan Li writes:
+
if (flag_stack_usage_info)
current_function_static_stack_size = constant_lower_bound (frame_size);
@@ -9066,6 +9089,10 @@ aarch64_expand_epilogue (bool for_sibcall)
RTX_FRAME_RELATED_P (insn) = 1;
Usually we handle DR1558 substitution near the top of tsubst, but in this
case while substituting TYPENAME_TYPE we were passing an alias
specialization to tsubst_aggr_type, which ignored its aliasness.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/103057
gcc/cp/ChangeLog:
47 matches
Mail list logo
