On Thu, 26 Aug 2021, Xionghu Luo wrote:
>
>
> On 2021/8/24 16:20, Richard Biener wrote:
> > On Tue, 24 Aug 2021, Xionghu Luo wrote:
> >
> >>
> >>
> >> On 2021/8/19 20:11, Richard Biener wrote:
> - class loop *inn_loop = loop;
>
> if (ALWAYS_EXECUTED_IN (loop->header) ==
This fixes DCE to be able to elide dead control flow in an
infinite loop without an exit edge. This special situation is
handled well by the code finding an edge to preserve since there's
no chance it will find the exit edge and make the loop finite.
Bootstrapped and tested on x86_64-unknown-linu
On 8/26/21 14:39, Martin Liška wrote:
I can investigate that.
So there are statistics about #pragma GCC optimize and optimize attribute in
openSUSE:Factory.
The numbers at the line beginning represent number of functions affected by the
pragma or attribute.
Are we smarter in what we want?
Pr
On Fri, Aug 27, 2021 at 10:35 AM Martin Liška wrote:
>
> On 8/26/21 14:39, Martin Liška wrote:
> > I can investigate that.
>
> So there are statistics about #pragma GCC optimize and optimize attribute in
> openSUSE:Factory.
> The numbers at the line beginning represent number of functions affecte
Currently, the asm output file for MIPS has no rev info.
It can make some trouble, for example:
assembler is mips1 by default,
gcc is fpxx by default.
To assemble the output of gcc -S, we have to pass -mips2
to assembler.
gcc/ChangeLog:
* gcc/config/mips/mips.c (mips_module_isa_name): New
On 8/10/21 17:43, Martin Liška wrote:
Hello.
I've just pushed the rebased branch here:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=log;h=refs/users/marxin/heads/sphinx-v4
which I force push once I rebase it. One can fetch the branch with:
$ git fetch origin refs/users/marxin/heads/sphinx-v4
This patch introduces some new define_insn rules to the nvptx backend,
to perform sign-extension of a truncation (from and to the same mode),
using a single cvt instruction. As an example, the following function
int foo(int x) { return (char)x; }
with -O2 currently generates:
mov.u32 %
Hi Segher,
On 8/26/21 6:15 PM, Segher Boessenkool wrote:
Hi!
On Thu, Jul 29, 2021 at 08:31:02AM -0500, Bill Schmidt wrote:
* config/rs6000/rs6000-call.c (rs6000-builtins.h): New #include.
(rs6000_init_builtins): Call rs6000_autoinit_builtins; skip the old
initialization
While working on patch to convert most of the 8 whitespace characters to tabs
in the analyzer’s source, I see this weird behaviour where at some places
indentation looks weird when viewed in patch file ( generated via “git
format-patch” ) but looks alright when viewed in text editor.
Here is
On Fri, Aug 27, 2021 at 07:35:05AM -0500, Bill Schmidt wrote:
> On 8/26/21 6:15 PM, Segher Boessenkool wrote:
> >On Thu, Jul 29, 2021 at 08:31:02AM -0500, Bill Schmidt wrote:
> >>+ /* Execute the autogenerated initialization code for builtins. */
> >>+ rs6000_autoinit_builtins ();
> >The name "a
On 8/27/21 14:44, Ankur Saini wrote:
While working on patch to convert most of the 8 whitespace characters to tabs
in the analyzer’s source, I see this weird behaviour where at some places
indentation looks weird when viewed in patch file ( generated via “git
format-patch” ) but looks alright
+Jeff
(it’s probably borderline obvious - but in the top level Makefile .. so)
> On 17 Aug 2021, at 21:53, David Malcolm wrote:
>
> On Tue, 2021-08-17 at 19:59 +0100, Iain Sandoe wrote:
>> Hi,
>>
>> For those of us who habitually build Ada, it’s convenient to
>> have a way of running individu
Hi Paul,
On 8/23/21 2:03 PM, Paul A. Clarke wrote:
Suppress exceptions (when specified), by saving, manipulating, and
restoring the FPSCR. Similarly, save, set, and restore the floating-point
rounding mode when required.
No attempt is made to optimize writing the FPSCR (by checking if the new
On 8/27/21 8:44 AM, Bill Schmidt wrote:
Again, please specify where the patch was tested and whether this is for
trunk, backports, etc. Thanks! (I know you aren't asking for
backports, but in general please get in the habit of this.)
Sorry, I see that you did this in the cover letter. Ne
Hi Paul,
This looks fine to me, recommend approval.
Thanks,
Bill
On 8/23/21 2:03 PM, Paul A. Clarke wrote:
Function signatures and decorations match gcc/config/i386/smmintrin.h.
Also, copy tests for _mm_min_epi8, _mm_min_epu16, _mm_min_epi32,
_mm_min_epu32, _mm_max_epi8, _mm_max_epu16, _mm_ma
This looks fine, recommend approval.
Thanks!
Bill
On 8/23/21 2:03 PM, Paul A. Clarke wrote:
Copy some simple redirections from i386 , for:
- _mm_test_all_zeros
- _mm_test_all_ones
- _mm_test_mix_ones_zeros
2021-08-20 Paul A. Clarke
gcc
* config/rs6000/smmintrin.h (_mm_test_all_zero
This looks fine, recommend approval.
Thanks!
Bill
On 8/23/21 2:03 PM, Paul A. Clarke wrote:
Function signatures and decorations match gcc/config/i386/smmintrin.h.
Also, copy tests for:
- _mm_cvtepi8_epi16, _mm_cvtepi8_epi32, _mm_cvtepi8_epi64
- _mm_cvtepi16_epi32, _mm_cvtepi16_epi64
- _mm_cvte
On Wed, Aug 25, 2021 at 9:45 AM David Malcolm wrote:
> > BTW, do you think it would be worthwhile to work on the other half of
> > encoding support, i.e. translating from UTF-8 to the user's locale,
> > when outputting diagnostics? I have probably 90% of a patch that does
> > this, however it comp
On 8/27/21 12:23 AM, Richard Biener wrote:
On Thu, Aug 26, 2021 at 9:30 PM Martin Sebor wrote:
On 8/26/21 10:38 AM, Martin Sebor wrote:
On 8/26/21 1:00 AM, Richard Biener wrote:
On Wed, Aug 25, 2021 at 10:03 PM Martin Sebor wrote:
Richard, some time ago you mentioned you'd had trouble get
Hi Paul,
On 8/23/21 2:03 PM, Paul A. Clarke wrote:
Function signatures and decorations match gcc/config/i386/smmintrin.h.
Also, copy tests for:
- _mm_cmpeq_epi64
- _mm_mullo_epi32, _mm_mul_epi32
- _mm_packus_epi32
- _mm_cmpgt_epi64 (SSE4.2)
from gcc/testsuite/gcc.target/i386.
2021-08-23 Paul
Hi Paul,
Thanks for the changes! This looks fine to me, recommend approval.
Thanks,
Bill
On 8/23/21 2:03 PM, Paul A. Clarke wrote:
Some compatibility implementations of x86 intrinsics include
Power intrinsics which require POWER8. Guard them.
emmintrin.h:
- _mm_cmpord_pd: Remove code which
Hi all,
Background: gfortran has its own array descriptor – and one which is defined in
F2018 and used/usable from C (#include ).
On mainline, the conversion is done via a void* pointer and calls to
libgfortran,
which causes all kind of issues, including alias issues but also data
type/bounds
i
> On 22 Aug 2021, at 09:44, Iain Sandoe wrote:
>
>
>
>> On 21 Aug 2021, at 23:18, Eric Gallager wrote:
>>
>> On Fri, Aug 20, 2021 at 3:53 AM Tobias Burnus
>> wrote:
>>>
>>> On 20.08.21 09:34, Richard Biener via Fortran wrote:
>>>
On Thu, Aug 19, 2021 at 10:10 PM Iain Sandoe wrote
Hi,
Some newer assemblers emit section start temp symbols for mod init and term
sections if there is no suitable symbol present already.
The temp symbols are linker visible and therefore appear in the symbol tables.
Since the temp symbol number can vary when debug is enabled, that causes
compare-d
On 27.08.21 17:47, Tobias Burnus wrote at
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578271.html :
PS: Current GCC (mainline w/o patch) generates the following.
[-> with patch, see a-test.f90.*.original.]
I accidentally attached the original dump created by mainline GCC.
For the pa
Hi,
We had a NOP cache clear, but there is a suitable mechanism provided
by a system call. This connects it up.
tested on i686, x86_64-darwin and x86_64-linux
pushed to master, thanks
Iain
Signed-off-by: Iain Sandoe
gcc/ChangeLog:
* config/i386/darwin.h (CLEAR_INSN_CACHE): New.
---
Hi Mike,
Thanks for this clean-up!
On 8/25/21 5:09 PM, Michael Meissner wrote:
From 327273dfeec5c000f3c33ca7b88ee0097fd33586 Mon Sep 17 00:00:00 2001
From: Michael Meissner
Date: Wed, 25 Aug 2021 00:31:35 -0400
Subject: [PATCH] Fix float128-call.c test for power8 IEEE 128 and power10.
I buil
This patch is okay.
Thanks, David
On Fri, Aug 27, 2021 at 12:41 PM Bill Schmidt wrote:
>
> Hi Mike,
>
> Thanks for this clean-up!
>
> On 8/25/21 5:09 PM, Michael Meissner wrote:
> > From 327273dfeec5c000f3c33ca7b88ee0097fd33586 Mon Sep 17 00:00:00 2001
> > From: Michael Meissner
> > Date: Wed,
On Fri, Aug 27, 2021 at 11:41:06AM -0500, Bill Schmidt wrote:
> This amuses me, and I want to keep it this way. :-)
> > void store (TYPE a, TYPE *p) { *p = a; }
> > -/* { dg-final { scan-assembler {\mlxvd2x 34\M} {target be} } } */
> > -/* { dg-final { scan-assembler {\mstxvd2x 34\M} {target be}
On Wed, Aug 25, 2021 at 06:09:44PM -0400, Michael Meissner wrote:
> I built a compiler on a little endian power8 system where the default long
> double was IEEE 128-bit instead of IBM 128-bit. I discovered that on
> power8, we would generate a lxvd2x and xxpermdi to deal with the endianess
> inste
On August 27, 2021 5:20:57 PM GMT+02:00, Martin Sebor wrote:
>On 8/27/21 12:23 AM, Richard Biener wrote:
>> On Thu, Aug 26, 2021 at 9:30 PM Martin Sebor wrote:
>>>
>>> On 8/26/21 10:38 AM, Martin Sebor wrote:
On 8/26/21 1:00 AM, Richard Biener wrote:
> On Wed, Aug 25, 2021 at 10:03 PM Ma
Hi,
On Thu, Mar 11, 2021 at 04:19:51PM +0100, Martin Liška wrote:
> Pushed as obvious, the original change was done
> in g:e05a117dc4b98f3ac60851608f532ba7cee7343a.
>
> Martin
>
> ChangeLog:
>
> * Makefile.tpl: The change was done Makefile.in which
> is generated file.
> ---
> Mak
On Thu, Jul 29, 2021 at 08:31:03AM -0500, Bill Schmidt wrote:
> * config/rs6000/darwin.h (SUBTARGET_INIT_BUILTINS): Use the new
> decl when new_builtins_are_live.
> * config/rs6000/rs6000-builtin-new.def (__builtin_cfstring): New
> built-in.
Okay for trunk. Thanks!
Seghe
On Fri, Aug 27, 2021 at 10:21:35AM -0500, Bill Schmidt via Gcc-patches wrote:
> On 8/23/21 2:03 PM, Paul A. Clarke wrote:
> > Function signatures and decorations match gcc/config/i386/smmintrin.h.
> > gcc
> > * config/rs6000/nmmintrin.h: Copy from i386, tweak to suit.
> > ---
> > v3:
> > - A
On Thu, Jul 29, 2021 at 08:31:04AM -0500, Bill Schmidt wrote:
> It seems quite strange for these to be "vector long" for 64-bit and
> "vector long long" for 32-bit, when "vector long long" will do for both.
Yeah. For most builtins the only thing that matters is the mode the
types map to. Similar
I was working some aspects of our port's vector support and stumbled
across a bit of silly code. We were comparing two vectors that were
both uniform.
We can simplify a comparison of uniform vectors to a comparison of a
representative element from each. That in turn may expose const/copy
On Thu, Jul 29, 2021 at 08:31:05AM -0500, Bill Schmidt wrote:
> * config/rs6000/rs6000-call.c (rs6000_init_builtins): Remove
> TARGET_EXTRA_BUILTINS guard.
> + vector_pair_type_node = make_node (OPAQUE_TYPE);
> + vector_quad_type_node = make_node (OPAQUE_TYPE);
Although those types
On August 27, 2021 5:47:58 PM GMT+02:00, Tobias Burnus
wrote:
>Hi all,
>
>Background: gfortran has its own array descriptor – and one which is defined in
>F2018 and used/usable from C (#include ).
>On mainline, the conversion is done via a void* pointer and calls to
>libgfortran,
>which causes a
Fwprop will happily optimize two xxsetaccz instructions into one xxsetaccz
by propagating the results of the first to the uses of the second.
We really don't want that to happen given the late priming/depriming of
accumulators. I fixed this by making the xxsetaccz source operand an
unspec volatile
This revision (v5) adds a test in libgcc/libgcc2.c for when
"__LIBGCC_TF_MANT_DIG__ == 106" to use __LIBGCC_DF_EPSILON__ instead
of __LIBGCC_TF_EPSILON__. That is specific to IBM 128-bit format long
doubles where EPSILON is very, very small and 1/EPSILON oveflows to
infinity. This change avoids the
Hello Nathan & Joern,
Richard has asked me to give you a heads up that we will be enabling
an informational note for all instances of the GCC -Wuninitialized
warning. You added the helpful note pretty much exactly 15 years ago
to the day (in http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=11656
On Fri, Aug 27, 2021 at 12:29:42PM -0500, Segher Boessenkool wrote:
> On Wed, Aug 25, 2021 at 06:09:44PM -0400, Michael Meissner wrote:
> > I built a compiler on a little endian power8 system where the default long
> > double was IEEE 128-bit instead of IBM 128-bit. I discovered that on
> > power8
Dear all,
the ICE in the original testcase does no longer occur but leads to an
error in a later stage of compilation, and we accepted invalid code.
(Cross-checked with other compilers, such as Intel and NAG).
F2018 states:
15.6.2.6 ENTRY statement
(3) ... If the characteristics of the result
Since std::allocator is not specialized anymore in
_GLIBCXX_INLINE_VERSION mode _ExtPtr_allocator specialization do
not compile
because std::allocator is incomplete.
So I think primary _ExtPtr_allocator template should also be prefered in
_GLIBCXX_INLINE_VERSION mode.
Ok to commit ?
Franço
One of the (few) remaining issues related to cc0 elimination from the H8
port was the fact that I dropped all setcc support. While we only had
setcc on the H8/SX variant, it seems a shame to regress like that.
Meanwhile my primary motivation behind the recent work on the H8 port is
to speed
On Fri, 27 Aug 2021 at 21:58, François Dumont via Libstdc++
wrote:
>
> Since std::allocator is not specialized anymore in
> _GLIBCXX_INLINE_VERSION mode _ExtPtr_allocator specialization do
> not compile
>
> because std::allocator is incomplete.
That doesn't look right ... it should be complete. T
On 8/26/2021 10:58 PM, YunQiang Su wrote:
for some instructions, MIPS r6 uses different encoding other than
the previous releases.
1. mips/n32.S disable .set mips4: since it casuses old insn encoding
is used.
https://github.com/libffi/libffi/pull/396
2. mips/ffi.c: the encoding for JR
On 8/20/21 12:56 PM, Anthony Sharp via Gcc-patches wrote:
Hi, hope everyone is well. I have a patch here for issue 70417
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70417). I'm still a GCC
noob, and this is probably the hardest thing I have ever coded in my
life, so please forgive any initial m
On 8/26/2021 11:26 PM, Xi Ruoyao via Gcc-patches wrote:
On Fri, 2021-08-27 at 13:11 +0800, YunQiang Su wrote:
在 2021/6/18 11:29, YunQiang Su 写道:
Currently, the asm output file for MIPS has no rev info.
It can make some trouble, for example:
assembler is mips1 by default,
gcc is fpxx
On 8/26/2021 10:20 PM, Xi Ruoyao via Gcc-patches wrote:
On Thu, 2021-08-26 at 23:56 -0400, YunQiang Su wrote:
gcc/ChangeLog:
PR target/102089
* config.gcc: MIPS: use N64 ABI by default if the triple end
with -gnuabi64, which is used by Debian since 2013.
---
gc
Even if the operand of -> has dependent type, if it's a pointer we know
that the result will be the target type of that pointer. This should avoid
some unnecessary TYPEOF_EXPR when looking up a name after ->.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* typeck2.c (
On 8/26/2021 1:00 AM, Richard Biener via Gcc-patches wrote:
On Wed, Aug 25, 2021 at 10:03 PM Martin Sebor wrote:
Richard, some time ago you mentioned you'd had trouble getting
-Wuninitialized to print the note pointing to the uninitialized
variable. I said I'd look into it, and so I did. T
As recently remarked by Jeff Law, SUBREGs are the "forever chemicals"
of GCC's RTL; once created they persist in the environment. The problem,
according to the comment on lines 5428-5438 of combine.c is that
non-tieable SUBREGs interfere with reload/register allocation, so
combine often doesn't t
Hi!
On Thu, Jul 29, 2021 at 08:31:06AM -0500, Bill Schmidt wrote:
> Although this patch looks quite large, the changes are fairly minimal.
> Most of it is duplicating the large function that does the overload
> resolution using the automatically generated data structures instead of
> the old hand-
On 8/27/2021 3:57 PM, Roger Sayle wrote:
As recently remarked by Jeff Law, SUBREGs are the "forever chemicals"
of GCC's RTL; once created they persist in the environment. The problem,
according to the comment on lines 5428-5438 of combine.c is that
non-tieable SUBREGs interfere with reload/re
On 8/26/2021 1:30 PM, Martin Sebor via Gcc-patches wrote:
On 8/26/21 10:38 AM, Martin Sebor wrote:
On 8/26/21 1:00 AM, Richard Biener wrote:
On Wed, Aug 25, 2021 at 10:03 PM Martin Sebor wrote:
Richard, some time ago you mentioned you'd had trouble getting
-Wuninitialized to print the not
On Aug 22, 2021, Jan Hubicka wrote:
> OK, thanks for looking into this issue!
Thanks, I've finally installed it in the trunk.
> It seems that analye_stmt indeed does not skip debug stmts. It is very
> odd we got so far without hitting build difference.
Indeed. That got me thinking... The co
57 matches
Mail list logo
