On 16 April 2012 20:35, Louis Kruger wrote:
> This patch teaches the arm target about the rev16 and revsh
> instructions which can
> efficiently execute the recently added __builtin_bswap16() function
> (BSWAP:HI in RTL)
> These instructions are available in thumb and arm modes on armv6
> architec
On Thu, Apr 19, 2012 at 01:45, Manfred Schwarb wrote:
> Hi Janne,
>
>
>>
>> - If the program is privileged, we shouldn't trust path style
>> environment variables. The patch fixes this for TMPDIR and also for
>> the logic figuring out where addr2line is.
>
>
>
> I did not test it, but if I remembe
All,
The attached patch re-initializes _M_thread_freelist in
__freelist::~__freelist just after calling
::operator delete(static_cast(_M_thread_freelist_array));
It avoids valgrind errors in __pool::_M_get_thread_id() later invoked.
Testcases :
ext/mt_allocator/deallocate_global_thread-
Also, here is the Changelog :
2012-04-13 Laurent Alfonsi
PR libstdc++/52604
* src/mt_allocator.cc: (__freelist::~__freelist): Reset pointer.
On Wed, 18 Apr 2012, Richard Guenther wrote:
>
> This teaches loop-iv (RTL IV analysis) about loop->nb_iterations_upper_bound.
> It avoids poinless unrolling of vectorizer prologue loops for now.
>
> Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
Finished. Needs the following tests
Am 19.04.2012 09:25, schrieb Janne Blomqvist:
On Thu, Apr 19, 2012 at 01:45, Manfred Schwarb wrote:
Hi Janne,
- If the program is privileged, we shouldn't trust path style
environment variables. The patch fixes this for TMPDIR and also for
the logic figuring out where addr2line is.
I di
On 04/18/2012 11:51 AM, Richard Guenther wrote:
> On Wed, Apr 18, 2012 at 11:06 AM, Manuel López-Ibáñez
> wrote:
>> On 18 April 2012 10:29, Christian Bruel wrote:
>>>
>>> Is it OK for trunk, bootstrapped and regtested on x86
>>
>> I think Joseph Myers is on vacation, and there are no other C FE
On 19 April 2012 11:11, Christian Bruel wrote:
>
>
> On 04/18/2012 11:51 AM, Richard Guenther wrote:
>> On Wed, Apr 18, 2012 at 11:06 AM, Manuel López-Ibáñez
>> wrote:
>>> On 18 April 2012 10:29, Christian Bruel wrote:
Is it OK for trunk, bootstrapped and regtested on x86
>>>
>>> I thi
On Wed, Apr 18, 2012 at 12:45:16AM +0930, Alan Modra wrote:
> This enables out-of-line save and restore for large frames, and for
> ABI_AIX when using the static chain.
Further testing revealed two problems when compiling nested
functions.
1) The logic I had for cr_save_regno is wrong, resulting i
Found by inspection.
Seeing this strncpy use without the usual following NUL-termination,
my reflex was that it was a buffer overrun candidate, but then I
realized this is gcc, so that's not very likely.
Looking a little harder, I saw the preceding strlen >= sizeof buf test,
which means there is no
Hi,
Following Uros's mail here
http://gcc.gnu.org/ml/gcc/2012-04/msg00679.html, I've noticed that
ARM is also an affected target. Applied to trunk after testing with a
new enough gdb, will be applied to 4.7 once testing completes there.
regards,
Ramana
2012-04-19 Ramana Radhakrishnan
Fixed this typo in PSImode reads via *(X+const)
http://gcc.gnu.org/viewcvs?view=revision&revision=186588
http://gcc.gnu.org/viewcvs?view=revision&revision=186589
Committed as obvious.
Johann
PR target/53033
* config/avr/avr.c (avr_out_load_psi): Fix assembler template for
On Thu, Apr 19, 2012 at 11:52, Manfred Schwarb wrote:
> Am 19.04.2012 09:25, schrieb Janne Blomqvist:
>
>> On Thu, Apr 19, 2012 at 01:45, Manfred Schwarb wrote:
>>>
>>> Hi Janne,
>>>
>>>
- If the program is privileged, we shouldn't trust path style
environment variables. The patch
On Thu, Apr 19, 2012 at 12:42 PM, Jim Meyering wrote:
> Found by inspection.
> Seeing this strncpy use without the usual following NUL-termination,
> my reflex was that it was a buffer overrun candidate, but then I
> realized this is gcc, so that's not very likely.
> Looking a little harder, I saw
Updated patch enclosed.
On 02/14/2012 12:42 PM, Tobias Burnus wrote:
in order to gain an overview for our code whether the recent RESHAPE
(and friends) bug affects us and to determine for which assignment a
reallocation happens, useful to mitigate performance issues, I added
-Wrealloc-lhs and
On Thu, Apr 19, 2012 at 02:01:36PM +0200, Richard Guenther wrote:
> strncpy -> strcpy definitely looks like premature optimization to me.
I disagree. Almost all uses of strncpy are wrong. If the string length is
smaller, than it is unlikely useful that it clears all remaining bytes
(sometimes ma
Richard Guenther wrote:
> On Thu, Apr 19, 2012 at 12:42 PM, Jim Meyering wrote:
>> Found by inspection.
>> Seeing this strncpy use without the usual following NUL-termination,
>> my reflex was that it was a buffer overrun candidate, but then I
>> realized this is gcc, so that's not very likely.
>>
This gave me headaches debugging a VRP "miscompile" of ira-build.c.
Number of iteration analysis concluded that the allocno object
iterators do not iterate because it sees accesses to ->objects[n]
for a loop i = 0; i < n; ++i. This is because
ira_allocno_object_iter_cond was written in a very fa
On Thu, Apr 19, 2012 at 2:13 PM, Jim Meyering wrote:
> Richard Guenther wrote:
>> On Thu, Apr 19, 2012 at 12:42 PM, Jim Meyering wrote:
>>> Found by inspection.
>>> Seeing this strncpy use without the usual following NUL-termination,
>>> my reflex was that it was a buffer overrun candidate, but t
On Thu, Apr 19, 2012 at 02:31:37PM +0200, Richard Guenther wrote:
> That's better. Or even cache the strlen result and use memcpy here
> as Jakub suggested.
tree-ssa-strlen.c will do that for you when optimizing in this case ;)
Jakub
On Thu, Apr 19, 2012 at 2:34 PM, Jakub Jelinek wrote:
> On Thu, Apr 19, 2012 at 02:31:37PM +0200, Richard Guenther wrote:
>> That's better. Or even cache the strlen result and use memcpy here
>> as Jakub suggested.
>
> tree-ssa-strlen.c will do that for you when optimizing in this case ;)
Does i
On Thu, Apr 19, 2012 at 02:38:11PM +0200, Richard Guenther wrote:
> On Thu, Apr 19, 2012 at 2:34 PM, Jakub Jelinek wrote:
> > On Thu, Apr 19, 2012 at 02:31:37PM +0200, Richard Guenther wrote:
> >> That's better. Or even cache the strlen result and use memcpy here
> >> as Jakub suggested.
> >
> >
Hi,
On 04/18/2012 08:30 PM, Paolo Carlini wrote:
Thus, it seems to me that with above change it's just that we don't have
any hope of fixing latent SFINAE bugs in turney called by
build_user_type_conversion_1 per the above. And, at this time, we don't
have any evidence of such bugs.
We've just
This fixes PR53031 and reverts back to using the number of latch
iterations in VRP when computing ranges for induction variables.
Now after ira_allocno_object_iter_cond is fixed this no longer
breaks bootstrap.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-04-19
Hi,
I observed this with an alternate implementation of the stdarg stuff that
allocs new va_lists for va_start and va_copy, and frees them on va_end.
Some routines of diagnostic.c called va_end while the va_list was still
stored away in the diag objects and used in report_diagnostic.
I've aud
On 18/04/12 22:09, Xinliang David Li wrote:
Flags in category 1)
--
There are four types of information that can be dumped (should be
controlled by flag set 1) ):
1.a) transformation decisions -- such as
-fdump-tree-vectorize-transformations (to be added)
1.b) Interm
Richard Guenther wrote:
> On Thu, Apr 19, 2012 at 2:13 PM, Jim Meyering wrote:
>> Richard Guenther wrote:
>>> On Thu, Apr 19, 2012 at 12:42 PM, Jim Meyering wrote:
Found by inspection.
Seeing this strncpy use without the usual following NUL-termination,
my reflex was that it was a
Hi,
On Mon, 16 Apr 2012, Richard Guenther wrote:
> This fixes PR52977 - for PCH to work with its pointer relocation code we
> have to avoid dereferencing pointers to compute array lengths in
> structures. So we have to unfortunately keep duplicated info about
> VECTOR_CST vector lengths.
Tha
On Thu, 19 Apr 2012, Michael Matz wrote:
> Hi,
>
> On Mon, 16 Apr 2012, Richard Guenther wrote:
>
> > This fixes PR52977 - for PCH to work with its pointer relocation code we
> > have to avoid dereferencing pointers to compute array lengths in
> > structures. So we have to unfortunately keep
I noticed we vectorize
int objects[2];
void foo (int n)
{
int i;
for (i = 0; i < n; ++i)
objects[i] = i;
}
which is of course pointless (with a vectorization factor > 2).
The following patch avoids doing this.
Bootstrap & regtest pending on x86_64-unknown-linux-gnu.
Richard.
2012-04
All,
The enclosed testcases (very close to
ext/mt_allocator/deallocate_global_thread-1.cc) exposes a pattern where
the following sequence is called (when __gthread_active_p is enabled) :
__gthread_key_create(&key,::_M_destroy_thread_key);
__gthread_setspecific(key, (void*)_M_id);
Committed as obvious.
Richard.
2012-04-19 Richard Guenther
* symtab.c (dump_symtab_base): Use TREE_STRING_POINTER
for dumping DECL_SECTION_NAME.
Index: gcc/symtab.c
===
--- gcc/symtab.c(revision 186591)
On Thu, Apr 19, 2012 at 3:01 PM, Jim Meyering wrote:
> Richard Guenther wrote:
>> On Thu, Apr 19, 2012 at 2:13 PM, Jim Meyering wrote:
>>> Richard Guenther wrote:
On Thu, Apr 19, 2012 at 12:42 PM, Jim Meyering wrote:
> Found by inspection.
> Seeing this strncpy use without the usual
Richard Guenther wrote:
...
>>> The patch is ok with caching strlen and using memcpy.
>>
>> Like this, I presume:
>> [alternatively, declare and compute m_len on a separate line,
>> just before the comparison:
>> size_t m_len = strlen (m->name);
>> I'd actually prefer that, but don't know if de
Hi,
All,
The enclosed testcases (very close to
ext/mt_allocator/deallocate_global_thread-1.cc) exposes a pattern
where the following sequence is called (when __gthread_active_p is
enabled) :
__gthread_key_create(&key,::_M_destroy_thread_key);
__gthread_setspecific(key, (void*)_M
On Thu, Apr 19, 2012 at 3:17 AM, Manuel López-Ibáñez
wrote:
> On 19 April 2012 11:11, Christian Bruel wrote:
>>
>>
>> On 04/18/2012 11:51 AM, Richard Guenther wrote:
>>> On Wed, Apr 18, 2012 at 11:06 AM, Manuel López-Ibáñez
>>> wrote:
On 18 April 2012 10:29, Christian Bruel wrote:
>
>>
On Tue, Apr 17, 2012 at 9:15 AM, Steven Bosscher wrote:
>> My goal for GCC 4.8 is to do just that: Move switch expansion to
>> GIMPLE and add value profiling for switch expressions.
>
> And the idea is to put all that code in tree-switch-conversion.c. But
> there are a few clean-ups I wish to do o
Well, I don't know mt_allocator enough to know if this is a fix for real
or a quick fix.
Regards,
Laurent
On 04/19/12 16:26, Paolo Carlini wrote:
Hi,
All,
The enclosed testcases (very close to
ext/mt_allocator/deallocate_global_thread-1.cc) exposes a pattern
where the following sequence
On Thu, Apr 19, 2012 at 4:55 PM, H.J. Lu wrote:
> On Tue, Apr 17, 2012 at 9:15 AM, Steven Bosscher
> wrote:
>>> My goal for GCC 4.8 is to do just that: Move switch expansion to
>>> GIMPLE and add value profiling for switch expressions.
>>
>> And the idea is to put all that code in tree-switch-co
Hello,
If we want to use profiling to expand switches in GIMPLE, we'll have
to run switch-conversion after profiling.
Bootstrapped and tested on x86_64-unknown-linux-gnu. OK?
Ciao!
Steven
* passes.c (pass_convert_switch): Move after profiling and pure_const.
Index: passes.c
===
On Thu, Apr 19, 2012 at 14:43, Janne Blomqvist
wrote:
> Also, I suspect getuid and friends are not actually part of the NSS
> stuff. The uid/gid/euid/egid are maintained for each process by the
> kernel, and NSS only handles translation to/from the numeric id's to
> string values, IP address looku
Folks,
Thanks a lot for prompts!
I've updated my patch, so cmparing to previous it is:
- have dedicated hook var, to define target dep. bits in mem model.
Check (and warning) is performed in get_memmodel
- prefix emit performed through dedicated operand type (%K)
Updated ChangeLog entry:
2012
On Thu, Apr 19, 2012 at 08:00:15PM +0930, Alan Modra wrote:
> On Wed, Apr 18, 2012 at 12:45:16AM +0930, Alan Modra wrote:
> > This enables out-of-line save and restore for large frames, and for
> > ABI_AIX when using the static chain.
>
> Further testing revealed two problems when compiling nested
On 04/19/2012 11:21 AM, Kirill Yukhin wrote:
+++ b/gcc/builtins.c
@@ -5338,6 +5338,7 @@ static enum memmodel
get_memmodel (tree exp)
{
rtx op;
+ unsigned memmodel_mask = (1<<16) - 1;
<...>
@@ -5398,11 +5409,14 @@ expand_builtin_atomic_compare_exchange (enum
machine_mode mode, tree exp,
On 04/19/2012 05:02 PM, Laurent Alfonsi wrote:
Well, I don't know mt_allocator enough to know if this is a fix for
real or a quick fix.
I'm pretty sure we could do better. Whether in practice we are going to
do better, any time soon, it's another matter ;)
Paolo.
Hi Doug,
2012-04-18 Doug Evans
* dwarf2.h (dwarf_location_atom): Add DW_OP_GNU_addr_index.
Approved - please apply.
Cheers
Nick
On Thu, Apr 19, 2012 at 5:58 AM, Andrew Stubbs wrote:
> On 18/04/12 22:09, Xinliang David Li wrote:
>>
>> Flags in category 1)
>> --
>> There are four types of information that can be dumped (should be
>> controlled by flag set 1) ):
>> 1.a) transformation decisions -- su
On 19/04/12 17:21, Xinliang David Li wrote:
To me, the existing "(default), verbose, details" option set makes sense,
and adding "quiet" to that set seemed appropriate. I'm not sure I like the
idea of renaming existing options, even if they aren't likely to break much.
It is confusing. 'verbose
On Thu, Apr 19, 2012 at 5:21 PM, Kirill Yukhin wrote:
> Folks,
> Thanks a lot for prompts!
> I've updated my patch, so cmparing to previous it is:
> - have dedicated hook var, to define target dep. bits in mem model.
> Check (and warning) is performed in get_memmodel
> - prefix emit performed t
The following patch fixes most GCC testsuite regressions of LRA on mips64.
Committed as rev. 186598.
2012-04-19 Vladimir Makarov
* config/mips/mips.c (mips_expand_fcc_reload): Remove code for
LRA. Add an assertion.
(mips_secondary_reload): New function.
(TARGE
On 04/19/2012 08:14 AM, Richard Guenther wrote:
This gave me headaches debugging a VRP "miscompile" of ira-build.c.
Number of iteration analysis concluded that the allocno object
iterators do not iterate because it sees accesses to ->objects[n]
for a loop i = 0; i< n; ++i. This is because
ira_a
Hi!
On Wed, 18 Apr 2012 18:16:32 +0200, Bernd Schmidt
wrote:
> On 04/18/2012 06:14 PM, Richard Earnshaw wrote:
> > On 18/04/12 16:37, Thomas Schwinge wrote:
> >> gcc/testsuite/
> >>* gcc.dg/tree-ssa/20030922-1.c: Compile with
> >>-fno-strict-volatile-bitfields.
> >>* gcc.dg/tree-ssa/
Hi!
On Thu, 19 Apr 2012 19:46:17 +0200, I wrote:
> diff -ru fnsvb/20030922-1.c.003t.original fsvb/20030922-1.c.003t.original
> --- fnsvb/20030922-1.c.003t.original2012-04-19 16:51:18.322150866 +0200
> +++ fsvb/20030922-1.c.003t.original 2012-04-19 16:49:18.132088498 +0200
> @@ -7,7 +7,7 @@
On Tue, Apr 17, 2012 at 11:08 AM, Alan Modra wrote:
> This is the first in a series of patches cleaning up rs6000 prologue
> and epilogue generating code. This one is just the formatting/style
> changes plus renaming two variables to better reflect their usage,
> and moving code around.
>
> The p
On 04/19/2012 08:45 AM, Paolo Carlini wrote:
@@ -812,7 +816,7 @@ build_list_conv (tree type, tree ctor, int flags)
{
conversion *sub
= implicit_conversion (elttype, TREE_TYPE (val), val,
- false, flags);
+ false, flag
Compiling the attached test case with -O2 using the trunk compiler,
the compiler will ICE. The proposed patch is also attached. The test
is under going, but I like to have discussion on the right fix first.
thanks,
David
Analysis:
-
Here is what is happening:
BB6 : (Successor: BB8)
Hi,
> On 04/19/2012 08:45 AM, Paolo Carlini wrote:
>> @@ -812,7 +816,7 @@ build_list_conv (tree type, tree ctor, int flags)
>> {
>>conversion *sub
>> = implicit_conversion (elttype, TREE_TYPE (val), val,
>> - false, flags);
>> + false, flags, t
On 04/19/2012 03:00 PM, Paolo Carlini wrote:
Yes, that's life ;) Seriously, if we want to avoid all those having to do with
implicit_conversion in one swoop, the eventual patch will be pretty big, should
I just go on and on?
I think so. Once we start down this road, we should follow it to th
Richard Guenther wrote:
> Sure, my point was that the
>
> if (strlen (m->name) >= sizeof buf)
> {
> error ("%s:%d:mode name \"%s\" is too long",
> m->file, m->line, m->name);
> continue;
> }
>
> check does not account for the (conditional)
Hello everyone,
I wasn't sure if I needed approval for this patch or not, but better
be safe than sorry. I'll apply to both GCC and then src when I receive
confirmation that it's OK to apply.
I would like to update the config.sub script to the latest version
from the official config repo. The bi
Hi Maxim, Richard,
I built cross-toolchains for 3 different targets as follows.
1. mips-linux-gnu
2. mips-linux-gnu --enable-targets=all
3. mips64-linux-gnu
These targets are affected by this MIPS Android patch.
Then, I checked the output from "gcc -dumpspecs" before and after applying
th
This enhances constant folding for division by complex and vector
constants. When -freciprocal-math is present, such divisions are
converted into multiplies by the constant reciprocal. When an exact
reciprocal is available, this is done for vector constants when
optimizing. I did not implement l
The change to the libgo testsuite script to look at data symbols for
function descriptors on PowerPC caused the script to pick up interface
method tables and the like for types named Test*. This patch adds a
grep -v to trim those out again. Bootstrapped and ran Go testsuite on
x86_64-unknown-linu
This patch to libgo ignores space allocated for goroutine stacks when
deciding when to next run the garbage collector. On systems that
support split stacks this does nothing, as on those systems the stacks
are allocated by the split stack code. On systems that do not support
split stacks this doe
Hi,
Previously I reported pr52804 in bugzilla about reload pass reloads wrong
register.
After investigation I believe it is a bug in reload pass and here comes the
patch.
You can refer to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52804 for
details.
In short, I think the confliction of reloads wi
> -Original Message-
> From: Thomas Schwinge [mailto:tho...@codesourcery.com]
> Sent: Friday, April 20, 2012 01:46
> To: Bernd Schmidt; Richard Earnshaw
> Cc: Richard Guenther; Joey Ye; d...@redhat.com; GCC Patches; Mitchell,
> Mark
> Subject: Re: Continue strict-volatile-bitfields fixes
66 matches
Mail list logo
