On 3/29/22 02:02, Pokechu22 wrote:
On Thu, Mar 24, 2022 at 1:53 PM Jason Merrill wrote:
Thanks! For future reference, the patch doesn't apply easily because
gmail wrapped lines; for sending patches via gmail you'll need to use
attachments. Or you can use another MUA, or git send-email. This
Optimize vec_splats of constant vec_extract for V2DI/V2DF, PR target 99293.
This is version 2 of the patch. The original patch was:
| Date: Mon, 28 Mar 2022 12:26:02 -0400
| Subject: [PATCH 1/4] Optimize vec_splats of constant vec_extract for
V2DI/V2DF, PR target 99293.
| Message-ID:
|
On 3/29/22 16:59, Marek Polacek wrote:
On Tue, Mar 29, 2022 at 04:53:21PM -0400, Marek Polacek via Gcc-patches wrote:
This patch fixes a crash in conversion_warning on a null expression.
It is null because the testcase uses the GNU A ?: B extension. We
could also use op0 instead of op1 in this
On 3/29/22 16:53, Marek Polacek wrote:
This patch fixes a crash in conversion_warning on a null expression.
It is null because the testcase uses the GNU A ?: B extension. We
could also use op0 instead of op1 in this case, but it doesn't seem
to be necessary.
I wonder why we don't represent
On 3/25/22 18:16, Marek Polacek wrote:
The attached 93280 test no longer ICEs but looks like it was never added to the
testsuite. The 104583 test, modified so that it closely resembles 93280, still
ICEs.
The problem is that in 104583 we have a value-init from {} (the line A a{};),
so this code
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 Croatian team of translators. The file is available at:
https://translationproject.org/latest/gcc/hr.po
(This file,
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 Croatian team of translators. The file is available at:
https://translationproject.org/latest/gcc/hr.po
(This file,
In case it's helpful, I've included copies of the patches as
attachments (as well as a single patch that is all of these changes
merged together).
--Poke
On Tue, Mar 22, 2022 at 12:50 PM Pokechu22 wrote:
>
> While working on a separate patch, I found several typos on the website.
> I have only
In r12-7809-g5f6197d7c197f9 I added -fdump-analyzer-untracked as support
for DejaGnu testing of an optimization of -fanalyzer,
PR analyzer/104954.
PR testsuite/105085 notes testsuite failures of the form:
FAIL: gcc.dg/analyzer/untracked-1.c (test for excess errors)
Excess errors:
cc1:
Dear all,
during error recovery on invalid declarations of functions as
coarrays we may hit multiple places with NULL pointer dereferences.
The attached patch provides a minimal and conservative solution.
Regtested on x86_64-pc-linux-gnu. OK for mainline/11-branch?
Thanks,
Harald
From
On 3/27/22 08:37, Zhao Wei Liew wrote:
On Fri, 25 Mar 2022 at 05:58, Jason Merrill wrote:
+ if (current_function_decl
+ && (DECL_CONSTRUCTOR_P (current_function_decl)
+ || DECL_DESTRUCTOR_P (current_function_decl))
+ && TREE_CODE (expr) == NOP_EXPR
+
On Tue, Mar 29, 2022 at 04:53:21PM -0400, Marek Polacek via Gcc-patches wrote:
> This patch fixes a crash in conversion_warning on a null expression.
> It is null because the testcase uses the GNU A ?: B extension. We
> could also use op0 instead of op1 in this case, but it doesn't seem
> to be
On 3/29/22 04:05, Jakub Jelinek wrote:
Hi!
The concepts support (in particular template introductions from concepts TS)
broke the following testcase, valid unnamed bitfields with dependent
types (or even just typedefs) were diagnosed as typos (: instead of correct
::) in template introduction
This patch fixes a crash in conversion_warning on a null expression.
It is null because the testcase uses the GNU A ?: B extension. We
could also use op0 instead of op1 in this case, but it doesn't seem
to be necessary.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR
On 3/29/22 15:22, Patrick Palka wrote:
Here we're crashing when diagnosing a failed __is_constructible constraint
because diagnose_atomic_constraint don't know how to diagnose a trait
that diagnose_trait_expr doesn't specifically handle. This patch fixes
this by falling through to the default
Dear all,
I committed an obvious patch by Steve to avoid a NULL pointer dereference
on checking for invalid specification of an elemental procedure argument:
https://gcc.gnu.org/g:69db6e7f4e1d07bf8f33e93a29139cc16c1e0a2f
Regtested on x86_64-pc-linux-gnu.
Thanks,
Harald
From
Hi!
On Mon, Feb 21, 2022 at 03:17:47PM -0600, Paul A. Clarke wrote:
> gcc/testsuite
> * g++.dg/debug/dwarf2/const2.C: Move to g++.target/powerpc.
> * g++.dg/other/darwin-minversion-1.C: Likewise.
> * g++.dg/eh/ppc64-sighandle-cr.C: Likewise.
This one uses
// { dg-do run {
Ping!
On 2022-03-15 17:26, Simon Marchi wrote:
> From: Simon Marchi
>
> [Sending to binutils, gdb-patches and gcc-patches, since it touches the
> top-level Makefile/configure]
>
> I have my debuginfod library installed in a non-standard location
> (/opt/debuginfod), which requires me to set
>
Hi!
On Tue, Feb 22, 2022 at 07:56:40PM -0600, Paul A. Clarke wrote:
> On Tue, Feb 22, 2022 at 06:41:45PM -0600, Segher Boessenkool wrote:
> > That said...
> >
> > > -/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
> > > -/* { dg-skip-if "" { powerpc*-*-darwin* } } */
> > > +/* {
On Tue, 29 Mar 2022, Thomas Schwinge wrote:
> I'm generally very much in favor of abstracting functionality into
> separate functions. Here, however, there ever existed only one user of
> 'gcc/opt-functions.awk:lang_enabled_by', its interface is a bit clumsy,
> leading to (slightly) confusing
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
These tests depend on unexpected handlers, which are no longer declared
for C++23 mode. Adjust the target specifier so they don't run.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept06.C: Disable for C++23.
libstdc++-v3/ChangeLog:
Here we're crashing when diagnosing a failed __is_constructible constraint
because diagnose_atomic_constraint don't know how to diagnose a trait
that diagnose_trait_expr doesn't specifically handle. This patch fixes
this by falling through to the default case in this situation.
Bootstrapped and
On Tue, 29 Mar 2022, Thomas Schwinge wrote:
> | --- gcc/c-family/c.opt
> | +++ gcc/c-family/c.opt
> | [...]
> | +Wc++11-extensions
> | +C++ ObjC++ Var(warn_cxx11_extensions) Warning LangEnabledBy(C++ ObjC++)
> Init(1)
> | +Warn about C++11 constructs in code compiled with an older standard.
> |
Hi Tobias,
Am 29.03.22 um 09:14 schrieb Tobias Burnus:
Hi Harald,
On 28.03.22 22:03, Harald Anlauf via Fortran wrote:
All current cases of printing a HOST_WIDE_INT in gcc/fortran/ use
'sprintf', and I did not find any other use of %wd/%wu. So the
mentioned implementation is not really
On Tue, 29 Mar 2022, Thomas Schwinge wrote:
> | --- gcc/c-family/c.opt
> | +++ gcc/c-family/c.opt
> | [...]
> | +# Defining these options here in addition to common.opt is necessary
> | +# in order for the default -Wall setting of -Wuse-after-free=2 to take
> | +# effect.
> | +
> |
On Tue, 29 Mar 2022, Thomas Schwinge wrote:
> | --- gcc/c-family/c.opt
> | +++ gcc/c-family/c.opt
> | [...]
> | Warray-bounds
> | -LangEnabledBy(C ObjC C++ LTO ObjC++,Wall)
> | +LangEnabledBy(C ObjC C++ LTO ObjC++)
> | ; in common.opt
> |
> | Warray-bounds=
>
> OK to push the attached
We no longer emit a bogus warning for the below testcase after
r11-3266-g4839de55e2c986.
Tested on x86_64-pc-linux-gnu, committed to trunk as obvious.
PR c++/71637
gcc/testsuite/ChangeLog:
* c-c++-common/Wmisleading-indentation-6.c: New test.
---
On Mon, Mar 28, 2022 at 06:59:14PM -0500, Segher Boessenkool wrote:
> On Mon, Mar 28, 2022 at 12:28:55PM -0400, Michael Meissner wrote:
> > In looking at PR target/99293, I noticed that the vsx_extract_
> > pattern for V2DImode and V2DFmode only allowed traditional floating point
> > registers,
On 29/03/2022 17:32, Jakub Jelinek via Gcc-patches wrote:
On Tue, Mar 29, 2022 at 04:32:10PM +0100, Richard Earnshaw wrote:
On arm the AAPCS states that an HFA is determined by the 'shape' of
the object after layout has been completed, so anything that adds no
members and does not cause the
On Tue, Mar 29, 2022 at 12:13:51PM -0400, Marek Polacek wrote:
> This patch fixes a wrong -Wimplicit-fallthrough warning for
>
> case 0:
> if (1) // wrong may fallthrough
> return 0;
> case 1:
>
> which in .gimple looks like
>
> : // case 0
> if (1 != 0) goto ; else
On Tue, Mar 29, 2022 at 04:32:11PM +0100, Richard Earnshaw wrote:
>
> On aarch64 the AAPCS64 states that an HFA is determined by the 'shape' of
> the object after layout has been completed, so anything that adds no
> members and does not cause the layout to be modified should be ignored
> for the
On Tue, Mar 29, 2022 at 04:32:10PM +0100, Richard Earnshaw wrote:
>
> On arm the AAPCS states that an HFA is determined by the 'shape' of
> the object after layout has been completed, so anything that adds no
> members and does not cause the layout to be modified should be ignored
> for the
This patch fixes a wrong -Wimplicit-fallthrough warning for
case 0:
if (1) // wrong may fallthrough
return 0;
case 1:
which in .gimple looks like
: // case 0
if (1 != 0) goto ; else goto ;
:
D.1987 = 0;
// predicted unlikely by early return (on trees)
The arm port has an optimization used during selection of the
function's ABI to permit deviation from the strict ABI when the
function does not escape the current translation unit.
Unfortunately, the ABI selection it makes can be unsafe if it changes
how a result is returned because not enough
Ping.
On Tue, Mar 08, 2022 at 01:59:47PM -0600, Paul A. Clarke via Gcc-patches wrote:
> Ping.
>
> On Mon, Feb 21, 2022 at 03:17:47PM -0600, Paul A. Clarke via Gcc-patches
> wrote:
> > Also adjust DejaGnu directives, as specifically requiring "powerpc*-*-*" is
> > no
> > longer required.
> >
>
Ping.
On Tue, Mar 08, 2022 at 02:03:04PM -0600, Paul A. Clarke via Gcc-patches wrote:
> Gentle ping. I am grateful for the initial review, but seek closure on the
> final couple of discussion items. Thanks!
>
> PC
>
> On Tue, Feb 22, 2022 at 07:56:40PM -0600, Paul A. Clarke via Gcc-patches
>
On aarch64 the AAPCS64 states that an HFA is determined by the 'shape' of
the object after layout has been completed, so anything that adds no
members and does not cause the layout to be modified should be ignored
for the purposes of determining which registers are used for parameter
passing.
A
On arm the AAPCS states that an HFA is determined by the 'shape' of
the object after layout has been completed, so anything that adds no
members and does not cause the layout to be modified should be ignored
for the purposes of determining which registers are used for parameter
passing.
A
On 3/29/22 03:24, Thomas Schwinge wrote:
Hi!
On 2022-01-15T17:00:11-0700, Martin Sebor via Gcc-patches
wrote:
On 1/11/22 15:40, Jason Merrill wrote:
On 11/30/21 17:32, Martin Sebor via Gcc-patches wrote:
[default setting of the option]
Let's put =2 in -Wall for now.
I've adjusted
On 29.03.22 16:28, Tobias Burnus wrote:
On 29.03.22 15:39, Tom de Vries wrote:
Any comments?
I think it would be useful to have additionally some wording for the
(new in GCC 12/new since today) macros, i.e. something like:
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -27546,6
Hi Tom,
On 29.03.22 15:39, Tom de Vries wrote:
Any comments?
+(e.g.@: @samp{sm_35}). Valid architecture strings are @samp{sm_30},
+@samp{sm_35}, @samp{sm_53} @samp{sm_70}, @samp{sm_75} and
+@samp{sm_80}. The default target architecture is sm_30.
Missing comma (",") between sm_53 and sm_70.
Hi,
Add preprocessor macros __PTX_ISA_VERSION_MAJOR__ and
__PTX_ISA_VERSION_MINOR__.
For the default 6.0, we have:
...
$ echo | cc1 -E -dD - 2>&1 | grep PTX_ISA_VERSION
#define __PTX_ISA_VERSION_MAJOR__ 6
#define __PTX_ISA_VERSION_MINOR__ 0
...
and for 3.1, we have:
...
$ echo | cc1
Hi,
While working on the Kalray port of gcc, I noticed that the hook
TARGET_ASM_FINAL_POSTSCAN_INSN is not called after emitting an instruction
coming from a basic asm block. Here is a patch which fixes this behavior.
The following check:
```
$ find gcc/config/ -type f -exec grep "#define
Currently the existing libcalls for restoring registers have the
requirement that they must be tail called by the parent function, so
that they can safely return through the restored return address
register. This does impose the restriction that the libcalls cannot be
used if there already exists
On 13/01/2021 15:07, Chung-Lin Tang wrote:
We currently emit errors, but do not fatally cause exit of the program
if those
are not met. We're still unsure if complete block-out of program
execution is the right
thing for the user. This can be discussed later.
After the Unified Shared Memory
Hi,
Update nvptx documentation:
- Use meaningful terms: "PTX ISA target architecture" and "PTX ISA version".
- Remove invalid claim that "ISA strings must be lower-case".
- Add missing sm_xx entries.
- Fix default ISA.
- Add march, copying misa doc.
- Declare misa an march alias.
- Add march-map.
On 3/29/22 08:43, Jonathan Wakely wrote:
Tested powerpc64le-linux, OK for trunk?
OK.
-- >8 --
This allows the gpp_std_list variable to be set in ~/.dejagnurc instead
of using the GXX_TESTSUITE_STDS environment variable. This is
consistent with how other defaults such as tool_timeout can be
Tested powerpc64le-linux, OK for trunk?
-- >8 --
This allows the gpp_std_list variable to be set in ~/.dejagnurc instead
of using the GXX_TESTSUITE_STDS environment variable. This is
consistent with how other defaults such as tool_timeout can be set.
The environment variable can still be used
Hi,
In the docs we have for m64:
...
Ignored, but preserved for backward compatibility. Only 64-bit ABI is
supported.
...
But with --target-help, we have instead:
...
$ gcc --target-help
...
-m64Generate code for a 64-bit ABI.
...
which could be interpreted as meaning that generating
Hi,
Say we have an sm_50 board, and we want to run a benchmark using the highest
possible march setting.
Currently there's march=sm_30, march=sm_35, march=sm_53, but no march=sm_50.
So, we'd need to pick march=sm_35.
Likewise, for a test script that handles multiple boards, we'd need a mapping
On Tue, 29 Mar 2022 at 10:28, Thomas Schwinge wrote:
>
> Hi!
>
> On 2021-05-19T13:09:29-0400, Marek Polacek via Gcc-patches
> wrote:
> > On Wed, May 19, 2021 at 05:59:34PM +0100, Jonathan Wakely wrote:
> >> On 19/05/21 12:53 -0400, Marek Polacek wrote:
> >> > On Wed, May 19, 2021 at 05:39:24PM
Hi,
The target option misa has the following description:
...
$ gcc --target-help 2>&1 | grep misa
-misa= Specify the PTX ISA target architecture to use.
...
The name misa is somewhat poorly chosen. It suggests that for a use
-misa=sm_30, sm_30 is the name of a specific
Hi!
Once the three 'LangEnabledBy' option property patches that I've just
posted are accepted, we may proceed here:
On 2012-11-07T18:11:02+, m...@gcc.gnu.org wrote:
> Author: manu
> Date: Wed Nov 7 18:11:01 2012
> New Revision: 193303
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc=rev=193303
Hi!
On 2021-05-19T13:09:29-0400, Marek Polacek via Gcc-patches
wrote:
> On Wed, May 19, 2021 at 05:59:34PM +0100, Jonathan Wakely wrote:
>> On 19/05/21 12:53 -0400, Marek Polacek wrote:
>> > On Wed, May 19, 2021 at 05:39:24PM +0100, Jonathan Wakely via Gcc-patches
>> > wrote:
>> > > ---
Hi!
On 2022-01-15T17:00:11-0700, Martin Sebor via Gcc-patches
wrote:
> On 1/11/22 15:40, Jason Merrill wrote:
>> On 11/30/21 17:32, Martin Sebor via Gcc-patches wrote:
>>> [default setting of the option]
>> Let's put =2 in -Wall for now.
> I've adjusted [...] and pushed r12-6605 [...]
That's
Hi!
On 2018-07-20T15:22:23-0600, Martin Sebor wrote:
> As the last observation in PR 82063 Jim points out that
>
>Both -Warray-bounds and -Warray-bounds= are listed in the c.opt
>file as being enabled by -Wall, but they are the same option,
>and it causes this one option to be
Hi!
On 2012-11-07T18:11:02+, m...@gcc.gnu.org wrote:
> Author: manu
> Date: Wed Nov 7 18:11:01 2012
> New Revision: 193303
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc=rev=193303
> Log:
> 2012-11-07 Manuel López-Ibáñez
>
> * optc-gen.awk: Factor code out to...
> *
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
Once we no longer care about older compilers without this feature, we
can drop these static data members, so the names don't have to be
visible at class scope.
libstdc++-v3/ChangeLog:
* libsupc++/compare (_Strong_order)
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
The conditions that guard the feature test macros in should
match the main definitions of the macros in other headers.
This doesn't matter for GCC, because it supports all the conditions
being tested here, but it does matter for non-GCC
Hi!
The concepts support (in particular template introductions from concepts TS)
broke the following testcase, valid unnamed bitfields with dependent
types (or even just typedefs) were diagnosed as typos (: instead of correct
::) in template introduction during their tentative parsing.
The
Hi!
The testcase in the PR fails under valgrind on mips64 (but only Martin
can reproduce, I couldn't).
But the problem reported there is that SUBST_MODE remembers addresses
into the regno_reg_rtx array, then some splitter needs a new pseudo
and calls gen_reg_rtx, which reallocates the
Hi Harald,
On 28.03.22 22:03, Harald Anlauf via Fortran wrote:
All current cases of printing a HOST_WIDE_INT in gcc/fortran/ use
'sprintf', and I did not find any other use of %wd/%wu. So the
mentioned implementation is not really stressed yet... ;-)
That's all your fault ;-)
(Your commit
On Tue, Mar 29, 2022 at 4:24 AM Alexandre Oliva via Gcc-patches
wrote:
>
>
> Add vxworks to the set of operating systems whose C libraries don't
> support strndup.
>
> Tested on affected systems and on x86_64-linux-gnu. Ok to install?
OK
>
> for gcc/testsuite/ChangeLog
>
> *
On Tue, Mar 29, 2022 at 1:04 AM Alexandre Oliva via Gcc-patches
wrote:
>
>
> Some ARM configurations, such as with -mlong-calls, load the call
> target from the constant pool, breaking the expectation of the test as
> on several other targets.
>
> Tested on an affected target. Ok to install?
OK
On Mon, Mar 28, 2022 at 4:46 PM Marc Poulhiès via Gcc-patches
wrote:
>
> Marc Poulhiès writes:
>
> > On targets that do not have MXX/SSE enabled by default, pr97521
> > and pr96713 fail because they emit warnings:
> >
> > pr97521.c:12:1: warning: MMX vector return without MMX enabled
> >
On Mon, Mar 28, 2022 at 4:46 PM Marc Poulhiès via Gcc-patches
wrote:
>
> Marc Poulhiès writes:
>
> > Test must check for effective support of fpic.
> >
> > Tested on x86_64-pc-linux-gnu{-m32,}.
> >
> > ok for master?
>
> ping?
OK
On Mon, 28 Mar 2022, Richard Sandiford wrote:
> Richard Biener writes:
> > On Mon, 28 Mar 2022, Richard Sandiford wrote:
> >
> >> Richard Biener writes:
> >> > Since we're now vectorizing by default at -O2 issues like PR101908
> >> > become more important where we apply basic-block
On Thu, Mar 24, 2022 at 1:53 PM Jason Merrill wrote:
> Thanks! For future reference, the patch doesn't apply easily because
> gmail wrapped lines; for sending patches via gmail you'll need to use
> attachments. Or you can use another MUA, or git send-email. This time
> I fixed the wrapping by
68 matches
Mail list logo
