Hi Bernd!
On 11/26/19 2:44 AM, Bernd Schmidt wrote:
> I overlooked a difference in the 68881 vs coldfire patterns when I
> combined them. They use different suffixes for register compares (I only
> spotted the different constraints).
>
> The following seems to fix the assembler failures. I
> On 11/21/19 10:30 AM, ste...@franke.ms wrote:
> > Hi there,
> >
> > here is mc68k's patch to switch the m68k architecture over to ccmode and
> > lra. See https://github.com/mc68kghost/gcc 68k-ccmode branch.
> Bernd Schmidt posted a conversion of the m68k port to ccmode a couple
> weeks before
I have a patch for the same location so here is my remark that might
make my patch useless.
Maybe you can even merge it with yours Ed, here it is:
https://gcc.gnu.org/ml/libstdc++/2019-10/msg00072.html
On 11/25/19 10:15 PM, Jonathan Wakely wrote:
On 15/11/19 22:17 -0500, Ed Smith-Rowland via
Summary variables should be deleted at the end of write_summary.
It's first newed in generate_summary, and second newed in read_summary.
Therefore, delete the first in write_summary, delete the second in
execute.
gcc/ChangeLog:
2019-11-26 Luo Xiong Hu
* ipa-pure-const.c
On Mon, Nov 25, 2019 at 07:05:02PM -0600, Segher Boessenkool wrote:
> On Mon, Nov 25, 2019 at 05:52:29PM -0500, Michael Meissner wrote:
> > If you write:
> >
> > paddi 10,9,foo@pcrel
> >
> > The assembler will interpret this as:
> >
> > paddi 10,9,(.-foo),0
foo-. actually.
> > I.e. it
On 11/26/19 3:21 AM, Joseph Myers wrote:
>
> The soft-float ColdFire build (--with-arch=cf --with-cpu=54455
> --disable-multilib) successfully built libgcc and glibc, but ran into an
> ICE building the glibc tests. Again, I've not bisected but this commit
> seems likely to be responsible.
On Tue, 26 Nov 2019, Bernd Schmidt wrote:
> On 11/26/19 1:36 AM, Joseph Myers wrote:
> > I'm seeing a libgcc build failure for coldfire in my build-many-glibcs.py
> > bot (m68k-linux-gnu configured --with-arch=cf --disable-multilib). That's
> > building _mulsc3.o; I get assembler errors:
>
>
On 11/26/19 1:36 AM, Joseph Myers wrote:
> I'm seeing a libgcc build failure for coldfire in my build-many-glibcs.py
> bot (m68k-linux-gnu configured --with-arch=cf --disable-multilib). That's
> building _mulsc3.o; I get assembler errors:
I overlooked a difference in the 68881 vs coldfire
On Mon, Nov 25, 2019 at 11:08:47PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Mon, Nov 25, 2019 at 09:16:52PM +, Richard Sandiford wrote:
> >> Segher Boessenkool writes:
> >> > I am wondering the other way around :-) Is what you do for combine2
> >> > something that
On Mon, Nov 25, 2019 at 05:52:29PM -0500, Michael Meissner wrote:
> On Fri, Nov 22, 2019 at 06:52:42PM -0600, Segher Boessenkool wrote:
> > On Thu, Nov 14, 2019 at 05:51:14PM -0500, Michael Meissner wrote:
> > > In some of my previous work, I had make a mistake forgetting that the
> > > PADDI
> >
On Mon, 25 Nov 2019, Rainer Orth wrote:
> and a few more, all DFP related. They used to be emitted by g++ for
> __fundamental_type_info in libsupc++/fundamental_type_info.cc and lived
> in the CXXABI_1.3.4 version. However, since Solaris *does* lack DFP
> support, that's no longer the case.
On Mon, 25 Nov 2019, Rainer Orth wrote:
> it seems you missed updating a couple of testcases that are ia32-only:
I think it's unavoidable that such target-specific testcases need updating
by someone testing on the target in question.
--
Joseph S. Myers
jos...@codesourcery.com
On Mon, Nov 25, 2019 at 05:40:02PM -0500, Michael Meissner wrote:
> On Fri, Nov 22, 2019 at 06:32:08PM -0600, Segher Boessenkool wrote:
> > On Thu, Nov 14, 2019 at 05:44:42PM -0500, Michael Meissner wrote:
> > > This patch generates PADDI to add 34-bit immediate constants on the
> > > 'future'
>
On Mon, Nov 25, 2019 at 05:17:08PM -0500, Michael Meissner wrote:
> On Fri, Nov 22, 2019 at 06:20:52PM -0600, Segher Boessenkool wrote:
> > > (define_split
> > >[(set (match_operand:SI 0 "gpc_reg_operand")
> > > (match_operand:SI 1 "const_int_operand"))]
> > >"(unsigned HOST_WIDE_INT)
On Mon, 25 Nov 2019, Bernd Schmidt wrote:
> On 11/23/19 6:36 PM, Jeff Law wrote:
>
> > Not really. I've already indicated to Bernd that he should go ahead and
> > commit the changes and we can iterate on any problems that arise.
>
> After the last fix, I did some more testing and since I feel
Hi!
The standard says that argument-attribute-clause is:
attribute-argument-clause:
( balanced-token-seq[opt] )
balanced-token-seq:
balanced-token
balanced-token-seq balanced-token
balanced-token:
( balanced-token-seq[opt] )
[ balanced-token-seq[opt] ]
Hi!
On Mon, Nov 25, 2019 at 03:46:23PM +0100, Jakub Jelinek wrote:
> On Mon, Nov 25, 2019 at 03:39:32PM +0100, Jakub Jelinek wrote:
> > I guess the question is, shall we store the minimum precision needed
> > somewhere by finish_enum_value_list (perhaps only bother if the precision
> > of the
Hi!
The following testcase ICEs, because we assert the only constants with
NULLPTR_TYPE created are 0.
The fix is to perform the value adjustment of boundary value and EQ/NE
conversion to other comparisons only for scalar integral types, not anything
that happens to be INTEGER_CST (other types
On Fri, Nov 22, 2019 at 12:33:47PM +0100, Tobias Burnus wrote:
> > Mark Eggleston
> > Jim MacArthur
> >
> > * gfortran.dg/dec-comparison.f90: New test.
This test is UNRESOLVED everywhere, a test which expects dg-error diagnostic
really can't be dg-do run, as for erroneous sources
Segher Boessenkool writes:
> Hi!
>
> On Mon, Nov 25, 2019 at 09:16:52PM +, Richard Sandiford wrote:
>> Segher Boessenkool writes:
>> > I am wondering the other way around :-) Is what you do for combine2
>> > something that would be more generally applicable/useful? That's what
>> > I'm
Hi Mike,
On Mon, Nov 25, 2019 at 05:09:10PM -0500, Michael Meissner wrote:
> On Fri, Nov 22, 2019 at 06:06:19PM -0600, Segher Boessenkool wrote:
> > > --- gcc/config/rs6000/rs6000.c(revision 278173)
> > > +++ gcc/config/rs6000/rs6000.c(working copy)
> > > @@ -5552,7 +5552,7 @@ static int
On Fri, Nov 22, 2019 at 06:52:42PM -0600, Segher Boessenkool wrote:
> On Thu, Nov 14, 2019 at 05:51:14PM -0500, Michael Meissner wrote:
> > In some of my previous work, I had make a mistake forgetting that the PADDI
> > instruction did not allow adding a PC-relative reference to a register (you
>
On Mon, Nov 25, 2019 at 09:40:36PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > - i386 goes into an infinite loop compiling, or at least an hour or so...
> > Erm I forgot too record what it was compiling. I did attach a GDB... It
> > is something from lra_create_live_ranges.
On Fri, Nov 22, 2019 at 06:32:08PM -0600, Segher Boessenkool wrote:
> On Thu, Nov 14, 2019 at 05:44:42PM -0500, Michael Meissner wrote:
> > This patch generates PADDI to add 34-bit immediate constants on the 'future'
> > system, and prevents such adds from being split.
>
> I don't see that last
On 25/11/19 22:34 +0100, François Dumont wrote:
I plan to commit this tomorrow.
Thanks.
But I really wonder if we couldn't just add some __glibcxx_checks_xxx
in std/array ?
That probably makes sense. std::array::iterator is just T* so we
don't get debug iterators anyway.
On Fri, Nov 22, 2019 at 06:20:52PM -0600, Segher Boessenkool wrote:
> On Thu, Nov 14, 2019 at 05:42:43PM -0500, Michael Meissner wrote:
> > -;; Split a load of a large constant into the appropriate two-insn
> > -;; sequence.
> > +;; Split a load of a large constant into the appropriate two-insn
>
Hi!
On Mon, Nov 25, 2019 at 09:16:52PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > I am wondering the other way around :-) Is what you do for combine2
> > something that would be more generally applicable/useful? That's what
> > I'm trying to find out :-)
> >
> > What
On Fri, Nov 22, 2019 at 06:06:19PM -0600, Segher Boessenkool wrote:
> On Thu, Nov 14, 2019 at 05:40:10PM -0500, Michael Meissner wrote:
> > --- gcc/config/rs6000/rs6000.c (revision 278173)
> > +++ gcc/config/rs6000/rs6000.c (working copy)
> > @@ -5552,7 +5552,7 @@ static int
> >
Segher Boessenkool writes:
> Hi!
>
> On Mon, Nov 18, 2019 at 05:55:13PM +, Richard Sandiford wrote:
>> Richard Sandiford writes:
>> > (It's 23:35 local time, so it's still just about stage 1. :-))
>>
>> Or actually, just under 1 day after end of stage 1. Oops.
>> Could have sworn stage 1
On 25/11/19 22:25 +0100, François Dumont wrote:
I plan to commit this patch tomorrow.
* include/debug/safe_iterator.h
[__cpp_lib_concepts](_Safe_iterator<>::iterator_concept): Define for
C++20.
Thanks.
François
diff --git a/libstdc++-v3/include/debug/safe_iterator.h
I plan to commit this tomorrow.
But I really wonder if we couldn't just add some __glibcxx_checks_xxx in
std/array ?
* include/debug/array (array<>::fill): Add C++20 constexpr.
(array<>::swap): Likewise.
François
diff --git a/libstdc++-v3/include/debug/array
I plan to commit this patch tomorrow.
* include/debug/safe_iterator.h
[__cpp_lib_concepts](_Safe_iterator<>::iterator_concept): Define for
C++20.
François
diff --git a/libstdc++-v3/include/debug/safe_iterator.h b/libstdc++-v3/include/debug/safe_iterator.h
index 685256551d9..abf575186c7
Segher Boessenkool writes:
> On Thu, Nov 21, 2019 at 08:32:14PM +, Richard Sandiford wrote:
>> Segher Boessenkool writes:
>> > It's not great if every pass invents its own version of some common
>> > infrastructure thing because that common one is not suitable.
>> >
>> > I.e., can this be
On 15/11/19 22:17 -0500, Ed Smith-Rowland via libstdc++ wrote:
Index: include/bits/stl_algobase.h
===
--- include/bits/stl_algobase.h (revision 278318)
+++ include/bits/stl_algobase.h (working copy)
@@ -107,6 +107,50 @@
}
/*
Hi,
a bunch of straightforward tweaks: let's use the available location in
some additional places. Tested x86_64-linux, as usual.
Thanks, Paolo.
///
/cp
2019-11-15 Paolo Carlini
* typeck.c (cp_build_unary_op): Consistently use the accurate
location in
Hi Joseph,
> Code that directly uses _Decimal* types on architectures not
> supporting DFP is properly diagnosed ("error: decimal floating-point
> not supported for this target"), via a call to
> targetm.decimal_float_supported_p, if the _Decimal32, _Decimal64 or
> _Decimal128 keywords are used
Hi Joseph,
> attribs.c has code to ignore all scoped attributes appertaining to
> types except when they are part of the definition of that type.
>
> I think the premise of that code is incorrect, and its presence is a
> bug; such attributes are clearly valid in both C and C++, which
> explicitly
So I was curious what would happen if I turned on LRA for m68k. It turns
out my autoinc patches from the cc0 patch set expose a bug in how LRA
handles autoincrement. While it copies the logic from reload's
inc_for_reload, it appears to be missing the find_reloads_address code
to ensure an autoinc
This implements most of the remaining C++20 additions to the
header.
* include/bits/iterator_concepts.h (ranges::iter_swap): Fix parameter
types of poison pill overload. Use remove_reference_t when checking
constraints.
* include/bits/stl_iterator.h
PR libstdc++/91786
* include/bits/fs_path.h (filesystem_error): Move definition before
the use in u8path.
Tested powerpc64le-linux, committed to trunk.
commit 48db2e15557a1e7bff8ce629c8e9979d0b6d0c29
Author: Jonathan Wakely
Date: Fri Nov 22 00:29:05 2019 +
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01015.html
It feels to me like it's getting a little late for this but it
would still be helpful to get some feedback. Jeff, you were
very interested in this work when we discussed it offline. Do
you have any comments?
On 10/24/19 8:42 AM,
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00812.html
On 11/18/19 11:23 AM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00812.html
On 11/11/19 6:27 PM, Martin Sebor wrote:
The attached patch extends the strlen pass to detect out-of-bounds
accesses to
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00652.html
This change is independent of either of the two patches below:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00429.html
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00652.html
On 11/18/19 11:22 AM, Martin Sebor wrote:
Ping:
On Mon, Nov 25, 2019 at 03:34:25PM +0100, Tobias Burnus wrote:
>
> well, the question is what counts as regression. In any case, I have now
> committed that patch as r278689.
>
Regression is fairly easy to define. Standard conforming code
that compiled and executed correctly (for some
Am 06.11.19 um 23:32 schrieb Jeff Law:
On 10/31/19 3:55 PM, Georg-Johann Lay wrote:
Hi, this adds the possibility to enable IEEE compatible double
and long double support in avr-gcc.
It supports 2 configure options
--with-double={32|64|32,64|64,32}
On Mon, Nov 25, 2019 at 03:58:44PM +0100, Jakub Jelinek wrote:
> On Mon, Nov 25, 2019 at 09:42:41AM -0500, Marek Polacek wrote:
> > On Mon, Nov 25, 2019 at 09:39:25AM -0500, Jason Merrill wrote:
> > > On Fri, Nov 22, 2019 at 4:51 PM Marek Polacek wrote:
> > >
> > > > Committed to git. Should
On Mon, Nov 25, 2019 at 09:42:41AM -0500, Marek Polacek wrote:
> On Mon, Nov 25, 2019 at 09:39:25AM -0500, Jason Merrill wrote:
> > On Fri, Nov 22, 2019 at 4:51 PM Marek Polacek wrote:
> >
> > > Committed to git. Should s/http/https/ the wg21 links.
> > >
> > > Jason, do we support P1907R1?
> >
On 11/15/19 12:02 PM, Stam Markianos-Wright wrote:
> Hi all,
>
> This patch adds support for a new real_format for ARM Brain Floating
> Point numbers to the middle end. This is to be used exclusively in the
> ARM back-end.
>
> The encode_arm_bfloat_half and decode_arm_bfloat_half functions
On Mon, Nov 25, 2019 at 03:39:32PM +0100, Jakub Jelinek wrote:
> I guess the question is, shall we store the minimum precision needed
> somewhere by finish_enum_value_list (perhaps only bother if the precision
> of the underlying type is not the same) or compute it each time again
> (which would
On 11/25/19 3:40 PM, Segher Boessenkool wrote:
> On Mon, Nov 25, 2019 at 01:38:53PM +0100, Tobias Burnus wrote:
>> Thanks for the m68k work! Can you also update
>> https://gcc.gnu.org/backends.html ?
>
>> PS: I wonder whether some other archs also should be updated on that web
>> page.
>
>
On Mon, Nov 25, 2019 at 09:39:25AM -0500, Jason Merrill wrote:
> On Fri, Nov 22, 2019 at 4:51 PM Marek Polacek wrote:
>
> > Committed to git. Should s/http/https/ the wg21 links.
> >
> > Jason, do we support P1907R1?
> >
>
> Pretty close, just need to add a bit more checking.
Thanks, won't
On Fri, Oct 20, 2017 at 11:59:39AM -0400, Jason Merrill wrote:
> > Still, warning when a bit-field can't hold all enumerators instead of
> > all values may be a good idea. I've looked into it, and it does require
> > recalculating the maximum and minimum enumerator value, since the bounds
> > of
On Fri, Nov 22, 2019 at 4:51 PM Marek Polacek wrote:
> Committed to git. Should s/http/https/ the wg21 links.
>
> Jason, do we support P1907R1?
>
Pretty close, just need to add a bit more checking.
> commit d59a823fb4ad2daa535d26f592274ec68b9cb4a1
> Author: Marek Polacek
> Date: Fri Nov
Hi!
On Mon, Nov 25, 2019 at 01:38:53PM +0100, Tobias Burnus wrote:
> Thanks for the m68k work! Can you also update
> https://gcc.gnu.org/backends.html ?
> PS: I wonder whether some other archs also should be updated on that web
> page.
Possibly. Probably?
But, do you have any particular
Hi Steve,
well, the question is what counts as regression. In any case, I have now
committed that patch as r278689.
Cheers,
Tobias
On 25/11/2019 14:17, Tobias Burnus wrote:
The compiler warns that funcs_tail and vars_tails are unused – they,
funcs_ids/var_ids and struct id_map seem to be a copy-n-paste leftovers
from gcc/config/nvptx/mkoffload.c.
Additionally, COMMENT_PREFIX does not seem to be used anywhere. (In the
The compiler warns that funcs_tail and vars_tails are unused – they,
funcs_ids/var_ids and struct id_map seem to be a copy-n-paste leftovers
from gcc/config/nvptx/mkoffload.c.
Additionally, COMMENT_PREFIX does not seem to be used anywhere. (In the
whole of GCC, it appears twice – in this file
Martin,
Thanks for your review. I updated the patch with your comments.
Feng
---
2019-11-15 Feng Xue
PR ipa/92133
* doc/invoke.texi (ipa-cp-max-recursive-depth): Document new option.
(ipa-cp-min-recursive-probability): Likewise.
* params.opt
Hi Thomas,
sorry for the belated reply.
Some comments – and a patch modifying two test cases (see below).
Regarding the patch: OK for the trunk?
On 11/11/19 10:39 AM, Thomas Schwinge wrote:
By the way, do you know what's the status is for Fortran common blocks in
OpenMP: supported vs.
Hi.
The patch cleans up typos in a dump message in IPA ICF pass.
I'm going to install the patch.
Thanks,
Martin
gcc/ChangeLog:
2019-11-25 Martin Liska
* ipa-icf.c (sem_item_optimizer::dump_cong_classes): Clean
up used dump message.
---
gcc/ipa-icf.c | 3 +--
1 file
Hi.
Based on the discussion with Honza, I'm going to install the following patch.
It comments out a checking assert that is too strict. Honza promised that he
will take a look later.
Martin
gcc/ChangeLog:
2019-11-25 Martin Liska
PR bootstrap/92653
* ipa-fnsummary.c
Hello.
I'm sending v2 of the patch set based on the discussion I had with Honza.
Changes from previous version:
- I changed type of edge count from uint32_t to uint64_t.
- The algorithm traverses recursively inline clones.
- TDF_DUMP_DETAILS is supported and provides more information.
- I added
On Nov 25 2019, Bernd Schmidt wrote:
> On 11/25/19 12:26 PM, Andreas Schwab wrote:
>> On Nov 24 2019, Bernd Schmidt wrote:
>>
>>> Whew, I think I have it. One tst instruction eliminated when it
>>> shouldn't have been:
>>>
>>> move.w %a4,%d0
>>> - tst.b %d0
>>> - jeq .L352
The following tries to improve PR92645 in a minimal invasive way.
Currently as heuristic the BB vectorizer throws away vector stmts
when all of the vector stmts need to be built via a vector CTOR.
That makes sense unless the stmt only needs a single such vector CTOR
which would still mean
On 11/25/19 1:38 PM, Tobias Burnus wrote:
> Thanks for the m68k work! Can you also update
> https://gcc.gnu.org/backends.html ?
Committed as obvious.
Bernd
commit f42834ad5e77c05cb6bc0908b8fc9282fec7fc19
Author: Bernd Schmidt
Date: Mon Nov 25 13:48:08 2019 +0100
Change backends table
Hi Richard,
Many thanks for the suggestion of an alternative implementation. I tried
implementing the suggestion, and I had a couple of observations:
1. As well as applying the bias in compute_fn_summary, it seemed to also
be necessary to apply it in ip_update_overall_fn_summary to avoid an ICE
On 11/25/19 1:38 PM, Bernd Schmidt wrote:
> On 11/25/19 1:34 PM, John Paul Adrian Glaubitz wrote:
>> Are all 4 + 2 patches in now? Thus, can we close the bug?
>
> We're missing one piece for better autoinc generation, but that's a
> small optimization issue. The cc0 conversion is complete.
On 11/25/19 1:34 PM, John Paul Adrian Glaubitz wrote:
> Are all 4 + 2 patches in now? Thus, can we close the bug?
We're missing one piece for better autoinc generation, but that's a
small optimization issue. The cc0 conversion is complete.
Bernd
Hi Bernd,
Thanks for the m68k work! Can you also update
https://gcc.gnu.org/backends.html ?
(Webseite repo ist now in git, cf. https://gcc.gnu.org/about.html#git )
Cheers,
Tobias
PS: I wonder whether some other archs also should be updated on that web
page.
On 11/25/19 1:33 PM, Bernd
Hi Bernd!
On 11/25/19 1:33 PM, Bernd Schmidt wrote:
> On 11/23/19 6:36 PM, Jeff Law wrote:
>
>> Not really. I've already indicated to Bernd that he should go ahead and
>> commit the changes and we can iterate on any problems that arise.
>
> After the last fix, I did some more testing and since
On 11/23/19 6:36 PM, Jeff Law wrote:
> Not really. I've already indicated to Bernd that he should go ahead and
> commit the changes and we can iterate on any problems that arise.
After the last fix, I did some more testing and since I feel confident
that it really is in good shape now, I
On 11/25/19 12:26 PM, Andreas Schwab wrote:
> On Nov 24 2019, Bernd Schmidt wrote:
>
>> Whew, I think I have it. One tst instruction eliminated when it
>> shouldn't have been:
>>
>> move.w %a4,%d0
>> - tst.b %d0
>> - jeq .L352
>> + jeq .L353
>>
>> And the reason - that's
Hi,
I forgot to ping this,
is the updated patch OK?
On 9/6/19 1:27 PM, Bernd Edlinger wrote:
> On 9/6/19 12:47 PM, Richard Earnshaw (lists) wrote:
>> On 06/09/2019 11:28, Bernd Edlinger wrote:
>>> Hi!
>>>
>>> It was pointed out in the PR that the test case fails on big endian
>>> targets.
>>>
On 11/21/19 3:59 PM, Matthew Malcomson wrote:
On 21/11/2019 13:10, Martin Liška wrote:
On 11/20/19 6:40 PM, Matthew Malcomson wrote:
On 20/11/2019 14:29, Martin Liška wrote:
On 11/7/19 7:37 PM, Matthew Malcomson wrote:
I have rebased this series onto Martin Liska's patches that take the
most
I've messed up sharing the visited hash-map.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2019-11-25 Richard Biener
* tree-vect-slp.c (vect_detect_hybrid_slp_stmts): Add assertion.
(vect_detect_hybrid_slp): Swap lane and instance
On Nov 24 2019, Bernd Schmidt wrote:
> Whew, I think I have it. One tst instruction eliminated when it
> shouldn't have been:
>
> move.w %a4,%d0
> - tst.b %d0
> - jeq .L352
> + jeq .L353
>
> And the reason - that's a movqi using move.w. The following should fix
> it.
On 11/25/19 11:57 AM, Mark Eggleston wrote:
On 22/11/2019 11:33, Tobias Burnus wrote:
First, can you also create some news quip for your GCC 10 changes for
https://gcc.gnu.org/gcc-10/changes.html ? See
https://gcc.gnu.org/about.html#git for the repository to diff against.
As I right in
On 25/11/2019 11:14, Tobias Burnus wrote:
This patch adds "gcc_unreachable ();" as suggested by me (cf. below).
It also silences the -Wunused-variable + 'no return statement' warnings.
OK for the trunk?
OK.
Thanks, Tobias.
Andrew
This patch adds "gcc_unreachable ();" as suggested by me (cf. below).
It also silences the -Wunused-variable + 'no return statement' warnings.
OK for the trunk?
Tobias
PS: The warning fixes were part of my OG9 silence-warnings patch at
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01056.html
Commited https://gcc.gnu.org/viewcvs/gcc?view=revision=278674
On 22/11/2019 11:33, Tobias Burnus wrote:
First, can you also create some news quip for your GCC 10 changes for
https://gcc.gnu.org/gcc-10/changes.html ? See
https://gcc.gnu.org/about.html#git for the repository to diff against.
This is a regression present on mainline and 9 branch: the expression of an
Address aspect is elaborated twice (if it has side effects) because of a silly
mistake made in an ealier change.
Tested on x86_64-suse-linux, applied on the mainline and 9 branch.
2019-11-25 Eric Botcazou
Hi Julian,
On 11/23/19 12:42 AM, Julian Brown wrote:
gcc/fortran/
* trans-expr.c
(gfc_auto_dereference_var): New function, broken out of...
[…]
+gfc_auto_dereference_var (location_t loc, gfc_symbol *sym, tree var,
+ bool
On 11/25/19 10:27 AM, Jan Hubicka wrote:
On 11/23/19 2:12 PM, Jan Hubicka wrote:
I always use the outer function params since that is how local parameters
behave. I hope it is kind of what is also expected in most case: it is better
to inline agressively into -O3 compiled code rather than
> On 11/23/19 2:12 PM, Jan Hubicka wrote:
> > I always use the outer function params since that is how local parameters
> > behave. I hope it is kind of what is also expected in most case: it is
> > better
> > to inline agressively into -O3 compiled code rather than inline agressively
> > -O3
>
On Fri, 22 Nov 2019, Jeff Law wrote:
> On 11/21/19 1:00 AM, Richard Biener wrote:
> > On Wed, 20 Nov 2019, Jeff Law wrote:
> >
> > Sure, but we're not being called with this but with RTL
> > expanded via cselib usually:
> >
> > (plus:SI (plus:SI (and:SI (symbol_ref:SI ("*.LANCHOR0") [flags
On 11/23/19 2:12 PM, Jan Hubicka wrote:
I always use the outer function params since that is how local parameters
behave. I hope it is kind of what is also expected in most case: it is better
to inline agressively into -O3 compiled code rather than inline agressively -O3
functions into their
86 matches
Mail list logo
