Hello,
(sorry for multiple copies of this email)
This small fix was inserted to skip DEBUG_INSNs while
recognizing doloop pattern in loop-doloop.c file. It's a fix
for the already approved do-loop patch (not in mainline yet,
http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01718.html) in loop-doloop
Hello,
(sorry for multiple copies of this email)
This small fix was inserted to skip DEBUG_INSNs while
recognizing doloop pattern in loop-doloop.c file. It's a fix
for the already approved do-loop patch (not in mainline yet,
http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01718.html) in loop-doloop
Hello,
(sorry for multiple copies of this email)
This small fix was inserted to skip DEBUG_INSNs while
recognizing doloop pattern in loop-doloop.c file. It's a fix
for the already approved do-loop patch (not in mainline yet,
http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01718.html) in loop-doloo
Hi,
> This small fix was inserted to skip DEBUG_INSNs while
> recognizing doloop pattern in loop-doloop.c file. It's a fix
> for the already approved do-loop patch (not in mainline yet,
> http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01718.html) in loop-doloop.c
>
> The patch was tested together
> This patch remove some unused macros from sparc.h. The
> RTX_OK_FOR_OFFSET_P and RTX_OK_FOR_OLO10_P macros is used only in
> sparc_legitimate_address_p function and moved to sparc.c.
Thanks for spotting this.
> OK to install?
>
>
> * config/sparc/sparc.h (REG_OK_FOR_INDEX_P, REG_OK_
> 2011-03-24 Eric Botcazou
>
> * config/rs6000/rs6000.c (output_profile_hook): Fix thinko.
Applied as obvious.
--
Eric Botcazou
> Have you run the regression test suite for the AVR for this patch?
The compiler doesn't even build without the print_operand_address hunk...
I've installed this hunk as obvious to make some progress.
--
Eric Botcazou
Hello,
Here the problem is that we were recursing even if there was a user
defined constructor. In fact, the check was only done at the top, not
in nested fields.
If there is a user defined constructor, uninitialized const or
reference members are diagnosed elsewhere.
Bootstraped and tested on x86
On 6 May 2011 13:29, Richard Earnshaw wrote:
>
> On Thu, 2011-04-21 at 09:02 +0300, Ira Rosen wrote:
>> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02172.html
>>
>> The last version:
>>
>> ChangeLog:
>>
>> * doc/invoke.texi (preferred-vector-size): Document.
>> * params.h (PREFERRED_VEC
On Sat, May 7, 2011 at 19:35, Janne Blomqvist wrote:
> Hi,
>
> the error printing functionality (in io/unix.c) st_printf and
> st_vprintf are not thread-safe as they use a static buffer. However,
> since these routines are used when something has gone wrong, we
> shouldn't use malloc() to allocate
On Sun, 8 May 2011, Ira Rosen wrote:
> How about ARM specific flag similar to -mprefer-avx128 (not tested)?
If this goes in, please also update gcc-4.7/changes.html.
Thanks,
Gerald
On 8 May 2011 15:02, Gerald Pfeifer wrote:
> On Sun, 8 May 2011, Ira Rosen wrote:
>> How about ARM specific flag similar to -mprefer-avx128 (not tested)?
>
> If this goes in, please also update gcc-4.7/changes.html.
Do you mean that the new flag should be documented?
This patch http://gcc.gnu.org
This has been redundant for 8+ years, and in the course of simplifying
things globally I noticed and yanked this now.
Gerald
Index: projects/tree-ssa/tree-browser.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/tree-ssa/tree-brow
On Fri, 6 May 2011, Jonathan Wakely wrote:
>> I would propose to clarify as:
>>
>> "To ensure that GCC finds the GNU assembler (or the GNU linker),"
> I see no harm in that change, Gerald, what do you think?
Agreed. Things would have been different twenty years ago, but these
days using linker is
> Agreed. Things would have been different twenty years ago, but these
> days using linker is a lot more natural and common (as a grep in gcc/doc
> confirms, too).
Even 20 years ago, I think "linker" would have been the more natural
word. I remember "linker" from my IBM days in the early 80's.
On May 8 2011, Janne Blomqvist wrote:
the error printing functionality (in io/unix.c) st_printf and
st_vprintf are not thread-safe as they use a static buffer. ...
While this patch makes error printing thread-safe, it's no longer
async-signal-safe as the stderr lock might lead to a deadlock. S
On Tue, May 3, 2011 at 6:33 AM, H.J. Lu wrote:
> On Sat, Apr 16, 2011 at 1:11 AM, Jakub Jelinek wrote:
>> On Fri, Mar 25, 2011 at 12:32:37PM +0100, Jakub Jelinek wrote:
>>> As I said in my GCC Summit talk, currently we just give up on
>>> any floating point/_Decimal*/__int128 and for 32-bit targe
Hi,
committed to mainline.
Paolo.
//
2011-05-08 Paolo Carlini
PR c++/48816
* cxx-pretty-print.c (pp_cxx_template_declaration): Remove
effectively unused variable.
Index: cxx-pretty-print.c
==
On Fri, Apr 29, 2011 at 2:18 PM, Jan Hubicka wrote:
> Hi,
> this more or less complettes the infrastructure for predicates by adding
> logic propagating predicates across CFG. I also added switch statement
> handling and __builtin_constant_p construct, so we "understand" functions
> using those a
Sorry - I should have clarified that ANYTHING that can't be used
independently in multiple threads and at multiple levels in the same thread
counts as a resource, and that includes stderr.
Regards,
Nick Maclaren.
Hi,
as far as I can see this is just another case where we want to pass down
more consistently the complain argument in order to avoid hard errors in
sfinae contexts. In particular, we don't want hard errors from
reshape_init itself (in order to fix 48737) and we want digest_init_r to
forward
On Sun, May 8, 2011 at 14:40, Janne Blomqvist wrote:
> On Sat, May 7, 2011 at 19:35, Janne Blomqvist
> wrote:
>> Hi,
>>
>> the error printing functionality (in io/unix.c) st_printf and
>> st_vprintf are not thread-safe as they use a static buffer. However,
>> since these routines are used when s
Hi,
this patch adds neccesary support into ipa-inline-analysis to make it useable
for ipa-cp. I.e. in the following testcase:
int test (int a)
{
if (a>10)
{
e();
e();
e();
e();
e();
e();
e();
e();
}
}
main2()
{
test(1);
test(
On Sun, May 8, 2011 at 16:42, N.M. Maclaren wrote:
> On May 8 2011, Janne Blomqvist wrote:
>>>
>>> the error printing functionality (in io/unix.c) st_printf and
>>> st_vprintf are not thread-safe as they use a static buffer. ...
>>
>> While this patch makes error printing thread-safe, it's no long
Hello!
Attached patch fixes changed register allocation where "enabled"
attribute is used. The core of the problem was with IRA, where IRA
does not look at "enabled" attribute when scanning through
alternatives string to perform various tasks (including register
allocation preferences).
Attached
On May 8 2011, Janne Blomqvist wrote:
It's theoretically insoluble, given the constraints you are working
under. Sorry. It is possible to do reasonably well, but there will
always be likely scenarios where all you can do is to say "Aargh!
I give up."
Well, I realize perfection is impossible,
On Sun, 8 May 2011, Ira Rosen wrote:
>> If this goes in, please also update gcc-4.7/changes.html.
> Do you mean that the new flag should be documented?
Yes, as we're adding new flags, it's (nearly?) always a good idea to
document them as part of the release notes.
> This patch http://gcc.gnu.org/
On Sat, 30 Apr 2011, Steven Bosscher wrote:
>> 2011-04-26 Gerald Pfeifer
>>
>> * projects.html: Use regular markup for section headers
>> instead of fake tables.
> The "Compiler improvements" section is 10 years behind on GCC's
> development (tree-ssa!). The "recently released" jM
On Tue, 31 Aug 2010, Andre Majorel wrote:
> Yesterday, I spent an hour looking for the C99 and C++0x status
> pages in http://gcc.gnu.org/,
>
> http://gcc.gnu.org/c99status.html
> http://gcc.gnu.org/projects/cxx0x.html
>
> Apparently, the shortest path to the latter is
>
> "Releases"
>
Hi,
The x86 Android toolchain needs setting LDFLAGS_FOR_TARGET to
build. This patch does that. The patch was tested by bootstrapping
natively on x86_64 linux. Do I also need to submit this to binutils
as well?
-Doug
On Sun, May 8, 2011 at 7:31 PM, Doug Kwan (關振德) wrote:
> Hi,
>
> The x86 Android toolchain needs setting LDFLAGS_FOR_TARGET to
> build. This patch does that. The patch was tested by bootstrapping
> natively on x86_64 linux. Do I also need to submit this to binutils
> as well?
>
There is no
Sorry, forgot the patch and the ChangeLog
2011-05-08 Doug Kwan
* configure.ac: Propagate LDFLAGS_FOR_TARGET.
* configure: Regenerated.
* Makefile.tpl (LDFLAGS_FOR_TARGET): Use LDFLAGS_FOR_TARGET
value from configure.
* Makefile.in: Regenerated.
On Sun,
OK.
Jason
On 05/08/2011 12:51 PM, Paolo Carlini wrote:
@@ -5203,7 +5203,7 @@ reshape_init_r (tree type, reshape_iter *d, bool f
{
++d->cur;
gcc_assert (BRACE_ENCLOSED_INITIALIZER_P (init));
- return reshape_init (type, init);
+ return reshape_
Gerald Pfeifer wrote on 09/05/2011 01:53:35 AM:
>
> On Sun, 8 May 2011, Ira Rosen wrote:
> >> If this goes in, please also update gcc-4.7/changes.html.
> > Do you mean that the new flag should be documented?
>
> Yes, as we're adding new flags, it's (nearly?) always a good idea to
> document the
35 matches
Mail list logo
