On Tue, Mar 19, 2019 at 11:03 AM Martin Liška wrote:
>
> What's Joseph telling is that right now the patch can't be approved (and
> installed).
> It's due to fact that we are close to the release in stage4:
> https://www.gnu.org/software/gcc/develop.html#stage4
>
> So that a proper review will ha
From: Manuel López-Ibáñez
* opts.c: Ignore -Wno-error= except if there are
other diagnostics.
---
gcc/opts-common.c | 2 ++
gcc/opts-global.c | 10 +++---
gcc/opts.c| 5 -
gcc/opts.h| 2 ++
4 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/gcc/opts-common
---
gcc/testsuite/c-c++-common/pr65403-1.c | 10 ++
gcc/testsuite/c-c++-common/pr65403-2.c | 15 +++
2 files changed, 25 insertions(+)
create mode 100644 gcc/testsuite/c-c++-common/pr65403-1.c
create mode 100644 gcc/testsuite/c-c++-common/pr65403-2.c
diff --git a/gcc/testsui
On Tue, Mar 19, 2019 at 11:26 AM Martin Sebor wrote:
>
> Please remember to quote the command line options in the message
> (same as in the error below):
I'll send a new version. Thanks for the feedback!
-Alex
On 3/19/19 8:22 PM, Joseph Myers wrote:
> On Tue, 19 Mar 2019, Jeff Law wrote:
>
>> I'll note that our documentation clearly states that attributes can be
>> applied to functions, variables, labels, enums, statements and types.
>
> A key thing here is that they can be applied to fields - that is,
Hi,
Please refer to below link for previous threads.
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00348.html
Comparing to patch v2, I've moved up the vector operation target
check upward together with vector type target check. Besides, I
ran bootstrap and regtest on powerpc64-linux-gnu (BE), u
On Tue, 19 Mar 2019, Jeff Law wrote:
> I'll note that our documentation clearly states that attributes can be
> applied to functions, variables, labels, enums, statements and types.
A key thing here is that they can be applied to fields - that is, they can
be properties of a FIELD_DECL. Referri
I have committed attached patch to aarch64/sve-acle-branch branch
which implements svbic.
Thanks,
Kugan
From 182bd15334874844bef5e317f55a6497f77e12ff Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah
Date: Thu, 24 Jan 2019 20:57:19 +1100
Subject: [PATCH 1/3] svbic
Change-Id: I819490ec63ee38b
Hi all,
the attached one-line patch fixes an ICE-on-invalid regression with
abstract interfaces. Regtests cleanly on x86_64-linux-gnu. Ok for
trunk and the release branches (7 and 8)?
Cheers,
Janus
diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index 4dd35ec6030..cee2b2cfd15 100644
--
This fixes the bug reported in PR 89411 where we accidentally generated a
%lo with an offset that overflowed at link time if the symbol was allocated
to an address just below the 2KB limit for %lo. This solves the problem
by checking for BLKmode references, pulling out the SYMBOL_REF_DECL, and
the
On 3/19/19 12:42 PM, Jeff Law wrote:
On 3/14/19 7:47 PM, Martin Sebor wrote:
To copy type attributes from struct A, the copy attribute (new
in GCC 9) accepts a pointer argument such as (struct A*)0, but
it isn't prepared for anything much more complicated than that.
So for example when it's pass
On 3/19/19 4:57 PM, Ed Smith-Rowland via libstdc++ wrote:
On 3/18/19 6:18 PM, Jonathan Wakely wrote:
On 17/03/19 22:54 -0400, Ed Smith-Rowland via libstdc++ wrote:
Greetings,
This patch implements C++20 p0202 - Add Constexpr Modifiers to
Functions in and Headers
and C++20 p1023 - constexp
On 3/19/19 12:30 PM, Jeff Law wrote:
On 2/22/19 9:42 AM, Marek Polacek wrote:
On Thu, Feb 21, 2019 at 03:39:21PM -0700, Martin Sebor wrote:
On 2/21/19 1:27 PM, Jeff Law wrote:
On 2/21/19 1:12 PM, Martin Sebor wrote:
On 2/21/19 12:08 PM, Jeff Law wrote:
On 2/18/19 7:53 PM, Martin Sebor wrote:
Hi Jan,
> these two PRs are about C++ destructors that are not virtual but have
> virtual alias. The devirtualization machinery walks from alias to symbol
> and is then confused by not knowing the class symbol belongs to.
>
> I think it would make more sense to avoid these walks but that require
>
On 3/18/19 6:18 PM, Jonathan Wakely wrote:
On 17/03/19 22:54 -0400, Ed Smith-Rowland via libstdc++ wrote:
Greetings,
This patch implements C++20 p0202 - Add Constexpr Modifiers to
Functions in and Headers
and C++20 p1023 - constexpr comparison operators for std::array.
The patch is large
On 3/5/19 3:40 PM, Jakub Jelinek wrote:
> On Tue, Mar 05, 2019 at 05:33:45PM -0500, Jason Merrill wrote:
>> The x86_64 psABI says that an empty class isn't passed or returned in memory
>> or registers, so we shouldn't set %eax in this function. This seems like a
>> missed case from the GCC 8 TYPE_
On 3/19/19 9:00 AM, Florian Weimer wrote:
> * Florian Weimer:
>
>> * Jeff Law:
>>
>>> On 03/29/2018 08:00 AM, Florian Weimer wrote:
This patch performs lazy initialization of the relevant CPUID feature
register value. It will needlessly invoke the CPUID determination code
on archit
On 2/28/19 5:26 AM, JiangNing OS wrote:
> To solve BZ89430 the followings are needed,
>
> (1) The code below in noce_try_cmove_arith needs to be fixed.
>
> /* ??? We could handle this if we knew that a load from A or B could
> not trap or fault. This is also true if we've already loaded
>
On 11/03/19 21:24 -0700, Thomas Rodgers wrote:
Let's try this patch -
The feature test macro should be 201603L (in and
):
+// Feature test macro for parallel algorithms
+# define __cpp_lib_parallel_algorithm 201703L
***
The new files have copyright dates of 2018, but it's taken so long to
On 3/6/19 3:05 AM, Richard Biener wrote:
> On Tue, Mar 5, 2019 at 10:36 PM Jeff Law wrote:
>>
>> On 3/5/19 7:44 AM, Richard Biener wrote:
>>
>>> So fixing it properly with also re-optimize_stmt those stmts so we'd CSE
>>> the MAX_EXPR introduced by folding makes it somewhat ugly.
>>>
>>> Bootstrap
On 3/19/19 11:54 AM, Jakub Jelinek wrote:
> Hi!
>
> On the testcase in the PR we ICE because we create non-canonical CONST_INTs
> (e.g. for HImode niter 0xfffe) and the compare_and_jump_seq code then ICEs
> on that.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
>
On 3/13/19 8:17 PM, Martin Sebor wrote:
> PR 89688 points out a bogus warning about an unterminated
> character array argument to strlen. The root cause is
> an oversight in the transformation of braced initializer lists
> to STRING_CSTs where the solution implemented last summer only
> considers
On 3/19/19 2:00 PM, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, BLKmode operands (such as in the testcase C++
variables with TREE_ADDRESSABLE types) may only live in a MEM, trying to
reload those in a register will always ICE. process_alt_operands already
has if (mode == BLKmode) break; in
This patch by Cherry Zhang changes the Go frontend and libgo to pass
the old slice's ptr/len/cap by value to growslice. In the C calling
convention, on AMD64, and probably a number of other architectures, a
3-word struct argument is passed on stack. This is less efficient
than passing in three re
On 3/14/19 7:47 PM, Martin Sebor wrote:
> To copy type attributes from struct A, the copy attribute (new
> in GCC 9) accepts a pointer argument such as (struct A*)0, but
> it isn't prepared for anything much more complicated than that.
> So for example when it's passed something like (struct A*)(0,
On 3/19/19 12:37 PM, Martin Sebor wrote:
> On 3/19/19 12:01 PM, Martin Sebor wrote:
>> On 3/19/19 8:33 AM, Jeff Law wrote:
>>> On 3/11/19 8:27 PM, Martin Sebor wrote:
The -Wstringop-truncation handling for strncpy/stpncpy neglects
to consider that character arrays tracked by the strlen pa
On 3/19/19 12:01 PM, Martin Sebor wrote:
> On 3/19/19 8:33 AM, Jeff Law wrote:
>> On 3/11/19 8:27 PM, Martin Sebor wrote:
>>> The -Wstringop-truncation handling for strncpy/stpncpy neglects
>>> to consider that character arrays tracked by the strlen pass
>>> are not necessarily nul-terminated. It
On 3/19/19 12:01 PM, Martin Sebor wrote:
On 3/19/19 8:33 AM, Jeff Law wrote:
On 3/11/19 8:27 PM, Martin Sebor wrote:
The -Wstringop-truncation handling for strncpy/stpncpy neglects
to consider that character arrays tracked by the strlen pass
are not necessarily nul-terminated. It unconditional
On 2/22/19 9:42 AM, Marek Polacek wrote:
> On Thu, Feb 21, 2019 at 03:39:21PM -0700, Martin Sebor wrote:
>> On 2/21/19 1:27 PM, Jeff Law wrote:
>>> On 2/21/19 1:12 PM, Martin Sebor wrote:
On 2/21/19 12:08 PM, Jeff Law wrote:
> On 2/18/19 7:53 PM, Martin Sebor wrote:
>> Please let me kn
On March 19, 2019 6:54:33 PM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>On the testcase in the PR we ICE because we create non-canonical
>CONST_INTs
>(e.g. for HImode niter 0xfffe) and the compare_and_jump_seq code then
>ICEs
>on that.
>
>Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-
Hi!
add_capture when parsing a lambda introducer uses the IDENTIFIER_MARKED
bit to detect duplicate captures.
I guess in strict C++11 that could have worked, if the introducer could
contain just identifiers, but in C++14 it has 2 problems:
1) lambda initializers can contain arbitrary expressions
On 3/19/19 8:33 AM, Jeff Law wrote:
On 3/11/19 8:27 PM, Martin Sebor wrote:
The -Wstringop-truncation handling for strncpy/stpncpy neglects
to consider that character arrays tracked by the strlen pass
are not necessarily nul-terminated. It unconditionally adds
one when computing the size of eac
Hi!
As mentioned in the PR, BLKmode operands (such as in the testcase C++
variables with TREE_ADDRESSABLE types) may only live in a MEM, trying to
reload those in a register will always ICE. process_alt_operands already
has if (mode == BLKmode) break; in it, so that it never claims a BLKmode
wins
Hi!
On the testcase in the PR we ICE because we create non-canonical CONST_INTs
(e.g. for HImode niter 0xfffe) and the compare_and_jump_seq code then ICEs
on that.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
Testcase not included, because it creates 48
On 2/25/19 2:07 AM, Eric Botcazou wrote:
> Hi,
>
> this is a regression present on the mainline and 8 branch, introduced by the
> new code in edge_info::derive_equivalences dealing with BIT_AND_EXPR for SSA
> names with boolean range:
>
> /* If either operand has a boolean range, th
On 3/18/19 8:46 PM, Alex Henrie wrote:
From: Manuel López-Ibáñez
* opts.c: Ignore -Wno-error= except if there are
other diagnostics.
---
gcc/opts-common.c | 2 ++
gcc/opts-global.c | 10 +++---
gcc/opts.c| 5 -
gcc/opts.h| 2 ++
4 files changed, 15 insertions(+)
On 3/19/19 3:52 PM, Jakub Jelinek wrote:
> On Tue, Mar 19, 2019 at 09:02:27AM +0100, Martin Liška wrote:
>> 2019-03-18 Martin Liska
>>
>> PR middle-end/89737
>> * predict.c (combine_predictions_for_bb): Empty likely_edges and
>> unlikely_edges if there's an edge that belongs to bo
On 3/19/19 5:35 PM, Alex Henrie wrote:
> On Tue, Mar 19, 2019 at 3:19 AM Martin Liška wrote:
>>
>> On 3/19/19 3:46 AM, Alex Henrie wrote:
>>> Hello,
>>>
>>> I have received permission to contribute to GCC, but I do not have
>>> commit access. Could one of you please merge these patches for me?
>>
On 3/19/19 3:37 PM, Jeff Law wrote:
> On 3/8/19 5:34 AM, Martin Liška wrote:
>> A small patch that deals with:
>> gcc/config/i386/i386.c:39427:11:Semantic Issue: comparison of two values
>> with different enumeration types in switch statement ('enum
>> built_in_function' and 'ix86_builtins'): -We
On Tue, Mar 19, 2019 at 04:26:18PM +, Segher Boessenkool wrote:
> The "classic" PowerPCs (6xx/7xx) are not STRICT_ALIGNMENT, but their
> floating point units are. This is not normally a problem, the ABIs
> make everything FP aligned. The RTL patterns converting FP to integer
> however get a p
On Tue, Mar 19, 2019 at 3:19 AM Martin Liška wrote:
>
> On 3/19/19 3:46 AM, Alex Henrie wrote:
> > Hello,
> >
> > I have received permission to contribute to GCC, but I do not have
> > commit access. Could one of you please merge these patches for me?
>
> Hi.
>
> I can do it for you. But if I see
The "classic" PowerPCs (6xx/7xx) are not STRICT_ALIGNMENT, but their
floating point units are. This is not normally a problem, the ABIs
make everything FP aligned. The RTL patterns converting FP to integer
however get a potentially unaligned destination, and we do not want to
do an stfiwx on that
Ping?
> On 5 Mar 2019, at 20:43, Simon Wright wrote:
>
> Arno,
>
> OK.
>
> --S
>
>> On 5 Mar 2019, at 20:38, Arnaud Charlet wrote:
>>
>> Simon,
>>
>> Thanks for the patch.
>> We already have a fix pending for that in our tree that we will merge.
>>
>> Arno
>>
>>> On 4 Mar 2019, at 20:48,
On Thu, Mar 14, 2019 at 04:22:41PM -0400, Jason Merrill wrote:
> On 3/7/19 4:52 PM, Marek Polacek wrote:
> > This was one of those PRs where the more you poke, the more ICEs turn up.
> > This patch fixes the ones I could find. The original problem was that
> > maybe_instantiate_noexcept got a TEMP
> This would mean that StructFlags and ClassFlags will also both have a
> wrong value as well.
Yes, can confirm that m_flags = 0 (instead of 1) for a struct containing
a pointer.
> If there's a compiler/library discrepancy, the compiler should be
> adjusted to write out the value at the correct s
* Florian Weimer:
> * Jeff Law:
>
>> On 03/29/2018 08:00 AM, Florian Weimer wrote:
>>> This patch performs lazy initialization of the relevant CPUID feature
>>> register value. It will needlessly invoke the CPUID determination code
>>> on architectures which lack CPUID support or support for the
On Tue, 19 Mar 2019, Martin Liška wrote:
> On 3/19/19 3:46 AM, Alex Henrie wrote:
> > Hello,
> >
> > I have received permission to contribute to GCC, but I do not have
> > commit access. Could one of you please merge these patches for me?
>
> Hi.
>
> I can do it for you. But if I see correctly,
On 3/18/19 10:31 PM, JonY wrote:
> On 3/3/19 10:41 AM, Johannes Pfau wrote:
>> We set __USE_MINGW_ACCESS for windows hosts to use MinGWs wrapper
>> for the access function. The wrapper ensures that access behaves
>> in the expected way (e.g. for special files, such as nul).
>> However, we now compi
On Tue, Mar 19, 2019 at 09:02:27AM +0100, Martin Liška wrote:
> 2019-03-18 Martin Liska
>
> PR middle-end/89737
> * predict.c (combine_predictions_for_bb): Empty likely_edges and
> unlikely_edges if there's an edge that belongs to both these sets.
I admit I don't know this co
> On 3/19/19 2:02 AM, Martin Liška wrote:
> > Hi.
> >
> > When calling set_even_probabilities, the function assumes that an edge
> > can't live in both sets ({un,}likely_edges). When such situation happens,
> > clear just the sets.
> >
> > Patch can bootstrap on x86_64-linux-gnu and survives regr
On 3/14/19 4:43 AM, Richard Biener wrote:
> On Wed, 13 Mar 2019, Richard Biener wrote:
>
>> On Wed, 13 Mar 2019, Bin.Cheng wrote:
>>
>>> On Wed, Mar 13, 2019 at 3:58 AM Richard Biener wrote:
This makes an attempt at fixing the most annoying parts of the GIMPLE
FE unit testing
On 3/14/19 7:52 AM, Jakub Jelinek wrote:
> Hi!
>
> On the gcc.dg/vect/pr88598-3.c testcase, gen_vec_extract... is called with
> operands[1] that is already a subreg - (subreg:V4SF (reg:V4SI 201 [ _31 ]) 0)
> and wraps it in another SUBREG, which is invalid in RTL.
>
> In all the following 4 spots
On 3/19/19 2:02 AM, Martin Liška wrote:
> Hi.
>
> When calling set_even_probabilities, the function assumes that an edge
> can't live in both sets ({un,}likely_edges). When such situation happens,
> clear just the sets.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
On 3/8/19 5:34 AM, Martin Liška wrote:
> A small patch that deals with:
> gcc/config/i386/i386.c:39427:11:Semantic Issue: comparison of two values with
> different enumeration types in switch statement ('enum built_in_function' and
> 'ix86_builtins'): -Wenum-compare-switch
>
> Is it fine to inst
On 3/11/19 8:27 PM, Martin Sebor wrote:
> The -Wstringop-truncation handling for strncpy/stpncpy neglects
> to consider that character arrays tracked by the strlen pass
> are not necessarily nul-terminated. It unconditionally adds
> one when computing the size of each sequence to account for
> the
A recently added test was observed to fail when compiled without the -mvsx
option. This patch adds -mvsx to the dg-options directive.
Was boostrapped and regression tested on powerpc-linux (P7 big-endian, both
-m32 and -m64).
Was preapproved by seg...@gcc.gnu.org and has been merged with trunk
This patch by Clément Chigot fixes the AIX support after the update to
Go 1.12. Bootstrapped and ran Go tests on x86_64-pc-linux-gnu.
Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revi
Hi,
I'd like to ping for this patch:
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00438.html
Thanks
Bernd.
On 3/10/19 10:42 AM, Bernd Edlinger wrote:
> Hi,
>
> This patch is an update to the previous patch, which takes into account that
> the middle-end is not supposed to use the unaligned DI
On Tue, 19 Mar 2019 at 13:07, Robin Dapp wrote:
>
> Hi,
>
> > Alignment is written to TypeInfo, I don't think it should ever be
> > zero. That would mean that it isn't being generated by the compiler,
> > or read by the library correctly, so something else is amiss.
>
> it took me a while to see
On March 19, 2019 1:07:26 PM GMT+01:00, Robin Dapp wrote:
>Hi,
>
>> Alignment is written to TypeInfo, I don't think it should ever be
>> zero. That would mean that it isn't being generated by the compiler,
>> or read by the library correctly, so something else is amiss.
>
>it took me a while to s
Hi,
> Alignment is written to TypeInfo, I don't think it should ever be
> zero. That would mean that it isn't being generated by the compiler,
> or read by the library correctly, so something else is amiss.
it took me a while to see that in libphobos/libdruntime/object.d
override @property siz
On Tue, 19 Mar 2019 08:47:49 +
Richard Sandiford wrote:
> > ... this identical condition, AFAICS?
> > So this second conditions else arm should be dead, shouldn't it?
>
> Yeah, that's what:
>
> /* ??? The "if" arm is written to handle all cases; see below for what
> we would do for
On Tue, 19 Mar 2019, Michael Matz wrote:
> Hi,
>
> On Tue, 19 Mar 2019, Richard Biener wrote:
>
> > It doesn't really. Consider the following IMHO valid testcase:
> >
> > enum X { A, B };
> > enum Y { C, D };
> > void foo (int *p)
> > {
> > *(enum X *)p = A;
> > *(enum Y *)p = D;
> > return
The following ignores -gsplit-dwarf when doing LTO since its model
seems to be fundamentally incompatible, see my last comment in the
now suspended PR.
Bootstrap & regtest running on x86_64-unknown-linux-gnu, I'll apply
this to trunk and GCC 8 branch.
Richard.
2019-03-19 Richard Biener
On Tue, Mar 19, 2019 at 3:56 AM Jakub Jelinek wrote:
>
> On Mon, Mar 18, 2019 at 06:35:12PM -0600, James Hilliard wrote:
> > On Mon, Mar 18, 2019 at 5:46 PM Jeff Law wrote:
> > >
> > > On 3/18/19 5:07 PM, James Hilliard wrote:
> > > > On Mon, Mar 18, 2019 at 4:51 PM Jakub Jelinek wrote:
> > > >>
On 04/03/2019 09:04, Jakub Jelinek wrote:
> On Fri, Mar 01, 2019 at 03:41:33PM +, Wilco Dijkstra wrote:
>> > and regtest revealed two code size
>> > regressions because of that. Is -1 vs. 1 the only case of immediate
>> > valid for both "I" and "L" constraints where the former is longer than t
On Mon, Mar 18, 2019 at 06:35:12PM -0600, James Hilliard wrote:
> On Mon, Mar 18, 2019 at 5:46 PM Jeff Law wrote:
> >
> > On 3/18/19 5:07 PM, James Hilliard wrote:
> > > On Mon, Mar 18, 2019 at 4:51 PM Jakub Jelinek wrote:
> > >>
> > >> On Mon, Mar 18, 2019 at 04:41:05PM -0600, James Hilliard wro
* doc/xml/manual/allocator.xml: Link to table documenting evolution
of extension allocators.
* doc/xml/manual/evolution.xml: Use angle brackets for header names.
Document new headers in 7.2, 8.1 and 9.1 releases.
* doc/xml/manual/using.xml: Adjust link targe
Hi,
On Tue, 19 Mar 2019, Richard Biener wrote:
> It doesn't really. Consider the following IMHO valid testcase:
>
> enum X { A, B };
> enum Y { C, D };
> void foo (int *p)
> {
> *(enum X *)p = A;
> *(enum Y *)p = D;
> return *(enum X *)p;
> }
>
> int main()
> {
> int storage;
> if (foo
On 3/19/19 3:46 AM, Alex Henrie wrote:
> Hello,
>
> I have received permission to contribute to GCC, but I do not have
> commit access. Could one of you please merge these patches for me?
Hi.
I can do it for you. But if I see correctly, Joseph M. had some concerns
and he should probably make fin
Bernhard Reutner-Fischer writes:
> On 18 March 2019 10:58:53 CET, Richard Sandiford
> wrote:
>>This patch fixes a case in which we vectorised something with a
>>fully-predicated loop even after the cost model had rejected it.
>>E.g. the loop in the testcase has the costs:
>>
>> Vector inside of
From: Mingli Yu
Initialize st_mode member to fix the below
build failure when -Og included in compiler flag.
|
./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:
In function 'elf_is_symlink':
|
../../../../../../../../../work-shared
On Mon, Mar 18, 2019 at 10:31 PM Jeff Law wrote:
>
> On 3/18/19 1:03 PM, Martin Sebor wrote:
> > I the -Warray-bounds enhancement committed at the beginning
> > of the GCC 9 window I tried to correctly handle offsets in
> > MEM_REFs in the [max, min] kind of a range after converting
> > from sizet
On Mon, 18 Mar 2019, Michael Matz wrote:
> Hi,
>
> On Mon, 18 Mar 2019, Richard Biener wrote:
>
> > > Or, because an enum with these properties could be modelled as a struct
> > > containing one member of basetype you could also change
> > > record_component_aliases(), though that doesn't allo
Hi.
When calling set_even_probabilities, the function assumes that an edge
can't live in both sets ({un,}likely_edges). When such situation happens,
clear just the sets.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
On Mon, 18 Mar 2019, Jan Hubicka wrote:
> Hi,
> these two PRs are about C++ destructors that are not virtual but have
> virtual alias. The devirtualization machinery walks from alias to symbol
> and is then confused by not knowing the class symbol belongs to.
>
> I think it would make more sense
On Mon, 18 Mar 2019, Jakub Jelinek wrote:
> Hi!
>
> For input arguments, we do:
> /* If we can't make copies, we can only accept memory. */
> if (TREE_ADDRESSABLE (TREE_TYPE (TREE_VALUE (link
> {
> if (allows_mem)
> allows_reg = 0;
> else
>
On Tue, Mar 12, 2019 at 12:43:29PM +0100, Jakub Jelinek wrote:
> On Mon, Mar 04, 2019 at 10:04:01AM +0100, Jakub Jelinek wrote:
> > The first one uses constraints and no C code in the output, I believe it is
> > actually more expensive for compile time, because if one just reads what
> > constrain_
On Fri, Mar 15, 2019 at 9:46 PM Jakub Jelinek wrote:
>
> Hi!
>
> As the enhanced testcase shows, ix86_expand_floorceildf_32 doesn't emit
> correct ceil when honoring signed zeros, because it performs copysign,
> then comparison and then based on the comparison an optional addition of 1.
> The comm
79 matches
Mail list logo
