On 17 August 2011 15:07, Joseph S. Myers wrote:
> On Wed, 17 Aug 2011, Richard Sandiford wrote:
>
>> libgcc/
>> PR target/50090
>> * config/arm/bpabi-lib.h (RENAME_LIBRARY): Use a C-level alias
>> instead of an assembly one.
>
> Is RENAME_LIBRARY_SET used at all after this patch
OK.
Jason
On 14 July 2011 08:45, Xinyu Qi wrote:
>> Hi,
>>
>> It is the fourth part of iWMMXt maintenance.
>>
Can this be broken down further. ? I'll have to do this again but
there are some initial comments below for some discussion.
>
> Since "*cond_iwmmxt_movsi_insn" would be got rid of soon, I keep it
On 11-08-17 22:09 , Gabriel Charette wrote:
Can you approve version 1 instead?!
Sure, that variant is fine as well. Whichever version better suits your
next patch.
The documentation is on the variable in the C file directly as I've
noticed this is what is done most of the time...
I put
Thinking more about this on my way back...
I will only need includes directly included by the current pph, not
the full include tree as I added in version 2 of this patch thinking I
would need it for the line_table...
Can you approve version 1 instead?!
> http://codereview.appspot.com/4904050/di
> -Original Message-
> From: Ramana Radhakrishnan [mailto:ramana.radhakrish...@linaro.org]
At 2011-08-18 09:29:34,"Ramana Radhakrishnan"
wrote:
> Hi ,
>
> Sorry about the delayed review - It's taken me a while to get back to this .
>
> On 14 July 2011 08:35, Xinyu Qi wrote:
> >> > Hi
Attached is the new patch file. Review please!
ChangeLog:
2011-08-18 Jiangning Liu
* config/arm/arm.md (*ior_scc_scc): Enable for Thumb2 as well.
(*ior_scc_scc_cmp): Likewise
(*and_scc_scc): Likewise.
(*and_scc_scc_cmp): Likewise.
(*and_scc_scc_nodom):
On 08/17/2011 09:06 AM, Rainer Orth wrote:
+@deftypefn {Target Hook} tree TARGET_CXX_DECL_MANGLING_CONTEXT (const_tree
@var{decl})
+Return target-specific mangling context of @var{decl}.
+@end deftypefn
This should say "or NULL_TREE". Otherwise OK.
Jason
On 6 July 2011 11:11, Xinyu Qi wrote:
> Hi,
>
> It is the second part of iWMMXt maintenance.
>
> *config/arm/mmintrin.h:
> Revise the iWMMXt intrinsics head file. Fix some intrinsics and add some new
> intrinsics
Is there a document somewhere that lists these intrinsics and what
each of these a
On 6 July 2011 11:18, Xinyu Qi wrote:
> Hi,
>
> It is the fifth part of iWMMXt maintenance.
>
> *config/arm/marvell-f-iwmmxt.md: New file. Add Marvell WMMX pipeline
> description.
Needs addition to MD_INCLUDES .
where are you including this file ?
Ramana
>
> Thanks,
> Xinyu
>
Hi ,
Sorry about the delayed review - It's taken me a while to get back to this .
On 14 July 2011 08:35, Xinyu Qi wrote:
>> > Hi,
>> >
>> > It is the first part of iWMMXt maintenance.
>> >
>> > *config/arm/arm.c (arm_option_override):
>> > Enable iWMMXt with VFP. iWMMXt and NEON are incompatib
OK with a minor nit.
http://codereview.appspot.com/4904050/diff/3001/gcc/cp/pph-streamer.h
File gcc/cp/pph-streamer.h (right):
http://codereview.appspot.com/4904050/diff/3001/gcc/cp/pph-streamer.h#newcode210
gcc/cp/pph-streamer.h:210: extern VEC(pph_stream_ptr, heap)
*pph_read_images;
209
210
On Wed, Aug 17, 2011 at 4:59 PM, Hans-Peter Nilsson wrote:
> On Tue, 16 Aug 2011, Sriraman Tallam wrote:
>
> (I don't see anyone else making this comment, so maybe I missed
> something obvious, but I don't think so...)
>
>> Support for getting CPU type and feature information at run-time.
>>
>> Th
On Tue, 16 Aug 2011, Sriraman Tallam wrote:
(I don't see anyone else making this comment, so maybe I missed
something obvious, but I don't think so...)
> Support for getting CPU type and feature information at run-time.
>
> The following patch provides support for finding the platform type at
>
I changed my mind and kept stream->includes the way it was originally meant to
be, i.e. every stream will have its list of includes not only the main pph's
stream.
More specifically I will be using this for every stream when regenerating the
linemap (and reading the includes in parallel) in my
Hi,
The attached patch is to fix PR target/50068. sh_output_mi_thunk
calls dbr_schedule which doesn't expect to be called in that
situation. Although we could set the environment in output_mi_thunk
in such a way to enable dbr_schedule, it looks a bit overkill for
this relatively rare optimizatio
On 05 August 2011 16:42, Mikael Morin wrote:
OK, I played a bit myself to see what the "right way" would look like, and I
came up with the attached patch, which is complicated, and not even correct.
And indeed, it plays with allocatable and pointer stuff.
So your approach makes some sense now.
I
This patch fixes the fact that referenced child includes were read more then
once before as stream->includes would contain too much.
This refactors the include structure.
pph_read_images now contains a flat vector of the pph_streams of all images
read so far.
pph_out_stream->encoder.w.includes
On Wed, 17 Aug 2011, Artem Shinkarov wrote:
> +For the convenience condition in the vector conditional can be just a
> +vector of signed integer type. In that case this vector is implicitly
> +compared with vectors of zeroes. Consider an example:
Where is this bit tested in the testcases added?
Hi.
No one back end does not use PREFERRED_OUTPUT_RELOAD_CLASS macro now, this
patch remove it. The TARGET_PREFERRED_RELOAD_CLASS target hook should be use
instead.
The patch has been bootstrapped on and regression tested on
x86_64-unknown-linux-gnu for c and c++.
This patch is pre-approv
After some reconsideration I have changed my patch to fix the
-static-libstdc++ build on HP-UX and the bootstrap with C++ build
problem. Originally, I set gcc_cv_ld_static_option to "-aarchive" to
only search archive libraries and this caused problems on IA64 HP-UX
where we used the system unwind
With this patch we can now XFAIL tests that are expected to fail at
runtime. This is how it's used:
/* { dg-final { memmodel-gdb-test { xfail x86*-*-* } } } */
Note, that the test will still run.
This is needed for an upcoming known-to-fail test Andrew will contribute
shortly.
Committed to
Hello Gabriel,
gch...@google.com (Gabriel Charette) a écrit:
> Here is the updated patch.
>
> It nows exposes two libcpp functions to force the source_location for tokens
> when desired.
>
> The lexer then checks for a value set by these functions in cpp_reader and
> acts accordingly when needi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/17/11 01:21, Richard Guenther wrote:
>
> We don't have a way to distinguish branch-taken vs. branch-not-take
> costs, right?
Not that I'm aware of. However, BRANCH_COST does allow the backend to
change the cost of a branch based on its predic
On Aug 15, 2011, at 10:53 AM, Rainer Orth wrote:
> * git libtool.m4 uses -fno-common on *-*-darwin. No idea if this is
> required.
Yes, it is.
Paolo Carlini wrote:
I sanity checked the patch on x86_64-linux and OP reported that on AVR
the patch fixes the regression.
Not really "on" AVR; AVR are just tiny 8-bit microcontrollers ;-)
I obseved the problem when compiling for AVR on a x86-linux-gnu host
where 0x8000 is negative.
J
Hello,
Consider this code snippet:
struct Outer
{
static const int value = 1 ;
template< int value >
struct Inner
{
static const int* get_value() { return &value ; } // #1 -> Error!
} ;
};
template class Outer::Inner<2>;
The line #1 should
Hi,
I prepared the below basing on an hint provided by Joseph on the audit
trail: essentially, I'm replacing all (but two) uses of abs_hwi outside
hwint.c by absu_hwi, a variant which returns an unsigned HOST_WIDE_INT.
All the replacements make sense to me: either we are comparing two abs,
or
On Wed, Aug 17, 2011 at 12:37 AM, Richard Guenther
wrote:
> On Tue, Aug 16, 2011 at 10:50 PM, Sriraman Tallam wrote:
>> Support for getting CPU type and feature information at run-time.
>>
>> The following patch provides support for finding the platform type at
>> run-time, like cpu type and fea
On 08/15/2011 07:49 PM, Thomas Koenig wrote:
Am 14.08.2011 22:54, schrieb Tobias Burnus:
Thomas Koenig wrote:
the attached patch extends conversion warnings to assignments.
OK for trunk?
I get now two warnings for:
complex(8), parameter :: z = cmplx (0.5, 0.5)
r = z
end
The problem is that
2 simple changes,
1 - the gdb-invoked tests we're sometimes getting enough text that it
would interactively ask for
---Type to continue, or q to quit---
which would either cause a hang/timeout while it waited and/or failure.
Fixed by adding 'set height 0' in the script
2 - sync-mem-invali
> I don't expect any issues, the patch is a noop right now (because
> of that sign-extension of unsigned sizetype), but I'll leave it
> until tomorrow for comments anyway.
>
> Thanks,
> Richard.
>
> 2011-08-17 Richard Guenther
>
> * expr.c (get_inner_reference): Sign-extend the constant
>
These two patches clean up:
- The streaming of token values. During PTH, we did not have a generic
tree streamer, so we were implementing our own. Easier to just call
pph_out_tree/pph_in_tree now.
- pph_out_tree_or_ref and pph_out_tree_or_ref_1 were misnamed. Renamed
all references to th
On Wed, Aug 17, 2011 at 06:13:47PM +0200, Tobias Burnus wrote:
> The patch is rather obvious and simple - especially as the use_only
> attribute already exists.
>
> Build and regtested on x86-64-linux.
> OK?
Yes.
--
Steve
The patch is rather obvious and simple - especially as the use_only
attribute already exists.
Build and regtested on x86-64-linux.
OK?
Tobias
2011-08-17 Tobias Burnus
PR fortran/31461
* trans-decl.c (generate_local_decl): Warn about
unused explicitly imported module variables/parameters.
Next step, change the C++ header files to use the new __sync builtins.
pretty straightforward.
mostly.
Turns out, C++ will allow you to specify the memory model as a variable
of type enum memory_order... WTF? I would expect that to be pretty
uncommon, and in order to get that right, we'd ne
I have been looking at changing UPC's method of
recording the blocking factor so that it uses less space
in the tree type node. The suggested method for
achieving this space reduction is to use a hash table to
map pointers to type nodes into UPC blocking factors
(for less commonly used blocking
On Wed, Aug 17, 2011 at 3:58 PM, Richard Guenther
wrote:
> On Wed, Aug 17, 2011 at 3:30 PM, Artem Shinkarov
> wrote:
>> Hi
>>
>> Several comments before the new version of the patch.
>> 1) x != x
>> I am happy to adjust constant_boolean_node, but look at the code
>> around line 9074 in fold-const
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/17/11 01:38, grabekm90 wrote:
>>
>
> The question is: how can we get to know, using GIMPLE mechanism, from
> which parameter a pointer derives?
You'd have to build code to record the derivations. Ideally you'd work
on the SSA graph and just re
Of course when you work on one thing (do not force sizetype for
POINTER_PLUS_EXPR) you run into that other thing you had in the
works (but abandoned because it's sooo boring). Thus, here we come,
the appearant (huh!?) only pre-requesites to making sizetypes
no longer sign-extended (well, unsigned
Hello,
Consider this code snippet:
class C
{
struct Private { };
};
template
struct exploit1
{
C::Private type;
};
exploit1 x1; //#1
At the instantiation point of exploit1 in #1, the compiler should
issue an error because C::Private is private in t
On Wed, Aug 17, 2011 at 3:30 PM, Artem Shinkarov
wrote:
> Hi
>
> Several comments before the new version of the patch.
> 1) x != x
> I am happy to adjust constant_boolean_node, but look at the code
> around line 9074 in fold-const.c, you will see that x x
> elimination, even with adjusted constan
On Wed, 17 Aug 2011, Richard Sandiford wrote:
> libgcc/
> PR target/50090
> * config/arm/bpabi-lib.h (RENAME_LIBRARY): Use a C-level alias
> instead of an assembly one.
Is RENAME_LIBRARY_SET used at all after this patch or should it be
removed?
--
Joseph S. Myers
jos...@codes
On 17/08/11 11:48, Ramana Radhakrishnan wrote:
> On 17 August 2011 08:59, Richard Sandiford
> wrote:
>> EABI functions like __aeabi_f2ulz are defined as aliases of standard
>> libgcc functions like __fixunssfdi. In libgcc.a, the standard function
>> gets the correct hidden visibility, but the al
Tristan,
>>>While alpha/t-vms already extracted symbol information with objdump
>>>--syms, ia64/t-vms still used a hardcoded list
>>>(ia64/vms_symvec_libgcc_s.opt). Since it has the comment `It would
>>>be better to auto-generate this file.', I've omitted it, hoping that
>>>th
Hi Robert,
> My patch still applies cleanly to current HEAD, has this migration
> happened already? If not, what's the current ETA? I'll have almost
> no spare time after this week, I'd like to sort this out before/during
> the weekend if possible.
all the relevant patches have been posted by n
Hi
Several comments before the new version of the patch.
1) x != x
I am happy to adjust constant_boolean_node, but look at the code
around line 9074 in fold-const.c, you will see that x x
elimination, even with adjusted constant_boolean_node, will look about
the same as my code. Because I need to
On Aug 11, 2011, at 1:52 PM, Paolo Bonzini wrote:
> On 08/10/2011 01:14 PM, Rainer Orth wrote:
>> * At the moment, SHLIB_LINK is used in gcc/Makefile.in and the various
>> Make-lang.in fragments to check if the target supports a shared
>> libgcc_s. I've introduced gcc/config/t-slibgcc (from
Jason Merrill writes:
> On 08/16/2011 11:31 AM, Marc Glisse wrote:
>> It might be less invasive to have decl_mangling_context return
>> global_namespace without actually modifying the expr?
>
> Please.
Done, tested as before.
Rainer
2011-08-07 Rainer Orth
Marc Glisse
On 16/08/11 10:28, Ira Rosen wrote:
> Hi,
>
> This patch changes the default vector size for auto-vectorization on
> ARM NEON to 128 bits. This new version is a result of a discussion
> with Richard and Ramana.
>
> wwwdocs changes will follow shortly.
>
> Bootstrapped and tested on arm-linux-gnu
Hi!
2011/7/26 Rainer Orth :
> Robert,
>
>> 2011/7/25 Richard Sandiford :
>>> Robert Millan writes:
This patch adds support for GNU/kFreeBSD systems running on MIPS.
>>>
>>> Looks good. However, Rainer's in the middle of moving things from gcc/
>>> to libgcc/ -- where they belong -- and comm
This patch removes more explicit sizetype references by (but not only by)
introducing convert_to_ptrofftype[_loc]. It's still trivial conversions
so even with the no-op abstraction we can be sure to not introduce new
errors.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
On 17 August 2011 10:34, Tom de Vries wrote:
>
> Ping. http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02173.html OK for trunk?
This is OK.
Ramana
>
> Thanks,
> - Tom
>
On 17 August 2011 08:59, Richard Sandiford wrote:
> EABI functions like __aeabi_f2ulz are defined as aliases of standard
> libgcc functions like __fixunssfdi. In libgcc.a, the standard function
> gets the correct hidden visibility, but the alias retains default
> visibility. This means that DSOs
On 26 July 2011 10:01, Dr. David Alan Gilbert wrote:
> Micahel K. Edwards points out in PR/48126 that the sync is in the wrong
> place
> relative to the branch target of the compare, since the load could float
> up beyond the ldrex.
>
> gcc/
> * config/arm/arm.c (arm_
On Tue, Aug 16, 2011 at 11:12 PM, Artem Shinkarov
wrote:
> Hi, here is a new version of the patch with the adjustments.
>
> Two important comments.
> 1) At the moment when I expand expression mask ? vec0 : vec1, I
> replace mask with (mask == {-1,-1,..}). The first reason is that
> expand_vec_con
On Tue, Aug 16, 2011 at 6:35 PM, Artem Shinkarov
wrote:
> On Tue, Aug 16, 2011 at 4:28 PM, Richard Guenther
> wrote:
Index: gcc/fold-const.c
===
--- gcc/fold-const.c (revision 177665)
+++ gcc/fold-const.c (w
Hi Richard,
Ping. http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02730.html and
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02733.html ok for trunk?
Thanks,
- Tom
Hi Richard,
Ping. http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02173.html OK for trunk?
Thanks,
- Tom
>> In any case, the patch was regtested on x86_64-unknown-linux-gnu. Ok for
>> trunk?
>
> OK. Thanks for the patch!
Thanks, Tobias. Committed as r177825.
Cheers,
Janus
>> 2011-08-16 Janus Weil
>>
>> PR fortran/50070
>> * resolve.c (resolve_fl_variable): Reject non-constant chara
On Wed, Aug 17, 2011 at 9:38 AM, grabekm90 wrote:
>
>
>
> Jeff Law wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 08/16/11 15:35, grabekm90 wrote:
>>
>>> How to resolve a problem with pointers (especially arrays)? For
>>> example, we have a GIMPLE function:
>>>
>>> set_a (i
Hello,
On 16 August 2011 03:32, Ayal Zaks wrote:
> Ok, so this extends the infrastructure to support insns which set an
> arbitrary number of registers, but currently specifically handles only
> REG_INC situations (which set two registers). I'm not against
> {0,1,infinity}, but wonder if this cas
EABI functions like __aeabi_f2ulz are defined as aliases of standard
libgcc functions like __fixunssfdi. In libgcc.a, the standard function
gets the correct hidden visibility, but the alias retains default
visibility. This means that DSOs linked against libgcc.a may end
up exporting the libgcc.a
Jeff Law wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 08/16/11 15:35, grabekm90 wrote:
>
>> How to resolve a problem with pointers (especially arrays)? For
>> example, we have a GIMPLE function:
>>
>> set_a (int * a) { int * D.2701; D.2701 = a + 40; *D.2701 = 7; }
>>
>>
On Tue, Aug 16, 2011 at 10:50 PM, Sriraman Tallam wrote:
> Support for getting CPU type and feature information at run-time.
>
> The following patch provides support for finding the platform type at
> run-time, like cpu type and features supported. The multi-versioning
> framework will use the b
On Tue, Aug 16, 2011 at 11:14 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> ifcvt.c is sometimes over-aggressive in speculating instructions from a
> not-predicted path.
>
> Given:
>
> if (test) goto E; // x not live
> x = big();
> goto L;
>
66 matches
Mail list logo
