On Tue, Apr 28, 2015 at 09:53:24PM -0600, Jeff Law wrote:
> On 04/28/2015 08:20 PM, Aditya K wrote:
> >Hi,
> >This is a small patch where I moved a portion of code from the function
> >vectorize_loops outside to improve readability.
> >Please see the patch attached and give comments for improvemen
Hello, gentle maintainer.
This is a message from the Translation Project robot. (If you have
any questions, send them to .)
A new POT file for textual domain 'cpplib' has been made available
to the language teams for translation. It is archived as:
http://translationproject.org/POT-files/c
Dear all,
attached patch fixes a bug and implements EVENTS. I think the patch is
finished, but I still have to extend the test cases, to re-read the
patch and to write a changelog. As I am not sure how soon I will able
to do so, I follow the paradigm: release soon, release often and post
it here.
On 28.04.2015 16:46, Richard Sandiford wrote:
>> +inline void rtx_jump_insn::set_jump_target (rtx_insn *target) +{
>> + JUMP_LABEL(this) = target;
Fixed.
> Could these two operate on rtx_code_labels rather than rtx_insns?
Indeed, right now [set_]jump_target are not used with NOTE's, so I could
pro
Hello, gentle maintainer.
This is a message from the Translation Project robot. (If you have
any questions, send them to .)
A new POT file for textual domain 'gcc' has been made available
to the language teams for translation. It is archived as:
http://translationproject.org/POT-files/gcc-
2012-09-21 H.J. Lu
PR target/48904
* config.gcc (x86_64-*-knetbsd*-gnu): Add i386/knetbsd-gnu64.h.
* config/i386/knetbsd-gnu64.h: New file
Signed-off-by: Bernhard Reutner-Fischer
---
This fixes config-list.mk all-gcc for x86_64-knetbsd-gnu.
Ok for trunk?
gcc/config.
Hi there,
I noticed that gimple-walk.c has a creative list of #includes.
Furthermore, in walk_gimple_asm parse_{in,out}put_constraint was called
even if neither allows_mem, allows_reg nor is_inout were used -- i.e. if
wi is NULL -- and the return value of the constraint parsing was not
taken into
These are bugfixes that prepare handling of SLP loads with gaps
and more SLP permutation kinds.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2015-04-29 Richard Biener
* tree-vect-data-refs.c (vect_analyze_group_access): Properly
compute GROUP_SIZE f
On Tue, Apr 28, 2015 at 06:59:12PM +0200, Thomas Schwinge wrote:
> We're getting ready to submit patches extending the C/C++ front ends for
> the remaining OpenACC clauses, and given the current layout of
> gcc/c-family/c-pragma.h:pragma_omp_clause, we're then at 69 unique
> clauses, which is more
> I think it's been the case for a while that parallel builds of GCC tend
> to serialise around the compilation of insn-recog.c, especially with
> higher --enable-checking settings. This patch tries to speed that
> up by replacing most of genrecog with a new algorithm.
I can confirm this, especia
The testcase gcc.dg/tree-ssa/20030922-2.c FAILs on m68k (and possibly
elsewhere), not on x86_64 though.
So on x86_64 ifcombine has "removed" the if but after dom1 we still have
_14 = *_13;
if (_8 != _14)
goto ;
else
goto ;
:
target_bb.1_15 = target_bb;
_16 = _8 != target_bb.
On Tue, Apr 28, 2015 at 08:45:50PM +0200, Thomas Schwinge wrote:
> I guess nobody so far ;-) has been using OpenMP's target update directive
> in templated code -- OK to commit the following, and to which branches
> (4.9, 5, trunk)?
Seems I've missed testcases for target {,update,data} in template
Hi,
After moving the expansion of va_arg from gimplification to pass_stdarg, we
execute less optimization passes on the expanded va_arg.
For example, in PR65893 the optimized-dump code for a va_arg expansion for
aarch64 is less optimal than it was before, because pass_tree_ifcombine is no
lo
Hi,
here is the patch for PR65924, only tested on the original testcase so far.
Thanks
Yvan
gcc/
2015-04-29 Yvan Roux
PR target/65924
* config/arm/thumb2.md (*thumb2_addsi3_compare0_scratch): Fix operand
number in type attribute expression.
gcc/testsuite/
2015-04-29 Yvan Roux
On Wed, Apr 29, 2015 at 10:01 AM, Bernhard Reutner-Fischer
wrote:
> Hi there,
>
> I noticed that gimple-walk.c has a creative list of #includes.
> Furthermore, in walk_gimple_asm parse_{in,out}put_constraint was called
> even if neither allows_mem, allows_reg nor is_inout were used -- i.e. if
> wi
On Wed, Apr 29, 2015 at 10:52 AM, Tom de Vries wrote:
> Hi,
>
> After moving the expansion of va_arg from gimplification to pass_stdarg, we
> execute less optimization passes on the expanded va_arg.
>
> For example, in PR65893 the optimized-dump code for a va_arg expansion for
> aarch64 is less op
Sorry, I realize I forgot to attach the patch to the original email, this
followed a couple of minutes later in message <553f91b9.7050...@arm.com> at
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01745.html .
Cheers, Alan
Jeff Law wrote:
On 04/28/2015 07:55 AM, Alan Lawrence wrote:
Tree if-c
Hi Jeff/Segher,
Restarting the discussion on the GCC combiner assumption about Memory/address
type.
Ref: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01298.html
https://gcc.gnu.org/ml/gcc/2015-04/msg00028.html
While working on the test case in PR 63949, I came across the below code in
combin
Hi Jakub!
On Wed, 29 Apr 2015 10:53:32 +0200, Jakub Jelinek wrote:
> On Tue, Apr 28, 2015 at 08:45:50PM +0200, Thomas Schwinge wrote:
> > I guess nobody so far ;-) has been using OpenMP's target update directive
> > in templated code -- OK to commit the following, and to which branches
> > (4.9,
Hi Jakub!
On Wed, 29 Apr 2015 10:53:32 +0200, Jakub Jelinek wrote:
> On Tue, Apr 28, 2015 at 08:45:50PM +0200, Thomas Schwinge wrote:
> > That said, what is the preferred approach to add support for
> > OACC_ENTER_DATA, OACC_EXIT_DATA, OACC_UPDATE? I'm not sure hard-coding
> > TREE_OPERAND (t, 0
On Tue, Apr 28, 2015 at 10:29 PM, Tom de Vries wrote:
> On 28-04-15 12:34, Richard Biener wrote:
>>
>> On Mon, Apr 27, 2015 at 5:04 PM, Tom de Vries
>> wrote:
>>>
>>> On 27-04-15 15:40, Richard Biener wrote:
On Mon, Apr 27, 2015 at 3:06 PM, Tom de Vries
wrote:
>
>
>>>
On Wed, Apr 29, 2015 at 11:28:55AM +0200, Thomas Schwinge wrote:
> Yet, if that's a non-starter, I'll pursue this one:
Yeah, it is a non-starter, it has unnecessary runtime overhead everywhere
where it is used.
Jakub
Historically the pragma Inline_Always of GNAT had been implemented in the FE
because the RTL inliner and then the Tree inliner weren't invoked at -O0 or
powerful enough to inline some constructs. But this approach had drawbacks,
especially wrt debug info. These restrictions were gradually lift
Hi Yvan,
On 29/04/15 09:57, Yvan Roux wrote:
Hi,
here is the patch for PR65924, only tested on the original testcase so far.
Can you please double check that the problem doesn't appear
in the other patterns you touched with your cleanup patch?
i.e. that you don't do match_operand on an out-of
You can easily get -fcompare-debug failures on AIX with small functions, in
fact you get the failure for the empty function:
void foo (void) {}
eric@polaris:~/build/gcc/powerpc-ibm-aix7.1> gcc/xgcc -Bgcc -S t.c -O -
fcompare-debug
xgcc: error: t.c: -fcompare-debug failure (length)
Fixed thusly,
> On Apr 29, 2015, at 3:22 AM, Eric Botcazou wrote:
>
> You can easily get -fcompare-debug failures on AIX with small functions, in
> fact you get the failure for the empty function:
>
> void foo (void) {}
>
> eric@polaris:~/build/gcc/powerpc-ibm-aix7.1> gcc/xgcc -Bgcc -S t.c -O -
> fcompa
> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, April 29, 2015 4:01 AM
> To: Dharmakan Rohit-B30502; gcc-patches@gcc.gnu.org;
> rguent...@suse.de; Jakub Jelinek
> Cc: Alan Modra; David Edelsohn; Wienskoski Edmar-RA8797
> Subject: Re: [RFC: Patch, PR 60158]
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 French team of translators. The file is available at:
http://translationproject.org/latest/gcc/fr.po
(This file, 'gcc-5.1.0.fr.po', has just
Hi Kyrill,
On 29 April 2015 at 12:06, Kyrill Tkachov wrote:
> Hi Yvan,
>
> On 29/04/15 09:57, Yvan Roux wrote:
>>
>> Hi,
>>
>> here is the patch for PR65924, only tested on the original testcase so
>> far.
>
>
> Can you please double check that the problem doesn't appear
> in the other patterns y
On 29 April 2015 at 11:00, Richard Biener wrote:
> On Wed, Apr 29, 2015 at 10:01 AM, Bernhard Reutner-Fischer
> wrote:
>> Hi there,
>>
>> I noticed that gimple-walk.c has a creative list of #includes.
>> Furthermore, in walk_gimple_asm parse_{in,out}put_constraint was called
>> even if neither al
On 29/04/15 11:43, Yvan Roux wrote:
Hi Kyrill,
On 29 April 2015 at 12:06, Kyrill Tkachov wrote:
Hi Yvan,
On 29/04/15 09:57, Yvan Roux wrote:
Hi,
here is the patch for PR65924, only tested on the original testcase so
far.
Can you please double check that the problem doesn't appear
in the
On 29 April 2015 at 01:24, Andrew Pinski wrote:
> On Tue, Dec 16, 2014 at 2:19 AM, Renlin Li wrote:
>> Hi all,
>>
>> This is a simple patch to add another two ACLE 2.0 predefined macros into
>> aarch64 backend.
>> They are __ARM_ALIGN_MAX_PWR and __ARM_ALIGN_MAX_STACK_PWR. Currently, those
>> two
Hi!
On Wed, 29 Apr 2015 11:32:31 +0200, Jakub Jelinek wrote:
> Yeah, it is a non-starter, it has unnecessary runtime overhead everywhere
> where it is used.
Huh. OMP_CLAUSES is currently used in a dozen places in
cp/cp-gimplify.c, cp/pt.c, and gimplify.c. I've been expecting my
changed code to
Jeff Law writes:
> On 04/28/2015 07:49 AM, Richard Sandiford wrote:
>> Fix a simple case where we can generalise the CONST_INT handling to all
>> integer constants (CONST_DOUBLE or CONST_WIDE_INT).
>>
>> Tested on x86_64-linux-gnu. OK to install?
>>
>> Thanks,
>> Richard
>>
>>
>> gcc/
>> * l
Hi!
Here is what I've committed to gomp-4_1-branch, a new branch for OpenMP 4.1
support. The intent is to develop OpenMP 4.1 support on the branch and
merge to trunk either when OpenMP 4.1 standard is released, or when
sufficiently close to the release, ideally before end of stage1.
I'll probabl
On 2015.04.28 at 10:42 -0400, Jason Merrill wrote:
> On 04/23/2015 01:45 PM, H.J. Lu wrote:
> > On Thu, Apr 23, 2015 at 8:52 AM, Jason Merrill wrote:
> >> We try to strip attributes that aren't reflected in mangling from template
> >> arguments, but were failing to do that in this case. Fixed by
On Wed, Apr 29, 2015 at 01:13:29PM +0200, Thomas Schwinge wrote:
> On Wed, 29 Apr 2015 11:32:31 +0200, Jakub Jelinek wrote:
> > Yeah, it is a non-starter, it has unnecessary runtime overhead everywhere
> > where it is used.
>
> Huh. OMP_CLAUSES is currently used in a dozen places in
> cp/cp-gimp
Hi Jakub!
(I have not yet read any version of the OpenMP 4.1 standard.)
On Wed, 29 Apr 2015 13:14:06 +0200, Jakub Jelinek wrote:
> --- gcc/tree.def.jj 2015-04-29 10:58:01.663745452 +0200
> +++ gcc/tree.def 2015-04-29 11:34:18.293302684 +0200
> +/* OpenMP - #pragma omp target enter data [
On Wed, Apr 29, 2015 at 11:50 AM, Eric Botcazou wrote:
> Historically the pragma Inline_Always of GNAT had been implemented in the FE
> because the RTL inliner and then the Tree inliner weren't invoked at -O0 or
> powerful enough to inline some constructs. But this approach had drawbacks,
> espec
Hello!
This test uses NaN, so it has to be compiled with ieee options.
2015-04-29 Uros Bizjak
* gfortran.dg/namelist_87.f90: Use dg-add-options ieee.
Tested on alphaev68-linux-gnu and committed to mainline.
Uros.
Index: gfortran.dg/namelist_87.f90
==
On 28 April 2015 at 16:41, Renlin Li wrote:
> Hi all,
>
> unsigned shift left dosen't support immediate shift. Previouly, gcc will
> generate asm instruction like this: "ushl d1, d0, 32", which is not a legal
> insn and will be rejected by assembler. This patch change the use of ushl in
> vec_shr_
On Wed, Apr 29, 2015 at 01:52:24PM +0200, Thomas Schwinge wrote:
> Hi Jakub!
>
> (I have not yet read any version of the OpenMP 4.1 standard.)
There is no OpenMP 4.1 standard, just the public TR3 released in November
last year, and then some non-public WIP.
> > + tree stmt = make_node (OMP_TARG
Hello,
Le 29/04/2015 02:02, David Malcolm a écrit :
> diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
> index 2c7c554..30e4eab 100644
> --- a/gcc/fortran/parse.c
> +++ b/gcc/fortran/parse.c
> @@ -4283,7 +4283,7 @@ parse_oacc_structured_block (gfc_statement acc_st)
> unexpected_eof ();
Hi all,
after the first patch to fix the issue reported in the pr, some more issues were
reported, which are now fixed by this new patch, aka the 2nd take.
The patch modifies the gfc_trans_allocate() in order to pre-evaluate all source=
expressions. It no longer rejects array valued source= expre
spawn /daten/aranym/gcc/gcc-20150429/Build/gcc/xgcc
-B/daten/aranym/gcc/gcc-20150429/Build/gcc/
/daten/aranym/gcc/gcc-20150429/gcc/testsuite/objc/execute/bf-1.m
-fno-diagnostics-show-caret -fdiagnostics-color=never -w -O0 -fgnu-runtime
-I/daten/aranym/gcc/gcc-20150429/gcc/testsuite
Hi,
Jonathan noticed in the audit trail the probably his work for c++/18016
could be easily extended to handle references: simply looking through
INDIRECT_REFs appears to do the trick. Tested x86_64-linux.
Thanks,
Paolo.
/cp
2015-04-29 Paolo Carlini
PR c++/64
On 04/27/2015 07:35 AM, Szabolcs Nagy wrote:
On 20/04/15 19:54, Szabolcs Nagy wrote:
Set up dynamic linker name for microblaze.
Patch v2.
(undef MUSL_DYNAMIC_LINKER that comes from config/linux.h)
gcc/Changelog:
2015-04-24 Gregor Richards
* config/microblaze/linux.h (MUSL_DYNAM
On Wed, Mar 4, 2015 at 3:14 PM, Bill Schmidt
wrote:
> Hi,
>
> I recently observed that -mno-crypto disables all instructions in
> section 5.11 of the 2.07 ISA, rather than just those flagged as
> Category:Vector.Crypto. This patch fixes that undesirable situation.
>
> The main fix is to ensure th
> Historically the pragma Inline_Always of GNAT had been implemented in the FE
> because the RTL inliner and then the Tree inliner weren't invoked at -O0 or
> powerful enough to inline some constructs. But this approach had drawbacks,
> especially wrt debug info. These restrictions were gradua
Alan Lawrence wrote:
As per bugzilla entry, indices in the generated assembly for bigendian are
flipped when they should not be (and, flipped always relative to a Q-register!).
This flips the lane indices back again at assembly time, fixing PR. The
"indices" contained in the RTL are still wron
On 04/29/2015 08:52 AM, Paolo Carlini wrote:
+ /* Handle references. */
+ if (TREE_CODE (val) == INDIRECT_REF)
Let's use REFERENCE_REF_P here. OK with that change.
Jason
On 29/04/15 00:27, Joseph Myers wrote:
> On Mon, 20 Apr 2015, Szabolcs Nagy wrote:
>
>> * On powerpc it seems the only configure option to choose the default
>> long-double abi is --with-long-double-128, but that's the default with
>> sufficiently new glibc. (musl gets 64bit long-double because
On 16 April 2015 at 18:27, Alan Lawrence wrote:
> As per bugzilla entry, indices in the generated assembly for bigendian are
> flipped when they should not be (and, flipped always relative to a
> Q-register!).
>
> This flips the lane indices back again at assembly time, fixing PR. The
> "indices"
On Wed, Apr 29, 2015 at 3:23 PM, Jan Hubicka wrote:
>> Historically the pragma Inline_Always of GNAT had been implemented in the FE
>> because the RTL inliner and then the Tree inliner weren't invoked at -O0 or
>> powerful enough to inline some constructs. But this approach had drawbacks,
>> espe
Eric Botcazou writes:
>> Also, the code is all goto-based, which makes it rather hard to step
>> through.
>
> Do you mean the code in genrecog.c or the generated code in insn-recog.c?
The generated code. genrecog.c itself isn't bad. :-)
>> PS. I've attached the new genrecog.c since the diff ver
Jeff Law writes:
> On 04/27/2015 04:20 AM, Richard Sandiford wrote:
>> Tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-none-eabi.
>> Also tested by building the testsuite for each of the targets above
>> and making sure there were no assembly differences. Made sure that no
>> objects in spe
On 29/04/15 14:17, Michael Eager wrote:
> On 04/27/2015 07:35 AM, Szabolcs Nagy wrote:
>>
>> On 20/04/15 19:54, Szabolcs Nagy wrote:
>>> Set up dynamic linker name for microblaze.
>>>
>>
>> Patch v2.
>> (undef MUSL_DYNAMIC_LINKER that comes from config/linux.h)
>>
>> gcc/Changelog:
>>
>> 2015-04-
On 20/04/15 21:30, James Greenhalgh wrote:
On Mon, Apr 20, 2015 at 05:24:39PM +0100, Kyrill Tkachov wrote:
Hi all,
When trying to compile a testcase with -mcpu=cortex-a57+crypto+nocrc I got
the weird assembler error:
Assembler messages:
Error: missing architectural extension
Error: unrecognize
> On Wed, Apr 29, 2015 at 3:23 PM, Jan Hubicka wrote:
> >> Historically the pragma Inline_Always of GNAT had been implemented in the
> >> FE
> >> because the RTL inliner and then the Tree inliner weren't invoked at -O0 or
> >> powerful enough to inline some constructs. But this approach had
> >
Hi,
this is updated patch that passes all languages LTO and non-LTO testing on
ppc64.
I found few issues
- C++ FE messes up METHOD pointers becuase sometimes it duplicated a type while
METHOD list is incomplete, so there are type variants that points to the
middle
of the final list. (I sup
Hi Jakub!
On Wed, 29 Apr 2015 13:43:55 +0200, Jakub Jelinek wrote:
> On Wed, Apr 29, 2015 at 01:13:29PM +0200, Thomas Schwinge wrote:
> > On Wed, 29 Apr 2015 11:32:31 +0200, Jakub Jelinek wrote:
> > > Yeah, it is a non-starter, it has unnecessary runtime overhead everywhere
> > > where it is use
On Wed, Apr 29, 2015 at 04:31:32PM +0200, Thomas Schwinge wrote:
> > So yes, I really prefer OMP_STANDALONE_CLAUSES over OMP_CLAUSES for
> > everything.
>
> Like this (for trunk)?
>
> commit 300e28fce192cb56d73cb61f787872643030f0bf
> Author: Thomas Schwinge
> Date: Wed Apr 29 16:18:49 2015 +02
Thanks for the feedback. I have added comment and properly indented the code.
-Aditya
> Date: Wed, 29 Apr 2015 09:31:46 +0200
> From: ja...@redhat.com
> To: l...@redhat.com
> CC: hiradi...@msn.com; gcc-patches@gcc.gnu.org
> Subject: Re: Refactor gcc/tree-
Hi Jakub!
On Wed, 29 Apr 2015 14:06:44 +0200, Jakub Jelinek wrote:
> On Wed, Apr 29, 2015 at 01:52:24PM +0200, Thomas Schwinge wrote:
> > > --- gcc/tree-pretty-print.c.jj2015-04-29 10:58:01.663745452 +0200
> > > +++ gcc/tree-pretty-print.c 2015-04-29 11:03:04.648990986 +0200
> > > @@ -5
This patch adds the -fsanitize=bounds-strict option Martin U. wanted; it is
actually based on his earlier patch, I did only some small adjustments.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2015-04-29 Marek Polacek
Martin Uecker
* c-ubsan.c (ubsan_instrument_
Picking up this old back port request...
On 5 March 2015 at 06:36, Chen Shanyao wrote:
> +2015-03-05 Shanyao Chen
There should be two spaces after the date and two before the < marker
in a ChangeLog name line. This comment applies to each of the
ChangeLogs presented.
> +/* { dg-final { clea
I think this covers all the places in the library where we do:
++i, ++j
Tested powerpc64le-linux, committed to trunk.
commit 572881116b98ee50027dbd5e8880ea6d92e86cca
Author: Jonathan Wakely
Date: Sun Jan 18 17:04:10 2015 +
PR libstdc++/64657
* include/bits/basic_string (basic_
On 04/28/2015 08:22 PM, Jan Hubicka wrote:
I also looked into extend.texi and both __builtin_alloca and
__builtin_alloca_with_align
is missing (along with many other builtins) which is probably quite bad omission
(__builtin_alloca_with_align is used at some places, i.e. in Firefox)
Sandra, sin
Hi all,
this is the fourth version of the patch, adapting to the current state of
trunk. This patch is based on my patch for 65584 version 2 and needs that patch
applied beforehand to apply cleanly. The patch for 65548 is available from:
https://gcc.gnu.org/ml/fortran/2015-04/msg00121.html
Scope
On Wed, Apr 29, 2015 at 05:25:39PM +0200, Thomas Schwinge wrote:
> Done. (I also reverted the gcc/cp/pt.c:tsubst_expr change which
> motivated this patch; will include that with the patch adding support for
> C++ templates usage with OpenACC directives.) OK for trunk?
Ok, thanks.
Jakub
Hi Jakub!
On Wed, 29 Apr 2015 16:36:24 +0200, Jakub Jelinek wrote:
> On Wed, Apr 29, 2015 at 04:31:32PM +0200, Thomas Schwinge wrote:
> > > So yes, I really prefer OMP_STANDALONE_CLAUSES over OMP_CLAUSES for
> > > everything.
> >
> > Like this (for trunk)?
> >
> > commit 300e28fce192cb56d73cb61
Hi!
On Wed, 29 Apr 2015 17:28:54 +0200, Jakub Jelinek wrote:
> On Wed, Apr 29, 2015 at 05:25:39PM +0200, Thomas Schwinge wrote:
> > Done. (I also reverted the gcc/cp/pt.c:tsubst_expr change which
> > motivated this patch; will include that with the patch adding support for
> > C++ templates usag
On Mon, Apr 27, 2015 at 3:41 PM, Jonathan Wakely wrote:
> On 27 April 2015 at 23:33, Doug Evans wrote:
>> Hi.
>>
>> While we should eventually get the xmethods to handle cxx11,
>> this patch fixes the current failure.
>> The xmethod matcher doesn't currently handle __cxx11 in the type name.
>>
>>
When bfd is configured as a shared library, we need to configure zlib
with --enable-host-shared since zlib is used by bfd. Any comments,
feedbacks, objections?
H.J.
--
PR ld/18355
* Makefile.def: Add extra_configure_flags to host zlib.
* configure.ac (extra_host_zlib_conf
On 17/04/15 01:03 +0200, Daniel Krügler wrote:
2015-04-16 14:33 GMT+02:00 Jonathan Wakely :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65760
I don't understand why commenting out *any one* of the lines marked
(1), (2), (3), (4) causes this to compile:
#include
struct C {
C() = default;
On 29 April 2015 at 17:04, Doug Evans wrote:
> Tested the same patch on the gcc 5.0 branch.
> Just double checking ... ok to apply there too?
Yes, OK for the branch too.
> btw, the test is currently marked as unsupported by the test run.
> I don't know what would be involved in marking it as fail
Hi!
On Tue, 28 Apr 2015 15:24:08 +0200, Bernd Schmidt
wrote:
> On 04/27/2015 06:08 PM, Thomas Schwinge wrote:
>
> >>> OK to do the following instead? (Coding style/code copied from
> >>> gcc/config/i386/intelmic-mkoffload.c for consistency.)
>
> Err, was this a question for me? I'm fine with
Hello!
> 2015-03-27 Caroline Tice
>
> * final.c (final_scan_insn): Change 'cold_function_name' to
> 'cold_partition_name' and make it a global variable; also output
> assembly to give it a 'FUNC' type, if appropriate.
> * varasm.c (cold_partition_name): Declare a
On Tue, Apr 28, 2015 at 09:07:09PM -0600, Martin Sebor wrote:
> The error message in the test cases below isn't quite right.
> The type of the aggregates isn't undefined, it's incomplete.
> Looking at the function, I wonder if the first argument
> should be EXPR rather than than NULL_TREE? Alternat
This fixes the remaining regressions. With the new design for
check_global_declaration*(), we diagnose many more warnings and so far,
no false positives.
Committed to branch.
commit 7aeb35184b29f3c67470b63fcf107b54f075ffd7
Author: Aldy Hernandez
Date: Wed Apr 29 09:43:48 2015 -0700
Adj
Hi.
This patch splits out from the patch for 65839 the consistent naming
suggested here.
https://gcc.gnu.org/ml/libstdc++/2015-04/msg00155.html
Regression tested on amd64-linux.
Ok to commit?
2015-04-29 Doug Evans
Use consistent naming for value type attributes.
* python/lib
Hello Venkat,
On Wed, Apr 29, 2015 at 09:25:21AM +, Kumar, Venkataramanan wrote:
> diff --git a/gcc/combine.c b/gcc/combine.c
> index 5c763b4..945abdb 100644
> --- a/gcc/combine.c
> +++ b/gcc/combine.c
> @@ -7703,8 +7703,6 @@ make_compound_operation (rtx x, enum rtx_code in_code)
> but o
Hi Julian!
On Fri, 24 Apr 2015 18:13:08 +0100, Julian Brown
wrote:
> On Thu, 23 Apr 2015 18:41:34 +0200
> Thomas Schwinge wrote:
> > On Wed, 22 Apr 2015 19:42:43 +0100, Julian Brown
> > wrote:
> > > This patch is an attempt to fix some potential race conditions with
> > > accesses to shared da
The attached patch can revert the previous patch, if that is the way
we should proceed on this. If you want me to apply the reversion,
please let me know.
I would be happy to fix to the problem, rather than just reverting the
patch, but I do not have expertise in assembly language on other
platfo
On Wed, Apr 29, 2015 at 7:38 PM, Caroline Tice wrote:
> The attached patch can revert the previous patch, if that is the way
> we should proceed on this. If you want me to apply the reversion,
> please let me know.
>
> I would be happy to fix to the problem, rather than just reverting the
> patch
On Tue, Apr 28, 2015 at 5:16 AM, Jonathan Wakely wrote:
> On 27/04/15 15:44 -0700, Doug Evans wrote:
>>
>> PR libstdc++/65839
>> * python/libstdcxx/v6/xmethods.py (get_bool_type): New function.
>> Replace all lookups of "bool" with this.
>> (get_std_size_type): New
On 29/04/15 09:49 -0700, Doug Evans wrote:
Hi.
This patch splits out from the patch for 65839 the consistent naming
suggested here.
https://gcc.gnu.org/ml/libstdc++/2015-04/msg00155.html
Regression tested on amd64-linux.
Ok to commit?
Thanks for doing this, OK to commit.
On 29/04/15 10:57 -0700, Doug Evans wrote:
On Tue, Apr 28, 2015 at 5:16 AM, Jonathan Wakely wrote:
On 27/04/15 15:44 -0700, Doug Evans wrote:
PR libstdc++/65839
* python/libstdcxx/v6/xmethods.py (get_bool_type): New function.
Replace all lookups of "bool" with this.
On Wed, Apr 29, 2015 at 7:47 PM, Uros Bizjak wrote:
> On Wed, Apr 29, 2015 at 7:38 PM, Caroline Tice wrote:
>> The attached patch can revert the previous patch, if that is the way
>> we should proceed on this. If you want me to apply the reversion,
>> please let me know.
>>
>> I would be happy t
This patch cleans up c_incomplete_type_error a bit: today, we should prefer
using %qT over %<%s %E%> (the code is largely intact since 1992), and second,
we should print the type if we can. The "invalid use of incomplete typedef"
error wasn't tested at all, so I'm also adding a test to exercise th
cpplib-5.1.0.sv.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Swedish team of translators. The file is available at:
http://translationproject.org/latest/cpplib/sv.po
(This file, 'cpplib-5.1.0.sv.po',
Thank you; I will work with your suggestions and try to get a new
patch done soon.
-- Caroline Tice
cmt...@google.com
On Wed, Apr 29, 2015 at 11:34 AM, Uros Bizjak wrote:
> On Wed, Apr 29, 2015 at 7:47 PM, Uros Bizjak wrote:
>> On Wed, Apr 29, 2015 at 7:38 PM, Caroline Tice wrote:
>>> The att
Hello!
Attached patch implements a CCZ-only setting pattern for a couple of
BMI[,2] intrinsics.
2015-04-29 Uros Bizjak
PR target/65871
* config/i386/i386.md (*bmi_bextr__cczonly): New pattern.
(*bmi2_bzhi_3_1_cczonly): Ditto.
testsuite/ChangeLog:
2015-04-29 Uros Bizjak
P
On 04/29/2015 03:25 AM, Kumar, Venkataramanan wrote:
Hi Jeff/Segher,
Restarting the discussion on the GCC combiner assumption about Memory/address
type.
Ref: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01298.html
https://gcc.gnu.org/ml/gcc/2015-04/msg00028.html
Regards,
Venkat.
PS: I am
On 04/29/2015 11:03 AM, Segher Boessenkool wrote:
Right. It would be good if you could find out for what targets it matters.
The thing is, if a target expects only the patterns as combine used to make
them, it will regress (as you've seen on aarch64); but it will regress
_silently_. Which isn'
On 04/29/2015 03:25 AM, Kumar, Venkataramanan wrote:
Hi Jeff/Segher,
When we see an RTX code with PLUS or MINUS then it is treated as MEM/address
type (we are inside address RTX).
Is there any significance on that assumption? I removed this assumption and
the test case in the PR 63949 passe
On Wed, Apr 29, 2015 at 09:02:16PM +0200, Uros Bizjak wrote:
> Hello!
>
> Attached patch implements a CCZ-only setting pattern for a couple of
> BMI[,2] intrinsics.
What about the case when the result is used, but also tested for zero or
non-zero? Like e.g.
int bar (void);
int foo (unsigned int
On Wed, Apr 29, 2015 at 9:23 PM, Jakub Jelinek wrote:
> On Wed, Apr 29, 2015 at 09:02:16PM +0200, Uros Bizjak wrote:
>> Hello!
>>
>> Attached patch implements a CCZ-only setting pattern for a couple of
>> BMI[,2] intrinsics.
>
> What about the case when the result is used, but also tested for zero
On 04/28/2015 09:01 PM, Aldy Hernandez wrote:
The approach looks good to me.
- analyze_functions ();
+ analyze_functions (true);
In the C++ front end at least we comment anonymous boolean arguments, i.e.
analyze_functions (/*first_time*/true);
Let's do that here, too. Similarly for the
1 - 100 of 144 matches
Mail list logo
