Nice that AdaCore put in a redirect.
Pushed.
---
htdocs/readings.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/readings.html b/htdocs/readings.html
index 4101fc4b..40ad4d62 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -562,7 +562,7 @@ names.
On Wed, 1 Apr 2020, Gerald Pfeifer wrote:
> Nice that AdaCore put in a redirect.
I spoke too fast, that was a 404 page.
> - https://www2.adacore.com/gap-static/GNAT_Book/html/";>GNAT:
> + https://www.adacore.com/gap-static/GNAT_Book/html/";>GNAT:
Arnaud, Eric, Pierre-Marie, what do you recom
Hi!
Oh, the OpenACC 'declare' implementation in GCC -- be careful to not look
too carefully, or you'll discover one problem after the other... ;-/
..., and also, a number of issues are open in the OpenACC tracker
regarding the 'declare' clause.
On 2020-03-12T15:43:03+0100, Frederik Harwath wro
Hi!
The following testcase ICEs because the objsz pass calls replace_uses_by
on SSA_NAME_OCCURS_IN_ABNORMAL_PHI SSA_NAME. The following patch instead
of that calls replace_call_with_value, which will turn it into
xyz_123(ab) = 234;
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
On Tue, Mar 31, 2020 at 3:28 PM Maciej W. Rozycki wrote:
>
> Correct an issue with GCC commit 906b3eb9df6c ("Improve endianess
> detection.") and fix a typo in the __BYTE_ORDER fallback macro check
> that causes compilation errors like:
>
> .../include/plugin-api.h:162:2: error: #error "Could not
Pushed.
---
htdocs/gcc-9/changes.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/gcc-9/changes.html b/htdocs/gcc-9/changes.html
index d5469ec4..74c7cde7 100644
--- a/htdocs/gcc-9/changes.html
+++ b/htdocs/gcc-9/changes.html
@@ -675,7 +675,7 @@ $ g++ typo.cc
Hi:
This patch is about to enable GCC support for SERIALIZE which would
be in GLC. There's only 1 instruction: SERIALIZE, more details please
refer to
https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
I know it's stag
Pushed.
---
htdocs/readings.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/readings.html b/htdocs/readings.html
index 40ad4d62..84fc0404 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -27,7 +27,7 @@
https://en.wikibooks.org/wiki/GNU_C_Compiler
Hi:
This patch is about to enable GCC support for TSXLDTRK which would
be in GLC. There's only 2 instructions: XRESLDTRK, XSUSLDTRK, more
details please
refer to
https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
I kno
On Wed, Apr 1, 2020 at 3:32 PM Hongtao Liu wrote:
>
> Hi:
> This patch is about to enable GCC support for TSXLDTRK which would
> be in GLC. There's only 2 instructions: XRESLDTRK, XSUSLDTRK, more
> details please
> refer to
> https://software.intel.com/sites/default/files/managed/c5/15/architec
On Wed, 1 Apr 2020, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs because the objsz pass calls replace_uses_by
> on SSA_NAME_OCCURS_IN_ABNORMAL_PHI SSA_NAME. The following patch instead
> of that calls replace_call_with_value, which will turn it into
> xyz_123(ab) = 234;
>
> Boot
On Wed, Apr 1, 2020 at 9:23 AM Hongtao Liu wrote:
>
> Hi:
> This patch is about to enable GCC support for SERIALIZE which would
> be in GLC. There's only 1 instruction: SERIALIZE, more details please
> refer to
> https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruct
On Wed, Apr 1, 2020 at 9:28 AM Hongtao Liu wrote:
>
> On Wed, Apr 1, 2020 at 3:32 PM Hongtao Liu wrote:
> >
> > Hi:
> > This patch is about to enable GCC support for TSXLDTRK which would
> > be in GLC. There's only 2 instructions: XRESLDTRK, XSUSLDTRK, more
> > details please
> > refer to
> >
On 3/31/20 3:27 PM, Maciej W. Rozycki wrote:
Correct an issue with GCC commit 906b3eb9df6c ("Improve endianess
detection.") and fix a typo in the __BYTE_ORDER fallback macro check
that causes compilation errors like:
.../include/plugin-api.h:162:2: error: #error "Could not detect architecture
e
On 4/1/20 7:01 AM, Hans-Peter Nilsson wrote:
On Tue, 31 Mar 2020, Maciej W. Rozycki wrote:
Correct an issue with GCC commit 906b3eb9df6c ("Improve endianess
detection.") and fix a typo in the __BYTE_ORDER fallback macro check
that causes compilation errors like:
.../include/plugin-api.h:162:2:
> I spoke too fast, that was a 404 page.
>
> > - https://www2.adacore.com/gap-static/GNAT_Book/html/";>GNAT:
> > + https://www.adacore.com/gap-static/GNAT_Book/html/";>GNAT:
>
> Arnaud, Eric, Pierre-Marie, what do you recommend?
>
> https://www.adacore.com/books/gnat-the-gnu-ada-compiler onl
Status
==
GCC trunk is in regression and documentation fixing mode, stage 4.
There's still quite some work to do before we reach the zero-P1
milestone and thus qualify for a first release candidate of GCC 10.
Please help in making this happen soon, historical data would
predict a RC to be av
Please find attached a patch to fix test case failures of pr93365.f90,
pr93600_1.f90 and pr93600_2.f90.
OK to commit?
gcc/fortran/ChangeLog:
Mark Eggleston
PR fortran/04386
expr.c (simplify_parameter_variable): Restore code deleted
in PR94246.
--
https://www.codethink.co.u
On Wed, Apr 1, 2020 at 2:31 AM Mark Eggleston
wrote:
>
> Please find attached a patch to fix test case failures of pr93365.f90,
> pr93600_1.f90 and pr93600_2.f90.
>
> OK to commit?
>
> gcc/fortran/ChangeLog:
>
> Mark Eggleston
>
> PR fortran/04386
^^^ Wrong
On Wed, Apr 01, 2020 at 02:43:46AM -0700, H.J. Lu via Gcc-patches wrote:
> On Wed, Apr 1, 2020 at 2:31 AM Mark Eggleston
> wrote:
> >
> > Please find attached a patch to fix test case failures of pr93365.f90,
> > pr93600_1.f90 and pr93600_2.f90.
> >
> > OK to commit?
> >
> > gcc/fortran/ChangeLog:
On 01/04/2020 10:43, H.J. Lu wrote:
On Wed, Apr 1, 2020 at 2:31 AM Mark Eggleston
wrote:
Please find attached a patch to fix test case failures of pr93365.f90,
pr93600_1.f90 and pr93600_2.f90.
OK to commit?
gcc/fortran/ChangeLog:
Mark Eggleston
PR fortran/04386
LGTM with the PR/spacing fixed as noted by HJ and Jakub.
Thanks for the patch!
Tobias
On 4/1/20 11:31 AM, Mark Eggleston wrote:
Please find attached a patch to fix test case failures of pr93365.f90,
pr93600_1.f90 and pr93600_2.f90.
OK to commit?
gcc/fortran/ChangeLog:
Mark Eggleston
On 01/04/2020 10:46, Jakub Jelinek wrote:
On Wed, Apr 01, 2020 at 02:43:46AM -0700, H.J. Lu via Gcc-patches wrote:
On Wed, Apr 1, 2020 at 2:31 AM Mark Eggleston
wrote:
Please find attached a patch to fix test case failures of pr93365.f90,
pr93600_1.f90 and pr93600_2.f90.
OK to commit?
gcc/
On Wed, 1 Apr 2020, Martin Liška wrote:
> > OK to apply this hopefully obvious fix to GCC and then merge to binutils?
>
> I've just installed the patch.
> @H.J. Can you please pull it to bintuils?
Why didn't you use the commit as I published it and also assumed
authorship of my change? I fe
On 4/1/20 11:55 AM, Maciej W. Rozycki wrote:
On Wed, 1 Apr 2020, Martin Liška wrote:
OK to apply this hopefully obvious fix to GCC and then merge to binutils?
I've just installed the patch.
@H.J. Can you please pull it to bintuils?
Why didn't you use the commit as I published it
Beca
On Wed, 1 Apr 2020, Martin Liška wrote:
> > NB if posting as an attachment please try matching the message subject
> > with the change heading as otherwise it takes a lot of effort to track the
> > patch submission corresponding to a given commit.
>
> I see your point, but note that sometimes a
On 4/1/20 12:04 PM, Maciej W. Rozycki wrote:
On Wed, 1 Apr 2020, Martin Liška wrote:
NB if posting as an attachment please try matching the message subject
with the change heading as otherwise it takes a lot of effort to track the
patch submission corresponding to a given commit.
I see you
Hello.
This is second attempt to get rid of tcc_comparison GENERIC trees
to be used as the first argument of VEC_COND_EXPR.
The patch attempts achieves that in the following steps:
1) veclower pass expands all tcc_comparison expression into a SSA_NAME
2) since that tcc_comparsion can't be used a
On 01/04/2020 08:28, Stefan Liebler wrote:
> ping
>
Hi Stefan,
As I've already said, I think that the name should be __ibmz_get_tls_offset to
make clear that it is an internal function.
Other than that, looks good to me.
Iain.
On 01/04/2020 08:28, Stefan Liebler wrote:
> ping
>
Thanks, I'll send the patch upstream, as it's the same there.
Looks OK to me.
Regards
Iain.
On Thu, 26 Mar 2020, Chung-Lin Tang wrote:
> > Changes from v2:
> >
> > - Do not use `--tool_exec' with AM_RUNTESTFLAGS.
> >
> > - Move the definition of GCC_UNDER_TEST from
> >testsuite/libgomp-test-support.exp to
> >testsuite/libgomp-site-extra.exp.
>
> Hi Maciej,
> sorry, I didn't no
Hi!
This PR has been fixed by r10-7237-g4e3d3e40726e1b68bf52fa205c68495124ea60b8
already but we didn't have a comparable testcase.
Tested on x86_64-linux -m32/-m64, committed to trunk as obvious.
2020-04-01 Jakub Jelinek
PR middle-end/94436
* gcc.dg/pr94436.c: New test.
---
On Tue, Mar 31, 2020 at 03:44:51PM -0700, Richard Henderson wrote:
> If we add more CC modes, does that mean that we have to improve SELECT_CC_MODE
> to match those patterns? Or do we add new CC modes just so that combine's use
> of SELECT_CC_MODE *cannot* match them?
Adding new CC modes isn't he
Hi Iain,
> This patch splits up gdc-test.exp into multiple test scipts, one for
> each subdirectory containing test files, instead of having one test
> script to manage them all.
>
> This allows removing some workarounds, such as the need to create
> symlinks in the test run directory.
unfortunat
This does away with enabling -ffinite-loops at -O2+ for all languages
and instead enables it selectively for C++ only.
Jason, I didn't find a reference as to when the forward progress
guarantee was introduced to C++ so I randomly chose C++11, is that
correct?
Joseph, this simply never enables -ff
On Wed, Apr 01, 2020 at 03:36:30PM +0200, Richard Biener wrote:
> @@ -512,7 +512,10 @@ can_inline_edge_by_limits_p (struct cgraph_edge *e, bool
> report,
> /* When devirtualization is disabled for callee, it is not safe
>to inline it as we possibly mangled the type info
On Wed, 1 Apr 2020, Jakub Jelinek wrote:
> On Wed, Apr 01, 2020 at 03:36:30PM +0200, Richard Biener wrote:
> > @@ -512,7 +512,10 @@ can_inline_edge_by_limits_p (struct cgraph_edge *e,
> > bool report,
> > /* When devirtualization is disabled for callee, it is not safe
> > t
On Thu, 2020-03-26 at 14:23 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Mar 23, 2020 at 03:18:25PM -0500, will schmidt wrote:
> > Disable the code that limits initialization of builtins based
> > on the rs6000_builtin_mask. This allows all built-ins to be
> > properly referenced when bui
Adding gcc-patches as I had somehow deleted it from the addresses...
> -Original Message-
> From: Kyrylo Tkachov
> Sent: 01 April 2020 15:23
> To: Pop, Sebastian
> Cc: Wilco Dijkstra ; richard.hender...@linaro.org
> Subject: RE: [AArch64] Backporting -moutline-atomics to gcc 9.x and 8.x
>
Thanks Kyrill! I will be happy to test the gcc-8 back-port of the patches.
We would also need to back-port the patches to gcc-7.
I hope it is ok to commit the changes to the gcc-7 branch even if it is not a
maintained branch.
Sebastian
On 4/1/20, 9:27 AM, "Kyrylo Tkachov" wrote:
CAUTION
Hi Sebastian,
> -Original Message-
> From: Pop, Sebastian
> Sent: 01 April 2020 15:32
> To: Kyrylo Tkachov
> Cc: Wilco Dijkstra ; richard.hender...@linaro.org;
> gcc-patches@gcc.gnu.org
> Subject: Re: [AArch64] Backporting -moutline-atomics to gcc 9.x and 8.x
>
> Thanks Kyrill! I will
On Wed, Apr 01, 2020 at 02:32:03PM +, Pop, Sebastian via Gcc-patches wrote:
> Thanks Kyrill! I will be happy to test the gcc-8 back-port of the patches.
Note, I have another fix, PR94435, that I've already bootstrapped and am
regtesting ATM, that will need to be included in any backports too
Thanks Jakub and Kyrill to point that out.
We will create a new branch called gcc-7-aarch64-outline-atomics or so with the
back-ported patches.
Sebastian
On 4/1/20, 9:36 AM, "Jakub Jelinek" wrote:
CAUTION: This email originated from outside of the organization. Do not
click links or open
On Wed, 1 Apr 2020, Jason Merrill wrote:
> We represent 'this' in a default member initializer with a PLACEHOLDER_EXPR.
> Normally in constexpr evaluation when we encounter one it refers to
> ctx->ctor, but when we're creating a temporary of class type, that replaces
> ctx->ctor, so a PLACEHOLDER_
Hi all,
"use_service.cc" libstdc++ test does not compile for baremetal,
unfortunately AFAIK we don't have an appropriate selector to skip
these.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89760
https://gcc.gnu.org/legacy-ml/gcc-patches/2018-10/msg01089.html
While the full issue is tackled wou
> On Wed, 1 Apr 2020, Jakub Jelinek wrote:
>
> > On Wed, Apr 01, 2020 at 03:36:30PM +0200, Richard Biener wrote:
> > > @@ -512,7 +512,10 @@ can_inline_edge_by_limits_p (struct cgraph_edge *e,
> > > bool report,
> > > /* When devirtualization is disabled for callee, it is not safe
> > >
On 01/04/20 17:28 +0200, Andrea Corallo wrote:
Hi all,
"use_service.cc" libstdc++ test does not compile for baremetal,
unfortunately AFAIK we don't have an appropriate selector to skip
these.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89760
https://gcc.gnu.org/legacy-ml/gcc-patches/2018-10/m
On Wed, 1 Apr 2020, Martin Liška wrote:
> >> I've just installed the patch.
> >> @H.J. Can you please pull it to bintuils?
> >
> > Why didn't you use the commit as I published it
>
> Because it didn't fit my script that takes changelog entries
> and moves that to the corresponding ChangeLog fi
On 01/04/20 16:56 +0100, Jonathan Wakely wrote:
On 01/04/20 17:28 +0200, Andrea Corallo wrote:
Hi all,
"use_service.cc" libstdc++ test does not compile for baremetal,
unfortunately AFAIK we don't have an appropriate selector to skip
these.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89760
ht
On 4/1/20 12:54 PM, Iain Buclaw wrote:
On 01/04/2020 08:28, Stefan Liebler wrote:
ping
Thanks, I'll send the patch upstream, as it's the same there.
Looks OK to me.
Regards
Iain.
Thanks for committing the patch upstream
On 4/1/20 12:50 PM, Iain Buclaw wrote:
On 01/04/2020 08:28, Stefan Liebler wrote:
ping
Hi Stefan,
As I've already said, I think that the name should be __ibmz_get_tls_offset to
make clear that it is an internal function.
Other than that, looks good to me.
Iain.
Hi Iain,
Sorry. I've
Richard Henderson writes:
> On 3/31/20 11:34 AM, Richard Sandiford wrote:
>>> +(define_insn "*cmp3_carryinC"
>>> + [(set (reg:CC CC_REGNUM)
>>> + (compare:CC
>>> + (ANY_EXTEND:
>>> + (match_operand:GPI 0 "register_operand" "r"))
>>> + (plus:
>>> + (ANY_EXTEND:
>>> +
On 4/1/20 5:59 PM, Maciej W. Rozycki wrote:
On Wed, 1 Apr 2020, Martin Liška wrote:
I've just installed the patch.
@H.J. Can you please pull it to bintuils?
Why didn't you use the commit as I published it
Because it didn't fit my script that takes changelog entries
and moves that to the
On Wed, 1 Apr 2020, Jan Hubicka wrote:
> > On Wed, 1 Apr 2020, Jakub Jelinek wrote:
> >
> > > On Wed, Apr 01, 2020 at 03:36:30PM +0200, Richard Biener wrote:
> > > > @@ -512,7 +512,10 @@ can_inline_edge_by_limits_p (struct cgraph_edge
> > > > *e, bool report,
> > > > /* When devirt
The example code in the PR uses r2 (the TOC register) directly. In the
RTL generated for that, r2 is copied to some pseudo, and then cprop
propagates that into a "*tocref" insn, because nothing is
preventing it from doing that.
So, put the same condition in the insn condition for this as we will
Unfortunately the mailing list stripped off this attachment so we do
not have a chance to review. As attachments appear to be working
lately, please resubmit this patch.
Fritz
On Sun, Mar 8, 2020 at 8:58 AM Paul Richard Thomas
wrote:
>
> This is yet another case, where a deferred character lengt
Zackery Spytz via Gcc-patches writes:
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index e0e7f540c219..f1f2064df459 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -2817,7 +2817,7 @@ the same type as the target function. As a result of
> the @code{copy}
> attrib
On 4/1/20 9:28 AM, Richard Sandiford wrote:
> How important is it to describe the flags operation as a compare though?
> Could we instead use an unspec with three inputs, and keep it as :CC?
> That would still allow special-case matching for zero operands.
I'm not sure.
My guess is that the only
This simple patch was submitted some time ago (over 1 year), but got
lost without review. I have lately rebased and tested, and the patch
is still good. Is this OK to commit to trunk and for backport? I'd
like to port as far back as 7.
---
Fritz Reese
gcc/ChangeLog:
2020-04-01 Fritz Reese
From: Joerg Sonnenberger
I committed this patch for a typo spotted by Joerg Sonnenbecker:
2020-04-01 Joerg Sonnenberger
* doc/extend.texi (Common Function Attributes): Fix typo.
---
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index f1f2064..bde3748 100644
--- a/gcc/doc/ext
On Wed, 1 Apr 2020, Martin Liška wrote:
> > commit 142d68f50b48309f48e34fc1d9d6dbbeecfde684
> > Author: Martin Liska
> > AuthorDate: Wed Apr 1 09:37:37 2020 +0200
> > Commit: Martin Liska
> > CommitDate: Wed Apr 1 09:37:37 2020 +0200
> >
> > You're still listed as the author of the chan
Hello,
While working on the migration of our production
ports to gcc-9, we stumbled on a problem with the
behavioral changed introduced by
commit 0b7fb27b698da38fd13108ecc914613f85f66f9d
Author: Allan Sandfeld Jensen
Date: Fri Sep 21 01:38:24 2018 +0600
Fix and document -r option
On 3/30/20 3:50 AM, Richard Sandiford wrote:
> Peter Bergner via Gcc-patches writes:
>> * lower-subreg.c (pass_lower_subreg3::gate): Remove test for
>> flag_split_wide_types_early.
>>
>> diff --git a/gcc/lower-subreg.c b/gcc/lower-subreg.c
>> index 4c8bc835f93..807ad398b64 100644
>> ---
On Wed, Apr 1, 2020 at 1:19 PM Fritz Reese wrote:
[...]
> is still good. Is this OK to commit to trunk and for backport? I'd
> like to port as far back as 7.
I realized 7 branch is closed. I would backport to 8.
> gcc/testsuite/ChangeLog:
> 2020-04-01 Fritz Reese
>
>PR fortran/85982
>
Peter Bergner writes:
> On 3/30/20 3:50 AM, Richard Sandiford wrote:
>> Peter Bergner via Gcc-patches writes:
>>> * lower-subreg.c (pass_lower_subreg3::gate): Remove test for
>>> flag_split_wide_types_early.
>>>
>>> diff --git a/gcc/lower-subreg.c b/gcc/lower-subreg.c
>>> index 4c8bc835f9
Jason,
This is from pr94426, which is fallout from my pr94147 fix.
You added the following to no_linkage_check as part of
2018-11-12 Jason Merrill
Implement P0315R4, Lambdas in unevaluated contexts.
/* Lambda types that don't have mangling scope have no linkage. We
check CL
On 4/1/20 9:36 AM, Richard Biener wrote:
This does away with enabling -ffinite-loops at -O2+ for all languages
and instead enables it selectively for C++ only.
Jason, I didn't find a reference as to when the forward progress
guarantee was introduced to C++ so I randomly chose C++11, is that
corr
On Mon, Mar 30, 2020 at 05:51:49PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Mar 30, 2020 at 12:50:43PM -0500, will schmidt wrote:
> > On Fri, 2020-03-27 at 21:31 -0400, Michael Meissner via Gcc-patches
> > > * config/rs6000/rs6000.c (PCREL_SUPPORTED_BY_OS): New macro.
> > > (rs6000_o
PR analyzer/94378 reports a false -Wanalyzer-malloc-leak
when returning a struct containing a malloc-ed pointer.
The issue is that the assignment code was not handling
compound copies, only copying top-level values from region to region,
and not copying child values.
This patch introduces a regio
On 4/1/20 1:32 PM, Richard Sandiford wrote:
> Peter Bergner writes:
>> Have we come to consensus on whether to split the options or not?
>> I think Segher is against it given we actually have 3 passes of
>> lower-subreg and -fsplit-wide-types would control the 1st and 3rd
>> passes and -fsplit-wid
Hello again,
> On 01 Apr 2020, at 19:48, Olivier Hainque wrote:
>
>* gcc.c (LINK_COMMAND_SPEC): Handle -r like -nostdlib.
>
> Would it be possible to revert to the previous behavior
> and document it ?
>
> Or maybe allow it to be controllable by the target ports ?
>
> Or provide s
See
https://stackoverflow.com/questions/60972134/whats-wrong-with-the-following-fortran-code-gfortran-dtio-dummy-argument-at
Is A(:) a deferred-shape array or an assumed-shape array? The
answer of course depends on context.
This patch fixes the issue found at the above URL.
Index: gcc/fortran/
Complement commit bfe78b08471f ("RISC-V: Using fmv.x.w/fmv.w.x rather
than fmv.x.s/fmv.s.x") and document a binutils 2.30 requirement in the
installation manual, matching the addition of fmv.x.w/fmv.w.x mnemonics
to GAS.
gcc/
* doc/install.texi (Specific)
: Update binut
On Wed, Apr 01, 2020 at 09:20:31AM -0500, will schmidt wrote:
> On Thu, 2020-03-26 at 14:23 -0500, Segher Boessenkool wrote:
> > On Mon, Mar 23, 2020 at 03:18:25PM -0500, will schmidt wrote:
> > > Disable the code that limits initialization of builtins based
> > > on the rs6000_builtin_mask. Thi
Olivier Hainque wrote:
Hello again,
On 01 Apr 2020, at 19:48, Olivier Hainque wrote:
* gcc.c (LINK_COMMAND_SPEC): Handle -r like -nostdlib.
Would it be possible to revert to the previous behavior
and document it ?
Or maybe allow it to be controllable by the target ports ?
perh
The fsf.org server now has a redirect to the gnu.org server; let's
follow that.
This is my first commit to libstdc++ using git, my first squashing
(since I had a follow tweak to the ChangeLog), and my first --amend.
Please advise if I can/should do something better.
Thank you,
Gerald
*
Hello Iain,
> On 1 Apr 2020, at 22:42, Iain Sandoe wrote:
>
> perhaps I’m missing something here, but it is quite possible for a target
> to override and provide a customised version of LINK_COMMAND_SPEC.
>
> Darwin does this: see config/darwin.h
>
> So, AFAIU, a port owner has the last call o
Hi!
The following testcase ICEs, because aarch64_gen_compare_reg_maybe_ze emits
invalid RTL.
For y_mode [QH]Imode it expects y to be of that mode (or CONST_INT that fits
into that mode) and x being SImode; for non-CONST_INT y it zero extends y
into SImode and compares that against x, for CONST_INT
Hi,
This patch fixes the test for PR92216 to also succeed on 16 and 32-bit
targets. The symbol being scanned for only matched on 64-bit targets
where the this pointer offset is 16.
Tested on x86_64-linux-gnu with -m32 and -mx32. Also checked avr-gcc
for what output comes from a 16-bit compiler.
On Wed, Apr 01, 2020 at 03:16:52PM -0400, Michael Meissner wrote:
> > > > -/* Support for a future processor's features. Do not enable -mpcrel
> > > > until it
> > > > - is fully functional. */
> > > > +/* Support for a future processor's features. We do not set -mpcrel
> > > > or
> > > > +
Hi,
This patch adjusts another test in gdc.dg that was reported to be
failing in PR94315.
The scan-file match is likely too strict to always succeed, so instead
have split it up into a set of smaller matches.
Tested on x86_64-linux-gnu and committed to mainline.
Regards
Iain.
---
gcc/testsuit
On Wed, 25 Mar 2020 at 01:24, Pop, Sebastian via Gcc-patches
wrote:
>
> Hi Kyrill,
>
> Thanks for pointing out the two missing bug fixes.
> Please see attached all the back-ported patches.
> All the patches from trunk applied cleanly with no conflicts (except for the
> ChangeLog files) to the gcc
On 3/31/20 3:50 PM, Patrick Palka wrote:
On Tue, 31 Mar 2020, Jason Merrill wrote:
On 3/30/20 6:46 PM, Patrick Palka wrote:
On Mon, 30 Mar 2020, Jason Merrill wrote:
On 3/30/20 3:58 PM, Patrick Palka wrote:
On Thu, 26 Mar 2020, Jason Merrill wrote:
On 3/22/20 9:21 PM, Patrick Palka wrote:
On 4/1/20 6:29 PM, Jason Merrill wrote:
On 3/31/20 3:50 PM, Patrick Palka wrote:
On Tue, 31 Mar 2020, Jason Merrill wrote:
On 3/30/20 6:46 PM, Patrick Palka wrote:
On Mon, 30 Mar 2020, Jason Merrill wrote:
On 3/30/20 3:58 PM, Patrick Palka wrote:
On Thu, 26 Mar 2020, Jason Merrill wrote:
On Mon, Mar 30, 2020 at 4:09 AM Richard Biener via Gcc-patches
wrote:
>
> On Mon, Mar 30, 2020 at 12:24 PM Kewen.Lin wrote:
> >
> > Hi,
> >
> > As PR94043 shows, my commit r10-4524 exposed one issue in
> > vectorizable_live_operation, which inserts one extra BB
> > before the single exit, leading
On Wed, Apr 01, 2020 at 04:36:05PM -0500, Segher Boessenkool wrote:
> On Wed, Apr 01, 2020 at 03:16:52PM -0400, Michael Meissner wrote:
> > > > > -/* Support for a future processor's features. Do not enable -mpcrel
> > > > > until it
> > > > > - is fully functional. */
> > > > > +/* Support for
On Wed, 1 Apr 2020, Martin Li?ka wrote:
> On 4/1/20 7:01 AM, Hans-Peter Nilsson wrote:
> > On Tue, 31 Mar 2020, Maciej W. Rozycki wrote:
> > > Correct an issue with GCC commit 906b3eb9df6c ("Improve endianess
> > > detection.") and fix a typo in the __BYTE_ORDER fallback macro check
> > > that cau
I have also seen this error in tsan.
The fix is
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ea376dd471a3b006bc48945c1d9a29408ab17a04
"Fix shrinkwrapping interactions with atomics (PR92692)".
This fix got committed as the last patch in the series.
Sebastian
On 4/1/20, 5:13 PM, "Christophe Lyon
Hello,
An Internal Compiler Error(ICE) is found in ipa-sra optimization pass when it
handle the argument of internal call svst3 for SVE.
The problem comes from gcc/testsuite/gcc.target/aarch64/sve/acle/asm/st2_bf16.c
in the test suit, which can be reduced to flowing code:
#include
#include
vo
On 4/1/20 10:47 AM, Patrick Palka wrote:
On Wed, 1 Apr 2020, Jason Merrill wrote:
We represent 'this' in a default member initializer with a PLACEHOLDER_EXPR.
Normally in constexpr evaluation when we encounter one it refers to
ctx->ctor, but when we're creating a temporary of class type, that r
Hi,
I've created a bug for this issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94442
And I'm going to solve this problem by propagating def's insn to its use
when they are at the same loop in fwprop pass.
I mean something like:
diff --git a/gcc/fwprop.c b/gcc/fwprop.c
index 705d2885a
91 matches
Mail list logo
