For R6+ target, it allows to configure gcc to use compact branches only.
gcc/ChangeLog:
* config.gcc: add -with-compact-branches=policy build option.
* doc/install.texi: Likewise.
---
gcc/ChangeLog| 5 +
gcc/config.gcc | 12 +++-
gcc/doc/install.texi | 1
For MIPSr6, we may wish to use compact-branches only.
Currently, we have to use `always' option, while it is mark as conflict
with pre-R6.
cc1: error: unsupported combination: ‘mips32r2’ -mcompact-branches=always
Just ignore -mcompact-branches=always for pre-R6.
This patch also defines
__mip
On Fri, 19 Feb 2021, Patrick McGehearty via Gcc-patches wrote:
> > Here you're properly computing the mapping from mode to float.h macro
> > prefix (though I think "modename" is a confusing name for the variable
> > used for float.h macro prefixes; to me, "modename" suggests the names such
> > as
Comments inline
On 2/19/2021 3:27 PM, Joseph Myers wrote:
On Tue, 2 Feb 2021, Patrick McGehearty via Gcc-patches wrote:
if (mode == TYPE_MODE (double_type_node))
- ; /* Empty suffix correct. */
+ {
+ ; /* Empty suffix correct. */
+ memcpy
One of the very strong invariants in modules is that module numbers are
allocated such that (other than the current TU), all imports have lesser
module numbers, and also that the binding vector is only appended to
with increasing module numbers. This broke down when module-directives
became a
On Tue, 2 Feb 2021, Patrick McGehearty via Gcc-patches wrote:
> if (mode == TYPE_MODE (double_type_node))
> - ; /* Empty suffix correct. */
> + {
> + ; /* Empty suffix correct. */
> + memcpy (modename, "DBL", 4);
> + }
> else if (mode =
Dear all,
we should not clobber the pointer in case of an allocatable scalar being
an intent(out) dummy argument to a procedure.
Regtested on x86_64-pc-linux-gnu.
OK for master? Since this is a regression, also for backports to 10/9?
Thanks,
Harald
PR fortran/99169 - Do not clobber allocatab
On Thu, Feb 18, 2021 at 10:44:14PM -0500, Michael Meissner wrote:
> On Wed, Feb 17, 2021 at 06:09:39PM -0600, Segher Boessenkool wrote:
> > Why test a p10 patch on a p8?
>
> Well it is just a code gen patch, so I can test it on any system, even an
> x86_64 with a cross compiler. Given that right
On Fri, 2021-02-19 at 11:16 +0100, Andrea Corallo wrote:
> David Malcolm via Gcc-patches writes:
>
> > I tried several approaches to fixing this; this seemed the
> > least invasive.
>
> Hi Dave,
>
> thanks for fixing this.
>
> I do have a trivial question: are we guaranteed that the middle-end
Hi!
On Fri, Feb 19, 2021 at 11:06:16AM +0800, Kewen.Lin wrote:
> on 2021/2/19 上午2:33, Segher Boessenkool wrote:
> > Is there a PR you should mention here?
>
> I thought this is trivial so didn't file one upstream PR. I did a
> searching in upstream bugzilla, PR93453 looks similar but different.
This patch updates libgo to the final Go 1.16 release. Bootstrapped
and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
c89b42d3b9d76dedb35e8478913ddf5367f3b5e6
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index eed9ce01905..217bdd55f1d 100644
--- a/gcc/go/g
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 French team of translators. The file is available at:
https://translationproject.org/latest/gcc/fr.po
(This file, 'gcc-11.1-b20210207.fr.po',
Hello
Sorry for taking so long in replying.
On 29/01/2021 3:03 pm, Jakub Jelinek wrote:
It can also crash if team is NULL, which will happen any time
this is called outside of a parallel. Just try (should go into testsuite
too):
#include
int
main ()
{
omp_event_handle_t ev;
#pragma omp
On 2/19/21 2:48 AM, Franz Sirl wrote:
Am 2021-02-01 um 01:31 schrieb Martin Sebor via Gcc-patches:
The initial -Wnonnull implementation in the middle end took place
too late in the pipeline (just before expansion), and as a result
was prone to false positives (bug 78817). In an attempt to avoid
On 2/18/21 8:51 PM, Jeff Law wrote:
On 2/18/21 7:23 PM, Martin Sebor wrote:
The fix for PR 97172 that removes non-constant VLA bounds from
attribute access is incomplete: it inadvertently removes the bounds
corresponding to just the first VLA argument, and not from subsequent
arguments.
The a
When successfully reading a module CMI, the user gets no indication of
where that CMI was located. I originally didn't consider this a problem
-- the read was successful after all. But it can make it difficult to
interact with build systems, particularly when caching can be involved.
Grovelli
* gcc-11/changes.html (General Improvements): Add a section on
the DWARF version 5 default.
---
htdocs/gcc-11/changes.html | 30 ++
1 file changed, 30 insertions(+)
diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index de75b8d6..04c
Hi Jerry,
On 17.02.21 04:02, Jerry DeLisle wrote:
Attached patch adds to checks. In the case of IMPLICIT typing it
checks to see if the objects listed in the NAMELIST have defined types
andf if not, sets them to the default implicit types.
In the case of IMPLICIT NONE, the types are required b
Pushed to master as obvious.
Martin
gcc/ChangeLog:
PR translation/99167
* params.opt: Fix typo.
---
gcc/params.opt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/params.opt b/gcc/params.opt
index a4e1ac0e88e..0dd9ac406eb 100644
--- a/gcc/params.opt
+++
On 2/19/21 1:33 AM, Tobias Burnus wrote:
On 09.02.21 12:52, Tobias Burnus wrote:
Hi all, hi Thomas,
On 02.02.21 18:15, Tobias Burnus wrote:
I think I will do a combination: If 'identical' is true, I think I
cannot remove it. If it is false, it can be identical or nonoverlapping
– which makes
On 2/19/21 8:00 AM, Tobias Burnus wrote:
In this example, the formal argument is a derived type
and not a class – hence, there is an ICE.
OK for the trunk?
This is OK, could you also check 89219 and 81499 and see if these are
the same or similar.
Much appreciated.
Jerry
In this example, the formal argument is a derived type
and not a class – hence, there is an ICE.
OK for the trunk?
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
F
On 2021-02-19 5:53 a.m., Andre Vieira (lists) wrote:
Hi,
This patch makes sure that allocno copies are not created for
unordered modes. The testcases in the PR highlighted a case where an
allocno copy was being created for:
(insn 121 120 123 11 (parallel [
(set (reg:VNx2QI 217)
Ps. The code in comment is needed, but was commented out due to the early free
issue described in the patch.
Thanks,
Tamar
> -Original Message-
> From: Tamar Christina
> Sent: Friday, February 19, 2021 2:42 PM
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; rguent...@suse.de
> Subject: [PATCH]
Hi Richi,
The attached testcase ICEs due to a couple of issues.
In the testcase you have two SLP instances that share the majority of their
definition with each other. One tree defines a COMPLEX_MUL sequence and the
other tree a COMPLEX_FMA.
The ice happens because:
1. the refcounts are wrong,
This avoids declaring a function with VLA arguments or return values
as inlineable. IPA CP still ICEs, so the testcase has that disabled.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-02-19 Richard Biener
PR middle-end/99122
* tree-inline.c (inline_forbidd
For:
#pragma acc parallel async(1,2)
avoid with C an ICE for the original tree:
#pragma acc parallel async(<<< Unknown tree: c_maybe_const_expr 1, 2 >>>)
It did not ICE with C++, but I think the tree does not make sense, either:
#pragma acc parallel async(<<< Unknown tree: void_cst >>>, 2)
On Tue, Feb 09, 2021 at 09:37:12AM +0100, Martin Liška wrote:
> PING^2
>
> @Honza: ?
Just concerning Windows (though I don't have access to that OS and can't
verify), e.g.
https://github.com/m-labs/uclibc-lm32/blob/master/utils/mmap-windows.c
contains public domain code to emulate mmap on top of
Hi Jakub,
> -Original Message-
> From: Jakub Jelinek
> Sent: 19 February 2021 10:45
> To: Richard Sandiford ; Richard Earnshaw
> ; Ramana Radhakrishnan
> ; Kyrylo Tkachov
>
> Cc: gcc-patches@gcc.gnu.org
> Subject: ARM patch ping
>
> Hi!
>
> I'd like to ping the
> https://gcc.gnu.org/pi
On 15/02/21 16:13 +, Jonathan Wakely wrote:
The __gthread_yield() function is only defined for gthreads targets, so
check _GLIBCXX_HAS_GTHREADS before using it.
Also reorder __thread_relax and __thread_yield so that the former can
use the latter instead of repeating the same preprocessor che
* Jeff Law via Gcc-patches:
> I'd lean towards deferring to gcc12 stage1 given the libstdc++ hack is
> in place. That does mean that glibc will need to work around the
> instance they've stumbled over in ppc's rawmemchr.
We'll need to work around this in the glibc build, too. I'll check if
the
Hi,
This patch makes sure that allocno copies are not created for unordered
modes. The testcases in the PR highlighted a case where an allocno copy
was being created for:
(insn 121 120 123 11 (parallel [
(set (reg:VNx2QI 217)
(vec_duplicate:VNx2QI (subreg/s/v:QI (re
On Thu, Feb 18 2021, Qing Zhao via Gcc-patches wrote:
> (CC’ing Kees Cook on this topic)
>
> Hi,
>
> This is the first version of the complete patch for the new security feature
> for GCC:
>
> Initialize automatic variables with new first class option
> -ftrivial-auto-var-init=[uninitialized|pa
On Fri, 19 Feb 2021, Jakub Jelinek wrote:
> Hi!
>
> The verifiers require that DECL_NONLOCAL or EH_LANDING_PAD_NR
> labels are always the first label if there is more than one label.
>
> When merging blocks, we don't honor that though.
> On the following testcase, we try to merge blocks:
> [cou
Hi!
I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565225.html
patch - PR98998 P1 fix.
Thanks
Jakub
Andrea Corallo via Gcc-patches writes:
> David Malcolm via Gcc-patches writes:
>
>> I tried several approaches to fixing this; this seemed the
>> least invasive.
>
> Hi Dave,
>
> thanks for fixing this.
>
> I do have a trivial question: are we guaranteed that the middle-end will
> not try to add
David Malcolm via Gcc-patches writes:
> I tried several approaches to fixing this; this seemed the
> least invasive.
Hi Dave,
thanks for fixing this.
I do have a trivial question: are we guaranteed that the middle-end will
not try to add any build-in other than a trap?
Regards
Andrea
Hi!
The verifiers require that DECL_NONLOCAL or EH_LANDING_PAD_NR
labels are always the first label if there is more than one label.
When merging blocks, we don't honor that though.
On the following testcase, we try to merge blocks:
[count: 0]:
:
S::~S (&s);
and
[count: 0]:
:
resx 1
where is
Am 2021-02-01 um 01:31 schrieb Martin Sebor via Gcc-patches:
The initial -Wnonnull implementation in the middle end took place
too late in the pipeline (just before expansion), and as a result
was prone to false positives (bug 78817). In an attempt to avoid
the worst of those, the warning was mo
Hi Marcus:
> I could also disable the -mlittle-endian and -mbig-endian options if
> the binutils is too old, but it's questionable if getting a "I don't
> understand -mbig-endian" from gcc is more useful than getting it from
> gas. And it would be more work for the user to fix it since then they
On 09.02.21 12:52, Tobias Burnus wrote:
Hi all, hi Thomas,
On 02.02.21 18:15, Tobias Burnus wrote:
I think I will do a combination: If 'identical' is true, I think I
cannot remove it. If it is false, it can be identical or nonoverlapping
– which makes sense.
Well, it turned out that coarray
Hi all,
This patch introduces the prefer_advsimd_autovec internal tune flag that's
already available on the GCC 8 and 9 branches.
It allows a CPU tuning to specify that it prefers Advanced SIMD for
autovectorisation rather than SVE.
In GCC 10 onwards this can be easily adjusted through the
aarc
On 2/18/21 1:57 PM, Ilya Leoshkevich wrote:
> This series fixes PR99134. Patch 1 is factored out from the pending
> [1], patch 2 is the actual fix. Bootstrapped and regtested on
> s390x-redhat-linux. Ok for master?
>
> [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564380.html
>
>
Hi Harald,
It looks 'obvious' to me too and is certainly OK for master.
Thanks
Paul
On Thu, 18 Feb 2021 at 21:30, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> the PR reports an issue detected with an ASAN instrumented compiler,
> which can also be verified with valgrind. It appears that
Here's an improved version of the patch. Regstrapped on
x86_64-linux-gnu, with and without a patchlet that moved multi-pieces
ahead of setmem, and also tested with riscv32-elf.
Is it ok to install? Or should it wait for stage1?
[PR94092] introduce try store by multiple pieces
From: Alexandre
45 matches
Mail list logo
