On Tue, Dec 3, 2013 at 6:53 AM, Konstantin Serebryany
wrote:
>>> >> with #if LINUX_VERSION_CODE >= 132640
>>> Good idea, let me try that.
>>
>> Had a quick look at this on RHEL 5.
>> Following patch let me compile at least the first source file, but then
>> I run into tons of issues in sanitizer_
On 12/02/13 15:58, Jakub Jelinek wrote:
Hi!
As discussed in the PR, combiner can combine e.g. unaligned integral
load (e.g. TImode) together with some SSE instruction that requires aligned
load, but doesn't actually check it. For AVX, most of the instructions
actually allow unaligned operands,
On 12/02/13 15:51, Jakub Jelinek wrote:
Hi!
On Sat, Nov 30, 2013 at 12:38:30PM +0100, Eric Botcazou wrote:
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_pendi
On 12/02/13 08:47, Yufeng Zhang wrote:
Ping~
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03360.html
Thanks,
Yufeng
On 11/26/13 15:02, Yufeng Zhang wrote:
On 11/26/13 12:45, Richard Biener wrote:
On Thu, Nov 14, 2013 at 12:25 AM, Yufeng
Zhang wrote:
On 11/13/13 20:54, Bill Schmidt wrot
ping
Thanks,
Kugan
On 27/11/13 15:30, Kugan wrote:
> On 27/11/13 02:07, Richard Earnshaw wrote:
>> On 23/11/13 01:54, Kugan wrote:
>
> [snip]
>
>>> +2013-11-22 Kugan Vivekanandarajah
>>> +
>>> + * libgcc/config/arm/pbapi-lib.h (HAVE_NO_HW_DIVIDE): Define for
>>
>> It's bpabi-lib.h
>
> Tha
On 11/27/13 17:52, Jason Merrill wrote:
On 11/27/2013 04:14 PM, Iyer, Balaji V wrote:
I completely agree with you that there are certain parts of Cilk
Plus that is similar to OMP4, namely #pragma simd and SIMD-enabled
functions (formerly called elemental functions). But, the Cilk
keywords is
On 11/27/13 17:13, Cesar Philippidis wrote:
I looked into adding support for incremental DF scanning from df*.[ch]
in combine but there are a couple of problems. First of all, combine
does its own DF analysis. It does so because its usage falls under this
category (df-core.c):
c) If the pas
> Is this still necessary after HJ's patch?
Frankly I don't have access to non-sanitizer-enabled platform but if I
manually disable it in libsanitizer/configure, I start getting Asan test
errors which are similiar to e.g.
http://gcc.gnu.org/ml/gcc-testresults/2013-12/msg00189.html
(i386-unkno
On 11/30/13 10:24, Eric Botcazou wrote:
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_exp
On 11/28/13 16:50, Alan Modra wrote:
This is due to that innocuous seeming change of setting
lra_in_progress before calling check_rtl(), in combination with
previous changes Vlad made to the rs6000 backend here:
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02208.html
In particular the "Call legi
On 11/28/13 03:24, Bernd Edlinger wrote:
Hi,
On Wed, 27 Nov 2013 12:07:16, Jeff Law wrote:
On 11/27/13 05:29, Bernd Edlinger wrote:
Hi,
ping...
this patch still open: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02291.html
Note: it does, as it is, _not_ depend on the keep_aligning patch.
A
On Tue, Dec 3, 2013 at 2:32 AM, Jakub Jelinek wrote:
> On Mon, Dec 02, 2013 at 05:59:53PM +0100, Konstantin Serebryany wrote:
>> >> with #if LINUX_VERSION_CODE >= 132640
>> Good idea, let me try that.
>
> Had a quick look at this on RHEL 5.
> Following patch let me compile at least the first sourc
On 12/02/13 16:02, Jakub Jelinek wrote:
Hi!
tree-nested.c uses declare_vars with last argument true, which
relies on BLOCK_VARS of gimple_bind_block being a tail
of the gimple_bind_vars chain. But unfortunately a debug info
improvement I've added to gimplify_var_or_parm_decl 4 years ago
violate
On 12/01/13 23:12, Yury Gribov wrote:
> This is causing all the tests being run on all targets,
> even if libsanitizer is not supported,
> most of them failing due to link errors.
Thanks for the info and sorry about this. I should probably check
non-sanitized platforms as well before commitin
On 12/02/13 16:04, Jakub Jelinek wrote:
Hi!
Recent change to tree-object-size.c to fold stmts with immediate uses
of __builtin_object_size result broke the pass, because it now can
create new SSA_NAMEs and the code wasn't expecting that to happen.
Fixed thusly, bootstrapped/regtested on x86_64-
On 12/02/13 16:44, Vladimir Makarov wrote:
First of all, it is a bad situation for code performance when IRA
decides that it can use frame pointer for allocation, and after that
LRA/reload decides that frame pointer can not be used and spills all
pseudos assigned to FP. The generated code w
On 11/28/13 00:17, Jakub Jelinek wrote:
On Wed, Nov 27, 2013 at 01:11:59PM -0700, Jeff Law wrote:
On 11/27/13 00:36, Jakub Jelinek wrote:
Use libbacktrace for libsanitizer's symbolization (will need tweaking,
depending on next libsanitizer merge, whether the corresponding
sanitizer_common chan
On 11/28/13 03:03, Chung-Ju Wu wrote:
Hi, Mike,
There is a pending testsuite patch for nds32 target:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01584.html
Is it OK for trunk? :)
Best regards,
jasonwucj
2013/11/14 Chung-Ju Wu :
I would like to modify some testcases for nds32 target.
On 11/27/13 15:31, Wei Mi wrote:
Hmm, maybe attack from the other direction? -- could we clear SCHED_GROUP_P
for each insn at the start of this loop in sched_analyze?
It's not as clean in the sense that SCHED_GROUP_P "escapes" the scheduler,
but it might be an option.
for (insn = head;; ins
Code was added to copy the jump threading path (AUX field on an edge) by
a change from Zdenek in 2007. At the time the code was added, AFAICT,
the copied AUX field would never be examined and certainly not used for
threading.
I'd been suspicious of Zdenek's code to copy the AUX field, but w
This patch fixes bug 58235, a corner case with non-lvalue arrays in
C90 where the assignment of a non-lvalue array to an expression with
array type was not diagnosed. A specific check is added for
assignments to arrays (which are never valid).
Bootstrapped with no regressions on x86_64-unknown-li
On Thu, Nov 28, 2013 at 9:36 PM, Bernd Edlinger
wrote:
> Hi,
>
> On Wed, 27 Nov 2013 19:49:39, Uros Bizjak wrote:
>>
>> On Mon, Nov 25, 2013 at 10:08 PM, Sriraman Tallam
>> wrote:
>>
>>> I have attached a patch to fix this bug :
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58944
>>>
>>> A
On Wed, Nov 27, 2013 at 3:04 PM, Michael Hudson-Doyle
wrote:
>
> This patch brings the recent fix for the generated hash functions of
> types that are aliases for structures containing unexported fields to
> the 4.8 branch.
Thanks. Committed to 4.8 branch.
Ian
On Wed, Nov 27, 2013 at 3:01 PM, Michael Hudson-Doyle
wrote:
> This patch brings the recent fix for calling a function or method that
> takes or returns an empty struct via reflection to the 4.8 branch.
Thanks. Committed to 4.8 branch.
Ian
After changing a backend to back end or back-end, I realized we had
a number of uses of back-end which actually were about the noun (back
end).
Fixed thusly.
Index: svn.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/svn.html,v
retrieving
Hi,
emit_memset fails to adjust destination address after gen_strset, which
leads to the wrong address in aliasing info. This patch fixes it.
Tested on Linux/x86-64. OK to install?
Thanks.
H.J.
---
gcc/
2013-12-03 H.J. Lu
PR target/59363
* config/i386/i386.c (emit_memset)
Hi Richard
Could you please take a look at this patch and see if it is ready for
the trunk? The patch is pasted as a text file here again.
Thank you very much!
Cong
On Mon, Nov 11, 2013 at 11:25 AM, Cong Hou wrote:
> Hi James
>
> Sorry for the late reply.
>
>
> On Fri, Nov 8, 2013 at 2:55 AM
On Mon, 11 Nov 2013, Joseph S. Myers wrote:
>> Working to address a user question, I noticed that many of our pages use
>> the spelling of "backend" when http://gcc.gnu.org/codingconventions.html
>> suggest "back end" (noun) and "back-end" (adjective).
>>
>> Joseph, if you confirm that back end i
Good idea, Mike, I'll make that change.
Thanks,
Bill
On Mon, 2013-12-02 at 16:54 -0800, Mike Stump wrote:
> On Dec 2, 2013, at 3:32 PM, Bill Schmidt wrote:
> > The test case gcc.dg/vect/costmodel/ppc/costmodel-slp-34.c fails if a
> > loop isn't vectorized. When compiled for little endian, the c
Any comment on this patch?
thanks,
Cong
On Fri, Nov 22, 2013 at 11:40 AM, Cong Hou wrote:
> On Fri, Nov 22, 2013 at 3:57 AM, Marc Glisse wrote:
>> On Thu, 21 Nov 2013, Cong Hou wrote:
>>
>>> On Thu, Nov 21, 2013 at 4:39 PM, Marc Glisse wrote:
On Thu, 21 Nov 2013, Cong Hou wrote:
>>
On Dec 2, 2013, at 3:32 PM, Bill Schmidt wrote:
> The test case gcc.dg/vect/costmodel/ppc/costmodel-slp-34.c fails if a
> loop isn't vectorized. When compiled for little endian, the cost of
> vectorizing the loop is deemed too high
> Index: gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-slp-3
On Mon, Dec 2, 2013 at 6:32 PM, Bill Schmidt
wrote:
> The test case gcc.dg/vect/costmodel/ppc/costmodel-slp-34.c fails if a
> loop isn't vectorized. When compiled for little endian, the cost of
> vectorizing the loop is deemed too high to vectorize due to unaligned
> vector accesses within the lo
On Dec 2, 2013, at 12:20 PM, Richard Sandiford
wrote:
> I noticed that there were still a couple of tests for zero precision.
> OK to install?
Ok.
On Mon, 2 Dec 2013, Marek Polacek wrote:
> Regtested/botstrapped on x86_64-linux, ok for trunk and 4.8 and
> perhaps even 4.7?
>
> 2013-12-02 Marek Polacek
>
> PR c/59351
> c/
> * c-decl.c (build_compound_literal): Allow compound literals with
> empty initial value.
> testsu
On 12/1/2013, 7:57 AM, James Greenhalgh wrote:
On Thu, Nov 28, 2013 at 10:11:26PM +, Vladimir Makarov wrote:
Committed as rev. 205498.
2013-11-28 Vladimir Makarov
PR target/57293
* ira.h (ira_setup_eliminable_regset): Remove parameter.
* ira.c (ira_setup_elimina
Hello,
there are dumps for Inkscape, it looks very well.
Link: https://docs.google.com/file/d/0B0pisUJ80pO1Y0t1aEVBRlByR28/edit
There are few of functions that look like this (wpa cgraph):
_ZL13resync_activeP19_EgeSelectOneActionii/2604322 (resync_active)
@0x7f84af42cea0
Type: function defi
The test case gcc.dg/vect/costmodel/ppc/costmodel-slp-34.c fails if a
loop isn't vectorized. When compiled for little endian, the cost of
vectorizing the loop is deemed too high to vectorize due to unaligned
vector accesses within the loop. Therefore we should skip this test for
LE.
Verified on
2013-12-02 Joern Rennecke
* config/epiphany/epiphany.h: Wrap rtl_opt_pass declarations
in #ifndef IN_LIBGCC2 / #endif.
Index: config/epiphany/epiphany.h
===
--- config/epiphany/epiphany.h (revision 205586)
+++ c
> Good question. Most of the time the expansion can not know if it expands
> Ada, C, or Fortran. In this case we know it can only be Ada, so the C++
> memory model is not mandatory. Maybe Eric can tell, if a data store race
> condition may be an issue in Ada if structure is laid out like
> __attri
Hi!
Recent change to tree-object-size.c to fold stmts with immediate uses
of __builtin_object_size result broke the pass, because it now can
create new SSA_NAMEs and the code wasn't expecting that to happen.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
2013-
Hi!
tree-nested.c uses declare_vars with last argument true, which
relies on BLOCK_VARS of gimple_bind_block being a tail
of the gimple_bind_vars chain. But unfortunately a debug info
improvement I've added to gimplify_var_or_parm_decl 4 years ago
violates this assumption, in that it adds some VA
Hi!
As discussed in the PR, combiner can combine e.g. unaligned integral
load (e.g. TImode) together with some SSE instruction that requires aligned
load, but doesn't actually check it. For AVX, most of the instructions
actually allow unaligned operands, except for a few vmov* instructions where
Hi!
On Sat, Nov 30, 2013 at 12:38:30PM +0100, Eric Botcazou wrote:
> > 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
Hi!
The following testcase is miscompiled (to endless loop), because
union_ranges didn't count with the possibility that *vr0max and vr1max
are uncomparable (one of them is symbolic).
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
preapproved by richi on IRC, committed to tr
On Mon, Dec 02, 2013 at 05:59:53PM +0100, Konstantin Serebryany wrote:
> >> with #if LINUX_VERSION_CODE >= 132640
> Good idea, let me try that.
Had a quick look at this on RHEL 5.
Following patch let me compile at least the first source file, but then
I run into tons of issues in sanitizer_platfor
Gerald Pfeifer wrote:
Okay, so I applied this patch plus the one below to adjust
gcc-4.9/changes.html accordingly. (The first anchor there
is not stable, but for other reasons.)
But it should be sufficient to check them before the release and then
one is fine as the links should refer to the
On 11/28/2013 11:40 AM, Iyer, Balaji V wrote:
Consider the following test case. I took this from the lambda_spawns.cc line
#203.
as you can tell, it is clobbering the lambda closure at the end of the lambda
calling and then it is catching value of A from main2 as it is supposed to.
Yep, your
On Mon, Dec 2, 2013 at 1:59 PM, Cary Coutant wrote:
> This is OK, but your patch also has a local change to contrib/mklog.
> Please be careful not to commit that.
Committed without the contrib/mklog portion.
Also committing on google/gcc-4_8 and google/main.
> gcc/ChangeLog
>
> 2013-12-02 Sterling Augustine
>
> * dwarf2out.c (output_pubnames): Use comp_unit_die ()->die_offset
> when there
> isn't a skeleton die.
This is OK, but your patch also has a local change to contrib/mklog.
Please be careful not to commit that.
Thanks!
-cary
The enclosed patch fixes a mismerge from google/gcc-4_7 to main. When
outputting a pubtype whose type has no skeleton section, it's DIE
offset should be from the comp_unit_die, instead of zero. Zero is
actually a place-holder for the end of the pubtypes.
Sterling
gcc/ChangeLog
2013-12-02 Sterlin
On Mon, 2 Dec 2013, Tobias Burnus wrote:
> Looks good to me. (I fully concur that the _002d is ugly.)
Okay, so I applied this patch plus the one below to adjust
gcc-4.9/changes.html accordingly. (The first anchor there
is not stable, but for other reasons.)
Thanks for pushing for this fix!
Ger
...for optimization purpose. Should be done in one month.
Thanks!
--
Regards,
Tim Shen
commit cc7d58128e68455498d0257c4796cb70a9e24990
Author: tim
Date: Mon Dec 2 15:49:15 2013 -0500
2013-12-02 Tim Shen
* regex_compiler.h: Add todo comment.
* regex_executor.tcc: Likewi
Hi,
On Mon, 2 Dec 2013 15:55:08Richard Biener wrote:
>
> On Mon, Nov 25, 2013 at 1:07 PM, Bernd Edlinger
> wrote:
>> Hello,
>>
>> I had forgotten to run the Ada test suite when I submitted the previous
>> version of this patch.
>> And indeed there were some Ada test cases failing because in Ada
On 12/02/2013 03:34 PM, Richard Sandiford wrote:
Kenneth Zadeck writes:
see wide-int.h around line 290
the MAX_BITSIZE_MODE_ANY_INT is the largest mode on the machine. however
if the value coming in is an unsigned number of the type the represents
that mode, don't we loose a bit?
That was the
Kenneth Zadeck writes:
> see wide-int.h around line 290
>
> the MAX_BITSIZE_MODE_ANY_INT is the largest mode on the machine. however
> if the value coming in is an unsigned number of the type the represents
> that mode, don't we loose a bit?
That was the +1 mentioned here:
http://gcc.gnu.or
Marek Polacek wrote:
>On Mon, Dec 02, 2013 at 05:40:33PM +0100, Marek Polacek wrote:
>> On Mon, Dec 02, 2013 at 04:01:05PM +0100, Richard Biener wrote:
>> > On Wed, Mar 13, 2013 at 1:57 PM, Marek Polacek
>wrote:
>> > > Ping.
>> >
>> > Ok. (yay, oldest patch in my review queue ...)
>>
>> ;) tha
see wide-int.h around line 290
the MAX_BITSIZE_MODE_ANY_INT is the largest mode on the machine. however
if the value coming in is an unsigned number of the type the represents
that mode, don't we loose a bit?
kenny
I noticed that there were still a couple of tests for zero precision.
This patch replaces them with asserts when handling separately-supplied
precisions and simply drops them when handling existing wide_ints.
(The idea is that most code would break for zero precision wide_ints
and only asserting in
On Tue, 21 Aug 2012, Sriraman Tallam wrote:
> Committed after making the changes.
>
> One small problem, I am not sure how to fix this:
>
> The hyper link I referenced is :
> http://gcc.gnu.org/onlinedocs/gcc/X86-Built_002din-Functions.html#X86-Built_002din-Functions
>
> whereas the committed ch
We triggered an assert on attached testcase, because when building the
compound literal with empty initial value complete_array_type returns
3, but we assert it returns 0. It returns 3 only in the pedantic mode,
where empty initializer braces are forbidden. Since we already gave
a warning, I thin
committed as revision 205599 to wide-int branch.
kenny
On 12/02/2013 05:50 AM, Richard Biener wrote:
On Sat, Nov 30, 2013 at 1:55 AM, Kenneth Zadeck
wrote:
Richi,
this is the first of either 2 or 3 patches to fix this.There are two
places that need be fixed for us to do 1X + 1 and this p
On Dec 2, 2013, at 1:10 AM, Andrew Pinski wrote:
>> All the documentation relevant to this architecture uses the term
>> "aarch64". How is arm64 obvious?
>
> The same reason Linus used arm64:
> https://lkml.org/lkml/2012/7/15/133
Thanks for the link, ah, now I exactly understand what that port i
Il 02/12/2013 20:34, Richard Sandiford ha scritto:
>>> >> I followed Joseph's suggestion and reused longlong.h. I copied it from
>>> >> libgcc rather than glibc since it seemed better for GCC to have a single
>>> >> version across both gcc/ and libgcc/. I can put it in include/ if that
>>> >> see
Gerald Pfeifer wrote:
Below you'll find a patch for maintainer-scripts/update_web_docs_svn
which I tested on gcc.gnu.org and the current documentation pages (not
those for older releases) are adjusted now.
Among others this fixes the link you reported above (though adjusting
gcc-4.9/changes.html
On Dec 2, 2013, at 5:02 AM, Chung-Ju Wu wrote:
> Perhaps I should have used the following description, which seems much better:
>
> +/* { dg-skip-if "Variadic funcs have all args on stack. Normal funcs have
> args in registers." { nds32*-*-* } "*" "" } */
Reads nicely, thanks. Also, if I do a
Ian Lance Taylor writes:
> On Sun, Dec 1, 2013 at 2:28 AM, Richard Sandiford
> wrote:
>> I followed Joseph's suggestion and reused longlong.h. I copied it from
>> libgcc rather than glibc since it seemed better for GCC to have a single
>> version across both gcc/ and libgcc/. I can put it in in
On Mon, Dec 02, 2013 at 05:40:33PM +0100, Marek Polacek wrote:
> On Mon, Dec 02, 2013 at 04:01:05PM +0100, Richard Biener wrote:
> > On Wed, Mar 13, 2013 at 1:57 PM, Marek Polacek wrote:
> > > Ping.
> >
> > Ok. (yay, oldest patch in my review queue ...)
>
> ;) thanks. Just to be sure, did you
On 11/29/2013 12:02 PM, Jakub Jelinek wrote:
> As we create SIMD clones for all of SSE2, AVX and AVX2 ISAs right now,
> the assembler needs to support SSE2, AVX and AVX2. Apparently some folks
> are still using binutils that don't handle that, this patch conditionalizes
> the test on that.
>
> Bo
Points to solver has a bug that can cause complex constraints to be
skipped leading to wrong points-to results. In the case that exposed
the problem, there is sd constraint: x = *y which is never processed.
'y''s final points to set is { NULL READONLY ESCAPED NOLOCAL}, but 'x'
points-to set is {}.
On Mon, 2 Dec 2013, Marc Glisse wrote:
>> Index: doc/extend.texi
>> ===
>> +In C++, the ternary operator @code{?:} is available. @code{a?b:c}, where
>> +@code{b} and @code{c} are vectors of the same type and @code{a} is an
>> +integer
On Mon, Dec 02, 2013 at 05:59:53PM +0100, Konstantin Serebryany wrote:
> On Mon, Dec 2, 2013 at 5:44 PM, Jakub Jelinek wrote:
> > On Mon, Dec 02, 2013 at 05:26:45PM +0100, Uros Bizjak wrote:
> >> No, so your patch doesn't regress anything. I can configure with
> >> --disable-libsanitizer to skip b
On Mon, Dec 2, 2013 at 5:10 AM, Gerald Pfeifer wrote:
> On Fri, 8 Nov 2013, H.J. Lu wrote:
>> bugreport.texi has
>>
>> @menu
>> * Criteria: Bug Criteria. Have you really found a bug?
>> * Reporting: Bug Reporting. How to report a bug effectively.
>> * Known: Trouble.Known problems.
On Mon, Dec 2, 2013 at 5:44 PM, Jakub Jelinek wrote:
> On Mon, Dec 02, 2013 at 05:26:45PM +0100, Uros Bizjak wrote:
>> No, so your patch doesn't regress anything. I can configure with
>> --disable-libsanitizer to skip build of libsanitizer, although it
>> would be nice to support RHEL5 derived lon
On Mon, Dec 02, 2013 at 05:43:17PM +0100, Konstantin Serebryany wrote:
> We can fix this particular failure, but unless someone helps us test
> the code upstream
> (not just that it builds, but also that it works) asan has little
> chance to work on old systems anyway.
For these kernel headers tha
Dear Teresa,
I will today double check if the graphs are correct :)
Martin
On 2 December 2013 17:16, Jeff Law wrote:
> On 12/02/13 08:16, Teresa Johnson wrote:
>>
>>
>> I'm wondering if the -fno-reorder-blocks-and-partition graph really
>> had that disabled. I am surprised that the size of th
On Mon, Dec 02, 2013 at 05:26:45PM +0100, Uros Bizjak wrote:
> No, so your patch doesn't regress anything. I can configure with
> --disable-libsanitizer to skip build of libsanitizer, although it
> would be nice to support RHEL5 derived long-term distributions.
>
> > Is there a way to test gcc in
On Mon, Dec 2, 2013 at 5:26 PM, Uros Bizjak wrote:
> On Mon, Dec 2, 2013 at 5:12 PM, Konstantin Serebryany
> wrote:
>
> Does it support using libbacktrace in GCC?
Not on it's own, but the support in the upstream maintained files
is there, so hopefully it will be just a matter o
On Mon, Dec 02, 2013 at 04:01:05PM +0100, Richard Biener wrote:
> On Wed, Mar 13, 2013 at 1:57 PM, Marek Polacek wrote:
> > Ping.
>
> Ok. (yay, oldest patch in my review queue ...)
;) thanks. Just to be sure, did you mean to ok this patch (that is,
the one with HOST_BITS_PER_INT)?
Bootstrap/r
On 12/1/2013, 7:57 AM, James Greenhalgh wrote:
On Thu, Nov 28, 2013 at 10:11:26PM +, Vladimir Makarov wrote:
Committed as rev. 205498.
2013-11-28 Vladimir Makarov
PR target/57293
* ira.h (ira_setup_eliminable_regset): Remove parameter.
* ira.c (ira_setup_elimina
On Mon, Dec 2, 2013 at 5:12 PM, Konstantin Serebryany
wrote:
Does it support using libbacktrace in GCC?
>>>
>>> Not on it's own, but the support in the upstream maintained files
>>> is there, so hopefully it will be just a matter of follow-up patch
>>> with configury/Makefile etc. stuff, I'l
On 12/02/13 08:16, Teresa Johnson wrote:
I'm wondering if the -fno-reorder-blocks-and-partition graph really
had that disabled. I am surprised that the size of the .text and
.text.hot did not shrink from splitting.
Could be due to needing longer jump opcodes to reach the unlikely sections.
jeff
On Mon, Dec 2, 2013 at 4:49 PM, Uros Bizjak wrote:
> Hello!
>
>>> Does it support using libbacktrace in GCC?
>>
>> Not on it's own, but the support in the upstream maintained files
>> is there, so hopefully it will be just a matter of follow-up patch
>> with configury/Makefile etc. stuff, I'll wor
On Mon, Dec 02, 2013 at 04:57:49PM +0100, Marek Polacek wrote:
> This patch puts every VLA test into its separate function to make it
> less like fail due to stack overflow.
>
> Ran ubsan testsuite, ok for trunk?
Ok, thanks.
> 2013-12-02 Marek Polacek
>
> testsuite/
> * c-c++-common/ubs
This patch puts every VLA test into its separate function to make it
less like fail due to stack overflow.
Ran ubsan testsuite, ok for trunk?
2013-12-02 Marek Polacek
testsuite/
* c-c++-common/ubsan/vla-1.c: Split the tests into individual
functions.
--- gcc/testsuite/c-c++-c
Hello!
>> Does it support using libbacktrace in GCC?
>
> Not on it's own, but the support in the upstream maintained files
> is there, so hopefully it will be just a matter of follow-up patch
> with configury/Makefile etc. stuff, I'll work on it once the merge is
> committed.
>
> What is more impo
Ping~
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03360.html
Thanks,
Yufeng
On 11/26/13 15:02, Yufeng Zhang wrote:
On 11/26/13 12:45, Richard Biener wrote:
On Thu, Nov 14, 2013 at 12:25 AM, Yufeng Zhang wrote:
On 11/13/13 20:54, Bill Schmidt wrote:
The second version of your original pat
On Sat, Nov 23, 2013 at 8:22 PM, Mike Stump wrote:
> Richi has asked the we break the wide-int patch so that the individual port
> and front end maintainers can review their parts without have to go through
> the entire patch.This patch covers the random pieces that didn't seem to
> fit nic
On Sat, Nov 23, 2013 at 8:23 PM, Mike Stump wrote:
> Richi has asked the we break the wide-int patch so that the individual port
> and front end maintainers can review their parts without have to go through
> the entire patch.This patch covers the tree-vec code.
>
> Ok?
Ok.
Thanks,
Richard
This fixes PR59139, ternary support was missing from get_val_for.
Instead of supporting it I simply chose to properly disable its
support.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2013-12-02 Richard Biener
PR tree-optimization/59139
* tree-ssa-
On Thu, Nov 28, 2013 at 6:06 AM, Jan Hubicka wrote:
>> Dear Teresa and Jan,
>>I tried to test Teresa's patch, but I've encountered two bugs
>> during usage of -fprofile-generate/use (one in SPEC CPU 2006 and
>> Inkscape).
>
> Thanks, this is non-LTO run. Is there a chance to get -flto version,
On Sun, Nov 3, 2013 at 11:25 AM, Bernd Edlinger
wrote:
> Hello,
>
> on i686-pc-linux-gnu the test case gcc.target/i386/intrinsics_4.c fails
> because of
> an internal compiler error, see PR58155.
>
> The reason for this is that the optab CODE_FOR_movv8sf is disabled when it
> should be enabled.
>
On Wed, Mar 13, 2013 at 1:57 PM, Marek Polacek wrote:
> Ping.
Ok. (yay, oldest patch in my review queue ...)
Thanks,
Richard.
> On Tue, Mar 05, 2013 at 05:06:21PM +0100, Marek Polacek wrote:
>> On Fri, Mar 01, 2013 at 09:41:27AM +0100, Richard Biener wrote:
>> > On Wed, Feb 27, 2013 at 6:38 PM
On Mon, Nov 18, 2013 at 1:11 PM, Bernd Edlinger
wrote:
> Hi,
>
>
> This modified test case exposes a bug in the already approved part of the
> strict-volatile-bitfields patch:
>
> #include
>
> typedef struct {
> char pad;
> int arr[0];
> } __attribute__((packed)) str;
>
> str *
> foo (int* s
On Mon, Dec 02, 2013 at 03:47:18PM +0100, Jakub Jelinek wrote:
> On Mon, Dec 02, 2013 at 03:41:18PM +0100, Marek Polacek wrote:
> > On Mon, Dec 02, 2013 at 02:41:05PM +0100, Marek Polacek wrote:
> > > On Mon, Dec 02, 2013 at 03:52:09PM +0400, Konstantin Serebryany wrote:
> > > > This change breaks
On Mon, Nov 25, 2013 at 1:07 PM, Bernd Edlinger
wrote:
> Hello,
>
> I had forgotten to run the Ada test suite when I submitted the previous
> version of this patch.
> And indeed there were some Ada test cases failing because in Ada packed
> structures are
> like bit fields, but without the DECL_
On Mon, Dec 02, 2013 at 03:41:18PM +0100, Marek Polacek wrote:
> On Mon, Dec 02, 2013 at 02:41:05PM +0100, Marek Polacek wrote:
> > On Mon, Dec 02, 2013 at 03:52:09PM +0400, Konstantin Serebryany wrote:
> > > This change breaks one ubsan test:
> > > make check -C gcc RUNTESTFLAGS='--target_board=un
On Mon, Dec 2, 2013 at 6:41 PM, Marek Polacek wrote:
> On Mon, Dec 02, 2013 at 02:41:05PM +0100, Marek Polacek wrote:
>> On Mon, Dec 02, 2013 at 03:52:09PM +0400, Konstantin Serebryany wrote:
>> > This change breaks one ubsan test:
>> > make check -C gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m6
On Wed, Nov 20, 2013 at 11:48 AM, Bernd Edlinger
wrote:
> Hello Richard,
>
> as a follow-up patch to the bit-fields patch(es), I wanted to remove the
> dependencies on
> the variable flag_strict_volatile_bitfields from expand_assignment and
> expand_expr_real_1.
> Additionally I want the access
On Mon, Dec 02, 2013 at 02:41:05PM +0100, Marek Polacek wrote:
> On Mon, Dec 02, 2013 at 03:52:09PM +0400, Konstantin Serebryany wrote:
> > This change breaks one ubsan test:
> > make check -C gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} ubsan.exp'
> > FAIL: c-c++-common/ubsan/vla-1.c -O0 e
On Mon, Dec 2, 2013 at 5:30 AM, Marek Polacek wrote:
> On Mon, Dec 02, 2013 at 02:21:04PM +0100, Richard Biener wrote:
>> On Mon, Dec 2, 2013 at 1:36 PM, Yuri Rumyantsev wrote:
>> > Hi All,
>> >
>> > Attached is evident fix found in process of investigation of PR 58721.
>> > Note that this fix do
1 - 100 of 149 matches
Mail list logo
