On Fri, Oct 3, 2014 at 8:52 AM, Jakub Jelinek wrote:
>> Tested with
>> GCC_TEST_RUN_EXPENSIVE=1 make -k check-gcc \
>> RUNTESTFLAGS='--target_board=unix/-mavx2 dg-torture.exp=vshuf*.c'
>> on x86_64-linux, ok for trunk if it passes bootstrap?
>>
>> As for the previous testcase with distilled pr522
Christophe Lyon writes:
> I've looked at debug info from dejagnu, and it really seems that
> abi_check is called with no argument, hence the error.
>
> What am I doing wrong?
That must be something unrelated, hidden since that test was never run
before. testsuite/libstdc++-abi/abi.exp clearly r
Hi!
Got surprised by seeing vect_suffle3* variable names in the dumps,
fixed thusly, committed as obvious to trunk.
2014-10-03 Jakub Jelinek
* tree-vect-data-refs.c (vect_permute_load_chain,
vect_shift_permute_load_chain): Fix a typo in temporary var names,
suffle3 to
Hi!
This patch fixes a problem where after processing some omp parallel
with shared clause on some non-addressable var (where we decide to
use copy-in/out for it) we process omp task with shared clause on the
same var and for task shared vars we can't use copy-in/out ever, thus
have to force it ad
On 03 Oct 00:05, Ilya Enkovich wrote:
> 2014-10-02 22:30 GMT+04:00 Jeff Law :
> > On 10/02/14 08:30, Ilya Enkovich wrote:
> >>
> >> Hi,
> >>
> >> This patch adds a check for call destination register for a call return
> >> value optimization based on REG_RETURNED note. This solves some ICE issues
Since we still don't have a final decision about how instrumented builtin
functions would look like, I replace this patch with a new one which assumes we
don't instrument them for now. It only has an additional init for va_start and
also makes sure there is no instrumented builtin calls. All i
On 3 October 2014 09:55, Andreas Schwab wrote:
> Christophe Lyon writes:
>
>> I've looked at debug info from dejagnu, and it really seems that
>> abi_check is called with no argument, hence the error.
>>
>> What am I doing wrong?
>
> That must be something unrelated, hidden since that test was ne
On 09/17/2014 04:38 PM, Pierre-Marie de Rodat wrote:
Ping for https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00206.html
Adding a few maintainers in copy... Thanks in advance!
Should I enhance something in this patch set in order to make the review
easier? Thanks!
--
Pierre-Marie de Rodat
Hi,
This patch avoids generation of __builtin_unreachable calls marked as
instrumented. It follows paradigma of no instrumented builtin calls (and
passes corresponding assert in expand_builtin from patch #18).
Thanks,
Ilya
--
2014-10-01 Ilya Enkovich
* cgraphunit.c (walk_polymorphi
On Wed, Sep 03, 2014 at 10:36:21AM +0200, Pierre-Marie de Rodat wrote:
> --- a/gcc/dwarf2out.c
> +++ b/gcc/dwarf2out.c
> @@ -17359,18 +17359,36 @@ static void
> gen_descr_array_type_die (tree type, struct array_descr_info *info,
> dw_die_ref context_die)
> {
> - dw_die_re
On Fri, Oct 03, 2014 at 11:18:48AM +0200, Jakub Jelinek wrote:
> > gcc/fortran/
> > * trans-types.c (gfc_get_array_descr_info): Use PLACEHOLDER_EXPR nodes
> > instead of VAR_DECL ones in type-related expressions. Remove base_decl
> > initialization.
>
> Ugh, I must say I don't like PL
On 08/21/2014 01:57 PM, Martin Liška wrote:
Ping.
There was no explicit agreement that I can commit the change to trunk?
Thanks,
Martin
On 07/30/2014 08:19 PM, Martin Liška wrote:
On 07/30/2014 06:38 PM, Mike Stump wrote:
On Jul 30, 2014, at 6:20 AM, Richard Biener wrote:
On Wed, Jul 30, 2
On 3 October 2014 06:03, Ed Smith-Rowland wrote:
> Built and tested clean on x86_64-linux.
>
> OK?
>
> Ed
>
The changelog just says "Add" for testsuite_tr1.h, I assume it should
say something like "Add FinalType"
OK with that change, thanks.
2014-10-03 Edward Smith-Rowland <3dw...@verizon.net>
"David Sherwood" writes:
> Hi Andreas,
>
> OK, I will fix this.
I installed David's patch below as obvious. Tested on x86_64-linux-gnu.
Thanks,
Richard
gcc/
2014-10-03 David Sherwood
* ira-int.h (ira_allocno): Mark hard_regno as signed.
Index: gcc/ira-int.h
==
Hello Uroš,
On 29 Sep 09:54, Uros Bizjak wrote:
> > +(define_expand "vashrv2di3"
> > + [(set (match_operand:V2DI 0 "register_operand")
> > + (ashiftrt:V2DI
> > + (match_operand:V2DI 1 "register_operand")
> > + (match_operand:V2DI 2 "nonimmediate_operand")))]
> > + "TARGET_XO
Hello Uroš,
On 29 Sep 10:00, Uros Bizjak wrote:
> > + /* There is no vandnp[sd] in avx512f. Use vpandn[qd]. */
> > + if (!TARGET_AVX512DQ)
>
> All other patterns also have " &&" condition here. Is
> the above condition correct?
I think this is correct since in this pattern we use AVX-512 only
Hello Uroš,
On 29 Sep 10:08, Uros Bizjak wrote:
> On Fri, Sep 26, 2014 at 4:09 PM, Kirill Yukhin
> wrote:
> > +(define_insn "avx512bw_pmaddubsw512"
> > + [(set (match_operand:VI2_AVX512VL 0 "register_operand" "=v")
> > + (unspec:VI2_AVX512VL
> > +[(match_operand: 1 "register
On Fri, Oct 3, 2014 at 12:26 PM, Kirill Yukhin wrote:
> Hello Uroš,
> On 29 Sep 09:54, Uros Bizjak wrote:
>> > +(define_expand "vashrv2di3"
>> > + [(set (match_operand:V2DI 0 "register_operand")
>> > + (ashiftrt:V2DI
>> > + (match_operand:V2DI 1 "register_operand")
>> > + (m
On Fri, Oct 3, 2014 at 12:49 PM, Kirill Yukhin wrote:
> Hello Uroš,
> On 29 Sep 10:00, Uros Bizjak wrote:
>> > + /* There is no vandnp[sd] in avx512f. Use vpandn[qd]. */
>> > + if (!TARGET_AVX512DQ)
>>
>> All other patterns also have " &&" condition here. Is
>> the above condition correct?
> I
On Fri, Oct 3, 2014 at 1:03 PM, Kirill Yukhin wrote:
> Hello Uroš,
> On 29 Sep 10:08, Uros Bizjak wrote:
>> On Fri, Sep 26, 2014 at 4:09 PM, Kirill Yukhin
>> wrote:
>> > +(define_insn "avx512bw_pmaddubsw512"
>> > + [(set (match_operand:VI2_AVX512VL 0 "register_operand" "=v")
>> > + (un
On Thu, Oct 02, 2014 at 08:34:40PM +0200, Uros Bizjak wrote:
> Index: i386.c
> ===
> --- i386.c (revision 215802)
> +++ i386.c (working copy)
> @@ -43407,8 +43407,10 @@ expand_vec_perm_pblendv (struct expand_vec_perm_d
>
This patch is a cleanup of tests in gcc.dg/gomp/ directory.
See https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02656.html for more info.
Tested on x86_64-linux: vanilla results == results with this patch ==
results with this patch and gnu11 as a default.
Applying to trunk.
2014-10-03 Marek Polac
On Fri, Oct 3, 2014 at 1:11 PM, Jakub Jelinek wrote:
> On Thu, Oct 02, 2014 at 08:34:40PM +0200, Uros Bizjak wrote:
>> Index: i386.c
>> ===
>> --- i386.c (revision 215802)
>> +++ i386.c (working copy)
>> @@ -43407,8 +43407,1
This is the patch I intend to commit to make std::list::size() O(1) as
required by C++11.
This is an ABI change, so std::list will get tagged with
abi_tag("cxx11") so that it mangles differently.
I took a different approach to the way O(1) size() was implemented
(and then reverted) for GCC 4.7.0
Hi all,
This patch disables generation of asan_init calls for KASan as discussed
in https://lkml.org/lkml/2014/9/26/711
Bootstrapped and regtested no x64. Ok to commit?
-Y
commit 91c015e54687666f4abf6745f33c2eee8e569d17
Author: Yury Gribov
Date: Fri Oct 3 11:53:38 2014 +0400
2014-10-0
On Fri, Oct 03, 2014 at 05:07:01PM +0400, Yury Gribov wrote:
> Hi all,
>
> This patch disables generation of asan_init calls for KASan as discussed in
> https://lkml.org/lkml/2014/9/26/711
>
> Bootstrapped and regtested no x64. Ok to commit?
Ok, thanks.
> commit 91c015e54687666f4abf6745f33c2eee
Looks good to me
On Fri, Oct 3, 2014 at 5:07 PM, Yury Gribov wrote:
> Hi all,
>
> This patch disables generation of asan_init calls for KASan as discussed in
> https://lkml.org/lkml/2014/9/26/711
>
> Bootstrapped and regtested no x64. Ok to commit?
>
> -Y
>
> commit 91c015e54687666f4abf6745f33c2e
A debugger not knowing whether a special member function was explicitly
defaulted, implicitly declared or explicitly defined seems less confusion
than not knowing whether it was deleted. But there are some subtle cases
where knowing whether a constructor was user defined or explicitly
defaulted do
Currently we output a declaration of the explicitly deleted function
in DWARF. That seems wrong. An alternative to adding an attribute would
be to just not output the declaration. But that is also confusing since
then it looks precisely the same as an class that has that special
function implicitly
I think after 12 years it's safe to say that alternative version ain't
gonna happen.
Committed to trunk.
commit 14a8726815925137217b4282cf89460c547e7248
Author: Jonathan Wakely
Date: Fri Oct 3 14:28:44 2014 +0100
PR libstdc++/63449
* doc/xml/manual/containers.xml: Remove outdated
On 02 Oct 07:41, H.J. Lu wrote:
> On Thu, Oct 2, 2014 at 7:29 AM, Ilya Tocar wrote:
> > Hi,
> >
> > sizeof (long) == 4 on windows, so we should use long long as param type.
> > Patch below does it.
>
> The same is true for x32. Can you add a testcase to show it
> fails on x32 without the fix?
>
On 10/02/2014 02:00 PM, DJ Delorie wrote:
Ah, good point. In which case I don't see what this code is trying to
accomplish relative to falling through to the "prefer the unsigned one"
code below. Shall we just remove it?
I don't know for sure. There was __int128 code there, I replaced it
wit
On 10/02/2014 03:24 PM, Aldy Hernandez wrote:
If you are ok with this incremental patch, I will push it to the branch.
Looks good. In general I don't think you need to wait for approval
before checking something in on your own branch. :)
Jason
From: Andi Kleen
Add calls for several illegal Cilk cases to the C++ frontend.
C++ usually doesn't ICE unlike C on illegal cilk, but it's
better to match C in what is allowed and what is not.
if (_Cilk_spawn ...) is still not errored, but at least it doesn't ICE.
gcc/cp/:
2014-09-30 Andi Klee
This version addresses the localization problem pointed out by Joseph.
No other changes. I only reposted the two changed patches in the patchkit,
the others have already been approved.
Passes bootstrap and test suite on x86_64-linux.
-Andi
From: Andi Kleen
_Cilk_spawn or Cilk array expressions are only allowed on their own,
but not in for(), if(), switch, do, while, goto, etc.
The C parser didn't always check for that, which lead to ICEs earlier
for invalid code.
Add a generic helper that checks this and call it where needed
in th
I know It just makes me feel better to know we're in agreement. Old habits
die hard I guess ;-).
On Oct 3, 2014 7:08 AM, Jason Merrill wrote:
>
> On 10/02/2014 03:24 PM, Aldy Hernandez wrote:
> > If you aOn 10/02/2014 03:24 PM, Aldy Hernandez wrote:
> If you are ok with this incremental pat
On 10/02/2014 02:21 PM, Aldy Hernandez wrote:
Actually, I think we/I need to rethink this whole globals thing.
Currently we're early dumping global *_DECLs, and hoping dwarf2out
recursion will also pick up types and any derivatives from the *_DECLs,
but taking a closer look I've noticed a lot of
The LEON3/4 soft-core CPU has support for both SPARCv7 and SPARCv8 that
is configurable at design time. The majority of the LEON3 ASICs are v8
compatible, however when designing an as small LEON3 as possible, v7
without FPU is frequently used.
The current GCC leon3 support implies the SPARCv8 inst
OK.
Jason
Hi,
On 10/02/2014 11:22 PM, Eric Botcazou wrote:
[Sorry for the long delay]
The LEON3/4 soft-core CPU has support for both SPARCv7 and SPARCv8 that
is configurable at design time. The majority of the LEON3 ASICs are v8
compatible, however when designing an as small LEON3 as possible, v7
witho
On 10/03/2014 09:12 AM, Mark Wielaard wrote:
A debugger not knowing whether a special member function was explicitly
defaulted, implicitly declared or explicitly defined seems less confusion
than not knowing whether it was deleted. But there are some subtle cases
where knowing whether a construct
Hi!
This patch extends the gcc.dg/torture/ testsuite for
512-bit vectors. Tested with
GCC_TEST_RUN_EXPENSIVE=1 make -j32 check-gcc \
RUNTESTFLAGS='--target_board=unix\{-mavx2,-mavx,-mavx512f,-mavx512bw/-mavx512vl\}
dg-torture.exp=vshuf*.c'
(of course with expected AVX512* execution test failures
On Fri, 3 Oct 2014, Jonathan Wakely wrote:
This is the patch I intend to commit to make std::list::size() O(1) as
required by C++11.
This is an ABI change, so std::list will get tagged with
abi_tag("cxx11") so that it mangles differently.
Assuming a future where we have both _GLIBCXX_ABI_TAG_
On 03/10/14 14:36 +0100, Jonathan Wakely wrote:
I think after 12 years it's safe to say that alternative version ain't
gonna happen.
Committed to trunk.
Here's the patch for the 4.8 and 4.9 branches, which also updates the
notes on std::list::size() being O(N) (in the words of Whitney
Houston,
On Wed, Sep 17, 2014 at 5:11 PM, Andrey Turetskiy
wrote:
> On Wed, Sep 17, 2014 at 3:19 PM, Bernd Schmidt
> wrote:
>> I have no objections to supporting a -ftarget-options switch. I had posted a
>> patch a while ago that looked somewhat similar, but also contained an
>> automatic translation ste
Hi!
I've noticed that expand_vec_perm_1 completely uselessly builds GC garbage
(CONST_VECTOR at least) when AVX512F isn't enabled at all.
Ok to just call it for AVX512F?
Even better would be to check the modes first too depending on target
(AVX512F will only handle V{8D,16S}{I,F}mode, AVX512BW w
On 09/24/2014 12:18 AM, Ilmir Usmanov wrote:
> Hi Cesar!
>
> Thank you for the patch!
>
> On 24.09.2014 02:29, Cesar Philippidis wrote:
>> This patch adds support for the async clause in the wait directive in
>> fortran. It should be pretty straight forward. The fortran FE already
>> supports the
On Fri, Oct 3, 2014 at 4:32 PM, Jakub Jelinek wrote:
> Hi!
>
> I've noticed that expand_vec_perm_1 completely uselessly builds GC garbage
> (CONST_VECTOR at least) when AVX512F isn't enabled at all.
>
> Ok to just call it for AVX512F?
OK.
> Even better would be to check the modes first too depen
On Fri, 2014-10-03 at 10:17 -0400, Jason Merrill wrote:
> On 10/03/2014 09:12 AM, Mark Wielaard wrote:
> > A debugger not knowing whether a special member function was explicitly
> > defaulted, implicitly declared or explicitly defined seems less confusion
> > than not knowing whether it was delete
Hi!
Just to stress the new testcases some more, I've enabled the
vec_perm_const{32hi,64qi} patterns.
Got several ICEs in expand_vec_perm_broadcast_1,
on the final gcc_unreachable () in the function. That function
is only called if it couldn't be broadcasted in a single insn,
which I believe for T
On Thu, Sep 18, 2014 at 7:05 PM, Jing Yu wrote:
> 2014-09-18 Jing Yu
> * configure.ac: Add aarch64 to list of targets that support gold.
> * configure: Regenerate.
OK.
Thanks. Diego.
On 03/10/14 16:25 +0200, Marc Glisse wrote:
On Fri, 3 Oct 2014, Jonathan Wakely wrote:
This is the patch I intend to commit to make std::list::size() O(1) as
required by C++11.
This is an ABI change, so std::list will get tagged with
abi_tag("cxx11") so that it mangles differently.
Assuming
On Fri, Oct 3, 2014 at 6:46 AM, Ilya Tocar wrote:
> On 02 Oct 07:41, H.J. Lu wrote:
>> On Thu, Oct 2, 2014 at 7:29 AM, Ilya Tocar wrote:
>> > Hi,
>> >
>> > sizeof (long) == 4 on windows, so we should use long long as param type.
>> > Patch below does it.
>>
>> The same is true for x32. Can you a
On 10/03/2014 10:35 AM, Mark Wielaard wrote:
Say you have a user defined copy constructor. The DWARF consumer will
see the declaration and can assume the class won't have a default
constructor (unless that one is explicitly declared too). But currently
the DWARF consumer cannot know whether that
The "main" function for the driver in gcc.c has grown from ~200 lines
in its original form (way back in r262) to ~1000 lines today, with a
dozen locals (if we include the params).
The following patch splits it up into 15 smaller functions, moving the
various locals into the places where they're ne
This patch from Tim Shen fixes a bug in the Go frontend in which a
promoted method could be used even if there was a field of the same
name. This fixes http://golang.org/issue/4365 . Bootstrapped and ran
Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r c9d064a071c9
On 03/10/14 15:49 +0100, Jonathan Wakely wrote:
On 03/10/14 16:25 +0200, Marc Glisse wrote:
Do you mind if I move (in a future patch once yours is committed)
_M_size into _M_impl::_M_node as suggested in PR 61347?
Gah, that's where I had it until earlier this week, and I looked at it
and wonde
On Fri, 3 Oct 2014, Jonathan Wakely wrote:
Marc, this is the relative diff to go back to what I had earlier, with
the size in the _List_impl in case you want to aply it locally (the
dg-error tests are off-by-one with this patch)
Thanks. For PR 61347, to avoid offsetof, I will actually need to
On 10/03/14 08:50, tsaund...@mozilla.com wrote:
From: Trevor Saunders
Hi,
It was obsoleted back in 2011, so we're good to remove it.
bootstrapped + regtested x86_64-unknown-linux-gnu, and checked configure
doesn't recognize score-elf. Ok?
Trev
libgcc/ChangeLog:
2014-09-10 Trevor Saunders
On 10/03/14 03:01, Ilya Enkovich wrote:
Hi,
This patch avoids generation of __builtin_unreachable calls marked as
instrumented. It follows paradigma of no instrumented builtin calls (and
passes corresponding assert in expand_builtin from patch #18).
Thanks,
Ilya
--
2014-10-01 Ilya Enkovich
This patch from Michael Hudson-Doyle fixes PR 61877 which is about using
reflection to get a variadic method value. Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 9a2ca32c libgo/go/reflect/all_test.go
--- a/libgo/go/reflect/all_test.go Fri
On 10/03/14 02:47, Ilya Enkovich wrote:
Since we still don't have a final decision about how instrumented builtin
functions would look like, I replace this patch with a new one which assumes we
don't instrument them for now. It only has an additional init for va_start and
also makes sure ther
On 10/02/14 19:53, tsaund...@mozilla.com wrote:
From: Trevor Saunders
Hi,
If vec.h is included before ggc.h it forward declares ggc_realloc with
defaulted arguments. This means ggc.h can not be included later because
it would lead to a second declaration of ggc_realloc with defaulted
argument
On Fri, 3 Oct 2014, David Malcolm wrote:
> The "main" function for the driver in gcc.c has grown from ~200 lines
> in its original form (way back in r262) to ~1000 lines today, with a
> dozen locals (if we include the params).
>
> The following patch splits it up into 15 smaller functions, moving
There is a reduction bug exposed in the following parallel block.
#pragma acc parallel copy(b[0:3][0:3]) copy(l)
{
#pragma acc loop collapse(2) reduction(+:l)
for (int i = 0; i < 2; i++)
for (int j = 0; j < 2; j++)
if (b[i][j] != 16)
l += 1;
Hi,
This patch fixed a bug exposed in build kernel with fdo.
We cannot simply overwrite the bb footer in emit_barrier_after_bb as
the bb may already have a footer (in this case, a deleted label stmt).
We need to output this label because it's a user label and debug_info
has a reference to it.
T
Adds handling in this block of code (new in gcc/4_9 and therefore
google/4_9) for LIPO fake edges for indirect calls, which don't have a
call_stmt set and cannot be redirected.
Passes regression tests, ok for google/4_9 branch?
Teresa
2014-10-03 Teresa Johnson
Google ref b/17378050
This patch should be targeting trunk gcc?
David
On Fri, Oct 3, 2014 at 9:23 AM, Rong Xu wrote:
> Hi,
>
> This patch fixed a bug exposed in build kernel with fdo.
>
> We cannot simply overwrite the bb footer in emit_barrier_after_bb as
> the bb may already have a footer (in this case, a deleted
The name 'e' is used for both outer scope edge and inner scope one.
This is confusing.
David
On Fri, Oct 3, 2014 at 9:27 AM, Teresa Johnson wrote:
> Adds handling in this block of code (new in gcc/4_9 and therefore
> google/4_9) for LIPO fake edges for indirect calls, which don't have a
> call_
On Fri, Oct 3, 2014 at 4:25 PM, Jakub Jelinek wrote:
> This patch extends the gcc.dg/torture/ testsuite for
> 512-bit vectors. Tested with
> GCC_TEST_RUN_EXPENSIVE=1 make -j32 check-gcc \
> RUNTESTFLAGS='--target_board=unix\{-mavx2,-mavx,-mavx512f,-mavx512bw/-mavx512vl\}
> dg-torture.exp=vshuf*
On 09/17/2014 10:38 AM, Pierre-Marie de Rodat wrote:
Patches 1-4 are OK.
+ bool pell_conversions = true;
I don't understand "pell". Do you mean "strip"?
Jason
Yes, this needs to be fixed on trunk too. I looked at the history and
it has been this way (overwriting the footer) for years. It must be
uncommon to have this confluence of events.
Thanks,
Teresa
On Fri, Oct 3, 2014 at 9:28 AM, Xinliang David Li wrote:
> This patch should be targeting trunk gcc
On Fri, Oct 3, 2014 at 9:31 AM, Xinliang David Li wrote:
> The name 'e' is used for both outer scope edge and inner scope one.
No, the declaration was moved from the inner scope to the outer scope.
Teresa
> This is confusing.
>
> David
>
>
> On Fri, Oct 3, 2014 at 9:27 AM, Teresa Johnson wrote
These patches implement a couple bits of the C++14 constexpr enhancements.
The first patch adds support for local variables in a constexpr function
with intializers that can just be substituted into the return expression.
The second patch adds diagnostics for things that are still not
permitt
oops -- misread it :)
Ok.
David
On Fri, Oct 3, 2014 at 9:45 AM, Teresa Johnson wrote:
> On Fri, Oct 3, 2014 at 9:31 AM, Xinliang David Li wrote:
>> The name 'e' is used for both outer scope edge and inner scope one.
>
> No, the declaration was moved from the inner scope to the outer scope.
>
>
On 10/03/14 08:08, Andi Kleen wrote:
From: Andi Kleen
_Cilk_spawn or Cilk array expressions are only allowed on their own,
but not in for(), if(), switch, do, while, goto, etc.
The C parser didn't always check for that, which lead to ICEs earlier
for invalid code.
Add a generic helper that che
Hi,
On 10/03/2014 04:08 PM, Andi Kleen wrote:
+ if (check_no_cilk (destination,
+"Cilk array notation cannot be used as a computed goto expression",
+"%<_Cilk_spawn%> statement cannot be used as a computed goto
expression"))
+ destination = error_mark_node;
Are you su
On Fri, Oct 3, 2014 at 7:17 AM, Jason Merrill wrote:
> On 10/03/2014 09:12 AM, Mark Wielaard wrote:
>>
>> A debugger not knowing whether a special member function was explicitly
>> defaulted, implicitly declared or explicitly defined seems less confusion
>> than not knowing whether it was deleted.
On Fri, Oct 03, 2014 at 07:10:05PM +0200, Paolo Carlini wrote:
> Hi,
>
> On 10/03/2014 04:08 PM, Andi Kleen wrote:
> >+ if (check_no_cilk (destination,
> >+ "Cilk array notation cannot be used as a computed goto expression",
> >+ "%<_Cilk_spawn%> statement cannot be used as a computed
On Fri, Oct 3, 2014 at 10:13 AM, Siva Chandra wrote:
> On Fri, Oct 3, 2014 at 7:17 AM, Jason Merrill wrote:
>> On 10/03/2014 09:12 AM, Mark Wielaard wrote:
>>>
>>> A debugger not knowing whether a special member function was explicitly
>>> defaulted, implicitly declared or explicitly defined seem
Hi,
On 10/03/2014 07:13 PM, Andi Kleen wrote:
On Fri, Oct 03, 2014 at 07:10:05PM +0200, Paolo Carlini wrote:
Hi,
On 10/03/2014 04:08 PM, Andi Kleen wrote:
+ if (check_no_cilk (destination,
+"Cilk array notation cannot be used as a computed goto expression",
+"%<_Cilk_spaw
On Fri, 2014-10-03 at 10:54 -0400, Jason Merrill wrote:
> "user-declared" includes declarations that are defaulted in the class
> body. "user-provided" is the category that does not include such
> declarations.
O. Then I was indeed wrong and defaulted does not impact ABI at all.
At least that i
While looking into something else I noticed that we produce C99ish
"inline function declared but never defined" warning even for functions
marked as gnu_inline, if not in GNU89 or if -fgnu89-inline is not
in effect, because the warning was guarded only by !flag_gnu89_inline.
Bootstrapped/regtested
On Mon, Sep 29, 2014 at 4:15 PM, Bill Schmidt
wrote:
> Hi,
>
> The vec_lvsl and vec_lvsr interfaces are deprecated for little-endian
> Power, and really should not be used on big-endian Power either when the
> target CPU is power8 or above. The lexer in libcpp currently makes use
> of these inter
> >I have no idea, but there are lots of error_at() all over while
> >don't use _. So I just follow precedence.
> The problem is, you are *not* calling error_at directly, you are
According to Joseph it's ok because I named the arguments _msgid.
-Andi
Hello!
My r215428 change exposed another PR 57003 problem on x86_64. When
compiling gcc.target/i386/pr57003.c we refer to clobbered %rdi
register after the call to memcpy:
--- pr57003.s 2014-10-03 15:08:24.0 +0200
+++ pr57003_.s 2014-10-03 15:08:19.0 +0200
@@ -78,7 +78,7 @@
On Oct 3, 2014, at 9:40 AM, Uros Bizjak wrote:
>> Ok for trunk?
>>
>> 2014-10-03 Jakub Jelinek
> That said, the patch is OK from x86 side, but a testsuite maintainer
> should OK it.
Ok.
Hi,
On 10/03/2014 07:50 PM, Andi Kleen wrote:
I have no idea, but there are lots of error_at() all over while
don't use _. So I just follow precedence.
The problem is, you are *not* calling error_at directly, you are
According to Joseph it's ok because I named the arguments _msgid.
Ok then,
On Thu, Oct 2, 2014 at 3:20 PM, Bill Schmidt
wrote:
> Hi,
>
> Here's a revised version of the patch that addresses Segher's comments.
> Bootstrapped and tested on powerpc64le-unknown-linux-gnu. Ok for trunk?
>
> Thanks,
> Bill
>
>
> [gcc]
>
> 2014-10-02 Bill Schmidt
>
> * altivec.md (a
On Mon, Sep 29, 2014 at 5:53 PM, Bill Schmidt
wrote:
> Hi,
>
> The vec_lvsl and vec_lvsr interfaces are deprecated for little endian in
> the ELFv2 ABI document. At the moment, these interfaces will produce
> incorrect code, and the only indication a programmer has of this is that
> his or her co
On Tue, Sep 9, 2014 at 5:51 AM, Dominik Vogt wrote:
> The current Gccgo cannot handle 64 bit symbol tables on s390[x].
> The attached patch fixes that.
>
> gcc/go/ChangeLog
> 2014-09-05 Dominik Vogt
>
> * gofrontend/import-archive.cc (interpret_header): Recognize 64-bit
> symbol
On 10/02/14 02:31, Ramana Radhakrishnan wrote:
And a couple of items caught my attention.
For one the backend doesn't set the costs of a reg-reg move to be the
same as a reg-const move. In the AArch64 backend the approach appears to
be in line with the documentation which is to set the costs of
Committed to branch dmalcolm/jit:
Running e.g. test-factorial.exe under valgrind shows that libgccjit.so
was leaking ~13.5KB of RAM per invocation of the compiler here:
==57074== 21,440 bytes in 4 blocks are definitely lost in loss record 896 of 907
==57074==at 0x4A0645D: malloc (in
/usr/lib
There are some inconsistencies in the middle-end about how to dump a
location. The following patch makes all places (that I found) use
dump_location, and makes that function print also the column number.
While searching for possible callers, I noticed two cases where we use
expanded_location for n
> O. Then I was indeed wrong and defaulted does not impact ABI at all.
> At least that is one worry less for the abi checkers :)
As Siva mentioned, it does in fact impact the ABI. A class with a
non-trivial destructor is not a POD, and affects the calling
convention, so the debugger needs to know
On Wed, Oct 1, 2014 at 10:58 PM, Jakub Jelinek wrote:
> On Wed, Oct 01, 2014 at 04:21:29PM -0700, Alexey Samsonov wrote:
>> Speaking of plain -f(no-)sanitize-recover - it would probably be
>> better to change the semantics of this flag,
>> so that "-f(no-)?sanitize-recover" means "enable(disable)
On Fri, 2014-10-03 at 11:41 -0700, Cary Coutant wrote:
> > O. Then I was indeed wrong and defaulted does not impact ABI at all.
> > At least that is one worry less for the abi checkers :)
>
> As Siva mentioned, it does in fact impact the ABI. A class with a
> non-trivial destructor is not a POD, a
> gcc/ChangeLog.jit:
> * diagnostic.c (diagnostic_finish): Free the memory for
> context->classify_diagnostic and context->printer, running the
> destructor for the latter.
It would be easier to review and merge your branch if you directly
propose these self-contained and generally use
On Fri, 2014-10-03 at 11:02 -0400, David Malcolm wrote:
> The "main" function for the driver in gcc.c has grown from ~200 lines
> in its original form (way back in r262) to ~1000 lines today, with a
> dozen locals (if we include the params).
>
> The following patch splits it up into 15 smaller fun
1 - 100 of 119 matches
Mail list logo
