On 06/12/2015 12:11 PM, Kai Tietz wrote:
@@ -589,9 +589,9 @@ null_member_pointer_value_p (tree t)
return false;
else if (TYPE_PTRMEMFUNC_P (type))
return (TREE_CODE (t) == CONSTRUCTOR
- && integer_zerop (CONSTRUCTOR_ELT (t, 0)->value));
+ && integer_zerop (fold
On Jun 12, 2015, at 8:25 PM, Jack Howarth wrote:
> The attached patch revises the tests for the filds and fists
> mnemonics to use the assembly...
>
> filds mem(%rip); fists mem(%rip)
> Okay for gcc trunk?
Fine from a darwin perspective, but I would like an x86 binutils person to
weigh in to
The attached patch revises the tests for the filds and fists
mnemonics to use the assembly...
filds mem(%rip); fists mem(%rip)
and the test for the fildq and fistq mnemonics to use the assembly...
fildq mem(%rip); fistpq mem(%rip)
which will assemble for both 64-bit and 32-bit mode. This is
OK.
Jason
On Fri, 12 Jun 2015, Andres Tiraboschi wrote:
> Hi, this patch is for adding a warning when a constexpr cannot be evaluated
> at compile time.
> This is a single case:
> type var = fun(args...), with fun declared as a constexpr.
All options need documenting in invoke.texi. All diagnostics need
Hi, this patch is for adding a warning when a constexpr cannot be evaluated at
compile time.
This is a single case:
type var = fun(args...), with fun declared as a constexpr.
diff --git a/gcc/common.opt b/gcc/common.opt
index b49ac46..88374b1 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -5
Hi everybody!
In the current implementation of if conversion, loads and stores are
if-converted in a thread-unsafe way:
* loads were always executed, even when they should have not been.
Some source code could be rendered invalid due to null pointers
that were OK in the original program
We have 5 patterns that can emit the movi instruction. These patterns
map it to 4 different type attributes. The mov_aarch64 pattern
uses mov_imm. The movdi_aarch64 pattern uses fmov. The movtf_aarch64
pattern uses fconstd. And the two aarch64_simd_mov patterns for
VD and VQ use neon_move. Bi
On 06/03/2015 05:35 PM, Jim Wilson wrote:
> I noticed that poor code is emitted for a long double 0.0.
ping
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00370.html
Jim
In this testcase, the problem is that const variables are implicitly
static, and static variables get DECL_INTERFACE_KNOWN set. Then when
instantiating the variable we set DECL_EXTERNAL, with the effect that we
are saying that we know that we aren't defining the variable in the
current transla
Hi
This is a patch to:
- Enhance __get_distance to get a better feedback about distance between
iterators so that we can take sharper decision about what is right or
not. This function is now aware about safe iterators and leverage on
those a little like std::distance does with C++ 11 list::i
Sigh. I must say my head is spinning with this testcase and what we do
with it (-O3), even prior to the debug-early work:
void f(int p) {}
int g() {
void f(int p);
g();
return 0;
}
The inliner recursively inlines this function up to a certain depth, but
the useless inlining gets cleaned
On Thu, Apr 30, 2015 at 01:34:18PM +0100, Bill Schmidt wrote:
> On Thu, 2015-04-30 at 18:26 +0800, Bin.Cheng wrote:
> > On Mon, Apr 27, 2015 at 9:26 PM, Bill Schmidt
> > wrote:
> > > On Mon, 2015-04-27 at 14:23 +0800, Bin.Cheng wrote:
> > >> On Mon, Mar 30, 2015 at 1:42 AM, Bill Schmidt
> > >> wr
Hi!
I've committed following parsing support for
#pragma omp criticial (foobar) hint (omp_lock_hint_uncontended)
and a header only change in libgomp for the omp_init*lock_with_hint
APIs.
We'll need to decide if we want to implement the hinted locks and how
first I guess (I believe Intel is using
Hello Jason,
Thanks for the review. I addressed a lot of your comments directly on
svn-branch. See revision r224439.
- Ursprüngliche Mail -
> Generally, it seems like most of my comments from April haven't been
> addressed yet.
Yes, most of them.
> > @@ -3023,13 +3023,14 @@ conversi
Hi,
Since debug is not initialised at the time built-ins are initialised, whilst
the latter may make forward declarations, those should not be considered for
early debug,
bootstrapped / tested on x86_64-darwin12 and x86_64-linux-gnu.
OK?
Iain
gcc:
PR bootstrap/66448
* passes.c
On Fri, 2015-06-12 at 10:30 +0100, Ramana Radhakrishnan wrote:
> On Fri, Jun 12, 2015 at 10:06 AM, Jonathan Wakely wrote:
> > On 11/06/15 23:56 +0200, Torvald Riegel wrote:
> >>>
> >>> > On Fri, 2015-05-22 at 12:37 +0100, Ramana Radhakrishnan wrote:
> >>> I don't think we can remove _GLIBCXX_READ_
On Fri, Jun 12, 2015 at 03:56:10PM +0200, Michael Matz wrote:
> Hi,
>
> this backports the fix for debug info of PR63623 to the 4.8 and 4.9
> branches. Without this shrink-wrapped functions often have invalid debug
> info for parameters. Bootstrapped and regtested 4.8 and 4.9 with this on
> x
Hi,
this backports the fix for debug info of PR63623 to the 4.8 and 4.9
branches. Without this shrink-wrapped functions often have invalid debug
info for parameters. Bootstrapped and regtested 4.8 and 4.9 with this on
x86_64-linux, no regressions (for my machine/gdb combination 4.8 has two
m
On 06/12/2015 01:11 PM, Richard Biener wrote:
By the way, I think we should apply this fix to the GCC 5 branch as
well. May I?
Yes
Done. Thanks again!
--
Pierre-Marie de Rodat
On 06/12/2015 12:22 AM, Andreas Schwab wrote:
../../gcc/dwarf2out.c:5693:1: error: 'void check_die(dw_die_ref)' defined but
not used [-Werror=unused-function]
Andreas.
Committed as obvious.
commit 76da2378b15ad786e8c2c64ddd8b39c132947738
Author: Aldy Hernandez
Date: Fri Jun 12 06:42:08 20
Hi all,
Here is the next battle in the war against manual swapping, this time in ifcvt.
Bootstrapped and tested on aarch64, x86_64.
Committed as obvious with r224429.
Thanks,
Kyrill
2015-06-12 Kyrylo Tkachov
* ifcvt.c (noce_try_store_flag_constants): Use std::swap instead of
This patch teaches all of the front ends how to error on duplicate
device_type entries such as
#pragma acc parallel device_type (nvidia) num_gangs (1) \
device_type (nvidia) num_gangs (20)
Before such clauses were silently ignored. I also fixed how invalid
device_type claues are reported
and were not included in the precompiled
headers.
Tested powerpc64le-linux, committed to trunk.
commit 66c9926b63b5dd333f310fa621d5c495deb77681
Author: Jonathan Wakely
Date: Fri Jun 12 12:42:41 2015 +0100
* include/precompiled/stdc++.h: Include and .
diff --git a/libstdc++-v3/include
Hi!
I've committed following patch to add C/C++ parsing of simd: schedule
clause modifier, and a very rough implementation of it for
schedule with chunk and dynamic schedule kinds.
No idea what to do about runtime schedule, because there we don't pass
a chunk size to the library routine.
And for n
This patch brings three new patterns for match.pd. I think these are
rare, but it shouldn't hurt to have them.
(I suppose you'd be happier if I was moving patterns from fold-const to
match.pd. I'll work on that as well.)
Given previous discussion, I don't think there's much to say otherwise,
but
On June 12, 2015 1:19:15 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>Is this ok to apply to 4.8 and 4.9 branches?
>Successfully bootstrapped/regtested on these branches on x86_64-linux
>and
>i686-linux, testcase is fixed.
OK.
Thanks,
Richard.
>2015-06-12 Jakub Jelinek
>
> Backported fro
On June 12, 2015 1:17:14 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>The following testcase ICEs in 4.8/4.9. The problem is that we don't
>fold
>NON_LVALUE_EXPR of INTEGER_CST into the INTEGER_CST, but it seems huge
>amount of fold-const.c code has the assumption that if
>argN = opN;
>...
>STRIP_N
On June 12, 2015 1:20:19 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>Bootstrapped/regtested on 4.8 and 4.9 branches on x86_64-linux and
>i686-linux, ok for 4.8/4.9?
OK.
Thanks,
Richard.
>2015-06-12 Jakub Jelinek
>
> Backported from mainline
> 2015-04-09 Richard Biener
>
>
Hi!
Bootstrapped/regtested on 4.8 and 4.9 branches on x86_64-linux and
i686-linux, ok for 4.8/4.9?
2015-06-12 Jakub Jelinek
Backported from mainline
2015-04-09 Richard Biener
PR pch/65550
* files.c (pch_open_file): Allow main and pre-included files
Hi!
Is this ok to apply to 4.8 and 4.9 branches?
Successfully bootstrapped/regtested on these branches on x86_64-linux and
i686-linux, testcase is fixed.
2015-06-12 Jakub Jelinek
Backported from mainline
2014-12-15 Vladimir Makarov
PR target/62642
* ira.c
Hi!
The following testcase ICEs in 4.8/4.9. The problem is that we don't fold
NON_LVALUE_EXPR of INTEGER_CST into the INTEGER_CST, but it seems huge
amount of fold-const.c code has the assumption that if
argN = opN;
...
STRIP_NOPS (argN);
...
if (TREE_CODE (argN) == INTEGER_CST)
then argN == opN
On June 12, 2015 12:31:02 PM GMT+02:00, Pierre-Marie de Rodat
wrote:
>On 06/12/2015 07:41 AM, Richard Biener wrote:
>> On June 12, 2015 2:30:36 AM GMT+02:00, David Edelsohn
> wrote:
>>> This patch broke AIX bootstrap because dbxout.c was not updated for
>>> the XCOFF_DEBUGGING_INFO case.
>>
>> OK
I didn't drop the test case and i have tested that case on my
manchine(aarch64-linux) with qemu.
I am sorry I forgot to add the testcase in the last patch.
A new patch was added to the accessory.
I am a new guy to the community and I will try my best to accord with the norm
of the community nex
On Fri, Jun 12, 2015 at 12:27 PM, Kumar, Venkataramanan
wrote:
>> > Ok for trunk ?
>>
>> OK for mainline with a small improvement below.
>>
>> +case IX86_BUILTIN_MONITORX:
>> + arg0 = CALL_EXPR_ARG (exp, 0);
>> + arg1 = CALL_EXPR_ARG (exp, 1);
>> + arg2 = CALL_EXPR_ARG (exp, 2)
On 06/12/2015 07:41 AM, Richard Biener wrote:
On June 12, 2015 2:30:36 AM GMT+02:00, David Edelsohn wrote:
This patch broke AIX bootstrap because dbxout.c was not updated for
the XCOFF_DEBUGGING_INFO case.
OK.
Thanks
Richard.
By the way, I think we should apply this fix to the GCC 5 branch
Hi Uros,
> -Original Message-
> From: Uros Bizjak [mailto:ubiz...@gmail.com]
> Sent: Thursday, June 11, 2015 3:50 PM
> To: Kumar, Venkataramanan
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] [X86_64]: Add support for MONITORX and MWAITX ISA
>
> On Thu, Jun 11, 2015 at 11:49 AM, Ku
Fixes a silly copy&paste error.
Tested powerpc64le-linux, committing to trunk and gcc-5-branch.
commit c7bb5649cc5706117a724dff484ecae8382279e1
Author: Jonathan Wakely
Date: Fri Jun 12 10:44:50 2015 +0100
PR libstdc++/66464
* src/c++11/codecvt.cc (codecvt_utf16_base::do_max_length):
Sorry about that. The new patch contains code diff.
The ICE i want to fix:
(aarch64_strip_extend_or_extend): ...this, don't strip shifts, check
RTX is well formed.
If the patch is not applied,the following compilation will cause a Seg fault:
../../install/bin/aarch64-linux-gnu-gcc -w -O2
On 06/12/2015 07:41 AM, Richard Biener wrote:
On June 12, 2015 2:30:36 AM GMT+02:00, David Edelsohn wrote:
This patch broke AIX bootstrap because dbxout.c was not updated for
the XCOFF_DEBUGGING_INFO case.
OK.
Thanks
Richard.
Sorry about that and thank you for the fix!
--
Pierre-Marie de R
On 12/06/15 10:30 +0100, Ramana Radhakrishnan wrote:
On Fri, Jun 12, 2015 at 10:06 AM, Jonathan Wakely wrote:
On 11/06/15 23:56 +0200, Torvald Riegel wrote:
> On Fri, 2015-05-22 at 12:37 +0100, Ramana Radhakrishnan wrote:
I don't think we can remove _GLIBCXX_READ_MEM_BARRIER and
_GLIBCXX_WRIT
On 06/12/2015 11:24 AM, Jakub Jelinek wrote:
> Looks mostly good, just wonder about the powerpc scan-assembler.
> Shouldn't that be "reg: (%r)?8" instead? I think powerpc has -mregnames
> option, dunno if some target doesn't even use it by default.
Good catch. I'll change that.
-Andreas-
On Fri, Jun 12, 2015 at 10:06 AM, Jonathan Wakely wrote:
> On 11/06/15 23:56 +0200, Torvald Riegel wrote:
>>>
>>> > On Fri, 2015-05-22 at 12:37 +0100, Ramana Radhakrishnan wrote:
>>> I don't think we can remove _GLIBCXX_READ_MEM_BARRIER and
>>> _GLIBCXX_WRITE_MEM_BARRIER from atomic_word.h even th
On Fri, Jun 12, 2015 at 10:52:56AM +0200, Andreas Krebbel wrote:
> Yes that's better. I've adjusted the testcase as you proposed and
> have tested it on x86_64, ppc, and s390x with -m32(-m31) and -m64.
As I said earlier, talking just about the testcase, leaving review to Jason.
> --- /dev/null
>
Hi,
On Thu, 11 Jun 2015 13:17:47 +0200, Eric Botcazou wrote:
>
>> Other than that, as I said already in the PR, I'm in favor of applying it to
>> the trunk (only, not release branches) and watching for performance and/or
>> wrong-code issues, but Eric is against it. What do others think about it?
On Thu, Jun 11, 2015 at 11:35 AM, Uros Bizjak wrote:
> Hello!
>
> We can use MEMMODEL_BASE_MASK here to avoid a couple of similar cases.
>
> 2015-06-11 Uros Bizjak
>
> * emit-rtl.c (need_atomic_barrier_p): Mask model with
> MEMMODEL_BASE_MASK. Remove MEMMODEL_SYNC_* cases.
>
> Tested o
Ping.
On Fri, Jun 05, 2015 at 10:55:08AM +0200, Marek Polacek wrote:
> On Thu, Jun 04, 2015 at 09:04:19PM +, Joseph Myers wrote:
> > The C changes are OK.
>
> Jason, do you want to approve the C++ parts?
>
> Thanks,
Marek
On 11/06/15 23:56 +0200, Torvald Riegel wrote:
> On Fri, 2015-05-22 at 12:37 +0100, Ramana Radhakrishnan wrote:
I don't think we can remove _GLIBCXX_READ_MEM_BARRIER and
_GLIBCXX_WRITE_MEM_BARRIER from atomic_word.h even though they are
superseded by the atomics as it is published in the document
On 11/06/15 23:43 -0700, Tim Shen wrote:
+ using element_type = _Tp[N];
using element_type = typename std::remove_extent_t<_Tp>; ?
Well at that point in the file we're inside the
__shared_ptr<__libfund_v1<_Tp[N]> specialization, so it could be
simply:
+ using element_type = _Tp;
Ho
On Fri, Jun 12, 2015 at 08:44:45AM +0200, Marc Glisse wrote:
> On Fri, 12 Jun 2015, Richard Biener wrote:
>
> >>Not judging at all whether it is desirable or not, but you might have
> >>hit the issue that when you want several convert?, you need to use the
> >>spelling convert1?, convert2?, and it
Yes that's better. I've adjusted the testcase as you proposed and
have tested it on x86_64, ppc, and s390x with -m32(-m31) and -m64.
Bye,
-Andreas-
gcc/cp/
2015-06-12 Andreas Krebbel
PR c++/33661
* decl.c (cp_finish_decl): Set assembler name for register
asm constru
On Thu, Jun 11, 2015 at 11:47:43PM +0200, Jan Hubicka wrote:
> Hi,
> gcc.c-torture/execute/930408-1.c currently ICE on -fshort-enum target(s)
> because
> TYPE_PACKED is not consistently set among type variants.
I guess that's because of the forward declaration in the test. But I have
no access
Add query for template-dependent arguments to -fdump-ada-spec:
http://gcc.gnu.org/ml/gcc-patches/2015-06/msg00403.html
Get rid of assembly file with -fdump-ada-spec:
http://gcc.gnu.org/ml/gcc-patches/2015-06/msg00420.html
Thanks in advance.
--
Eric Botcazou
Hi Thomas,
thanks for the review and valuing my effort.
I am on travel over the weekend, i.e., I will commit the job earliest on Monday
giving objections a bit more time.
Regards and thanks,
Andre
On Thu, 11 Jun 2015 23:59:48 +0200
Thomas Koenig wrote:
> Hi Andre,
>
> > please find
../../gcc/dwarf2out.c:5693:1: error: 'void check_die(dw_die_ref)' defined but
not used [-Werror=unused-function]
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
55 matches
Mail list logo
