On 10/15/2018 12:07 PM, Jonathan Wakely wrote:
On 09/10/18 07:11 +0200, François Dumont wrote:
Here is the communication for my yesterday's patch which I thought
svn had failed to commit (I had to interrupt it).
Similarly to what I've done for associative containers here is a
cleanup of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87619
Bug ID: 87619
Summary: sizeof(std::variant) can be reduced if its
variant_size is UCHAR_MAX
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
From 55047aa22e40de2637fbab4b5e246dfc4ca191f8 Mon Sep 17 00:00:00 2001
From: Chenghua Xu
Date: Mon, 3 Sep 2018 19:45:15 +0800
Subject: [PATCH 5/6] Add support for Loongson 3A2000/3A3000 proccessor.
gcc/
* config/mips/gs464e.md: New.
* config/mips/mips-cpus.def: Define gs464e.
*
From 0df9c46bea628086ca2c4b5db24c28cec912d319 Mon Sep 17 00:00:00 2001
From: Chenghua Xu
Date: Mon, 3 Sep 2018 20:01:54 +0800
Subject: [PATCH 6/6] Add support for Loongson 2K1000 proccessor.
gcc/
* config/mips/gs264e.md: New.
* config/mips/mips-cpus.def: Define gs264e.
*
From 14eabf990f187631cacd47e02342941ddb1b04a0 Mon Sep 17 00:00:00 2001
From: Chenghua Xu
Date: Fri, 31 Aug 2018 11:55:48 +0800
Subject: [PATCH 3/6] Add support for Loongson EXT2 istructions.
gcc/
* config/mips/mips.h (TARGET_CPU_CPP_BUILTINS): Define
__mips_loongson_ext2,
From ce950df0f918eb02d15c4287d21e3aecb43bf351 Mon Sep 17 00:00:00 2001
From: Chenghua Xu
Date: Fri, 31 Aug 2018 14:08:01 +0800
Subject: [PATCH 4/6] Add support for Loongson 3A1000 proccessor.
gcc/
* config/mips/loongson3a.md: Rename to ...
* config/mips/gs464.md: ... here.
*
From e9d36eb4d4a841486ac82037497a2671481f8a27 Mon Sep 17 00:00:00 2001
From: Chenghua Xu
Date: Sun, 14 Oct 2018 11:11:00 +0800
Subject: [PATCH 1/6] Add support for loongson mmi instructions.
gcc/
* config.gcc (extra_headers): Add loongson-mmiintrin.h.
* config/mips/loongson.md:
From 2e053c832497892c6b8b1b685aaf871d8fc4da76 Mon Sep 17 00:00:00 2001
From: Chenghua Xu
Date: Fri, 31 Aug 2018 11:52:33 +0800
Subject: [PATCH 2/6] Add support for Loongson EXT istructions.
gcc/
* config/mips/mips.c (mips_option_override): Default enable
Loongson EXT on Loongson 3a target.
*
Hi:
The original version of patches were here:
https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00099.html
This is a update version. please review, thanks.
This series patches reorganize the Loongson -march=xxx and Loongson
extensions instructions set. For long time, the Loongson extensions
On 10/11/18 10:40 PM, Jeff Law wrote:
> On 10/11/18 1:23 PM, Peter Bergner wrote:
>> * ira-lives (non_conflicting_reg_copy_p): Disable for non LRA targets.
> So this helped the alpha & hppa and sh4.
>
> I'm still seeing failures on the aarch64, s390x. No surprise on these
> since they use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87618
Bug ID: 87618
Summary: Missing symbol for std::__cxx11::basic_stringbuf, std::allocator
>::basic_stringbuf()
Product: gcc
Version: 9.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
Eric Gallager changed:
What|Removed |Added
Keywords||diagnostic
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85593
--- Comment #9 from Austin Morton ---
Apologies for letting this sit so long.
I spent an afternoon digging through some of the mentioned functions trying to
familiarize myself with everything but I didn't make it further than that.
That was a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84648
--- Comment #3 from bin cheng ---
(In reply to Richard Biener from comment #2)
> So we run into
>
> /* Ignore loops of while (i-- < 10) type. */
> if (code != NE_EXPR)
> {
> if (iv0->step && tree_int_cst_sign_bit (iv0->step))
>
I sent mail to James about a month ago, but never heard back So...
This patch works around a problem in the ft32 port that shows up when
building newlib.
The assembler was complaining about a line like this:
ldi.b $r1,_ctype_-0x80+1($r0)
That's certainly an odd looking
This patch adds a minimum width to the left margin used for printing
line numbers. I set the default to 6. Hence rather than:
some-filename:9:1: some message
9 | some source text
| ^~~~
some-filename:10:1: another message
10 | more source text
| ^~~~
we now print:
"error_at_rich_loc" went away in r254280 (in favor of overloading
"error_at"), but there was a stray reference in a comment.
Remove it.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Committed to trunk as r265177.
gcc/ChangeLog:
* gcc-rich-location.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87617
seurer at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
On Mon, Oct 15, 2018 at 08:13:19PM +0100, Jonathan Wakely wrote:
> On Mon, 15 Oct 2018 at 20:08, Gabriel Paubert wrote:
> >
> > On Mon, Oct 15, 2018 at 08:11:42PM +0200, Florian Weimer wrote:
> > > * Jonathan Wakely:
> > >
> > > > On Sun, 14 Oct 2018 at 20:46, Florian Weimer wrote:
> > > >>
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87614
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87617
--- Comment #1 from seurer at gcc dot gnu.org ---
Maybe fixed by r265175?
On 10/15/2018 12:10 PM, Jonathan Wakely wrote:
On 15/10/18 07:23 +0200, François Dumont wrote:
This patch extend usage of C++11 direct initialization in
__debug::vector and makes some calls to operator - more consistent.
Note that I also rewrote following expression in erase method:
-
I started considering PR libstdc++/68303.
First thing was to write a dedicated performance test case, it is the
unordered_small_size.cc I'd like to add with this patch.
The first runs show a major difference between tr1 and std
implementations, tr1 being much better:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615
--- Comment #4 from David Binderman ---
(In reply to Alexander Monakov from comment #3)
> Looks like gcc-9 regressed here.
Not sure. Adding flag -fno-inline to the compile line:
$ time ~/gcc/results.265139.release/bin/gcc -w -I
On 10/15/2018 11:36 AM, Jonathan Wakely wrote:
On 12/10/18 18:25 +0200, François Dumont wrote:
Here is the patch for _Bit_iterator and _Bit_const_iterator operators.
I noticed that _Bit_reference == and < operators could be made inline
friend too. Do you want me to include this change in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87617
Bug ID: 87617
Summary: New test case gfortran.dg/inline_matmul_24.f90 from
r265126 doesn't work quite right
Product: gcc
Version: 9.0
Status: UNCONFIRMED
On Fri, Oct 12, 2018 at 2:14 PM Marc Glisse wrote:
> On Fri, 12 Oct 2018, Thomas Schwinge wrote:
>
> > Hmm, and without any OpenACC/OpenMP etc., actually the same problem is
> > also present when running the following code through the vectorizer:
> >
> >for (int tmp = 0; tmp < N_J * N_I;
On Mon, Oct 15, 2018 at 10:45:08PM +0300, Alexander Monakov wrote:
> On Mon, 15 Oct 2018, Segher Boessenkool wrote:
> > On Sun, Oct 14, 2018 at 11:07:20PM +0300, Alexander Monakov wrote:
> > > For Basic asms, no similar mechanism is necessary since they are
> > > antithetical
> > > to efficiency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615
--- Comment #3 from Alexander Monakov ---
On gcc-8 -fno-ipa-cp does not affect time, I brought it up prematurely:
-O2 -time
# cc1 207.15 0.22
-O2 -time -fno-ipa-cp
# cc1 207.57 0.18
-O2 -time -fno-inline
# cc1 21.13 0.10
Looks like gcc-9
On 10/15/2018 11:58 AM, Jonathan Wakely wrote:
On 11/10/18 22:46 +0200, François Dumont wrote:
This patch makes extensive use of C++11 direct init in
__debug::forward_list.
Doing so I also try to detect useless creation of safe iterators in
debug implementation. In __debug::forward_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77385
--- Comment #3 from Paul Thomas ---
(In reply to Dominique d'Humieres from comment #1)
> Confirmed from 4.7 up to trunk (7.0), Polymorphic arrays are not yet
> supported on 4.6.
>
> Note that the following variant
>
> MODULE a
>IMPLICIT
On Mon, 15 Oct 2018, Segher Boessenkool wrote:
> On Sun, Oct 14, 2018 at 11:07:20PM +0300, Alexander Monakov wrote:
> > For Basic asms, no similar mechanism is necessary since they are
> > antithetical
> > to efficiency in the first place.
>
> I missed this part.
>
> asm("bla");
>
> means
as the subject states, FORM TEAM was only using the resulting tree
expression, ignoring code which was generated before (or afterward).
I am not sure how to best convert it to a test-suite test case. For
form team (team(this_image()), my_team2)
the old dump was:
integer(kind=4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87495
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87607
Jonathan Wakely changed:
What|Removed |Added
Resolution|FIXED |INVALID
On Mon, 15 Oct 2018 at 20:08, Gabriel Paubert wrote:
>
> On Mon, Oct 15, 2018 at 08:11:42PM +0200, Florian Weimer wrote:
> > * Jonathan Wakely:
> >
> > > On Sun, 14 Oct 2018 at 20:46, Florian Weimer wrote:
> > >>
> > >> * Rasmus Villemoes:
> > >>
> > >> > This is something I've sometimes found
On Mon, Oct 15, 2018 at 08:11:42PM +0200, Florian Weimer wrote:
> * Jonathan Wakely:
>
> > On Sun, 14 Oct 2018 at 20:46, Florian Weimer wrote:
> >>
> >> * Rasmus Villemoes:
> >>
> >> > This is something I've sometimes found myself wishing was supported. The
> >> > idea being that one can say
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87556
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84849
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
Right commit revision, wrong attached file (original patch, not the
follow-up one).
Now hopefully the correct one.
Tobias
Am 15.10.18 um 21:02 schrieb Tobias Burnus:
Fixed with commit Rev. 265175 as attached.
Cheers
Tobias
Dominique d'Humières wrote:
Le 14 oct. 2018 à 00:43, Tobias
Fixed with commit Rev. 265175 as attached.
Cheers
Tobias
Dominique d'Humières wrote:
Le 14 oct. 2018 à 00:43, Tobias Burnus a écrit :
Dominique d'Humières wrote:
UNRESOLVED: gfortran.dg/inline_matmul_24.f90 -O0 scan-tree-dump-times optimized
"gamma5[__var_1_do * 4 +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87597
--- Comment #7 from Tobias Burnus ---
Author: burnus
Date: Mon Oct 15 18:58:17 2018
New Revision: 265175
URL: https://gcc.gnu.org/viewcvs?rev=265175=gcc=rev
Log:
2018-10-15 Tobias Burnus
PR fortran/87597
*
On 15/10/18 14:55 +0100, Jonathan Wakely wrote:
Glibc changed the it_IT locales to use thousands separators,
invalidating this test. Use nl_NL instead, as Dutch only uses grouping
for money not numbers.
* testsuite/22_locale/numpunct/members/char/3.cc: Adjust test to
account for
On Sun, 2018-10-14 at 11:01 -0600, Martin Sebor wrote:
> On 10/12/2018 09:43 AM, David Malcolm wrote:
> > Here's a proposed "User Experience Guidelines" section for our
> > internals manual
> >
> > It's a mixture of proposed policy, together with notes on how to
> > implement the recommendations.
Hi Richard,
as Joseph pointed out, there are some related discussions
on the WG14 reflector. How a about moving the discussion
there?
I find your approach very interesting and that it already
comes with an implementation is of course very useful
But I don't really understand the reasons why
On Sun, Oct 14, 2018 at 11:07:20PM +0300, Alexander Monakov wrote:
> For Basic asms, no similar mechanism is necessary since they are antithetical
> to efficiency in the first place.
I missed this part.
asm("bla");
means almost the same as
asm("bla" : );
and there is nothing in there that
* Jonathan Wakely:
> On Sun, 14 Oct 2018 at 20:46, Florian Weimer wrote:
>>
>> * Rasmus Villemoes:
>>
>> > This is something I've sometimes found myself wishing was supported. The
>> > idea being that one can say
>> >
>> > unsigned a[] = { [0] = 1, [1] = 3, [0] |= 4, ...}
>> >
>> > which would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615
--- Comment #2 from David Binderman ---
(In reply to Alexander Monakov from comment #1)
> How much does -fno-ipa-cp help (on gcc-8 I see incredibly deep recursion in
> walk_aliased_vdefs_1 under IPA-CP analysis)?
New execution time is about 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87607
Håkon Høines changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #2 from Håkon Høines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87616
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87616
--- Comment #2 from Michael Gorbovitski ---
Slightly simplified test case (no need for double-argument template):
struct foo{};
template struct friender {
using cls=foo;
};
class bar {
template
friend class friender::cls;
int
On Sun, Oct 14, 2018 at 11:07:20PM +0300, Alexander Monakov wrote:
> impacts inlining decisions badly, since GCC assumes cost of the asm to be
> high, even though it emits just one instruction to the text section. I'd
> like to point out that branch range optimization is also negatively affected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87616
--- Comment #1 from Michael Gorbovitski ---
> g++ prog.cc -Wall -Wextra
prog.cc:8:36: internal compiler error: Segmentation fault
8 | friend class friender::cls;
|^
0xb3 crash_signal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87616
Bug ID: 87616
Summary: Compiler segfaults on dependent templated friend
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566
--- Comment #8 from Paul Thomas ---
Fixed on trunk.
I am going back on my original intention to backport the recent patches to
8-branch. Or, rather, I will do them one at a time if at all. The trouble is
that an omnibus patch doesn't work for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87563
--- Comment #4 from Renlin Li ---
Author: renlin
Date: Mon Oct 15 16:49:05 2018
New Revision: 265172
URL: https://gcc.gnu.org/viewcvs?rev=265172=gcc=rev
Log:
[PR87563][AARCH64-SVE]: Don't keep ifcvt loop when COND_ ifn could not be
vectorized.
Hi,
here we ICE when, at the end of check_tag_decl we pass a DECLTYPE_TYPE
to warn_misplaced_attr_for_class_type. I think the right fix is
rejecting earlier a decltype with no declarator as a declaration that
doesn't declare anything (note: all the compilers I have at hand agree).
Tested
Committed as revision 265171.
Thanks to you, Dominique and, of course, Tobias.
Paul
On Mon, 15 Oct 2018 at 10:15, Thomas Koenig wrote:
>
> Hi Paul,
>
> > Bootstrapped and regtested on FC28/x86_64 - OK for trunk?
>
> Looks good. Thanks!
>
> Regards
>
> Thomas
--
"If you can't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566
--- Comment #7 from Paul Thomas ---
Author: pault
Date: Mon Oct 15 16:31:15 2018
New Revision: 265171
URL: https://gcc.gnu.org/viewcvs?rev=265171=gcc=rev
Log:
2018-10-15 Paul Thomas
Tobias Burnus
PR fortran/87566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615
Bug ID: 87615
Summary: Possible excessive compile time with -O2
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
On Mon, 15 Oct 2018 at 16:19, David Malcolm wrote:
>
> On Tue, 2018-09-18 at 02:33 +0200, Iain Buclaw wrote:
> > This patch adds the D front-end implementation, the only part of the
> > compiler that interacts with GCC directly, and being the parts that I
> > maintain, is something that I can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87572
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Mon Oct 15 16:08:09 2018
New Revision: 265169
URL: https://gcc.gnu.org/viewcvs?rev=265169=gcc=rev
Log:
PR target/87572
* common/config/i386/i386-common.c
On Mon, Oct 15, 2018 at 05:57:18PM +0200, Uros Bizjak wrote:
> On Mon, Oct 15, 2018 at 5:49 PM Uros Bizjak wrote:
>
> > > Plus, I wonder if we shouldn't make it harder to run into these issues, by
> > > changing
> > > Target Report Mask(ISA_AVX5124FMAPS) Var(ix86_isa_flags2) Save
> > > etc. to
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87562
Renlin Li changed:
What|Removed |Added
CC||renlin at gcc dot gnu.org
--- Comment #2
On Mon, Oct 15, 2018 at 5:49 PM Uros Bizjak wrote:
> > Plus, I wonder if we shouldn't make it harder to run into these issues, by
> > changing
> > Target Report Mask(ISA_AVX5124FMAPS) Var(ix86_isa_flags2) Save
> > etc. to
> > Target Report Mask(ISA2_AVX5124FMAPS) Var(ix86_isa_flags2) Save
> > so
On Mon, Oct 15, 2018 at 4:50 PM Jakub Jelinek wrote:
>
> On Mon, Oct 15, 2018 at 04:22:04PM +0200, Richard Biener wrote:
> > On Sun, Oct 14, 2018 at 9:29 PM Uros Bizjak wrote:
> > >
> > > On Sat, Oct 13, 2018 at 11:54 PM H.J. Lu wrote:
> > > >
> > > > Also disable AVX512IFMA, AVX5124FMAPS and
Hi Martin,
On 10/15/18 6:20 PM, Martin Sebor wrote:
On 10/15/2018 01:55 AM, Nikolai Merinov wrote:
Hi Martin,
On 10/12/18 9:58 PM, Martin Sebor wrote:
On 10/12/2018 04:14 AM, Nikolai Merinov wrote:
Hello,
In https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01795.html mail I
suggested patch to
Hi Rasmus,
> On 8 Oct 2018, at 15:03, Rasmus Villemoes wrote:
>
> fixincludes/
>
> * inclhack.def (AAB_vxworks_regs_vxtypes): Add unconditional
> include of vxCpu.h, guard include of vxTypesOld.h by
> !_ASMLANGUAGE.
> * fixincl.x: Regenerate.
Good for me, thanks.
Ping?
Best regards,
Thomas
On Fri, 5 Oct 2018 at 17:50, Thomas Preudhomme
wrote:
>
> Hi Ramana and Kyrill,
>
> I've reworked the patch to add some documentation of the option
> conflict and reworked the -mword-relocation logic slightly to set the
> variable explicitely in PIC mode rather than
On Mon, 15 Oct 2018, Richard Sandiford wrote:
> The patches therefore add a new "__sizeless_struct" keyword to denote
> structures that are sizeless rather than sized. Unlike normal
> structures, these structures can have members of sizeless type in
> addition to members of sized type. On the
On Mon, Oct 15, 2018 at 04:22:04PM +0200, Richard Biener wrote:
> On Sun, Oct 14, 2018 at 9:29 PM Uros Bizjak wrote:
> >
> > On Sat, Oct 13, 2018 at 11:54 PM H.J. Lu wrote:
> > >
> > > Also disable AVX512IFMA, AVX5124FMAPS and AVX5124VNNIW when disabling
> > > AVX512F.
> > >
> > > gcc/
> > >
> >
C Bergström writes:
> It could be the contribution process for gcc is an obstacle. I don't get
> involved with
In which case there's nothing to be done.
> those communities enough to know how well they do or don't play with
> upstream. In
> no way would I want to create extra unnecessary
This patch adds support for sizeless types to C, along the lines
described in the covering RFC. The patch is actually a squash
of 26 patches that I've attached as a tarball, with each patch
building up the support piece-by-piece. The individual patches
say which part of the standard they relate
This patch adds a bit to tree_type_common (which still has plenty
of bits spare) to indicate whether the type has a measurable size
at the language level once fully-defined.
2018-10-15 Richard Sandiford
gcc/
* tree-core.h (tree_type_common::sizeless): New bitfield.
This patch makes a couple of c-family macros use COMPLETE_TYPE_P instead
of TYPE_SIZE, so that the definitions more clearly correspond to the
names of the macros.
2018-10-15 Richard Sandiford
gcc/c-family/
* c-common.h (C_TYPE_OBJECT_P, C_TYPE_INCOMPLETE_P): Test
After previous patches there are no more uses of COMPLETE_TYPE_P outside
the frontends. This patch moves the definition to c-common.h.
2018-10-15 Richard Sandiford
gcc/
* tree.h (COMPLETE_TYPE_P): Move to c-common.h.
gcc/c-family/
* c-common.h (COMPLETE_TYPE_P): Moved from
complete_or_array_type_p was defined in tree.h but unused outside
the frontends. This patch moves it to c-common.h.
2018-10-15 Richard Sandiford
gcc/
* tree.h (complete_or_array_type_p): Move to c-common.h.
gcc/c-family/
* c-common.h (complete_or_array_type_p): Moved from
There was only one use of COMPLETE_OR_UNBOUND_ARRAY_TYPE_P outside the
frontends, in expr.c. This patch expands the macro there and moves the
macro's definition to c-common.h.
It feels a bit odd that we still have decls with no layout at
this late stage, but that's a separate issue...
There was only one use of this macro outside the frontends, in dbxout.c.
This patch expands that use and moves the macro's definition to c-common.h.
There's no expectation that dbx will support sizeless types,
so keeping the current definition should be fine.
2018-10-15 Richard Sandiford
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87614
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
This patch adds a DEFINITE_TYPE_P macro for testing whether a
type has been fully-defined. The definition is the same as the
current definition of COMPLETE_TYPE_P, but later patches redefine
COMPLETE_TYPE_P and make it local to the C and C++ frontends.
The name "definite type" comes from the SVE
Hi Jeffrey,
> On Mon, Oct 15, 2018 at 10:13 AM C Bergström wrote:
>>
>> Is there anyone in the *open* solaris or variant camp who may be impacted
>> by this? SOL10 gets deprecated and I doubt anyone will really cry fowl, but
>> can it negatively impact any of the similar open source projects
Some tests for COMPLETE_TYPE_P are just protecting against a null
TYPE_SIZE or TYPE_SIZE_UNIT. Rather than replace them with a new
macro, it seemed clearer to write out the underlying test.
2018-10-15 Richard Sandiford
gcc/
* calls.c (initialize_argument_information): Replace
The C standard says:
At various points within a translation unit an object type may be
"incomplete" (lacking sufficient information to determine the size of
objects of that type) or "complete" (having sufficient information).
For AArch64 SVE, we'd like to split this into two
It could be the contribution process for gcc is an obstacle. I don't get
involved with those communities enough to know how well they do or don't
play with upstream. In no way would I want to create extra unnecessary work
for you, but if you really care maybe ping them to see if anyone could help
On Mon, Oct 15, 2018 at 10:13 AM C Bergström wrote:
>
> Is there anyone in the *open* solaris or variant camp who may be impacted
> by this? SOL10 gets deprecated and I doubt anyone will really cry fowl, but
> can it negatively impact any of the similar open source projects that may
> identify at
ping
On 27/09/18 14:43, Matthew Malcomson wrote:
[PATCH][GCC][AARCH64] Introduce aarch64 atomic_{load,store}ti patterns
In Armv8.4-a these patterns use the LDP/STP instructions that are guaranteed to
be single-copy atomic, ensure correct memory ordering semantics by using
the DMB instruction.
On Fri, 12 Oct 2018 at 13:45, Richard Earnshaw (lists)
wrote:
>
> On 11/10/18 14:34, Christophe Lyon wrote:
> > 2018-XX-XX Christophe Lyon
> > Mickaël Guêné
> >
> > gcc/
> > * config/arm/arm.c (arm_compute_save_reg0_reg12_mask): Handle
> > FDPIC.
> >
On Sun, Oct 14, 2018 at 9:29 PM Uros Bizjak wrote:
>
> On Sat, Oct 13, 2018 at 11:54 PM H.J. Lu wrote:
> >
> > Also disable AVX512IFMA, AVX5124FMAPS and AVX5124VNNIW when disabling
> > AVX512F.
> >
> > gcc/
> >
> > PR target/87572
> > * common/config/i386/i386-common.c
On Tue, 2018-09-18 at 02:33 +0200, Iain Buclaw wrote:
> This patch adds the D front-end implementation, the only part of the
> compiler that interacts with GCC directly, and being the parts that I
> maintain, is something that I can talk about more directly.
>
> For the actual code generation
C Bergström writes:
> Is there anyone in the *open* solaris or variant camp who may be impacted by
> this?
> SOL10 gets deprecated and I doubt anyone will really cry fowl, but can it
> negatively
> impact any of the similar open source projects that may identify at SOL10,
> but not
> be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87614
Bug ID: 87614
Summary: User related warnings are hidden in system headers
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
On Fri, 12 Oct 2018 at 13:37, Richard Earnshaw (lists) <
richard.earns...@arm.com> wrote:
> On 11/10/18 14:34, Christophe Lyon wrote:
> > The main difference with existing support is that function addresses
> > are function descriptor addresses instead. This means that all code
> > dealing with
Is there anyone in the *open* solaris or variant camp who may be impacted
by this? SOL10 gets deprecated and I doubt anyone will really cry fowl, but
can it negatively impact any of the similar open source projects that may
identify at SOL10, but not be exactly the same... Thoughts?
On Mon, Oct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87613
Bug ID: 87613
Summary: Non-reachable default required in switch statement to
get optimal code
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
On Mon, 15 Oct 2018, Robin Dapp wrote:
> * haifa-sched.c (priority): Add force_recompute parameter.
> (apply_replacement):
> Call priority () with force_recompute = true.
> (restore_pattern): Likewise.
A C++ style nit/question: instead of adding a new overload
priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84648
Richard Biener changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment
> > I think only double quote, backslash, backtick remain unclaimed. And of
> > course
> > ASCII \0 through \040 and \177 ;)
>
> I see. Apart from using some of the traditional begin-end sequences we
> could use %; or similar on each line to "comment" it?
I guess in theory we could define
Solaris 10 is reaching the end of its support live, as can be seen in
the following overview based on
http://www.oracle.com/us/support/library/lsp-coverage-sun-software-309122.pdf,
p.29:
ReleaseGA Date Last Premier Extended GCC
Update Support Support Obsoletion
1 - 100 of 176 matches
Mail list logo
