Hi,
This is regarding gcc.c-torture/execute/vla-dealloc-1.c failure.
4.7.0 ia64-hp-hpux: program timed out (time out 300 seconds).
4.7.0 ia64-redhat-linux: program timed out (time out 300 seconds).
4.7.0 x86_64-suse-linux: execution completes successfully.
Inserting a printf statement in
Hi,
Similarly for the following two test case which deals with VLA
de-allocation in a branch back situation:
1. gcc.c-torture/execute/pr43220.c
2. gcc.c-torture/execute/20040811-1.c
Regards,
Kannan
-Original Message-
From: Mailaripillai, Kannan Jeganathan
Sent: Thursday, May 03, 20
On Thu, May 3, 2012 at 1:33 PM, Mailaripillai, Kannan Jeganathan
wrote:
> Hi,
>
> Similarly for the following two test case which deals with VLA
> de-allocation in a branch back situation:
> 1. gcc.c-torture/execute/pr43220.c
> 2. gcc.c-torture/execute/20040811-1.c
Can you try --param large-sta
Thank you all very much for your comments and advice!
It certainly has helped me to gain a better perspective on porting GCC
to a new architecture.
It's not directly a suggestion from my "Betreuer"; a few suggested it
as a Praktikum or as a masters thesis, and I wanted to look into it and
see wh
> Can you try --param large-stack-frame=1?
No change. The program did not return/exit for more than 12 minutes.
> Is sizeof (int) <= 2?
No.
Regards,
Kannan
-Original Message-
From: Richard Guenther [mailto:richard.guent...@gmail.com]
Sent: Thursday, May 03, 2012 5:14 PM
To: Mailaripi
On 02/05/12 16:36, Ian Lance Taylor wrote:
I don't know what a bachelor thesis is, so I don't know if this would be
suitable. A GCC port by itself would be too simple for a masters thesis
in the U.S.
Yes, on second thought, the Betreuer I mentioned did not say anything
about a masters thesis;
02/05/2012 21:36, Eric Botcazou :
>> I have an issue (gcc 4.6.3, private bacakend) when reloading operands of
>> this insn:
>> (set (subreg:SI (reg:QI 21 [ iftmp.1 ]) 0)
>> (lshiftrt:SI (reg/v:SI 24 [ w ]) (const_int 31 [0x1f]))
>>
>> The register 21 is reloaded into
>> (reg:QI 0 r0 [orig:21 i
On Thu, May 3, 2012 at 2:02 PM, Mailaripillai, Kannan Jeganathan
wrote:
>
>> Can you try --param large-stack-frame=1?
> No change. The program did not return/exit for more than 12 minutes.
>
>> Is sizeof (int) <= 2?
> No.
I suppose you open a bugreport then (or check if one is already present
for
I have been fighting with a simple problem for the past few nights. In my
GIMPLE pass I create a variable, an ssa name for that variable, and then assign
it to the LHS of a call I build:
call = gimple_build_call(fndecl, 0);
decl = create_tmp_var(TREE_TYPE(TREE_TYPE(test_decode_fndecl)), "FOO"
On Thu, May 3, 2012 at 3:30 PM, Matt Davis wrote:
> I have been fighting with a simple problem for the past few nights. In my
> GIMPLE pass I create a variable, an ssa name for that variable, and then
> assign
> it to the LHS of a call I build:
>
> call = gimple_build_call(fndecl, 0);
> decl =
Hi gcc team,
The following code creates orphaned memory by ignoring the return value of new:
#include
using namespace std;
int main ( void ) {
for (int i=0; i< 1000; i++)
new int[1000];
int a;
cin >> a;
return 0;
}
Should g++ report a compile-time warning for th
On 05-03 09:19, Camm Maguire wrote:
> Greetings! The build succeeded, which, alas, means the failure at
>
> http://buildd.debian-ports.org/status/fetch.php?pkg=axiom&arch=alpha&ver=20120301-3&stamp=1335722507
>
> is again unreproducible, like the kfree_amd64 and ppc examples. Sigh.
> Are there
On 3 May 2012 17:16, Samuel David wrote:
> Hi gcc team,
>
> The following code creates orphaned memory by ignoring the return value of
> new:
[...]
> Should g++ report a compile-time warning for this case?
Maybe. If you think so then please open a bugzilla report asking for
a new warning, than
On Thu, May 3, 2012 at 1:29 PM, Jonathan Wakely wrote:
>
> Maybe. If you think so then please open a bugzilla report asking for
> a new warning, thanks.
Done! http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53215
With sincere regards,
-S
Greetings, and thanks foro looking into this!
Witold Baryluk writes:
> On 05-03 09:19, Camm Maguire wrote:
>> Greetings! The build succeeded, which, alas, means the failure at
>>
>> http://buildd.debian-ports.org/status/fetch.php?pkg=axiom&arch=alpha&ver=20120301-3&stamp=1335722507
>>
>> is a
On 05/03/2012 10:51 AM, Camm Maguire wrote:
The goal was to exercise the very helpful gcc __builtin___clear_cache
support, and to avoid having to maintain our own assembler for all the
different cpus in this regard. Clearly, it is easy to revert this on a
per architecture basis if absolutely nec
An update on the GNU Tools Cauldron (http://gcc.gnu.org/wiki/cauldron2012)
We have published an initial schedule for the workshop. It is
available at http://gcc.gnu.org/wiki/cauldron2012.
Presenters, please double-check your entries. If you find
anything missing or wrong, please contact me and
On 05-03 11:34, Richard Henderson wrote:
> On 05/03/2012 10:51 AM, Camm Maguire wrote:
> >The goal was to exercise the very helpful gcc __builtin___clear_cache
> >support, and to avoid having to maintain our own assembler for all the
> >different cpus in this regard. Clearly, it is easy to revert
Snapshot gcc-4.5-20120503 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20120503/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
19 matches
Mail list logo