This libgo patch by Nikhil Benesch only compiles the ptrace varargs
shim on GNU/Linux, to avoid compilation failures on some other
platforms. The C ptrace function is not entirely portable (e.g.,
NetBSD has `int data` instead of `void* data`), and so far Linux is
the only platform that needs the
On Oct 18, 2020, Alexandre Oliva wrote:
> The Aux_Short_Float unit is implemented in terms of the Aux_Float one,
> and the others rely on the elementary functions from the C Math
> library for float, double and long double types, respectively.
Use Aux_Long_Float for all real types on LynxOS
On Oct 18, 2020, Alexandre Oliva wrote:
> The option is provided by default, but there is an alternate version
> that doesn't, that is used for vxworks targets.
vxworks float EFs not precise enough -> use long float
From: Alexandre Oliva
Some acats-4 tests that check the precision of Float
On Oct 20, 2020, Rainer Orth wrote:
> your patch similarly broke sparc*-sun-solaris* bootstrap. The attached
> snippet on top of this workaround fixes that.
Thanks, here's what I'm installing, approved by me with my build
machinery maintainer hat on ;-)
Use Aux_Long_Long_Float wraplf for
On Oct 19, 2020, Alexandre Oliva wrote:
> Hello, Andreas,
> On Oct 19, 2020, Andreas Schwab wrote:
>> -nostdinc a-nallfl.ads -o a-nallfl.o
>> a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on return value
>> a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on argument
Err, sorry, I mislabeled this patch as [FYI,Ada], but it is neither
about Ada nor pre-approved. It does require a review before I can check
it in.
On Oct 22, 2020, Alexandre Oliva wrote:
> for gcc/ChangeLog
> * config/i386/cygming.h (TARGET_LIBC_HAS_FUNCTION): Enable
> sincos
The sincos transformation does not take place on all platforms,
because the libc_has_function target hook disables it by default.
Current w64-mingw's math library supports sincos, sincosl and sincosf,
in 32- and 64-bit modes. I suppose this has been this way for long,
also with mingw32 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97249
Hongtao.liu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97249
--- Comment #8 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:52e7f09698ecb5ba6d9e921ffe912d1f66158e9e
commit r11-4204-g52e7f09698ecb5ba6d9e921ffe912d1f66158e9e
Author: liuhongt
Date: Tue Oct
On Thu, Oct 22, 2020 at 12:36 AM Segher Boessenkool
wrote:
>
> On Wed, Oct 21, 2020 at 04:43:29PM +0100, Richard Sandiford wrote:
> > Hongtao Liu writes:
> > > + poly_uint64 nunits
> > > + = GET_MODE_NUNITS (GET_MODE (SUBREG_REG (trueop0)));
> > > + rtx par = trueop1;
>
I had a wrong email setting and got your reply later. I modified the
patch according to your advice. Could you please review it again? Thanks.
On 2/10/2020 上午 1:47, Richard Sandiford wrote:
Sorry for the slow review.
HAO CHEN GUI via Gcc-patches writes:
diff --git a/gcc/config/mips/mips.c
On Wed, Oct 21, 2020 at 7:36 PM Jim Wilson wrote:
>
>
> On Fri, Oct 16, 2020 at 2:34 AM Kito Cheng wrote:
>
>> +# Example 2:
>> +# rv32imafd-ilp32d--c*b
>> +# means that, in addition to rv32imafd, these configurations can also
>> use the
>> +# rv32imafd-ilp32d libraries: rv32imafd-ilp32dc,
On Fri, Oct 16, 2020 at 2:34 AM Kito Cheng wrote:
> +# Example 2:
> +# rv32imafd-ilp32d--c*b
> +# means that, in addition to rv32imafd, these configurations can also use
> the
> +# rv32imafd-ilp32d libraries: rv32imafd-ilp32dc, rv32imafd-ilp32db,
> +#
On Wed, Oct 21, 2020 at 11:04 PM Vladimir Makarov wrote:
>
>
> On 2020-10-20 10:11 p.m., Hongtao Liu wrote:
> >
> > Changed, and it passed the i386/x86-64 regression test.
> >
> > Update patch.
> >
> Thank you, Hongtao. This patch is ok for the trunk.
>
>
Thanks for the review, committed.
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87767
--- Comment #17 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:4de7b010038933dd6ca96bf186ca49f243d0def6
commit r11-4202-g4de7b010038933dd6ca96bf186ca49f243d0def6
Author: liuhongt
Date: Sat Sep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87767
--- Comment #18 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:7026bb9504eb0f95e114f832cd6dd14302376861
commit r11-4203-g7026bb9504eb0f95e114f832cd6dd14302376861
Author: liuhongt
Date: Sat Sep
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555646.html
Thanks
From: Dennis Zhang
Sent: Tuesday, October 6, 2020 5:46 PM
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov; nd; Richard Earnshaw; Ramana Radhakrishnan
Subject: Re: [PATCH][Arm]
Hi Kyrylo,
>
> From: Kyrylo Tkachov
> Sent: Wednesday, October 14, 2020 10:15 AM
> To: Dennis Zhang; gcc-patches@gcc.gnu.org
> Cc: nd; Richard Earnshaw; Ramana Radhakrishnan
> Subject: RE: [PATCH][Arm] Auto-vectorization for MVE: vmin/vmax
>
> Hi Dennis,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97515
--- Comment #4 from Andrew Macleod ---
Furthermore, this PR is also a good example of a case where we want to inject
updated values into the Ranger's iterator.
:
goto ; [INV]
:
ui_8 = ~xe_3;
if (ui_8 == 0)
goto ; [INV]
else
Hi,
this patch moves nested function information out of cgraph_node (to a summary).
This saves memory (especially at WPA time) and also makes nested function
support more contained.
Bootstrapped/regtested x86_64-linux. Plan to commit it tomorrow.
gcc/ChangeLog:
2020-10-22 Jan Hubicka
Pick up the correct type for the RHS of a_2 =
bootstrapped on x86_64-pc-linux-gnu, no regressions, pushed.
Andrew
commit 966fdb2e12c0347aa3f9efaf5f4e1cd8237fa024
Author: Andrew MacLeod
Date: Wed Oct 21 20:11:16 2020 -0400
Handle a_2= properly in range calculations.
when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97520
--- Comment #3 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:966fdb2e12c0347aa3f9efaf5f4e1cd8237fa024
commit r11-4200-g966fdb2e12c0347aa3f9efaf5f4e1cd8237fa024
Author: Andrew MacLeod
Date:
Hi kyrylo,
>
> From: Kyrylo Tkachov
> Sent: Wednesday, October 14, 2020 10:14 AM
> To: Dennis Zhang; gcc-patches@gcc.gnu.org
> Cc: nd; Richard Earnshaw; Ramana Radhakrishnan
> Subject: RE: [PATCH][Arm] Auto-vectorization for MVE: vmul
>
> Hi Dennis,
>
>
Full comments in the PR, but basically substitute and fold was expecting
to see a constant returned for any range which globally evaluates to a
constant.
This allowed it to replace all uses of an ssa name as they were encountered.
The ranger model can return UNDEFINED for the range of names in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97515
--- Comment #3 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:ca5f4666f7a9404cdb04832324de3dd7d71e35c3
commit r11-4198-gca5f4666f7a9404cdb04832324de3dd7d71e35c3
Author: Andrew MacLeod
Date:
This libgo patch by Nikhil Benesch imports the upstream code for BSD
sockets and sysctls into the syscall package. This code is
sufficiently different that it doesn't get merged by the scripts.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
hi,
this patch makes builtin_constant_p hint to combine with other loop hints
we already support. This is necessary for it to be realy effective
since most such functions will already get big_speedup hint.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/ChangeLog:
2020-10-22 Jan Hubicka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #56 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:3fd5876793ddf882994acafc9c5b28e3be8897bd
commit r11-4196-g3fd5876793ddf882994acafc9c5b28e3be8897bd
Author: Jan Hubicka
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97525
Marek Polacek changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
Marek Polacek changed:
What|Removed |Added
CC||smuccione at agisent dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97525
Bug ID: 97525
Summary: failed to report use before initialization in
constructor initialization
Product: gcc
Version: og10 (devel/omp/gcc-10)
Status: UNCONFIRMED
On Wed, Oct 21, 2020 at 03:29:11PM -0500, Segher Boessenkool wrote:
> Anyway:
>
> + || (outer_code == AND
> + && rs6000_is_valid_2insn_and (x, mode)))
> {
> *total = COSTS_N_INSNS (1);
> return true;
>
> It should return COSTS_N_INSNS (2)
+ correct kernel mailing list this time.
On Wed, Oct 21, 2020 at 2:33 PM Nick Desaulniers
wrote:
>
> Thanks for the quick feedback!
>
> On Wed, Oct 21, 2020 at 2:13 PM Jakub Jelinek wrote:
> >
> > On Wed, Oct 21, 2020 at 02:04:15PM -0700, Nick Desaulniers via Gcc-patches
> > wrote:
> > >
On 10/21/20 5:46 PM, Patrick Palka wrote:
On Wed, 21 Oct 2020, Jason Merrill wrote:
On 10/8/20 4:47 PM, Patrick Palka wrote:
In the testcase below, we're ICEing during constexpr evaluation of the
CONSTRUCTOR {.data={{}, [1 ... 7]={}}} of type 'vector'. The apparently
unique thing about this
On 10/21/20 6:32 AM, kamlesh kumar wrote:
gcc/cp/ChangeLog
---
2020-10-21 Kamlesh Kumar
PR c++/97453
* pt.c (get_template_base): Implement DR2303,
Consider closest base while template
deduction when base of base also matches.
gcc/testsuite/ChangeLog
On Wed, 21 Oct 2020, Jason Merrill wrote:
> On 10/8/20 4:47 PM, Patrick Palka wrote:
> > In the testcase below, we're ICEing during constexpr evaluation of the
> > CONSTRUCTOR {.data={{}, [1 ... 7]={}}} of type 'vector'. The apparently
> > unique thing about this CONSTRUCTOR is that it has a
Thanks for the quick feedback!
On Wed, Oct 21, 2020 at 2:13 PM Jakub Jelinek wrote:
>
> On Wed, Oct 21, 2020 at 02:04:15PM -0700, Nick Desaulniers via Gcc-patches
> wrote:
> > Tangentially related question:
> > We're running into a bug related to LTO for the kernel when code
> > compiled with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
--- Comment #31 from Segher Boessenkool ---
Performing a jump based on the carry bit is not something we can
easily do (there are no simple insns for it, and those sequences
that will do the trick are expensive). But I'll look at that,
thanks
> On Wed, Oct 21, 2020 at 09:03:03PM +0200, Martin Liška wrote:
> > Maybe a silly question, but isn't the code only an obfuscation?
> > What about doing:
> >
> > if (__builtin_constant_p(x))
> > return x < 2 ? 0 : __builtin_clz(x);
> >
> > which is fully eliminated in a c.031t.ccp1 pass right
>
> Hello.
>
> Maybe a silly question, but isn't the code only an obfuscation?
> What about doing:
>
> if (__builtin_constant_p(x))
> return x < 2 ? 0 : __builtin_clz(x);
>
> which is fully eliminated in a c.031t.ccp1 pass right after einline happens
> for a call context where 'x' is a
On Wed, Oct 21, 2020 at 02:04:15PM -0700, Nick Desaulniers via Gcc-patches
wrote:
> Tangentially related question:
> We're running into a bug related to LTO for the kernel when code
> compiled with -fno-stack-protector is called from and inlined into
> code that is compiled with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80076
--- Comment #4 from Andres Freund ---
(In reply to Patrick Palka from comment #3)
> Fixed for GCC 11. Thanks for the report.
Thanks!
On 10/21/20 12:37 PM, Patrick Palka wrote:
In the testcase below, folding of the initializer for 'ret' inside the
instantiated f::lambda ends up yielding an initializer for which
potential_constant_expression returns false. This causes finish_function
to mark the lambda as non-constexpr, which
On Tue, Oct 20, 2020 at 5:19 AM Richard Biener
wrote:
>
> On Tue, Oct 20, 2020 at 1:24 PM Martin Liška wrote:
> >
> > PING^5
>
> So can we use the same identifier as clang here as Nick
> requests? Thus, OK with re-naming everything alongside
> no_stack_protector. It isn't really the opposite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
On Tue, Oct 20, 2020 at 04:34:46PM -0500, will schmidt wrote:
> This adds support for the VSX load/store rightmost element operations.
> This includes the instructions lxvrbx, lxvrhx, lxvrwx, lxvrdx,
> stxvrbx, stxvrhx, stxvrwx, stxvrdx; And the builtins
> vec_xl_sext() /* vector load sign extend
On 10/8/20 4:47 PM, Patrick Palka wrote:
In the testcase below, we're ICEing during constexpr evaluation of the
CONSTRUCTOR {.data={{}, [1 ... 7]={}}} of type 'vector'. The apparently
unique thing about this CONSTRUCTOR is that it has a RANGE_EXPR index
whose corresponding sub-aggregate
On 10/21/20 4:35 PM, Patrick Palka wrote:
This makes duplicate_decls differentiate a TYPE_DECL for an alias
template from a TYPE_DECL for one of its template parameters. The
recently added assert in template_parm_to_arg revealed this latent issue
because merging of the two TYPE_DECLs cleared
This makes duplicate_decls differentiate a TYPE_DECL for an alias
template from a TYPE_DECL for one of its template parameters. The
recently added assert in template_parm_to_arg revealed this latent issue
because merging of the two TYPE_DECLs cleared the DECL_TEMPLATE_PARM_P
flag.
With this
On Wed, Oct 21, 2020 at 01:27:42PM +1030, Alan Modra wrote:
> On Tue, Oct 20, 2020 at 01:55:56PM -0500, Segher Boessenkool wrote:
> > On Thu, Oct 08, 2020 at 09:27:54AM +1030, Alan Modra wrote:
> > > The existing "case AND" in this function is not sufficient for
> > >
The _M_add_ref_lock() and _M_add_ref_lock_nothrow() members of
_Sp_counted_base are very similar, except that the former throws an
exception when the use count is zero and the latter returns false. The
former (and its callers) can be implemented in terms of the latter.
This results in a small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80076
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97515
--- Comment #2 from Andrew Macleod ---
Created attachment 49417
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49417=edit
check for undefined before not returning a constant value
The ranger deals with UNDEFINED slightly differently than
> On Oct 21, 2020, at 10:34 AM, Jonathan Wakely wrote:
>
> On 21/10/20 09:53 -0700, Thomas Rodgers wrote:
>> From: Thomas Rodgers
>>
>> libstdc++/Changelog:
>> libstdc++-v3/doc/doxygen/user.cfg.in (INPUT): Add new header.
>> libstdc++-v3/include/Makefile.am (std_headers): Add new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #37 from Peter Bergner ---
Fixed on trunk. I'll let this bake a week before backporting the rs6000 part
of the fix to GCC 10 (approved by Segher).
On 10/21/20 1:34 PM, Segher Boessenkool wrote:
>> The following patch from Andrew and richi fixes the ICE on Martin's test
>> case and passes bootstrap and regtesting on powerpc64le-linux.
>> Ok for trunk?
>
> Yes, okay for trunk. Thanks!
Ok, pushed to trunk. Thanks!
>> Since the ranger
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #36 from CVS Commits ---
The master branch has been updated by Peter Bergner :
https://gcc.gnu.org/g:84cc3370d6d5972fe495b2114fb32f7b4a49a98d
commit r11-4193-g84cc3370d6d5972fe495b2114fb32f7b4a49a98d
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
--- Comment #29 from Segher Boessenkool ---
Yup, and that is a more elegant way of writing this anyway. But we
still do not handle the exact testcase code optimally ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97524
Bug ID: 97524
Summary: Compiling with -flto=auto fails in make is not
installed
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
On Wed, Oct 21, 2020 at 09:03:03PM +0200, Martin Liška wrote:
> Maybe a silly question, but isn't the code only an obfuscation?
> What about doing:
>
> if (__builtin_constant_p(x))
> return x < 2 ? 0 : __builtin_clz(x);
>
> which is fully eliminated in a c.031t.ccp1 pass right after einline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97523
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97523
Bug ID: 97523
Summary: [11 Regression] bogus "would use explicit constructor"
error for new[]()
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
On 10/21/20 5:11 PM, Jan Hubicka wrote:
return ( __builtin_constant_p((size) - 1) ? ( __builtin_constant_p((size) - 1)
? ( ((size) - 1) < 2 ? 0 : ((size) - 1) & (1ULL << 63) ? 63 : ((size) - 1) &
(1ULL << 62) ? 62 : ((size) - 1) & (1ULL << 61) ? 61 : ((size) - 1) & (1ULL <<
60) ? 60 : ((size) -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #55 from Martin Liška ---
(In reply to Jan Hubicka from comment #54)
> > > It goes from 1 to 1<<63, so each of tests translates to a range.
> >
> > Yes, but these ranges are very large, nothing for a jump table or a
> > bit-test.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97520
Martin Liška changed:
What|Removed |Added
Known to fail||11.0
Target Milestone|---
Hi!
On Wed, Oct 21, 2020 at 01:00:20PM -0500, Peter Bergner wrote:
> PR97360 shows a problem in how we create our PXI and POI modes that cause
> an ICE in the ranger pass. The problem seems to be that the extra call
> to build_distinct_type_copy() also creates new TYPE_{MIN,MAX}_VALUEs that
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97520
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2020-10-21
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #54 from Jan Hubicka ---
> > It goes from 1 to 1<<63, so each of tests translates to a range.
>
> Yes, but these ranges are very large, nothing for a jump table or a bit-test.
Yep, but theoretically you can recover the decision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97521
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Known to
On Wed, Oct 21, 2020 at 06:09:28PM +0200, Uros Bizjak wrote:
> On Wed, Oct 21, 2020 at 4:45 PM Qing Zhao wrote:
> > Looks like it’s very complicate to use the st/mm register set correctly, So,
> > I assume that this set of registers might be very hard to be used by the
> > attacker correctly.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97520
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #53 from Martin Liška ---
> It goes from 1 to 1<<63, so each of tests translates to a range.
Yes, but these ranges are very large, nothing for a jump table or a bit-test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #52 from Jan Hubicka ---
> I don't see how can if-to-switch conversion pass help us here. It's designed
> to
> identify compact intervals. In this case we see:
>
>:
> _16 = _2 & 576460752303423488;
> if (_16 == 0)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #51 from Martin Liška ---
> Martin, how does the if chain conversion behave on the example?
I don't see how can if-to-switch conversion pass help us here. It's designed to
identify compact intervals. In this case we see:
:
_16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97511
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #50 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:caaa218f912ccf932fdb79243ded68bb462bbe63
commit r11-4192-gcaaa218f912ccf932fdb79243ded68bb462bbe63
Author: Jan Hubicka
Date: Wed
PR97360 shows a problem in how we create our PXI and POI modes that cause
an ICE in the ranger pass. The problem seems to be that the extra call
to build_distinct_type_copy() also creates new TYPE_{MIN,MAX}_VALUEs that
are not compatible/the same as the base type itself. The simple "fix" is
to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97522
Bug ID: 97522
Summary: [11 regression] test cases fail on powerpc64 BE after
r11-4077
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
On Wed, Oct 21, 2020 at 07:30:46PM +0200, Rainer Orth wrote:
> this broke sparc-sun-solaris2.11 bootstrap
>
> /vol/gcc/src/hg/master/local/gcc/tree-ssa-phiopt.c: In function 'bool
> cond_removal_in_popcount_clz_ctz_pattern(basic_block, basic_block, edge,
> edge, gimple*, tree, tree)':
>
On 21/10/2020 17:11, Christophe Lyon via Gcc-patches wrote:
> On Wed, 21 Oct 2020 at 18:07, Richard Earnshaw
> wrote:
>>
>> On 21/10/2020 16:49, Christophe Lyon via Gcc-patches wrote:
>>> On Tue, 20 Oct 2020 at 13:25, Richard Earnshaw
>>> wrote:
On 20/10/2020 12:22, Richard Earnshaw
On 21/10/20 09:53 -0700, Thomas Rodgers wrote:
From: Thomas Rodgers
libstdc++/Changelog:
libstdc++-v3/doc/doxygen/user.cfg.in (INPUT): Add new header.
libstdc++-v3/include/Makefile.am (std_headers): Add new header.
libstdc++-v3/include/Makefile.in: Regenerate.
Hi Jakub,
> While we have at the RTL level noce_try_ifelse_collapse combined with
> simplify_cond_clz_ctz, that optimization doesn't always trigger because
> e.g. on powerpc there is an define_insn to compare a reg against zero and
> copy that register to another one and so we end up with a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97521
--- Comment #3 from Jakub Jelinek ---
And we do that because:
case VECTOR_CST:
{
tree tmp = NULL_TREE;
if (VECTOR_MODE_P (mode))
return const_vector_from_tree (exp);
scalar_int_mode int_mode;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97521
--- Comment #2 from Jakub Jelinek ---
It seems that
vector(2) _1;
vector(2) _2;
...
_1 = _2 & { 0, -1 };
remains in the IL after that change, which results in expansion of TImode AND,
but the second operand of that is (const_int 2 [0x2])
> >What about instead putting above extern long long __gnat_file_time the
> >following:
> >
> >#if __APPLE__
> >#define st_mtim st_mtimespec
> >#define st_atim st_atimespec
> >#endif
> >
> >To avoid having the two (nested) #if __APPLE__ and keep the code easier
two => three :-)
> >to follow?
>
From: Thomas Rodgers
libstdc++/Changelog:
libstdc++-v3/doc/doxygen/user.cfg.in (INPUT): Add new header.
libstdc++-v3/include/Makefile.am (std_headers): Add new header.
libstdc++-v3/include/Makefile.in: Regenerate.
libstdc++-v3/include/precompiled/stdc++.h: Include
> On Oct 21, 2020, at 11:09 AM, Uros Bizjak wrote:
>
> On Wed, Oct 21, 2020 at 4:45 PM Qing Zhao wrote:
>>
>>
>>
>> -- q --
>> The CPU shall be in x87 mode upon entry to a function. Therefore,
>> every function that uses the MMX registers is required to issue an
>> emms or femms
Got it.
thanks.
Qing
> On Oct 21, 2020, at 10:47 AM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
+ /* For each of the hard registers, check to see whether we should zero
it if:
+ 1. it is a call-used-registers;
+ and 2. it is not a fixed-registers;
+ and
Arnaud Charlet wrote:
This patch breaks bootstrap on Darwin platforms.
Pierre-Marie de Rodat wrote:
The modification file time precision now defined by OS.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* adaint.c (__gnat_file_time): New routine.
On Thu, 8 Oct 2020, Patrick Palka wrote:
> In the testcase below, we're ICEing during constexpr evaluation of the
> CONSTRUCTOR {.data={{}, [1 ... 7]={}}} of type 'vector'. The apparently
> unique thing about this CONSTRUCTOR is that it has a RANGE_EXPR index
> whose corresponding sub-aggregate
In the testcase below, folding of the initializer for 'ret' inside the
instantiated f::lambda ends up yielding an initializer for which
potential_constant_expression returns false. This causes finish_function
to mark the lambda as non-constexpr, which ultimately causes us to reject
'f(g)' as a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97521
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
> This patch breaks bootstrap on Darwin platforms.
>
> Pierre-Marie de Rodat wrote:
>
> > The modification file time precision now defined by OS.
> >
> > Tested on x86_64-pc-linux-gnu, committed on trunk
> >
> > gcc/ada/
> >
> > * adaint.c (__gnat_file_time): New routine.
> >
On Wed, Oct 21, 2020 at 04:43:29PM +0100, Richard Sandiford wrote:
> Hongtao Liu writes:
> > + poly_uint64 nunits
> > + = GET_MODE_NUNITS (GET_MODE (SUBREG_REG (trueop0)));
> > + rtx par = trueop1;
> > + for (int i = 0; i != l1; i++)
> > + {
> > +
Hi Folks,
This patch breaks bootstrap on Darwin platforms.
Pierre-Marie de Rodat wrote:
> The modification file time precision now defined by OS.
>
> Tested on x86_64-pc-linux-gnu, committed on trunk
>
> gcc/ada/
>
> * adaint.c (__gnat_file_time): New routine.
>
387-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20201021 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118
--- Comment #37 from Paul Thomas ---
(In reply to Paul Thomas from comment #36)
> Created attachment 49412 [details]
> An updated patch
>
> The patch has been evolving... slowly.
>
> I found that dependency_57.f90 segfaulted in runtime so I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97519
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97519
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
On Wed, Oct 21, 2020 at 5:15 PM Jakub Jelinek wrote:
>
> On Wed, Sep 30, 2020 at 06:06:31PM +0200, Florian Weimer wrote:
> > --- a/gcc/common/config/i386/i386-common.c
> > +++ b/gcc/common/config/i386/i386-common.c
> > @@ -1795,9 +1795,13 @@ const pta processor_alias_table[] =
> > PTA_MMX |
1 - 100 of 248 matches
Mail list logo
