*ping*
2013/4/11 Alexander Ivchenko :
> Hi,
>
> The same motivation as for:
> http://gcc.gnu.org/ml/gcc-cvs/2013-03/msg00786.html
>
> "Since -fpic option is turned on by default in Android we have certain test
> fails. The reason for that is that those tests rely on the
> availability of functions
2013/5/24 Xinyu Qi :
> Hi,
>
> For this simple case, compiled with option -march=iwmmxt -O,
> #define N 64
> signed int b[N];
> signed long long j[N], d[N];
> void foo (void)
> {
> int i;
> for (i = 0; i < N; i++)
> j[i] = d[i] << b[i];
> }
> An internal compiler error occurs,
> error: in
On Thu, May 23, 2013 at 11:54:05PM +0200, Rainer Orth wrote:
> > Agreed, that seems the best course of action if that's an option.
>
> I just remembered that we aren't there yet even on mainline:
>
> * This snippet
>
> http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01255.html
>
> is necessary
> I've found it is good to have also one mode to invalidate a register for
> all uses; it seems natural to use VOIDmode for that, and then we can use
> BLKmode for all but the first hard register of a multi-hard-reg register.
OK, that sounds sensible.
> I have attached the patch that makes the re
> 2013-05-19 Easwaran Raman
>
> PR tree-optimization/57322
> * (build_and_add_sum): If a BB is empty, set the UID of the
> statement added to the BB to be 1.
Missing filename in the ChangeLog.
--
Eric Botcazou
On Thu, May 23, 2013 at 7:26 PM, Easwaran Raman wrote:
> This addresses the case where UID alone is not sufficient to figure
> out which statement appears earlier in a BB. Bootstraps and no test
> regressions in x86_64 on linux. Ok for trunk?
Why not simply conservatively use gimple_uid (a) <= g
On Thu, May 23, 2013 at 9:47 PM, Marc Glisse wrote:
> Hello,
>
> this is a simple patch to reduce a bit the noise in PR57324 (undefined
> behavior flagged by clang). I only handled some of the most obvious ones.
> Passes bootstrap+testsuite on x86_64-linux-gnu.
Hm, so ISO C99 says in 6.5.7/4 that
On 23 May 2013 21:56, Rainer Orth wrote:
>
> Right, it only got enable by defaulting --enable-libstdcxx-time to auto.
I think it would have been enabled previously with
--enable-libstdcxx-time=rt, but it wasn't tested and so didn't make it
into the linker script at the same time as the GNU symbol
On Thu, May 23, 2013 at 11:42 PM, Jeff Law wrote:
> On 05/23/2013 02:59 PM, Jakub Jelinek wrote:
>>
>> On Thu, May 23, 2013 at 02:44:48PM -0600, Jeff Law wrote:
>>>
>>> On 05/23/2013 02:31 PM, Richard Henderson wrote:
I think we need more weigh in from other maintainers on this, rather
>
On Fri, May 24, 2013 at 12:23 AM, Alexander Ivchenko wrote:
> Hi,
>
> The following patch fixes PR57385
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57385)
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 51e7b9e..cca61e7 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,9 @@
With the attached change, the compiler willl now take into account the subtype
constraints added by renaming discriminants in the derivation of untagged
discriminated types to determine the size of mutable objects of the derived
types, instead of using the same size as for the root type.
Tested
On Fri, 24 May 2013, Richard Biener wrote:
On Thu, May 23, 2013 at 9:47 PM, Marc Glisse wrote:
Hello,
this is a simple patch to reduce a bit the noise in PR57324 (undefined
behavior flagged by clang). I only handled some of the most obvious ones.
Passes bootstrap+testsuite on x86_64-linux-gnu
On Thu, 23 May 2013, Christophe Lyon wrote:
> This patch mentions Address Sanitizer on ARM in the gcc-4.9/changes.html
> pages. (and re-enables the "General Optimizer Improvements" section)
>
> Is it OK to commit?
Looks good to me, thanks!
Gerald
On Fri, May 24, 2013 at 10:33 AM, Marc Glisse wrote:
> On Fri, 24 May 2013, Richard Biener wrote:
>
>> On Thu, May 23, 2013 at 9:47 PM, Marc Glisse wrote:
>>>
>>> Hello,
>>>
>>> this is a simple patch to reduce a bit the noise in PR57324 (undefined
>>> behavior flagged by clang). I only handled s
Quoting Eric Botcazou :
+static bool
+move2add_valid_value_p (int regno, enum machine_mode mode)
[...]
+ for (i = hard_regno_nregs[regno][mode] - 1; i > 0; i--)
+if (reg_mode[i] != BLKmode)
+ return false;
I think that a 'regno' is missing in the second hunk.
Huh? Could you be more
On Fri, May 24, 2013 at 10:15:29AM +0200, Richard Biener wrote:
> On Thu, May 23, 2013 at 9:47 PM, Marc Glisse wrote:
> > Hello,
> >
> > this is a simple patch to reduce a bit the noise in PR57324 (undefined
> > behavior flagged by clang). I only handled some of the most obvious ones.
> > Passes b
Jonathan Wakely writes:
> On 23 May 2013 21:56, Rainer Orth wrote:
>>
>> Right, it only got enable by defaulting --enable-libstdcxx-time to auto.
>
> I think it would have been enabled previously with
> --enable-libstdcxx-time=rt, but it wasn't tested and so didn't make it
> into the linker scrip
2013/5/24 Jakub Jelinek :
> So, let's talk about other options, is constexpr/const on
> std::chrono::steady_clock::is_steady
> required by the standard (as in, could we export
> _ZNSt6chrono12steady_clock9is_steadyE@@GLIBCXX_3.4.19
> and let the library say which case it is, it would be constexpr w
On Fri, May 24, 2013 at 09:57:05AM +0200, Jakub Jelinek wrote:
> Thus, what about this version (just slightly modified, headers remain the
> same, but we export _ZNSt6chrono12steady_clock3nowEv@@GLIBCXX_3.4.19
> even if monotonic clock isn't supported, it will just be work the same as
> _ZNSt6chron
Jakub Jelinek writes:
> On Thu, May 23, 2013 at 11:54:05PM +0200, Rainer Orth wrote:
>> > Agreed, that seems the best course of action if that's an option.
>>
>> I just remembered that we aren't there yet even on mainline:
>>
>> * This snippet
>>
>> http://gcc.gnu.org/ml/gcc-patches/2013-05/
Hi Tobias,
> Rainer Orth wrote:
>> how should we proceed with this patch now, given the questions above?
>> Install as is, although it doesn't seem really beneficial, or drop it?
>
> I would install it. Actually, did you get a libquadmath dependence on
> Solaris or not?
I do, both with Solaris ld
Adding back community
On Fri, May 24, 2013 at 1:15 PM, Kirill Yukhin wrote:
>>
>> Ok for trunk and 4.8 after 4.8.1 is out.
>>
>
> Checked in to trunk:
> http://gcc.gnu.org/ml/gcc-cvs/2013-05/msg00803.html (+
> http://gcc.gnu.org/ml/gcc-cvs/2013-05/msg00804.html for missed test).
> And 4.8 branch:
This is the gigi bits to enable support for pragma No_Inline in the Ada
compiler. Nothing more to say, except that specifying also pragma Inline
yields a warning and specifying also pragma Inline_Always is an error.
Tested on x86_64-suse-linux, applied on the mainline.
2013-05-24 Eric Botcaz
This (partially) coordinates the floating-point settings of the front-end and
the middle-end for the Ada compiler:
- if Machine_Overflows is set to True, -ftrapping-math is enabled in the
compiler; otherwise, it is disabled (unless overridden by the user).
- if Signed_Zeros is set to True, -fsi
On May 22, 2013 23:28Tobias Burnus wrote:
A rather simple patch found while testing the draft finalization patch.
For a "class(...), allocatable, intent(out)" dummy argument, the
actual argument has to be deallocated. That worked for scalar
polymorphic vars, but not for polymorphic arrays.
A
Hi,
both issues already fixed. Committed to mainline.
Thanks,
Paolo.
/
2013-05-24 Paolo Carlini
PR c++/26572
* g++.dg/template/error51.C: New.
2013-05-24 Paolo Carlini
PR c++/25503
* g++.dg/template/bitfield2.C: New.
Index: g++.dg/tem
Hi Michael,
> > - What about define_insn_and_split? Currently, we can define
> "predicable"
> > for a define_insn_and_split,
> Yes, you're right. Currently define_subst cannot be applied to
> define_insn_and_split. That's not implemented yet because I didn't
> see
> a real usages of define_substs
Hello,
I'd like to fix this ancient PR.
The attached patch picks up the suggested changes mentioned in comment
#3 to avoid changing the FPSCR.FR bit in the sdivsi3_i4 and udivsi3_i4
library functions. As mentioned in the PR, this makes integer division
a bit slower when using -mdiv=call-fp, but i
> Unfortunately, that is a strong point against define_subst in my case,
> since on arm we have more than 400 predicable patterns, of we which we
> might want to modify dozens to perform this cond_exec restriction.
> And creating custom subst-attributes for each one would really make
> things hard
Bionic prior to Gingerbread doesn't support sincos*, but upstream GCC
enables sincos optimization for OPTION_BIONIC unconditionally since
4.6. I'd like to propose a new flag -foptimize-sincos for NDK to
maintain backward compatibility.
1. For BIONIC: sincos optimization is disabled by default. A
After spending some time to try retaining some abnormal SSA name
uninitialized uses I gave up and just punt like below.
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
Richard.
2013-05-24 Richard Biener
PR tree-optimization/57287
* tree-ssa-uninit.c (compute_uninit_
> > Unfortunately, that is a strong point against define_subst in my
> case,
> > since on arm we have more than 400 predicable patterns, of we
> which we
> > might want to modify dozens to perform this cond_exec
> restriction.
> > And creating custom subst-attributes for each one would really
> mak
On Fri, May 24, 2013 at 12:53 PM, Andrew Hsieh wrote:
> Bionic prior to Gingerbread doesn't support sincos*, but upstream GCC
> enables sincos optimization for OPTION_BIONIC unconditionally since
> 4.6. I'd like to propose a new flag -foptimize-sincos for NDK to
> maintain backward compatibility.
On Fri, May 24, 2013 at 02:10:18PM +0200, Richard Biener wrote:
> That's a pretty awful option name for one that makes us assume the target
> C library has a sincos function.
>
> I'd rather think about a way to specify, for all known builtins, whether GCC
> should generate calls to such function w
Richard, the target hook (libc_has_function) for what you described is
waiting for a review:
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg01201.html
However, it doesn't have command line options support.
Alexander
2013/5/24 Richard Biener :
> On Fri, May 24, 2013 at 12:53 PM, Andrew Hsieh wrot
Predictive commoning thinks that { a, +, a + 1 } and { 2 * a, +, a + 1 }
are just 1 iteration apart because when verifying if the difference
between a and 2*a is a multiple of a + 1 it falls into the trap
of double_int_constant_multiple_p returning true (but not initializing
a multiplier) for the
On Fri, May 24, 2013 at 2:18 PM, Jakub Jelinek wrote:
> On Fri, May 24, 2013 at 02:10:18PM +0200, Richard Biener wrote:
>> That's a pretty awful option name for one that makes us assume the target
>> C library has a sincos function.
>>
>> I'd rather think about a way to specify, for all known buil
Hi,
I think we can resolve this very old issue too: we don't warn at all for
bitfields of size exceeding the type when it's bool or enum. I have no
idea why historically we decided to not do that, but certainly all the
modern compilers I have at hand do warn, by default, thus it seems safe
to
This patch (trunk r198547)
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00061.html
fixes an ICE in gcc 4.8:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56732
Ok to backport to 4.8 branch?
Thanks,
Greta
> -Original Message-
> From: Richard Earnshaw
> Sent: 02 May 2013 15:45
> To: Greta Yo
On Fri, May 24, 2013 at 02:23:45PM +0200, Richard Biener wrote:
> But for example memset/memcpy always have that set, even if no prototype
> is in the source. So, is that decl_implicit_p really supposed to tell us
> whether we've seen a compatible prototype?
decl_implicit_p isn't whether we've se
On 05/24/13 13:26, Greta Yorsh wrote:
This patch (trunk r198547)
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00061.html
fixes an ICE in gcc 4.8:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56732
Ok to backport to 4.8 branch?
Ok.
regards
Ramana
Thanks,
Greta
gcc/ChangeLog
2013-05-02 Gr
On Fri, May 24, 2013 at 2:28 PM, Jakub Jelinek wrote:
> On Fri, May 24, 2013 at 02:23:45PM +0200, Richard Biener wrote:
>> But for example memset/memcpy always have that set, even if no prototype
>> is in the source. So, is that decl_implicit_p really supposed to tell us
>> whether we've seen a c
> As things stand now, if "predicable" is set to "no" for a particular
> alternative, the value of control_attr is irrelevant, that alternative
> will never have a cond_exec version. In your scheme, however,
> the presence of triggers the creation of cond_exec
> variants for all of the alternative
On Thu, May 23, 2013 at 5:35 PM, Jeff Law wrote:
> Thanks. I wasn't aware of that wiki page. I'll be reading it today :-)
The .odp attachment is actually a bit more informative, you should
take a look at that too, if you have the time.
Comments welcome, so I can include that in the new .texi ve
Hi!
This patch contains C++ parser changes etc. to handle
#pragma omp {teams,target {,data,update},distribute} parsing
all the way through till omp lowering (it bombs badly in omp expansion,
but already omp lowering will need to be tought out).
Things not handled yet are #pragma omp declare target
Hi,
> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
>
> Zdenek, does this look ok? double_int_constant_multiple_p seems to
> be only used from aff_combination_constant_multiple_p.
yes,
Zdenek
On Thu, May 23, 2013 at 04:50:34PM -0400, Jason Merrill wrote:
> This is a simple oversight in the ref-qualifier code.
>
> Tested x86_64-pc-linux-gnu, applying to trunk. Jakub, is this OK for 4.8.1?
Ok, thanks.
> commit 0914d39b7335966f5d828c1b4225beb2e5448755
> Author: Jason Merrill
> Date:
On Fri, May 24, 2013 at 11:00:26AM +0200, Rainer Orth wrote:
> Jakub Jelinek writes:
>
> > On Thu, May 23, 2013 at 11:54:05PM +0200, Rainer Orth wrote:
> >> > Agreed, that seems the best course of action if that's an option.
> >>
> >> I just remembered that we aren't there yet even on mainline:
> On Thu, May 23, 2013 at 5:35 PM, Jeff Law wrote:
> > Thanks. I wasn't aware of that wiki page. I'll be reading it today :-)
>
> The .odp attachment is actually a bit more informative, you should
> take a look at that too, if you have the time.
>
> Comments welcome, so I can include that in th
Hi,
On Thu, May 23, 2013 at 11:38:10AM +0200, Richard Biener wrote:
> On Thu, 23 May 2013, Eric Botcazou wrote:
>
> > > earlier this week I asked on IRC whether we could have non-top-level
> > > BIT_FIELD_REFs and Richi said that we could. However, when I later
> > > looked at SRA code, quite ap
Jakub Jelinek writes:
>> It occured to me that there might be a far less intrusive option to still
>> allow a Solaris backport: instead of going the libstdc++.spec route
>> (which I still think is the correct way forward), statically handle -lrt
>> addition in g++spec.c, controlled by a macro def
Why would we want to pedwarn? As far as I can tell, the standard
doesn't say this is ill-formed. 9.6 says,
"The value of the integral constant expression may be larger than the
number of bits in the object representation (3.9) of the bit-field’s
type; in such cases the extra bits are used as
On Fri, May 24, 2013 at 03:35:15PM +0200, Rainer Orth wrote:
> > I've posted today wouldn't work well on Solaris?
>
> It should work on the 4.8 branch (I'll include it in my bootstraps this
> weekend), but on mainline the failures due to missing nanosleep/-lrt
> will remain.
Thanks. Please make
Jakub Jelinek writes:
> On Fri, May 24, 2013 at 03:35:15PM +0200, Rainer Orth wrote:
>> > I've posted today wouldn't work well on Solaris?
>>
>> It should work on the 4.8 branch (I'll include it in my bootstraps this
>> weekend), but on mainline the failures due to missing nanosleep/-lrt
>> will
On 24 May 2013 14:40, Jakub Jelinek wrote:
>
> Note that for 4.8.1 this is kind of urgent, because it is blocking 4.8.1-rc2
> and thus also 4.8.1 release, so the sooner this gets resolved, the better.
Sorry about that, I didn't realise the trunk change would affect 4.8.1
> Jonathan/Benjamin, coul
On Fri, May 24, 2013 at 02:56:24PM +0100, Jonathan Wakely wrote:
> > Jonathan/Benjamin, could you please review the patch in the mean time,
> > so that if it works well for Rainer, it can be applied immediately and
> > 4.8.1-rc2 rolled, even during the weekend?
>
>
> In the fallback for steady_cl
On Fri, 24 May 2013, Jakub Jelinek wrote:
On Fri, May 24, 2013 at 10:15:29AM +0200, Richard Biener wrote:
On Thu, May 23, 2013 at 9:47 PM, Marc Glisse wrote:
Hello,
this is a simple patch to reduce a bit the noise in PR57324 (undefined
behavior flagged by clang). I only handled some of the m
On 05/24/2013 01:53 AM, David Edelsohn wrote:
Also, you are not updating testsuite/ChangeLog.
http://gcc.gnu.org/codingconventions.html#ChangeLogs says "There is no
established convention on when ChangeLog entries are to be made for
testsuite changes."
I prefer not to mess with testsuite/Ch
On 24 May 2013 15:07, Jakub Jelinek wrote:
> On Fri, May 24, 2013 at 02:56:24PM +0100, Jonathan Wakely wrote:
>> > Jonathan/Benjamin, could you please review the patch in the mean time,
>> > so that if it works well for Rainer, it can be applied immediately and
>> > 4.8.1-rc2 rolled, even during t
When FMA_EXPR was added to potential_constant_expression_1, it wasn't
added to cxx_eval_constant_expression at the same time...
Regression tested x86_64-pc-linux-gnu, applying to trunk. David, can
you verify that this fixes bootstrap on AIX?
commit a78fee4d0a9c2a353637f239c6ac189227248491
Auth
On Fri, May 24, 2013 at 04:07:48PM +0200, Jakub Jelinek wrote:
> On Fri, May 24, 2013 at 02:56:24PM +0100, Jonathan Wakely wrote:
> > > Jonathan/Benjamin, could you please review the patch in the mean time,
> > > so that if it works well for Rainer, it can be applied immediately and
> > > 4.8.1-rc2
On 24 May 2013 15:16, Jakub Jelinek wrote:
> On Fri, May 24, 2013 at 04:07:48PM +0200, Jakub Jelinek wrote:
>> On Fri, May 24, 2013 at 02:56:24PM +0100, Jonathan Wakely wrote:
>> > > Jonathan/Benjamin, could you please review the patch in the mean time,
>> > > so that if it works well for Rainer,
Hi,
On 05/24/2013 03:36 PM, Jason Merrill wrote:
Why would we want to pedwarn? As far as I can tell, the standard
doesn't say this is ill-formed. 9.6 says,
"The value of the integral constant expression may be larger than the
number of bits in the object representation (3.9) of the bit-fiel
On 05/24/2013 04:16 PM, Jason Merrill wrote:
When FMA_EXPR was added to potential_constant_expression_1, it wasn't
added to cxx_eval_constant_expression at the same time...
Sorry.
Paolo.
On Fri, May 24, 2013 at 03:29:43PM +0100, Jonathan Wakely wrote:
> >> in the latter). And there is no conversion in between the two.
> >>
> >> Perhaps I'd have to do something like:
> >> return time_point(system_clock::now().time_since_epoch());
> >> ? Can try that.
> >
> > Ah, but the duration
> 2013-05-23 Martin Jambor
>
> * tree-cfg.c (verify_expr): Verify that BIT_FIELD_REFs, IMAGPART_EXPRs
> and REALPART_EXPRs have scalar type.
I cannot formally approve, but this looks the right test to me.
--
Eric Botcazou
On Fri, 24 May 2013, Richard Biener wrote:
> On Thu, May 23, 2013 at 9:47 PM, Marc Glisse wrote:
> > Hello,
> >
> > this is a simple patch to reduce a bit the noise in PR57324 (undefined
> > behavior flagged by clang). I only handled some of the most obvious ones.
> > Passes bootstrap+testsuite o
Jakub Jelinek writes:
> So, adjusted patches attached, ok for trunk/4.8 if they pass
> bootstrap/regtest? Guess Rainer will need to on top of that adjust
> Solaris baseline_symbols.txt files.
I meant to look into that, but usually I only update the baselines for
x.y.0 releases, not micro releas
On Fri, May 24, 2013 at 05:05:52PM +0200, Eric Botcazou wrote:
> > 2013-05-23 Martin Jambor
> >
> > * tree-cfg.c (verify_expr): Verify that BIT_FIELD_REFs, IMAGPART_EXPRs
> > and REALPART_EXPRs have scalar type.
>
> I cannot formally approve, but this looks the right test to me.
I agr
Hi,
when modifying an indirectly recursively called function, IPA-SRA may
remove a statement for which we have already gathered references in
the symbol table and replace it with new statement(s), making the
symbol table information stale which can lead to problems like PR
57294.
The patch below
> 2013-05-24 Martin Jambor
>
> * cgraph.h (ipa_record_stmt_references): Declare.
> * cgraphbuild.c (ipa_record_stmt_references): New function.
> (build_cgraph_edges): Use ipa_record_stmt_references.
> (rebuild_cgraph_edges): Likewise.
> (cgraph_rebuild_references):
> > As things stand now, if "predicable" is set to "no" for a
> particular
> > alternative, the value of control_attr is irrelevant, that
> alternative
> > will never have a cond_exec version. In your scheme, however,
> > the presence of triggers the creation of
> cond_exec
> > variants for all of
On 24 May 2013 16:03, Jakub Jelinek wrote:
>
> So, adjusted patches attached, ok for trunk/4.8 if they pass
> bootstrap/regtest?
Yes, they're OK - thanks for sorting it out.
On 24 May 2013 16:20, Gedare Bloom wrote:
> Updated patch attached to address the comments. I was not able to
> figure out how to build the libstdc++ documentation to verify my doc
> changes although I did run xmllint successfully.
Did you see
http://gcc.gnu.org/onlinedocs/libstdc++/manual/docume
2013/5/23 Chung-Ju Wu :
>
> The patch is revised accordingly as follows:
> - The tar files, including gmp/mpfr/mpc/isl/cloog, are left under directory.
> - In the shell script, we should use '=' as equality comparison operator.
>
> Thanks for the review comments and Paolo's approval.
> I will c
The following patch contains some changes needed for porting LRA to
rs6000 and s390.
The patch was successfully bootstrapped on x86/x86-64.
Committed as rev. 199298.
2013-05-24 Vladimir Makarov
* lra-constraints.c (emit_spill_move): Use smaller mode for
mem-mem moves.
> I agree it is desirable, but is it enough to ensure that they will be only
> toplevel? Can't you e.g. do a VIEW_CONVERT_EXPR from an integer type or
> floating/vector type etc. to struct type, then the verifier wouldn't
> discover there is VIEW_CONVERT_EXPR 32>>?
Sure, you can apply VIEW_CONVE
On 13-05-23 4:51 PM, Steven Bosscher wrote:
Ping**2
Steven, sorry for the delay. The patch is ok. Thanks for better
documentation too. We need it as the scheduler is becoming more and
more complicated.
2013/5/23 Jakub Jelinek :
> On Wed, May 22, 2013 at 08:30:35PM -0400, David Malcolm wrote:
>> The arrays of thresholds in gcc/bb-reorder.c appear not to have changed
>> since 2004 (in r80564).
>>
>> As part of my hope of quashing global state in gcc, I'd like to mark
>> them as const.
>>
>> Bootstr
On Fri, May 24, 2013 at 10:16 AM, Jason Merrill wrote:
> When FMA_EXPR was added to potential_constant_expression_1, it wasn't added
> to cxx_eval_constant_expression at the same time...
>
> Regression tested x86_64-pc-linux-gnu, applying to trunk. David, can you
> verify that this fixes bootstra
On 05/24/2013 10:50 AM, Paolo Carlini wrote:
+ || ((TREE_CODE (type) == ENUMERAL_TYPE
+ && (tree_int_cst_lt
+ (TYPE_SIZE (ENUM_UNDERLYING_TYPE (type)), w)))
+ || (TREE_CODE (type) == BOOLEAN_TYPE
+ && tree_
On Fri, 2013-05-24 at 23:51 +0800, Chung-Ju Wu wrote:
> 2013/5/23 Jakub Jelinek :
> > On Wed, May 22, 2013 at 08:30:35PM -0400, David Malcolm wrote:
> >> The arrays of thresholds in gcc/bb-reorder.c appear not to have changed
> >> since 2004 (in r80564).
> >>
> >> As part of my hope of quashing glo
On 05/23/2013 06:42 PM, Iyer, Balaji V wrote:
I got all your responses and, if I remove the compile, execute and
errors directories but keep cilk-plus and array notation, maybe even
abbreviate array notation to "an", (in future cilk keywords to "ck",
pragma simd to "ps" and elemental function t
Trying to send again; gcc_patches list bounced original message.
-- Forwarded message --
From: Caroline Tice
Date: Fri, May 24, 2013 at 9:15 AM
Subject: Re: [PATCH, updated] Vtable pointer verification, C++ front
end changes (patch 1 of 3)
To: Jason Merrill
Cc: Diego Novillo , Lu
On Fri, May 24, 2013 at 11:26 AM, Jonathan Wakely wrote:
> On 24 May 2013 16:20, Gedare Bloom wrote:
>> Updated patch attached to address the comments. I was not able to
>> figure out how to build the libstdc++ documentation to verify my doc
>> changes although I did run xmllint successfully.
>
>
Please find attached the updated patch.
bootstrapped / regtested for i686-pc-linux-gnu
regtested for i686-pc-linux-gnu X sh-elf
regtested in gcc 4.8 branch for i686-pc-linux-gnu X avr
(--target-board atmega128-sim)
2013-05-24 Joern Rennecke
PR rtl-optimization/56833
* postrel
On 05/21/2013 02:23 AM, Richard Biener wrote:
On Fri, May 17, 2013 at 5:51 PM, Jeff Law wrote:
As I believe I pointed out in a follow-up message, 254.gap is depending on
signed overflow semantics.
This patch avoids eliminating a cast feeding a conditional when the
SSA_NAME's range has overflow
Hi,
On 05/24/2013 06:12 PM, Jason Merrill wrote:
On 05/24/2013 10:50 AM, Paolo Carlini wrote:
+ || ((TREE_CODE (type) == ENUMERAL_TYPE
+&& (tree_int_cst_lt
+(TYPE_SIZE (ENUM_UNDERLYING_TYPE (type)), w)))
+ || (TREE_CODE (type) == BOOLEAN_TYPE
+
OK.
Jason
In that case, if my insert_stmt immediately follows dep_stmt and both
have the same UID, not_dominated_by would return true and I will end
up updating insert_stmt to dep_stmt which is wrong.
- Easwaran
On Fri, May 24, 2013 at 1:07 AM, Richard Biener
wrote:
> On Thu, May 23, 2013 at 7:26 PM, Easw
Hello Richard, et al.,
Attached please find a patch with the following changes:
1. Test-suite codes were moved to the appropriate location as suggested below
And the following modifications that RTH mentioned in
(http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01400.html)
2. ARRAY_NOTATION
I'm ok inasmuch as the relevant tests are shared between c/c++.
"Iyer, Balaji V" wrote:
[I included Jeff Law also in this conversation]
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Aldy Hernandez
> Sent: Thursday, May
On Fri, May 24, 2013 at 05:52:11PM +, Iyer, Balaji V wrote:
> * gcc.dg/cilk-plus/AN/array_test1.c: New test.
...
> * gcc.dg/cilk-plus/AN/cilkplus_AN_c.exp: New script.
Ok, I guess I can live with /AN/ extra level, but can you please
move it still to c-c++-common/cilk-plus/AN/ for a
On 2013-05-23 11:51 , Paul Pluzhnikov wrote:
Greetings,
This patch adds (relatively) cheap bounds and dangling checks to
vector, similar to the checks I added to vector in r195373,
r195356, etc.
Ok for google branches (gcc-4_7, gcc-4_8, integration) ?
OK.
Diego.
Hi,
a couple of tiny tweaks that should reduce a bit the risk of confusions
and subtle bugs (mostly suggested by Daniel, thanks!)
Thanks,
Paolo.
2013-05-24 Paolo Carlini
* include/ext/type_traits.h (__is_null_pointer): Add std::nullptr_t
overload.
Jonathan,
On Thu, May 23, 2013 at 10:13 AM, Paul Pluzhnikov
wrote:
> On Thu, May 23, 2013 at 9:14 AM, Jonathan Wakely
> wrote:
>
>> I was wondering the other day whether we should put these checks on
>> trunk and enable them automatically when !defined(__OPTIMIZE__)
>
> FWIW, we keep this under
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jakub Jelinek
> Sent: Friday, May 24, 2013 2:03 PM
> To: Iyer, Balaji V
> Cc: Jeff Law; r...@redhat.com; Aldy Hernandez; 'Joseph S. Myers';
> 'gcc-patches'
> Subject: Re: [PI
On May 24, 2013, at 12:02 AM, Alexander Ivchenko wrote:
> *ping*
>
> 2013/4/11 Alexander Ivchenko :
>> Hi,
>>
>> The same motivation as for:
>> http://gcc.gnu.org/ml/gcc-cvs/2013-03/msg00786.html
>>
>> "Since -fpic option is turned on by default in Android we have certain test
>> fails. The rea
We do in fact set TYPE_STRUCTURAL_EQUALITY_P on TEMPLATE_TEMPLATE_PARM,
so we can't assume it isn't set.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit affd3dcbcfeeda70db2413f19948dfd039ce0a0a
Author: Jason Merrill
Date: Fri May 24 13:52:31 2013 -0400
PR c++/56971
* pt.c (an
On Fri, May 24, 2013 at 04:22:43PM +0100, Jonathan Wakely wrote:
> On 24 May 2013 16:03, Jakub Jelinek wrote:
> >
> > So, adjusted patches attached, ok for trunk/4.8 if they pass
> > bootstrap/regtest?
>
> Yes, they're OK - thanks for sorting it out.
Note, I've already committed the patches, but
1 - 100 of 118 matches
Mail list logo
