Similar for sqrt/sqrtl.
gcc/ChangeLog:
PR target/102464
* match.pd: Simplify (_Float16) sqrtf((float) a) to .SQRT(a)
when direct_internal_fn_supported_p, similar for sqrt/sqrtl.
gcc/testsuite/ChangeLog:
PR target/102464
*
Hi Bernhard,
what you're doing seems a useful clean-up, thanks.
One point for discussion:
-match
+static match
gfc_match_label (void)
I have generally understood that the gfc_ prefix is for global variables
and functions only. We do not always adhere to it (also since some
global
On 10/24/2021 8:15 PM, Jeff Law wrote:
On 10/18/2021 2:17 AM, Aldy Hernandez wrote:
On 10/18/21 12:52 AM, Jeff Law wrote:
On 10/8/2021 9:12 AM, Aldy Hernandez via Gcc-patches wrote:
The following patch converts the strlen pass from evrp to ranger,
leaving DOM as the last remaining
Hi,
As PR102767 shows, the commit r12-3482 exposed one ICE in function
rs6000_builtin_vectorization_cost. We claims V1TI supports movmisalign
on rs6000 (See define_expand "movmisalign"), so it return true in
rs6000_builtin_support_vector_misalignment for misalign 8. Later in
the cost querying
Hi,
As PR102789 shows, when vectorizer does some peelings for alignment
in prologue, function vect_update_inits_of_drs would update the
inits of some drs. But as the failed case, we shouldn't update the
dr for simd_lane_access, it has the fixed-length storage mainly for
the main loop, the update
If the second operand of __builtin_shuffle is const vector 0, and with
specific mask, it can be optimized to vspltisw+xxpermdi instead of lxv.
gcc/ChangeLog:
* config/rs6000/rs6000.c (altivec_expand_vec_perm_const): Add
patterns match and emit for VSX xxpermdi.
On 10/24/2021 5:40 PM, Martin Sebor via Gcc-patches wrote:
Attached is a revised patch for just the access warning pass
to diagnose out-of-bounds stores by atomic functions, with
no attr-fnspec changes.
Is this okay for trunk?
Martin
PS Just to clarify the effect of the original patch in
On 10/24/2021 5:43 PM, Martin Sebor via Gcc-patches wrote:
The detection of overlapping sprintf calls has a limitation
that leads to both false positives (PR 102919) and negatives
(PR 102238) in corner cases involving members of aggregates.
The false positives result from the overlap logic
On 10/18/2021 2:17 AM, Aldy Hernandez wrote:
On 10/18/21 12:52 AM, Jeff Law wrote:
On 10/8/2021 9:12 AM, Aldy Hernandez via Gcc-patches wrote:
The following patch converts the strlen pass from evrp to ranger,
leaving DOM as the last remaining user.
So is there any reason why we can't
On Fri, Oct 22, 2021 at 1:57 PM Kong, Lingling via Gcc-patches
wrote:
>
> Hi,
>
> This patch is to support transform in fast-math something like
> _mm512_add_ph(x1, _mm512_fmadd_pch(a, b, _mm512_setzero_ph())) to
> _mm512_fmadd_pch(a, b, x1).
>
> And support transform _mm512_add_ph(x1,
On 10/23/2021 3:32 PM, Jeff Law wrote:
On 10/21/2021 12:20 PM, Jeff Law wrote:
So if we're referring to those temporary const/copy propagations
"escaping" into Ranger, then I would fully expect that to cause
problems. Essentially they're path sensitive const/copy propagations
and may
The detection of overlapping sprintf calls has a limitation
that leads to both false positives (PR 102919) and negatives
(PR 102238) in corner cases involving members of aggregates.
The false positives result from the overlap logic not using
the size of the member used as an argument to %s to
Attached is a revised patch for just the access warning pass
to diagnose out-of-bounds stores by atomic functions, with
no attr-fnspec changes.
Is this okay for trunk?
Martin
PS Just to clarify the effect of the original patch in case
it wasn't: it didn't enable optimizations of atomic
On Mon, 25 Oct 2021 00:30:16 +0200
Bernhard Reutner-Fischer wrote:
> Hi!
>
> Quickly skimming through the frontend headers.
I'm also attaching the other view for the fortran FE after the header
cleanup:
python3 $topsrc/contrib/unused_functions.py gcc/fortran/ \
grep -v "gt_"
for a
From: Bernhard Reutner-Fischer
This makes some trans* functions static and deletes declarations of
functions that either do not exist anymore like gfc_get_function_decl
or that are unused like gfc_check_any_c_kind.
gcc/fortran/ChangeLog:
* expr.c (is_non_empty_structure_constructor):
From: Bernhard Reutner-Fischer
gfc_match_small_int_expr was unused, delete it.
gfc_match_gcc_unroll should use gfc_match_small_literal_int and then
gfc_match_small_int can be deleted since it will be unused.
gcc/fortran/ChangeLog:
* decl.c (gfc_match_old_kind_spec,
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
* trans-stmt.h (gfc_trans_deallocate_array): Delete.
---
gcc/fortran/trans-stmt.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/gcc/fortran/trans-stmt.h b/gcc/fortran/trans-stmt.h
index 1a24d9b4cdc..e824caf4d08 100644
---
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
* trans-array.c (gfc_trans_scalarized_loop_end): Make static.
* trans-array.h (gfc_trans_scalarized_loop_end,
gfc_conv_tmp_ref, gfc_conv_array_transpose): Delete declaration.
---
gcc/fortran/trans-array.c | 2 +-
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
* trans-types.h (gfc_convert_function_code): Delete.
---
gcc/fortran/trans-types.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/gcc/fortran/trans-types.h b/gcc/fortran/trans-types.h
index 1b43503092b..3bc236cad0d 100644
---
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
* intrinsic.h (gfc_check_sum, gfc_resolve_atan2d, gfc_resolve_kill,
gfc_resolve_kill_sub): Delete declaration.
---
gcc/fortran/intrinsic.h | 4
1 file changed, 4 deletions(-)
diff --git a/gcc/fortran/intrinsic.h
From: Bernhard Reutner-Fischer
gfc_constructor_expr_foreach and gfc_constructor_swap were just stubs.
gcc/fortran/ChangeLog:
* constructor.c (gfc_constructor_get_base): Make static.
(gfc_constructor_expr_foreach, (gfc_constructor_swap): Delete.
* constructor.h
Hi!
Quickly skimming through the frontend headers.
There are a couple of declarations for functions that do not have
definitions. And there are a couple of functions that can be static.
Notes i took while at it / TODOs:
- get rid of VTAB_GET_FIELD_GEN and unused extern decls
- The last block of
On Sun, Oct 24, 2021 at 1:36 PM Iain Sandoe wrote:
>
> Hi H.J.
>
> > On 19 Oct 2021, at 19:01, H.J. Lu via Gcc-patches
> > wrote:
> >
> > On Tue, Oct 19, 2021 at 8:03 AM David Edelsohn wrote:
> >>
>
> >> My colleague built GCC, including GCC Go, with your patch:
> >>
> >> "I was able to build
Hi H.J.
> On 19 Oct 2021, at 19:01, H.J. Lu via Gcc-patches
> wrote:
>
> On Tue, Oct 19, 2021 at 8:03 AM David Edelsohn wrote:
>>
>> My colleague built GCC, including GCC Go, with your patch:
>>
>> "I was able to build libgo and test it partially. The results are
>> similar to the current
On Sun, Oct 24, 2021 at 09:00:52PM +0200, Harald Anlauf wrote:
> Dear Fortranners, Steve,
>
> I've created PR 102917 for tracking this issue and packaged
> the attached patch.
>
> Regtested on x86_64-pc-linux-gnu. OK mainline?
>
Thanks for picking this up. The patch looks good to me,
but
Hi,
Attached is a new version of the patch, mainly for improving performance
and simplifying the code.
First, regarding the comments:
> -Original Message-
> From: Richard Biener
> Sent: Friday, October 1, 2021 9:00 PM
> To: Di Zhao OS
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re:
Dear Fortranners, Steve,
I've created PR 102917 for tracking this issue and packaged
the attached patch.
Regtested on x86_64-pc-linux-gnu. OK mainline?
Thanks,
Harald
> Gesendet: Freitag, 22. Oktober 2021 um 22:25 Uhr
> Von: "Steve Kargl"
> An: "Harald Anlauf"
> Cc: fort...@gcc.gnu.org
>
The Linux kernel on hppa is built with -mdisable-fpregs to inhibit the use of
the floating-point
registers. However, I noticed that the 64-bit kernel was using floating-point
registers for hardware
integer multiplication (xmpyu). It turned out this was because various DImode
routines in
On 10/24/21 6:57 PM, Jeff Law wrote:
Ugwe could put the test back, check for some random large
number, and come up with a more satisfactory test later? ;-)
I thought our "counting" based tests could only check equality (ie,
expect to see this string precisely N times). Though if we
On October 24, 2021 6:57:05 PM GMT+02:00, Jeff Law via Gcc-patches
wrote:
>
>
>On 10/21/2021 9:53 PM, Aldy Hernandez wrote:
>>
>>
>> >
>> > Phew, I think we're finally converging on a useful set of
>> threading tests :).
>> >
>> > OK for trunk?
>> Mostly, I just worry
The 'G' constraint only matches a float zero, so it will never match in integer
move patterns.
Tested on hppa-unknown-linux-gnu. Committed to active branches.
Dave
---
Don't use 'G' constraint in integer move patterns
The 'G' constraint only matches a float zero.
2021-10-24 John David
On Sun, 24 Oct 2021 10:57:05 -0600
Jeff Law via Gcc-patches wrote:
> I thought our "counting" based tests could only check equality (ie,
> expect to see this string precisely N times). Though if we could check
> that # threads realized was > some low water mark, that'd probably be
> better
On Wed, Oct 20, 2021 at 10:57 AM Marek Polacek via Gcc-patches
wrote:
>
> On Wed, Oct 20, 2021 at 03:49:09PM +, Qing Zhao via Gcc-patches wrote:
> > Hi,
> >
> > In GCC, there are many utility routines for reporting error, warning, or
> > information, for example:
> >
> > warning (0, "weak
On 10/21/2021 9:53 PM, Aldy Hernandez wrote:
>
> Phew, I think we're finally converging on a useful set of
threading tests :).
>
> OK for trunk?
Mostly, I just worry about losing the key test for the FSM
optimization.
With the provided test, the forward
This patch provides RTL expanders to implement logical shifts and
rotates of 128-bit values (stored in vector integer registers) by
constant bit counts. Previously, GCC would transfer these values
to a pair of scalar registers (TImode) via memory to perform the
operation, then transfer the
This patch cures the testsuite failure of bfin/20090914-3.c, which
currently FAILs on bfin-elf with "(test for excess errors)" due to:
20090914-3.c:3:1: warning: return type defaults to 'int' [-Wimplicit-int]
which is obviously not what this code was intended to test. Fixed by
turning the code
Jonathan pointed this out to me while remove a link from the
installation documentation to the no longer existing old.html
page.
At first I was puzzled, but a bit of debugging made me realize
where the (now) empty old.html page still was coming from.
Fixed thusly, and I'll add some code to
While debugging an issue Jonathan reported I noticed we still have
those references to way old versions of GNU/Linux and Windows from
the early days of Itanium, which really do not add value - now gone
they are.
Gerald
gcc:
* doc/install.texi (Specific): Remove obsolete details
From: Andrew Pinski
Just like PR 100382, here we have a DCE removing a
null pointer load which is needed still.
In this case, execute_fixup_cfg removes a store (correctly)
and then removes the null load (incorrectly) due to
not checking stmt_unremovable_because_of_non_call_eh_p.
This patch adds
Hi Richard,
On Sun, 2021-10-24 08:36:36 +0200, Richard Biener wrote:
> On October 23, 2021 10:00:05 PM GMT+02:00, Jan-Benedict Glaw
> wrote:
> >On Tue, 2021-09-21 16:25:19 +0200, Richard Biener via Gcc-patches
> > wrote:
> >> I have built all targets from contrib/config-list.mk to make sure
On October 23, 2021 10:00:05 PM GMT+02:00, Jan-Benedict Glaw
wrote:
>Hi Richard,
>
>On Tue, 2021-09-21 16:25:19 +0200, Richard Biener via Gcc-patches
> wrote:
>> I have built all targets from contrib/config-list.mk to make sure we
>> don't run into the #error and the following makes the STABS
41 matches
Mail list logo
