On Thu, Oct 2, 2014 at 10:13 PM, Vladimir Makarov vmaka...@redhat.com wrote:
I guess we achieved the consensus about the following patch to fix
PR61360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61360
The patch was successfully bootstrapped and tested (w/wo
-march=amdfam10) on
On 09/26/2014 12:55 PM, Marat Zakirov wrote:
Hi all!
Here's a patch which instruments byte-aligned BIT_FIELD_REFs. During
GCC asan-bootstrap and Linux kernel build I didn't find any cases
where BIT_FIELD_REF is not 8 bits aligned. But I do not have
sufficient confidence to replace current
On Thu, Oct 02, 2014 at 11:48:27AM +0200, 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
On Fri, Oct 3, 2014 at 8:52 AM, Jakub Jelinek ja...@redhat.com 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
Christophe Lyon christophe.l...@linaro.org 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.
Hi!
Got surprised by seeing vect_suffle3* variable names in the dumps,
fixed thusly, committed as obvious to trunk.
2014-10-03 Jakub Jelinek ja...@redhat.com
* tree-vect-data-refs.c (vect_permute_load_chain,
vect_shift_permute_load_chain): Fix a typo in temporary var names,
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
On 03 Oct 00:05, Ilya Enkovich wrote:
2014-10-02 22:30 GMT+04:00 Jeff Law l...@redhat.com:
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
On 3 October 2014 09:55, Andreas Schwab sch...@linux-m68k.org wrote:
Christophe Lyon christophe.l...@linaro.org 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
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 ilya.enkov...@intel.com
*
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_ref
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
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
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 david.sherw...@arm.com 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 david.sherw...@arm.com
* ira-int.h (ira_allocno): Mark hard_regno as signed.
Hello Uroš,
On 29 Sep 09:54, Uros Bizjak wrote:
+(define_expand vashrv2di3mask_name
+ [(set (match_operand:V2DI 0 register_operand)
+ (ashiftrt:V2DI
+ (match_operand:V2DI 1 register_operand)
+ (match_operand:V2DI 2 nonimmediate_operand)))]
+ TARGET_XOP ||
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 mask_applied condition here. Is
the above condition correct?
I think this is correct since in this pattern we use AVX-512
Hello Uroš,
On 29 Sep 10:08, Uros Bizjak wrote:
On Fri, Sep 26, 2014 at 4:09 PM, Kirill Yukhin kirill.yuk...@gmail.com
wrote:
+(define_insn avx512bw_pmaddubsw512modemask_name
+ [(set (match_operand:VI2_AVX512VL 0 register_operand =v)
+ (unspec:VI2_AVX512VL
+
On Fri, Oct 3, 2014 at 12:26 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote:
Hello Uroš,
On 29 Sep 09:54, Uros Bizjak wrote:
+(define_expand vashrv2di3mask_name
+ [(set (match_operand:V2DI 0 register_operand)
+ (ashiftrt:V2DI
+ (match_operand:V2DI 1 register_operand)
+
On Fri, Oct 3, 2014 at 12:49 PM, Kirill Yukhin kirill.yuk...@gmail.com 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 mask_applied condition here. Is
the above
On Fri, Oct 3, 2014 at 1:03 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote:
Hello Uroš,
On 29 Sep 10:08, Uros Bizjak wrote:
On Fri, Sep 26, 2014 at 4:09 PM, Kirill Yukhin kirill.yuk...@gmail.com
wrote:
+(define_insn avx512bw_pmaddubsw512modemask_name
+ [(set (match_operand:VI2_AVX512VL
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
AVX
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
On Fri, Oct 3, 2014 at 1:11 PM, Jakub Jelinek ja...@redhat.com 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
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 y.gri...@samsung.com
Date: Fri Oct 3 11:53:38 2014
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
Looks good to me
On Fri, Oct 3, 2014 at 5:07 PM, Yury Gribov y.gri...@samsung.com 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
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
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 jwak...@redhat.com
Date: Fri Oct 3 14:28:44 2014 +0100
PR libstdc++/63449
*
On 02 Oct 07:41, H.J. Lu wrote:
On Thu, Oct 2, 2014 at 7:29 AM, Ilya Tocar tocarip.in...@gmail.com 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
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
with
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 a...@linux.intel.com
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/:
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 a...@linux.intel.com
_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
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 ja...@redhat.com 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
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
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
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
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
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
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
On Wed, Sep 17, 2014 at 5:11 PM, Andrey Turetskiy
andrey.turets...@gmail.com wrote:
On Wed, Sep 17, 2014 at 3:19 PM, Bernd Schmidt ber...@codesourcery.com
wrote:
I have no objections to supporting a -ftarget-options switch. I had posted a
patch a while ago that looked somewhat similar, but
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
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 wait
On Fri, Oct 3, 2014 at 4:32 PM, Jakub Jelinek ja...@redhat.com 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
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 deleted. But
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
On Thu, Sep 18, 2014 at 7:05 PM, Jing Yu jin...@google.com wrote:
2014-09-18 Jing Yu jin...@google.com
* 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 a
On Fri, Oct 3, 2014 at 6:46 AM, Ilya Tocar tocarip.in...@gmail.com wrote:
On 02 Oct 07:41, H.J. Lu wrote:
On Thu, Oct 2, 2014 at 7:29 AM, Ilya Tocar tocarip.in...@gmail.com wrote:
Hi,
sizeof (long) == 4 on windows, so we should use long long as param type.
Patch below does it.
The same
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
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
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 tsaund...@mozilla.com
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:
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
On 10/02/14 19:53, tsaund...@mozilla.com wrote:
From: Trevor Saunders trev.saund...@gmail.com
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
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 the
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.
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 tejohn...@google.com
This patch should be targeting trunk gcc?
David
On Fri, Oct 3, 2014 at 9:23 AM, Rong Xu x...@google.com 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,
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 tejohn...@google.com 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
On Fri, Oct 3, 2014 at 4:25 PM, Jakub Jelinek ja...@redhat.com 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\}
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 davi...@google.com wrote:
This patch should be
On Fri, Oct 3, 2014 at 9:31 AM, Xinliang David Li davi...@google.com 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
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
oops -- misread it :)
Ok.
David
On Fri, Oct 3, 2014 at 9:45 AM, Teresa Johnson tejohn...@google.com wrote:
On Fri, Oct 3, 2014 at 9:31 AM, Xinliang David Li davi...@google.com wrote:
The name 'e' is used for both outer scope edge and inner scope one.
No, the declaration was moved from the
On 10/03/14 08:08, Andi Kleen wrote:
From: Andi Kleen a...@linux.intel.com
_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
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 sure
On Fri, Oct 3, 2014 at 7:17 AM, Jason Merrill ja...@redhat.com 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
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 goto
On Fri, Oct 3, 2014 at 10:13 AM, Siva Chandra sivachan...@google.com wrote:
On Fri, Oct 3, 2014 at 7:17 AM, Jason Merrill ja...@redhat.com 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
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_spawn%
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 is one
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
wschm...@linux.vnet.ibm.com 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
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 ubiz...@gmail.com wrote:
Ok for trunk?
2014-10-03 Jakub Jelinek ja...@redhat.com
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
wschm...@linux.vnet.ibm.com 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
On Mon, Sep 29, 2014 at 5:53 PM, Bill Schmidt
wschm...@linux.vnet.ibm.com 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
On Tue, Sep 9, 2014 at 5:51 AM, Dominik Vogt v...@linux.vnet.ibm.com 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 v...@linux.vnet.ibm.com
* gofrontend/import-archive.cc
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
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
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
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 ja...@redhat.com 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
1 - 100 of 122 matches
Mail list logo
