On Mon, Oct 25, 2010 at 9:24 PM, Ian Lance Taylor wrote:
> This patch implements Jakub's suggestion for fixing PR 45687. The patch
> is mainly by inspection. The test case fails before the patch and
> succeeds afterward, but the test case only tests the first hunk of the
> patch, not the third (
On 05/14/2011 06:49 PM, Jason Merrill wrote:
On 05/14/2011 02:19 PM, Ville Voutilainen wrote:
Cool, thanks! I'm not quite sure whether there are ambiguities in the
case
of elaborate-specifiers, but I suppose those can be fixed later.
Good point. In the case that
!cp_parser_next_token_starts_cl
On 05/14/2011 02:19 PM, Ville Voutilainen wrote:
Cool, thanks! I'm not quite sure whether there are ambiguities in the case
of elaborate-specifiers, but I suppose those can be fixed later.
Good point. In the case that
!cp_parser_next_token_starts_class_definition_p, we should rewind to
befor
The Tree LIM pass keeps track of the execution status of statements by means of
/* The outermost loop for that execution of the header guarantees that the
block will be executed. */
#define ALWAYS_EXECUTED_IN(BB) ((struct loop *) (BB)->aux)
and there is a fill_always_executed_in function:
/*
> OK, thanks. Note that another delay slot bug was fixed around the same time:
>
> 2010-09-20 Eric Botcazou
>
> PR rtl-optimization/42775
> * cfgrtl.c (rest_of_pass_free_cfg): Recompute notes if delay slot
> scheduling is enabled.
>
> This one was installed on the 4.6/4.5/4
Hi,
the current version of showing the backtrace is not async-signal-safe
as it uses backtrace_symbols() which, in turn, uses malloc(). The
attached patch changes the backtrace printing functionality to instead
use backtrace_symbols_fd() and pipes.
Also, it does some other work on backtrace print
> Investigation showed that this bug was a delay slot scheduling problem
> and that the issue was fixed by Eric last September. The fix was back
> ported to the 4.5 branch but not to previous branches. The identical
> fix applies to the 4.4 and 4.3 branches.
>
> Ok to backport?
OK, thanks. Note
On 14 May 2011 21:15, Jason Merrill wrote:
> On 05/14/2011 12:42 PM, Ville Voutilainen wrote:
>> Duly noted, I'll keep that in mind for subsequent ones. Is the patch
>> otherwise ok?
> Yes, and I've applied it.
Cool, thanks! I'm not quite sure whether there are ambiguities in the case
of elaborat
Trunk fails to build using gcc-4.3 and gcc-4.4 when -O1 is specified
in STAGE1_CFLAGS on hppa2.0w-hp-hpux11.11. I have had anecdotal reports
of similar delay slot problems in glibc and the Linux kernel.
Investigation showed that this bug was a delay slot scheduling problem
and that the issue was
On 05/14/2011 12:42 PM, Ville Voutilainen wrote:
On 14 May 2011 19:41, Jason Merrill wrote:
Paolo is right, C++0x tests go in cpp0x. I'll move this and your earlier
one.
Duly noted, I'll keep that in mind for subsequent ones. Is the patch
otherwise ok?
Yes, and I've applied it.
Jason
2011/5/14 Eric Botcazou :
>> Those issues should be fixed by the attached patch, which relaxes
>> strictness of logical operations in tree-cfg.c file.
>
> Thanks.
>
>> 2011-05-14 Kai Tietz
>>
>> * tree-cfg.c (verify_gimple_assign_unary): Don't enforce
>> boolean_type_node
>> compat
On 14 May 2011 19:41, Jason Merrill wrote:
> Paolo is right, C++0x tests go in cpp0x. I'll move this and your earlier
> one.
Duly noted, I'll keep that in mind for subsequent ones. Is the patch
otherwise ok?
On 05/14/2011 10:56 AM, Ville Voutilainen wrote:
At Sat, 14 May 2011 09:01:39 +0200,
Paolo Carlini wrote:
... I'm wondering if wouldn't be more appropriate for the new testcase to be in
/cpp0x, with a name like final.C
There are probably other tests there that need moving too,
if such moving
> Those issues should be fixed by the attached patch, which relaxes
> strictness of logical operations in tree-cfg.c file.
Thanks.
> 2011-05-14 Kai Tietz
>
> * tree-cfg.c (verify_gimple_assign_unary): Don't enforce
> boolean_type_node
> compatible lhs/rhs types for logical expres
On Sat, May 14, 2011 at 18:35, Tobias Burnus wrote:
> Janne Blomqvist wrote:
>>
>> > I disagree with the ERROR STOP change.
>> My thinking is that the spirit of ERROR STOP is that the program
>> noticed something went seriously wrong (e.g. program state corrupted
>> in some way), and hence a bac
Janne Blomqvist wrote:
> I disagree with the ERROR STOP change.
My thinking is that the spirit of ERROR STOP is that the program
noticed something went seriously wrong (e.g. program state corrupted
in some way), and hence a backtrace and/or core dump might help
figure out what went wrong. For l
Hello!
Attached patch introduces Yd and Yx conditional register constraints
to merge push{xf,df}_integer, movdf_integer with corresponding base
patterns. Additionaly, the patch adds standard_sse_constant_p to
check for valid SSE constants in relevant patterns and
standard_sse_constant_opcode to o
On Sat, May 14, 2011 at 13:25, Tobias Burnus wrote:
> Janne Blomqvist wrote: PR libfortran/48915
>>
>> * lang.opt: Remove -fdump-core.
>
> Shouldn't one set this one to "Ignore" instead of removing it?
It suppose one could argue this makes sense, in order to not break
existing makefiles.
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00781.html
At Sat, 14 May 2011 09:01:39 +0200,
Paolo Carlini wrote:
> ... I'm wondering if wouldn't be more appropriate for the new testcase to be
> in /cpp0x, with a name like final.C
There are probably other tests there that need moving too,
if such moving is done. I don't have a strong opinion
either way
Joern Rennecke wrote:
This patch hasn't been reviewed for a week:
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00582.html
The Fortran bits are OK.
Tobias
PS: For those, who have not looked at the patch, the Fortran-relevant
part is '#include "tm.h"' and the removal of "#if 0" code.
2010-
On 05/14/2011 09:14 AM, Tobias Burnus wrote:
As title says: Make -Ofast imply -fstack-arrays
I haven't commented on this before, but everyone should realize that
automatic arrays were allocated on the stack *always* by g77.
I never even bothered to study how gfortran did it, because I assum
This patch hasn't been reviewed for a week:
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00582.html
On 05/14/2011 06:47 AM, Tobias Burnus wrote:
This patch re-adds the option -f(no-)backtrace as Ignored to improve backward
compatibility.
Additionally, for ERROR STOP, no backtrace is printed any more.
Build on x86-64-linux.
OK for the trunk?
Tobias
OK, thanks,
Jerry
2011/5/14 Eric Botcazou :
>> In Fortran (and maybe other langauges) there are booleans with
>> different sizes but the same precision.
>
> Ada doesn't have a C-like boolean type either. The patches have introduced:
>
> FAIL: gnat.dg/lto1.adb (test for excess errors)
>
>
> /home/eric/svn/gcc/gcc/te
This patch re-adds the option -f(no-)backtrace as Ignored to improve
backward compatibility.
Additionally, for ERROR STOP, no backtrace is printed any more.
Build on x86-64-linux.
OK for the trunk?
Tobias
2011-05-14 Tobias Burnus
* lang.opt (fdump-core): Re-add as ignored option
for back
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Chinese (simplified) team of translators. The file is available at:
http://translationproject.org/latest/gcc/zh_CN.po
(This file, 'gcc-4.6.0.
Janne Blomqvist wrote: PR libfortran/48915
* lang.opt: Remove -fdump-core.
Shouldn't one set this one to "Ignore" instead of removing it? In
particular as in a way the default option is kind of "-fdump-core"?
* runtime/stop.c (stop_numeric): Call exit().
(error_stop_
Hi,
I committed the attached patch as obvious. It updates the manual
section on mixed-language programming to reflect the changes made as
part of PR 48915.
Index: gfortran.texi
===
--- gfortran.texi (revision 173750)
+++ gfortr
Hi Jerry,
On 05/01/2011 02:49 AM, Thomas Koenig wrote:
Hello world,
after Paul's fix for allocate on assignment (thanks Paul!), here is a
patch for the original test case from PR 22572, where the bounds of
the function are unknown at compile time. This uses an allocatable
temporary.
In the lo
On Sat, May 14, 2011 at 10:14, Tobias Burnus wrote:
> As title says: Make -Ofast imply -fstack-arrays
>
> (For Polyhedron shows, -fstack-arrays improves performance by 7% to 10%. Cf.
> https://userpage.physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/iff/#rt )
>
> Build on x86-64-linux.
> OK for t
As title says: Make -Ofast imply -fstack-arrays
(For Polyhedron shows, -fstack-arrays improves performance by 7% to 10%.
Cf.
https://userpage.physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/iff/#rt )
Build on x86-64-linux.
OK for the trunk?
Tobias
2011-05-14 Tobias Burnus
* doc/invoke.
... I'm wondering if wouldn't be more appropriate for the new testcase to be in
/cpp0x, with a name like final.C
Paolo
33 matches
Mail list logo
