On Sun, 2022-09-11 at 00:19 +0200, Tim Lange wrote:
> Hi,
>
> see my patch below for a fix of pr106845. I decided to allow
> bit_ranges
> and byte_ranges to have a size of zero and rather only add an
> assertion
> to the functions that assume a non-zero size. That way is more
> elegant in
> the
On 11 September 2022 10:04:51 CEST, David Malcolm via Gcc-patches
wrote:
>> +++ b/gcc/testsuite/gcc.dg/analyzer/pr106845.c
>> @@ -0,0 +1,11 @@
>> +int buf_size;
>> +
>> +int
>> +main (void)
>> +{
>> + char buf[buf_size];
>> +
>> + __builtin_memset (&buf[1], 0, buf_size);
>> +
>> + return 0;
>
On Sun, 2022-09-11 at 10:21 +0200, Bernhard Reutner-Fischer wrote:
> On 11 September 2022 10:04:51 CEST, David Malcolm via Gcc-patches
> wrote:
>
> > > +++ b/gcc/testsuite/gcc.dg/analyzer/pr106845.c
> > > @@ -0,0 +1,11 @@
> > > +int buf_size;
> > > +
> > > +int
> > > +main (void)
> > > +{
> > > +
Le 10/09/2022 à 12:14, FX via Fortran a écrit :
If you have a solution for the standards checking, I’ll add it.
As a first step, one could check the use rename lists; what's done for
iso_fortran_env can be used as an example.
To diagnose the other usages, the check could be put in resolve_sym
Hi Mikael,
> As a first step, one could check the use rename lists; what's done for
> iso_fortran_env can be used as an example.
Yes, but iso_fortran_env is handled entirely in front-end, not through external
files.
This is what I plan to do when migrating the IEEE modules to front-end, but it
Le 11/09/2022 à 11:57, FX a écrit :
As a first step, one could check the use rename lists; what's done for
iso_fortran_env can be used as an example.
Yes, but iso_fortran_env is handled entirely in front-end, not through external
files.
That's true, but the standard check doesn't really dep
> ...it took me a moment to realize that the analyzer "sees" that this is
> "main", and thus buf_size is 0.
>
> Interestingly, if I rename it to not be "main" (and thus buf_size could
> be non-zero), we still don't complain:
> https://godbolt.org/z/PezfTo9Mz
> Presumably this is a known limitati
Hello,
diff --git a/gcc/testsuite/gcc.misc-tests/gcov.exp
b/gcc/testsuite/gcc.misc-tests/gcov.exp
index 82376d90ac2..a55ce234f6e 100644
--- a/gcc/testsuite/gcc.misc-tests/gcov.exp
+++ b/gcc/testsuite/gcc.misc-tests/gcov.exp
@@ -24,9 +24,9 @@ global GCC_UNDER_TEST
(...)
} else {
-set GC
Hi,
On 2022-09-11 16:34, Mikael Morin wrote:
Hello,
diff --git a/gcc/testsuite/gcc.misc-tests/gcov.exp
b/gcc/testsuite/gcc.misc-tests/gcov.exp
index 82376d90ac2..a55ce234f6e 100644
--- a/gcc/testsuite/gcc.misc-tests/gcov.exp
+++ b/gcc/testsuite/gcc.misc-tests/gcov.exp
@@ -24,9 +24,9 @@ global
Le 11/09/2022 à 18:04, Torbjorn SVENSSON a écrit :
Can you fix it for me and submit it or do you want me to send a v3?
For trivial things like this, there is no need for a v3 (nor was there
for a v2).
Do you miss a git write account and need someone to push for you?
This patch implements new target hook TARGET_CONSTANT_OK_FOR_CPROP_P in
order to exclude CONST_INTs that cannot fit into a MOVI machine instruction
from cprop.
gcc/ChangeLog:
* config/xtensa/xtensa.c (TARGET_CONSTANT_OK_FOR_CPROP_P):
New macro definition.
(xtensa_constant_
Hi,
Many RISC machines, as we know, have some restrictions on placing
register-width constants in the source of load-immediate machine instructions,
so the target must provide a solution for that in the machine description.
A naive way would be to solve it early, ie. to replace with read consta
This patch addresses PR rtl-optimization/106594, a significant performance
regression affecting aarch64 recently introduced (exposed) by one of my
recent RTL simplification improvements. Firstly many thanks to
Tamar Christina for confirming that the core of this patch provides ~5%
performance imp
13 matches
Mail list logo
