https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106873
--- Comment #6 from Kemal Akcam ---
(In reply to Jonathan Wakely from comment #5)
> Read https://en.cppreference.com/w/c/language/object#Alignment (for C) and
> https://en.cppreference.com/w/cpp/language/object#Alignment (for C++).
>
> Instead
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106904
--- Comment #3 from Zebediah Figura ---
>From the warning, it seems like it thinks I wrote
memcpy(>wp.hwnd, , sizeof(wp));
but that's not what I wrote.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106904
--- Comment #2 from Zebediah Figura ---
(In reply to Andrew Pinski from comment #1)
> The warning is correct for the reduced testcase as we warning that you are
> copying the wrong size for the field
The field ">wp" is of size 16 (4 ints),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106904
--- Comment #1 from Andrew Pinski ---
The warning is correct for the reduced testcase as we warning that you are
copying the wrong size for the field
Now I have not looked at the non reduced testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106904
Bug ID: 106904
Summary: Incorrect -Wstringop-overflow with partial memcpy()
into a nested structure
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity:
Snapshot gcc-13-20220911 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20220911/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106845
Tim Lange changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106845
--- Comment #5 from CVS Commits ---
The master branch has been updated by Tim Lange :
https://gcc.gnu.org/g:0ea5e3f4542832b8da016b152695e64a2a386309
commit r13-2582-g0ea5e3f4542832b8da016b152695e64a2a386309
Author: Tim Lange
Date: Sat Sep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96367
--- Comment #4 from Zebediah Figura ---
Forgot to mention:
leslie@terabithia:~/git/wine32$ gcc --version
gcc (Debian 12.2.0-1) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96367
Zebediah Figura changed:
What|Removed |Added
CC||zfigura at codeweavers dot com
---
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106750
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
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?
On Sun, Sep 11, 2022, 10:30 Junk Trash via Gcc wrote:
> Hi,
>
> I want to get the opinions of GCC developers regarding adding CMake as a
> build system for GCC. Is it something you would like, something you are
> neutral about, or something you are strongly against?
>
> Thanks for your valuable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106903
Bug ID: 106903
Summary: Incorrectly accepts call to function template when
deduced type doesn't match adjusted type
Product: gcc
Version: 13.0
Status: UNCONFIRMED
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 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
Brendan Dolan-Gavitt changed:
What|Removed |Added
CC||brendandg at nyu dot edu
---
在 2022-09-11 22:29, Junk Trash via Gcc 写道:
Hi,
I want to get the opinions of GCC developers regarding adding CMake as a build
system for GCC. Is it something you would like, something you are neutral
about, or something you are strongly against?
Thanks for your valuable feedback!
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
Hi,
I want to get the opinions of GCC developers regarding adding CMake as a build
system for GCC. Is it something you would like, something you are neutral
about, or something you are strongly against?
Thanks for your valuable feedback!
Regards,
JT
> ...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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753
Triffid Hunter changed:
What|Removed |Added
CC||triffid.hunter at gmail dot com
---
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 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
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)
> > > +{
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106901
--- Comment #5 from Carlos Galvez ---
I also would like to understand why the warning is not triggered if the first
"if (size < expected_size)" is removed.
https://godbolt.org/z/7vqPxhsqo
The possibility of executing the loop and do
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 ([1], 0, buf_size);
>> +
>> + return 0;
>>
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
31 matches
Mail list logo
