On 09/30/2014 04:24 AM, Konstantin Serebryany wrote:
On Mon, Sep 29, 2014 at 4:26 PM, Alexey Samsonov wrote:
I don't think we ever going to support recovery for regular ASan
(Kostya, correct me if I'm wrong).
I hope so too.
Another point is that with asan-instrumentation-with-call-threshold=0
On Mon, Sep 29, 2014 at 05:24:02PM -0700, Konstantin Serebryany wrote:
> > I don't think we ever going to support recovery for regular ASan
> > (Kostya, correct me if I'm wrong).
>
> I hope so too.
> Another point is that with asan-instrumentation-with-call-threshold=0
> (instrumentation with call
On 09/27/14 03:53, Bernd Edlinger wrote:
Comment before this change. Someone not familiar with this code is
going to have no idea why these two lines exist.
Ok, I added a comment now, do you like it?
Yes.
Please try to include a testcase. If you're having trouble reproducing
on the trunk
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> Sent: Monday, September 29, 2014 3:33 PM
> ChangeLog are as follows:
>
> *** gcc/cp/ChangeLog ***
>
> 2014-09-26 Thomas Preud'homme
>
> * decl.c (grokdeclarator): Set defaul
On 09/29/14 08:19, Teresa Johnson wrote:
Just an update - I found some good test cases by compiling the
c-torture tests with profile feedback with and without my patch. But
in the cases I pulled out I saw that there were still a couple profile
or probability insanities introduced by jump threadi
On 09/29/14 12:06, Jiong Wang wrote:
thanks for pointing this out, patch updated.
re-tested, pass x86-64 bootstrap and no regression on check-gcc/g++.
pass aarch64-none-elf cross check also.
ok for trunk?
Yes this is fine.
BTW, another bug exposed by linux x86-64 kernel build, and it's at
On 09/29/14 13:24, Jiong Wang wrote:
I don't think so. from the x86-64 bootstrap, there is no regression
on the number of functions shrink-wrapped. actually speaking,
previously only single mov dest, src handled, so the disallowing
USE/CLOBBER will not disallow shrink-wrap opportunity which was
On Mon, Sep 29, 2014 at 6:05 PM, Alexey Samsonov wrote:
> On Mon, Sep 29, 2014 at 5:24 PM, Konstantin Serebryany
> wrote:
>>
>> On Mon, Sep 29, 2014 at 4:26 PM, Alexey Samsonov wrote:
>> > On Mon, Sep 29, 2014 at 4:17 PM, Jakub Jelinek wrote:
>> >> On Mon, Sep 29, 2014 at 03:36:20PM -0700, Alex
On Mon, Sep 29, 2014 at 5:24 PM, Konstantin Serebryany
wrote:
>
> On Mon, Sep 29, 2014 at 4:26 PM, Alexey Samsonov wrote:
> > On Mon, Sep 29, 2014 at 4:17 PM, Jakub Jelinek wrote:
> >> On Mon, Sep 29, 2014 at 03:36:20PM -0700, Alexey Samsonov wrote:
> >>> -fasan-recover doesn't look like a good
On Mon, Sep 29, 2014 at 4:26 PM, Alexey Samsonov wrote:
> On Mon, Sep 29, 2014 at 4:17 PM, Jakub Jelinek wrote:
>> On Mon, Sep 29, 2014 at 03:36:20PM -0700, Alexey Samsonov wrote:
>>> -fasan-recover doesn't look like a good idea - for instance, in Clang, we
>>> never use "?san"
>>> in flag names,
Similar to a recent patch to libgo, this patch to the libffi configure
script checks whether the compiler support -Qunused-arguments. If it
does, it passes -Qunused-arguments when invoking the compiler on .s
files. This is because the clang driver complains by default when given
useless arguments
This patch to the libgo configure script changes it to use
-Qunused-arguments when running the assembler tests. Apparently clang
by default complains when arguments to the driver are unused, as in -I
arguments when invoked on a .s file. Passing -Qunused-arguments
disables these warnings, and lets
On Mon, Sep 29, 2014 at 4:17 PM, Jakub Jelinek wrote:
> On Mon, Sep 29, 2014 at 03:36:20PM -0700, Alexey Samsonov wrote:
>> -fasan-recover doesn't look like a good idea - for instance, in Clang, we
>> never use "?san"
>> in flag names, preferring -fsanitize-whatever. What's the rationale behind
>>
I've noticed that config/sh/sh.md uses define_constants to define
unspec and unspecv numbers, though config/sh/sync.md uses define_c_enum
for them. This causes collisions of some numbers. The attached
patch would be an obvious fix. Tested on sh4-unknown-linux. Applied
to trunk. I'll backport i
On Mon, Sep 29, 2014 at 03:36:20PM -0700, Alexey Samsonov wrote:
> -fasan-recover doesn't look like a good idea - for instance, in Clang, we
> never use "?san"
> in flag names, preferring -fsanitize-whatever. What's the rationale behind
> splitting
> -fsanitize-recover in two flags (ASan- and UBSan
> Yeah, that sounds good to me.
Here's what I have at last commited after testing on x86-64/Linux.
2014-09-29 Eric Botcazou
* tree-vrp.c (get_single_symbol): New function.
(build_symbolic_expr): Likewise.
(symbolic_range_based_on_p): New predicate.
(extract_ra
(resending in plain-text mode)
-fasan-recover doesn't look like a good idea - for instance, in Clang,
we never use "?san"
in flag names, preferring -fsanitize-whatever. What's the rationale
behind splitting
-fsanitize-recover in two flags (ASan- and UBSan- specific)?
Is there no way to keep a sing
Hi,
Up till now we have not attempted to generate code for LE usage of
vec_lvsl and vec_lvsr that is compatible with expected BE usage. The LE
code sequence corresponding to lvsl/vperm is not good, and we encourage
programmers to convert those sequences to use direct assignment and the
type syste
Le 29 sept. 2014 à 23:56, Dominique d'Humières a écrit :
> Unless there is an objection I plan to commit tomorrow the following patch
> with a change log:
>
> --- ../_clean/gcc/testsuite/gfortran.dg/coarray_collectives_9.f90
> 2014-09-25 12:14:05.0 +0200
> +++ gcc/testsuite/gfortr
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 code does not function correctly. This patch adds a warning
messag
On 09/27/14 08:48, Felix Yang wrote:
Thanks for the explaination.
I have changed the loop_depth into a short interger hoping that we can
save some memory :-)
Thanks.
Attached please find the updated patch. Bootstrapped and reg-tested on
x86_64-suse-linux.
Please do a final revew once the assig
+Alexey Samsonov
On Mon, Sep 29, 2014 at 10:43 AM, Jakub Jelinek wrote:
> On Mon, Sep 29, 2014 at 09:21:11PM +0400, Yury Gribov wrote:
>> >>This patch enables -fsanitize-recover for KASan by default. This causes
>> >>KASan to continue execution after error in case of inline
>> >>instrumentation.
Hi!
On Mon, 29 Sep 2014 15:00:03 -0600, Jeff Law wrote:
> On 09/29/14 12:13, Thomas Schwinge wrote:
> > libcilkrts/
> > * [...]
> The Cilk+ runtime is shared with ICC and they'll need to pull in this
> code first. We can then pick it up via merges.
Yeah, Barry is alrea
On 09/29/14 12:13, Thomas Schwinge wrote:
Hi!
On Wed, 9 Oct 2013 18:32:11 +, "Iyer, Balaji V"
wrote:
[libcilkrts]
I have found a function that is -- as far as I can tell -- unused, and
I'm thus proposing to remove it. This increases portability, as this
code has dependencies on the ope
On Mon, 2014-09-29 at 20:24 +0100, Jiong Wang wrote:
> On 29/09/14 19:32, Richard Henderson wrote:
> > On 09/29/2014 11:12 AM, Jiong Wang wrote:
> >> +inline rtx single_set_no_clobber_use (const rtx_insn *insn)
> >> +{
> >> + if (!INSN_P (insn))
> >> +return NULL_RTX;
> >> +
> >> + if (GET_CO
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 interfaces in search_line_fast(). This patch provides a new
version o
I added myself as libstdc++ special modes maintainer. Special modes are
debug, profile and parallel modes.
Thanks for your trust.
François
On 29/09/14 19:32, Richard Henderson wrote:
On 09/29/2014 11:12 AM, Jiong Wang wrote:
+inline rtx single_set_no_clobber_use (const rtx_insn *insn)
+{
+ if (!INSN_P (insn))
+return NULL_RTX;
+
+ if (GET_CODE (PATTERN (insn)) == SET)
+return PATTERN (insn);
+
+ /* Defer to the more exp
I'm rearranging some code in Michael's original patch to minimize the
difference with mainline.
It seems that the check for DECL_STRUCT_FUNCTION (decl)->gimple_df, was
merely a check to see if we had already set the FDE bits for the decl in
question. I've moved the check inside the original D
On 29/09/14 19:24 +0200, Andreas Schwab wrote:
Jonathan Wakely writes:
Would a safer change be to just add a new pattern for aarch64?
--- a/libstdc++-v3/configure.host
+++ b/libstdc++-v3/configure.host
@@ -345,6 +345,9 @@ case "${host}" in
x86_64)
abi_baseline_pair=x86_64-linux-
On 29/09/14 14:06 -0400, DJ Delorie wrote:
Just one question about the include/std/limits changes below.
It seems that __glibcxx_signed_b isn't strictly necessary as it
doesn't use the B argument, so is it just there for consistency?
Yup.
OK, thanks for confirming.
On 09/29/2014 11:12 AM, Jiong Wang wrote:
> +inline rtx single_set_no_clobber_use (const rtx_insn *insn)
> +{
> + if (!INSN_P (insn))
> +return NULL_RTX;
> +
> + if (GET_CODE (PATTERN (insn)) == SET)
> +return PATTERN (insn);
> +
> + /* Defer to the more expensive case, and return NULL_R
It's a remnant from something we were attempting to support (and abandoned) 4
years ago. I'm fine with removing it from the runtime.
Igor, I'll make the change and send you a new copy.
- Barry
-Original Message-
From: Thomas Schwinge [mailto:tho...@codesourcery.com]
Sent: Monday, Se
Hi!
On Wed, 9 Oct 2013 18:32:11 +, "Iyer, Balaji V"
wrote:
> [libcilkrts]
Here is a patch to have libcilkrts use AC_USE_SYSTEM_EXTENSIONS (as other
libraries are doing) instead of manually fiddling with the _GNU_SOURCE
definition. This increases portability, as most of those definitions ar
Hi!
On Wed, 9 Oct 2013 18:32:11 +, "Iyer, Balaji V"
wrote:
> [libcilkrts]
Currently, by means of the libcilkrts/configure.tgt file that has been
added during patch review, libcilkrts is attempted to be built for all
*-*-gnu* system, but it has actually only been ported to GNU/Linux. This
i
Hi!
On Wed, 9 Oct 2013 18:32:11 +, "Iyer, Balaji V"
wrote:
> [libcilkrts]
As requested during patch review, symbol versioning infrastructure has
been added to libcilkrts. However, this is currently
described/implemented as "Linux-only", while in fact it's standard GNU
linker scripts, gener
Hi!
On Wed, 9 Oct 2013 18:32:11 +, "Iyer, Balaji V"
wrote:
> [libcilkrts]
I have found a function that is -- as far as I can tell -- unused, and
I'm thus proposing to remove it. This increases portability, as this
code has dependencies on the operating system. Tested on x86 GNU/Hurd,
and
it's exposed by linux kernel for x86.
the root cause is current "single_set" will ignore CLOBBER & USE,
while we need to take them into account when handling shrink-wrap.
this patch add one parameter to single_set_2 to support return
NULL_RTX if we want to remove any side-effect. add a new helpe
On 26/09/14 17:12, Jeff Law wrote:
On 09/26/14 08:50, Jiong Wang wrote:
if (may_trap_p (x))
don't sink this instruction.
any comments?
Should be checking if x may throw internally instead.
Richard, thanks for the suggestion, have used insn_could_throw_p to do
the check,
wh
> Just one question about the include/std/limits changes below.
>
> It seems that __glibcxx_signed_b isn't strictly necessary as it
> doesn't use the B argument, so is it just there for consistency?
Yup.
Ping.
On Mon, Sep 22, 2014 at 11:41 AM, Carrot Wei wrote:
> Hi
>
> The extended register width in add/adds/sub/subs/cmp instructions is
> not always the same as target register, it depends on both target
> register width and extension type. But in current implementation the
> extended register wi
Ping.
On Fri, Sep 19, 2014 at 2:11 PM, Sriraman Tallam wrote:
> Hi Richard,
>
> I also ran the gcc testsuite with
> RUNTESTFLAGS="--tool_opts=-mcopyrelocs" to check for issues. The only
> test that failed was g++.dg/tsan/default_options.C. It uses -fpie
> -pie and BFD ld to link. Since BFD ld d
On 2014-09-29 18:32, Jason Merrill wrote:
> On 09/29/2014 11:46 AM, Andrew Sutton wrote:
>> The main reason for the restriction is that concept definitions are
>> normalized into a single constraint-expression. And it's not obvious
>> how things like using declarations and static-assertions should
On Mon, Sep 29, 2014 at 09:21:11PM +0400, Yury Gribov wrote:
> >>This patch enables -fsanitize-recover for KASan by default. This causes
> >>KASan to continue execution after error in case of inline
> >>instrumentation. This feature is needed because
> >>- reports during early bootstrap won't even
On Mon, Sep 29, 2014 at 1:27 PM, Bill Schmidt
wrote:
> Hi,
>
> While working on another patch, I observed that the test case
> gcc.dg/vmx/ops.c contains numerous calls to vec_splat and friends for
> which the second argument (the element selector) is out of range. At
> best these calls are invali
On 29 Sep 03:10, Jan Hubicka wrote:
> dump for me implied debug dump. LTO is usually called streaming, so prehaps
> need_lto_stremaing?
Fixed.
> > +initialize_offload (void)
> Perhaps have_offload_p? Nothing is initialized here...
The next patch will add some initialization to this function. An
On Mon, 29 Sep 2014, rohitarul...@freescale.com wrote:
> > As I understand it, the change was supposed to only affect GCC internals,
> > all
> > externally generated debug info was supposed to remain unchanged.
> >
> > If there are changes in debug info, something must have gone wrong.
>
> Let
Hi,
While working on another patch, I observed that the test case
gcc.dg/vmx/ops.c contains numerous calls to vec_splat and friends for
which the second argument (the element selector) is out of range. At
best these calls are invalid; as it is, we generate insns that can cause
trouble during opti
Jonathan Wakely writes:
> Would a safer change be to just add a new pattern for aarch64?
>
> --- a/libstdc++-v3/configure.host
> +++ b/libstdc++-v3/configure.host
> @@ -345,6 +345,9 @@ case "${host}" in
> x86_64)
> abi_baseline_pair=x86_64-linux-gnu
> ;;
> + aarch64)
>
On 09/16/2014 05:23 PM, Andrew MacLeod wrote:
On 09/16/2014 05:12 PM, Joseph S. Myers wrote:
On Tue, 16 Sep 2014, Andrew MacLeod wrote:
I did an include file reduction on all the language/*.[ch] and core
*.[ch]
files, but left the target files with the full complement of 7
includes that
funct
Hi all,
Kasan developers has asked for an option to override offset of Asan
shadow memory region. This should simplify experimenting with memory
layouts on 64-bit architectures.
New patch which checks that -fasan-shadow-offset is only enabled for
-fsanitize=kernel-address. I (unfortunately) c
Hi all,
This patch enables -fsanitize-recover for KASan by default. This causes
KASan to continue execution after error in case of inline
instrumentation. This feature is needed because
- reports during early bootstrap won't even be printed
- needed to run all tests w/o rebooting machine for eve
> Given that we've had this bake sufficiently on trunk and have seen no
> regressions reported it should be fine to go back to these branches.
>
> Further we've had the 4.9.1 and 4.8.3 releases recently so I'd say Yes,
> unless the RM's object in the next 24 hours.
Make check passed on 4.8 and 4.9
On Sep 29, 2014, at 6:20 AM, FX wrote:
> I have not seen any trouble arising following the fix to PR 61407
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407).
> The patch committed is here:
> https://gcc.gnu.org/viewcvs?rev=215251&root=gcc&view=rev
>
> I’ve just tested the exact same chang
On 09/28/14 23:36, Jakub Jelinek wrote:
Hi!
On the following testcase, dead_or_predicable decides to call
redirect_jump_1 on asm goto which has more than one label, but the
bb still has just two successors (one of the labels points to
code label at the start of the fallthru bb) and redirect_jump
On 09/27/14 16:03, Segher Boessenkool wrote:
On Mon, Sep 22, 2014 at 04:20:12PM -0600, Jeff Law wrote:
Can you add a testcase which shows the 3-insn combination from PR62151
applying?
I've tried to make a stable future-proof testcase that does such a three-insn
combination. Not easy at all.
On Mon, 2014-09-29 at 17:38 +0200, Jakub Jelinek wrote:
> On Mon, Sep 29, 2014 at 05:35:24PM +0200, Torvald Riegel wrote:
> > On Mon, 2014-09-29 at 16:53 +0400, Gleb Fotengauer-Malinovskiy wrote:
> > > -#undef __always_inline
> > > -#define __always_inline __attribute__((always_inline))
> > > +#de
On 09/25/14 07:03, Chen Gang wrote:
2014-09-25 Chen Gang
gcc:
* config/microblaze/microblaze.md (call_internal1): Use VOID
instead of SI to fix "((void (*)(void)) 0)()" issue
gcc/testsuite/:
2014-09-28 Chen Gang
* gcc.c-torture/compile/calls-void.c: New test.
C
On 09/29/2014 11:46 AM, Andrew Sutton wrote:
The main reason for the restriction is that concept definitions are
normalized into a single constraint-expression. And it's not obvious
how things like using declarations and static-assertions should be
interpreted within the constraint language.
A
2014-09-27 Gleb Fotengauer-Malinovskiy
libitm/
PR libitm/61164
* local_atomic (__always_inline): Rename to...
(__libitm_always_inline): ... this.
---
On Mon, Sep 29, 2014 at 03:38:25PM +0200, Jakub Jelinek wrote:
> Why do you want to add inline keyword to that? Some i
Committed to branch dmalcolm/jit:
gcc/jit/ChangeLog.jit:
* TODO.rst: Update.
* docs/topics/expressions.rst (gcc_jit_context_new_call): Add
a note clarifying the behavior of this entrypoint.
* docs/topics/functions.rst (Creating and using functions): Markup
f
Hi Guys,
I am applying the patch below to the MSP430 backend. It improves the
-mhwmult=auto command line option so that MCUs without any hardware
support will be recognised if the -mmcu= option has also been given.
The patch also fixes a small problem with the prologue and epilogue
gen
> So - no, you can't simply remove it. But IMHO it should become a
> target-specific flag.
How about a patch to just disable it for x86?
-Andi
> Hmm, have we actually discussed this in core review? I'm not seeing it on
> the wiki. Constexpr started out this way too, and allowing static_assert
> was added pretty fast. C++11 said
>
> its function-body shall be = delete, = default, or a compound-statement that
> contains only
> — null sta
On Mon, Sep 29, 2014 at 05:35:24PM +0200, Torvald Riegel wrote:
> On Mon, 2014-09-29 at 16:53 +0400, Gleb Fotengauer-Malinovskiy wrote:
> > -#undef __always_inline
> > -#define __always_inline __attribute__((always_inline))
> > +#define __libitm_always_inline inline __attribute__((always_inline))
> >
> > Why not just make all anonymous types their own canonical type?
> > (of course considering type variants)
>
> If C++ FE sets canonical type always to main variant, it should work.
> Is it always the case? I noticed you do this for variadic types.
> I tought there is reason why canonical t
>
> Why not just make all anonymous types their own canonical type?
> (of course considering type variants)
If C++ FE sets canonical type always to main variant, it should work.
Is it always the case? I noticed you do this for variadic types.
I tought there is reason why canonical types differ fr
On Mon, 2014-09-29 at 16:53 +0400, Gleb Fotengauer-Malinovskiy wrote:
> -#undef __always_inline
> -#define __always_inline __attribute__((always_inline))
> +#define __libitm_always_inline inline __attribute__((always_inline))
The previous code seems to work in libstdc++. I believe that
eventuall
On 09/25/2014 12:57 PM, Jason Merrill wrote:
On 09/01/2014 09:34 PM, Ed Smith-Rowland wrote:
(open_file_failed()): Not an error to not find a header file for
__has_include__.
Hmm, looks like this means that __has_include__ will silently return
false if a header exists but is unreadabl
On September 29, 2014 5:21:36 PM CEST, Jakub Jelinek wrote:
>On Mon, Sep 29, 2014 at 08:20:03AM -0700, Andi Kleen wrote:
>> > As we saw LTO fixes for -fshort-double it's clear that this flag
>_is_ used
>> > for some embedded archs.
>>
>> Did we? It has been ICEing since 4.5, which is before LTO.
On 09/29/14 08:26, Thomas Schwinge wrote:
Hi!
On Mon, 29 Sep 2014 13:58:31 +, "Tannenbaum, Barry M"
wrote:
In a nutshell, add the following code to main() before the call to f3():
int status = __cilkrts_set_param("nworkers", "2");
if (0 != status) {
// Failed to set th
On Mon, Sep 29, 2014 at 08:20:03AM -0700, Andi Kleen wrote:
> > As we saw LTO fixes for -fshort-double it's clear that this flag _is_ used
> > for some embedded archs.
>
> Did we? It has been ICEing since 4.5, which is before LTO.
Depends on which target. Aren't the ICEs i?86/x86_64 backend ICEs
> As we saw LTO fixes for -fshort-double it's clear that this flag _is_ used
> for some embedded archs.
Did we? It has been ICEing since 4.5, which is before LTO.
-Andi
On 09/29/2014 10:55 AM, Andrew Sutton wrote:
Jason, do you want to review this before I commit? This is a pretty small patch.
No need to wait for review before committing to the branch.
+ // If fn was declared with auto, make sure the result type is bool.
+ if (FNDECL_USED_AUTO (fn) && TREE
Looks good to me. I apologize for spamming you with the extra details. I wasn't
clear that this was a patch instead of a bug report.
I believe that Igor is the one who controls the GCC submission for Cilk Plus.
- Barry
-Original Message-
From: Thomas Schwinge [mailto:tho...@codesource
This fixes an ICE trying to normalize a function concept with multiple
statements. That error will now be diagnosed at the point of
definition.
Jason, do you want to review this before I commit? This is a pretty small patch.
2014-09-01 Andrew Sutton
Check requirements on function conc
Jonathan> I'll commit it later this week unless I hear objections from
Jonathan> Tom.
It looks reasonable to me.
Tom
On Mon, Sep 29, 2014 at 10:17:04AM +0200, Tobias Burnus wrote:
> Dominique Dhumieres wrote:
> > The failures for the gfortran.dg/coarray_collectives_9.f90 are fixed
> > with the following patch:
>
> Looks good to me. The patch is OK with a ChangLog.
Actually, I missed the following part:
...
-
Update the docs again. Committed to trunk.
commit ef8c7f18cdfc087d54b0bbe2a1cd171409eb1f18
Author: Jonathan Wakely
Date: Mon Sep 29 15:13:33 2014 +0100
* doc/xml/manual/status_cxx2011.xml: Update.
* doc/html/manual/status.html: Regenerate.
diff --git a/libstdc++-v3/doc/xml/manual/s
Hi!
On Mon, 29 Sep 2014 13:58:31 +, "Tannenbaum, Barry M"
wrote:
> In a nutshell, add the following code to main() before the call to f3():
>
> int status = __cilkrts_set_param("nworkers", "2");
> if (0 != status) {
> // Failed to set the number of Cilk workers
> ret
On Fri, Aug 1, 2014 at 10:10 PM, Teresa Johnson wrote:
> On Wed, Jul 23, 2014 at 2:08 PM, Teresa Johnson wrote:
>> On Tue, Jul 22, 2014 at 7:29 PM, Jeff Law wrote:
>>> On 03/26/14 17:44, Teresa Johnson wrote:
Recently I discovered that the profile updates being performed by jump
t
Hi,
Currently if call to atexit (lto_wrapper_cleanup) fails we
won't report error as we haven't initialized error-reporting
infrastructure. This patch moves this call after diagnostic_initialize.
I hope that we can't exit inside diagnostic_initialize. Otherwise we
won't cleanup after it.
Ok for t
In a nutshell, add the following code to main() before the call to f3():
int status = __cilkrts_set_param("nworkers", "2");
if (0 != status) {
// Failed to set the number of Cilk workers
return status;
}
Here's the details:
There are three sources of information the C
On Mon, Sep 29, 2014 at 04:53:26PM +0400, Gleb Fotengauer-Malinovskiy wrote:
> 2014-09-27 Gleb Fotengauer-Malinovskiy
Two spaces around name on each side.
>
> libitm/
>
> PR libitm/61164
> * local_atomic: Rename __always_inline to __libitm_always_inline
> to eliminate glibc ma
Hi Mike,
I have not seen any trouble arising following the fix to PR 61407
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407).
The patch committed is here:
https://gcc.gnu.org/viewcvs?rev=215251&root=gcc&view=rev
I’ve just tested the exact same change on the 4.9 branch, and it bootstraps and
On 29/09/14 06:02 -0700, Siva Chandra wrote:
The attached patch refactors python/hook.in so that there are no
individual function calls to load pretty printers and xmethods. This
was suggested by Tom here:
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02589.html. He indicates
that it is better to
On 26/09/14 23:42 +0200, Andreas Schwab wrote:
Tested on aarch64-suse-linux, where try_cpu=generic.
Andreas.
* configure.host: Use host_cpu, not try_cpu, to define default
abi_baseline_pair.
---
libstdc++-v3/configure.host | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
The attached patch refactors python/hook.in so that there are no
individual function calls to load pretty printers and xmethods. This
was suggested by Tom here:
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02589.html. He indicates
that it is better to put as little as possible in the hook file. Th
On 26 September 2014 23:05, Andreas Schwab wrote:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34c65c4
>
> * sanitizer_common/sanitizer_platform_limits_posix.h
> (__sanitizer___kernel_old_uid_t, __sanitizer___kernel_old_gid_t)
> [__aarch64__]
2014-09-27 Gleb Fotengauer-Malinovskiy
libitm/
PR libitm/61164
* local_atomic: Rename __always_inline to __libitm_always_inline
to eliminate glibc macro redefinition.
(__libitm_always_inline): Add inline.
(__calculate_memory_order): Remove inline.
On Sat, Sep 27, 2014 at 3:54 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> -fshort-double has crashes the compiler since 4.6 (see PR60410)
> Since it's an obscure option that apparently nobody uses it the
> best way to fix it seems to just remove it.
>
> This prevents constant ICEs when running an
On Sat, Sep 27, 2014 at 3:54 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> Make -Q --help print the --param default, min, max values, similar
> to how it does print the defaults for other flags. This is useful
> to let a option auto tuner automatically query all needed information
> abourt gcc par
On Wed, Sep 24, 2014 at 03:20:44PM -0600, Jeff Law wrote:
> On 09/24/14 14:32, Ilya Enkovich wrote:
> >2014-09-24 19:27 GMT+04:00 Jeff Law :
> >>On 09/24/14 00:56, Ilya Enkovich wrote:
>
> >>>
> >>>After register allocation we have no idea where GOT address is and
> >>>therefore delegitimize_addre
Hi Ramana, Richard,
This patch implements the attribute target (and pragma) to allow
function based interworking.
as in the updated documentation, the syntax is:
__attribute__((target("thumb"))) int foo()
Forces thumb mode for function foo only. If the file was compiled with
-mthumb iit has no
Hi!
On Mon, 22 Sep 2014 19:21:33 +, "Tannenbaum, Barry M"
wrote:
> That's exactly correct.
>
> There are two ways to implement a work-stealing scheduler. We refer to them
> as: [...]
Thanks for the explanation.
> Cilk implements Parent Stealing. Since you're running with 1 worker, there'
> From: Ulrich Weigand [mailto:uweig...@de.ibm.com]
> Maciej W. Rozycki wrote:
> > On Mon, 4 Aug 2014, Edmar wrote:
> >
> > > Committed on trunk, revision 213596
> > > Committed on 4.9 branch, revision 213597
> >
> > This change regressed GDB for e500v2 multilibs, presumably because it
> > does
On Fri, 26 Sep 2014, Jan Hubicka wrote:
> Hello,
> this is patch to preserve TBAA for anonymous types to LTO. The difference
> can be seen on the testcase:
>
> namespace
> {
> struct A {int a;};
> struct B {int b;};
> }
>
> struct A aa,*a=&aa;
> struct B bb,*b=&bb;
>
> void
> setA()
> {
>
On 26/09/14 23:42 +0200, Andreas Schwab wrote:
Generated by make new-abi-baseline on aarch64-suse-linux.
Andreas.
* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: New
file.
OK, thanks.
Maciej W. Rozycki wrote:
> On Mon, 4 Aug 2014, Edmar wrote:
>
> > Committed on trunk, revision 213596
> > Committed on 4.9 branch, revision 213597
>
> This change regressed GDB for e500v2 multilibs, presumably because it
> does not understand the new DWARF register numbers and does not know how
It looks like the committee has reversed his opinion on this since the 2008
interp. There is wording in both F2003 and F2008 standards that supports this
view, so I’ve closed the PR.
Now, here’s a tiny patch to silence the related warning in PR36534. I also
remove the condition on gfc_current_f
1 - 100 of 109 matches
Mail list logo
