This adds a testcase for a fixed wrong-code bug.
Tested on x86_64-unknown-linux-gnu, pushed.
2022-01-03 Richard Biener
PR tree-optimization/103615
* gcc.dg/torture/pr103615.c: New testcase.
---
gcc/testsuite/gcc.dg/torture/pr103615.c | 13 +
1 file changed, 13 ins
This adds the second testcase which we now also handle eliminating
a redundant PHI node.
Tested on x86_64-unknown-linux-gu.
2022-01-03 Richard Biener
PR tree-optimization/66502
* gcc.dg/tree-ssa/ssa-fre-98.c: New testcase.
---
gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-98.c | 18 +
The patch ports the script to Python3.
Tested with:
$ echo "libstdc++-v3/xx" | ./email_to.py
gcc-...@gcc.gnu.org
libstdc++-...@gcc.gnu.org
May I install it?
Thanks,
Martin
---
email_to.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/email_to.py b/email_to.py
index 073b7
Hi!
In
https://gcc.gnu.org/r12-6176-gd04ae83244d346b95c36c2e3d39918548310f142
https://gcc.gnu.org/r12-6177-g6123f29a18a77eb1a0597f403c4424ae375351fd
https://gcc.gnu.org/r12-6178-gabc1ac2d8d99b7b2846d06ac5a5298ca2f93aedf
https://gcc.gnu.org/r12-6179-g877e3c2abf7a29d746ffda6354d6f19855595905
https:/
On Tue, 14 Dec 2021, Prathamesh Kulkarni wrote:
> On Tue, 7 Dec 2021 at 19:08, Richard Sandiford
> wrote:
> >
> > Prathamesh Kulkarni writes:
> > > On Thu, 2 Dec 2021 at 23:11, Richard Sandiford
> > > wrote:
> > >>
> > >> Prathamesh Kulkarni writes:
> > >> > Hi Richard,
> > >> > I have attache
Hi!
I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586553.html
symtab: Fold &a == &b to 0 if folding_initializer [PR94716]
patch. Thanks.
Jakub
Hi!
I'd like to ping the middle-end part of the
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586879.html
patch (which Uros approved the backend part for with a minor change
I have in my tree).
Thanks.
Jakub
On Fri, 17 Dec 2021, Richard Sandiford wrote:
> Prathamesh Kulkarni writes:
> > Hi,
> > The attached patch rearranges order of type-check for vec_perm_expr
> > and relaxes type checking for
> > lhs = vec_perm_expr
> >
> > when:
> > rhs1 == rhs2,
> > lhs is variable length vector,
> > rhs1 is fixe
On Thu, Dec 30, 2021 at 04:08:25AM -0600, Segher Boessenkool wrote:
> > The following simple patch makes sure we call can_get_prologue even after
> > the last former iteration when vec is already empty and only break from
> > the loop afterwards (and only if the updating of pro done because of
> >
PING: Jakub?
On 12/15/21 10:57, Martin Liška wrote:
On 12/14/21 17:12, Jakub Jelinek wrote:
I'd use INT_TYPE_SIZE - 1 instead of 31. Otherwise LGTM.
Installed with that change, thanks.
Moreover, I'm suggesting a simplification:
The patch removes unneeded loops for cpu_features2 and CONVERT
On 12/14/21 16:28, Martin Liška wrote:
Ready for master?
I'm going to install this as it's quite obvious.
Martin
On 12/15/21 14:24, Martin Liška wrote:
Ready to be installed?
I'm going to install this as it's quite obvious.
Martin
This makes sure to release moved & remapped SSA names during OMP
outlining which happens before going into SSA but with SSA names
created by gimplification around.
Boostrap & regtest running on x86_64-unknown-linux-gnu.
2022-01-03 Richard Biener
PR middle-end/103851
* tree-cfg
On Wed, 29 Dec 2021, Andre Vieira (lists) wrote:
> Hi Richard,
>
> Thank you for the review, I've adopted all above suggestions downstream, I am
> still surprised how many style things I still miss after years of gcc
> development :(
>
> On 17/12/2021 12:44, Richard Sandiford wrote:
> >
> >> @@
On Mon, 3 Jan 2022, Jakub Jelinek wrote:
> Hi!
>
> I'd like to ping the middle-end part of the
> https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586879.html
> patch (which Uros approved the backend part for with a minor change
> I have in my tree).
OK for the middle-end parts if you prop
On Mon, 3 Jan 2022, Jakub Jelinek wrote:
> Hi!
>
> I'd like to ping the
> https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586553.html
> symtab: Fold &a == &b to 0 if folding_initializer [PR94716]
OK.
Thanks,
Richard.
Hi!
On Mon, Jan 03, 2022 at 12:00:10PM +0100, Jakub Jelinek wrote:
> On Thu, Dec 30, 2021 at 04:08:25AM -0600, Segher Boessenkool wrote:
> > > The following simple patch makes sure we call can_get_prologue even after
> > > the last former iteration when vec is already empty and only break from
> >
> Hi!
>
> I'd like to ping the
> https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586553.html
> symtab: Fold &a == &b to 0 if folding_initializer [PR94716]
>
> patch. Thanks.
OK.
Note that with LTO partitioning it may happen that alias is defined in
one partition but used in another. W
On Mon, 3 Jan 2022, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jan 03, 2022 at 12:00:10PM +0100, Jakub Jelinek wrote:
> > On Thu, Dec 30, 2021 at 04:08:25AM -0600, Segher Boessenkool wrote:
> > > > The following simple patch makes sure we call can_get_prologue even
> > > > after
> > > > the las
On Tue, Dec 14, 2021 at 12:10 PM Алексей Нурмухаметов
wrote:
>
> On 13.12.2021 18:20, Alexander Monakov wrote:
> > On Mon, 13 Dec 2021, Richard Biener wrote:
> >
> >> On December 13, 2021 3:25:47 PM GMT+01:00, Alexander Monakov
> >> wrote:
> >>> Greetings!
> >>>
> >>> While testing our patch tha
On Fri, Dec 17, 2021 at 11:45 PM H.J. Lu via Gcc-patches
wrote:
>
> OK for release branches?
OK - I assume the size is not leaked as ABI detail?
>
> H.J.
> ---
> Cherry-pick from LLVM release/13.x branch:
>
> commit d96358a2819399a2abb60ad3b26444ab7b4409cf
> Author: Michał Górny
> Date: Mon D
This issue was triggered after the patch extending syntax for component access
in map clauses
(https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=0ab29cf0bb68960c)
In gimplify_scan_omp_clauses, the case for handling indirect accesses (which
creates
firstprivate ptr and zero-length array section map
On Wed, 22 Dec 2021, Jiufu Guo wrote:
> Hi,
>
> Normaly, estimate_numbers_of_iterations get/caculate niter first,
> and then invokes infer_loop_bounds_from_undefined. While in some case,
> after a few call stacks, estimate_numbers_of_iterations is invoked before
> niter is ready (e.g. before numb
On Tue, Dec 28, 2021 at 2:10 PM Martin Liška wrote:
>
> Hello.
>
> The mold linker is getting quite popular and I think we should support it:
> https://github.com/rui314/mold
Does it support the gold plugin API/ABI and thus proper LTO? If not
I'm not sure we should encourage use. For example u
After the PR90030 patch, which removes the universal casting of all Fortran
array pointers to 'c_char*',
a Fortran descriptor based array passed into an affinity() clause now looks
like:
- #pragma omp task private(i) shared(b) affinity(*(c_char *) a.data)
+ #pragma omp task private(i) s
On Mon, Jan 3, 2022 at 2:51 AM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> While cleaning up the bug database, I noticed there was a request
> to improve the documentation of the _Complex type extensions.
> So I rewrote part of the documentation to make things clearer on
> __rea
On Mon, Jan 03, 2022 at 10:51:49PM +0800, Chung-Lin Tang wrote:
> After the PR90030 patch, which removes the universal casting of all Fortran
> array pointers to 'c_char*',
> a Fortran descriptor based array passed into an affinity() clause now looks
> like:
>
> - #pragma omp task private(i)
On 1/3/22 15:48, Richard Biener wrote:
On Tue, Dec 28, 2021 at 2:10 PM Martin Liška wrote:
Hello.
The mold linker is getting quite popular and I think we should support it:
https://github.com/rui314/mold
Does it support the gold plugin API/ABI and thus proper LTO?
No, but it's planned to
On Mon, Jan 03, 2022 at 11:33:32AM +0100, Jakub Jelinek wrote:
> The idea behind this is that libstdc++ is written such that it can handle
> both IBM extended and IEEE quad long double, so its object files are
> compatible with both.
Now tested on powerpc64le-linux (and together with the regenerat
Hello world,
the attached patch lets the library compile correctly, as far as I
have been able to determine.
Committed to the branch.
Best regards
Thomas
Make sure the Fortran specifics have real(kind=16).
This brings the library to compile with all specific functions.
It also correc
Hi!
Testing found that we also need libquadmath to be built with
-mno-gnu-attribute, otherwise -mabi=ieeelongdouble programs don't link.
Ok for power-ieee128?
2022-01-03 Jakub Jelinek
* configure.ac: Set XCFLAGS to -mno-gnu-attribute on
powerpc64le*-linux*.
* configur
On Wed, 22 Dec 2021, Jason Merrill wrote:
> On 12/21/21 14:08, Patrick Palka wrote:
> > On Tue, Dec 21, 2021 at 2:03 PM Patrick Palka wrote:
> > >
> > > On Wed, Jun 30, 2021 at 4:23 PM Jason Merrill wrote:
> > > >
> > > > On 6/30/21 4:18 PM, Patrick Palka wrote:
> > > > > On Wed, Jun 30, 2021
Hi Jakub,
On Mon, Jan 03, 2022 at 11:33:32AM +0100, Jakub Jelinek wrote:
The idea behind this is that libstdc++ is written such that it can handle
both IBM extended and IEEE quad long double, so its object files are
compatible with both.
Now tested on powerpc64le-linux (and together with the
On Tue, Dec 28, 2021 at 10:08 AM Patrick Palka wrote:
>
> Here during satisfaction of B's associated constraints we're failing to
> reject the object-less call to the non-static member function A::size
> ultimately because satisfaction is performed in the (access) context of
> the class template B
Hi!
The following patch adds the library side of -mabi=ieeelongdouble
I/O support.
There is one issue to be resolved though, for the sake of libgfortran.a
built on an older powerpc64le-linux system (glibc older than 2.32) and
then deployed on glibc 2.32 or later, I believe we want to use
_gfortra
Hi!
Here is the compiler side of those changes, but depends of course
on the decision what to do with those *real128* and *complex128* symbols.
With all the 4 patches e.g. print *, var for real(kind=16) var; var = 1.0;
works both with -mabi=ibmlongdouble and -mabi=ieeelongdouble.
2022-01-03 Jak
On 03.01.22 16:24, Jakub Jelinek via Fortran wrote:
Ok for power-ieee128?
OK.
Thanks!
Best regards
Thomas
On Mon, Jan 03, 2022 at 04:36:21PM +0100, Jakub Jelinek via Gcc-patches wrote:
> The following patch adds the library side of -mabi=ieeelongdouble
> I/O support.
>
> There is one issue to be resolved though, for the sake of libgfortran.a
> built on an older powerpc64le-linux system (glibc older th
On Mon, 3 Jan 2022, Richard Biener wrote:
> > @@ -5674,6 +5675,14 @@ gimple_verify_flow_info (void)
> >err = 1;
> > }
> >
> > + if (prev_stmt && stmt_starts_bb_p (stmt, prev_stmt))
>
> stmt_starts_bb_p is really a helper used during CFG build, I'd rather
> tes
On 1/2/2022 11:08 AM, Jason Merrill via Gcc-patches wrote:
It would be nice to handle language-specific codes in the tree
pretty-printer, but until then we can at least indent them appropriately.
Tested x86_64-pc-linux-gnu, ok for trunk?
gcc/ChangeLog:
* tree-pretty-print.c (do_niy)
On 12/30/21 8:59 AM, Palmer Dabbelt wrote:
On Thu, 30 Dec 2021 08:28:34 PST (-0800), gcc-patches@gcc.gnu.org wrote:
On 12/29/2021 8:02 PM, jiawei wrote:
Add -msmall-data-limit option to put global and static data into right
section and generate 'btt_info' on RISC-V target.
BTF (BPF Type Form
Hi Jakub,
So, either we'd need to add e.g. preprocessing support for gfortran.map
or some other way how to make certain symbols appear conditionally at
different symbol versions, or another option would be to choose different
symbol names for those for the powerpc64le-linux cases
(e.g._gfortra
On Thu, Nov 18, 2021 at 08:24:52PM -0600, Paul A. Clarke via Gcc-patches wrote:
> On Mon, Nov 08, 2021 at 11:40:42AM -0600, Paul A. Clarke via Gcc-patches
> wrote:
> > On Tue, Oct 26, 2021 at 03:00:11PM -0500, Paul A. Clarke via Gcc-patches
> > wrote:
> > > Patches 1/3 and 3/3 have been committed
On 12/30/2021 9:59 AM, Palmer Dabbelt wrote:
On Thu, 30 Dec 2021 08:28:34 PST (-0800), gcc-patches@gcc.gnu.org wrote:
On 12/29/2021 8:02 PM, jiawei wrote:
Add -msmall-data-limit option to put global and static data into right
section and generate 'btt_info' on RISC-V target.
BTF (BPF Type
On 03.01.22 17:26, Jakub Jelinek wrote:
so we could similarly have something like:
#if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ &&
__SIZEOF_LONG_DOUBLE__ == 16)
_gfortran_transfer_complex128;
_gfortran_transfer_complex128_write;
#endif
...
#if !(defined(
On 1/3/22 08:43, Indu Bhagat wrote:
On 12/30/21 8:59 AM, Palmer Dabbelt wrote:
On Thu, 30 Dec 2021 08:28:34 PST (-0800), gcc-patches@gcc.gnu.org wrote:
On 12/29/2021 8:02 PM, jiawei wrote:
Add -msmall-data-limit option to put global and static data into right
section and generate 'btt_inf
On Sat, Dec 18, 2021 at 07:43:55PM -0500, Eric Gallager wrote:
> On Fri, Dec 17, 2021 at 5:59 PM Marek Polacek via Gcc-patches
> wrote:
> >
> > This fixes
> >
> > gcc/cp/parser.c:4618:41: warning: narrowing conversion of '(char)(*(str +
> > ((sizetype)i)))' from 'char' to 'unsigned char' [-Wnarro
Dear all,
the initial-data-target for a pointer initialization can be either
NULL() or a non-constant target. In the latter case subscripts of
the target specification (or substring starting and ending points)
must be constant expressions. The patch adds corresponding checks.
I have verified th
On Mon, Jan 03, 2022 at 06:03:41PM +0100, Thomas Koenig wrote:
> On 03.01.22 17:26, Jakub Jelinek wrote:
>
> > so we could similarly have something like:
> > #if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
> > && __SIZEOF_LONG_DOUBLE__ == 16)
> > _gfortran_transfer_
Middle end tries to generate V4QImode moves to implement V2QImode inserts
and calls emit_move_multi_word when V4QImode moves are unavailable, as is
the case with 32-bit vector moves, constrainted with TARGET_SSE2.
However, this triggers
gcc_assert (mode_size >= UNITS_PER_WORD);
in emit_move_mu
On Mon, Dec 20, 2021 at 09:53:25PM +0100, Jakub Jelinek wrote:
> On Mon, Dec 20, 2021 at 03:21:04PM -0500, Jason Merrill via Gcc-patches wrote:
> > > @@ -3215,6 +3215,14 @@ check_tokens (const token_t *tokens, unsigned
> > > ntoks,
> > > plural = "s";
> > > }
On Mon, Jan 03, 2022 at 03:55:51PM -0500, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
LGTM, thanks.
> Can I backport it to GCC 11 too?
Not immediately, but say after 2 weeks sure.
>
> -- >8 --
> I'm tired of seeing
>
> cp/parser.c:15923:55: warning: miss
Hi Jakub,
clearly there is still work to fix (but seems e.g. most of the lto tests
are related to the gnu attributes stuff:( ).
This is looking better than what I expected. Apart from LTO, I expect
that a couple of files still do not have the correct flags set when
compiling, or maybe some t
From: Andrew Pinski
This testcase was fixed by r12-1744-g3eecc1 as it make
sense it fixed a few other class deduction issues.
So I thought I would add a testcase for this PR and close
it as fixed.
Committed after a quick test of the testcase.
PR c++/90782
gcc/testsuite/ChangeLog:
Hi, David!
One question below as I'm still not done with using this patch in
rustc_codegen_gcc.
Le jeudi 20 mai 2021 à 15:25 -0400, David Malcolm a écrit :
> On Tue, 2021-05-18 at 14:53 +0200, Jakub Jelinek via Jit wrote:
> > On Tue, May 18, 2021 at 08:23:56AM -0400, Antoni Boucher via Gcc-
> > p
Happy new year, and ping!
On 12/18/21 18:05, Siddhesh Poyarekar wrote:
This patchset enhances the __builtin_dynamic_object_size builtin to
produce dynamic expressions for object sizes to improve coverage of
_FORTIFY_SOURCE.
Testing:
This series has been tested with build and test for
Avoid ICE of move pattern from memory to memory.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Pushed to trunk.
gcc/ChangeLog:
PR target/103895
* config/i386/sse.md (*bit_and_float_vector_all_ones):
Force_reg operand 1 to avoid ICE.
gcc/testsuite/ChangeLog:
On Sat, Dec 11, 2021 at 10:44 AM H.J. Lu wrote:
>
> On Thu, Nov 25, 2021 at 9:54 AM H.J. Lu wrote:
> >
> > On Mon, Nov 1, 2021 at 7:02 AM H.J. Lu wrote:
> > >
> > > On Thu, Oct 21, 2021 at 12:56 PM H.J. Lu wrote:
> > > >
> > > > On Wed, Sep 22, 2021 at 7:02 PM H.J. Lu wrote:
> > > > >
> > > >
Hi Uros,
This patch is to update model value for Alderlake and Rocketlake.
Bootstrap is ok, and no regressions for i386/x86-64 testsuite.
OK for master?
gcc/ChangeLog
* common/config/i386/cpuinfo.h (get_intel_cpu): Add new model values
to Alderlake and Rocketlake.
---
gcc/comm
> -Original Message-
> From: Cui, Lili
> Sent: Tuesday, January 4, 2022 1:20 PM
> To: gcc-patches@gcc.gnu.org
> Cc: ubiz...@gmail.com; Liu, Hongtao ;
> hjl.to...@gmail.com
> Subject: [PATCH] x86: Update model value for Alderlake and Rocketlake
>
> Hi Uros,
>
> This patch is to update
On Mon, Jan 3, 2022 at 4:23 PM Martin Liška wrote:
>
> On 1/3/22 15:48, Richard Biener wrote:
> > On Tue, Dec 28, 2021 at 2:10 PM Martin Liška wrote:
> >>
> >> Hello.
> >>
> >> The mold linker is getting quite popular and I think we should support it:
> >> https://github.com/rui314/mold
> >
> > D
On Mon, Jan 3, 2022 at 5:35 PM Alexander Monakov wrote:
>
> On Mon, 3 Jan 2022, Richard Biener wrote:
>
> > > @@ -5674,6 +5675,14 @@ gimple_verify_flow_info (void)
> > >err = 1;
> > > }
> > >
> > > + if (prev_stmt && stmt_starts_bb_p (stmt, prev_stmt))
> >
> >
62 matches
Mail list logo
