On Jan 20, 2016, at 10:56 PM, Marcin Kościelnicki wrote:
>> This is ok if bootstrap and regression tests are clean. Thanks!
> The bootstrap and regression tests are indeed clean for this patch and #2. I
> don't have commit access to gcc repo, how do I get this pushed?
Just ask someone to apply
On Thu, 21 Jan 2016, Thomas Preud'homme wrote:
> On Friday, January 08, 2016 10:05:25 AM Richard Biener wrote:
> > On Tue, 5 Jan 2016, Thomas Preud'homme wrote:
> > > Hi,
> > >
> > > bswap optimization pass generate wrong code on big endian targets when the
> > > result of a bit operation it anal
On Thursday, January 21, 2016 09:21:52 AM Richard Biener wrote:
> On Thu, 21 Jan 2016, Thomas Preud'homme wrote:
> > On Friday, January 08, 2016 10:05:25 AM Richard Biener wrote:
> > > On Tue, 5 Jan 2016, Thomas Preud'homme wrote:
> > > > Hi,
> > > >
> > > > bswap optimization pass generate wrong
Hi!
This is the same issue that has been fixed a while ago in the aarch64 port
as PR65624. Bootstrapped/regtested on armv7hl-linux-gnueabi, ok for trunk?
2016-01-21 Stefan Sørensen
Jakub Jelinek
PR target/69187
PR target/65624
* config/arm/arm-builtins
On Wed, Jan 06, 2016 at 02:44:47PM -0600, Evandro Menezes wrote:
> Hi, Wilco.
>
> On 01/06/2016 06:04 AM, Wilco Dijkstra wrote:
> >>Here's what I had in mind when I inquired about distinguishing FCMP from
> >>FCCMP. As you can see in the patch, Exynos is the only target that
> >>cares about it, b
Jonathan,
> PR libstdc++/69386
> * include/c_global/ccomplex: Ensure C++ language linkage.
> * include/c_global/cmath: Likewise.
> * include/c_global/cstdlib: Likewise.
> * include/c_global/ctgmath: Likewise.
> * testsuite/17_intro/headers/c++2011/linkage.cc: New.
The test
On 21/01/16 09:20, Jakub Jelinek wrote:
Hi!
This is the same issue that has been fixed a while ago in the aarch64 port
as PR65624. Bootstrapped/regtested on armv7hl-linux-gnueabi, ok for trunk?
Ok, thanks for taking care of this.
Kyrill
2016-01-21 Stefan Sørensen
Jakub Jel
On 01/21/2016 07:56 AM, Marcin Kościelnicki wrote:
>>> +2016-01-02 Marcin Kościelnicki
>>> +
>>> + * config/s390/s390.md (pool_section_start): Use switch_to_section
>>> + to select proper read-only data section instead of hardcoding .rodata.
>>> + (pool_section_end): Use switch_to_section
On 01/20/2016 02:16 PM, Andreas Krebbel wrote:
> On 01/02/2016 08:16 PM, Marcin Kościelnicki wrote:
>> It seems at some point the .size hook was hijacked to emit some
>> machine-specific directives, and the actual .size directive was
>> forgotten. This caused problems for split-stack support, sinc
Torvald,
Now that I can bootstrap on darwin, I have found the following failure for
libitm.c++/libstdc++-safeexc.C
/opt/gcc/work/libitm/testsuite/libitm.c++/libstdc++-safeexc.C:50:2: error:
unsafe function call 'std::underflow_error::underflow_error(const string&)'
within atomic transaction
On 01/02/2016 08:16 PM, Marcin Kościelnicki wrote:
> When an unconditional jump with side effects targets an immediately
> following label, rtl_tidy_fallthru_edge is called. Since it has side
> effects, it doesn't remove the jump, but the label is still marked
> as fallthru. This later causes a v
On 21/01/16 10:58, Andreas Krebbel wrote:
On 01/20/2016 02:16 PM, Andreas Krebbel wrote:
On 01/02/2016 08:16 PM, Marcin Kościelnicki wrote:
It seems at some point the .size hook was hijacked to emit some
machine-specific directives, and the actual .size directive was
forgotten. This caused pro
On 21/01/16 11:05, Andreas Krebbel wrote:
On 01/02/2016 08:16 PM, Marcin Kościelnicki wrote:
When an unconditional jump with side effects targets an immediately
following label, rtl_tidy_fallthru_edge is called. Since it has side
effects, it doesn't remove the jump, but the label is still marke
On 01/15/2016 10:08 PM, Marcin Kościelnicki wrote:
> On 15/01/16 19:38, Andreas Krebbel wrote:
>> Marcin,
>>
>> your implementation looks very good to me. Thanks!
>>
>> But please be aware that we deprecated the support of g5 and g6 and intend
>> to remove that code from
>> the back-end with the n
Committed as obvious.
2016-01-21 Richard Biener
* graphite-optimize-isl.c (get_schedule_map): Fix typo.
Index: gcc/graphite-optimize-isl.c
===
--- gcc/graphite-optimize-isl.c (revision 232666)
+++ gcc/graphite-optimize-i
James Greenhalgh wrote:
> If we don't have any targets which care about the fccmps/fccmpd split in
> the code base, do we really need it? Can we just follow the example of
> fcsel?
If we do that then we should also change fcmps/d to fcmp to keep the f(c)cmp
attributes orthogonal. However it seems
On Wed, 20 Jan 2016, Ilya Verbin wrote:
> I agree that OpenMP doesn't guarantee that all target regions must be executed
> on the device, but in this case a user can't be sure that some library
> function
> always will offload (because the library might be replaced by fallback
> version),
> and h
On Thu, Jan 21, 2016 at 11:13:29AM +, Wilco Dijkstra wrote:
> James Greenhalgh wrote:
> > If we don't have any targets which care about the fccmps/fccmpd split in
> > the code base, do we really need it? Can we just follow the example of
> > fcsel?
>
> If we do that then we should also change
Hi Christian,
On 21/01/16 10:36, Christian Bruel wrote:
The current arm_set_current_function was both awkward and buggy. For instance using partially set TARGET_OPTION set from pragma_parse, while restore_target_globalsnor arm_option_params_internal was not reset. Another issue is that in some
p
On 20/01/16 20:30 -0500, Ed Smith-Rowland wrote:
Now that libstdc++ installs a proper math.h we can piggyback on that
to put in the last bit of TR29124.
This patch adds the math special functions to c_compatibility/math.h
in the global namespace.
I remove the XFAILs from the compile_2.cc test
On Wed, Jan 13, 2016 at 05:44:30PM +, Bilyan Borisov wrote:
> This patch implements all the vcvtR_s64_f64 and vcvtR_u64_f64 vector
> intrinsics, where R is ['',a,m,n,p]. Since these intrinsics are
> identical in semantics to the corresponding scalar variants, they are
> implemented in terms of
On TARGET_CPU_ZARCH && !TARGET_64BIT, we can use a similiar lean mcount
call sequence to TARGET_64BIT. The longer sequences are now used only
on deprecated g5/g6 CPUs.
Tested on s390-ibm-linux-gnu on RHEL 7.2.
gcc/ChangeLog:
* config/s390/s390.c (s390_function_profiler): Add a new seque
On 21/01/16 11:12, Andreas Krebbel wrote:
On 01/15/2016 10:08 PM, Marcin Kościelnicki wrote:
On 15/01/16 19:38, Andreas Krebbel wrote:
Marcin,
your implementation looks very good to me. Thanks!
But please be aware that we deprecated the support of g5 and g6 and intend to
remove that code fro
On Wed, Jan 20, 2016 at 8:00 PM, Michael Meissner
wrote:
> This is revision 4 of the IEEE 128-bit floating point libgcc support.
>
> Since revision 3, I have removed the gcc changes that broke AIX. I rewrote
> the
> IBM extended double pack/unpack support to not use the builtin functions, but
>
On Wed, Jan 20, 2016 at 4:21 PM, Pat Haugen wrote:
> The following adds a couple missed Power9 assembler option entries.
> Bootstrapped on ppc64. Ok for trunk?
>
> -Pat
>
> 2016-01-20 Pat Haugen
>
> * config/rs6000/aix71.h (ASM_CPU_SPEC): Add entry for Power9.
> * config/rs6000/
On 21/01/16 10:27 +0100, Dominique d'Humières wrote:
Jonathan,
PR libstdc++/69386
* include/c_global/ccomplex: Ensure C++ language linkage.
* include/c_global/cmath: Likewise.
* include/c_global/cstdlib: Likewise.
* include/c_global/ctgmath: Likewise.
* testsuite/17_intro
On 20/01/16 12:34 +, Jonathan Wakely wrote:
--- a/libstdc++-v3/include/c_global/ccomplex
+++ b/libstdc++-v3/include/c_global/ccomplex
@@ -35,6 +35,8 @@
# include
#endif
+extern "C++" {
#include
+}
P.S. I would have preferred not to do this around and add
the linkage specification inside
This makes the SSA def stmt update during inlining cheaper by adjusting
it after remapping a SSA def instead of via an extra walk over all stmt
defs (which incidentially is not possible with FOR_EACH_SSA_* during
"early SSA" as we don't have SSA operands there).
I've tested this independently of
On Thu, 2016-01-21 at 11:00 +0100, Dominique d'Humières wrote:
> Torvald,
>
> Now that I can bootstrap on darwin, I have found the following failure for
> libitm.c++/libstdc++-safeexc.C
>
> /opt/gcc/work/libitm/testsuite/libitm.c++/libstdc++-safeexc.C:50:2: error:
> unsafe function call 'std::u
Hi Matthias,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69129
this fixes the bootstrap errors for me, seen in both libgnat and libgfortran.
Great - I have gone ahead and checked the patch in.
Cheers
Nick
> On Wed, Jan 20, 2016 at 9:32 AM, Eric Botcazou wrote:
> > Hi,
> >
> > this patch from Jan:
> > https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01388.html
> > totally disabled cross-language inlining into Ada without notice, by adding
> > a
> > check that always fails when the language of the ca
On Thu, Jan 21, 2016 at 3:13 PM, Jan Hubicka wrote:
>> On Wed, Jan 20, 2016 at 9:32 AM, Eric Botcazou wrote:
>> > Hi,
>> >
>> > this patch from Jan:
>> > https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01388.html
>> > totally disabled cross-language inlining into Ada without notice, by
>> > addi
> >
> > Well, it is a while since I looked deeper into EH code, but if I remember
> > correctly we have EH region associated with statements and the non-call
> > exceptions do not have EH region that is taken by EH code as an information
> > that the statement was proved to not throw? In that case
On 2016/1/20 09:17 PM, Bernd Schmidt wrote:
> On 01/05/2016 02:15 PM, Chung-Lin Tang wrote:
>> * omp-low.c (scan_sharing_clauses): Call add_local_decl() for
>> use_device/use_device_ptr variables.
>
> It looks vaguely plausible, but if everything is part of the host
> function, why make a
On 15/01/16 17:14, Sebastian Pop wrote:
From: Sebastian Pop
2015-12-30 Aditya Kumar
Sebastian Pop
* graphite-dependences.c (constrain_domain): Add call to isl_*_coalesce.
(add_pdr_constraints): Same.
(scop_get_reads): Same.
(scop_get_must_writes
On 21/01/16 14:22, Matthew Wahab wrote:
On 15/01/16 17:14, Sebastian Pop wrote:
From: Sebastian Pop
2015-12-30 Aditya Kumar
Sebastian Pop
* graphite-dependences.c (constrain_domain): Add call to isl_*_coalesce.
(add_pdr_constraints): Same.
(scop_get_reads): Same.
A gcc/configure stanza to test for PowerPC mfcrf support became
tangled with Darwin test for .machine directive. This patch detangles
and separates the two tests.
I don't have a Darwin system to test.
* configure.ac (gcc_cv_as_powerpc_mfcrf, gcc_cv_as_machine_directive): Detangle.
Okay?
Thanks
Thomas, I've mentioned this issue before - there is sometimes just too
much irrelevant stuff to wade through in your patch submissions, and it
discourages review. The discussion of the actual problem begins more
than halfway through your multi-page mail. Please try to be more concise.
On 12/16
On Thu, 2016-01-21 at 11:00 +0100, Dominique d'Humières wrote:
> Torvald,
>
> Now that I can bootstrap on darwin, I have found the following failure for
> libitm.c++/libstdc++-safeexc.C
>
> /opt/gcc/work/libitm/testsuite/libitm.c++/libstdc++-safeexc.C:50:2: error:
> unsafe function call 'std::u
On Thu, Jan 21, 2016 at 10:22:19PM +0800, Chung-Lin Tang wrote:
> On 2016/1/20 09:17 PM, Bernd Schmidt wrote:
> > On 01/05/2016 02:15 PM, Chung-Lin Tang wrote:
> >> * omp-low.c (scan_sharing_clauses): Call add_local_decl() for
> >> use_device/use_device_ptr variables.
> >
> > It looks vagu
On 01/21/2016 03:22 PM, Chung-Lin Tang wrote:
On 2016/1/20 09:17 PM, Bernd Schmidt wrote:
On 01/05/2016 02:15 PM, Chung-Lin Tang wrote:
* omp-low.c (scan_sharing_clauses): Call add_local_decl() for
use_device/use_device_ptr variables.
It looks vaguely plausible, but if everything is
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68990
The patch was successfully bootstrapped and tested on x86 and
x86-64. The patch was also checked on x86-64 SPECFP2000. The only
changed code was for fma3d. There was no visible change in fm3d
performance.
Tested on x86_64-suse-linux, OK for the mainline?
2016-01-21 Eric Botcazou
* doc/extend.texi (scalar_storage_order type attribute): Document
restriction on type punning and aliasing.
--
Eric BotcazouIndex: doc/extend.texi
=
Hi,
this has bothered me for some time. The gcc configure with stage1 feels
like taking forever because some of the decl availability tests (checking
for C function) include system.h, and that, since a while, unconditionally
includes and under C++, and we meanwhile use the C++
compiler for
Hi,
Anton Blanchard proposed a fix to his own bug report in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63354, but never submitted
the patch upstream. I've added a formal test case and am submitting on
his behalf.
The patch simply ensures that we don't stack a frame for leaf procedures
when cal
On Thu, Jan 21, 2016 at 5:57 PM, Michael Matz wrote:
> Hi,
>
> this has bothered me for some time. The gcc configure with stage1 feels
> like taking forever because some of the decl availability tests (checking
> for C function) include system.h, and that, since a while, unconditionally
> include
On 01/12/2016 09:42 AM, Ajit Kumar Agarwal wrote:
The patch contains the changes in the macros fixed_registers and
call_used_registers.
Earlier the register r21 is marked as fixed and also marked as 1 for call_used
registers.
On top of that r21 is not assigned to any of the temporaries in rtl i
> Le 21 janv. 2016 à 16:25, Torvald Riegel a écrit :
>
> On Thu, 2016-01-21 at 11:00 +0100, Dominique d'Humières wrote:
>> Torvald,
>>
>> Now that I can bootstrap on darwin, I have found the following failure for
>> libitm.c++/libstdc++-safeexc.C
>>
>> /opt/gcc/work/libitm/testsuite/libitm.c+
On 12/07/2015 09:39 AM, Ajit Kumar Agarwal wrote:
-Original Message-
From: Michael Eager [mailto:ea...@eagerm.com]
Sent: Thursday, December 03, 2015 7:27 PM
To: Ajit Kumar Agarwal; GCC Patches
Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala
Subject: Re: [Pat
On 18/01/16 17:10, Eric Botcazou wrote:
Similarly to ARM, I note that Ada is affected. Indeed, with a gcc 4.9 host
compiler, I saw a bootstrap miscompare iff including Ada; however, I was
able to bootstrap Ada successfully, if I first built a GCC including this
patch with --disable-bootstrap, and
On Thu, Jan 21, 2016 at 11:48 AM, Bill Schmidt
wrote:
> Hi,
>
> Anton Blanchard proposed a fix to his own bug report in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63354, but never submitted
> the patch upstream. I've added a formal test case and am submitting on
> his behalf.
>
> The patch si
> Le 21 janv. 2016 à 18:15, Dominique d'Humières a écrit :
>
>
>> Le 21 janv. 2016 à 16:25, Torvald Riegel a écrit :
>>
>> On Thu, 2016-01-21 at 11:00 +0100, Dominique d'Humières wrote:
>>> Torvald,
>>>
>>> Now that I can bootstrap on darwin, I have found the following failure for
>>> libit
On Thu, Jan 21, 2016 at 08:28:05AM -0500, David Edelsohn wrote:
> On Wed, Jan 20, 2016 at 8:00 PM, Michael Meissner
> wrote:
> > This is revision 4 of the IEEE 128-bit floating point libgcc support.
> >
> > Since revision 3, I have removed the gcc changes that broke AIX. I rewrote
> > the
> > IB
On 01/20/2016 10:00 PM, Martin Sebor wrote:
The attached patch avoids printing a diagnostic referencing the type
of an incompatible argument to the __atomic_xxx built-ins when the
argument is in error. Doing otherwise causes an ICE as pointed out
in the bug, for both of which I am to blame.
Mar
On 01/21/2016 05:34 PM, Eric Botcazou wrote:
Tested on x86_64-suse-linux, OK for the mainline?
2016-01-21 Eric Botcazou
* doc/extend.texi (scalar_storage_order type attribute): Document
restriction on type punning and aliasing.
Isn't this kind of implied by the already doc
On 01/18/2016 08:30 PM, David Edelsohn wrote:
Bootstrapped on powerpc-ibm-aix7.1.2.0 with and without the corrected assembler.
Okay?
The changes seem to be in *-*-aix blocks, so as far as I'm concerned you
are the maintainer and can check this in. One question though:
;;
esac
On Thu, Jan 21, 2016 at 12:47 PM, Bernd Schmidt wrote:
> On 01/18/2016 08:30 PM, David Edelsohn wrote:
>>
>> Bootstrapped on powerpc-ibm-aix7.1.2.0 with and without the corrected
>> assembler.
>>
>> Okay?
>
>
> The changes seem to be in *-*-aix blocks, so as far as I'm concerned you are
> the main
Hi all,
In this wrong-code PR the pattern for performing
x = x | for -mrestrict-it is buggy and ends up writing 1 to the
result register rather than orring it.
The offending pattern is *thumb2_ior_scc_strict_it.
My proposed solution is to rewrite it as a splitter, remove the
alternative for the
I've bootstrapped and tested the following on 4.9-branch. It's a
backport of a patch that avoids unnecessary assertion failures, both by
tuning down an assert, and restricting an optimization for the case
where the assert would validly trigger.
Ok to commit on the branch?
Bernd
PR target/6
On Jan 21, 2016, at 9:29 AM, Dominique d'Humières wrote:
> // { dg-do run { target { ! { *-*-darwin* powerpc-ibm-aix* } } } }
A comment to hint that this has something to do with weak undefined would be
nice.
On Jan 21, 2016, at 6:50 AM, David Edelsohn wrote:
> A gcc/configure stanza to test for PowerPC mfcrf support became
> tangled with Darwin test for .machine directive. This patch detangles
> and separates the two tests.
>
> I don't have a Darwin system to test.
>
> * configure.ac (gcc_cv_as_pow
On 01/21/2016 06:06 PM, Mike Stump wrote:
> On Jan 21, 2016, at 9:29 AM, Dominique d'Humières wrote:
>> // { dg-do run { target { ! { *-*-darwin* powerpc-ibm-aix* } } } }
>
> A comment to hint that this has something to do with weak undefined would be
> nice.
>
Or come up with some new "dg-req
On Thu, 2016-01-21 at 10:06 -0800, Mike Stump wrote:
> On Jan 21, 2016, at 9:29 AM, Dominique d'Humières wrote:
> > // { dg-do run { target { ! { *-*-darwin* powerpc-ibm-aix* } } } }
>
> A comment to hint that this has something to do with weak undefined would be
> nice.
Here's the patch I prep
On Thu, 2016-01-21 at 18:12 +, Pedro Alves wrote:
> On 01/21/2016 06:06 PM, Mike Stump wrote:
> > On Jan 21, 2016, at 9:29 AM, Dominique d'Humières
> > wrote:
> >> // { dg-do run { target { ! { *-*-darwin* powerpc-ibm-aix* } } } }
> >
> > A comment to hint that this has something to do with
On Jan 21, 2016, at 10:15 AM, Torvald Riegel wrote:
> On Thu, 2016-01-21 at 10:06 -0800, Mike Stump wrote:
>> On Jan 21, 2016, at 9:29 AM, Dominique d'Humières wrote:
>>> // { dg-do run { target { ! { *-*-darwin* powerpc-ibm-aix* } } } }
>>
>> A comment to hint that this has something to do with
The problem in this PR is that we have a PTRMEM_CST wrapped in NOP_EXPR
and fold_convert can't digest that.
For the unreduced test in the PR, this occurs since rev 230508: we force
a NOP_EXPR when converting to the same type in build_static_cast_1:
if (result == expr && SCALAR_TYPE_P (t
On 21/01/16 10:19 -0800, Mike Stump wrote:
On Jan 21, 2016, at 10:15 AM, Torvald Riegel wrote:
On Thu, 2016-01-21 at 10:06 -0800, Mike Stump wrote:
On Jan 21, 2016, at 9:29 AM, Dominique d'Humières wrote:
// { dg-do run { target { ! { *-*-darwin* powerpc-ibm-aix* } } } }
A comment to hint
On Thu, 2016-01-21 at 18:26 +, Jonathan Wakely wrote:
> On 21/01/16 10:19 -0800, Mike Stump wrote:
> >On Jan 21, 2016, at 10:15 AM, Torvald Riegel wrote:
> >> On Thu, 2016-01-21 at 10:06 -0800, Mike Stump wrote:
> >>> On Jan 21, 2016, at 9:29 AM, Dominique d'Humières
> >>> wrote:
> // {
On 01/19/2016 10:30 PM, Patrick Palka wrote:
* g++.dg/template/unify17.C: XFAIL.
Hmm, I'm not comfortable with deliberately regressing this testcase.
template
-void bar (void (T[5])); // { dg-error "array of 'void'" }
+void bar (void (T[5])); // { dg-error "array of 'void'" "" { xfail
On 01/21/2016 01:25 PM, Marek Polacek wrote:
The problem in this PR is that we have a PTRMEM_CST wrapped in NOP_EXPR
and fold_convert can't digest that.
Why didn't we fold away the NOP_EXPR before calling fold_convert? I
guess we shouldn't call fold_convert on an un-folded operand.
Jason
Hi, James.
On 01/21/16 03:24, James Greenhalgh wrote:
On Wed, Jan 06, 2016 at 02:44:47PM -0600, Evandro Menezes wrote:
On 01/06/2016 06:04 AM, Wilco Dijkstra wrote:
Here's what I had in mind when I inquired about distinguishing FCMP from
FCCMP. As you can see in the patch, Exynos is the only
On 01/21/16 13:58, Evandro Menezes wrote:
Hi, James.
On 01/21/16 03:24, James Greenhalgh wrote:
On Wed, Jan 06, 2016 at 02:44:47PM -0600, Evandro Menezes wrote:
On 01/06/2016 06:04 AM, Wilco Dijkstra wrote:
Here's what I had in mind when I inquired about distinguishing
FCMP from
FCCMP. As y
We were complaining about attributes on C++11 scoped enums because
start_enum gives them an underlying type, and thereby a TYPE_SIZE,
immediately. Fixed by passing early attributes to start_enum.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 2a974c0078f1f7b39e7b4ef94fee8836faf5aa95
Aut
The problem here was that when copy_type_enum updates the size and
alignment of the enum to match its underlying type, it was clobbering
any explicit alignment. I've fixed similar issues in other places, but
this one needed the update as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
co
wide-int.h has
/* For fixed-precision integers like offset_int and widest_int,
handle the case where the shift value is constant and the
result is a single nonnegative HWI (meaning that we don't
need to worry about val[1]). This is particularly common
for
On 01/18/2016 11:01 AM, Jerry DeLisle wrote:
> This patch follows the suggestion Jakub made in the PR and is very
> straightforward.
>
The patch is simple enough. I will commit to trunk shortly if I hear from no
one.
Regards,
Jerry
> With the patch, an abort is given on actual errors, in ag
This BZ asks that the C++ front end follow the behavior of the C front
end in handling typedefs that involve deprecated types: we should warn
when defining the typedef, not when using it. This seems reasonable,
particularly since the C front end works this way.
Tested x86_64-pc-linux-gnu, app
Hi!
This patch attempts to fix a regression caused by early debug info, where
DIEs are created sooner and some intermediate qualified types might not
exist yet.
Rather than creating further variant tree types, this patch arranges for the
qualified DIEs (DW_TAG_{atomic,restrict,volatile,const}_typ
On 01/21/2016 10:53 AM, Bernd Schmidt wrote:
I've bootstrapped and tested the following on 4.9-branch. It's a
backport of a patch that avoids unnecessary assertion failures, both by
tuning down an assert, and restricting an optimization for the case
where the assert would validly trigger.
Ok to
On Thu, Jan 21, 2016 at 10:37:47AM -0700, Jeff Law wrote:
> On 01/20/2016 10:00 PM, Martin Sebor wrote:
> >The attached patch avoids printing a diagnostic referencing the type
> >of an incompatible argument to the __atomic_xxx built-ins when the
> >argument is in error. Doing otherwise causes an I
This is the final patch (at least so far) that turns on -mfloat128 by default
for PowerPC Linux systems where the VSX instruction set is enabled. As I
mentioned in the last email, because we don't build the __float128 emulator on
other systems, I didn't think it would be useful to make it the defa
On Thu, 21 Jan 2016, Jason Merrill wrote:
On 01/19/2016 10:30 PM, Patrick Palka wrote:
* g++.dg/template/unify17.C: XFAIL.
Hmm, I'm not comfortable with deliberately regressing this testcase.
template
-void bar (void (T[5])); // { dg-error "array of 'void'" }
+void bar (void (T[5]))
Hi!
On Mon, 18 Jan 2016 18:26:49 +0100, Tom de Vries wrote:
> This patch introduces an option fopt-info-oacc.
>
> When using the option like this with a kernels region in kernels-loop.c
> that parloops does not manage to parallelize:
> ...
> $ gcc kernels-loop.c -S -O2 -fopenacc -fopt-info-oacc
On Thu, Jan 21, 2016 at 01:58:31PM -0600, Evandro Menezes wrote:
> Hi, James.
>
> On 01/21/16 03:24, James Greenhalgh wrote:
> >On Wed, Jan 06, 2016 at 02:44:47PM -0600, Evandro Menezes wrote:
> >>On 01/06/2016 06:04 AM, Wilco Dijkstra wrote:
> Here's what I had in mind when I inquired about d
BZ69347 shows excessive memory consumption in the FSM threading code.
The underlying problem has been there since the introduction of the FSM
threader, but the increased reliance on the FSM threader has brought the
issue to the forefront of things we need to look at.
Essentially the FSM bit
On 01/21/2016 09:34 AM, Eric Botcazou wrote:
Tested on x86_64-suse-linux, OK for the mainline?
2016-01-21 Eric Botcazou
* doc/extend.texi (scalar_storage_order type attribute): Document
restriction on type punning and aliasing.
This patch is OK.
I wish somebody could fix
The attached patch fixes another ICE triggered by an invalid
initialization of a flexible array member, and caused by making
the upper bound of the TYPE_DOMAIN() of such arrays null.
Martin
PS Jason, when you have a chance, there are two other patches
for similar P1 failures waiting for your rev
On 01/21/16 16:07, James Greenhalgh wrote:
On Thu, Jan 21, 2016 at 01:58:31PM -0600, Evandro Menezes wrote:
Hi, James.
On 01/21/16 03:24, James Greenhalgh wrote:
On Wed, Jan 06, 2016 at 02:44:47PM -0600, Evandro Menezes wrote:
On 01/06/2016 06:04 AM, Wilco Dijkstra wrote:
Here's what I had i
Hi Kyrill, the patched gcc generates correct asm for me for the test
case. (I'll then build the whole system to see if other it-block
related bugs are gone too.)
One short question, the newly generated RTL for
x = x |(a)
will be
orr %0, %1, #1; it ; mov%D2\\t%0, %1 (b)
The cond in (a
Per the exchange we had two days ago.
Applied.
Gerald
Index: gcc-5/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/porting_to.html,v
retrieving revision 1.10
diff -u -r1.10 porting_to.html
--- gcc-5/porting_to.html
Hi,
The test case gcc.target/powerpc/p8vector-builtin-8.c needs to be
restricted to targets that support the __int128 keyword. This was
wrongly being attempted with { dg-do compile { target int128 } } when
what's really wanted is { dg-require-effective-target int128 }. With
this patch, the test
I was trying the ttype prototype for static type checking on
fold-const.c to see how long it would take me to convert such a large
file, and it choked on this snippet of code in fold_unary_loc, around
lines 7690-7711:
suspect code tagged with (*)
if ((CONVERT_EXPR_CODE_P (code)
On 01/21/2016 03:05 AM, Andreas Krebbel wrote:
On 01/02/2016 08:16 PM, Marcin Kościelnicki wrote:
When an unconditional jump with side effects targets an immediately
following label, rtl_tidy_fallthru_edge is called. Since it has side
effects, it doesn't remove the jump, but the label is still
On Tue, 19 Jan 2016, Richard Biener wrote:
> I think the merge warrants a NEWS entry on gcc.gnu.org/
...and gcc-6/changes.html. :-)
Martin, happy to help. Want to propose some text (or even patch)?
Gerald
On 01/21/2016 03:35 PM, Jakub Jelinek wrote:
+static const dwarf_qual_info_t dwarf_qual_info[] =
+{
+ { TYPE_QUAL_ATOMIC, DW_TAG_atomic_type },
+ { TYPE_QUAL_RESTRICT, DW_TAG_restrict_type },
+ { TYPE_QUAL_VOLATILE, DW_TAG_volatile_type },
+ { TYPE_QUAL_CONST, DW_TAG_const_type },
+};
Let's
Can we reconsider the representation of flexible arrays? Following the
example of the C front-end is causing a lot of trouble, and using a null
TYPE_DOMAIN seems more intuitive.
Jason
On Thu, Jan 21, 2016 at 6:00 PM, Bill Schmidt
wrote:
> Hi,
>
> The test case gcc.target/powerpc/p8vector-builtin-8.c needs to be
> restricted to targets that support the __int128 keyword. This was
> wrongly being attempted with { dg-do compile { target int128 } } when
> what's really wanted is {
On 01/21/2016 04:19 PM, Jason Merrill wrote:
Can we reconsider the representation of flexible arrays? Following the
example of the C front-end is causing a lot of trouble, and using a null
TYPE_DOMAIN seems more intuitive.
I remember running into at least one ICE in the middle end with
the alt
On 13/01/16 09:42, Richard Biener wrote:
On Tue, 12 Jan 2016, Tom de Vries wrote:
On 12/01/16 14:04, Richard Biener wrote:
On Tue, 12 Jan 2016, Tom de Vries wrote:
On 12/01/16 12:22, Richard Biener wrote:
Doesnt' the same issue apply to
unsigned int *p;
static void __attribute__((noinlin
On 01/21/2016 07:29 AM, Jonathan Wakely wrote:
On 20/01/16 20:30 -0500, Ed Smith-Rowland wrote:
Now that libstdc++ installs a proper math.h we can piggyback on that
to put in the last bit of TR29124.
This patch adds the math special functions to c_compatibility/math.h
in the global namespace.
1 - 100 of 107 matches
Mail list logo
