https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Bug 19987 depends on bug 94916, which changed state.
Bug 94916 Summary: Failure to optimize pattern into difference or zero selector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94916
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94916
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3507
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|rask at gcc dot
Thomas Koenig writes:
> C99, 6.7.2, "Type specifiers"
>
> # Constraints
>
> # At least one type specifier shall be given in the declaration
> # specifiers in each declaration, and in the specifier-qualifier
> # list in each struct declaration and type name.
And?
> In C99 and onwards, this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95408
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
On 13.05.23 02:45, Po Lu via Gcc wrote:
Gabriel Ravier writes:
...You're joking, right ? You can't possibly be seriously arguing
this, you have to be kidding... right ?
No, I'm not. The meaning of a variable declaration with only a storage
class specifier is extremely clear: the type of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #30 from Xi Ruoyao ---
https://reviews.llvm.org/D150505.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94893
--- Comment #3 from Andrew Pinski ---
Note we also don't optimize:
inline int sign1(int x)
{
return (x < 0 ? -1 : 0) | (x > 0 ? 1 : 0);
}
bool f1(int x)
{
return sign1(x) < 1;
}
To be just `x <= 0`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98710
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2021-04-26 00:00:00 |2023-5-12
--- Comment #2 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #34 from Miklos Karacsony ---
(In reply to Sergei Trofimovich from comment #32)
> Created attachment 55068 [details]
> gzip.c.c
>
> > > You should be able to extract preprocessed file using
> > > https://gcc.gnu.org/bugs/#need: you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #33 from Miklos Karacsony ---
Created attachment 55073
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55073=edit
gcc 12.3.1 preprocessed source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94911
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-05-13
Ever confirmed|0
It appears that GCC 13 has been released, but I am wondering if there
are any issues preventing this patch from being merged yet. Can you
provide any information on this?
On Sat, Apr 8, 2023 at 2:08 PM Ken Matsui wrote:
>
> I see. Thank you!
>
> On Sat, Apr 8, 2023 at 12:52 AM Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #29 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #28)
> (In reply to Alexander Monakov from comment #21)
> > (In reply to Xi Ruoyao from comment #18)
> > > Maybe. Should we send a patch?
> >
> > Yes, if we have a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #28 from Xi Ruoyao ---
(In reply to Alexander Monakov from comment #21)
> (In reply to Xi Ruoyao from comment #18)
> > Maybe. Should we send a patch?
>
> Yes, if we have a volunteer.
I'm creating it, but from the description of
Hmmm here is alternative approach for this:
diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index b8dc333f54e1..c88056024e7d 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -50,6 +50,21 @@ using namespace riscv_vector;
namespace riscv_vector {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
--- Comment #12 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:99488a6048745a7b999c22f46e5814d02ebf88d9
commit r14-804-g99488a6048745a7b999c22f46e5814d02ebf88d9
Author: Andrew Pinski
Date:
After r14-673-gc0dd80e4c4c3, there was a check in the match
patterns which was checking the type is unsigned but
instead of using the type, the patch used the expression.
This adds the needed TREE_TYPE so get the correct answer and don't ICE.
Committed as obvious after a bootstrap/test on
On Wed, May 10, 2023 at 2:58 AM Uros Bizjak wrote:
>
> On Fri, Apr 28, 2023 at 2:47 AM Fangrui Song wrote:
> >
> > When using -mcmodel=medium, large data is placed into .l* sections. GNU ld
> > places .l* sections into separate output sections. If small and medium
> > code model object files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109839
Bug ID: 109839
Summary: -Wanalyzer-fd-leak false positive with routine dup2
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
From: Juzhe-Zhong
This patch is optimizing the AVL for VLS auto-vectorzation.
Consider such case:
typedef int8_t vnx2qi __attribute__ ((vector_size (2)));
__attribute__ ((noipa)) void
f_vnx2qi (int8_t a, int8_t b, int8_t *out)
{
vnx2qi v = {a, b};
*(vnx2qi *) out = v;
}
Before this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #24 from Janez Zemva ---
I'll go libm shopping them, I know just the thing to try out first:
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/libs/libm/
> From: Hans-Peter Nilsson
> Date: Sat, 13 May 2023 02:56:39 +0200
>
> > From: "Roger Sayle"
> > Date: Fri, 12 May 2023 15:04:03 +0100
>
> > Hi H-P,
> > This patch should now already be on trunk:
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d8a6945c6ea22efa4d5e42fe1922d2
> > b27953c8cd
>
> From: "Roger Sayle"
> Date: Fri, 12 May 2023 15:04:03 +0100
> Hi H-P,
> This patch should now already be on trunk:
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d8a6945c6ea22efa4d5e42fe1922d2
> b27953c8cd
> Many thanks to Jeff for the review/approval.
> There have been no reported adverse
Gabriel Ravier writes:
> ...You're joking, right ? You can't possibly be seriously arguing
> this, you have to be kidding... right ?
No, I'm not. The meaning of a variable declaration with only a storage
class specifier is extremely clear: the type of the variable is `int'.
There's absolutely
Address comments.
V5 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618398.html
Thanks.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-05-13 00:16
To: juzhe.zhong
CC: gcc-patches; palmer; jeffreyalaw
Subject: Re: [PATCH V4] RISC-V: Using merge approach to optimize repeating
From: Juzhe-Zhong
1. Remove magic number of V4
2. Remove unnecessary gcc_assert
Consider this following case:
typedef int64_t vnx32di __attribute__ ((vector_size (256)));
__attribute__ ((noipa)) void
f_vnx32di (int64_t a, int64_t b, int64_t *out)
{
vnx32di v
= {a, b, a, b, a, b, a, b,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109825
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109838
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109825
Andrew Pinski changed:
What|Removed |Added
CC||slyfox at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109838
Bug ID: 109838
Summary: [14 Regression] ICE on libaom-3.6.0: in
ix86_widen_mult_cost, at config/i386/i386.cc:20444
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #23 from Jonathan Wakely ---
No, the built-in functions just call the functions defined in libm. GCC doesn't
implement them.
Look at the code for a call to __builtin_acosh:
https://godbolt.org/z/dPf46sKxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109824
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #22 from Janez Zemva ---
They are very sloppy, so I doubt even what they provide is working 100%. This
is why I suggested the generative approach. gcc has many built-in functions,
surely a rudimentary could be cobbled out of them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109824
Andrew Pinski changed:
What|Removed |Added
Summary|aligned attribute lost on |aligned attribute lost when
This patch adds the attribute `type` to most SVE1 instructions, as in the other
instructions.
--
Evandro Menezes
0002-aarch64-Add-SVE-instruction-types.patch
Description: Binary data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109837
Bug ID: 109837
Summary: [OpenMP] despite 'requires unified_address' there is
segfault when 'is_device_ptr' is not used
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109824
Stas Sergeev changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
>> What the magic 64 means?
uint64_t mask = 0;
64 = sizeof (uint64_t)
>> gcc_assert will removed at release mode, so it's not you want I guess?
You mean I need to remove it?
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-05-13 00:16
To: juzhe.zhong
CC: gcc-patches; palmer; jeffreyalaw
Snapshot gcc-12-20230512 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20230512/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109814
--- Comment #10 from Arsen Arsenović ---
(In reply to lesto fante from comment #9)
> To be fair I have no idea what would be the impact of removing freestanding,
> from a quick test does not seems to have a realistic impact.
>
> I guess what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-05-12
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
--- Comment #9 from Sam James ---
(In reply to Sam James from comment #8)
> Created attachment 55071 [details]
> graphite2-GlyphCache.cpp.ii (maybe related)
I guess this is really the same given the operations it's doing (its own
bswaps).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
--- Comment #8 from Sam James ---
Created attachment 55071
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55071=edit
graphite2-GlyphCache.cpp.ii (maybe related)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #21 from Jonathan Wakely ---
Oh, checking FLT_EVAL_METHOD doesn't work, because that's defined in
not . So another djgpp-specific "NO_FLOAT_TYPES" macro will be needed.
Sigh.
* Sam James:
> Florian Weimer writes:
>
>> * Sam James:
>>
>>> Florian Weimer writes:
>>>
[...]
In summary, all these seems to be good candidates for errors by default:
* int-conversion as errors (already raised separately
* -Wint-conversion for ?:
* parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #20 from Jonathan Wakely ---
Created attachment 55070
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55070=edit
Patch to make cmath configure tests more granular
Something like this might work, but it's horrible.
On Fri, 12 May 2023 at 19:05, Uros Bizjak wrote:
>
> On Fri, May 12, 2023 at 4:07 PM Ard Biesheuvel wrote:
>
> > > > > > Note that the GOT reference in question is in fact a data
> > > > > > reference: we
> > > > > > explicitly load the address of __fentry__ from the GOT, which
> > > > > >
Florian Weimer writes:
> * Sam James:
>
>> Florian Weimer writes:
>>
>>> [...]
>>> In summary, all these seems to be good candidates for errors by default:
>>>
>>> * int-conversion as errors (already raised separately
>>> * -Wint-conversion for ?:
>>> * parameter names in non-prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59905
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |4.9.0
* Sam James:
> Florian Weimer writes:
>
>> [...]
>> In summary, all these seems to be good candidates for errors by default:
>>
>> * int-conversion as errors (already raised separately
>> * -Wint-conversion for ?:
>> * parameter names in non-prototype function declarations
>> * the union wait
Florian Weimer writes:
> [...]
> In summary, all these seems to be good candidates for errors by default:
>
> * int-conversion as errors (already raised separately
> * -Wint-conversion for ?:
> * parameter names in non-prototype function declarations
> * the union wait function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #19 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #15)
> A proper fix would be to split up the configure test for USE_C99_MATH_TR1 to
> be more fine-grained, so that we use the subset of functions that are
>
Florian Weimer writes:
> * Jason Merrill:
>
>> On Fri, May 12, 2023 at 11:03 AM Florian Weimer wrote:
>>>
>>> * Joseph Myers:
>>>
>>> > On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote:
>>> >
>>> >> That is not the case we are discussing, AFAIU. Or at least no one has
>>> >> yet explained why
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109745
--- Comment #8 from Carlos Galvez ---
Thanks a lot for the quick fix!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109835
--- Comment #2 from Sam James ---
Okay, fair point, I gave examples but not *motivating* examples.
I have some non-harmless examples:
1.
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1e0e5c4d289004fa779c86da9319cf2bb18548b1
(a nasty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
--- Comment #7 from Andrew Pinski ---
Reduced further:
int split_subtables(char v)
{
return __builtin_popcount((int)__builtin_bswap16(v));
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
--- Comment #6 from Sam James ---
Created attachment 55069
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55069=edit
reduced.ii
I might reduce the graphite2 one for fun just to see how different it is but no
promises.
* Jason Merrill:
> On Fri, May 12, 2023 at 11:03 AM Florian Weimer wrote:
>>
>> * Joseph Myers:
>>
>> > On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote:
>> >
>> >> That is not the case we are discussing, AFAIU. Or at least no one has
>> >> yet explained why accepting those old K programs will
In the context of the recent discussion, it occurred to me that this semantic
would be useful, but currently there is no easy way to access it. Bikeshedding
welcome; the use of this flag is a bit odd, but it has the advantage of being
accepted without error going back at least to 4.3.
-- 8< --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
--- Comment #5 from Andrew Pinski ---
(In reply to Mikael Morin from comment #4)
> (In reply to Andrew Pinski from comment #2)
> > I am 99% sure it was introduced by r14-673-g5fdcfe3c5776
> >
> I think the correct link is r14-673-gc0dd80e4c4c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109654
Andrew Pinski changed:
What|Removed |Added
CC||stsp at users dot
sourceforge.net
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109824
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
* Joseph Myers:
> On Fri, 12 May 2023, Florian Weimer wrote:
>
>> This sone seems to be a good candidate for additional errors, though:
>>
>> warned_here = pedwarn
>> (loc, warn_return_type >= 0 ? OPT_Wreturn_type : 0,
>> "% with no value, in function returning non-void");
>>
>> It's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828
--- Comment #6 from Andrew Pinski ---
here is another example where we output a bogus `.zero` (though it does not
ICE):
struct s { int i; char c[]; };
const struct s *t = &(struct s) { .c = {'2','\0'}, };
We get:
.size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
--- Comment #21 from CVS Commits ---
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:96cc09dea48b562a0fc93d43fb3b702ac20b89fd
commit r14-802-g96cc09dea48b562a0fc93d43fb3b702ac20b89fd
Author: Jerry DeLisle
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
--- Comment #20 from CVS Commits ---
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:cf3b032b8fb681516ccacbe3689f1cad43a1773a
commit r14-801-gcf3b032b8fb681516ccacbe3689f1cad43a1773a
Author: Jerry DeLisle
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109577
Paul Eggert changed:
What|Removed |Added
CC||eggert at cs dot ucla.edu
--- Comment #1
I plan to commit the following as simple.
The issue was a value was being modified on a short namelist read. After
tthe first read gives the correct EOF, a second read would give the
error but modify the variable.
diff --git a/libgfortran/io/unit.c b/libgfortran/io/unit.c
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #32 from Sergei Trofimovich ---
Created attachment 55068
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55068=edit
gzip.c.c
> > You should be able to extract preprocessed file using
> > https://gcc.gnu.org/bugs/#need: you
Thank you, Richard. I went with your suggestion. New patch:
[PATCH] Disable warnings as errors for STAGEautofeedback.
Compilation during STAGEautofeedback produces additional warnings
since inlining decisions with -fauto-profile are different from
other builds.
This patches disables warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106168
Eric Botcazou changed:
What|Removed |Added
Status|REOPENED|SUSPENDED
--- Comment #5 from Eric
On Fri, May 12, 2023 at 11:03 AM Florian Weimer wrote:
>
> * Joseph Myers:
>
> > On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote:
> >
> >> That is not the case we are discussing, AFAIU. Or at least no one has
> >> yet explained why accepting those old K programs will adversely
> >> affect the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829
--- Comment #6 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #4)
> Or does match.pd try to invert all the COND_EXPR conditions and swap the
> operands?
match does not try but phiopt does in gimple_simplify_phiopt .
Or even
Hi Jakub,
do you recall how this snuck in? None of other other pages has had
<..." />
instead of
<...">
for a while. Not a biggie at all, just curious.
Pushed.
On a related note, the buildstat pages for GCC 9, 10, 11, 12, and 13
all are empty and I suggest to remove them. Any concerns?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109814
--- Comment #9 from lesto fante ---
To be fair I have no idea what would be the impact of removing freestanding,
from a quick test does not seems to have a realistic impact.
I guess what happen here is that the freestanding option should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829
--- Comment #5 from Jakub Jelinek ---
Or canonicalize COND_EXPRs such that only ne and not eq appears in condition
(and similarly to other comparisons)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472
--- Comment #26 from matoro ---
We also had somebody report on IRC that they observed this on powerpc (not sure
what tuple), again with -j1. It does not seem to show up with -j2, so likely
-j1 is necessary to trigger.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472
--- Comment #25 from matoro ---
Created attachment 55067
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55067=edit
build.log for gcc-13.1
This bug is still present on 13.1.0, attaching log
On Fri, 12 May 2023, Florian Weimer wrote:
> This sone seems to be a good candidate for additional errors, though:
>
> warned_here = pedwarn
> (loc, warn_return_type >= 0 ? OPT_Wreturn_type : 0,
> "% with no value, in function returning non-void");
>
> It's a clear type volation that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109788
--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #11)
> If you e.g. put breakpoint on the spot I changed and stopon the testcase
> with -Os when t == global_trees[TI_VOID_LIST_NODE] you can then see in
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109826
--- Comment #2 from Andrew Pinski ---
The warning is not even controlled by an option either so only -Werror turns it
into an error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829
--- Comment #3 from Andrew Pinski ---
Should add this one too:
(simplify
(cond (ne (SIGNBIT @0) zero_p@1) @0 (neg @0))
(neg (abs @0)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #27 from Andrew Pinski ---
(In reply to Alexander Monakov from comment #26)
> Would that help? GCC raises its own stack limit to 64MB:
>
> gcc.cc: stack_limit_increase (64 * 1024 * 1024);
> toplev.cc: stack_limit_increase (64 *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #26 from Alexander Monakov ---
Would that help? GCC raises its own stack limit to 64MB:
gcc.cc: stack_limit_increase (64 * 1024 * 1024);
toplev.cc: stack_limit_increase (64 * 1024 * 1024);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106168
Pascal Pignard changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
On 12 May 2023 14:45:14 CEST, Martin Jambor wrote:
>gcc/ChangeLog:
>
>2023-05-11 Martin Jambor
>
> PR ipa/108007
> * cgraph.h (cgraph_edge): Add a parameter to
> redirect_call_stmt_to_callee.
> * ipa-param-manipulation.h (ipa_param_adjustments): Added a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #25 from Andrew Pinski ---
(In reply to Alexander Monakov from comment #24)
> Appreciate the advice. So far I've managed to reduce the number of LTO
> inputs down to two files, RegisterBankInfo.cpp.o plus APInt.cpp.o. I also
> built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828
--- Comment #5 from Andrew Pinski ---
(In reply to Yann Droneaud from comment #4)
> I'm still playing with this, for example https://godbolt.org/z/dfjr8veh5,
> and I've noticed the size of the compound_initializer is incorrect too:
> Maybe it's
On 12 May 2023 08:49:53 CEST, Richard Biener via Gcc-patches
wrote:
>> gcc/ChangeLog:
>>
>> * combine.cc (struct reg_stat_type): Extended machine mode to 16 bits.
>> * cse.cc (struct qty_table_elem): Ditto.
>> (struct table_elt): Ditto.
>> (struct set): Ditto.
>> *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828
--- Comment #4 from Yann Droneaud ---
I'm still playing with this, for example https://godbolt.org/z/dfjr8veh5, and
I've noticed the size of the compound_initializer is incorrect too:
struct s { char i; char c[]; };
const struct s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #24 from Alexander Monakov ---
Appreciate the advice. So far I've managed to reduce the number of LTO inputs
down to two files, RegisterBankInfo.cpp.o plus APInt.cpp.o. I also built
gcc-12.3 with lineinfo and have a better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|C2x:static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087
Andrew Pinski changed:
What|Removed |Added
Status|REOPENED|NEW
Summary|Misleading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087
Andrew Pinski changed:
What|Removed |Added
CC||ideasman42 at gmail dot com
--- Comment
1 - 100 of 415 matches
Mail list logo
