Hello Eric,
On 02 Jan 00:07, Eric Botcazou wrote:
The change is actually to ix86_data_alignment, not to ix86_constant_alignment:
@@ -26219,7 +26433,8 @@ ix86_constant_alignment (tree exp, int align)
int
ix86_data_alignment (tree type, int align, bool opt)
{
- int max_align =
On 01/01/2014 02:01 PM, Felix Yang wrote:
cc1 backtrace:
arraysum.c: In function 'test_entry':
arraysum.c:14:1: internal compiler error: in cfg_layout_initialize, at
cfgrtl.c:4233
Please include steps to reproduce bugs.
Attached please find the patch for this ICE.
Since c6x backend choose
On 30/12/13 02:09, Terry Guo wrote:
Hi There,
This patch intends to check value of --with-arch against the arm-arches.def,
rather than current solution that use hard coded things in config.gcc.
Tested with various values of --with-arch and it works. Is it ok to trunk?
BR,
Terry
Hello,
this patch fixes PR58007, where the compiler was not able to relate a
component pointer to any loaded derived type symbol.
The problem came from an optimization avoiding loading again a symbol
which had already been loaded, skipping by the way the association of
component pointers (if the
Hello Vladimir,
This patch fixes a trivial bug of SMS: distance1_uses needs to be
initialized if newly allocated.
Since the original author of SMS is not active for a very long time,
it would be nice if you can apply it for me : )
Thanks.
Index: gcc/ChangeLog
Hi Bernd,
It's easy to reproduce this error:
step1: Build gcc for c6x from gcc code of latest trunk, say
c6x-uclinux-gcc for example
step2: Using the newly built c6x gcc compiler to comiple this small case:
$c6x-unlinux-gcc -S -O2 arraysum.c
arraysum.c:
int array[1024];
int
Sorry, the year of the date in ChangeLog is wrong, fix it.
Index: gcc/ChangeLog
==
=
--- gcc/ChangeLog(revision 206279)
+++ gcc/ChangeLog(working copy)
@@ -1,3 +1,8 @@
+2014-01-02 Felix Yang fei.yang0...@gmail.com
+
+*
On 14-01-01 09:23 AM, Jan Hubicka wrote:
Here insn 765 gets adjusted for insn766 wihtout updating REG_ARGS_SIZE.
This is IMO not bug in scheduler but bug in fact that insn 775 should not have
the note on it
when it is not adjusting stack pointer. This is because originally it was push
Hi,
This patch fixes pr59651. The original regression for pr52943 only appears on
AArch64 target. I constructed a similar test that also exposes bug on x86-64.
The problem is that calculation of address range in alias versioning for loops
with negative step is wrong during vectorization. For
Frankly speaking, I do not understand, what's wrong here.
IMHO, this change is pretty mechanical: we just extend maximal aligment
available. Because of 512-bit data types we now extend maximal aligment to
512 bits.
Nothing wrong per se, but...
I suspect that an issue is here:
if (opt
On 01/01/2014 09:41 PM, Mike Stump wrote:
Jason, are the C++ patches with this change to them Ok?
Yes.
Jason
Hi,
While looking for -Winline messages I noticed that sched-int.h has self
recursive
function declared inline. The recursion is tail recursion but we fail to
recognize
it as such. The problem ist hat there is a local variable link whose address
is passed to function DEPS_LIST_FIRST (list) and
Hi,
those functions are not inlined since they are too large anyway.
I do not think it is disaster. get_attr_length_1 takes a callback
that may make it more interesting inlining candidate than others,
perhaps.
Bootstrapped/regtested x86_64-linux, OK?
Honza
* gengtype-state.c
Hi all,
I have just committed as obvious a one-line-removal patch which fixes
a wrong-code OOP regression:
http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=206281
Since the regression also affects 4.8, I would like to backport the
patch (after waiting a few days and letting the reporter
Le 02/01/2014 18:40, Janus Weil a écrit :
Hi all,
I have just committed as obvious a one-line-removal patch which fixes
a wrong-code OOP regression:
http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=206281
Sometimes computer programming is more witchcraft than (computer) science.
You
Hi Mikael,
I have just committed as obvious a one-line-removal patch which fixes
a wrong-code OOP regression:
http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=206281
Sometimes computer programming is more witchcraft than (computer) science.
You add some code, it fixes a bug.
Now you
I'd like to suggest applying this to active GCC release branches (i.e. 4.8
and 4.7), subject to testing there, as (effectively) a wrong-code bug fix
needed to avoid glibc test failures.
--
Joseph S. Myers
jos...@codesourcery.com
This patch updates the user visible copyright year in the GCC output of
the commands and in the documentation.* (* I touched only those with
2013 copyright year.)
Unsurprisingly, the patch survived a full bootstrap.
OK for the trunk?
Tobias
PS: I will also roll the ChangeLog files, which I
*ping* - I think the patch is nearly obvious …
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00584.html
On December 6, 2013, Tobias Burnus wrote:
A rather simple fix for an ICE on invalid bug (low-priority 4.8/4.9
regression).
Bootstrapped and regtested without new failure on
On Thu, Jan 02, 2014 at 09:45:30PM +0100, Tobias Burnus wrote:
This patch updates the user visible copyright year in the GCC output
of the commands and in the documentation.* (* I touched only those
with 2013 copyright year.)
Unsurprisingly, the patch survived a full bootstrap.
OK for the
OK.
Jason
OK.
Jason
OK.
Jason
OK.
Jason
On 11/30/2013 05:41 AM, Marc Glisse wrote:
for some reason one of the attributes can see a FUNCTION_DECL where others see
an IDENTIFIER_NODE, I didn't try to understand why and just added that check to
the code.
Please do check.
+ if (size size != error_mark_node TREE_CODE (size) !=
On 12/27/2013 07:02 AM, Paolo Carlini wrote:
the same arguments. Conservatively but still more neatly than my first
try, we could maybe use same_type_ignoring_top_level_qualifiers_p in the
definition of the DERIVED_FROM_P macro?
Sure, let's do that. And add something about incomplete types to
This patch fixes inaccuracy of IBM long double division that causes
large errors in glibc testing
https://sourceware.org/bugzilla/show_bug.cgi?id=15396. The
implementation computes a first approximation to the result as t = a /
c, dividing the high parts of the arguments, then does adjustments
OK.
Jason
x86-64 ABI has clause about aligning static vars to 128bit boundary at a
given size. This was introduced to aid compiler to generate aligned
vector store/load even if the object may bind to other object file.
This is set to stone and can not be changed for AVX/SSE.
Yes, but that's irrelevant
Jakub Jelinek ja...@redhat.com writes:
On Thu, Jan 02, 2014 at 09:45:30PM +0100, Tobias Burnus wrote:
This patch updates the user visible copyright year in the GCC output
of the commands and in the documentation.* (* I touched only those
with 2013 copyright year.)
Unsurprisingly, the patch
x86-64 ABI has clause about aligning static vars to 128bit boundary at a
given size. This was introduced to aid compiler to generate aligned
vector store/load even if the object may bind to other object file.
This is set to stone and can not be changed for AVX/SSE.
Yes, but that's
Note that it has unexpected side-effects: previously, in 32-bit mode,
256-bit aggregate objects would have been given 256-bit alignment; now,
they will fall back to default alignment, for example 32-bit only.
In case this wasn't clear enough, just compile in 32-bit mode:
int a[8] = { 1, 2, 3,
So, Kenny hopefully resolved or answered your previous email, and the only
thing outstanding was the MAX_BITS_PER_UNIT. That part of the patch is now
gone (resolved in a much nicer way in another patch).
So, I'd like to ping the original patch and Kenny's patch to resolve the issues
you
So, I'd like to ping the original patch and Kenny's patch to resolve the
issues you found. If you have any other concerns or thoughts, let us
know.
Almost OK, but remove the strange quotes in the comment for the INTEGER_CST
case of expand_expr_real_1 (and optionally add the fast path for the
On Thu, Jan 02, 2014 at 10:09:20PM +, Richard Sandiford wrote:
Yeah, the one in contrib/ is still the most recent. Here's part 1,
which just makes some new files use the standard format for the copyright
notice, without changing the years. Applied as obvious.
Thanks for this (and for the
Richard Sandiford rdsandif...@googlemail.com writes:
Jakub Jelinek ja...@redhat.com writes:
On Thu, Jan 02, 2014 at 09:45:30PM +0100, Tobias Burnus wrote:
This patch updates the user visible copyright year in the GCC output
of the commands and in the documentation.* (* I touched only those
On 01/02/2014 05:26 PM, Eric Botcazou wrote:
So, I'd like to ping the original patch and Kenny's patch to resolve the
issues you found. If you have any other concerns or thoughts, let us
know.
Almost OK, but remove the strange quotes in the comment for the INTEGER_CST
case of
On Thu, Jan 2, 2014 at 4:46 PM, Joseph S. Myers jos...@codesourcery.com wrote:
This patch fixes inaccuracy of IBM long double division that causes
large errors in glibc testing
https://sourceware.org/bugzilla/show_bug.cgi?id=15396. The
implementation computes a first approximation to the
hi,
In hw-doloop.c, is there a memory leak?
void
reorg_loops (bool do_reorder, struct hw_doloop_hooks *hooks)
{
hwloop_info loops = NULL;
hwloop_info loop;
bitmap_obstack loop_stack;
df_live_add_problem ();
df_live_set_all_dirty ();
df_analyze ();
*bitmap_obstack_initialize
On 01/02/2014 03:47 PM, Tobias Burnus wrote:
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00584.html
OK, but please also check init for error_mark_node.
Jason
40 matches
Mail list logo
