On Tue, 2020-05-12 at 11:12 +0200, Sebastian Kürten wrote:
> Hi everybody,
>
> I'm trying to adapt an existing, open source GCC plugin so that it
> will
> work with more recent versions of GCC (it is currently working with
> 4.7
> only). During my research I came across your suggestion on the
>
On Tue, 12 May 2020, 21:57 Freddie Chopin, wrote:
>
> On Tue, 2020-05-12 at 12:07 +0100, Jonathan Wakely wrote:
> > You're talking about C++ exceptions in general, but the problems you
> > mention seems to be issues with specific implementation properties.
>
> Possibly true, but this argument -
On Sat, 9 May 2020, Eric Botcazou wrote:
> > Strangely, I failed to find any PR for e200, so maybe some unnoticed ones
> > are still lying around.
>
> I think that the e200 support was never contributed upstream.
Or rather, it wasn't accepted. Cf.
On Tue, 2020-05-12 at 12:07 +0100, Jonathan Wakely wrote:
> You're talking about C++ exceptions in general, but the problems you
> mention seems to be issues with specific implementation properties.
Possibly true, but this argument - that all the problems are related to
specific implementation
> Just echoing what David said really, but: if the libgcc changes
> are expected to be portable beyond glibc, then the existence of
> an alternative option for glibc shouldn't block the libgcc changes.
> The two approaches aren't be mutually exclusive and each approach
> would achieve something
On Tue, 12 May 2020 at 23:39, Jonathan Wakely wrote:
> On Tue, 12 May 2020, 21:57 Freddie Chopin, wrote:
> > Anyway... If you have to recompile the toolchain, the problem is still
> > there. Most of the people (like 99,666%) will not do that for various
> > reasons. Some don't know how, some use
> Some people use exceptions to propagate "low memory" up which
> made me increase the size of the EH emergency pool (which is
> used when malloc cannot even allocate the EH data itself) ...
>
> So yes, people care. There absolutely has to be a path in
> unwinding that allocates no (as little as
On Tue, 2020-05-12 at 09:20 +0200, Freddie Chopin wrote:
>
> I actually have to build my own toolchain instead of the one provided
> by ARM, because to really NOT use C++ exceptions, you have to recompile
> the whole libstdc++ with `-fno-exceptions -fno-rtti` (yes, I know they
> provide the
> Not all GCC/G++ targets are GNU/Linux and use GLIBC. A duplicate
> implementation in GLIBC creates its own set of advantages and
> disadvantages.
so what should I do now? Should I try to move the lookup into GLIBC? Or
handled it within libgcc, as I had originally proposed? Or give up due
to
On Mon, 2020-05-11 at 17:14 +0200, Moritz Strübe wrote:
> I just wanted to point out that Herbceptions do not only fix
> performance
> issues, but also code-size problems. While anything below 4GB of RAM
> is
> considered under-powered for a PC, typical deep embedded
> environments
> have
On Tue, May 12, 2020 at 2:44 PM 易会战 via Gcc wrote:
>
> hi, I am working on gcc ssa name. For each function, we can traverse all
> defined ssa name by macro FOR_EACH_SSA_NAME. If a ssa name is default
> definition for a symbol (check SSA_NAME_IS_DEFAULT_DEF) , I can get the
> symbol by
I'm also CCing gcc-patches and fortran ML.
Martin
On 5/12/20 11:05 AM, Martin Liška wrote:
Hi.
Thanks to Jakub, we finally set up an experimental environment:
gcc.gnu.org/home/gccadmin/gcc-reposurgeon-8.git
The repository now contains a new pre-commit hook that validates
the git commit
On Tue, 2020-05-12 at 11:16 +0200, Florian Weimer wrote:
> That can only happen if the embedded people do not bother to show up
> in
> numbers. Of course the tools will move in different directions.
True (;
> > That's why the proposal by Herb is a real surprise and I really
> > hope
> > it
Am 12.05.2020 um 11:44 schrieb Freddie Chopin:
Would you use it if switching from -fno-exceptions to this new
approach
resulted in an immediate 20% code size increase, without actually
using
the new error handling feature at all? What about 10%?
I don't think that it will be that much. I
thanks a lot. I will check your advice.
Can you give some explaination about memory ssa, and how to use it. I check
internal, cannot get it. Maybe you know some examples or some more materials.
---Original---
From: "Richard Biener"
Hi.
Thanks to Jakub, we finally set up an experimental environment:
gcc.gnu.org/home/gccadmin/gcc-reposurgeon-8.git
The repository now contains a new pre-commit hook that validates
the git commit format ([1]) and provides a reasonable error message
when violated. The hook is based on [2] and
On Tue, 12 May 2020 at 09:17, Freddie Chopin wrote:
> The problem with C++ exceptions is that even in the most
> trivial of the programs and even if you don't explicitly
> use/catch/throw them, they instantly eat around 60 kB of ROM and quite
> a lot of RAM. With some hacking you can get down to
* Moritz Strübe:
> Hey.
>
> Am 11.05.2020 um 15:59 schrieb Thomas Neumann via Gcc:
>> In a way I am disagreeing with the paper, of course, in that I propose
>> to make the existing exception mechanism faster instead of inventing a
>> new exception mechanism. But what I agree on with P0709 is that
Thomas Neumann via Gcc writes:
>> Not all GCC/G++ targets are GNU/Linux and use GLIBC. A duplicate
>> implementation in GLIBC creates its own set of advantages and
>> disadvantages.
>
> so what should I do now? Should I try to move the lookup into GLIBC? Or
> handled it within libgcc, as I had
On Tue, 12 May 2020 at 11:48, Freddie Chopin wrote:
> To summarize. Current C++ exceptions have very huge, mostly "one-time"
> kind, cost on the size, even if not used at all by the user, mosly due
> to std::terminate() and all the string handling code inside it, as well
> as the unwind tables.
hi, I am working on gcc ssa name. For each function, we can traverse all
defined ssa name by macro FOR_EACH_SSA_NAME. If a ssa name is default
definition for a symbol (check SSA_NAME_IS_DEFAULT_DEF) , I can get the symbol
by SSA_NAME_VAR. But for a virtual DEFAULT DEF, I cannot get it,
* Freddie Chopin:
> Very nice that Moritz finally mentioned it (; The world of deep
> embedded is usually forgotten by all the language committees and people
> who are in charge.
That can only happen if the embedded people do not bother to show up in
numbers. Of course the tools will move in
Hi everybody,
I'm trying to adapt an existing, open source GCC plugin so that it will
work with more recent versions of GCC (it is currently working with 4.7
only). During my research I came across your suggestion on the Wiki[1]
to get in touch if one has any questions concerning developing
On Tue, May 12, 2020 at 11:05:58AM +0200, Martin Liška wrote:
> Thanks to Jakub, we finally set up an experimental environment:
> gcc.gnu.org/home/gccadmin/gcc-reposurgeon-8.git
>
> The repository now contains a new pre-commit hook that validates
> the git commit format ([1]) and provides a
* Moritz Strübe:
>> Would you use it if switching from -fno-exceptions to this new
>> approach resulted in an immediate 20% code size increase, without
>> actually using the new error handling feature at all? What about
>> 10%?
>
> I don't think that it will be that much.
Why? Have you
Before the sourcware upgrade, it was possible to incrementally copy the
mailing list archives using rsync. This is still advertised on
https://gcc.gnu.org/rsync.html
but this only includes the pre-upgrade archives.
Would it be possible to provide this feature for the current archives,
Hey.
Am 12.05.2020 um 13:29 schrieb Florian Weimer:
Would you use it if switching from -fno-exceptions to this new
approach resulted in an immediate 20% code size increase, without
actually using the new error handling feature at all? What about
10%?
I don't think that it will be that much.
On Tue, May 12, 2020 at 4:16 PM 易会战 wrote:
>
> thanks a lot. I will check your advice.
> Can you give some explaination about memory ssa, and how to use it. I check
> internal, cannot get it. Maybe you know some examples or some more materials.
memory SSA in GCC is simply a SSA chain of all
Hi -
> Would it be possible to provide this feature for the current archives,
> too? [...]
rsync now makes available the master .mbox files for every mailing
list hosted on sourceware:
rsync gcc.gnu.org::gcc-mbox
This includes historical ezmlm era files as well as the new.
- FChE
Hi Frank,
>> Would it be possible to provide this feature for the current archives,
>> too? [...]
>
> rsync now makes available the master .mbox files for every mailing
> list hosted on sourceware:
>
>rsync gcc.gnu.org::gcc-mbox
>
> This includes historical ezmlm era files as well as the
On Tue, May 12, 2020 at 8:14 AM Thomas Neumann via Gcc wrote:
>
> > Not all GCC/G++ targets are GNU/Linux and use GLIBC. A duplicate
> > implementation in GLIBC creates its own set of advantages and
> > disadvantages.
>
> so what should I do now? Should I try to move the lookup into GLIBC? Or
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95094
Bug ID: 95094
Summary: alignof(reference_to_type) doesn't return
alignof(referenced_type) as it ought to, by the
standard
Product: gcc
Version: 11.0
-fsplit-dwarf is similar to -gsplit-dwarf, but does not enable debugging
information by itself. This makes it easier to be plugged into a build
system without worrying that unnecessary debugging information may be
generated.
2020-05-12 Fangrui Song
PR debug/95096
* common.opt:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95096
Bug ID: 95096
Summary: Feature request: add -fsplit-dwarf
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
This fixes a bug reported to the RISC-V sw-dev mailing list late last year.
https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/JV5Jdh4UjVw
Keith Packard wote the obvious patch to fix it. I tested it with cross builds
for riscv32-newlib and riscv64-linux. There were no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95013
--- Comment #7 from CVS Commits ---
The master branch has been updated by Nathan Sidwell :
https://gcc.gnu.org/g:2a0225e47868fbfceaecaa5e2de96c1c5a2251ea
commit r11-338-g2a0225e47868fbfceaecaa5e2de96c1c5a2251ea
Author: Nathan Sidwell
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095
Bug ID: 95095
Summary: Feature request: support -fno-unique-section-names
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12411
Rafael Avila de Espindola changed:
What|Removed |Added
CC||rafael at espindo dot la
On Sun, Apr 12, 2020 at 7:54 PM Kito Cheng wrote:
> On Sat, Apr 11, 2020 at 1:48 AM Jim Wilson wrote:
> > Do we really need this now? It is a new feature not a bug fix, so it
> > might be better to wait until we reach stage1. We have limited time
> > to test this before the gcc-10 release.
>
>
On Tue, May 12, 2020 at 2:24 PM Nathan Sidwell wrote:
>
> My recent C++ parser change to pay attention to EOF location uncovered a
> separate bug. The preprocesor's EOF logic would set the EOF location to
> be the beginning of the last line of text in the file -- not the 'line'
> after that,
Hi.
On 05/11, Richard Biener wrote:
> On Fri, May 8, 2020 at 7:11 PM Jeff Law via Gcc-patches
> wrote:
> >
> > On Fri, 2020-05-08 at 13:06 -0300, Giuliano Belinassi via Gcc-patches wrote:
> > > Hi,
> > >
> > > This patch Refactors tree-vrp.c to eliminate all global variables except
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95094
--- Comment #2 from Jonathan Wakely ---
But this doesn't seem like a very useful behaviour for the extension.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95094
--- Comment #3 from Inbal Levi ---
Actually, you are right,
I'm currently working on a paper to change it, should have waited for
afterward.
The reason to change it is to align (...) with C behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95078
--- Comment #2 from Hongtao.liu ---
(In reply to Richard Biener from comment #1)
> TER should go away, not be extended. So you are suggesting that we replace
>
> leaq44(%rdi,%rdx,4), %rdx --- redundant could be fwprop
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95097
Bug ID: 95097
Summary: Missed optimization with bitfield value ranges
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94118
--- Comment #5 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:0fec3f62b9bfc03e5088a09036791c2ac84fe0c8
commit r11-344-g0fec3f62b9bfc03e5088a09036791c2ac84fe0c8
Author: liuhongt
Date: Fri May 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93983
gcc-bugs at marehr dot dialup.fu-berlin.de changed:
What|Removed |Added
CC||gcc-bugs at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #25 from Jiu Fu Guo ---
(In reply to Richard Biener from comment #23)
> (In reply to Richard Biener from comment #20)
> > (In reply to Jiu Fu Guo from comment #18)
> > > Currently, I'm thinking to enhance GCC 'cunroll' as:
> > > if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #26 from Jiu Fu Guo ---
(In reply to Richard Biener from comment #20)
> (In reply to Jiu Fu Guo from comment #18)
> > Currently, I'm thinking to enhance GCC 'cunroll' as:
> > if the loop has multi-exits or upbound is not a fixed
My recent C++ parser change to pay attention to EOF location uncovered a
separate bug. The preprocesor's EOF logic would set the EOF location to
be the beginning of the last line of text in the file -- not the 'line'
after that, which contains no characters. Mostly. This fixes things so
The C/C++ bindings generated by means of -fdump-ada-spec always contain with
and use clauses for Interfaces.C, but they can be unused in some cases so make
sure to avoid warning about that.
Tested on x86-64/Linux, applied on the mainline.
2020-05-12 Eric Botcazou
c-family/
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95013
Nathan Sidwell changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
On Mon, Apr 27, 2020 at 10:08 AM Craig Blackmore
wrote:
> Thanks for the review. I have updated the following patch with those changes.
This looks good, and the tree is open for development work again, so I
committed both parts 1 and 2 and pushed it.
One weird thing is that while the patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95094
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95093
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94118
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |11.0
Status|NEW
This makes sure that gigi is prepared to handle more aggregates in the special
memset code path.
Tested on x86-64/Linux, applied on the mainline.
2020-05-12 Eric Botcazou
* sem_aggr.ads (Is_Single_Aggregate): New function.
* sem_aggr.adb (Is_Others_Aggregate): Use local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93983
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95096
--- Comment #1 from Fangrui Song ---
Created https://sourceware.org/pipermail/gcc-patches/2020-May/545638.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95023
--- Comment #2 from Ye Luo ---
I got the following error when building the new lib. Tried gcc 8 and 10 with
master and newlib-3.3.0. No difference
/home/yeluo/opt/build-amdgcn-gcc/./gcc/xgcc
-B/home/yeluo/opt/build-amdgcn-gcc/./gcc/ -nostdinc
On Tue, May 12, 2020 at 9:04 AM Martin Liška wrote:
>
> On 5/11/20 2:44 PM, Richard Biener wrote:
> > Hmm, I think the fix is to clear DECL_NOT_GIMPLE_REG_P instead
> > where the code clears TREE_ADDRESSABLE of 'arg'
>
> Ah, you are right. There's a patch that I've just tested.
>
> Patch can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95077
Bug ID: 95077
Summary: Wrong backtrace infromation at O1
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95063
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:99b0c9ec47d563d1f780cb678c04d37c9835440f
commit r11-314-g99b0c9ec47d563d1f780cb678c04d37c9835440f
Author: Jakub Jelinek
Date:
Hi!
The r11-15 change broke this testcase, as it now asserts type is equal to
the type of the DECL_VALUE_EXPR, but for DECL_OMP_PRIVATIZED_MEMBER artificial
vars mapping to bitfields it wasn't. Fixed by changing the
DECL_OMP_PRIVATIZED_MEMBER var type in that case.
Bootstrapped/regtested on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94980
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95045
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:bb63ca63e744c08bc5a9ffa53df62ea35f098b0b
commit r11-308-gbb63ca63e744c08bc5a9ffa53df62ea35f098b0b
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95067
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2020-05-12
Summary|[10/11
On Fri, May 08, 2020 at 11:48:34AM -0400, Nathan Sidwell wrote:
> 2020-05-08 Nathan Sidwell
>
> gcc/cp/
> * parser.c (cp_lexer_set_source_position_from_token): EOF has a
> location too.
This change:
> --- c/gcc/cp/parser.c
> +++ w/gcc/cp/parser.c
> @@ -895,10 +895,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95075
Bug ID: 95075
Summary: gcc/d/dmd/dscope.c: 2 * strange assignments ?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95076
Bug ID: 95076
Summary: Failure to optimize out stack alignment on function
call of different type
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12345
--- Comment #10 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=a62236b9d579315a0482cdd6deb409f76381c233
commit r10-5848-ga62236b9d579315a0482cdd6deb409f76381c233
Author:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93223
--- Comment #6 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=8a37df5e5cb2de8302f9412173103593ec53961e
commit r10-5852-g8a37df5e5cb2de8302f9412173103593ec53961e
Author:
On Mai 11 2020, Jason Merrill via Gcc-patches wrote:
> If a program has no other dependencies on libstdc++, we shouldn't require it
> just for __cxa_pure_virtual, which is only there to give a prettier
> diagnostic before crashing the program; resolving the reference to NULL will
> also crash,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95068
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
Minor refine of checking iterations nonoverflow and a testcase for stage 1.
This "subtract/extend/add" existed for a long time and still annoying us
(PR37451, part of PR61837) when converting from 32bits to 64bits, as the ctr
register is used as 64bits on powerpc64, Andraw Pinski had a patch but
Hi!
This attempts to implement what the OpenMP 5.0 spec in declare target section
says as ammended by the 5.1 changes so far (related to device_type(host)),
except
that it doesn't have the device(ancestor: ...) handling yet because we do not
support it yet, and I've left so far out the except
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93223
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #7
Hi Jakub,
> On Fri, May 08, 2020 at 11:48:34AM -0400, Nathan Sidwell wrote:
>> 2020-05-08 Nathan Sidwell
>>
>> gcc/cp/
>> * parser.c (cp_lexer_set_source_position_from_token): EOF has a
>> location too.
>
> This change:
>
>> --- c/gcc/cp/parser.c
>> +++ w/gcc/cp/parser.c
>> @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93244
--- Comment #14 from Martin Liška ---
(In reply to CVS Commits from comment #13)
> The master branch has been updated by Martin Liska :
>
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;
> h=af213b4c4ca30e55de64f8b1e0bf442df08f3e6d
>
> commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95033
--- Comment #2 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:6b41920bd5c68998a53de749b4fe5c0b8875db6c
commit r11-315-g6b41920bd5c68998a53de749b4fe5c0b8875db6c
Author: Martin Liska
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95051
--- Comment #5 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:6b41920bd5c68998a53de749b4fe5c0b8875db6c
commit r11-315-g6b41920bd5c68998a53de749b4fe5c0b8875db6c
Author: Martin Liska
Date: Tue
On Mon, 11 May 2020, Joseph Myers wrote:
> On Fri, 8 May 2020, Richard Biener wrote:
>
> > The IFNs are supposed to match fmin and fmax from the C standard which
> > IIRC have IEEE semantics.
>
> fmin and fmax have IEEE (2008) semantics (where an sNaN operand results in
> a qNaN result with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95073
--- Comment #1 from Jonathan Wakely ---
This part is still useful, to show the one that *was* found, but couldn't be
called:
q.C:9:15: note: declared here
9 | extern void f();
| ^
If that is replaced then it's not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #18 from Jiu Fu Guo ---
Currently, I'm thinking to enhance GCC 'cunroll' as:
if the loop has multi-exits or upbound is not a fixed number, we may not do
'complete unroll' for the loop, except -funroll-all-loops is specified.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95045
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
Bug 57359 depends on bug 95045, which changed state.
Bug 95045 Summary: [11 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95045
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93244
--- Comment #13 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=af213b4c4ca30e55de64f8b1e0bf442df08f3e6d
commit r10-5851-gaf213b4c4ca30e55de64f8b1e0bf442df08f3e6d
Author:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95033
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95051
Bug 95051 depends on bug 95033, which changed state.
Bug 95033 Summary: [11 Regression] ICE in set_parm_rtl, at cfgexpand.c:1310
since r11-165-geb72dc663e9070b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95033
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95051
Martin Liška changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84766
--- Comment #1 from Jonathan Wakely ---
I don't think we want to use another TLS entry just for this handler, so I'm
leaning towards the nice suggestion to say "reentrant" instead.
On Tue, May 12, 2020 at 7:57 AM Richard Biener wrote:
>
> On Mon, 11 May 2020, Uros Bizjak wrote:
>
> > Attached patch implements V2SFmode FMA insn patterns. Patched compiler
> > vectorizes FMA, FMS and FNMA instructions, but for some reason fails
> > to vectorize FNMS.
> >
> > I have double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #19 from Richard Biener ---
Is libgfortran built with -O2 -funroll-loops or with -O3 (IIRC -O3?). Note we
see
Estimating sizes for loop 3
BB: 14, after_exit: 0
size: 1 _20 = count[n_95];
size: 1 _21 = _20 + 1;
size: 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94980
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:d17a896da1e898928d337596d029f0ece0039d55
commit r11-311-gd17a896da1e898928d337596d029f0ece0039d55
Author: Richard Sandiford
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94980
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:14605b6bd8c37fffd8065c5c3fe6b1b9d7b2a294
commit r11-312-g14605b6bd8c37fffd8065c5c3fe6b1b9d7b2a294
Author: Richard Sandiford
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94980
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:4c0283b9ad75b128b79c507d78d678123fe9f471
commit r11-313-g4c0283b9ad75b128b79c507d78d678123fe9f471
Author: Richard Sandiford
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95073
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
Since we apply SM to an edge which exits multiple loops we have
to make sure to commit insertions on it immediately since otherwise
store order is not preserved.
The testcase was committed with yesterdays fix, the bug was still
latent (with careful -fdbgcnt=lim you could still trigger it).
On 5/11/20 2:44 PM, Richard Biener wrote:
Hmm, I think the fix is to clear DECL_NOT_GIMPLE_REG_P instead
where the code clears TREE_ADDRESSABLE of 'arg'
Ah, you are right. There's a patch that I've just tested.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95067
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.4
--- Comment #2 from Richard Biener
1 - 100 of 259 matches
Mail list logo
