On Fri, Oct 03, 2014 at 12:36:37PM -0600, Jeff Law wrote:
> rtx_cost and its friends have always been a problem and it's always felt
> like a design problem. The true cost of something is so context
> dependent I'm not really sure how to build an API to do this in a sane way.
In many places it
On Tue, Sep 9, 2014 at 5:56 AM, Dominik Vogt wrote:
> This optional cleanup patch fixes some sloppy programming in the
> x86 libgo/go/debug/elf library that had given me a very hard time
> to debug and fix when porting the code to s390[x]. See commit
> comment for details.
>
> ChangeLog
> 2014-09
On Tue, Sep 9, 2014 at 5:53 AM, Dominik Vogt wrote:
>
> This patch fixes the compiler flags in libgo/mksysinfo.sh. In one
> place, some compiler flags were missing that are consistently used
> elswhere, resulting in an error message.
>
> ChangeLog
> 2014-09-05 Dominik Vogt
>
> * libgo/
On Thu, 2 Oct 2014, Jason Merrill wrote:
OK.
Thanks. While committing, I noticed that I restricted ! to integer
vectors, whereas it seems to work just fine with scalar floats, so it
would make sense to extend it to float vectors. Tested on
x86_64-linux-gnu.
2014-10-04 Marc Glisse
gcc/
Hi,
this patch add basic testcaes for new devirtualization features (more to come)
and
also fixes bug I introduced while refactoring the speculative context merging
code - that most likely explains why I observed number of speculative devirt
to drop considerably after finishing the patch.
Jason,
On Fri, Oct 3, 2014 at 12:45 PM, Jason Merrill wrote:
> On 10/03/2014 02:41 PM, 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
On Fri, Oct 3, 2014 at 12:00 PM, Mark Wielaard wrote:
> Thanks for that reference. I was just stepping through gdb's
> gdbarch_return_in_first_hidden_param_p to understand why Siva's example
> did indeed seem to go wrong under GDB. That code is a little hairy with
> all the arch specific indirecti
The following patch adds two new functions. One of them is an overload
of gfc_warning_cmdline() that takes an option. Thus now we get:
f951: Warning: Nonexistent include directory
'C:\msys\1.0.10\home\FX\ibin\i586-pc-mingw32\libgfortran/../../../trunk/libgfortran/generated'
[-Wmissing-include-dirs
On 3 October 2014 16:08:57 CEST, Andi Kleen wrote:
>From: Andi Kleen
> (check_no_cilk): Dito.
I'm just curious, but isn't the english term "ditto" (im österreichischen ugs.
"detto", think latin "idem") ?
On Wed, 24 Sep 2014, Joseph S. Myers wrote:
> > > * config/rs6000/e500.h (HARD_REGNO_CALLER_SAVE_MODE): Remove
> > > macro.
> > > * config/rs6000/rs6000.h (HARD_REGNO_CALLER_SAVE_MODE): Handle
> > > TARGET_E500_DOUBLE case here.
> >
> > This patch is okay. The rep
Note that there is a separate __int128_t type that isn't part of the
"standard" extension. Maybe it's there for that type?
Otherwise, I don't see what moving the test would accomplish. If
"long" is never 128 bits, it doesn't matter if the int128 test is
before or after it, and the other intN ar
On 10/03/14 12:39, Manuel López-Ibáñez wrote:
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 notice
On 10/03/14 13:15, David Malcolm wrote:
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
Hi David,
On 3 Oct 2014, at 20:15, David Malcolm wrote:
> 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 par
On 10/02/14 08:03, Ilya Enkovich wrote:
Here is an updated version.
Thanks,
Ilya
--
2014-10-02 Ilya Enkovich
* calls.c: Include tree-chkp.h, rtl-chkp.h, bitmap.h.
(arg_data): Add fields special_slot, pointer_arg and
pointer_offset.
(store_bounds): New.
On Fri, 3 Oct 2014, Marek Polacek wrote:
> 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 o
On 10/03/14 02:50, Ilya Enkovich wrote:
Attached is an updated version of the patch. It has disabled instrumenttation
for builtin calls.
Thanks,
Ilya
--
gcc/
2014-10-02 Ilya Enkovich
* tree-chkp.c: New.
* tree-chkp.h: New.
* rtl-chkp.c: New.
* rtl-chkp.h: New
Hi,
this patch adds basic tracking of what types may be in construction because the
call appears in a polymorphic cdtor.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
* cgraph.h (struct indirect_call_info): Add IN_POLYMORPHIC_CDTOR
* lto-cgraph.c (lto_output_edge, input_edg
On 10/03/2014 02:41 PM, 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, and affects the calling
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
> 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: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
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)
> 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
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
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
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
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 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 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
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 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.
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 @@
> >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
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
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 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
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, 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
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 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.
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 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
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.
>
>
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
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
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 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
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*
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_
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
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
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
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;
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
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 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
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 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
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 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 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
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
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
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
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 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 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.
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 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
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 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
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 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
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 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_
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 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,
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
OK.
Jason
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
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
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
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
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
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
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
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 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?
>
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
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
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
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
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
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
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
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 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 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
>
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
1 - 100 of 119 matches
Mail list logo
