> On Sat, Nov 2, 2013 at 6:48 PM, Steven Bosscher wrote:
> > The failure of pr53199.c is because of different instruction selection
> > for bswap. Test case is reduced to just one function:
[snip]
> > Is this an improvement or a regression? If it's an improvement then
> > these two test cases shou
Hello Everyone,
The changes mentioned in
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03506.html is also applicable to
my C++ patch. With this email, I am attaching a fixed patch.
Here are the ChangeLog entries:
gcc/cp/ChangeLog
2013-11-30 Balaji V. Iyer
* decl2.c (is_late_t
Hello Aldy,
Some of the middle end changes I made in the previous patch was not
flying for the C++. Here is a fixed patch where the middle-end changes will
work for both C and C++.
With this email, I am attaching the patch for C along with the middle
end changes. Is this Ok for t
Hi Jakub,
Well, it turns out that I need to do a couple more changes than that
one change in omp-low.c So, please ignore that. I will check in the changes in
i386.c as obvious since all it involves is removing a '\n.' in the error string.
Thanks,
Balaji V. Iyer.
> -Original Message
Dear All,
This is a partial fix for this problem in that it generates a
temporary to provide a correct assignment but then goes on to do an
unnecessary reallocation of the lhs. That is to say, the temporary
could be taken over by the array descriptor. At the moment, I could
not see a good way to
Dear All,
This one is trivial. NULL(...) is simply out of context in a transfer
statement.
Bootstrapped and regtested on FC17/x86_64. OK for trunk and 4.8?
Cheers
Paul
2013-11-30 Paul Thomas
PR fortran/34547
* resolve.c (resolve_transfer): EXPR_NULL is always in an
invalid co
Dear All,
This turned out to be a valid uninitialized variable warning.
However, it was unlikely ever to cause problems at run-time.
Nonetheless, here is the fix. I am disinclined to load the testsuite
with a fix that is so specific and localized that it simply will not
break. However, if review
Hello Jakub,
I was looking at my elemental function for C patch that I fixed up and
send as requested by Aldy, and I saw two changes there that were used for C and
C++ and they were pretty obvious. Here are the changes. Can I just commit them?
Thanks,
Balaji V. Iyer.
Index: gcc/config/
On Sat, Nov 30, 2013 at 9:54 AM, Andreas Schwab wrote:
> Ian Lance Taylor writes:
>
>> diff -r fa6c22b293e8 libgo/go/reflect/makefunc_386.S
>> --- a/libgo/go/reflect/makefunc_386.S Tue Nov 26 16:49:31 2013 -0800
>> +++ b/libgo/go/reflect/makefunc_386.S Sat Nov 30 09:05:42 2013 -0800
>> @@ -26,8 +
I backported the libbacktrace fix in
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01445.html to the GCC 4.8
branch. Bootstrapped and ran libbacktrace testsuite on
x86_64-unknown-linux-gnu. Committed to 4.8 branch.
Ian
2013-11-30 Ian Lance Taylor
Backport from mainline:
2013
Ian Lance Taylor writes:
> diff -r fa6c22b293e8 libgo/go/reflect/makefunc_386.S
> --- a/libgo/go/reflect/makefunc_386.S Tue Nov 26 16:49:31 2013 -0800
> +++ b/libgo/go/reflect/makefunc_386.S Sat Nov 30 09:05:42 2013 -0800
> @@ -26,8 +26,11 @@
>esp uint32 // 0x0
>ea
Hi,
this test started to fail very recently on 32-bit platforms with 64-bit HWI.
Not sure exactly why, but the issue is straightforward and was latent.
For the following reference, a call to ao_ref_init_from_ptr_and_size yields:
(gdb) p debug_generic_expr((tree_node *) 0x76e01200)
&a[0 ...]{
On 386 when a function returns a struct the pointer to the return value
is passed as a hidden first parameter, and the function is supposed to
"ret 4" to pop the hidden parameter when returning to the caller. The
implementation of reflect.MakeFunc in libgo was not doing that. This
patch fixes the
On 11/26/13 17:43, Jan-Benedict Glaw wrote:
On Sun, 2013-11-24 20:02:43 +0100, Jan-Benedict Glaw wrote:
2013-11-24 Jan-Benedict Glaw
* config-list.mk (host_options): Allow to override it.
(LIST): Change "=" to "EQUAL".
(list): New target listing all configurations.
On Thu, 28 Nov 2013, Jan Hubicka wrote:
> We previously renamed every static function foo into foo.1234 (just as a
> precaution because other compilation unit may have also function foo).
> This confuses many thins, so now we do renaming only when we see a
> conflict.
Ah, I see. Thanks.
>
Yury Gribov writes:
> diff --git a/gcc/testsuite/lib/asan-dg.exp b/gcc/testsuite/lib/asan-dg.exp
> index e0bf2da..06122e2 100644
> --- a/gcc/testsuite/lib/asan-dg.exp
> +++ b/gcc/testsuite/lib/asan-dg.exp
> @@ -39,9 +39,9 @@ proc asan_link_flags { paths } {
> set shlib_ext [get_shlib_extensi
Richard Sandiford wrote:
>Richard Biener writes:
>> On Fri, Nov 29, 2013 at 12:14 PM, Richard Sandiford
>> wrote:
>>> In the fold-const.ii testcase, well over half of the mul_internal
>calls
>>> were for multiplication by 0 (106038 out of 169355). This patch
>adds
>>> an early-out for that.
>>>
Richard Sandiford wrote:
>This started out as an another attempt to find places where we had
>things like:
>
> offset_int x = wi::to_offset (...);
> x = ...x...;
>
>and change them to:
>
> offset_int x = ...wi::to_offset (...)...;
>
>with the get_ref_base_and_extent case being the main one.
Richard Sandiford wrote:
>Without profiling information, GCC tends to assume "x == 1" and
>"x + y == 2" are likely false, so this patch adds some
>__builtin_expects.
>(system.h has a dummy definition for compilers that don't support
>__builtin_expect.)
>
>Tested on x86_64-linux-gnu. OK to install
> 2013-11-29 Paulo Matos
>Eric Botcazou
>
> * combine.c (reg_nonzero_bits_for_combine): Apply mask transformation
> as applied to nonzero_sign_valid fixing bug when last_set_mode has
> less precision than mode.
Applied, thanks.
--
Eric Botcazou
> Rather than adding do_pending_stack_adjust () in all the places, especially
> when it isn't clear whether emit_conditional_move will be called at all and
> whether it will actually do do_pending_stack_adjust (), I chose to add
> two new functions to save/restore the pending stack adjustment state
Hello,
we currently reject:
constexpr int s = 32;
typedef double VEC __attribute__ ((__vector_size__ (s)));
and similarly for other attributes, while we accept s+0 or (int)s, etc.
The code is basically copied from the constructor attribute. The C
front-end is much less forgiving than the C++
Without profiling information, GCC tends to assume "x == 1" and
"x + y == 2" are likely false, so this patch adds some __builtin_expects.
(system.h has a dummy definition for compilers that don't support
__builtin_expect.)
Tested on x86_64-linux-gnu. OK to install?
Thanks,
Richard
Index: gcc/w
This started out as an another attempt to find places where we had
things like:
offset_int x = wi::to_offset (...);
x = ...x...;
and change them to:
offset_int x = ...wi::to_offset (...)...;
with the get_ref_base_and_extent case being the main one.
But it turned out that some of them w
So maybe two INTEGER_CST lengths weren't enough. Because bitsizetype
can be offset_int-sized, wi::to_offset had a TYPE_PRECISION condition
to pick the array length:
template
inline unsigned int
wi::extended_tree ::get_len () const
{
if (N == MAX_BITSIZE_MODE_ANY_INT
|| N > TYPE_PRECISION
Tobias Burnus wrote:
Tobias Burnus wrote:
While looking at the index for -fsanitize=, I found out that it – and
many other options – lack the @opindex. Attached is an attempted to
add the missing ones.
Updated patch: I also observed some odd "*<-fsanitize=null>" output in
the man page; Manue
On October 25, 2013 22:32, Tobias Burnus wrote:
Tobias Burnus wrote:
Thanks for looking at the patch. However, the patch has a link
problem. The documentation is at
http://gcc.gnu.org/onlinedocs/gcc/Loop_002dSpecific-Pragmas.html
That's also the link I use in the changes.html file. However, so
Jakub Jelinek wrote:
>Hi!
>
>The following testcase ICEs because expand_cond_expr_using_cmove
>calls emit_conditional_move (which calls do_pending_stack_adjust
>under some circumstances), but when that fails, just removes all the
>insns generated by emit_conditional_move (and perhaps some earlier
28 matches
Mail list logo
