On 3/30/22 16:48, Sebastian Huber wrote:
On 30/03/2022 15:30, Sebastian Huber wrote:
On 30/03/2022 13:56, Martin Liška wrote:
Example:
base64 -d log.txt | gcov-tool merge-stream
The gcov-tool uses a new tag which contains the filename of the associated gcov
info file:
gcov-dump b-xilinx_z
On 3/31/22 08:55, Sebastian Huber wrote:
gcc/
* gcov-io.cc (gcov_read_string): Reword documentation comment.
---
gcc/gcov-io.cc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/gcov-io.cc b/gcc/gcov-io.cc
index c2e9e2b6d64..72c40f8eaa0 100644
--- a/gcc/gco
Hi.
Before the patch we have:
$ gcc-11 --help | grep target-help
--target-helpDisplay target specific command line options.
$ gcc-11 --help=common | grep target-help
--target-help Alias for --help=target.
and --target-help prints undocumented options (that was repo
gcc/
* gcov-io.cc (gcov_read_string): Reword documentation comment.
---
gcc/gcov-io.cc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/gcov-io.cc b/gcc/gcov-io.cc
index c2e9e2b6d64..72c40f8eaa0 100644
--- a/gcc/gcov-io.cc
+++ b/gcc/gcov-io.cc
@@ -473,9 +473,9
Since cfg is freed before machine_reorg, just do a rough calculation
of the window according to the layout.
Also according to an experiment on CLX, set window size to 64.
Currently only handle V2DFmode load since it doesn't need any scratch
registers, and it's sufficient to recover cray performanc
The recent change to reject __is_constructible for nested classes with DMI
is breaking some code loudly that was previously only silently broken.
Let's allow simple cases by immediately parsing DMI that do no name lookup;
then being in complete class scope makes no difference.
Tested x86_64-pc-lin
These tests require a target that supports arm soft-float. The
problem is that the test checks for compile-time soft-float support,
but they may hit a problem when the linker complains that it can't
combine the testcase's object file with hard-float init files and
target system libraries.
I don
The CTF format cannot differentiate between a non-defining extern
variable declaration vs. a defining variable declaration (unlike DWARF).
So, the correct behaviour wrt the compiler generating CTF for such
extern variables (i.e., when both the defining and non-defining decl
are present in the same
This commit splits the ctf-array-2.c into ctf-array-5.c and
ctf-variables.c with the following responsibilities:
[1] ctf-array-2.c: Test CTF generation for unsized arrays.
[2] ctf-array-5.c: Test CTF generation for unsized but initialized array.
[3] ctf-variables-3.c: Test CTF generation for exter
2022-03-28 Indu Bhagat
gcc/ChangeLog:
* ctfc.h (struct ctf_container): Introduce a new member.
* ctfout.cc (ctf_list_add_ctf_vars): Use it instead of static
variable.
---
gcc/ctfc.h| 2 ++
gcc/ctfout.cc | 4 +---
2 files changed, 3 insertions(+), 3 deletions(-)
Hello,
This patch set fixes PR debug/105089.
[PS: The first patch in the series "ctfc: get rid of the static variable in
ctf_list_add_ctf_vars" is unrelated to the PR and is combined here only for
ease of review.]
As noted in the PR debug/105089, gcc is emitting two CTF variable records
where it
On Tue, Mar 15, 2022 at 02:18:00PM +0100, Jakub Jelinek wrote:
> On Fri, Jan 28, 2022 at 11:50:26AM -0600, Bill Schmidt via Gcc-patches wrote:
> > PR104004 caught some misses on my part in converting to the new built-in
> > function infrastructure. In particular, I forgot to mark all of the
> > "
On Mon, Mar 28, 2022 at 05:06:00PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Mar 28, 2022 at 12:28:04PM -0400, Michael Meissner wrote:
> > In looking at PR target/99293, I noticed that the insn "type" attribute is
> > incorrect for the vsx_extract_ insns. In particular:
> >
> > 1)
On Mon, Mar 28, 2022 at 03:28:39PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Mar 28, 2022 at 12:27:05PM -0400, Michael Meissner wrote:
> > In looking at PR target/99293, I noticed that the code in the insn
> > vsx_splat__reg used "vecmove" as the "type" insn attribute when the
> > "mtvsrd
On 08/03/2022 11:30, Hafiz Abid Qadeer wrote:
gcc/ChangeLog:
* omp-low.cc (omp_enable_pinned_mode): New function.
(execute_lower_omp): Call omp_enable_pinned_mode.
This worked for x86_64, but I needed to make the attached adjustment to
work on powerpc without a linker error.
When g++ emits
warning: overflow in conversion from 'int' to 'char' changes value from '300'
to '',''
for code like "char c = 300;" it might raise a few eyebrows. With this
warning we're not interested in the ASCII representation of the char, only
the numerical value, so convert constants of ty
Here deduction for the P/A pair V/a spuriously fails with
types ‘A’ and ‘const A’ have incompatible cv-qualifiers
because the argument type is const, whereas the parameter type is
non-const.
Since the type of an NTTP is always cv-unqualified, it seems natural to
ignore cv-qualifiers on the arg
Hi!
On 2012-05-13T11:03:36+, "Joseph S. Myers" wrote:
> On Sun, 13 May 2012, Manuel Lpez-Ibez wrote:
>> [an option is duplicated somewhere else]
>>
>> Only 2 options in Ada trigger this warning, and their help text has no
>> effect, since it gest overridden by the ones in c.opt. Fixing this
>
Dear all,
I committed the attached patch as obvious: we had a NULL pointer
dereference when checking the arguments of the ASSOCIATED intrinsic
when the target was an array-valued function.
Regtested on x86_64-pc-linux-gnu.
Thanks,
Harald
From b4e4b35f4ebe561826489bed971324efc99c5423 Mon Sep 17
Hi!
On 2012-05-13T11:04:36+0200, Manuel López-Ibáñez wrote:
> These warnings are invisible when building but they may help to detect
> if an option is duplicated somewhere else with different purpose , so
> it would be better to make this an error,
ACK.
> --- gcc/optc-gen.awk (revision 187427)
On 2022-03-30 15:18, Uros Bizjak wrote:
On Wed, Mar 30, 2022 at 7:15 PM Vladimir Makarov via Gcc-patches
wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032
The patch was successfully bootstrapped and tested on x86-64.
diff --git a/gcc/testsuite/gcc.target/
On Wed, Mar 30, 2022 at 7:15 PM Vladimir Makarov via Gcc-patches
wrote:
>
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032
>
> The patch was successfully bootstrapped and tested on x86-64.
diff --git a/gcc/testsuite/gcc.target/i386/pr105032.c
b/gcc/testsuite/gcc
On Fri, Jan 28, 2022 at 11:50:25AM -0600, Bill Schmidt wrote:
> As the subject states. Fixing this is accomplished by moving the built-ins
> to the correct stanzas, [altivec] and [vsx].
>
> Bootstrapped and tested on powerpc64le-linux-gnu with no regressions.
> Is this okay for trunk?
Okay for t
On Fri, 2022-01-28 at 11:50 -0600, Bill Schmidt via Gcc-patches wrote:
> PR104004 caught some misses on my part in converting to the new
> built-in
> function infrastructure. In particular, I forgot to mark all of the
> "nosoft"
> built-ins, and one of those should also have been marked "no32bit".
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032
The patch was successfully bootstrapped and tested on x86-64.
commit 25de4889c16fec80172a5e2d1825f3ff505d0cc4
Author: Vladimir N. Makarov
Date: Wed Mar 30 13:03:44 2022 -0400
[PR105032] LRA: modify loop conditi
On 23/03/2022 14:57, Richard Biener via Gcc-patches wrote:
The following extends the heuristical memcpy folding path with the
ability to use misaligned accesses on strict-alignment targets just
like the size-based path does. That avoids regressing the following
testcase on arm
uint64_t
On 30/03/2022 15:30, Sebastian Huber wrote:
On 30/03/2022 13:56, Martin Liška wrote:
Example:
base64 -d log.txt | gcov-tool merge-stream
The gcov-tool uses a new tag which contains the filename of the
associated gcov info file:
gcov-dump b-xilinx_zynq_a9_qemu/init.gcda
b-xilinx_zynq_a9_q
On Tue, Mar 29, 2022 at 10:21:47PM -0400, Jason Merrill wrote:
> 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,
Hi!
The testcase has UB at runtime, placement new shouldn't construct
an object with certain alignment requirements into an unaligned buffer.
Discussed on IRC, tested on x86_64-linux -m32/-m64, committed to trunk.
2022-03-30 Jakub Jelinek
PR tree-optimization/80334
PR target/
On Tue, Mar 29, 2022 at 10:19:47PM -0400, Jason Merrill wrote:
> 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.
> >
>
On 30/03/2022 13:56, Martin Liška wrote:
Example:
base64 -d log.txt | gcov-tool merge-stream
The gcov-tool uses a new tag which contains the filename of the
associated gcov info file:
gcov-dump b-xilinx_zynq_a9_qemu/init.gcda
b-xilinx_zynq_a9_qemu/init.gcda:data:magic `gcda':version `B20 '
b
On Mon, Mar 28, 2022 at 9:37 AM H.J. Lu wrote:
>
> PR target/105068
> * config/i386/sse.md (*ssse3_pshufbv8qi3): Also replace "Yv" with
> "Yw" in clobber.
> ---
> gcc/config/i386/sse.md | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/i38
> Benno, do you have write access?
>
> If not I can take care of this for you if you like?
I do not have write access, so that would be great. I've sent a new
version with added Changelog entries and your test to the list.
Do you think there's a chance to get this patch backported to gcc 10?
That
From: Benno Evers
When finishing a function that is a coroutine, the function is
transformed into a "ramp" function, and the original user-provided
function body gets moved into a newly created "actor" function.
In this case `current_function_decl` points to the ramp function,
but `current_bindi
On 3/30/22 08:56, Patrick Palka wrote:
On Tue, 29 Mar 2022, Jason Merrill wrote:
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 does
On Tue, 29 Mar 2022, Jason Merrill wrote:
> 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. Thi
On Tue, Mar 15, 2022 at 02:18:00PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Fri, Jan 28, 2022 at 11:50:26AM -0600, Bill Schmidt via Gcc-patches wrote:
> > PR104004 caught some misses on my part in converting to the new built-in
> > function infrastructure. In particular, I forgot to mark a
[ was: Re: [wwwdocs][patch] gcc-12/changes.html: Document -misa update
for nvptx ]
On 3/3/22 13:27, Tobias Burnus wrote:
The current wording, https://gcc.gnu.org/gcc-12/changes.html#nvptx ,
is outdated and (now wrongly) encourages to use -mptx=.
Updated as follows.
I've taken these changes a
Never mind, just spotted it.
:)
On 30/03/2022 13:10, Richard Earnshaw wrote:
Doesn't this need the anchor that the compiler links to?
#zero_width_bitfields
R.
On 30/03/2022 11:07, Jakub Jelinek via Gcc-patches wrote:
Hi!
This patch documents the PR102024 ABI changes.
The x86-64, ARM and
Doesn't this need the anchor that the compiler links to?
#zero_width_bitfields
R.
On 30/03/2022 11:07, Jakub Jelinek via Gcc-patches wrote:
Hi!
This patch documents the PR102024 ABI changes.
The x86-64, ARM and AArch64 backends refer to this in their -Wpsabi
diagnostics.
Ok for wwwdocs?
diff
On 3/28/22 18:23, Sebastian Huber wrote:
On 24/03/2022 13:03, Martin Liška wrote:
On 3/24/22 11:51, Sebastian Huber wrote:
Maybe we could add the file path into the gcov information stream using a new
tag:
#define GCOV_TAG_GCDA_FILE_NAME ((gcov_unsigned_t)0xa500)
Then the complete gcov
On 3/30/22 11:02, Tobias Burnus wrote:
On 30.03.22 10:03, Tom de Vries wrote:
On 3/29/22 16:47, Tobias Burnus wrote:
I think it would be useful to have additionally some wording for the
(new in GCC 12/new since today) macros,
[...]
The macro is defined also if the option is not specified, so
On Wed, Mar 30, 2022 at 01:00:43PM +0200, Richard Biener wrote:
> > --- a/htdocs/gcc-12/changes.html
> > +++ b/htdocs/gcc-12/changes.html
> > @@ -28,6 +28,31 @@ a work-in-progress.
> >
> > Caveats
> >
> > +
> > +An ABI incompatibility between C and
> > +C++ when passing or returning
On Wed, Mar 30, 2022 at 12:08 PM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> This patch documents the PR102024 ABI changes.
> The x86-64, ARM and AArch64 backends refer to this in their -Wpsabi
> diagnostics.
> Ok for wwwdocs?
>
> diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/change
Hi Iain,
I don't know if you really saw this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591844.html
It's Cc'ed to you in my outbox, but somehow the Cc: is missing in the
mail that arrived on gcc-patches ;-(
> This patch documents the Solaris-specific D bootstrap requirements.
>
Hi!
This patch documents the PR102024 ABI changes.
The x86-64, ARM and AArch64 backends refer to this in their -Wpsabi
diagnostics.
Ok for wwwdocs?
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 689feeba..dc0e4074 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gc
On Wed, Mar 30, 2022 at 11:52 AM Martin Jambor wrote:
>
> Hi,
>
> I did not backport my fix of PR 97456 to GCC 9 and it re-surfaced there
> as PR 105071. I have cherry-picked the fix, pasted below, on top of the
> gcc 9 branch (the only change is an extra bug reference in the
> ChangeLog) and mad
Hi,
I did not backport my fix of PR 97456 to GCC 9 and it re-surfaced there
as PR 105071. I have cherry-picked the fix, pasted below, on top of the
gcc 9 branch (the only change is an extra bug reference in the
ChangeLog) and made sure it passes bootstrap and testing on
x86_64-linux. Can I commi
On 30.03.22 10:03, Tom de Vries wrote:
On 3/29/22 16:47, Tobias Burnus wrote:
I think it would be useful to have additionally some wording for the
(new in GCC 12/new since today) macros,
[...]
The macro is defined also if the option is not specified, so I think
this formulation is not 100% cl
On Wed, 30 Mar 2022, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs, because for a volatile X & RESULT_DECL
> ubsan wants to take address of that reference. instrument_object_size
> is called with x, so the base is equal to the access and the var
> is automatic, so there is no risk o
Hi!
The following testcase ICEs, because for a volatile X & RESULT_DECL
ubsan wants to take address of that reference. instrument_object_size
is called with x, so the base is equal to the access and the var
is automatic, so there is no risk of an out of bounds access for it.
Normally we wouldn't
On Wed, 30 Mar 2022, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase on 64-bit targets, store-merging sees
> a MEM_REF store from {} ctor with "negative" bitsize where bitoff + bitsize
> wraps around to very small end offset. This later confuses the code
> so that it allocates just a fe
Hello.
I noticed the change that was backported to gcc-11 breaks LTO bytecode
due to the addition of the new parameter:
./lto1 -quiet -dumpbase ./a.wpa -mtune=generic -march=x86-64 -O2 -version
-fno-openmp -fno-openacc -fno-pie -fcf-protection=none
-fltrans-output-list=./a.ltrans.out -fwpa -fr
On 3/29/22 16:47, Tobias Burnus wrote:
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,
Agreed.
i.e. something like:
--- a/gcc/doc/inv
Hi!
On the following testcase on 64-bit targets, store-merging sees
a MEM_REF store from {} ctor with "negative" bitsize where bitoff + bitsize
wraps around to very small end offset. This later confuses the code
so that it allocates just a few bytes of memory but fills in huge amounts of
it. Lat
Hi!
cp_parser_omp_iterators does:
DECL_ARTIFICIAL (iter_var) = 1;
DECL_CONTEXT (iter_var) = current_function_decl;
pushdecl (iter_var);
on the newly created iterator vars, but when we instantiate templates
containing them, we just tsubst_decl them (which apparently for
automatic
On 3/29/22 16:28, Tobias Burnus wrote:
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.
Missin
57 matches
Mail list logo
