On Fri, 21 Dec 2018, Richard Biener wrote:
>
> It looks like IPA ICF does code generation based on the order of
> a hahstable walk which is keyed on pointers. That's a no-no.
> Fixing that doesn't solve the cc1 miscompare for LTO bootstrap
> but at least the IPA ICF WPA dumps are now consistent
On Sun, Dec 30, 2018 at 12:51 PM Jozef Lawrynowicz
wrote:
>
> There have been some ICEs in the past for msp430-elf with the large
> memory model (20-bit pointers), caused by SET_{DECL,TYPE}_ALIGN being called
> with an argument which resolves to 20 i.e. POINTER_SIZE,
> or the default value of TARG
On Thu, Dec 27, 2018 at 3:59 PM Segher Boessenkool
wrote:
>
> Hi!
>
> I'd like to backport the "asm inline" series to 8 branch and 7 branch.
> The patches are identical to trunk, except I added a patch 8/8 that
> makes these branches not error on code it only warned on before (that
> is, C code th
On Wed, Jan 2, 2019 at 10:09 AM Richard Biener
wrote:
>
> On Thu, Dec 27, 2018 at 3:59 PM Segher Boessenkool
> wrote:
> >
> > Hi!
> >
> > I'd like to backport the "asm inline" series to 8 branch and 7 branch.
> > The patches are identical to trunk, except I added a patch 8/8 that
> > makes these
On Wed, Jan 02, 2019 at 12:15:53AM +0100, Jan Hubicka wrote:
> > /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/tree-prof/devirt.C:99:26:
> > optimized: folding virtual function call to virtual unsigned int
> > mozPersonalDictionary::_ZThn8_N21mozPersonalDictionary6AddRefEv()
> >
> > > Is ther
> On Wed, Jan 02, 2019 at 12:15:53AM +0100, Jan Hubicka wrote:
> > > /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/tree-prof/devirt.C:99:26:
> > > optimized: folding virtual function call to virtual unsigned int
> > > mozPersonalDictionary::_ZThn8_N21mozPersonalDictionary6AddRefEv()
> > >
> >
Hi!
On the following testcase we ICE, because pushdecl* ggc_frees the decl
passed to it, but builtin_function_1 returns it anyway.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2019-01-02 Jakub Jelinek
PR c++/88636
* decl.c (builtin_functi
On 01/01/19 09:45 +0400, Joel Brobecker wrote:
Hello,
In working on updating the copyright year notices for the GDB files,
I noticed something very minor regarding the patch which added the
file below (the same file was copied in gdb's testsuite); it looks
like the year range for one of the file
Hi Steve,
Due to the nuances of issuing error messages with ieee_selected_real_kind
when used in an initialization expression, it became painfully obvious
that gfortran will often issue an "Unclassifiable statement" error
as a run-on error. I tried to make the "Unclassifiable ..." error a
fatal
This adjusts intel costs to reflect other intel CPU costs in _one_ place
to fix PR87545. But I noted that -mtune=intel lacks any common sense
so please intel folks do your homework.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2019-01-02 Richard Biener
PR
Hi.
Following patch moves a probability calculation to a place where
it's really used. Otherwise one can end up with division by zero
that can't happen as there's no edge for which the probability
would be used.
Patch survives tests on x86_64-linux-gnu and bootstrap fine.
Ready for trunk?
Thanks
Hi Kyrill,
> >
> > Bootstrap and Regtest on aarch64-none-linux-gnu, arm-none-gnueabihf
> > and x86_64-pc-linux-gnu are still on going but previous patch showed no
> regressions.
> >
>
> Did the testing go okay in the end?
Yes it was clean.
> This looks ok to me but can you provide an example, o
Hi,
Ping^4 ?
Thanks,
Christophe
On Tue, 11 Dec 2018 at 11:27, Christophe Lyon wrote:
>
> Ping?
>
>
> On 03/12/2018 10:19, Christophe Lyon wrote:
> > Ping?
> >
> > The series started here:
> > https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01464.html
> >
> > Thanks,
> >
> > Christophe
> >
> >
On 12/28/18 12:24 PM, Sudakshina Das wrote:
> Hi Martin
>
> On 27/12/18 12:32 PM, Martin Liška wrote:
>> On 11/20/18 11:58 AM, Martin Liška wrote:
>>> On 10/3/18 11:23 AM, Martin Liška wrote:
On 9/25/18 8:48 AM, Martin Liška wrote:
> Hi.
>
> One more tested patch.
>
> Mart
Honza: PING
On 12/6/18 12:16 AM, Qing Zhao wrote:
> Hi, Honza,
>
> I have one question relate to whether to disable nothrow for -flive-patching
> as following:
>
> actually, there are two passes here:
>
> 1. local nothrow pass: in this pass, nothrow attribute is set locally after
> analyzing
>
> Honza, in order to make the test working I would need to backport
> r267495. Is it a good idea?
Yes, my apologies for the mistake! I should stop looking for failures
via grep and use test_summary consistently since I tend to miss
unresolved tests. Old habits are hard to change.
Honza
>
> T
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2019-01-02 Richard Biener
PR tree-optimization/88621
* tree-ssa-loop-im.c (gather_mem_refs_stmt): Fix pastos, avoid
bitfields when canoncalizing.
* gcc.dg/torture/pr88621.c: New testcase.
Hi Martin,
> The PR is about a function (__tls_init) that ends before it begins
> (from line point of view). The patch uses location of a variable where
> we first create the function declaration. I'm not much familiar with C++ FE,
> but it works.
>
> Survives bootstrap and regression test on ppc6
Hi Thomas, Happy New Year,
On 2018/12/19 5:03 AM, Thomas Schwinge wrote:
+
+ if (!dev->openacc.async.asyncqueue[async])
+{
+ dev->openacc.async.asyncqueue[async] = dev->openacc.async.construct_func
();
+
+ if (!dev->openacc.async.asyncqueue[async])
+ {
+ gomp_mutex_
On 1/2/19 1:41 PM, Rainer Orth wrote:
> Hi Martin,
>
>> The PR is about a function (__tls_init) that ends before it begins
>> (from line point of view). The patch uses location of a variable where
>> we first create the function declaration. I'm not much familiar with C++ FE,
>> but it works.
>>
>
Gerald Pfeifer writes:
> On Fri, 23 Nov 2018, Tom de Vries wrote:
>> When building libbacktrace, we typically use elf.c, and don't build
>> pecoff.c, xcoff.c or unknown.c
>>
>> Add testcases that use unused format to ensure that we also build and
>> test those on a typical development setup.
>
On 12/30/18 12:41 AM, Martin Jambor wrote:
> Any comments welcome,
Hi Martin.
I'll run smoke test for OBS Factory with -flto flags enabled for the patch.
So far I've noticed that current trunk can't profilebootstrap with following
configuration:
$ ../configure --enable-languages=c,c++,d --disabl
> On 2 Jan 2019, at 13:20, Rainer Orth wrote:
>
> Gerald Pfeifer writes:
>
>> On Fri, 23 Nov 2018, Tom de Vries wrote:
>>> When building libbacktrace, we typically use elf.c, and don't build
>>> pecoff.c, xcoff.c or unknown.c
>>>
>>> Add testcases that use unused format to ensure that we al
Hi Iain,
> The c-c++-common tests fail (or XPASS depending on which) on Darwin
> because it doesn't currently emit .ident marker.
>
> For powerpc darwin (and, I think, AIX - hence copying David), there’s no
> .ident support in the assembler, and we need to skip the tests.
>
> In this case, I sugg
The following should fix PR88651 (don't have UBSAN GCC to verify).
We mangle HWI max_stmt_execution result in ways not considering
overflow but max_stmt_execution can return quite large numbers.
The following switches the code over to widest_ints.
Bootstrapped and tested on x86_64-unknown-linux
On Wed, Jan 2, 2019 at 12:14 PM Martin Liška wrote:
>
> Hi.
>
> Following patch moves a probability calculation to a place where
> it's really used. Otherwise one can end up with division by zero
> that can't happen as there's no edge for which the probability
> would be used.
>
> Patch survives t
Hello world,
the attached patch fixes the PR, a regression introduced by r265649,
by special-casing those intrinsics of the min/max family which
need to be special-cased.
This is actually something that had been fixed before (PR 14377),
but at the time, no test case had been committed.
Regressi
On Tue, Jan 1, 2019 at 10:02 PM Jeff Law wrote:
>
>
> So the first of probably 3 patches to fix issues with string length
> computations now that the underlying infrastructure is in place. Like
> the prior patches, this is primarily Martin's work. My contribution has
> been to break it down into
Hi Jakub,
I have updated this patch and rebased with current trunk. The issues you
identified
in the last review should all be resolved. Is this now okay for trunk?
Thanks, and Happy New Year~
Chung-Lin
Index: gcc/fortran/openmp.c
Hi,
this patch fixes ICE when at WPA we try to look for ctor which was
removed at compilation time and thus not streamed. While testcase seems
to reproduce only on gcc 9, this is old bug and thus the fix should be
backported to gcc 8 and 7 after some additional testing.
Bootstrapped/regtested x86
Hell world,
somebody fixed PR 48543 for us, so I have committed the
attached test case as obvious and closed the PR. Thanks
to however did this!
Regards
Thomas
2019-01-02 Thomas Koenig
PR fortran/48543
* gfortran.dg/const_chararacter_merge.f90: New test.
! { dg-do
This adds additional tests for std::map and std::multimap CTAD. The
tests ensure that deduction works for braced-init-list of value_type
objects, and for pairs of input iterators (with both std::pair
and value_type as the iterator's value_type). This ensures deduction
from value_type still works,
Hi Thomas,
Your patch LGTM (and works as expected).
Thanks for the quick fix and happy new year,
Dominique
The testcase in this PR was fixed by r267272, so I've reduced it and am going
to add it to the testsuite.
Tested on x86_64-linux (and with -m32), applying onto trunk.
2019-01-02 Marek Polacek
PR c++/86875
* g++.dg/cpp1y/lambda-generic-86875.C: New test.
diff --git gcc/testsui
Should we mark the symbols that are deprecated in OpenMP 5.0 as such in
the header? Yes, this will break code that uses the symbols and -Werror
but this is the standard writers intend, right? It's easy enough to
work around for the time being.
Aside from the header changes the files implementing
On Wed, Jan 02, 2019 at 05:58:07PM +0100, Ulrich Drepper wrote:
> Should we mark the symbols that are deprecated in OpenMP 5.0 as such in
> the header? Yes, this will break code that uses the symbols and -Werror
> but this is the standard writers intend, right? It's easy enough to
> work around f
On 1/2/19 6:21 PM, Jakub Jelinek wrote:
> As we aren't implementing OpenMP 5.0 fully yet and especially because
> we aren't implementing the new nesting ICV semantics, we shouldn't do it now,
> they are valid in OpenMP 4.5.
OK, that applies to omp_[gs]et_nested.
How about the lock symbols? All t
On Wed, Jan 02, 2019 at 06:23:57PM +0100, Ulrich Drepper wrote:
> On 1/2/19 6:21 PM, Jakub Jelinek wrote:
> > As we aren't implementing OpenMP 5.0 fully yet and especially because
> > we aren't implementing the new nesting ICV semantics, we shouldn't do it
> > now,
> > they are valid in OpenMP 4.5
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Spanish team of translators. The file is available at:
https://translationproject.org/latest/gcc/es.po
(This file, 'gcc-8.2.0.es.po', has jus
On Wed, Jan 02, 2019 at 06:29:27PM +0100, Jakub Jelinek wrote:
> On Wed, Jan 02, 2019 at 06:23:57PM +0100, Ulrich Drepper wrote:
> > On 1/2/19 6:21 PM, Jakub Jelinek wrote:
> > > As we aren't implementing OpenMP 5.0 fully yet and especially because
> > > we aren't implementing the new nesting ICV s
Hi!
As mentioned in the PR, this testcase is not vectorized e.g. on power7
(32-bit as well as 64-bit), because there is no misalign support.
Tested on x86_64-linux (-m32/-m64) where the scan-tree-dump-times still
passes and on powerpc64-linux (-m32/-m64) where it previously FAILed and now
isn't t
This fixes pr88663.
We drop the flexp special handling and instead handle the trailing array
just like any other situation where we need to be conservative. It also
removes some special casing when we had an unterminated character array.
Generic code handles that just fine now. Make return valu
On January 2, 2019 7:26:19 PM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>As mentioned in the PR, this testcase is not vectorized e.g. on power7
>(32-bit as well as 64-bit), because there is no misalign support.
>
>Tested on x86_64-linux (-m32/-m64) where the scan-tree-dump-times still
>passes and on
Hi,
it seems we can easily improve this location by using
DECL_SOURCE_LOCATION in the standard way. Tested x86_64-linux.
Thanks, Paolo.
//
/cp
2019-01-02 Paolo Carlini
* tree.c (handle_nodiscard_attribute): Improve warning location.
/testsuite
2019-01-02 Paolo C
On 1/2/19 5:09 AM, Jakub Jelinek wrote:
Hi!
On the following testcase we ICE, because pushdecl* ggc_frees the decl
passed to it, but builtin_function_1 returns it anyway.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
OK.
On 12/31/18 10:13 AM, Marek Polacek wrote:
This new warning was missing tf_warning checks so we may've wound up
re-entering the reporting routines. Fixed thus.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
OK.
This is the last of the major pieces of Martin's work.
set_strlen_range is extracted out of maybe_set_strlen_range and used by
the strlen folder.
The remnants of maybe_set_strlen_range is made more conservative,
particularly for cases where we might cross a subobject boundary.
There's the usual
On 12/30/18 11:31 PM, Alexandre Oliva wrote:
Concepts-checking and other kinds of early tsubsting may often take
place while location wrappers are suppressed, e.g. because we've
triggered template instantiation within template parameter lists.
With that, exprs that are usually wrapped by VIEW_CO
On 12/30/18 11:08 AM, Marek Polacek wrote:
This PR points out that while we are able to deduce the template arguments
for A{}, we fail for A().
For A{}, the deduction happens in finish_compound_literal:
2789 if (tree anode = type_uses_auto (type))
2790 if (CLASS_PLACEHOLDER_TEMPLATE (anode
On 1/2/19 4:26 PM, Paolo Carlini wrote:
it seems we can easily improve this location by using
DECL_SOURCE_LOCATION in the standard way. Tested x86_64-linux.
OK.
Jason
Add a test case to check whether -masm-syntax-unified is indeed
emitting the inline assembler with .syntax unified.
---
.../gcc.target/arm/pr88648-asm-syntax-unified.c| 14 ++
1 file changed, 14 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/arm/pr88648-asm-syntax-unifi
My recent fix for c++/88612 fixed these two testcases too. Let's add them.
Tested on x86_64-linux, applying to trunk.
2019-01-02 Marek Polacek
PR c++/81486 - CTAD failing with ().
* g++.dg/cpp1z/class-deduction60.C: New test.
* g++.dg/cpp1z/class-deduction61.C: New te
This removes SRK_LENRANGE_2 which was used temporarily as I pulled apart
different parts of the API changes for get_range_strlen. As of a
couple patches ago, it's no longer needed.
Bootstrapped and regression tested on x86_64-linux-gnu. Installing on
the trunk.
jeff
commit 54a7a5e3a7b392f05c7
Here is an update of this patch. I believe I addressed all of the
issues you raised. Thanks for the new target.def description, it
seems much clearer than mine. I did a full build and test on x86 as
well as aarch64 to make sure that architectures that do not define
TARGET_REMOVE_EXTRA_CALL_PRES
Hi , guys
Happy new year!
On the 20th of last month, I submitted a tsv110 pipeline patch. I
want to know if you have received it. Looking forward to your reply.
From: Дилян Палаузов
[I (Simon) just pushed this to binutils-gdb, please consider merging it
in gcc to keep the files sync-ed(-ish).]
https://sourceware.org/bugzilla/show_bug.cgi?id=18632
The bundled libreadline is always built, even if the system is
./configure'd --with-system-readline and th
Hi.
There's a small test-case update requested by Richi in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88436#c1.
Tests are fine on ppc64le-linux-gnu.
Ready for trunk?
Martin
gcc/testsuite/ChangeLog:
2019-01-02 Martin Liska
PR testsuite/88436
* gcc.target/powerpc/pr54240.c:
Hi Martin,
On Thu, Jan 03, 2019 at 08:41:09AM +0100, Martin Liška wrote:
> There's a small test-case update requested by Richi in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88436#c1.
> Tests are fine on ppc64le-linux-gnu.
>
> Ready for trunk?
Yes please. Thanks,
Segher
> 2019-01-02 Ma
58 matches
Mail list logo
