Hi!
I've backported a couple of patches from trunk to 6 branch,
bootstrapped/regtested on x86_64-linux and i686-linux, committed
to 6.x.
Jakub
2016-12-07 Jakub Jelinek
Backported from mainline
2016-09-16 Jakub Jelinek
PR c++/77375
* class.c (check_b
Ping?
On 1 December 2016 at 15:27, Christophe Lyon wrote:
> Hi,
>
>
> On 10 November 2016 at 15:10, Christophe Lyon
> wrote:
>> On 10 November 2016 at 11:05, Richard Earnshaw
>> wrote:
>>> On 09/11/16 21:29, Christophe Lyon wrote:
Hi,
PR 78253 shows that the handling of weak refe
On 21 November 2016 at 12:03, Thomas Preudhomme
wrote:
> On 17/11/16 20:04, Thomas Preudhomme wrote:
>>
>> Hi Christophe,
>>
>> On 17/11/16 13:36, Christophe Lyon wrote:
>>>
>>> On 16 November 2016 at 10:39, Kyrill Tkachov
>>> wrote:
On 09/11/16 16:19, Thomas Preudhomme wrote:
Sending again, after removing ARM's "company disclaimer or privacy notice"...
On 8 December 2016 at 10:03, Christophe Lyon wrote:
> Hi,
>
> On 6 December 2016 at 11:55, Tamar Christina wrote:
>> Hi Christophe,
>>
>> Aarch64 seems to still pass. It seems the types are really unused after I
>> m
On 08/12/16 08:46, Christophe Lyon wrote:
On 21 November 2016 at 12:03, Thomas Preudhomme
wrote:
On 17/11/16 20:04, Thomas Preudhomme wrote:
Hi Christophe,
On 17/11/16 13:36, Christophe Lyon wrote:
On 16 November 2016 at 10:39, Kyrill Tkachov
wrote:
On 09/11/16 16:19, Thomas Preudhom
Ping.
Link to original post: https://gcc.gnu.org/ml/gcc-patches/2016-11/msg03119.html
On 8 December 2016 at 10:09, Thomas Preudhomme
wrote:
>
>
> On 08/12/16 08:46, Christophe Lyon wrote:
>>
>> On 21 November 2016 at 12:03, Thomas Preudhomme
>> wrote:
>>>
>>> On 17/11/16 20:04, Thomas Preudhomme wrote:
Hi Christophe,
On 17/11/16 13:36, Christophe Lyon wrot
On 08/12/16 09:07, Christophe Lyon wrote:
Sending again, after removing ARM's "company disclaimer or privacy notice"...
And resending the "ok" without the disclaimer...
Ok.
Thanks,
Kyrill
On 8 December 2016 at 10:03, Christophe Lyon wrote:
Hi,
On 6 December 2016 at 11:55, Tamar Christina
I've tested the patch on MPX HW, no new regressions. Attached the
final version below, would that be ok to submit?
2016-11-29 Alexander Ivchenko
* mpxrt/libtool-version: New version.
* mpxrt/mpxrt-utils.c (set_mpx_rt_stop_handler): New function.
(print_help): Add help for CHKP_RT_STOP_HANDLER
Hi all,
Similar to the previous patch this transforms X-reg UBFIZ instructions into
W-reg LSL instructions
when the UBFIZ operands add up to 32, so we can take advantage of the implicit
zero-extension to DImode
when writing to a W-register.
This is done by splitting the existing *andim_ashift_
Hi all,
In this patch we split X-register UBFX instructions that extract up to the edge
of a W-register into
a W-register LSR instruction. So for the example in the testcase instead of:
UBFXX0, X0, 24, 8
we'd generate:
LSR w0, w0, 24
An LSR is a simpler instruction and there's a higher
On Tue, Dec 06, 2016 at 05:00:25PM +, James Greenhalgh wrote:
> On Fri, Nov 11, 2016 at 01:14:15PM +, Wilco Dijkstra wrote:
> > Richard Earnshaw wrote:
> >
> > > Has this patch been truncated? The last line above looks to be part-way
> > > through a hunk.
> >
> > Oops sorry, it seems the
Hello Mike,
On 11/30/2016 09:12 PM, Mike Stump wrote:
So, I noticed this and didn't see who you wanted to review it so,
since it was C++, I thought I'd take a look at it. Ick. Complex
issue.
I did not have anyone special in mind actually, so thank you for having
had a look. :-)
One way t
On 07/12/16 11:46 -0600, Aditya Kumar wrote:
Here is an improved version of basic_string::find. The idea is to
split the string find in two parts:
1. search for the first match by using traits_type::find (this gets converted
to memchr for x86)
2. see if there is a match (this gets converted to m
Ping.
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg03078.html
Thanks,
Kyrill
On 30/11/16 16:47, Kyrill Tkachov wrote:
Hi all,
In this awkward ICE we have a *load_multiple pattern that is being transformed
in reload from:
(insn 55 67 151 3 (parallel [
(set (reg:SI 0 r0)
This should fix this bug properly, by renaming __glibcxx_assert to
__glibcxx_assert_impl, and then using it as __glibcxx_assert when
_GLIBCXX_ASSERTIONS is defined, and/or using it as
_GLIBCXX_PARALLEL_ASSERT when _GLIBCXX_PARALLEL_ASSERTIONS is defined.
This allows us to enable __glibcxx_assert
This is another case where an optimization turns a trap_if
unconditional. We have to defer changing the CFG, since the rest of
cprop seems to blow up when we modify things while scanning.
Bootstrapped and tested on x86_64-linux, and reportedly fixes the
problem on ppc, ok?
Bernd
PR rtl-opt
One of the test strings is empty, so we shouldn't use front() on it.
* testsuite/experimental/filesystem/path/construct/range.cc: Don't
use basic_string::front() when string might be empty.
Tested x86_64-linux, committing to trunk.
commit 116f2615e837bb6f4ed6f6b951205a5be717e910
On 12/02/2016 01:29 PM, Richard Biener wrote:
> On Thu, Dec 1, 2016 at 5:30 PM, Martin Liška wrote:
>> On 11/23/2016 03:13 PM, Jakub Jelinek wrote:
>>> On Wed, Nov 23, 2016 at 02:57:07PM +0100, Martin Liška wrote:
I started review process in libsanitizer: https://reviews.llvm.org/D26965
With the patch applied, one can distinguish between PROB_VERY_UNLIKELY and
real zero probability:
f ()
{
int _1;
[100.00%]:
_1 = __builtin_sprintf (&d2, "%i", 12);
if (_1 != 2)
goto ; [0.04%]
else
goto ; [99.96%]
[0.04%]:
__builtin_abort ();
[99.96%]:
return;
}
P
Hi all,
the attached patch fixes an ice-on-valid problem with finalization.
The ICE turned out to be caused by a bug in 'has_finalizer_component':
According to the documentation, this function is supposed to detect
whether a derived type has any nonpointer nonallocatable components
that have a fin
Hi Janus,
so when I interpret the testcase correctly, than the finalizer should not be
called, right? So adding a call abort() in the Finalize and allocating and
deallocating M in the main program should do no harm, but make the testcase IMO
more feasible. What do you think?
- Andre
On Thu, 8 D
On 26/11/16 14:47 +0200, Ville Voutilainen wrote:
--- a/libstdc++-v3/include/std/array
+++ b/libstdc++-v3/include/std/array
@@ -287,6 +287,13 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
swap(array<_Tp, _Nm>& __one, array<_Tp, _Nm>& __two)
noexcept(noexcept(__one.swap(__two)))
{ __one.swap(_
Hello.
Following patch changes behavior in pretty_print_string, where all non-printable
characters are encoded as \x%x. Currently, when some non-printable characters
are directly
printed to a dump file stream. That makes it complicated to read a dump file
for instance
via a Python script.
Patch
Hi all, hi Dominique,
this is the "compile time part 1" (ctp1) patch to fix the issues reported in
gfortran by a sanitized compiler when compiling the testsuite. The patch
addresses all issues besides leaks (ASAN_OPTIONS="detect_leaks=false". Most of
the issues were about assuming certain kinds of
Ping!
On Fri, 2 Dec 2016 13:28:40 +0100
Andre Vehreschild wrote:
> Hi all,
>
> attached patch fixes on ICE, when freeing a scalar allocatable component in a
> derived typed coarray.
>
> Furthermore does it fix freeing of nested derived typed allocatable
> components. A simple code explains the
Ping!
On Fri, 2 Dec 2016 16:46:29 +0100
Andre Vehreschild wrote:
> Hi all,
>
> attached patch adds a call to sync_all after an ALLOCATE allocating a coarray.
> This is to adhere to standard wanting:
>
> ..., execution of the segment (11.6.2) following the statement is delayed
> until all other
On Wed, Dec 7, 2016 at 10:57 PM, Sandra Loosemore
wrote:
> On 12/07/2016 12:30 PM, Dmitry Vyukov wrote:
>>
>> On Wed, Dec 7, 2016 at 8:23 PM, Sandra Loosemore
>> wrote:
>>>
>>>
>>> You need to fix doc/invoke.texi as well to reflect this change.
>>
>>
>> Done.
>>
>> Attached updated patch.
>
>
> T
There's a patch that adds a new test-case for that.
Martin
>From e8805309edca43153721ce3c79252a4f4a3b2073 Mon Sep 17 00:00:00 2001
From: marxin
Date: Thu, 8 Dec 2016 15:59:28 +0100
Subject: [PATCH] New test
gcc/testsuite/ChangeLog:
2016-12-08 Martin Liska
* gcc.dg/tree-ssa/dump-3.c: New te
On 12/08/2016 04:01 AM, David Malcolm wrote:
gcc/ChangeLog:
* read-md.c (md_reader::read_name_1): Write out the location of
the start of the name, rather than the end, eliminating
unread_char and read_char calls.
For avoidance of doubt, ok to check in the currently appro
This patch fixes an issue in aarch64_classify_address. TImode and TFmode
can either use a 64-bit LDP/STP or 128-bit LDR/STR. The addressing mode
must be carefully modelled as the intersection of both. This is done for
the immediate offsets, however load_store_pair_p must be set as well to
avoid
Hi,
The msa-builtins-err.c test is failing in the following configuration:
-O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
This is because the errors it is checking for are triggered by assembly
generation, which is prevented by -fno-fat-lto-objects.
This patch fixes this by adding a dg-skip-i
Hi Andre,
> so when I interpret the testcase correctly, than the finalizer should not be
> called, right? So adding a call abort() in the Finalize and allocating and
> deallocating M in the main program should do no harm, but make the testcase
> IMO
> more feasible. What do you think?
thanks for
Because of the way the Go frontend handles call expressions with
multiple results, it's possible for expressions to be flattened more
than once. In the case of Slice_construction_expression, allocating
the slice storage multiple times caused a compiler crash as one of the
Temporary_statement's wou
As documented a few lines below in the same file (but I presume that the
BADNAMES file is long gone), using _N wreaks havoc on Solaris:
// This marks string literals in header files to be extracted for eventual
// translation. It is primarily used for messages in thrown exceptions; see
// src/fu
The gc library allocates a _panic struct on the stack. This does not
work for gccgo, because when a deferred function recovers the panic we
unwind the stack up to that point so that returning from the function
will work correctly.
Allocating on the stack fine if the panic is not recovered, and it
On 8 December 2016 at 17:53, Eric Botcazou wrote:
> As documented a few lines below in the same file (but I presume that the
> BADNAMES file is long gone), using _N wreaks havoc on Solaris:
I think this documentation has the same content as BADNAMES used to have?
https://gcc.gnu.org/onlinedocs/l
Hi,
I am seeing some failures in the p9-dimode tests. This appears to
be due to the scan-assembler strings matching comment portions of the
generated assembly, versus the actual generated assembly. In
particular, the dg-final directive { scan-assembler-not "ld"}
is matching the "ld" as seen in t
GCC maintainers:
The following patch adds two more built-ins that are missing.
Specifically:
vector floatvec_packvector doublevector double
vector double vec_sld vector doublevector double
The patch has been boot strapped and tested on
powerpc64le-un
This patch fixes 78550, where we ICE in varasm as we discover a
code-generating NOP_EXPR of an INTEGER_CST. output_constructor
(varasm.c) has a STRIP_NOPs, but that leaves the NOP alone, as it is
truncating a regular QI mode operand to a 1 bit type.
That tree is generated in convert.c:
This patch to libgo copies the memory hashing code from the Go 1.7
runtime. This is particular important because we earlier copied the
hashmap code from Go 1.7, and that changed hash table sizes from prime
numbers to powers of two. The memory hashing code used before this
patch was fine for prime
On 12/08/2016 05:55 AM, Martin Liška wrote:
With the patch applied, one can distinguish between PROB_VERY_UNLIKELY and
real zero probability:
I tried to see if formatting the expression
e->probability * 100.0 / REG_BR_PROB_BASE
with "%.2f" is guaranteed to output non-zero when e->probabilit
On Dec 8, 2016, at 3:04 AM, Pierre-Marie de Rodat wrote:
> Thank you for the pre-approval: I’ve just pushed this fix. For the record,
> I’ve checked it runs fine on x86_64-linux and x86_64-apple-darwin-16.3.0 and
> I’ve checked manually we have the correct number of attributes with a partial
>
Jonathan,
I'm seeing a new failure on AIX.
FAIL: 25_algorithms/headers/algorithm/parallel_algorithm_assert2.cc
(test for excess errors)
Excess errors:
xg++: error: libgomp.spec: No such file or directory
Does the testsuite driver assume that libgomp.spec already is
installed in the correct insta
2016-12-08 12:21 GMT+03:00 Alexander Ivchenko :
> I've tested the patch on MPX HW, no new regressions. Attached the
> final version below, would that be ok to submit?
The patch is OK.
Ilya
>
>
> 2016-11-29 Alexander Ivchenko
>
> * mpxrt/libtool-version: New version.
> * mpxrt/mpxrt-utils.c (s
On 12/08/2016 05:39 PM, Martin Sebor wrote:
> On 12/08/2016 05:55 AM, Martin Liška wrote:
>> With the patch applied, one can distinguish between PROB_VERY_UNLIKELY and
>> real zero probability:
>
> I tried to see if formatting the expression
>
> e->probability * 100.0 / REG_BR_PROB_BASE
>
> wi
On Thu, Dec 08, 2016 at 03:30:59PM +, Wilco Dijkstra wrote:
> This patch fixes an issue in aarch64_classify_address. TImode and TFmode
> can either use a 64-bit LDP/STP or 128-bit LDR/STR. The addressing mode
> must be carefully modelled as the intersection of both. This is done for
> the im
On 5 December 2016 at 21:01, Paul Richard Thomas
wrote:
> Dear All,
>
> It took me an excessively long time to realise that processing the
> typespec for an explicitly typed module procedure was wiping out the
> interface symbol and so preventing the comparison of characteristics
> between the int
On 8 December 2016 at 17:09, David Edelsohn wrote:
> Jonathan,
>
> I'm seeing a new failure on AIX.
>
> FAIL: 25_algorithms/headers/algorithm/parallel_algorithm_assert2.cc
> (test for excess errors)
> Excess errors:
> xg++: error: libgomp.spec: No such file or directory
>
> Does the testsuite drive
On Wed, Dec 7, 2016 at 3:31 PM, Nathan Sidwell wrote:
> This patch fixes 78551. The union was a red herring. The underlying
> problem is that we first initialize a char array with a string constant, and
> then zap a random element of that array. That zapping expects to see a
> CONSTRUCTOR, not
If the problem is the member initializer, we can diagnose that
directly rather than wait until we're in a constructor.
On Wed, Dec 7, 2016 at 3:26 PM, Marek Polacek wrote:
> We were crashing in finish_expr_stmt here:
> 676 /* If we ran into a problem, make sure we complained. */
> 677
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:
http://translationproject.org/latest/gcc/es.po
(This file, 'gcc-6.2.0.es.po', has just
On 12/07/2016 01:30 PM, Nathan Sidwell wrote:
This patch fixes the generic lambda mangling bug that caused the
demangler to infinitely recurse (78252). The generic's auto parms fail
the is_auto check because that's testing for the 'auto' identifier,
whereas the parms are distinct template type p
No functional changes.
2016-12-08 Uros Bizjak
* gcc.target/i386/i386.h (HARD_REGNO_NREGS): Use GENERAL_REGNO_P.
(HARD_REGNO_NREGS_HAS_PADDING): Ditto. Simplify macro.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline SVN.
Uros.
diff --git a/gcc/c
James Greenhalgh wrote:
>
> I presume you also made a testsuite run?
>
> You should be able to do something like:
>
> make check RUNTESTFLAGS="--target_board=unix/-mpc-relative-literal-loads"
Yes the results of that looked OK, the 250 new failures are gone. I've
committed the fix.
Wilco
On 12/08/2016 02:08 PM, Jason Merrill wrote:
Right. Which is because they act as normal template parameters rather
than like the auto type-specifier does in, say, a variable declaration.
But indeed this produces bad mangling, and using Da in the mangling of a
generic lambda seems reasonable. Y
Hi Andre,
Thomas, your part of the patch looks ok to me, too. I haven't tracked the
discussion on whether it is ok to add your part of the patch. Therefore I don't
have committed your patch. My opinion is, that it does do no harm. So it should
be applied.
Based on the feedback so far, I will t
Hi Wilco,
On 11/30/16 18:01, Bernd Edlinger wrote:
> I attached the completely untested follow-up patch now, but I would
> like to post that one again for review, after I applied my current
> patch, which is still waiting for final review (please feel pinged!).
>
>
> This is really exciting...
>
>
On 12/08/2016 01:05 PM, Jason Merrill wrote:
If the problem is the member initializer, we can diagnose that
directly rather than wait until we're in a constructor.
What about:
struct Foo {
int a;
char ary[];
Foo () : ary ("bob"){}
};
? That ICEs in the same way.
nathan
--
Nathan Sidwell
Le 08/12/2016 à 20:26, Thomas Koenig a écrit :
Hi Andre,
Thomas, your part of the patch looks ok to me, too. I haven't tracked the
discussion on whether it is ok to add your part of the patch.
Therefore I don't
have committed your patch. My opinion is, that it does do no harm. So
it should
be a
Testing the patch kit on i686 showed numerous failures of this
assertion in set_mem_attributes_minus_bitpos in emit-rtl.c:
1821gcc_assert (!defattrs->offset_known_p);
when expanding "main" in the rtl.exp test files, after parsing
an __RTL-tagged function.
Root cause is various assignme
On 12/08/2016 09:39 PM, David Malcolm wrote:
OK as adjustments to patches 8a and 8b?
Ok. Is it possible to adjust these macros to return something like a
const reference to ensure people can't make this kind of error?
Bernd
I merged trunk revision 243445 to the gccgo branch.
Ian
On Thu, Dec 08, 2016 at 02:56:56PM -0500, Nathan Sidwell wrote:
> On 12/08/2016 01:05 PM, Jason Merrill wrote:
> > If the problem is the member initializer, we can diagnose that
> > directly rather than wait until we're in a constructor.
>
> What about:
> struct Foo {
> int a;
> char ary[];
> Foo
On 06/12/2016 12:54, Jonathan Wakely wrote:
On 20/11/16 19:14 +0100, François Dumont wrote:
Talking about _M_color I just realize that move semantic doesn't copy
_M_color. Shouldn't we capture it along with all the other _M_header
information ?
Is it needed? I think the current code does the
On 12/08/2016 01:28 PM, Marek Polacek wrote:
On Thu, Dec 08, 2016 at 02:56:56PM -0500, Nathan Sidwell wrote:
On 12/08/2016 01:05 PM, Jason Merrill wrote:
If the problem is the member initializer, we can diagnose that
directly rather than wait until we're in a constructor.
What about:
struct F
This patch to libgo marks the unused parameters in the non-x86 code of
the new file aeshash.c as unused, to avoid build warnings.
Bootstrapped on x86_64-pc-linux-gnu, test compiled using an ARM
cross-compiler. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
=
I now merged trunk revision 243459 to the gccgo branch.
Ian
This test ICEs since r240072 where Tom disallowed using va_list * as a first
argument to va_arg. I think the problem is in the ADDR_EXPR check in
gimplify_va_arg_expr. It's meant to handle Case 1, but the valist doesn't
always have to be ADDR_EXPR. E.g. for this testcase build_va_arg creates
VA_
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78671
The patch was successfully bootstrapped and tested on x86-64.
Committed as rev. 243462.
Index: ChangeLog
===
--- ChangeLog (revision 243461)
+++ ChangeL
On Thu, Dec 08, 2016 at 07:58:37AM +0100, Paul Richard Thomas wrote:
>
> "Accidence" == state of fixing non-deterministic ICEs? :-)
>
> OK for trunk.
>
> Thanks for dealing with this kind of dead wood.
>
Committed revision 243463.
--
Steve
Hello!
Attached patch fixes fall-out from excess-precision improvements
patch. As shown in the PR, the code throughout the compiler assumes
FLAG_PRECISION_FAST when flag_unsafe_math_optimizations flag is in
effect. The patch puts back two lines, removed by excess-precision
improvements patch.
201
On Thu, 2016-12-01 at 14:29 +0100, Bernd Schmidt wrote:
> On 11/11/2016 10:15 PM, David Malcolm wrote:
> > + /* Makefile.in has -fself-test=$(srcdir)/testsuite/selftests, so
> > that
> > + flag_self_test contains the path to the selftest subdirectory
> > of the
> > + source tree (without a
Am 08.12.2016 um 21:01 schrieb Mikael Morin:
Le 08/12/2016 à 20:26, Thomas Koenig a écrit :
Hi Andre,
Thomas, your part of the patch looks ok to me, too. I haven't tracked
the
discussion on whether it is ok to add your part of the patch.
Therefore I don't
have committed your patch. My opinion
Hi!
The following testcases show two bugs in zero_one_operation (used during
undistribute optimization) and functions it calls.
The first one (wrong-code) is fixed by the
+ tree orig_def = *def;
and
- if (stmts_to_fix.length () > 0)
+ if (stmts_to_fix.length () > 0 || *def == orig_def)
changes
Hi!
Issaquah papers have been recently published and there are two
decomp changes. One I've sent a partially working patch privately and am
lost with, the other one is that whenever std::tuple_size is a
complete type, we should commit to the std::tuple* way - so if it is
missing value static data
Le 08/12/2016 à 22:50, Thomas Koenig a écrit :
Am 08.12.2016 um 21:01 schrieb Mikael Morin:
Le 08/12/2016 à 20:26, Thomas Koenig a écrit :
Hi Andre,
Thomas, your part of the patch looks ok to me, too. I haven't tracked
the
discussion on whether it is ok to add your part of the patch.
Therefor
On Thu, Dec 8, 2016 at 10:03 AM, Jonathan Wakely wrote:
> On 8 December 2016 at 17:09, David Edelsohn wrote:
>> Jonathan,
>>
>> I'm seeing a new failure on AIX.
>>
>> FAIL: 25_algorithms/headers/algorithm/parallel_algorithm_assert2.cc
>> (test for excess errors)
>> Excess errors:
>> xg++: error: l
Le 08/12/2016 à 14:39, Andre Vehreschild a écrit :
Hi all, hi Dominique,
this is the "compile time part 1" (ctp1) patch to fix the issues reported in
gfortran by a sanitized compiler when compiling the testsuite. The patch
addresses all issues besides leaks (ASAN_OPTIONS="detect_leaks=false". Mo
Hi,
Back in October
(https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00256.html), Jakub
updated the target pass registration framework so that target passes act
more like regular passes: their dumps are numbered in proper order, and
use of dump options like -details now works. I've finally gotten
This patch adds support to gcc for the Fuchsia OS
(https://fuchsia.googlesource.com/).
OK for mainline?
Thanks -
Josh
2016-12-08 Joshua Conner
* config/arm/fuchsia-elf.h: New file.
* config/fuchsia.h: New file.
* config.gcc (*-*-fuchsia*): Set native_system_header_dir.
PR78027 was classified as a fortran bug, but the underlying problem
turned out to be more generic. Basically, the IPA-ICF pass usually
ignores functions with omp decl attributes as candidates for aliasing.
Usually that works for OpenACC, because offloaded functions generated by
OpenACC PARALLEL or
On Thu, Dec 08, 2016 at 03:05:10PM -0800, Cesar Philippidis wrote:
> 2016-12-08 Cesar Philippidis
>
> PR fortran/78027
>
> gcc/
> * ipa-icf.c (sem_function::parse): Don't process functions with
> oacc decl attributes, as they may be OpenACC routines.
>
> gcc/tes
+enabled with @option{-Wextra}.
So I think we should in the immediate term not enable this in Wextra.
However, I think for gcc-8 we should revisit after fixing GCC to be
cleaner WRT alloc-zero.
So disable alloc-zero by default, comment typo and potentially adding
the GTY marker to alloc_object_s
On 12/08/2016 04:05 PM, Cesar Philippidis wrote:
PR78027 was classified as a fortran bug, but the underlying problem
turned out to be more generic. Basically, the IPA-ICF pass usually
ignores functions with omp decl attributes as candidates for aliasing.
Usually that works for OpenACC, because of
On Thu, 2016-12-08 at 21:08 +0100, Bernd Schmidt wrote:
> On 12/08/2016 09:39 PM, David Malcolm wrote:
> >
> > OK as adjustments to patches 8a and 8b?
>
> Ok. Is it possible to adjust these macros to return something like a
> const reference to ensure people can't make this kind of error?
>
>
>
On 12/09/2016 03:02 AM, David Malcolm wrote:
The following patch leads to errors like this for that kind
of mistake:
error: assignment of member 'mem_attrs::offset' in read-only object
MEM_OFFSET (x) = atoi (name.string);
^
Successfully bootstra
On 12/08/2016 10:47 PM, David Malcolm wrote:
Is (A) OK, or would you prefer (B)? (I prefer (A) fwiw)
Oh well, just keep it as it is.
Bernd
On Wed, Dec 07, 2016 at 09:05:13PM -0600, Bill Schmidt wrote:
> Andreas Schwab observed that the subject test case fails on 32-bit big-endian
> because the test is not restricted to targets that support __int128. This
> patch rectifies that.
>
> Tested on powerpc64-unknown-linux-gnu and verified
Hello,
On Thu, Dec 08, 2016 at 10:18:42AM -0600, Will Schmidt wrote:
> I am seeing some failures in the p9-dimode tests. This appears to
> be due to the scan-assembler strings matching comment portions of the
> generated assembly, versus the actual generated assembly. In
> particular, the dg-final
On Thu, Dec 08, 2016 at 08:28:22AM -0800, Carl E. Love wrote:
> The following patch adds two more built-ins that are missing.
> Specifically:
>
> vector floatvec_packvector doublevector double
> vector double vec_sld vector doublevector double
>
> The
On Thu, Dec 08, 2016 at 04:53:55PM -0600, Bill Schmidt wrote:
> Back in October
> (https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00256.html), Jakub
> updated the target pass registration framework so that target passes act
> more like regular passes: their dumps are numbered in proper order, and
>
Hi,
The AArch64 vector initialization sequence can be optimized to generate
better code. The attached patch handles for the case where the vector
contains only variables. It checks for the common elements in the vector
and inserts the values in optimized way.
Bootstrapped and Regression tested on
Hi,
in propagate_vr_accross_jump_function, drop_tree_overflow should be
after fold_convert. Attached patch changes this.
Bootstrapped and regression tested on x86_64-linux-gnu with no new
regressions. Is this OK for trunk?
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2016-12-09 Kugan Vivekanan
Hi Martin,
On 07/12/16 21:08, Martin Jambor wrote:
Hello Kugan,
sorry, I have lost track of this patch and re-discovered it only now.
On Mon, Nov 28, 2016 at 04:25:00PM +1100, kugan wrote:
Hi,
On 24/11/16 19:48, Richard Biener wrote:
On Wed, Nov 23, 2016 at 4:33 PM, Martin Jambor wrote:
H
Hi,
Sorry. Missed out the testcase in patch submission.
Added the missing testcase along with the ChangeLog.
Please review the same and let us know if thats okay?
2016-12-09 Andrew PInski
gcc
* config/aarch64/aarch64.c (aarch64_expand_vector_init):
Improve vector initializatio
Hello,
Le 08/12/2016 à 23:49, Mikael Morin a écrit :
Le 08/12/2016 à 14:39, Andre Vehreschild a écrit :
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 2e6ef2a..8173ba9 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -1019,7 +1019,7 @@ gfc_build_qu
97 matches
Mail list logo
