Piotr is the one spending most times on ensuring FreeBSD ports work
fine on POWER, so personally I'm happy to follow his recommendation
on such matters.
Okay for trunk and backports (GCC 10 at least)?
Gerald
gcc/ChangeLog:
2020-12-13 Piotr Kubaj
Gerald Pfeifer
* confi
Hello world,
I have struggled with debugging the GENERIC generated by the
Fortran front end because it is only possible to look at the
code via -fdump-tree-original, but it is not possible to
inspect the values; additionally, the D.3456 form makes it
hard to read which variable is which.
This pa
On Sat, 12 Dec 2020 at 01:15, Segher Boessenkool
wrote:
> On Fri, Dec 11, 2020 at 11:20:01PM +0200, abebeos wrote:
> > Στις Παρ, 11 Δεκ 2020 στις 11:00 μ.μ., ο/η Segher Boessenkool <
> > seg...@kernel.crashing.org> έγραψε:
> > > > Ok, to speed things up, is it ok if I simply pick the patch that I
On Sat, Dec 12, 2020 at 08:55:01AM +0100, Jakub Jelinek via Gcc-patches wrote:
> Actually, seems we diagnose goto out of it, so perhaps for trunk
> the best thing forward is to add the noexcept block around target data
> body, but I think we still don't really need the omp return, omp-expand
> does
Hi!
On Sat, Dec 12, 2020 at 12:17:19PM +0100, John Paul Adrian Glaubitz wrote:
> >> I'd ask the original author, but it seems he's busy with other work, so to
> >> avoid delays...
> >
> > Please try to ask him first? That is always nice, but you all also need
> > to figure out what to do with th
Hi Paul,
Fortran: Enable inquiry references in data statements [PR98022].
This patch speaks for itself.
Regtests on FC31/x86_64 - OK for master?
Looks good. Thanks a lot for the patch!
Best regards
Thomas
Fortran: Enable inquiry references in data statements [PR98022].
This patch speaks for itself.
Regtests on FC31/x86_64 - OK for master?
Paul
2020-12-12 Paul Thomas
gcc/fortran
PR fortran/98022
* data.c (gfc_assign_data_value): Handle inquiry references in
the data statement object list.
gc
On Sat, Dec 12, 2020 at 02:00:49PM +0100, Marc Glisse wrote:
> > Extending it to non-constants is what I wanted to avoid.
> > For ~(X + Y), because + is commutative, it wouldn't be a canonicalization
> > as it would pick more-less randomly whether to do ~X + Y or X + ~Y.
>
> ~X - Y or ~Y - X I gue
On Sat, 12 Dec 2020, Jakub Jelinek via Gcc-patches wrote:
On Sat, Dec 12, 2020 at 01:25:39PM +0100, Marc Glisse wrote:
On Sat, 12 Dec 2020, Jakub Jelinek via Gcc-patches wrote:
This patch adds the ~(X - Y) -> ~X + Y simplification requested
in the PR (plus also ~(X + C) -> ~X + (-C) for const
On Sat, Dec 12, 2020 at 01:25:39PM +0100, Marc Glisse wrote:
> On Sat, 12 Dec 2020, Jakub Jelinek via Gcc-patches wrote:
>
> > This patch adds the ~(X - Y) -> ~X + Y simplification requested
> > in the PR (plus also ~(X + C) -> ~X + (-C) for constants C that can
> > be safely negated.
>
> Would i
On Sat, 12 Dec 2020, Jakub Jelinek via Gcc-patches wrote:
This patch adds the ~(X - Y) -> ~X + Y simplification requested
in the PR (plus also ~(X + C) -> ~X + (-C) for constants C that can
be safely negated.
Would it have been wrong to produce ~X - C without caring about negating
(and then e
Avoid the possibility of code discrepancies like one fixed with the
previous change and improve the structure of code by selecting between
push and non-push operations in a single place in `vax_output_int_move'.
The PUSHAB/MOVAB address moves are never actually produced from this
code as the SI
Check the output operand for representing pushing a value onto the stack
rather than the constant 0 input in determining whether to use the PUSHL
or the CLRL instruction for a SImode move. The latter actually works by
means of using the predecrement addressing mode with the SP register and
the
Hi,
While working on QMATH DImode add/sub fixes I have spotted an issue with
the push operation. Here's a small patch series that addresses it.
Lightly-verified with the `vax-netbsdelf' target and the C frontend test
suite only as I need to have hardware available for a Linux kernel project
Hello!
>> I'd ask the original author, but it seems he's busy with other work, so to
>> avoid delays...
>
> Please try to ask him first? That is always nice, but you all also need
> to figure out what to do with the bounty.
Going through the messages in this thread, my suggestion would be to pi
On December 12, 2020 9:01:50 AM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>The following patch recognizes another form of hand written
>__builtin_add_overflow (this time _p), in particular when
>the code does unsigned
>if (x > ~0U - y)
>or
>if (x <= ~0U - y)
>it can be optimized (if the subtraction
On December 12, 2020 9:10:41 AM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>This patch adds the ~(X - Y) -> ~X + Y simplification requested
>in the PR (plus also ~(X + C) -> ~X + (-C) for constants C that can
>be safely negated.
>
>The first two simplify blocks is what has been requested in the PR
>a
Fortran: Fix some select rank issues [PR97694 and 97723].
Hi All,
Unlike select type, select rank selectors retain the allocatable attribute.
This is corrected by the chunk in check.c. Note the trailing whitespace
corrections. Resolution of select rank construct must be done in the same
way as se
Hi!
This patch adds the ~(X - Y) -> ~X + Y simplification requested
in the PR (plus also ~(X + C) -> ~X + (-C) for constants C that can
be safely negated.
The first two simplify blocks is what has been requested in the PR
and that makes the first testcase pass.
Unfortunately, that change also bre
Hi!
The following patch recognizes another form of hand written
__builtin_add_overflow (this time _p), in particular when
the code does unsigned
if (x > ~0U - y)
or
if (x <= ~0U - y)
it can be optimized (if the subtraction turned into ~y is single use)
into
if (__builtin_add_overflow_p (x, y, 0U))
20 matches
Mail list logo
