On 3/26/20 11:49 PM, Patrick Palka wrote:
On Thu, 26 Mar 2020, Jason Merrill wrote:
On 3/26/20 6:36 PM, Patrick Palka wrote:
On Thu, 26 Mar 2020, Jason Merrill wrote:
On 3/26/20 5:28 PM, Patrick Palka wrote:
This adds support to detect and recover from the case where an opening
brace
immedi
On Mon, 9 Mar 2020, Patrick Palka wrote:
> The first patch tries to avoid changing our current default diagnostics. But
> for the sake of consistency we arguably should also respect
> current_constraint_diagnosis_depth in diagnose_compound_requirement() like we
> do
> in the other error-replayin
On Mon, 16 Mar 2020, Patrick Palka wrote:
> Hi Martin,
>
> On Sun, 15 Mar 2020, Martin Sebor wrote:
>
> > On 3/11/20 4:18 PM, Patrick Palka via Gcc-patches wrote:
> > ...
> > > Hmm, like this? This version introduces a new static member function
> > > diagnosing_failed_constraint::replay_errors
On Thu, 26 Mar 2020, Jason Merrill wrote:
> On 3/26/20 6:36 PM, Patrick Palka wrote:
> > On Thu, 26 Mar 2020, Jason Merrill wrote:
> >
> > > On 3/26/20 5:28 PM, Patrick Palka wrote:
> > > > This adds support to detect and recover from the case where an opening
> > > > brace
> > > > immediately fo
On 3/26/20 3:13 PM, Jakub Jelinek wrote:
Hi!
My recent change to get_narrower/warnings_for_convert_and_check broke
the following testcase, warnings_for_convert_and_check is upset that
expr is a COMPOUND_EXPR with INTEGER_CST at the rightmost operand, while
result is a COMPOUND_EXPR with a NOP_EX
On 3/26/20 3:39 PM, Jakub Jelinek wrote:
Hi!
The following testcase FAILs -fcompare-debug, because if we emit a
-Wreturn-local-addr warning, we tsubst decltype in order to print the
warning and as that function could throw, set_flags_from_callee during that
sets cp_function_chain->can_throw and
On 3/26/20 6:31 PM, Marek Polacek wrote:
This came up on the C++ core list recently. We don't diagnose the case
when 'template' is followed by a destructor name which is not permitted
by [temp.names]/5.
OK.
PR c++/94336 - template keyword accepted before destructor names.
* p
On 3/26/20 6:36 PM, Patrick Palka wrote:
On Thu, 26 Mar 2020, Jason Merrill wrote:
On 3/26/20 5:28 PM, Patrick Palka wrote:
This adds support to detect and recover from the case where an opening brace
immediately follows the start of a requires-clause. So rather than emitting
the
error
e
Attribute copy can be invoked with an expression argument to copy from
the expression's type. However, it must avoid passing the expression
as the last (optional) argument to decl_attributes because the function
is only prepared to deal with DECLs and types.
The attached patch passes null as the
On 2020/3/27 07:59, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Mar 25, 2020 at 11:15:22PM -0500, luo...@linux.ibm.com wrote:
>> frame_pointer_needed is set to true in reload pass setup_can_eliminate,
>> but regs_ever_live[31] is false, so pro_and_epilogue doesn't save/restore
>> r31 even it is
Matthias Klose writes:
Thanks so much for all of you for pay attention and take care of
this. Matthias and Segher point out this; Joseph helped remove this
file. Sorry for spend your extra time on this.
Thanks again!
> diff --git a/a b/a
> new file mode 100644
> index 000..a4f422403ef
On Mar 26, 2020, Jakub Jelinek wrote:
> The hardest issue I gave up completely on after trying 3 different
> approaches is PR93786, I just don't know what to do in that case.
struct S {virtual void v();};
void f(S * s) {
({ s; })->v();
}
Thanks, I can now see how markers create situations tha
On 3/26/20 4:57 PM, Martin Sebor wrote:
On 3/25/20 3:56 PM, Jason Merrill wrote:
On 3/16/20 4:41 PM, Martin Sebor wrote:
The recent fix to avoid modifying in place the type argument in
handle_access_attribute (PR 92721) was incomplete and didn't fully
resolve the problem (an ICE in the C++ fron
Hi.
I failed to comment out some test printing before committing the testcase.
However, for that to work, we need to include on Linux platforms.
tested on x86_64-linux-gnu, applied to master.
thanks
Iain
2020-03-27 Iain Sandoe
* g++.dg/coroutines/torture/symmetric-transfer-0
Hi!
On Wed, Mar 25, 2020 at 11:15:22PM -0500, luo...@linux.ibm.com wrote:
> frame_pointer_needed is set to true in reload pass setup_can_eliminate,
> but regs_ever_live[31] is false, so pro_and_epilogue doesn't save/restore
> r31 even it is used actually, causing CPU2006 465.tonto segment fault of
On Thu, Mar 26, 2020 at 08:41:41PM -0300, Alexandre Oliva wrote:
> On Mar 26, 2020, Jakub Jelinek wrote:
>
> > Or disable -gstatement-frontiers by default and declare it -fcompare-debug
> > incompatible.
>
> I don't get what makes debug stmts introduced by -gstatement-frontiers
> special in this
Hi!
This define_insn has two issues.
One is that with -mavx512f -mno-avx512vl it can emit an AVX512VL-only insn
- 128-bit or 256-bit EVEX encoded vpternlog{d,q}.
Another one is that because there is no vpternlog{b,w}, we emit vpternlogd
instead, but then we shouldn't pretend we support masking of
On Mar 26, 2020, Jakub Jelinek wrote:
> Or disable -gstatement-frontiers by default and declare it -fcompare-debug
> incompatible.
I don't get what makes debug stmts introduced by -gstatement-frontiers
special in this regard. I recall working a lot on making statement list
management compatible
On Wed, Mar 25, 2020 at 05:59:36PM -0600, Jeff Law via Gcc-patches wrote:
> Sorry. I know you asked me to look at this eons ago, but ever time I just get
> lost.
>
> I get the distinct impression that we could do something much simpler (the
> patch
> you initially proposed for backporting to the
I have removed both calls to remove_attribute because with the changes
to calls.c they are no longer needed. The revised patch is attached.
I will plan to commit it tomorrow unless there's something else.
In hindsight, I think changing the attribute from the human-readable
form to the internal,
On Thu, 26 Mar 2020, David Malcolm wrote:
> On Thu, 2020-03-26 at 17:28 -0400, Patrick Palka via Gcc-patches wrote:
> > This adds support to detect and recover from the case where an
> > opening brace
> > immediately follows the start of a requires-clause. So rather than
> > emitting the
> > erro
On 3/26/20 4:16 PM, Jason Merrill wrote:
On 3/26/20 2:58 PM, Martin Sebor wrote:
On 3/25/20 11:36 PM, Jason Merrill wrote:
On 3/23/20 12:50 PM, Martin Sebor wrote:
On 3/23/20 8:49 AM, Jason Merrill wrote:
On 3/21/20 5:59 PM, Martin Sebor wrote:
+ /* Diagnose class/struct/union mismatches
On Thu, 26 Mar 2020, Jason Merrill wrote:
> On 3/26/20 5:28 PM, Patrick Palka wrote:
> > This adds support to detect and recover from the case where an opening brace
> > immediately follows the start of a requires-clause. So rather than emitting
> > the
> > error
> >
> >error: expected prima
This came up on the C++ core list recently. We don't diagnose the case
when 'template' is followed by a destructor name which is not permitted
by [temp.names]/5.
PR c++/94336 - template keyword accepted before destructor names.
* parser.c (cp_parser_unqualified_id): Give an error
On Thu, 26 Mar 2020, Jason Merrill wrote:
> On 3/26/20 5:24 PM, Patrick Palka wrote:
> > On Wed, 25 Mar 2020, Jason Merrill wrote:
> >
> > > On 3/25/20 12:17 PM, Patrick Palka wrote:
> > > > This PR reports that the requires-expression in
> > > >
> > > > auto f = [] { };
> > > > static_a
On 3/26/20 2:58 PM, Martin Sebor wrote:
On 3/25/20 11:36 PM, Jason Merrill wrote:
On 3/23/20 12:50 PM, Martin Sebor wrote:
On 3/23/20 8:49 AM, Jason Merrill wrote:
On 3/21/20 5:59 PM, Martin Sebor wrote:
+ /* Diagnose class/struct/union mismatches. IS_DECLARATION
is false
+ for ali
On Thu, 2020-03-26 at 17:28 -0400, Patrick Palka via Gcc-patches wrote:
> This adds support to detect and recover from the case where an
> opening brace
> immediately follows the start of a requires-clause. So rather than
> emitting the
> error
>
> error: expected primary-expression before '{'
Hi!
On Tue, Mar 24, 2020 at 01:26:25PM -0500, will schmidt wrote:
> Update existing testcase powerpc/bswap64-4.c to
> reflect that we generate ldbrx and stdbrx instructions
> for newer cpu targets. This is in contrast to the
> pair of lwbrx and stwbrx instructions that are
> generated with old
On 3/26/20 3:44 PM, Marek Polacek wrote:
On Thu, Mar 26, 2020 at 01:43:28AM -0400, Jason Merrill wrote:
I think you want to check all typedefs like in e.g. find_parameter_packs_r;
if the name is a typedef, it's only suitable if
alias_template_specialization_p.
..this: Since alias_template_spec
On Tue, 24 Mar 2020, Mike Stump wrote:
> > Have we made any conclusions WRT the way to move forward with this stuff?
> > Things remain broken and I'd prefer to get the issues off the plate while
> > the stuff is hot, or at least mildly warm. I'm about to get distracted
> > with other work.
>
On Thu, 2020-03-26 at 12:38 -0600, Jeff Law wrote:
> On Wed, 2020-03-25 at 23:10 -0400, Hans-Peter Nilsson wrote:
> > On Wed, 25 Mar 2020, Jeff Law via Gcc-patches wrote:
> >
> > The patch you sent, as well as what you committed as r10-7383,
> > was just a ChangeLog entry.
> >
> > > Bootstrapped
On 3/26/20 5:24 PM, Patrick Palka wrote:
On Wed, 25 Mar 2020, Jason Merrill wrote:
On 3/25/20 12:17 PM, Patrick Palka wrote:
This PR reports that the requires-expression in
auto f = [] { };
static_assert(requires { f(); });
erroneously evaluates to false. The way we end up evaluatin
On 3/26/20 5:28 PM, Patrick Palka wrote:
This adds support to detect and recover from the case where an opening brace
immediately follows the start of a requires-clause. So rather than emitting the
error
error: expected primary-expression before '{' token
followed by a slew of irrevelant er
This adds support to detect and recover from the case where an opening brace
immediately follows the start of a requires-clause. So rather than emitting the
error
error: expected primary-expression before '{' token
followed by a slew of irrevelant errors, we now assume the user had intended to
On Wed, 25 Mar 2020, Jason Merrill wrote:
> On 3/25/20 12:17 PM, Patrick Palka wrote:
> > This PR reports that the requires-expression in
> >
> >auto f = [] { };
> >static_assert(requires { f(); });
> >
> > erroneously evaluates to false. The way we end up evaluating to false goes
> > a
On 3/25/20 3:56 PM, Jason Merrill wrote:
On 3/16/20 4:41 PM, Martin Sebor wrote:
The recent fix to avoid modifying in place the type argument in
handle_access_attribute (PR 92721) was incomplete and didn't fully
resolve the problem (an ICE in the C++ front-end). The attached
patch removes the r
Hi!
On 2020-03-26T09:09:01-0600, Sandra Loosemore wrote:
> On 3/26/20 8:27 AM, Thomas Schwinge wrote:
>> Note that as this code is shared between OpenACC/OpenMP, this might
>> affect OpenMP, too, as far as I can tell. (Subject updated.) Jakub, can
>> you please have a look, too?
>>
>> On 2020-0
On Thu, Mar 26, 2020 at 01:43:28AM -0400, Jason Merrill wrote:
> > > I think you want to check all typedefs like in e.g.
> > > find_parameter_packs_r;
> > > if the name is a typedef, it's only suitable if
> > > alias_template_specialization_p.
> >
> > ..this: Since alias_template_specialization_p
Hi!
The following testcase FAILs -fcompare-debug, because if we emit a
-Wreturn-local-addr warning, we tsubst decltype in order to print the
warning and as that function could throw, set_flags_from_callee during that
sets cp_function_chain->can_throw and later on we don't set TREE_NOTHROW
on foo.
On 3/22/20 9:21 PM, Patrick Palka wrote:
This patch relaxes an assertion in tsubst_default_argument that exposes a latent
bug in how we substitute an array type into a cv-qualified wildcard function
parameter type. Concretely, the latent bug is that given the function template
template void
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 building code using #pragma for cpu
> targets newer than what was specified
Hi!
My recent change to get_narrower/warnings_for_convert_and_check broke
the following testcase, warnings_for_convert_and_check is upset that
expr is a COMPOUND_EXPR with INTEGER_CST at the rightmost operand, while
result is a COMPOUND_EXPR with a NOP_EXPR of INTEGER_CST at the rightmost
operand,
On 3/25/20 11:36 PM, Jason Merrill wrote:
On 3/23/20 12:50 PM, Martin Sebor wrote:
On 3/23/20 8:49 AM, Jason Merrill wrote:
On 3/21/20 5:59 PM, Martin Sebor wrote:
+ /* Diagnose class/struct/union mismatches. IS_DECLARATION is
false
+ for alias definition. */
+ bool decl_class
On Wed, 2020-03-25 at 23:10 -0400, Hans-Peter Nilsson wrote:
> On Wed, 25 Mar 2020, Jeff Law via Gcc-patches wrote:
>
> The patch you sent, as well as what you committed as r10-7383,
> was just a ChangeLog entry.
>
> > Bootstrapped on sh4-linux-gnu and sh4eb-linux-gnu. Regression testing in
> >
Hi!
On Mon, Mar 23, 2020 at 06:37:52PM +, Richard Sandiford wrote:
> g:497498c878d48754318e486428e2aa30854020b9 caused lra to cycle
> on some SDmode reloads for power6. As explained in more detail
> in the PR comments, the problem was a conflict between two target
> hooks: rs6000_secondary_me
>
> Why don't we represent the alias at the cgraph level? That is,
> why do decls come into play at all here? b prevails and it has a
> reference to a.c:a so we need to keep (and emit) that. The only issue
> would be that we'd end up with two 'a's so we have to notice that
> and fixup somehow.
Hi!
On Mon, Mar 23, 2020 at 12:21:03PM +1030, Alan Modra wrote:
> On Wed, Mar 18, 2020 at 04:53:59PM -0500, Segher Boessenkool wrote:
> > Could you please send a new patch (could be the same patch even) that
> > is easier to review for me?
>
> The PLT is volatile. On PowerPC it is a bss style se
> > Is it? What does a non-weak local alias to a weak function mean?
>
> I think we should continue to try to model ELF semantics re weak and
> aliases. If so, then yes, LTO gets it wrong and the above testcase should
> not abort. Weak doesn't enter the picture for creating aliases (the
> al
On Mon, 2020-03-09 at 17:56 +0100, Martin Liška wrote:
> On 3/9/20 4:36 PM, H.J. Lu wrote:
> > We nee to support different variables, like TLS, data and bss variables.
>
> Why do we need TLS? Right now, it's not supported by nm. Or am I wrong?
>
> About BSS and DATA I agree that it would be handy
Hi!
On 2020-03-25T18:09:25+0100, I wrote:
> On 2018-02-22T12:23:25+0100, Tom de Vries wrote:
>> when using cuda 9 nvprof with an openacc executable, the executable hangs.
> What Frederik has discovered today in the hard way... is that the og9
> version of this patch did get its code altered in a
Hello,
On Thu, 26 Mar 2020, Richard Biener wrote:
> > = b.c:
> >
> > __attribute__((weak))
> > __attribute__((noinline))
> >
> > int a()
> > {
> > return 1;
> > }
> >
> > __attribute__((noinline))
> > static int b() __attribute__((alias("a")));
> > void
> > test()
> > {
> > if (b()!=1)
On Thu, 2020-03-26 at 05:06 -0500, luoxhu--- via Gcc-patches wrote:
> From: Xionghu Luo
>
> Remove split code from add3 to allow a later pass to split.
> This allows later logic to hoist out constant load in add
> instructions.
> In loop, lis+ori could be hoisted out to improve performance compar
On Wed, 2020-03-25 at 23:15 -0500, luoxhu--- via Gcc-patches wrote:
> From: Xionghu Luo
>
Hi,
No real issues noted in my review. Patch is straighforward, just a
couple cosmetic comments inline below.
> This P1 bug is exposed by FRE refactor of r263875. Comparing the fre
> dump file shows no o
On 3/26/20 8:27 AM, Thomas Schwinge wrote:
Hi!
Note that as this code is shared between OpenACC/OpenMP, this might
affect OpenMP, too, as far as I can tell. (Subject updated.) Jakub, can
you please have a look, too?
On 2020-03-25T23:02:38-0600, Sandra Loosemore wrote:
The attached patch fix
On Thu, 26 Mar 2020, Jan Hubicka wrote:
> Hi,
> this patch started as an attempt to fix pr64706 that kept me walking in loops
> for some time (I failed to make a hack that would make the testcase work in
> all
> basic settings of -O0/2 -flto set on the both files independently. All GCC
> releases
Hi My Friend,
Hope you everything is well.
Now the Coronavirus has spread very seriously, please take care,
If you need other support please let us know, thanks .
Our factory still working, If you need any blinds and shades we will send the
goods ASAP.
With best regards,
Max Xie
Chief Sales
Hi!
Note that as this code is shared between OpenACC/OpenMP, this might
affect OpenMP, too, as far as I can tell. (Subject updated.) Jakub, can
you please have a look, too?
On 2020-03-25T23:02:38-0600, Sandra Loosemore wrote:
> The attached patch fixes a bug I found in the C++ front end's hand
Hi,
this patch started as an attempt to fix pr64706 that kept me walking in loops
for some time (I failed to make a hack that would make the testcase work in all
basic settings of -O0/2 -flto set on the both files independently. All GCC
releases crashes on some).
The testcase has ODR violation tha
Not sure where the original URL came from, but it does not work, so
I looked this up in the mailing list archive and updated it.
Pushed.
Gerald
---
htdocs/index.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/index.html b/htdocs/index.html
index edeeb817..d14d432
* include/std/chrono (chrono::days, chrono::weeks, chrono::years)
(chrono::months, chrono::sys_days, chrono::local_t)
(chrono::local_time, chrono::local_seconds, chrono::local_days):
Define for C++20.
(chrono::time_point): Add missing static assert.
*
On 3/26/20 1:42 PM, Jan Hubicka wrote:
Hi.
I'm suggesting to provide a warning when one uses -flto=jobserver
but we can't detect job server for some reason.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed in next stage1?
Thanks,
Martin
gcc/ChangeLo
> Hi.
>
> I'm suggesting to provide a warning when one uses -flto=jobserver
> but we can't detect job server for some reason.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed in next stage1?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2020-03-2
On Thu, Mar 26, 2020 at 12:01 PM Kewen.Lin wrote:
>
> Hi Richi,
>
> on 2020/3/25 下午4:25, Richard Biener wrote:
> > On Tue, Mar 24, 2020 at 9:30 AM Kewen.Lin wrote:
> >>
> >> Hi,
> >>
> >> The new version with refactoring has been attached.
> >> Bootstrapped/regtested on powerpc64le-linux-gnu (LE)
On 3/25/20 5:40 PM, Iain Sandoe wrote:
Nathan Sidwell wrote:
On 3/24/20 2:08 PM, Iain Sandoe wrote:
tree suspend = TREE_VEC_ELT (awaiter_calls, 1); /* await_suspend(). */
+ tree susp_type;
+ if (tree fndecl = cp_get_callee_fndecl_nofold (suspend))
+susp_type = TREE_TYPE (TREE_TYPE
On 3/25/20 3:46 PM, Iain Sandoe wrote:
Hi,
Iain Sandoe wrote:
This is the first of two remaining changes needed to bring the GCC
implementation into line with the standard draft at n4849.
Here is a revised version with the “initial await resume called” variable
renamed to be more consistent
[Arm] Implement CDE intrinsics for MVE registers.
Implement CDE intrinsics on MVE registers.
Other than the basics required for adding intrinsics this patch consists
of three changes.
** We separate out the MVE types and casts from the arm_mve.h header.
This is so that the types can be used in
Dear Paul,
OK – thanks for the patch.
Tobias
PS: I assume that the spacing issue in the patch
is due to the mail program.
On 3/26/20 12:20 PM, Paul Richard Thomas via Fortran wrote:
This turned out to be relatively trivial, following a fair amount of
head scratching:-(
Regtests on FC31/x64_
This turned out to be relatively trivial, following a fair amount of
head scratching:-(
Regtests on FC31/x64_86 - OK for both branches?
Paul
2020-03-26 Paul Thomas
PR fortran/94246
* expr.c (scalarize_intrinsic_call): Remove the error checking.
Make a copy of the expression to be
Hi Richi,
on 2020/3/25 下午4:25, Richard Biener wrote:
> On Tue, Mar 24, 2020 at 9:30 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> The new version with refactoring has been attached.
>> Bootstrapped/regtested on powerpc64le-linux-gnu (LE) P8 and P9.
>>
>> Is it ok for trunk?
>
> Yes.
>
Thanks! I'm sorry
The recent patch to convert all thumb1 code in libgcc to unified syntax
ommitted the conditional code that is used only when building the
library for minimal size. This patch fixes this case.
I've also fixed the COND macro so that a single definition is always
used that is for unified syntax. Th
On Thu, 26 Mar 2020, Jakub Jelinek wrote:
> Hi!
>
> On Thu, Mar 26, 2020 at 10:24:29AM +0100, Richard Biener wrote:
> > On Thu, 26 Mar 2020, Jakub Jelinek wrote:
> >
> > > On Thu, Mar 26, 2020 at 10:14:35AM +0100, Richard Biener wrote:
> > > > Ick. I fear we really need a better way of dealing
Hi!
On Thu, Mar 26, 2020 at 10:24:29AM +0100, Richard Biener wrote:
> On Thu, 26 Mar 2020, Jakub Jelinek wrote:
>
> > On Thu, Mar 26, 2020 at 10:14:35AM +0100, Richard Biener wrote:
> > > Ick. I fear we really need a better way of dealing with this
> > > STATEMENT_LIST appearance with only -g ..
From: Xionghu Luo
Remove split code from add3 to allow a later pass to split.
This allows later logic to hoist out constant load in add instructions.
In loop, lis+ori could be hoisted out to improve performance compared with
previous addis+addi (About 15% on typical case), weak point is
one more
On Thu, Mar 26, 2020 at 10:46:48AM +0100, Martin Liška wrote:
> 2020-03-26 Martin Liska
>
> * gcc.target/i386/pr81213.c: Do not scan assembler
> and add one missing PR entry.
Ok.
> ---
> gcc/testsuite/gcc.target/i386/pr81213.c | 5 +
> 1 file changed, 1 insertion(+), 4 deleti
On 3/26/20 10:23 AM, Jakub Jelinek wrote:
On Mon, Mar 23, 2020 at 04:09:52PM +0100, Martin Liška wrote:
2020-03-17 Martin Liska
PR target/93274 PR lto/94271
* gcc.target/i386/pr81213-2.c: New test.
* gcc.target/i386/pr81213.c: Add additional source.
* gcc.dg/l
Hi.
I'm suggesting to provide a warning when one uses -flto=jobserver
but we can't detect job server for some reason.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed in next stage1?
Thanks,
Martin
gcc/ChangeLog:
2020-03-26 Martin Liska
I pushed the following update.
2020-03-26 Richard Biener
* gcc-10/changes.html: Document --param allow-store-data-races
change.
---
htdocs/gcc-10/changes.html | 9 +
1 file changed, 9 insertions(+)
diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
On Thu, 26 Mar 2020, Jakub Jelinek wrote:
> On Thu, Mar 26, 2020 at 10:14:35AM +0100, Richard Biener wrote:
> > Ick. I fear we really need a better way of dealing with this
> > STATEMENT_LIST appearance with only -g ...
>
> Yeah, it is very ugly and in some PRs I'm out of ideas what to do.
I th
On Mon, Mar 23, 2020 at 04:09:52PM +0100, Martin Liška wrote:
> 2020-03-17 Martin Liska
>
> PR target/93274 PR lto/94271
> * gcc.target/i386/pr81213-2.c: New test.
> * gcc.target/i386/pr81213.c: Add additional source.
> * gcc.dg/lto/pr94271_0.c: New test.
> * gcc.d
On Thu, Mar 26, 2020 at 10:14:35AM +0100, Richard Biener wrote:
> Ick. I fear we really need a better way of dealing with this
> STATEMENT_LIST appearance with only -g ...
Yeah, it is very ugly and in some PRs I'm out of ideas what to do.
Jakub
Hi Bin,
Bin.Cheng via Gcc-patches wrote:
On Mon, Mar 16, 2020 at 5:34 PM Bin.Cheng wrote:
On Wed, Mar 11, 2020 at 5:07 PM Iain Sandoe wrote:
Bin.Cheng wrote:
On Thu, Mar 5, 2020 at 10:18 PM Iain Sandoe wrote:
With current trunk + Bin’s two approved patches.
I see no change in the t
On Thu, 26 Mar 2020, Jakub Jelinek wrote:
> Hi!
>
> The following testcase FAILs since recently when the C++ FE started calling
> protected_set_expr_location more often.
> With -g, it is called on a STATEMENT_LIST that contains a DEBUG_BEGIN_STMT
> and CLEANUP_POINT_EXPR, and as STATEMENT_LISTs h
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Finnish team of translators. The file is available at:
https://translationproject.org/latest/gcc/fi.po
(This file, 'gcc-10.1-b20200322.fi.po'
There are 2 more nits needed for the test-case fix.
I'm going to install this version.
Martin
>From 3aece9a2f2eed08c91d5f52d5481701d01bc3a90 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Thu, 26 Mar 2020 10:07:06 +0100
Subject: [PATCH] Skip test for non-x86 targets.
gcc/testsuite/ChangeLog:
Hi Martin,
> The test-case only works on x86 targets.
> I'm going to install the patch.
as noted in the PR, you also need
/* { dg-require-ifunc "" } */
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielef
On Thu, 26 Mar 2020, Jakub Jelinek wrote:
> Hi!
>
> The following testcase FAILs, because gimplify_body adds a GIMPLE_NOP only
> when there are no statements in the function and with -g there is a
> DEBUG_BEGIN_STMT, so it doesn't add it and due to -fno-tree-dce that never
> gets removed afterwar
Hi.
The test-case only works on x86 targets.
I'm going to install the patch.
Martin
gcc/testsuite/ChangeLog:
2020-03-26 Martin Liska
PR testsuite/94334
* gcc.dg/lto/pr94271_0.c: Skip for non-x86 targets.
---
gcc/testsuite/gcc.dg/lto/pr94271_0.c | 1 +
1 file changed, 1 ins
Hi!
The following testcase FAILs since recently when the C++ FE started calling
protected_set_expr_location more often.
With -g, it is called on a STATEMENT_LIST that contains a DEBUG_BEGIN_STMT
and CLEANUP_POINT_EXPR, and as STATEMENT_LISTs have !CAN_HAVE_LOCATION_P,
nothing is set. Without -g,
Hi!
The following testcase FAILs, because gimplify_body adds a GIMPLE_NOP only
when there are no statements in the function and with -g there is a
DEBUG_BEGIN_STMT, so it doesn't add it and due to -fno-tree-dce that never
gets removed afterwards. Similarly, if the body seq after gimplification
co
This is the second such case in the tree. Thanks to Frank Ch. Eigler
for the updated link.
Pushed.
Gerald
---
htdocs/gcc-4.8/changes.html | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/htdocs/gcc-4.8/changes.html b/htdocs/gcc-4.8/changes.html
index 83f7da6c..60cf4d42 100
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Thursday, March 26, 2020 3:37 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [RFC] Should widening_mul should consider block frequency?
>
> >
> > That's a good point. I have att
On Thu, Mar 26, 2020 at 2:06 AM Yangfei (Felix) wrote:
>
> Hi!
>
> > -Original Message-
> > From: Richard Biener [mailto:richard.guent...@gmail.com]
> > Sent: Tuesday, March 24, 2020 10:14 PM
> > To: Yangfei (Felix)
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [RFC] Should widening_mu
92 matches
Mail list logo
