Hi!
As mentioned in the PR, x == 0 can be equivalently tested as x < 1U
and the latter form has the advantage that it sets the carry flag and if it
is consumed by an instruction that can directly use the carry flag, it is a
win.
The following patch adds a couple of (pre-reload only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86575
--- Comment #8 from Eric Gallager ---
(In reply to Michael Matz from comment #7)
> As I stated, it's only fixed in trunk, so it's still a regression in 7 and 8,
> as marked in the summary.
But you also said you weren't planning on backporting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91593
--- Comment #8 from Eric Gallager ---
(In reply to Jerry DeLisle from comment #7)
> Author: jvdelisle
> Date: Wed Oct 2 02:35:14 2019
> New Revision: 276439
>
> URL: https://gcc.gnu.org/viewcvs?rev=276439=gcc=rev
> Log:
> 2019-10-01 Jerry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60591
--- Comment #5 from Eric Gallager ---
(In reply to Eric Gallager from comment #2)
> There are several other bugs open like this one, such as bug 78736
This is fixed now. It's probably still worth checking some of the other bugs
under its "See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52763
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78736
Eric Gallager changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
Bug 87403 depends on bug 78736, which changed state.
Bug 78736 Summary: enum warnings in GCC (request for -Wenum-conversion to be
added)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78736
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7654
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77404
Eric Gallager changed:
What|Removed |Added
CC||mikestump at comcast dot net
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82240
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
On Oct 16, 2019, Luis Machado wrote:
> It seems, from reading the blog post about SFN's, that it was meant to
> help with debugging optimized binaries.
Indeed. Getting rid of the dummy jumps would be one kind of
optimization, and then SFN might help preserve some of the loss of
location info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86518
--- Comment #12 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to Eric Gallager from comment #10)
> > If this is becoming the meta-bug for all warnings that affect codegen, then
> > I'd like to add bug 61579
On 10/18/19 1:54 AM, JeanHeyd Meneide wrote:
... And I am very tired and forgot to attach the patch. Again. Sorry...!
On Fri, Oct 18, 2019 at 1:54 AM JeanHeyd Meneide
wrote:
Dear Jason,
On Thu, Oct 17, 2019 at 3:51 PM Jason Merrill wrote:
> FAIL: g++.dg/cpp0x/gen-attrs-67.C -std=c++11
Hello, Jason,
On Oct 14, 2019, Jason Merrill wrote:
> Alex, you had a lot of helpful comments when I first wrote this, any thoughts
> on this revision?
I think the check of the pid file could be made slightly simpler and
cheaper if we created it using:
echo $$ > $lockdir/pidT && mv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #42 from Eric Gallager ---
(In reply to Rich Felker from comment #41)
> > Josef Wolf mentioned that he ran into this on the gcc-help mailing list
> > here: https://gcc.gnu.org/ml/gcc-help/2019-10/msg00079.html
>
> I don't think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540
Oleg Endo changed:
What|Removed |Added
Target|sh*-*-* |
--- Comment #12 from Oleg Endo ---
(In
On 10/18/19 4:27 PM, Martin Sebor wrote:
> The optimization to fold (strcmp() == 0) results involving
> arrays/strings of unequal size/length has a bug where it is
> unprepared for the compute_string_length() function to return
> an invalid length as an indication that the length is unknown.
>
Snapshot gcc-8-20191018 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/8-20191018/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92157
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
Bug 83819 depends on bug 92157, which changed state.
Bug 92157 Summary: [10 Regression] incorrect strcmp() == 0 result for unknown
strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92157
What|Removed |Added
The optimization to fold (strcmp() == 0) results involving
arrays/strings of unequal size/length has a bug where it is
unprepared for the compute_string_length() function to return
an invalid length as an indication that the length is unknown.
This leads to some strings that are unequal being
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92155
--- Comment #4 from Martin Sebor ---
Author: msebor
Date: Fri Oct 18 22:26:39 2019
New Revision: 277194
URL: https://gcc.gnu.org/viewcvs?rev=277194=gcc=rev
Log:
PR tree-optimization/92157 - incorrect strcmp() == 0 result for unknown strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92157
--- Comment #2 from Martin Sebor ---
Author: msebor
Date: Fri Oct 18 22:26:39 2019
New Revision: 277194
URL: https://gcc.gnu.org/viewcvs?rev=277194=gcc=rev
Log:
PR tree-optimization/92157 - incorrect strcmp() == 0 result for unknown strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #25 from Jakub Jelinek ---
The define_insn part of define_insn_and_split needs constraints if it is meant
to match during or after reload, the patterns are just written with the
assumption that they are split before reload. At least
Hi Richard,
Sorry for not adding the test in PR91532 fix.
Is the attached patch OK to commit ?
Thanks,
Prathamesh
2019-10-18 Prathamesh Kulkarni
PR tree-optimization/91532
testsuite/
* gcc.target/aarch64/sve/fmla_2.c: Add dg-scan check for deleted store.
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #24 from Segher Boessenkool ---
A dumb question I'm sure, but I don't see it: if the rest of your
define_insn doesn't need constraints, why would the match_scratch
need some? (A define_split never uses constraints).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92155
--- Comment #3 from Martin Sebor ---
Actually, the memcpy is transformed to MEM_REF and the strlen pass knows how to
deal with a subset of those (small powers of 2). What it doesn't know how to
do yet is deal with other sizes like in the test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92155
--- Comment #2 from Martin Sebor ---
The inequality (__builtin_strlen (a4) != 0) is folded into (a4[0] != 0) very
early on during Gimplification so the strlen pass never sees it.
What the strlen pass should be able to do is fold strlen(a4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92155
prathamesh3492 at gcc dot gnu.org changed:
What|Removed |Added
CC||prathamesh3492 at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92157
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92157
Bug ID: 92157
Summary: incorrect strcmp() == 0 result for unknown strings
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
This is the first step of early splitting all the DImode comparison
operations. We start by factoring the DImode handling out of
arm_gen_compare_reg into its own function.
Simple DImode equality comparisions (such as equality with zero, or
equality with a constant that is zero in one of the two
In thumb2 we now generate a NEGS instruction rather than RSBS, so this
test needs updating.
* gcc.target/arm/negdi-3.c: Update expected output to allow NEGS.
---
gcc/testsuite/gcc.target/arm/negdi-3.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Now that we early split DImode subtracts, the patterns to emit the
original and to match zero-extend with subtraction or negation are
no-longer useful.
* config/arm/arm.md (arm_subdi3): Delete insn.
(zextendsidi_negsi, negdi_extendsidi): Delete insn_and_split.
---
Similar to the improvements for uaddvsi4, this patch improves the code
generation for addvsi4 to handle immediates and to add alternatives
that better target thumb2. To do this we separate out the expansion
of uaddvsi4 from that of uaddvdi4 and then add an additional pattern
to handle constants.
This patch adds early splitting of subdi3 so that the individual
operations can be seen by the optimizers, particuarly combine. This
should allow us to do at least as good a job as previously, but with
far fewer patterns in the machine description.
This is just the initial patch to add the
The uaddv patterns in the arm back-end do not currenty handle immediates
during expansion. This patch adds this support for uaddvsi4. It's really
a stepping-stone towards early expansion of uaddvdi4, but it complete and
a useful change in its own right.
Whilst making this change I also
Now that all the major patterns for DImode have been converted to
early expansion, we can safely clean up some dead code for the old way
of handling DImode.
* config/arm/arm-modes.def (CC_NCV, CC_CZ): Delete CC modes.
* config/arm/arm.c (arm_select_cc_mode): Remove old selection
This patch matches the signed add-with-overflow patterns when the
summation itself is dropped. In this case we can use CMN (or CMP with
some immediates). There are a small number of constants in thumb2
where this can result in less dense code (as we lack 16-bit CMN with
immediate patterns). To
This code borrows strongly on the uaddvti4 expansion for aarch64 since
the principles are similar. Firstly, if the one of the low words of
the expansion is 0, we can simply copy the other low word to the
destination and use uaddvsi4 for the upper word. If that doesn't work
we have to handle
The generic expansion code for negv does not try the subv patterns,
but instead emits a sub and a compare separately. Fortunately, the
patterns can make use of the new subv operations, so just call those.
We can also rewrite this using an iterator to simplify things further.
Finally, we can now
The add-with-carry operation which involves a shift doesn't match at present
because it isn't matching the canonical form generated by combine. Fixing
this is simply a matter of re-ordering the operands.
* config/arm/arm.md (addsi3_carryin_shift_): Reorder operands
to match
In almost all cases it is better to handle inequality handling against constants
by transforming comparisons of the form (reg const) into
(reg (const+1)). However, there are many cases that we could
handle but currently failed to do so because we forced the constant into a
register too early
This patch addresses constant handling in subvsi4. Either operand may
be a constant. If the second input (operand[2]) is a constant, then
we can canonicalize this into an addition form, providing we take care
of the INT_MIN case. In that case the negation has to handle the fact
that -INT_MIN
addsi3_carryin_alt2 has a more strict constraint than the predicate
when adding a constant. This leads to sub-optimal code in some
circumstances.
* config/arm/arm.md (addsi3_carryin_alt2): Use arm_not_operand for
operand 2.
---
gcc/config/arm/arm.md | 2 +-
1 file changed, 1
In a small number of cases it is preferable to handle comparisons with
constants using the sequence
RSBStmp, Xlo, constlo
RSCStmp, Xhi, consthi
which allows us to handle a small number of LE/GT/LEU/GEU cases when
changing the code to use LT/GE/LTU/GEU would make the
An earlier patch introduced arm_borrow_operation, this one introduces
the carry variant, which is the same except that the logic of the
carry-setting is inverted. Having done this we can now match more
cases where the carry flag is propagated from comparisons with
different modes without having
The cost routine for Arm and Thumb2 was not recognising the idioms that
describe the addition with carry, this results in the instructions
appearing more expensive than they really are, which occasionally can lead
to poor choices by combine. Recognising all the possible variants is
a little
Consider this sequence during combine:
Trying 18, 7 -> 22:
18: r118:SI=r122:SI
REG_DEAD r122:SI
7: r114:SI=0x1-r118:SI-ltu(cc:CC_RSB,0)
REG_DEAD r118:SI
REG_DEAD cc:CC_RSB
22: r1:SI=r114:SI
REG_DEAD r114:SI
Failed to match this instruction:
(set (reg:SI 1 r1 [+4
This patch adds a couple of alternative canonicalizations to allow
combine to match a subtract-with-carry operation when one of the operands
is shifted first. The most common case of this is when combining a
sign-extend of one operand with a long-long value during subtraction.
The RSC variant is
This patch adds early expansion of subvdi4. The expansion sequence
is broadly based on the expansion of usubvdi4.
* config/arm/arm.md (subvdi4): Decompose calculation into 32-bit
operations.
(subdi3_compare1): Delete pattern.
(subvsi3_borrow): New insn pattern.
This patch adds early splitting for addvdi4; it's very similar to the
uaddvdi4 splitter, but the details are just different enough in
places, especially for the patterns that match the splitting, where we
have to compare against the non-widened version to detect if overflow
occurred.
I've also
When the carry flag is appropriately set by a comprison, negscc
patterns can expand into a simple SBC of a register with itself. This
means we can convert two conditional instructions into a single
non-conditional instruction. Furthermore, in Thumb2 we can avoid the
need for an IT instruction
The rtx_cost calculations when a borrow operation was being performed were
not being calculated correctly. The borrow is free as part of the
subtract-with-carry instructions. This patch recognizes the various
idioms that can describe this and returns the correct costs.
*
This patch adds early expansion of usubvdi4, allowing us to handle some
constants in place, which previously we were unable to do.
* config/arm/arm.md (usubvdi4): Allow registers or integers for
incoming operands. Early split the calculation into SImode
operations.
This patch improves the expansion of usubvsi4 by allowing suitable
constants to be passed directly. Unlike normal subtraction, either
operand may be a constant (and indeed I have seen cases where both can
be with LTO enabled). One interesting testcase that improves as a
result of this is:
This patch does most of the work for early splitting the DImode
comparisons. We now handle EQ, NE, LT, GE, LTU and GEU during early
expansion, in addition to EQ and NE, for which the expansion has now
been reworked to use a standard conditional-compare pattern already in
the back-end.
To handle
This patch changes the insn patterns for zero- and sign-extend into
define_expands that generate the appropriate word operations
immediately.
* config/arm/arm.md (zero_extenddi2): Convert to define_expand.
(extenddi2): Likewise.
---
gcc/config/arm/arm.md | 75
The first step towards early splitting of addition and subtraction at
DImode is to rip out the old patterns that are designed to propagate
DImode through the RTL optimization passes and the do late splitting.
This patch does cause some code size regressions, but it should still
execute
This patch causes the expansion of adddi3 to split the operation
immediately for Arm and Thumb-2. This is desirable as it frees up the
register allocator to pick what ever combination of registers suits
best and reduces the number of auxiliary patterns that we need in the
back-end. Three of the
This series of patches rewrites all the DImode arithmetic patterns for
the Arm backend when compiling for Arm or Thumb2 to split the
operations during expand (the thumb1 code is unchanged and cannot
benefit from early splitting as we are unable to expose the carry
flag).
This has a number of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #23 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #22)
> Hrm, I don't see how this is nicer than just adding a scratch in the
> pattern? What makes that a worse option?
Most of the patterns don't have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92156
Bug ID: 92156
Summary: Cannot in-place construct std::any with std::any
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
On Fri, Oct 18, 2019 at 05:17:38PM +0100, Iain Sandoe wrote:
>
> something like this, perhaps (I regret my Fortran skills are in the f77 era):
>
If you know/knew F77 and have some working knowledge of C/C++ and
you want to see where modern Fortran sits, I recommend Modern Fortran
Explained iby
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #22 from Segher Boessenkool ---
Hrm, I don't see how this is nicer than just adding a scratch in the
pattern? What makes that a worse option?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92155
Bug ID: 92155
Summary: strlen(a) not folded after memset(a, 0, sizeof a)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91929
Dmitry G. Dyachenko changed:
What|Removed |Added
CC||dimhen at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69455
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69455
--- Comment #19 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Oct 18 19:26:22 2019
New Revision: 277193
URL: https://gcc.gnu.org/viewcvs?rev=277193=gcc=rev
Log:
2019-10-18 Steven G. Kargl
PR fortran/69455
*
The following C code:
unsigned int wrong(unsigned int n){
return (n%2) ? 0 : 42;
}
should return 42 when n is odd and 0 when n is even.
But ARM gcc 8.2 with -O3 produces following assembly:
tst r0, #1
moveq r0, #42
movne r0, #0
bx lr
tst r0,#1 sets Z=1 iff r0 is even, and moveq r0,#42 executes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92056
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540
--- Comment #11 from Harald van Dijk ---
(In reply to Rich Felker from comment #10)
> On this particular target, and on every target of any modern
> relevance, (float)16777217 has well-defined behavior.
That was exactly the point of my original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540
--- Comment #10 from Rich Felker ---
GCC can choose the behavior for any undefined behavior it wants, and GCC
absolutely can make transformations based on behaviors it guarantees or that
Annex F guarantees on targets for which it implements the
The only reason I wanted `float complex` was for interoperability
between the two other demanglers. Although the go demangler
does use `_Complex` and `_Imaginary`, so I guess it's sort of split.
But I agree, `_Complex` and `_Imaginary` is probably the
better option.
Thanks,
Miguel Saldivar
On
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540
--- Comment #9 from Harald van Dijk ---
(In reply to Rich Felker from comment #8)
> So arguments about generality to non-Annex-F C
> environments are not relevant to the topic here.
The comment it was a reply to suggested (possibly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69455
--- Comment #18 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Oct 18 18:18:34 2019
New Revision: 277161
URL: https://gcc.gnu.org/viewcvs?rev=277161=gcc=rev
Log:
2019-10-18 Steven G. Kargl
PR fortran/69455
*
I will deal with this and various other issues associated with
ISO_Fortran_binding tomorrow.
Thanks for your help
Paul
On Thu, 17 Oct 2019 at 18:30, Tobias Burnus wrote:
>
> Hi,
>
> + fprintf (stderr, "CFI_setpointer: Result is NULL.\n");
> …
> > + return CFI_INVALID_DESCRIPTOR;
> > +! {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540
--- Comment #8 from Rich Felker ---
> Floating point types are not guaranteed to support infinity by the C standard
Annex F (IEEE 754 alignment) does guarantee it, and GCC aims to implement this.
This issue report is specific to target sh*-*-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540
--- Comment #7 from Harald van Dijk ---
(In reply to Rich Felker from comment #6)
> > Only if the int is out of float's range.
>
> float's range is [-INF,INF] (endpoints included). There is no such thing as
> "out of float's range".
Floating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69455
--- Comment #17 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Oct 18 17:59:32 2019
New Revision: 277160
URL: https://gcc.gnu.org/viewcvs?rev=277160=gcc=rev
Log:
2019-10-18 Steven G. Kargl
PR fortran/69455
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69455
--- Comment #16 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Oct 18 17:27:06 2019
New Revision: 277158
URL: https://gcc.gnu.org/viewcvs?rev=277158=gcc=rev
Log:
2019-10-18 Steven G. Kargl
PR fortran/69455
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92149
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92153
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
A kind reminder.
Sent from my iPhone
> On Oct 6, 2019, at 01:01, Sami Ait Ali Oulahcen wrote:
>
> Hi,
>
> We'd like to start mirroring the GCC.
>
> URLs:
> http://mirror.marwan.ma/gcc/
> https://mirror.marwan.ma/gcc/
> rsync://mirror.marwan.ma/gcc/
> Location: Rabat, Morocco
>
On Fri, Oct 11, 2019 at 09:03:53AM +0200, Jan Hubicka wrote:
> Bootstrapped/regtested x86_64-linux, OK?
>
> * ggc-page.c (release_pages): Output statistics when !quiet_flag.
> (ggc_collect): Dump later to not interfere with release_page dump.
> (ggc_trim): New function.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92153
--- Comment #1 from Jakub Jelinek ---
Author: jakub
Date: Fri Oct 18 17:18:21 2019
New Revision: 277157
URL: https://gcc.gnu.org/viewcvs?rev=277157=gcc=rev
Log:
PR middle-end/92153
* ggc-page.c (release_pages): Read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #41 from Rich Felker ---
> Josef Wolf mentioned that he ran into this on the gcc-help mailing list here:
> https://gcc.gnu.org/ml/gcc-help/2019-10/msg00079.html
I don't think that's an instance of this issue. It's normal/expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92153
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92154
--- Comment #1 from Jakub Jelinek ---
If it has landed upstream already, please post the backport of it to
gcc-patches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #40 from Eric Gallager ---
Josef Wolf mentioned that he ran into this on the gcc-help mailing list here:
https://gcc.gnu.org/ml/gcc-help/2019-10/msg00079.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #21 from Jakub Jelinek ---
Created attachment 47069
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47069=edit
gcc10-prereload-splitters.patch
Ah, apparently we already have for ~ 2 years a property to handle this safely.
So
Hi!
While reviewing
<20191003163505.49997-2-julian@codesourcery.com">http://mid.mail-archive.com/20191003163505.49997-2-julian@codesourcery.com>
"OpenACC reference count overhaul", I've just now stumbled over one thing
that originally was designed here:
On 2018-12-10T19:41:37+, Julian Brown
As mentioned at the Cauldron, I'm looking at finding better branchpoints
for the cases in the GCC repository where cvs2svn messed up identifying
the parent branch and commit on which a branch was based, so that affected
branches can be reparented as part of moving to git, since messed-up
Hello community,
I don't know the correct format for this email, so I'll give a summary
according to https://gcc.gnu.org/contributewhy.html and wait for
responses!
"what you are working on"
I am creating a program to link the draw.io platform with a c++
compiled gcc output
to allow for:
1.
On Thu, Oct 17, 2019 at 10:20 PM Miguel Saldivar wrote:
>
> This is a small fix for Bug 67299, where symbol: `Z1fCf` which would become
> `f(float complex)` instead of `f(floatcomplex )`.
> I thought this would be the preferred way of printing, because both
> `llvm-cxxfilt` and `cpp_filt` both
On 18 Oct 2019, Pedro Alves stated:
> On 10/18/19 2:21 PM, Richard Biener wrote:
>
In most cases local types etc are a fairly small contributor to the
total volume -- but macros can contribute a lot in some codebases.
>>> (The
Linux kernel's READ_ONCE macro is one I've personally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #20 from Segher Boessenkool ---
Ah, okay. So it is either one or two insns (zero can not be handled, but you
can do a noop, a move of a reg to itself, and that will be optimised away just
fine). Three insns is not something combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #19 from Jakub Jelinek ---
Created attachment 47068
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47068=edit
gcc10-pr90231.patch
Untested implementation of what I wrote above.
The difference on the testcase at -O2 -g is:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12306
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #8
1 - 100 of 190 matches
Mail list logo
