Hi!
I'd like to ping the following patches
libcpp: __VA_OPT__ p1042r1 placemarker changes [PR101488]
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575621.html
together with your
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577602.html
incremental patch (successfully tested on x86_6
On Sun, Aug 29, 2021 at 11:28 AM Roger Sayle wrote:
>
>
> This is another attempt to add an -fpreserve-traps command line
> option to GCC. Many thanks to Richard Beiner for approving the
> code clean-up pieces of my earlier submission: This revision
> contains just the actual functional change(s)
This makes -fexceptions enabled by -fnon-call-exceptions, removing
the odd state of !flag_exceptions && flag_non_call_exceptions from
middle-end consideration.
Bootstrapped and tested on x86_64-unknown-linux-gnu for all languages.
OK?
Richard.
2021-08-30 Richard Biener
* common.opt (
> This makes -fexceptions enabled by -fnon-call-exceptions, removing
> the odd state of !flag_exceptions && flag_non_call_exceptions from
> middle-end consideration.
FWIW fine with me.
--
Eric Botcazou
On 8/27/21 19:45, Gleb Fotengauer-Malinovskiy wrote:
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 whic
在 2021/8/30 5:00, Jeff Law 写道:
On 8/28/2021 1:23 AM, Xi Ruoyao wrote:
On Fri, 2021-08-27 at 15:28 -0600, Jeff Law via Gcc-patches wrote:
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
On 2021/8/27 15:45, Richard Biener wrote:
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
Hi Richard,
> I hoped the one jumping on the "traps" bandwagon would have tackled -ftrapv
> first.
I did, back in 2003 I introduced (or helped introduce) the flag "-fwrapv" 😊
https://gcc.gnu.org/legacy-ml/gcc-patches/2003-03/msg02126.html
Prior to that, signed overflow was undefined in the mi
On Mon, 30 Aug 2021, Xionghu Luo wrote:
>
>
> On 2021/8/27 15:45, Richard Biener wrote:
> > 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 B
On Mon, Aug 30, 2021 at 11:13 AM Roger Sayle wrote:
>
>
> Hi Richard,
>
> > I hoped the one jumping on the "traps" bandwagon would have tackled -ftrapv
> > first.
>
> I did, back in 2003 I introduced (or helped introduce) the flag "-fwrapv" 😊
> https://gcc.gnu.org/legacy-ml/gcc-patches/2003-03/ms
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-11.2.0.sv.po', has ju
Hi,
On Tue, Aug 17, 2021 at 10:43 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> abort() is used in gcc_assert() and gcc_unreachable() which is used by
> target
> libraries such as libgcov.a. This patch changes the abort() definition
> under
> certain conditions. If inhibit_
Currently for evex vpcmpeqb instruction, we have two forms of rtl
template representation, one is (unspec [op1 op2] UNSPEC_MASK_EQ), the
other is (unspec [op1, op2, const_int 0] UNSPEC_PCMP), which increases
the maintenance burden, such as optimization (not: vpcmpeqb)
to (vpcmpneqb) requires two de
Hi!
Ping -- we still need to plug the memory leak; see patch attached, and/or
long discussion here:
On 2021-08-16T14:10:00-0600, Martin Sebor wrote:
> On 8/16/21 6:44 AM, Thomas Schwinge wrote:
>> On 2021-08-12T17:15:44-0600, Martin Sebor via Gcc wrote:
>>> On 8/6/21 10:57 AM, Thomas Schwinge w
Document Roger's patch
https://gcc.gnu.org/g:3c496e92d795a8fe5c527e3c5b5a6606669ae50d
OK? Suggestions?
Tobias
PS: I have a pending wwwdocs patch for OpenMP, but I think I will hold
off with an updated version until Jakub's next patch – to avoid too many
updates.
PPS: I also have a pending wwwd
Hello Christophe,
it seems there are a couple of more abort() declarations:
libgcc/unwind-arm-common.inc:extern void abort (void);
libgcc/config/c6x/pr-support.c:extern void abort (void);
libgcc/config/arm/pr-support.c:extern void abort (void);
libgcc/config/arm/linux-atomic-64bit.c:extern void
Hi!
Ping. For easy reference I've again attached Richard Sandiford's
"libgcc: Add missing runtime exception notices".
On 2021-07-12T17:34:09+0100, Richard Sandiford via Gcc-patches
wrote:
> David Edelsohn writes:
>> On Mon, Jul 12, 2021 at 11:58 AM Richard Sandiford
>> wrote:
>>> David Edels
On Mon, Aug 30, 2021 at 12:55 PM Sebastian Huber
wrote:
>
> Hello Christophe,
>
> it seems there are a couple of more abort() declarations:
>
> libgcc/unwind-arm-common.inc:extern void abort (void);
> libgcc/config/c6x/pr-support.c:extern void abort (void);
> libgcc/config/arm/pr-support.c:extern
On Mon, Aug 30, 2021 at 12:59 PM Thomas Schwinge
wrote:
>
> Hi!
>
> Ping. For easy reference I've again attached Richard Sandiford's
> "libgcc: Add missing runtime exception notices".
>
> On 2021-07-12T17:34:09+0100, Richard Sandiford via Gcc-patches
> wrote:
> > David Edelsohn writes:
> >> On
On 30/08/2021 13:44, Richard Biener wrote:
On Mon, Aug 30, 2021 at 12:55 PM Sebastian Huber
wrote:
Hello Christophe,
it seems there are a couple of more abort() declarations:
libgcc/unwind-arm-common.inc:extern void abort (void);
libgcc/config/c6x/pr-support.c:extern void abort (void);
libgc
Do not declare abort in "libgcc/unwind-arm-common.inc" since it is already
provided by "tsystem.h". It fixes the following build error:
In file included from libgcc/config/arm/unwind-arm.c:144:
libgcc/unwind-arm-common.inc:55:24: error: macro "abort" passed 1 arguments,
but takes just 0
55 |
On Mon, 30 Aug 2021, guojiufu wrote:
> On 2021-08-30 14:15, Jiufu Guo wrote:
> > Hi,
> >
> > In patch r12-3136, niter->control, niter->bound and niter->cmp are
> > derived from number_of_iterations_lt. While for 'until wrap condition',
> > the calculation in number_of_iterations_lt is not align
This reworks the previous attempt to avoid leaving around if-converted
scalar code in BB vectorized loop bodies to keep costing independent
subgraphs which should address the observed regression with 519.lbm_r.
For this to work we now first cost all subgraphs and only after
doing that proceed to e
On Mon, 30 Aug 2021, Eric Botcazou wrote:
> > This makes -fexceptions enabled by -fnon-call-exceptions, removing
> > the odd state of !flag_exceptions && flag_non_call_exceptions from
> > middle-end consideration.
>
> FWIW fine with me.
Thanks - pushed.
Richard.
> -Original Message-
> From: Dragan Mladjenovic
> Sent: 17 August 2021 17:59
> To: 'Andrew Pinski'
> Cc: 'gcc-patches@gcc.gnu.org'
> Subject: RE: [PATCH] [MIPS] Hazard barrier return support
>
>
>
> > -Original Message-
> > From: Dragan Mladjenovic
> > Sent: 16 August 2021 22
On Fri, Aug 27, 2021 at 8:53 AM liuhongt wrote:
>
> When gimple simplifcation try to combine op and vec_cond_expr to cond_op,
> it doesn't check if mask type matches. It causes an ICE when expand cond_op
> with mismatched mode.
> This patch add a function named cond_vectorized_internal_fn_supp
On 8/30/2021 12:52 AM, Xi Ruoyao via Gcc-patches wrote:
These two patches look good to me. Still, need a maintainer's approval.
Consider them approved.
Thanks,
Jeff
On 8/30/2021 12:51 AM, Richard Biener wrote:
On Fri, Aug 27, 2021 at 9:31 PM Jeff Law via Gcc-patches
wrote:
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
On 8/30/2021 2:47 AM, YunQiang Su wrote:
在 2021/8/30 5:00, Jeff Law 写道:
On 8/28/2021 1:23 AM, Xi Ruoyao wrote:
On Fri, 2021-08-27 at 15:28 -0600, Jeff Law via Gcc-patches wrote:
On 8/26/2021 10:58 PM, YunQiang Su wrote:
for some instructions, MIPS r6 uses different encoding other than
t
On Sun, Aug 29, 2021 at 12:11:23PM -0700, H.J. Lu wrote:
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -1840,6 +1840,54 @@ init_cumulative_args (CUMULATIVE_ARGS *cum, /*
> Argument info to initialize */
>cfun->machine->arg_reg_available = (cum->nregs > 0);
> }
>
> +/*
Hi!
I have backported 9080a3bf2329, a3f6bd789149, and f0529d96f567 to the
GCC 11 branch. This solves PR102062, but is a >2% performance win for
such a trivial patch, too, which is enough reason on its own :-)
Segher
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578135.html
Are there any further comments on the patch?
Richard, you were kind enough to review the first two patches in this
series. Would you mind doing the same for this one? It continues in
the same vein.
Martin
On 8/25/21 3:26
Hi,
This patch changes WITH_LOCAL_DRUNTIME to build with `-fno-druntime'.
The D tests done at configure-time for libphobos don't require a
functional D run-time, so don't enable any run-time features.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
committed to mainline.
R
Hi!
The following patch changes the way destructor calls are sanitized. Currently,
they are sanitized just like any other member calls, transforming `a::~a(this)'
to `a::~a(.UBSAN_NULL(SAVE_EXPR(this)), SAVE_EXPR(this))'. However, this is a
problem for coroutines. In some cases, a destructor call
This commit introduces an ICE building libgcc for 32-bit SPARC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102133
--
Joseph S. Myers
jos...@codesourcery.com
Hi,
Darwin provides an implementation of sbrk, which is detected by the
libiberty configuration process.
However, (like most of the BSD-derivatives) sbrk/brk are deprecated on
Darwin which leads to build-time warnings. It seems that the configure
process does not see the deprecation warnings as
The following change fixes the build of libgfortran on hppa*-hp-hpux[01]*.
Tested on hppa64-hp-hpux11.11 and hppa2.0w-hp-hpux11.11. Committed to trunk.
Dave
---
Fix libgfortran build on hppa*-hp-hpux[01]*
Add include hack to define PRIdPTR, PRIiPTR, PRIoPTR, PRIuPTR, PRIxPTR
and PRIXPTR in int
I plan to make use of libbacktrace within GDB. I believe that the
patch below needs to be merged into GCCs toplevel directory and then
back-ported to the binutils-gdb repository.
Is this OK to merge?
Thanks,
Andrew
---
GDB is going to start using libbacktrace, so add a build dependency
between
Thanks Jeff. I've reached out to Roger to see if the fix would be better suited
in CCP. If that isn't the right spot, I'll reach out to Aldy and Andrew about
getting the fix in VRP/Ranger.
From: Jeff Law
Sent: Sunday, August 22, 2021 8:11 PM
To: Victor Tong ; gcc-patches@gcc.gnu.org
; pins...
I noticed that concepts-lambda14.C had two useless requires-expressions:
static_assert(requires { C; });
always succeeds, because C is always a valid expression for any type,
regardless of whether C is satisfied for a particular type. Presumably the
user means
static_assert(requires { requi
From: Andrew Pinski
Since == is not portable, it is better to use = in contrib/
download_prerequisites. The only place == was used is inside
the function md5_check which is used only on Mac OS X.
Tested on Mac OS X as:
./contrib/download_prerequisites --md5
Both with all files having the correc
The check of arguments to ALLOCATE did not properly implement
F2008:C628 / F2018:C932, as it excluded unlimited polymophics,
in contrast to the standard text. Fix this.
Committed Steve's patch as obvious after regtesting on x86_64-pc-linux-gnu.
Thanks,
Harald
Fortran - correct check for constr
A whitespace issue during parsing.
Committed Steve's patch as obvious after regtesting on x86_64-pc-linux-gnu.
Thanks,
Harald
Fortran - fix whitespace issue during parsing of assigned goto
gcc/fortran/ChangeLog:
PR fortran/102113
* match.c (gfc_match_goto): Allow for whitespac
On 8/30/2021 1:09 PM, Joseph Myers wrote:
This commit introduces an ICE building libgcc for 32-bit SPARC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102133
I've sent Hongtao a testcase which is ICE-ing. It was mcore-elf, but I
saw similar failures on a half-dozen architectures before I re
On Fri, Aug 27, 2021 at 08:44:43AM -0500, Bill Schmidt via Gcc-patches wrote:
> On 8/23/21 2:03 PM, Paul A. Clarke wrote:
> > + __fpscr_save.__fr = __builtin_mffsl ();
>
> As pointed out in the v1 review, __builtin_mffsl is enabled (or supposed to
> be) only for POWER9 and later. This will fail
On Fri, Jul 23, 2021 at 1:33 PM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> The problem here is the x86_64 back-end uses a signed integer
> for alignment and then divides by BITS_PER_UNIT so if we had
> INT_MIN (which is what 1<<28*8 is), we would get the wrong result.
>
> This
As discussed in the PR, we were giving a lot of unnecessary errors for this
testcase because we didn't try to do constant evaluation until
convert_nontype_argument, which happens for each of the candidates. But
when looking at a template-id as the function operand of a call, we can try
to fold arg
Hi Paul,
On 8/30/21 4:16 PM, Paul A. Clarke wrote:
On Fri, Aug 27, 2021 at 08:44:43AM -0500, Bill Schmidt via Gcc-patches wrote:
On 8/23/21 2:03 PM, Paul A. Clarke wrote:
+ __fpscr_save.__fr = __builtin_mffsl ();
As pointed out in the v1 review, __builtin_mffsl is enabled (or supposed t
While working on the patch for PR101460, I noticed that we were losing the
expression location when folding class prvalue expressions. The final patch
doesn't fold class prvalues, but this still seems a worthwhile change. I
don't add location wrappers for scalar prvalues because many callers are
I noticed that after the static_assert failures in lwg3466.cc, we got
various follow-on errors because we went ahead and tried to instantiate the
promise member functions even after instantiating the class itself ran
into problems. Interrupting instantiation of the class itself seems likely
to cau
There was an issue when trying to use an element from an array constructor
which was a broken in a way probably only Gerhard could conceive.
We hit an assert that can be replaced by more robust code.
Patch is basically Steve's.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
Most of the state-management code in the analyzer involves
modifying state objects in-place, which implies a single outcome.
(I originally implemented in-place modification because I wanted
to avoid having to create copies of state objects, and it's now
very difficult to change this aspect of the a
On Mon, Aug 30, 2021 at 05:25:01PM -0400, Jason Merrill via Gcc-patches wrote:
> While working on the patch for PR101460, I noticed that we were losing the
> expression location when folding class prvalue expressions. The final patch
> doesn't fold class prvalues, but this still seems a worthwhile
On Mon, Aug 30, 2021 at 10:13:21AM +0200, Martin Liška wrote:
> On 8/27/21 19:45, Gleb Fotengauer-Malinovskiy wrote:
> > 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
Hi,
This is a patch to generate debug info for local variables as well as globals.
With this, "ptype foo", "info variables", "info locals" etc works when
debugging in GDB.
Finalizing of global variable declares are moved to after locations are handled
and done
as Fortran, C, Go etc do it. Also
Well I seemed to have attached the wrong testcase. Here is the proper one
attached.
Regards,
-Ursprungligt meddelande-
Från: Petter Tomner
Skickat: den 31 augusti 2021 02:14
Till: gcc-patches@gcc.gnu.org; j...@gcc.gnu.org
Ämne: [PATCH] jit : Generate debug info for variables
Hi,
This
During overload resolution, when the arity of a function template
clearly disagrees with the arity of the call, no specialization of the
function template could yield a viable candidate. The deduction routine
type_unification_real already notices this situation, but not before
it substitutes expli
In the context of overload resolution we have the notion of a "bad"
argument conversion, which is a conversion that "would be a permitted
with a bending of the language standards", and we handle such bad
conversions specially. In particular, we rank a bad conversion as
better than no conversion bu
Here when partially substituting into the pack expansion, substitution
into the constexpr if yields a still-dependent tree, so tsubst_expr
returns an IF_STMT with an unsubstituted IF_COND and with
IF_STMT_EXTRA_ARGS added to. Hence after partial substitution
the pack expansion pattern still refers
From: Andrew Pinski
So the main issue here is that some signals are not setup unlike collect2.
So this merges the setting up of the signal handlers to one function in
collect-utils and has collect2 and lto-wrapper call that function.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regres
Jeff Law via Gcc-patches 于2021年8月30日周一 下午9:48写道：
>
>
>
> On 8/30/2021 2:47 AM, YunQiang Su wrote:
> > 在 2021/8/30 5:00, Jeff Law 写道:
> >>
> >>
> >> On 8/28/2021 1:23 AM, Xi Ruoyao wrote:
> >>> On Fri, 2021-08-27 at 15:28 -0600, Jeff Law via Gcc-patches wrote:
>
> On 8/26/2021 10:58 PM, Y
On 2021-08-30 20:02, Richard Biener wrote:
On Mon, 30 Aug 2021, guojiufu wrote:
On 2021-08-30 14:15, Jiufu Guo wrote:
> Hi,
>
> In patch r12-3136, niter->control, niter->bound and niter->cmp are
> derived from number_of_iterations_lt. While for 'until wrap condition',
> the calculation in numb
Hi Segher,
On 8/27/21 6:07 PM, Segher Boessenkool wrote:
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 automatical
From: Andrew Pinski
The problem here is with -fPIC, both cmp and move
don't bind locally so they are not even tried to be
inlined. This fixes the issue by marking both
functions as static and now the testcase passes
for both -fPIC and -fno-PIC cases.
OK? Tested on x86_64-linux-gnu.
gcc/testsui
On Mon, Aug 30, 2021 at 4:27 PM Martin Sebor wrote:
>
> Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578135.html
>
> Are there any further comments on the patch?
>
> Richard, you were kind enough to review the first two patches in this
> series. Would you mind doing the same for th
On Mon, Aug 30, 2021 at 10:22 PM Andrew Burgess
wrote:
>
> I plan to make use of libbacktrace within GDB. I believe that the
> patch below needs to be merged into GCCs toplevel directory and then
> back-ported to the binutils-gdb repository.
>
> Is this OK to merge?
OK.
> Thanks,
> Andrew
>
> -
On Mon, Aug 30, 2021 at 10:49 PM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> Since == is not portable, it is better to use = in contrib/
> download_prerequisites. The only place == was used is inside
> the function md5_check which is used only on Mac OS X.
>
> Tested on Mac OS
Hi Tobias,
s/However, as argument they are also iteroperable/However, as an argument
they are also interoperable/
s/ /* else: valid only sind F2018 - and an assumed-shape/rank
array; however, gfc_notify_std is already called when
those array type are used. Thus, silently accept F200x. */
On Fri, Aug 27, 2021 at 6:50 AM Hongtao Liu wrote:
>
> On Thu, Aug 26, 2021 at 7:09 PM Richard Biener via Gcc-patches
> wrote:
> >
> > On Thu, Aug 26, 2021 at 12:50 PM Richard Sandiford
> > wrote:
> > >
> > > Richard Biener via Gcc-patches writes:
> > > > On Thu, Aug 26, 2021 at 11:06 AM Richar
On Mon, Aug 30, 2021 at 11:38 PM Andrew Pinski via Gcc-patches
wrote:
>
> On Fri, Jul 23, 2021 at 1:33 PM apinski--- via Gcc-patches
> wrote:
> >
> > From: Andrew Pinski
> >
> > The problem here is the x86_64 back-end uses a signed integer
> > for alignment and then divides by BITS_PER_UNIT so i
On Tue, Aug 31, 2021 at 4:17 AM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> So the main issue here is that some signals are not setup unlike collect2.
> So this merges the setting up of the signal handlers to one function in
> collect-utils and has collect2 and lto-wrapper call
On Tue, Aug 31, 2021 at 7:41 AM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> The problem here is with -fPIC, both cmp and move
> don't bind locally so they are not even tried to be
> inlined. This fixes the issue by marking both
> functions as static and now the testcase passes
Time to hopefully earn some goodwill from the team; this patch fixes
a P1 wrong-code-on-valid regression in ivopts. Many thanks to Andrew
Pinski for help with the analysis.
Consider the code fragment below:
int i;
for (j=0; j<10; j++)
i++;
This results in a loop conta
On Tue, Aug 31, 2021 at 2:11 PM Richard Biener
wrote:
>
> On Fri, Aug 27, 2021 at 6:50 AM Hongtao Liu wrote:
> >
> > On Thu, Aug 26, 2021 at 7:09 PM Richard Biener via Gcc-patches
> > wrote:
> > >
> > > On Thu, Aug 26, 2021 at 12:50 PM Richard Sandiford
> > > wrote:
> > > >
> > > > Richard Bien
On Tue, Aug 31, 2021 at 2:30 PM Hongtao Liu wrote:
>
> On Tue, Aug 31, 2021 at 2:11 PM Richard Biener
> wrote:
> >
> > On Fri, Aug 27, 2021 at 6:50 AM Hongtao Liu wrote:
> > >
> > > On Thu, Aug 26, 2021 at 7:09 PM Richard Biener via Gcc-patches
> > > wrote:
> > > >
> > > > On Thu, Aug 26, 2021
On 8/31/21 01:03, Gleb Fotengauer-Malinovskiy wrote:
On Mon, Aug 30, 2021 at 10:13:21AM +0200, Martin Liška wrote:
On 8/27/21 19:45, Gleb Fotengauer-Malinovskiy wrote:
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:e05a11
76 matches
Mail list logo
