Sorry about the garbled message. My mistake with the mailer. Here
is what I really intended to send.
This patch was earlier submitted to google/main, but I propose itfor
trunk as well.
This patch adds an intermediate coverage format (enabled via
'gcov-i'). This is a compact format as it does
This fixes many C++ tests on s390x and PPC64:
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01220.html
This patch was earlier submitted to google/main, but I propose itfor
the trunk as well.
This patch adds an intermediate coverage format (enabled via
'gcov-i'). This is a compact format as it does not require source
files.
The new option ('gcov -i') outputs .gcov files in an intermediate
textformat
Hello!
2011-10-05 Uros Bizjak
* gcc.dg/torture/builtin-complex-1.c: Use dg-add-options ieee.
Tested on alphaev68-pc-linux-gnu, committed to mainline.
Uros.
Index: gcc.dg/torture/builtin-complex-1.c
===
--- gcc.dg/tortur
There are only a few VIS 3.0 instructions left after this, such as
"lzd" (leading zero detect) and add-with-carry instructions that make
use of the 64-bit condition codes.
Committed to trunk.
gcc/
* config/sparc/sparc.md (UNSPEC_FHADD, UNSPEC_FHSUB,
UNSPEC_XMUL): New unspecs.
Jan Hubicka writes:
> Hi,
> GNU LD has bug about reporting references to hidden symbol sthat has been
> optimized out.
> This however made me notice that we do output into LTO symbol tables things
> that do
> not belong there. In partiuclar we often output extern inline functions that
> has be
On 4 October 2011 23:41, Paolo Carlini wrote:
> .. another nit: normally basic_string testcases are added in pairs, for char
> and wchar_t, in the appropriate subdirs... I see range_access.cc should be
> adjusted...
Good points, I'll deal with that and the exports before checking in, thanks.
As per PR 50562, when --without-newlib is passed to configure,
target-newlib is added to skipdirs.
But target-newlib is not added to noconfigdirs, so this check:
# If we aren't building newlib, then don't build libgloss, since
libgloss
# depends upon some newlib header files.
case "${noconfigdi
The Go frontend had a bug when initializing a global variable to a
function call when some of the arguments to the call were themselves
function calls. The code which enforces function call ordering was
accidentally causing the outermost function to be called twice. This
patch fixes the bug. Boo
On Tue, Oct 4, 2011 at 11:51 PM, Joseph S. Myers
wrote:
> On Tue, 4 Oct 2011, Artem Shinkarov wrote:
>
>> Hi
>>
>> Here is the patch tho fix bconstp-3.c failure in the bug 50607. The
>> failure was cause because the new parser routine did not consider
>> original_tree_code of the expression.
>>
>>
On 10/04/2011 11:31 PM, Tom de Vries wrote:
> On 10/04/2011 10:58 PM, Richard Henderson wrote:
>> On 10/04/2011 01:17 PM, Tom de Vries wrote:
>>> In general, to fold vlas (which are lowered to allocas) to normal
>>> declarations,
>>> if the alloca argument is constant.
>>
>> Ah. Ok, I suppose. H
> +(define_constraint "M"
> + "A unsigned and customized 4-bit immediate."
> + (and (match_code "const_int")
> + (match_test "(IN_RANGE_P (ival, 0, 15) && ((ival != 9) || (ival !=
> 11))) ")))
Logic error: x != 9 || x != 11 => true.
> +/* TARGETM Function Prototypes and forward declara
On Tue, 4 Oct 2011, Artem Shinkarov wrote:
> Hi
>
> Here is the patch tho fix bconstp-3.c failure in the bug 50607. The
> failure was cause because the new parser routine did not consider
> original_tree_code of the expression.
>
> The patch is bootstrapped on x86-unknown-linux-gnu and is being
.. another nit: normally basic_string testcases are added in pairs, for
char and wchar_t, in the appropriate subdirs... I see range_access.cc
should be adjusted...
Paolo.
On 10/04/2011 03:10 PM, Bernd Schmidt wrote:
> * doc/invoke.texi (-fshrink-wrap): Document.
> * opts.c (default_options_table): Add it.
> * common.opt (fshrink-wrap): Add.
> * function.c (emit_return_into_block): Remove useless declaration.
> (record_hard_reg_uses_1, r
Hi,
this simply implements the O(1) size for the C++0x std::list. Tested
x86_64-linux multilib, etc, committed to mainline.
Thanks,
Paolo.
//
2011-10-04 Paolo Carlini
PR libstdc++/49561
* include/bits/stl_list.h (_List_base<>::_List_impl::_M_size):
Hi
Here is a patch to inform a programmer about the expanded vector operation.
Bootstrapped on x86-unknown-linux-gnu.
ChangeLog:
* gcc/tree-vect-generic.c (expand_vector_piecewise): Adjust to
produce the warning.
(expand_vector_parallel): Adjust to produce the warning
On 09/30/11 18:51, Richard Henderson wrote:
> Please do leave out RETURN_ADDR_REGNUM for now. If you remember why,
> then you could bring it back alongside the patch for the ARM backend.
Changed.
> As for the i386 backend changes, not an objection per se, but I'm
> trying to understand why we n
On 10/04/2011 11:35 PM, Jonathan Wakely wrote:
Tested x86_64-linux, any objections to committing?
No objections, but I think the basic_string exports have to be adjusted,
to export the new member functions at the current minor version.
Paolo.
On Oct 4, 2011, at 2:37 PM, Quentin Neill wrote:
> Ping?
The problem with this patch is it reorders the listing so that lower priority
things are after higher priority things. The entire point of the routine is to
list the high priority things first, so that a casual user can read the first
li
Now that G++ supports non-static data member initializers, I want to
use it for initializing the __gthread_mutex_t members of std::mutex
and friends:
__native_type _M_mutex = __GTHREAD_MUTEX_INIT;
This is more portable than our current code, which does:
constexpr mutex() noexcept : _M_mutex(__
Hi
Here is the patch tho fix bconstp-3.c failure in the bug 50607. The
failure was cause because the new parser routine did not consider
original_tree_code of the expression.
The patch is bootstrapped on x86-unknown-linux-gnu and is being tested.
Thanks,
Artem.
Index: c-parser.c
===
On Tuesday 04 October 2011 19:01:50 Janus Weil wrote:
> If you have a cute idea how to elegantly introduce warnings into this
> mechanism, I'm all ears.
I'm not sure that it qualifies as cute, but we could produce multi-line
diagnostics in the same way c++ does (for template candidates for example
Ping?
On Wed, Sep 7, 2011 at 12:21 PM, Quentin Neill
wrote:
> Hi,
>
> Should not change behavior for comparing two files (expect for usage
> output), and also should be POSIX compliant.
>
> Tested on x86_64 tests logs and test directories, would be interested
> in help testing on other platforms.
This adds the new C++11 pop_back() member to ,
and , as added by LWG 534.
* include/bits/basic_string.h (basic_string::pop_back): Define.
* include/ext/vstring.h (versa_string::pop_back): Define.
* include/debug/string (basic_string::pop_back): Define.
* testsuite/
On 10/04/2011 10:58 PM, Richard Henderson wrote:
> On 10/04/2011 01:17 PM, Tom de Vries wrote:
>> In general, to fold vlas (which are lowered to allocas) to normal
>> declarations,
>> if the alloca argument is constant.
>
> Ah. Ok, I suppose. How often are you seeing this happening? I can imag
Jason Merrill writes:
> I was thinking that you could walk the macro expansions to see if the
> two locations have an expansion in common, and if so compare the
> indices. I guess you could do this only if the locations have the same
> expansion location but are not themselves equal.
OK. I thou
> 2011/10/2 Jan Hubicka :
> >> > Index: tree-sra.c
> >> > ===
> >> > *** tree-sra.c (revision 179423)
> >> > --- tree-sra.c (working copy)
> >> > *** modify_function (struct cgraph_node *nod
> >> > *** 4622,4627
> >>
> On Tue, 4 Oct 2011, Andi Kleen wrote:
>
> > > Well, I'm not sure we should jump through too much hoops to make
> > > -flto work with -fno-toplevel-reorder. Simply because I think nothing
> > > defines any "toplevel order" for multiple object files. So, I think
> >
> > In practice it seems to
Most three-argument tests failed due, in part, to the two_arguments variable
being uninitialized.
Committed.
r~
* c-typeck.c (c_build_vec_shuffle_expr): Fix uninitialized variable.
Avoid save_expr unless two_arguments.
diff --git a/gcc/c-typeck.c b/gcc/c-typeck.c
index 96ef4a3
I was thinking that you could walk the macro expansions to see if the two
locations have an expansion in common, and if so compare the indices. I guess
you could do this only if the locations have the same expansion location but
are not themselves equal.
If comparing the expansion locations is
On 10/04/2011 01:17 PM, Tom de Vries wrote:
> In general, to fold vlas (which are lowered to allocas) to normal
> declarations,
> if the alloca argument is constant.
Ah. Ok, I suppose. How often are you seeing this happening? I can imagine
a few instances via inlining, but even there not so mu
2011-10-04 Jonathan Wakely
* include/ext/alloc_traits.h (__alloc_traits::max_size): Define.
(__alloc_traits::rebind): Define.
* include/bits/stl_vector.h: Use them.
* testsuite/util/testsuite_allocator.h (SimpleAllocator): Define.
* testsuite/23_container
Jason Merrill writes:
> On 10/03/2011 06:49 PM, Dodji Seketeli wrote:
>> Good question. Is the below better?
>
>> + if (linemap_location_from_macro_expansion_p (set, pre))
>> +pre = linemap_resolve_location (set, pre,
>> + LRK_MACRO_EXPANSION_POINT, NULL);
Jason Merrill writes:
> So then this change would make
>
> _Complex c;
>
> OK, but not
>
> static _Complex c;
>
> because the first declspec is not from a macro, right?
Yes.
>
>> I believe you noted this at some point and
>> agreed with me that ideally each declspec should come with its locatio
On 10/04/2011 08:51 PM, Richard Henderson wrote:
> On 10/04/2011 09:28 AM, Tom de Vries wrote:
>> Well, that was the idea. But now I wonder, isn't it better to do this in
>> expand_builtin_alloca:
>> ...
>>/* Compute the argument. */
>>op0 = expand_normal (CALL_EXPR_ARG (exp, 0));
>>
>> +
Richard Sandiford writes:
> Bernd Schmidt writes:
>> On 09/25/11 19:16, Richard Sandiford wrote:
>>> The last bit is indirect, via a new HARD_REG_SET called operand_reg_set.
>>> And this set is the reason why I'm sending the patch now. The MIPS16 port
>>> has always had a problem with the HI and
On 10/03/2011 04:08 PM, Dodji Seketeli wrote:
Jason Merrill writes:
-finish_declspecs (struct c_declspecs *specs)
+finish_declspecs (struct c_declspecs *specs,
+ location_t where)
I'm not sure the beginning of the declspecs is a better place for
these diagnostics than the begi
On 10/03/2011 06:49 PM, Dodji Seketeli wrote:
Good question. Is the below better?
+ if (linemap_location_from_macro_expansion_p (set, pre))
+pre = linemap_resolve_location (set, pre,
+ LRK_MACRO_EXPANSION_POINT, NULL);
+
+ if (linemap_location_from_macr
On 10/04/2011 08:42 AM, Joseph S. Myers wrote:
> On Tue, 4 Oct 2011, Ilya Tocar wrote:
>
>> Hi everyone,
>>
>> This patch fixes PR 50038 (redundant zero extensions) by modifying
>> implicit-zee pass
>> to also remove unneeded zero extensions from QImode to SImode.
>
> Hardcoding particular modes
I want to commit the attached patch to install.texi, but have been
unable to test it successfully.
The problem is that the link for "x86_64-*-solaris2.1[0-9]*" in the
Host/Target Specific notes is
http://gcc.gnu.org/install/specific.html#x86-64-x-solaris210
but the corresponding anchor is:
Note
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/04/11 05:00, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs on the trunk, as strlen optimization
> was assuming memcpy arguments will have expected type
> (size_type_node), but they had ssizetype instead. The following
> patch fixes
I've committed this, which documents the fix for
http://gcc.gnu.org/PR1773 in gcc-4.7/changes.html, and also replaces
some > characters with the > entity.
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
On 5/10/2011, at 1:49 AM, Richard Guenther wrote:
> On Tue, Oct 4, 2011 at 9:17 AM, Maxim Kuvyrkov wrote:
>> Richard,
>>
>> The following patch fixes a CFG consistency problem.
>>
>> When early IPA optimizations (e.g., early SRA) create a version of a
>> function that no longer throws, version
On 10/04/2011 11:51 AM, Andrew MacLeod wrote:
> * optabs.c (expand_sync_mem_load): Don't expand into a default load if
> the type is larger than a word. Try a compare_and_swap with 0.
> (expand_sync_mem_store): Return const0_rtx if a store is generated. If
> type is larger t
THe framework for invoking gdb and simulating other threads can run into
a problem when memmodel_other_thread() is written in a hostile manner.
memodel_other_thread ()
{
mem++; /* increment mem every instruction. */
}
and it is tested against something like a compare_and_swap loop
imple
On Oct 4, 2011, at 6:03 AM, Andi Kleen wrote:
> Also as Honza pointed out it has other benefits, like making
> compiles more reproducible. For example if you have a memory corruption
> somewhere the random order currently will randomly move it from
> run to run and make it harder to debug.
I like
On Tue, Oct 4, 2011 at 11:51 AM, Uros Bizjak wrote:
> On Tue, Oct 4, 2011 at 8:37 PM, H.J. Lu wrote:
>
> OTOH, x86_64 and i686 targets can also benefit from this change. If
> combine can't create more complex address (covered by lea), then it
> will simply propagate memory operand bac
>>> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>>>
>> The patch is basically OK.
> Otherwise I'll just start by committing the
> patch as posted ...
Just did so (r179520).
Cheers,
Janus
On 10/04/2011 09:28 AM, Tom de Vries wrote:
> Well, that was the idea. But now I wonder, isn't it better to do this in
> expand_builtin_alloca:
> ...
>/* Compute the argument. */
>op0 = expand_normal (CALL_EXPR_ARG (exp, 0));
>
> + align =
> +(DECL_FUNCTION_CODE (get_callee_fndecl (e
I think I had a similar patch earlier that got forgotten, but I've made
some changes.
if (sizeof(atomic) > target_word_size) then defaulting to a load or
store with barriers will result in non-atomic code, which is bad.
instead, the default has now been changed.
Store will try an exchange,
On Tue, Oct 4, 2011 at 8:37 PM, H.J. Lu wrote:
OTOH, x86_64 and i686 targets can also benefit from this change. If
combine can't create more complex address (covered by lea), then it
will simply propagate memory operand back into the add insn. It looks
to me that we can't loos
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/04/11 08:43, Aldy Hernandez wrote:
> http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01272.html
So others have already mentioned the name "memmodel" as being
unsatisfactory... From the list, I liked simulate-thread (before
looking at your message w
On Tue, Oct 04, 2011 at 02:28:13PM -0400, Jason Merrill wrote:
> This won't affect vectors that are passed by non-restrict reference,
> correct? We don't want to break code that, say, takes the address
It will ATM also affect global std::vector variables, and std::vector
variables passed by invis
On Tue, Oct 4, 2011 at 10:32 AM, Uros Bizjak wrote:
> On Tue, Oct 4, 2011 at 6:06 PM, H.J. Lu wrote:
>
>>> OTOH, x86_64 and i686 targets can also benefit from this change. If
>>> combine can't create more complex address (covered by lea), then it
>>> will simply propagate memory operand back into
This won't affect vectors that are passed by non-restrict reference,
correct? We don't want to break code that, say, takes the address of an
element and then uses it later unless we've made that invalid by marking
the vector as restrict.
Jason
On 10/3/2011 8:35 AM, Gabriel Dos Reis wrote:
"unnamed variadic functions" sounds as if the function itself is
unnamed, so not good.
-funnamed-variadic-parameter
How about
-fvariadic-parameters-unnamed
there's already a -fvariadic-macros, so maybe putting variadic first is
more consistent?
From: Gerald Pfeifer
Date: Tue, 4 Oct 2011 11:25:11 +0200 (CEST)
> On Sun, 2 Oct 2011, David Miller wrote:
>> We always use "Sparc" instead of "SPARC" for the cpu names output
>> by the kernel in /proc/cpuinfo.
>
> Ah, I see. Thanks for the explanation.
>
> What confused me a bit is that a bit
On Tue, Oct 4, 2011 at 6:06 PM, H.J. Lu wrote:
>> OTOH, x86_64 and i686 targets can also benefit from this change. If
>> combine can't create more complex address (covered by lea), then it
>> will simply propagate memory operand back into the add insn. It looks
>> to me that we can't loose here,
Hi Mikael,
>> here is a patch for a rather long-standing PR. It continues my ongoing
>> campaign of improving the checks for "procedure characteristics" (cf.
>> F08 chapter 12.3), which are relevant for dummy procedures, procedure
>> pointer assignments, overriding of type-bound procedures, etc.
>
Two patches, both in trunk for some time, which fix crashes on ARM.
Andrew.
2011-10-04 Andrew Haley
* src/arm/ffi.c (FFI_INIT_TRAMPOLINE): Clear icache.
Index: libffi/src/arm/ffi.c
===
--- libffi/src/arm/ffi.c(r
2011/10/3 Ozkan Sezer :
> On Mon, Oct 3, 2011 at 5:56 PM, Kai Tietz wrote:
>> 2011/10/3 Ozkan Sezer :
>>> PING?
>>>
>>> On Thu, Sep 22, 2011 at 2:28 PM, Ozkan Sezer wrote:
Hi:
Unless I'm missing something, the mingw CPP_SPEC changes introduced in
r171833 have a typo: -D_REENTR
On 10/04/2011 08:18 AM, Artem Shinkarov wrote:
> Ping.
>
> Richard, the patch in the attachment should be submitted asap. The
> other problem could wait for a while.
The patch in the attachment is wrong too. I've re-written the x86
backend support, adding TARGET_XOP in the process. I've also re
On 10/04/2011 03:03 PM, Richard Guenther wrote:
> On Tue, Oct 4, 2011 at 9:43 AM, Tom de Vries wrote:
>> On 10/01/2011 05:46 PM, Tom de Vries wrote:
>>> On 09/30/2011 03:29 PM, Richard Guenther wrote:
On Thu, Sep 29, 2011 at 3:15 PM, Tom de Vries
wrote:
> On 09/28/2011 11:53 AM, Ri
On Tue, Oct 4, 2011 at 1:19 AM, Uros Bizjak wrote:
> On Tue, Oct 4, 2011 at 10:06 AM, Uros Bizjak wrote:
This patch improves address combine for x32 by forcing the memory memory
operand of PLUS operation into register. Tested on Linux/x86-64 with
-mx32. OK for trunk?
>>>
>>> Does
On Tue, 4 Oct 2011, Jayant R. Sonar wrote:
> PING 4: For review
> Hi,
> Can someone please review the patch:
> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01441.html
Could someone with general back-end expertise look at this? I don't have
the expertise to review whether the back end follow
On Tue, 4 Oct 2011, Ilya Tocar wrote:
> Hi everyone,
>
> This patch fixes PR 50038 (redundant zero extensions) by modifying
> implicit-zee pass
> to also remove unneeded zero extensions from QImode to SImode.
Hardcoding particular modes like this in the target-independent parts of
the compiler
On Mon, 3 Oct 2011, Michael Meissner wrote:
> On Sat, Oct 01, 2011 at 02:11:27PM +, Joseph S. Myers wrote:
> > On Fri, 30 Sep 2011, Michael Meissner wrote:
> >
> > > Is this enough of a savings to continue on? I'm of two minds about it,
> > > one is
> >
> > The thing to measure is not so m
This fixes PR50609, we need to do something sensible for VECTOR_TYPE
constructors, which is not dispatch to fold_nonarray_ctor_reference.
Instead fold_array_ctor_reference can be conveniently re-used.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2011-10-04 Richard Guenth
Ramana Radhakrishnan wrote:
> On 26 September 2011 15:24, Ulrich Weigand wrote:
> > Is this sufficient, or should I test any other set of options as well?
>
> Could you run one set of tests with neon ?
Sorry for the delay, but I had to switch to my IGEP board for Neon
support, and that's a bit s
Ping.
Richard, the patch in the attachment should be submitted asap. The
other problem could wait for a while.
Thanks,
Artem.
On Tue, Oct 4, 2011 at 12:04 AM, Artem Shinkarov
wrote:
> On Mon, Oct 3, 2011 at 6:12 PM, Richard Henderson wrote:
>> On 10/03/2011 09:43 AM, Artem Shinkarov wrote:
>>>
On Wed, Sep 28, 2011 at 17:28, Gabriel Charette wrote:
> Very nice!
>
> I really like where this is heading :)!
>
> I think it would be great to instrument this to know how many times we
> need to use a PPH_RECORD_MREF, to avoid trashing the cache (i.e.
> potentially there are specific cases where
This implements the clean up Gab suggested in
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01882.html
Tested on x86_64. Committed.
Diego.
* pph-streamer.h (pph_cache_find): New.
Replace pph_cache_select/pph_cache_get combinations with it.
diff --git a/gcc/cp/pph-streamer-in.c
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01272.html
On Tue, Oct 4, 2011 at 2:28 AM, Gerald Pfeifer wrote:
> On Mon, 3 Oct 2011, H.J. Lu wrote:
>> I checked it in.
>
> Thanks, H.J.
>
> This needed a small markup fix which I just applied; see below.
>
Thanks.
--
H.J.
On Tue, Oct 4, 2011 at 1:19 AM, Uros Bizjak wrote:
> On Tue, Oct 4, 2011 at 10:06 AM, Uros Bizjak wrote:
This patch improves address combine for x32 by forcing the memory memory
operand of PLUS operation into register. Tested on Linux/x86-64 with
-mx32. OK for trunk?
>>>
>>> Does
Hi,
I checked in this patch to fix a typo.
--
H.J.
---
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.44
diff -u -p -r1.44 changes.html
--- changes.html4 Oct 2011 09:27
From: Gerald Pfeifer
Date: Tue, 4 Oct 2011 11:25:11 +0200 (CEST)
> On Sun, 2 Oct 2011, David Miller wrote:
>> We always use "Sparc" instead of "SPARC" for the cpu names output
>> by the kernel in /proc/cpuinfo.
>
> Ah, I see. Thanks for the explanation.
>
> What confused me a bit is that a bit
From: Eric Botcazou
Date: Tue, 4 Oct 2011 09:37:01 +0200
> Tested on SPARC/Solaris, applied on the mainline.
>
>
> 2011-10-04 Eric Botcazou
>
> * config/sparc/sparc.c (sparc_fold_builtin): Use a sequence of tests.
Thanks for fixing this Eric.
On Tue, Oct 04, 2011 at 02:44:00PM +0200, Richard Guenther wrote:
> On Tue, Oct 4, 2011 at 2:07 AM, Michael Meissner
> wrote:
> > On Sat, Oct 01, 2011 at 02:11:27PM +, Joseph S. Myers wrote:
> >> On Fri, 30 Sep 2011, Michael Meissner wrote:
> >>
> >> > Is this enough of a savings to continue o
On Tue, Oct 4, 2011 at 3:28 PM, Jakub Jelinek wrote:
> On Tue, Oct 04, 2011 at 01:55:27PM +0200, Michael Matz wrote:
>> Ugh, that's stretching our fragile to unsafe restrict support quite much.
>> IMO beyond what we can reasonably be confident to not cause
>> miscompilations. Essentially what you
Hi,
On Tue, 4 Oct 2011, Jakub Jelinek wrote:
> If it causes miscompilations, then GCC is buggy and needs to be fixed.
That's not easy without effectively making the whole restrict support
ineffective.
> > Keep in mind that the whole current restrict-tag support was designed to
> > support for
On Tue, 4 Oct 2011, Andi Kleen wrote:
> On Tue, Oct 04, 2011 at 03:08:02PM +0200, Richard Guenther wrote
>
> > Sure, the question is if "-flto" counts as magic and thus
> > "don't do it when it hurts" ;)) I suppose with -flto-partition=none
> > (or 1to1) it would be reasonable to make -fno-tople
On Tue, 4 Oct 2011, Richard Guenther wrote:
> On Tue, 4 Oct 2011, Jakub Jelinek wrote:
>
> > On Tue, Oct 04, 2011 at 12:17:30PM +0200, Richard Guenther wrote:
> > > int *x;
> > >
> > > > void foo (int *p)
> > > > {
> > > > int * __restrict p1 = p;
> > > > int * __restrict p2 = p + 32;
> >
On Tue, Oct 04, 2011 at 01:55:27PM +0200, Michael Matz wrote:
> Ugh, that's stretching our fragile to unsafe restrict support quite much.
> IMO beyond what we can reasonably be confident to not cause
> miscompilations. Essentially what you're implicitely assuming is that the
> sources of restr
On Tue, Oct 4, 2011 at 1:55 PM, Michael Matz wrote:
> Hi,
>
> On Mon, 3 Oct 2011, Jakub Jelinek wrote:
>
>> std::vector acts roughly as something having a restrict pointer field,
>> i.e. two different std::vector objects will have the pointers pointing to
>> a different array, unfortunately unlike
On Tue, Oct 4, 2011 at 1:00 PM, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs on the trunk, as strlen optimization was
> assuming memcpy arguments will have expected type (size_type_node),
> but they had ssizetype instead. The following patch fixes it
> both in the builtins.c folders
On Tue, Oct 04, 2011 at 03:08:02PM +0200, Richard Guenther wrote
> Sure, the question is if "-flto" counts as magic and thus
> "don't do it when it hurts" ;)) I suppose with -flto-partition=none
> (or 1to1) it would be reasonable to make -fno-toplevel-reorder work
> (and thus maybe -fno-toplevel-
On Tue, 4 Oct 2011, Andi Kleen wrote:
> > Well, I'm not sure we should jump through too much hoops to make
> > -flto work with -fno-toplevel-reorder. Simply because I think nothing
> > defines any "toplevel order" for multiple object files. So, I think
>
> In practice it seems to work because r
On Tue, 4 Oct 2011, Jakub Jelinek wrote:
> On Tue, Oct 04, 2011 at 12:17:30PM +0200, Richard Guenther wrote:
> > int *x;
> >
> > > void foo (int *p)
> > > {
> > > int * __restrict p1 = p;
> > > int * __restrict p2 = p + 32;
> > > int *q;
> > > int i;
> > x = p2;
> > > q = p + 32;
On Tue, Oct 4, 2011 at 9:43 AM, Tom de Vries wrote:
> On 10/01/2011 05:46 PM, Tom de Vries wrote:
>> On 09/30/2011 03:29 PM, Richard Guenther wrote:
>>> On Thu, Sep 29, 2011 at 3:15 PM, Tom de Vries
>>> wrote:
On 09/28/2011 11:53 AM, Richard Guenther wrote:
> On Wed, Sep 28, 2011 at 11:
> Well, I'm not sure we should jump through too much hoops to make
> -flto work with -fno-toplevel-reorder. Simply because I think nothing
> defines any "toplevel order" for multiple object files. So, I think
In practice it seems to work because real programs rely on it.
I can just say with thi
On Tue, Oct 04, 2011 at 12:17:30PM +0200, Richard Guenther wrote:
> int *x;
>
> > void foo (int *p)
> > {
> > int * __restrict p1 = p;
> > int * __restrict p2 = p + 32;
> > int *q;
> > int i;
> x = p2;
> > q = p + 32;
> q = q - 31;
> > for (i = 0; i < 32; ++i)
> > p[i] =
On Tue, Oct 4, 2011 at 9:17 AM, Maxim Kuvyrkov wrote:
> Richard,
>
> The following patch fixes a CFG consistency problem.
>
> When early IPA optimizations (e.g., early SRA) create a version of a function
> that no longer throws, versioning machinery deletes EH landings pads in
> _callers_ of the
On Tue, Oct 4, 2011 at 2:07 AM, Michael Meissner
wrote:
> On Sat, Oct 01, 2011 at 02:11:27PM +, Joseph S. Myers wrote:
>> On Fri, 30 Sep 2011, Michael Meissner wrote:
>>
>> > Is this enough of a savings to continue on? I'm of two minds about it,
>> > one is
>>
>> The thing to measure is not
Hello,
This patch (two of two) adds to tree-ssa-reassociation code for
repropagation of unpacked
bitwise-binary operations - like (X == 0) & (Y == 0), etc.
Also it denormalizes bitwise-not operations on bitwise-binary tree
chains - eg ~X & ~Y -> ~(X | Y).
ChangeLog
2011-10-04 Kai Tietz
Hello,
This patch (one of two) adds to tree-ssa-reassociation code for
expansion of packed
bitwise-binary operations - like (X | Y) == 0, etc.
Also it normalizes bitwise-not operations on bitwise-binary tree
chains - like ~(X | Y) -> ~X & ~Y.
ChangeLog
2011-10-04 Kai Tietz
* tree-ssa
Bernd Schmidt writes:
> On 09/25/11 19:16, Richard Sandiford wrote:
>> The last bit is indirect, via a new HARD_REG_SET called operand_reg_set.
>> And this set is the reason why I'm sending the patch now. The MIPS16 port
>> has always had a problem with the HI and LO registers: they can only be
>
Hi,
On Mon, 3 Oct 2011, Jakub Jelinek wrote:
> std::vector acts roughly as something having a restrict pointer field,
> i.e. two different std::vector objects will have the pointers pointing to
> a different array, unfortunately unlike e.g. std::valarray we have 3
> different pointers pointing in
On Monday 03 October 2011 23:02:15 Janus Weil wrote:
> Hi all,
>
> here is a patch for a rather long-standing PR. It continues my ongoing
> campaign of improving the checks for "procedure characteristics" (cf.
> F08 chapter 12.3), which are relevant for dummy procedures, procedure
> pointer assign
1 - 100 of 133 matches
Mail list logo
