On Fri, Dec 2, 2022 at 7:37 AM Alexandre Oliva via Gcc-patches
wrote:
>
> On Dec 1, 2022, Jason Merrill wrote:
>
> > Once we see g*, starred is set. Then we see %:, and it sees that as a
> > zero-length switch, which because starred is still set, matches any and all
> > command-line options.
On Fri, Dec 2, 2022 at 8:43 AM Richard Biener
wrote:
>
> On Fri, Dec 2, 2022 at 1:23 AM Zopolis0 wrote:
> >
> > > But that looks like the correct thing to do.
> >
> > It's not. The patch I reverted changes it so that no matter what,
> > void_list_node = build_tree_list (NULL_TREE,
On Fri, Dec 2, 2022 at 1:23 AM Zopolis0 wrote:
>
> > But that looks like the correct thing to do.
>
> It's not. The patch I reverted changes it so that no matter what,
> void_list_node = build_tree_list (NULL_TREE, void_type_node);.
>
> Before, each front-end set it in their own way, but they all
I tried turning -Wnarrowing back on earlier this year, but
unfortunately it didn't work due to triggering a bunch of new errors.
This patch silences at least some of them, but there will still be
more left even after applying it. (When compiling with clang,
technically the warning flag is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
--- Comment #7 from rguenther at suse dot de ---
On Thu, 1 Dec 2022, me at xenu dot pl wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
>
> --- Comment #5 from Tomasz Konojacki ---
> To sum this thread up, there are undocumented
Hi,
The following test:
#include "arm_sve.h"
svint8_t
test_s8(int8_t *x)
{
return svld1rq_s8 (svptrue_b8 (), [0]);
}
ICE's with -march=armv8.2-a+sve -O1 -fno-tree-ccp -fno-tree-forwprop:
during GIMPLE pass: fre
pr107920.c: In function ‘test_s8’:
pr107920.c:7:1: internal compiler error: in
On Fri, 2 Dec 2022, Richard Biener wrote:
> On Thu, 1 Dec 2022, Siddhesh Poyarekar wrote:
>
> > On 2022-12-01 11:42, Kees Cook wrote:
> > > On Wed, Nov 30, 2022 at 02:25:56PM +, Qing Zhao wrote:
> > >> '-Wstrict-flex-arrays'
> > >> Warn about inproper usages of flexible array members
On Thu, 1 Dec 2022, Siddhesh Poyarekar wrote:
> On 2022-12-01 11:42, Kees Cook wrote:
> > On Wed, Nov 30, 2022 at 02:25:56PM +, Qing Zhao wrote:
> >> '-Wstrict-flex-arrays'
> >> Warn about inproper usages of flexible array members according to
> >> the LEVEL of the
On Thu, 1 Dec 2022, Tamar Christina wrote:
> > > +/* Check to see if the supplied comparison in PTEST can be performed as a
> > > + bit-test-and-branch instead. VAL must contain the original tree
> > > + expression of the non-zero operand which will be used to rewrite the
> > > +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107946
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:5b50850c3c6f2eceb8012dcc8d3cd5ddd94fac6c
commit r13-4458-g5b50850c3c6f2eceb8012dcc8d3cd5ddd94fac6c
Author: Richard Biener
Date:
Hi,
For scalar extract/insert instructions, exponent field can be stored in a
32-bit register. So this patch changes the mode of exponent field from DI to
SI so that these instructions can be generated in a 32-bit environment. Also
it removes TARGET_64BIT check for these instructions.
The
The following adds a --param to limit the depth of unswitched loop
nests. One can use --param max-unswitch-depth=1 to disable unswitching
of outer loops (the innermost loop will then be unswitched).
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/107946
On Fri, Dec 2, 2022 at 5:26 AM liuhongt wrote:
>
> After supporting extendbfsf2_1, ix86_expand_fast_convert_bf_to_sf can
> be improved with pslld either.
> CONST_INT_P is not handled since constant shift can be optimized off.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for
On Dec 1, 2022, Jason Merrill wrote:
> Once we see g*, starred is set. Then we see %:, and it sees that as a
> zero-length switch, which because starred is still set, matches any and all
> command-line options. So targets that use such a spec accept all options in
> the driver, while ones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43301
--- Comment #8 from Eric Gallager ---
(In reply to Eric Gallager from comment #7)
>
> Alexandre Oliva's assessment is that the issue was just one having an old
> build left over, and that all the patch did was to force a rebuild:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447
Eric Gallager changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On Fri, Dec 2, 2022 at 12:30 AM Sandra Loosemore
wrote:
>
> On 12/1/22 20:29, Eric Gallager via Gcc-patches wrote:
> > A pretty simple patch; borrowed from Andrew Pinski on bugzilla:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447
> > Tested by doing `./configure --help` in the gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447
--- Comment #11 from CVS Commits ---
The master branch has been updated by Eric Gallager :
https://gcc.gnu.org/g:a710f3ce7474792c098ac6fe4dc6a366cdbb4fb4
commit r13-4457-ga710f3ce7474792c098ac6fe4dc6a366cdbb4fb4
Author: Eric Gallager
Date:
Hi Nilsson,
在 2022/12/2 10:49, Hans-Peter Nilsson 写道:
> On Wed, 23 Nov 2022, HAO CHEN GUI via Gcc-patches wrote:
>
>> diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
>> index 92bda1a7e14..9823eccbe68 100644
>> --- a/gcc/doc/tm.texi
>> +++ b/gcc/doc/tm.texi
>> @@ -7094,6 +7094,15 @@ the
On 12/1/22 20:29, Eric Gallager via Gcc-patches wrote:
A pretty simple patch; borrowed from Andrew Pinski on bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447
Tested by doing `./configure --help` in the gcc subdirectory and
noting that the "(or later)" made it into the output. OK for
After supporting extendbfsf2_1, ix86_expand_fast_convert_bf_to_sf can
be improved with pslld either.
CONST_INT_P is not handled since constant shift can be optimized off.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
* config/i386/i386-expand.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84471
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107504
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447
Eric Gallager changed:
What|Removed |Added
Keywords||patch
URL|
A pretty simple patch; borrowed from Andrew Pinski on bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447
Tested by doing `./configure --help` in the gcc subdirectory and
noting that the "(or later)" made it into the output. OK for trunk?
gcc/ChangeLog:
PR bootstrap/59447
*
On Wed, 23 Nov 2022, HAO CHEN GUI via Gcc-patches wrote:
> diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
> index 92bda1a7e14..9823eccbe68 100644
> --- a/gcc/doc/tm.texi
> +++ b/gcc/doc/tm.texi
> @@ -7094,6 +7094,15 @@ the @code{POLY_VALUE_MIN}, @code{POLY_VALUE_MAX} and
> implementation returns
Hi,
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600475.html
BR,
Jeff(Jiufu)
Jiufu Guo via Gcc-patches writes:
> Hi,
>
> Gentle ping this:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600475.html
>
> BR,
> Jeff (Jiufu)
>
>
> Jiufu Guo via Gcc-patches writes:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107948
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-4456-g0b737090a69624.
gcc/analyzer/ChangeLog:
PR analyzer/107948
* region-model-manager.cc
(region_model_manager::maybe_fold_binop): Fold (0 - VAL) to -VAL.
* region-model.cc
Tested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-4455-g5cb7d28dcfb11a.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/string-ops-concat-pair.c: New test.
* gcc.dg/analyzer/string-ops-dup.c: New test.
Signed-off-by: David Malcolm
---
.../gcc.dg/analyzer/string-ops-concat-pair.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107948
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:0b737090a69624dea5318c380620283f0321a92e
commit r13-4456-g0b737090a69624dea5318c380620283f0321a92e
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413
--- Comment #19 from Rama Malladi ---
(In reply to Wilco from comment #17)
> (In reply to Rama Malladi from comment #16)
> > (In reply to Wilco from comment #15)
> > > (In reply to Rama Malladi from comment #14)
> > > > This fix also improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107934
--- Comment #5 from Hongtao.liu ---
Fixed in GCC13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107934
--- Comment #4 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:e055e6db974d8b8950b30859a853e0aee74e20c2
commit r13-4454-ge055e6db974d8b8950b30859a853e0aee74e20c2
Author: liuhongt
Date: Thu Dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #53 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107539
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107539
--- Comment #6 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:a4e577b044d69977f93b2cb7769dc991eadf2cf0
commit r13-4453-ga4e577b044d69977f93b2cb7769dc991eadf2cf0
Author: Patrick Palka
Date:
On 02/12/2022 00:05, Martin Liška wrote:
> On 11/11/22 06:21, Jørgen Kvalsvik wrote:
>> From: Jørgen Kvalsvik
>>
>> This patch adds support in gcc+gcov for modified condition/decision
>> coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a type of
>> test/code coverage and it is
-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk/configure --prefix=/home/jerry/dev/usr
--enable-languages=c,c++,fortran --enable-libgomp --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221201 (experimental) (GCC
> the "all in one go" approach that you seem to have attempted (?)
I did do all the patches in one go onto master, but for rebases and
bisects I did apply them on various baselines. See
https://github.com/Zopolis4/gcj-branches, where all the branches
labellled newplan/year-month-day will have
In response to the testing thing, one critical issue is that these
patches aren't entirely functional (see the second point of my
original message), so I can't test yet. I'll check once I can though.
> But that looks like the correct thing to do.
It's not. The patch I reverted changes it so that no matter what,
void_list_node = build_tree_list (NULL_TREE, void_type_node);.
Before, each front-end set it in their own way, but they all set it
via void_list_node = build_tree_list (NULL_TREE,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
--- Comment #13 from Jerry DeLisle ---
A debug session gives:
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
futex_wait (private=0, expected=2, futex_word=0x405950) at
../sysdeps/nptl/futex-internal.h:146
146 int err =
On 2022-12-01 18:19, Kees Cook wrote:
On Thu, Dec 01, 2022 at 10:27:41PM +, Qing Zhao wrote:
Hi, Sid,
Thanks a lot for the input.
After more thinking based on your and Kees’ comments, I have the following
thought:
1. -fstrict-flex-arrays=level should control both GCC code gen and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
---
On Thu, Dec 01, 2022 at 10:27:41PM +, Qing Zhao wrote:
> Hi, Sid,
>
> Thanks a lot for the input.
>
> After more thinking based on your and Kees’ comments, I have the following
> thought:
>
> 1. -fstrict-flex-arrays=level should control both GCC code gen and warnings
> consistently;
> 2.
Snapshot gcc-10-20221201 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20221201/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106773
--- Comment #12 from James Hilliard ---
(In reply to James Hilliard from comment #10)
> (In reply to David Faust from comment #9)
> > Created attachment 54002 [details]
> > updated patch
> >
> > Update the 'extern' variable marking, and also
Hi, Sid,
Thanks a lot for the input.
After more thinking based on your and Kees’ comments, I have the following
thought:
1. -fstrict-flex-arrays=level should control both GCC code gen and warnings
consistently;
2. We need warnings specifically for -fstrict-flex-arrays=level to report any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
--- Comment #11 from anlauf at gcc dot gnu.org ---
And this is the output I'm getting on stdout:
tstuff
fstuff
T
tstuff
fstuff
F
tstuff
fstuff
T
tstuff
fstuff
F
tstuff
T
tstuff
F
fstuff
T
fstuff
F
Can you compare your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106773
--- Comment #11 from James Hilliard ---
Also hitting this one in cgroup_hierarchical_stats.c:
$ /home/buildroot/bpf-next/tools/testing/selftests/bpf/tools/sbin/bpftool
--debug gen skeleton
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106773
--- Comment #10 from James Hilliard ---
(In reply to David Faust from comment #9)
> Created attachment 54002 [details]
> updated patch
>
> Update the 'extern' variable marking, and also mark 'extern' funcs.
That fixes the issue in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106773
David Faust changed:
What|Removed |Added
Attachment #53993|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
--- Comment #9 from Jerry DeLisle ---
I am seeing timeout failures with merge_1.f90. Can you look into this?
Thanks,
Jerry
On Thu, Dec 1, 2022, 12:28 PM anlauf at gcc dot gnu.org via Gcc-bugs <
gcc-bugs@gcc.gnu.org> wrote:
>
On 12/1/22 15:57, Patrick Palka wrote:
Here the two BOUND_TEMPLATE_TEMPLATE_PARMs written as C end
up having the same TYPE_CANONICAL since the ctp_table (which interns the
canonical form of a template type parameter) doesn't set the
comparing_specializations flag which controls how PARM_DECLs
On 12/1/22 14:51, Patrick Palka wrote:
On Thu, 1 Dec 2022, Jason Merrill wrote:
On 12/1/22 11:37, Patrick Palka wrote:
When defining a explicit specialization of a constrained member template
(of a class template) such as f and g in the below testcase, the
DECL_TEMPLATE_PARMS of the
On Fri, 2 Dec 2022, Longjun Luo via Gcc-patches wrote:
> They are ./gcc/testsuite/gcc.dg/cpp/warn-redefined.c and
> ./gcc/testsuite/gcc.dg/cpp/warn-redefined-2.c
>
> These two cases redefine the __TIME__ macro when using the option
> '-Wbuiltin-macro-redefined'.
>
> I think I shoud add a test
Here the two BOUND_TEMPLATE_TEMPLATE_PARMs written as C end
up having the same TYPE_CANONICAL since the ctp_table (which interns the
canonical form of a template type parameter) doesn't set the
comparing_specializations flag which controls how PARM_DECLs from
different DECL_CONTEXTs compare equal.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |13.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107922
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Dear all,
we did not properly handle the case of insufficient array-valued
FIELD when trying to simplify UNPACK and could run into a NULL
pointer dereference. The fix is obvious.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 0ff50e73c6fce52263b9530daffe6743c1fc9b2c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104160
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79083
Andrew Pinski changed:
What|Removed |Added
CC||stephan.oostveen@nextlevel-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107945
Andrew Pinski changed:
What|Removed |Added
Summary|static incomplete |static constexpr incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107945
--- Comment #2 from Andrew Pinski ---
ICC has the same behavior as GCC, though I don't know if it was EDG marking
this as an extension or not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107945
--- Comment #1 from Andrew Pinski ---
Reduced:
```
struct incomplete;
template struct C
{
static constexpr T t{};
};
int main() {
C t;
// t.t;
}
```
If we uncomment t.t, then GCC will reject it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447
Eric Gallager changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107940
--- Comment #7 from Andrew Pinski ---
(In reply to laurent.alfo...@linaro.org from comment #0)
> sanitizer=address reports an issue while stack unwinding :
>
> ==13419==ERROR: AddressSanitizer: SEGV on unknown address 0x
> (pc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
On 12/2/2022 3:07 AM, Joseph Myers wrote:
On Fri, 2 Dec 2022, Longjun Luo via Gcc-patches wrote:
On 12/2/2022 1:01 AM, Joseph Myers wrote:
On Thu, 1 Dec 2022, Longjun Luo via Gcc-patches wrote:
diff --git a/gcc/testsuite/gcc.dg/builtin-redefine.c
b/gcc/testsuite/gcc.dg/builtin-redefine.c
On Thu, 1 Dec 2022, Jason Merrill wrote:
> On 12/1/22 11:37, Patrick Palka wrote:
> > When defining a explicit specialization of a constrained member template
> > (of a class template) such as f and g in the below testcase, the
> > DECL_TEMPLATE_PARMS of the corresponding TEMPLATE_DECL are
On 2022-12-01 11:42, Kees Cook wrote:
On Wed, Nov 30, 2022 at 02:25:56PM +, Qing Zhao wrote:
'-Wstrict-flex-arrays'
Warn about inproper usages of flexible array members according to
the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to
the trailing array field
On 12/1/22 11:37, Patrick Palka wrote:
When defining a explicit specialization of a constrained member template
(of a class template) such as f and g in the below testcase, the
DECL_TEMPLATE_PARMS of the corresponding TEMPLATE_DECL are partially
instantiated, whereas its associated constraints
On Fri, 2 Dec 2022, Longjun Luo via Gcc-patches wrote:
>
> On 12/2/2022 1:01 AM, Joseph Myers wrote:
> > On Thu, 1 Dec 2022, Longjun Luo via Gcc-patches wrote:
> >
> > > diff --git a/gcc/testsuite/gcc.dg/builtin-redefine.c
> > > b/gcc/testsuite/gcc.dg/builtin-redefine.c
> > > index
On Thu, 1 Dec 2022, Joshi, Tejas Sanjay wrote:
> I have addressed all your comments in this revised patch, PFA and inlined
> below.
Thank you. Honza, please let me know if any further input is needed
from my side. For reference, here's how insn-automata.o table sizes
look with this patch (top
Richard,
Can you submit this patch for me while I sort out git write access?
On 11/18/22 07:57, Richard Biener wrote:
On Fri, Nov 11, 2022 at 3:28 AM Michael Collison wrote:
This patches transforms ((x & 0x1) == 0) ? y : z y -into
(-(typeof(y))(x & 0x1) & z) y, where op is a '^' or a '|'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107929
--- Comment #5 from cqwrteur ---
1. the real gap is much larger due to larger preprocessor space.
2. that is just an excuse. the mm_ intrinsic is implemented with builtin
functions on gcc and clang. You can always avoid include that header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107947
--- Comment #5 from eggert at cs dot ucla.edu ---
Thanks for reporting the conformance bug in TZDB. I fixed it in the TZDB
development repository here:
https://github.com/eggert/tz/commit/9cfe9507fcc22cd4a0c4da486ea1c7f0de6b075f
and the fix
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Monday, November 14, 2022 9:59 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>> ; Marcus Shawcroft
>> ; Kyrylo Tkachov
>> Subject: Re: [PATCH 2/2]AArch64 Perform more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107515
--- Comment #9 from Stam Markianos-Wright ---
> Clearly Helium+Linux on Godbolt is a bit confused
Yea, I agree -- it still shouldn't be an unintuitive front-end type clash
error, though!
I've posted another patch:
On 12/2/2022 1:01 AM, Joseph Myers wrote:
On Thu, 1 Dec 2022, Longjun Luo via Gcc-patches wrote:
diff --git a/gcc/testsuite/gcc.dg/builtin-redefine.c
b/gcc/testsuite/gcc.dg/builtin-redefine.c
index 882b2210992..9d5b42252ee 100644
--- a/gcc/testsuite/gcc.dg/builtin-redefine.c
+++
On 12/1/22 05:32, Jakub Jelinek wrote:
On Wed, Nov 30, 2022 at 01:52:08PM -0500, Jason Merrill wrote:
It looks like we're already deducing the type for the underlying S variable
in cp_convert_omp_range_for, we just aren't updating the types of the
individual bindings.
You're right. With this
Hi all,
With these previous patches:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606586.html
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606587.html
we enabled the MVE overloaded _Generic associations to handle more
scalar types, however at PR 107515 we found a new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107920
prathamesh3492 at gcc dot gnu.org changed:
What|Removed |Added
Attachment #53992|0 |1
is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
--- Comment #6 from Jakub Jelinek ---
If you use always_inline attribute and therefore want an error if some function
isn't inlined, to be precise. Otherwise it just wouldn't be inlined...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
--- Comment #5 from Tomasz Konojacki ---
To sum this thread up, there are undocumented rules that can cause a
semantically identical program to be rejected by the compiler under certain
optimisation levels (with an uninformative error message)
On 01/12/2022 16:12, Richard Sandiford wrote:
> Alex Coplan via Gcc-patches writes:
> > Hi,
> >
> > This patch fixes a type confusion bug in varasm.cc:assemble_variable.
> > The problem is that the current code calls:
> >
> > sect = get_variable_section (decl, false);
> >
> > and then accesses
Richard,
What’s your opinion on this?
Do we need one separate warning option to report the misuse of flexible array
member only?
Or we just combine such warnings into -Warray-bounds when it combines with
-fstrict-flex-arrays?
Thanks.
Qing
> On Dec 1, 2022, at 12:18 PM, Kees Cook wrote:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
--- Comment #9 from Jakub Jelinek ---
Wasn't this discussed in the past in other PRs? Whether uninitialized vars
mean anything or anything but same value each time a SSA_NAME initialized to it
is used?
Because as this testcase shows, not all
On Thu, Dec 01, 2022 at 05:04:02PM +, Qing Zhao wrote:
>
>
> > On Dec 1, 2022, at 11:42 AM, Kees Cook wrote:
> >
> > On Wed, Nov 30, 2022 at 02:25:56PM +, Qing Zhao wrote:
> >> '-Wstrict-flex-arrays'
> >> Warn about inproper usages of flexible array members according to
> >>
Hey,
On Thu, 1 Dec 2022, James K. Lowden wrote:
> > E.g. look in gcc.cc for '@c' (matching the file extension) how that
> > entry uses '%(cpp_unique_options)', and how cpp_unique_options is
> > defined for the specs language:
> >
> > INIT_STATIC_SPEC ("cpp_unique_options",
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106773
--- Comment #8 from David Faust ---
(In reply to James Hilliard from comment #5)
> (In reply to David Faust from comment #4)
> > Created attachment 53993 [details]
> > proposed patch
> >
> > Should fix the remaining issues with 'extern'
> On Dec 1, 2022, at 11:42 AM, Kees Cook wrote:
>
> On Wed, Nov 30, 2022 at 02:25:56PM +, Qing Zhao wrote:
>> '-Wstrict-flex-arrays'
>> Warn about inproper usages of flexible array members according to
>> the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to
>> the
On Thu, 1 Dec 2022, Longjun Luo via Gcc-patches wrote:
> diff --git a/gcc/testsuite/gcc.dg/builtin-redefine.c
> b/gcc/testsuite/gcc.dg/builtin-redefine.c
> index 882b2210992..9d5b42252ee 100644
> --- a/gcc/testsuite/gcc.dg/builtin-redefine.c
> +++ b/gcc/testsuite/gcc.dg/builtin-redefine.c
> @@
On Thu, 2022-12-01 at 10:33 -0500, Antoni Boucher wrote:
> On Thu, 2022-12-01 at 10:25 -0500, David Malcolm wrote:
> > On Thu, 2022-12-01 at 10:01 -0500, Antoni Boucher wrote:
> > > Thanks, David.
> > > Since we're not in phase 1 anymore, do we need an approval before
> > > I
> > > merge like last
A recent change only initializes the regs.how[] during Dwarf unwinding
which resulted in an uninitialized offset used in return address signing
and random failures during unwinding. The fix is to use REG_SAVED_OFFSET
as the state where the return address signing bit is valid, and if the
state is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
--- Comment #8 from Jakub Jelinek ---
I think this is CCP's fault rather than VRP.
Everything I've looked at in the vrp2 dump looks right to me.
In the outer loop, h/i is
# RANGE [irange] int [0, 3] NONZERO 0x3
# h_41 = PHI
# i_44 = PHI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107678
Wilco changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org
--- Comment #6
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
Under the old logic for validate_switches, once suffix or starred got set,
they stayed set for all later switches found in the spec. So for e.g.
%{g*:%{%:debug-level-gt(0):
Once we see g*, starred is set. Then we see %:, and it sees that as
1 - 100 of 219 matches
Mail list logo
