https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92657
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663
--- Comment #6 from fiesh at zefix dot tv ---
My suggestion would be to uniformly include the information about whether a bug
has been closed, irrespective of its nature. So yes, un-optimal code
generation might also be listed, and I think the
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414
Eric Gallager changed:
What|Removed |Added
URL||https://gcc.gnu.org/ml/gcc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46558
Eric Gallager changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
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
Congrats!
On Tue, Nov 26, 2019, 11:11 Brett Gilio wrote:
> Jan Nieuwenhuizen writes:
>
> > We are pleased to announce the release of GNU Mes 0.21, representing
> > 54 commits over 10 weeks.
> >
> > Mes has now brought the Reduced Binary Seed bootstrap to Guix (bootstrap
> > a GNU/Linux system
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92667
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70477
--- Comment #9 from Eric Gallager ---
*** Bug 92668 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92668
Eric Gallager changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
Joseph Myers :
> I'm looking at the sets of branches and tags resulting from a GCC
> repository conversion with reposurgeon.
>
> 1. I see 227 branches (and one tag) with names like
> cxx0x-concepts-branch-deleted-r131428-1 (this is out of 780 branches in
> total in a conversion of GCC history
Jan Nieuwenhuizen writes:
> We are pleased to announce the release of GNU Mes 0.21, representing
> 54 commits over 10 weeks.
>
> Mes has now brought the Reduced Binary Seed bootstrap to Guix (bootstrap
> a GNU/Linux system without binary GNU toolchain or equivalent). See
>
Joseph Myers :
> My question is: is it a stable interface to reposurgeon that the portions
> of such a split commit will always be numbered in lexicographical order by
> branch name (or some other such well-defined stable ordering), so I can
> write <80870.2> in gcc.lift and know that some
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92649
--- Comment #5 from Jiangning Liu ---
Unrolling 1024 iterations would increase code size a lot, so usually we don't
do that. 1024 is only an example. Without knowing we could eliminate most of
them, we don't really want to do loop unrolling, I
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92651
--- Comment #5 from Hongyu Wang ---
(In reply to Jakub Jelinek from comment #3)
> Do you mean r274481 rather than r277481, right?
Yes. Thanks for your correction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92651
--- Comment #4 from Hongyu Wang ---
(In reply to Richard Biener from comment #2)
> Btw, which variant is actually the fastest for you? abs expansion doesn't
> do any cost comparison but just uses direct abs, max and then the xor with
> shift
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92668
--- Comment #3 from joseph at codesourcery dot com ---
Isn't this the same as bug 70477?
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92668
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92668
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92569
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92569
--- Comment #12 from Thomas Koenig ---
Author: tkoenig
Date: Mon Nov 25 22:26:26 2019
New Revision: 278710
URL: https://gcc.gnu.org/viewcvs?rev=278710=gcc=rev
Log:
Fix EOF handling for arrays.
2019-11-25 Thomas Koenig
Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92668
Bug ID: 92668
Summary: -Wtautological-compare warns for macros that expand to
the same symbol
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
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
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92629
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
On Mon, Nov 25, 2019 at 9:43 PM Andrew Dean wrote:
>
> > > >>> I get errors like this:
> > > >>>
> > > >>> aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file
> > > >>> 'rdimon.specs': No such file or directory
> > > >>>
> > > >>> I can see that the rdimon.specs flag is added based on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92667
Bug ID: 92667
Summary: spurious missing sentinel in function call with a
local sentinel variable
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity:
> > >>> I get errors like this:
> > >>>
> > >>> aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file
> > >>> 'rdimon.specs': No such file or directory
> > >>>
> > >>> I can see that the rdimon.specs flag is added based on this line
> > >>> in aarch64-
> > >> sim.exp:
> > >>
> > >> Where
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92666
--- Comment #2 from Martin Sebor ---
The check_function_restrict() function is called to do the -Wrestrict checking.
It's called conditionally, from check_function_arguments(), when warn_restrict
is nonzero. When called, the function calls
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663
--- Comment #5 from Jonathan Wakely ---
True, but I still think the list needs to be compiled in to the binaries
statically. If that gave incorrect results in some cases (because a bug was
thought to be fixed when the static list was generated,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92442
--- Comment #8 from Jason Merrill ---
(In reply to Richard Biener from comment #5)
> There are also quite many _name_ duplicates refering to different DIEs! Like
> 178 copies of 'std::is_same_v' and others:
std::*_v are variable templates, so
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 @@
}
/*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92656
--- Comment #1 from Andrew Pinski ---
Hmm, this comes from coremarks (what a bad benchmark).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92656
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92666
Martin Sebor changed:
What|Removed |Added
Summary|bogus |[10 Regression] bogus
Greetings Richard,
After looking through the current work on multi-threading seems that we
can scale
better with a workqueue strategy sharing and launching depending on how
state is
shared between the GCC passes.
I'm not very familiar with all the details of how state is share in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92666
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92666
Bug ID: 92666
Summary: bogus -Wunused-but-set-variable in gcov.c with
-Wno-restrict
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
On Mon, Nov 25, 2019 at 8:40 PM Adhemerval Zanella
wrote:
>
>
>
> On 25/11/2019 17:28, Andrew Dean via gcc wrote:
> >>> This completes successfully. However, when I then try to run the gcc
> >>> tests like
> >> so:
> >>> runtest --outdir . --tool gcc --srcdir /path/to/gcc/gcc/testsuite
> >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663
--- Comment #3 from Jonathan Wakely ---
(In reply to Eric Gallager from comment #2)
> This sounds like it could be dangerous from a security context... currently
> no network connection is needed to use gcc, it would be a major
> disappointment
On 25/11/2019 17:28, Andrew Dean via gcc wrote:
>>> This completes successfully. However, when I then try to run the gcc tests
>>> like
>> so:
>>> runtest --outdir . --tool gcc --srcdir /path/to/gcc/gcc/testsuite
>>> aarch64.exp --target aarch64-linux-gnu --target_board aarch64-sim
>>>
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92533
--- Comment #5 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #4)
> Probably somewhere in module.c's gfc_use_module.
That's actually to early. gfc_use_module is run after all use statements have
been processed while the
> > This completes successfully. However, when I then try to run the gcc tests
> > like
> so:
> > runtest --outdir . --tool gcc --srcdir /path/to/gcc/gcc/testsuite
> > aarch64.exp --target aarch64-linux-gnu --target_board aarch64-sim
> > --tool_exec
> >
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
On Mon, 25 Nov 2019 at 20:17, Andrew Dean via gcc wrote:
>
> Based on https://www.gnu.org/software/hurd/hurd/glibc.html, I'm using
> glibc/scripts/build-many-glibcs.py targeting aarch64-linux-gnu as so:
>
> build-many-glibcs.py build_dir checkout --keep all
>
> build-many-glibcs.py build_dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549
--- Comment #17 from Dávid Bolvanský ---
Check few lines above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549#c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92569
--- Comment #11 from Thomas Koenig ---
Author: tkoenig
Date: Mon Nov 25 20:04:28 2019
New Revision: 278702
URL: https://gcc.gnu.org/viewcvs?rev=278702=gcc=rev
Log:
Fix EOF handling for arrays.
2019-11-25 Thomas Koenig
Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92665
--- Comment #4 from Andrew Pinski ---
(In reply to Wilco from comment #3)
> I think it's because many intrinsics in arm_neon.h still use asm which
> inhibits most optimizations.
NO in this case it is not.
Take:
#include "arm_neon.h"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549
--- Comment #16 from Jakub Jelinek ---
Of course there is, -Wno-misleading-indentation or use line breaks from time to
time. With >= 4KB long lines, the user clearly doesn't care about indentation,
so the warning doesn't make sense.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
Eric Gallager changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
--- Comment #13 from Florian Weimer ---
(In reply to Wilco from comment #12)
> Giving errors on old-style code by default sounds like a good idea. We could
> add -std=legacy similar to Fortran to support building old K code (and
> that would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92629
--- Comment #3 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Mon Nov 25 19:50:38 2019
New Revision: 278699
URL: https://gcc.gnu.org/viewcvs?rev=278699=gcc=rev
Log:
2019-11-25 Harald Anlauf
PR fortran/92629
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92665
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661
--- Comment #5 from Peter Bergner ---
(In reply to jos...@codesourcery.com from comment #4)
> My suggestion for the target-specific built-in functions would be:
>
> * builtin_function_type in rs6000-call.c should detect the case of a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92665
--- Comment #2 from Andrew Pinski ---
Created attachment 47356
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47356=edit
Patch which I wrote for GCC 7.3
I have to double check if it applies directly as I had other patches in this
area but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
--- Comment #12 from Wilco ---
(In reply to David Brown from comment #11)
> Changing the default to "-fno-common" (and ideally
> "-Werror=strict-prototypes -Werror=old-style-declaration
> -Werror=missing-parameter-type") would have a lot
Based on https://www.gnu.org/software/hurd/hurd/glibc.html, I'm using
glibc/scripts/build-many-glibcs.py targeting aarch64-linux-gnu as so:
build-many-glibcs.py build_dir checkout --keep all
build-many-glibcs.py build_dir host-libraries --keep all -j 12
build-many-glibcs.py build_dir compilers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92538
Erick Ochoa changed:
What|Removed |Added
CC||erick.ochoa@theobroma-syste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549
--- Comment #15 from Dávid Bolvanský ---
But there is no way to silence this "note".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92665
Andrew Pinski changed:
What|Removed |Added
Target||aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91786
--- Comment #1 from Jonathan Wakely ---
Author: redi
Date: Mon Nov 25 19:01:58 2019
New Revision: 278697
URL: https://gcc.gnu.org/viewcvs?rev=278697=gcc=rev
Log:
PR libstdc++/91786 fix compilation error with Clang
PR libstdc++/91786
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 +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92665
Bug ID: 92665
Summary: [AArch64] low lanes select not optimized out for vmlal
intrinsics
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #1 from Andrew
1 - 100 of 261 matches
Mail list logo
