Richard Biener writes:
> On Wed, 27 Mar 2019, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > Our beloved condition combining code to BIT_FIELD_REFs miscompiles
>> > the testcase because it relies on operand_equal_p to detect equal
>> > bases. For some reason that very same
On Mon, 25 Mar 2019, Richard Biener wrote:
>
> This PR and possibly quite some dups that have been accumulating lately
> run into an artifact of DCEs edge removal code when generating debug
> stmts. Here DCE removes edges from the CFG at the same time it removes
> dead controlling stmts but
Hi.
While I was working on PR84201 it was very handy for me to use debug counters
for a particular source file. That's because I can't run a verification
on a spec result and I was unable to persuade runspec command to use a modified
binary
for run.
Thus's I'm suggesting extension of the option
gcc/ChangeLog:
2019-03-27 Martin Liska
* dbgcnt.c (dbg_cnt_process_single_pair): Fix GNU coding style.
(dbg_cnt_process_opt): Parse first tokens aas
dbg_cnt_process_single_pair is also using strtok.
---
gcc/dbgcnt.c | 25 +++--
1 file changed, 15
gcc/ChangeLog:
2019-03-27 Martin Liska
* dbgcnt.c (dbg_cnt_set_limit_by_name): Add new argument
aux_base and filter based on aux_base_name.
(dbg_cnt_process_single_pair): Parse aux_base.
* doc/invoke.texi: Document new extended format.
gcc/ChangeLog:
2019-03-27 Martin Liska
* dbgcnt.c (print_limit_reach): New function.
(dbg_cnt): Use it.
---
gcc/dbgcnt.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/gcc/dbgcnt.c b/gcc/dbgcnt.c
index
Dear Paul,
Here are further bug reports, mostly on the various functions for manipulating
descriptors:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89843
Hi Reinhold,
Many thanks - the bug number is out by one on the last. Jakub Jelnik
got one in before it :-)
I'll take a look this afternoon.
Cheers
Paul
On Wed, 27 Mar 2019 at 10:25, Bader, Reinhold wrote:
>
> Dear Paul,
>
> Here are further bug reports, mostly on the various functions for
On Wed, 27 Mar 2019, Richard Sandiford wrote:
> Richard Biener writes:
> > Our beloved condition combining code to BIT_FIELD_REFs miscompiles
> > the testcase because it relies on operand_equal_p to detect equal
> > bases. For some reason that very same operand_equal_p is
> > treating any
Hi.
The revision should be reverted as prev-* is the location
where stagetrain stores all *.gcda files.
I've tested that with PGO on x86_64-linux-gnu.
Ready for trunk?
Thanks,
Martin
ChangeLog:
2019-03-27 Martin Liska
PR bootstrap/89829
* Makefile.in: Revert r254150.
Richard Biener writes:
> Our beloved condition combining code to BIT_FIELD_REFs miscompiles
> the testcase because it relies on operand_equal_p to detect equal
> bases. For some reason that very same operand_equal_p is
> treating any dereference of a pointer based on the same pointer
> or decl
On 21/03/19 15:03 -0400, Jason Merrill wrote:
On 3/20/19 6:06 PM, Marek Polacek wrote:
On Wed, Mar 20, 2019 at 10:58:32PM +0100, Jakub Jelinek wrote:
On Wed, Mar 20, 2019 at 05:55:04PM -0400, Marek Polacek wrote:
On Wed, Mar 20, 2019 at 04:56:33PM -0300, Alexandre Oliva wrote:
On Mar 20,
> I modified the patch.
> Please let me know your thoughts.
Thanks. This version is certainly better, but I cannot approve it myself.
Uros, given that the bug was fixed in 64-bit mode for GCC 9, I think that it
would make sense to have it fixed in 32-bit mode too.
--
Eric Botcazou
PING!
Patch posted at https://gcc.gnu.org/ml/fortran/2019-03/msg00098.html
TIA
Dominique
Hi!
If that's of any help to document the version dependencies:
On Fri, 22 Mar 2019 00:04:30 +, Jonathan Wakely wrote:
> I keep forgetting to add that docs for this stuff will be coming some
> time next week, describing the TBB dependency that's needed to use
> these parallel algos.
On an
On Sun, Mar 24, 2019 at 09:20:07AM -0600, Jeff Law wrote:
> However, I'm increasingly of the opinion that MIPS targets need to drop
> off the priority platform list. Given the trajectory I see for MIPS
> based processors in industry, it's really hard to justify spending this
> much time on them,
On 3/27/19 8:36 AM, Jakub Jelinek wrote:
> On Sun, Mar 24, 2019 at 09:20:07AM -0600, Jeff Law wrote:
>> However, I'm increasingly of the opinion that MIPS targets need to drop
>> off the priority platform list. Given the trajectory I see for MIPS
>> based processors in industry, it's really hard
On 27/03/19 15:51 +0100, Thomas Schwinge wrote:
Hi!
If that's of any help to document the version dependencies:
Thanks for t his.
On Fri, 22 Mar 2019 00:04:30 +, Jonathan Wakely wrote:
I keep forgetting to add that docs for this stuff will be coming some
time next week, describing the
The following adds a testcase I managed to break when trying to make
SSA names safe_from_p.
Richard.
2019-03-27 Richard Biener
* gcc.dg/torture/20190327-1.c: New testcase.
Index: gcc/testsuite/gcc.dg/torture/20190327-1.c
The issue here was that when processing the explicit template args in
fn_type_unification we added an empty argument pack for the parameter pack,
so we never tried to do any deduction for it, and therefore never looked at
its type. We need that empty pack behavior for partial ordering, but we
On Wed, Mar 27, 2019 at 09:24:46AM -0600, Jeff Law wrote:
> > 2) another thing I've noticed today, we queue up the debug insn changes,
> > but if we iterate the second time for any bb, we overwrite and thus lose any
> > of the debug insn queued changes from the first iteration, so those changes
>
This patch makes a number of corrections to rs6000_register_move_cost,
adds a new register union class, GEN_OR_VSX_REGS, and adjusts insn
alternative to suit.
The patch initially just corrected register move cost when direct
moves are available, but that resulted in regressions. Inspection of
On 3/25/19 3:36 PM, Jeff Law wrote:
> On 2/20/19 8:19 PM, Peter Bergner wrote:
>> gcc/
>> PR rtl-optimization/89313
>> * function.c (matching_constraint_num): New static function.
>> (match_asm_constraints_1): Use it. Fixup white space and comment.
>> Don't replace inputs with
ld not have visibility into the removal.
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 0679cb72e52..b2c649cfb3e 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2019-03-26 Jeff Law
+
+ PR rtl-optimization/87761
+ PR rtl-optimiz
On 3/21/19 1:03 PM, Jason Merrill wrote:
On 3/20/19 6:06 PM, Marek Polacek wrote:
On Wed, Mar 20, 2019 at 10:58:32PM +0100, Jakub Jelinek wrote:
On Wed, Mar 20, 2019 at 05:55:04PM -0400, Marek Polacek wrote:
On Wed, Mar 20, 2019 at 04:56:33PM -0300, Alexandre Oliva wrote:
On Mar 20, 2019,
On Wed, Mar 27, 2019 at 10:20:17AM -0600, Jeff Law wrote:
> --- a/gcc/regcprop.c
> +++ b/gcc/regcprop.c
> @@ -800,9 +800,9 @@ copyprop_hardreg_forward_1 (basic_block bb, struct
> value_data *vd)
>
>/* Detect obviously dead sets (via REG_UNUSED notes) and remove them.
> */
>if
This patch fixes a bug in which symbol load instructions created by LRA
clobbered the SCC register, and therefore caused rare bad code bugs.
The patch now saves and restores SCC, if called during LRA. The save and
restore instructions are later optimized away if SCC isn't actually live.
On 2/2/19 3:22 AM, Jakub Jelinek wrote:
> On Fri, Feb 01, 2019 at 11:52:04PM +0100, Eric Botcazou wrote:
>>> So, can we e.g. keep emitting the epilogue where it is now for
>>> naked_return_label != NULL_RTX and move it otherwise?
>>> For __builtin_return the setter and use of the hard register
On Wed, Mar 27, 2019 at 3:08 PM Eric Botcazou wrote:
>
> > I modified the patch.
> > Please let me know your thoughts.
>
> Thanks. This version is certainly better, but I cannot approve it myself.
>
> Uros, given that the bug was fixed in 64-bit mode for GCC 9, I think that it
> would make sense
Ping!?
On 03/20/19 23:20, Harald Anlauf wrote:
> The PRs originated in gfc_element_size lacking a treatment of
> procedure pointers, which has been added. The testcase is currently
> a pure compile test. When a reduced run-time test for PR83515
> becomes available, it will be added to the
Hi,
PR89834 identifies a problem with test case gcc.dg/vect/pr81740-2.c, which
relies
implicitly on vectorizing unaligned accesses. This causes it to fail when the
target processor does not support this. The attached patch requires
vect_hw_misalign
so that the test is skipped on such targets.
This fixes bug id,88395 by checking if the second tree reqs
is correctly not a null pointer before calling the function,
tsubst_requirement_body. Otherwise we will get a nullptr
if compiling with -fconcepts for concepts enabled.
Signed-off-by: Nicholas Krause
---
gcc/cp/constraint.cc | 2 ++
1
Jonathan Wakely writes:
> On 27/03/19 15:51 +0100, Thomas Schwinge wrote:
>>Hi!
>>
>>If that's of any help to document the version dependencies:
>
> Thanks for t his.
>
>>On Fri, 22 Mar 2019 00:04:30 +, Jonathan Wakely
>>wrote:
>>> I keep forgetting to add that docs for this stuff will be
This corrects a screw-up on my part. The attribute field of the CFI
descriptor must be set by the formal argument in the interface and not
the actual argument.
Most of the work was in correcting
Bootstrapped and regtested on FC29/x86_64 - OK for trunk?
Cheers
Paul
2019-03-27 Paul Thomas
Ping.
On Wed, Mar 20, 2019 at 04:12:13PM -0400, Marek Polacek wrote:
> The fix for 77656 caused us to call convert_nontype_argument even for
> value-dependent arguments, to perform the conversion in order to avoid
> a bogus warning.
>
> In this case, the argument is Pod{N}. The call to
>
On Wed, Mar 27, 2019 at 06:50:41PM +, Paul Richard Thomas wrote:
> This corrects a screw-up on my part. The attribute field of the CFI
> descriptor must be set by the formal argument in the interface and not
> the actual argument.
>
> Most of the work was in correcting
>
> Bootstrapped and
I noticed that this test doesn't compile because build_converted_constant_expr
failed to consider explicit conversion functions. That's wrong: while Core
Issue 1981 specifies that explicit conversion functions are not considered for
contextual conversions, they are considered in contextual
Since the fix for 15272 we were remembering the wrong function to use at
instantiation time, because the type of the SCOPE_REF didn't reflect the
cv-quals of 'this'. Conveniently, we can fix this by simplifying the code.
Tested x86_64-pc-linux-gnu, applying to trunk.
* semantics.c
On 3/27/19 12:24 PM, Martin Sebor wrote:
On 3/21/19 1:03 PM, Jason Merrill wrote:
On 3/20/19 6:06 PM, Marek Polacek wrote:
On Wed, Mar 20, 2019 at 10:58:32PM +0100, Jakub Jelinek wrote:
On Wed, Mar 20, 2019 at 05:55:04PM -0400, Marek Polacek wrote:
On Wed, Mar 20, 2019 at 04:56:33PM -0300,
Hi Dominique,
Patch posted at https://gcc.gnu.org/ml/fortran/2019-03/msg00098.html
I think the patch is OK. I think the patch is probably appropriate for
stage 1 once that reopens.
Regards
Thomas
We were getting confused by a lambda in template definition context that
isn't actually in the scope of any templated entity. Fixed by telling
type_dependent_expression_p that such a lambda is type-dependent even if we
can't tell that from its closure type. I've also restored the error for
On 3/27/19 4:44 AM, Jonathan Wakely wrote:
On 21/03/19 15:03 -0400, Jason Merrill wrote:
On 3/20/19 6:06 PM, Marek Polacek wrote:
On Wed, Mar 20, 2019 at 10:58:32PM +0100, Jakub Jelinek wrote:
On Wed, Mar 20, 2019 at 05:55:04PM -0400, Marek Polacek wrote:
On Wed, Mar 20, 2019 at 04:56:33PM
nit_11.f90: New test case.
+
2019-03-27 Richard Biener
* gcc.dg/torture/20190327-1.c: New testcase.
diff --git a/gcc/testsuite/gfortran.dg/dummy_procedure_11.f90 b/gcc/testsuite/gfortran.dg/dummy_procedure_11.f90
index f51c5455c05..3e4b2b1d6f0 100644
--- a/gcc/testsuite/gfortran.dg/dummy_
Here we have a non-dependent constructor in a template:
{ VIEW_CONVERT_EXPR(j) }
In digest_init we call massage_init_elt, which calls digest_init_r on the
element. We convert the element, but we're in a template, so
perform_implicit_conversion added an IMPLICIT_CONV_EXPR around it. And then
On Wed, Mar 27, 2019 at 11:22:49PM +0100, Janus Weil wrote:
>
> > > the attached patch implements some missing constraints from Fortran
> > > 2008 concerning procedure pointer initialization (cf. the standard
> > > quote in comment #18), thus fixing two accepts-invalid and
> > > ICE-on-invalid
On 3/27/19 3:11 PM, Martin Sebor wrote:
On 3/27/19 4:44 AM, Jonathan Wakely wrote:
On 21/03/19 15:03 -0400, Jason Merrill wrote:
On 3/20/19 6:06 PM, Marek Polacek wrote:
On Wed, Mar 20, 2019 at 10:58:32PM +0100, Jakub Jelinek wrote:
On Wed, Mar 20, 2019 at 05:55:04PM -0400, Marek Polacek
Am Mi., 27. März 2019 um 23:32 Uhr schrieb Thomas Koenig
:
>
> Am 27.03.19 um 22:54 schrieb Thomas Koenig:
> > I do not think this is correct.
>
> ... and I missed the point that this was specifically about
> initializations.
>
> So, OK from my side. Thanks!
Great. Thanks for the reviews,
Hi!
This cleans up something I found ugly already several times.
NONDEBUG_INSN_P(X) used to be defined as
((GET_CODE (X) == INSN || GET_CODE (X) == DEBUG_INSN
|| GET_CODE (X) == JUMP_INSN || GET_CODE (X) == CALL_INSN)
&& GET_CODE (X) != DEBUG_INSN)
rather than the simpler
(GET_CODE (X) == INSN
On Wed, Mar 27, 2019 at 11:12:38PM +0100, Janus Weil wrote:
> Hi Steve,
>
> > > the attached patch implements some missing constraints from Fortran
> > > 2008 concerning procedure pointer initialization (cf. the standard
> > > quote in comment #18), thus fixing two accepts-invalid and
> > >
On Wed, Mar 27, 2019 at 04:32:15PM +0100, Jakub Jelinek wrote:
> On Wed, Mar 27, 2019 at 09:24:46AM -0600, Jeff Law wrote:
> > > 2) another thing I've noticed today, we queue up the debug insn changes,
> > > but if we iterate the second time for any bb, we overwrite and thus lose
> > > any
> > >
On Wed, Mar 27, 2019 at 10:35:33PM +0100, Janus Weil wrote:
>
> the attached patch implements some missing constraints from Fortran
> 2008 concerning procedure pointer initialization (cf. the standard
> quote in comment #18), thus fixing two accepts-invalid and
> ICE-on-invalid problems.
>
> It
Hi Janus,
the attached patch implements some missing constraints from Fortran
2008 concerning procedure pointer initialization (cf. the standard
quote in comment #18), thus fixing two accepts-invalid and
ICE-on-invalid problems.
I do not think this is correct.
F2008:
# 12.2.2.4 Procedure
Hi Steve,
> > the attached patch implements some missing constraints from Fortran
> > 2008 concerning procedure pointer initialization (cf. the standard
> > quote in comment #18), thus fixing two accepts-invalid and
> > ICE-on-invalid problems.
> >
> > It regtests cleanly on x86_64-linux-gnu. Ok
Hi Thomas,
> > the attached patch implements some missing constraints from Fortran
> > 2008 concerning procedure pointer initialization (cf. the standard
> > quote in comment #18), thus fixing two accepts-invalid and
> > ICE-on-invalid problems.
>
> I do not think this is correct.
>
> F2008:
>
>
Am 27.03.19 um 22:54 schrieb Thomas Koenig:
I do not think this is correct.
... and I missed the point that this was specifically about
initializations.
So, OK from my side. Thanks!
Regards
Thomas
55 matches
Mail list logo
