Hi Adam,
Looks like you were right! My SIZE_TYPE was undefined so it defaulted
to "long unsigned int". Setting it to "unsigned int" solved my
problems.
Thank you very much!
/Markus
2009/8/13 Adam Nemet :
> Markus L writes:
>> I run into an assert in convert_memory_address not beeing able to
>>
Working on the GNAT multi-source compile feature
(see http://gcc.gnu.org/ml/gcc/2009-04/msg00380.html),
I am running into crashes in ggc_collect() on compiling
the 2nd file in the compile job.
Following the advice given in
http://gcc.gnu.org/ml/gcc/2004-04/msg00901.html ,
I configured GCC wit
okell...@freenet.de wrote:
> Working on the GNAT multi-source compile feature
>
> (see http://gcc.gnu.org/ml/gcc/2009-04/msg00380.html),
>
> I am running into crashes in ggc_collect() on compiling
>
> the 2nd file in the compile job.
>
>
>
> Following the advice given in
> http://gcc.gnu.org/
2009/8/13 Sebastian Pop :
> Could you please send the patch you are working on, together with
> a reduced testcase? This could help to reproduce the error.
Thanks.
I put the patch and a test below. The patch is based on 4.4.0. It's
just a toy, I haven't a nice design for now.
Actually, first_n
Hello,
The following code is rejected by one compiler, while it is accepted by gcc
without any warning. Several people in comp.lang.c seem to think that it is a
bug in the first compiler which should ***not*** reject the program.
Message-ID:
http://groups.google.com/group/comp.lang.c/browse_frm/
On Fri, 14 Aug 2009, Marc Mason wrote:
> Hello,
>
> The following code is rejected by one compiler, while it is accepted by gcc
> without any warning. Several people in comp.lang.c seem to think that it is a
> bug in the first compiler which should ***not*** reject the program.
>
> Message-ID:
Hi,
> Seems that use info is not updated.
>
You should put a TODO_update_ssa in the flags of prefetching pass.
With the attached patch I don't see an error.
Also, why don't you use trunk for your developments?
Sebastian
diff --git a/gcc/tree-flow.h b/gcc/tree-flow.h
index 1d2e69a..1320b5a 10064
In article <20090811.n7cmlsw1041...@latour.labs.mot.com>, I wrote:
> GCC 4.4.1 was successfully built, checked and installed on
> i386-unknown-freebsd7.2. Note: Default configure options were
> used except GNU binutils 2.19.1.20090812 rather than system's
> binutils 2.15 and the testsuite was
> "Andrew" == Andrew Haley writes:
>> I am running into crashes in ggc_collect() on compiling
Andrew> The usual way to find this is to use a gdb watchpoint. Find
Andrew> what object is being freed, put a breakpoing on ggc_alloc_stat
Andrew> at the point the object is created, and then put a
On 8/13/09, Joseph S. Myers wrote:
> On Thu, 13 Aug 2009, Lawrence Crowl wrote:
> > > Now a processor D for this architecture comes out. All code
> > > for A, B and C will work on D, but D also has 8-byte atomic
> > > operations. GCC 4.7, with -march=D, generates code that
> > > uses these opera
I am doing research on multi-threaded call stack mechanisms, and in addition
to academic papers, I am surveying what mechanisms existing languages use.
Does the gcc backend use a mechanism other than the standard C-pthread
style "one stack is allocated on thread creation for each thread, and if
On Fri, 14 Aug 2009, Lawrence Crowl wrote:
> So, if -march=D should not imply inlining of the atomic operations,
> we need another option that does. That other option in turn
> must require the dynamic library use compatible implementations.
> (I'd really like to see errors caught by the loader.)
Hi,
Even after the last patch I can still see random ACATS failures on a
stock debian etch x86_64 machine (gcc13). I've added many traces to the
ACATS script and I can see now a common pattern and it's not related
to Ada multi threading or wrong code generation.
First the ACATS script itself is r
On 8/14/09, Joseph S. Myers wrote:
> On Fri, 14 Aug 2009, Lawrence Crowl wrote:
> > So, if -march=D should not imply inlining of the atomic
> > operations, we need another option that does. That other
> > option in turn must require the dynamic library use compatible
> > implementations. (I'd re
Laurent GUERBY wrote:
> 3/ Here is the point I find surprising: the "ps fauxww" run in the
> second "if" show that even if the script is fully sequential
> at least one gnatmake subprocess (collect-ld) is still marked as running
> *in parallel* with the ps command in the subsequent "if" of the sc
On Fri, 2009-08-14 at 22:19 +0100, Dave Korn wrote:
> Laurent GUERBY wrote:
>
> > 3/ Here is the point I find surprising: the "ps fauxww" run in the
> > second "if" show that even if the script is fully sequential
> > at least one gnatmake subprocess (collect-ld) is still marked as running
> > *i
Hello,
* Laurent GUERBY wrote on Fri, Aug 14, 2009 at 10:52:35PM CEST:
> => gcc/testsuite/ada/acats/run_all.sh
> 3/ Here is the point I find surprising: the "ps fauxww" run in the
> second "if" show that even if the script is fully sequential
> at least one gnatmake subprocess (collect-ld) is sti
On Fri, 2009-08-14 at 23:25 +0200, Ralf Wildenhues wrote:
> Hello,
>
> * Laurent GUERBY wrote on Fri, Aug 14, 2009 at 10:52:35PM CEST:
> > => gcc/testsuite/ada/acats/run_all.sh
>
> > 3/ Here is the point I find surprising: the "ps fauxww" run in the
> > second "if" show that even if the script is
Laurent GUERBY writes:
> Any idea of why /bin/sh is running stuff in parallel instead
> of sequential?
Have you tried set -x?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different
On Fri, 2009-08-14 at 23:36 +0200, Andreas Schwab wrote:
> Laurent GUERBY writes:
>
> > Any idea of why /bin/sh is running stuff in parallel instead
> > of sequential?
>
> Have you tried set -x?
IIRC I tried at first but it didn't gave me useful information,
everything looked "normal", then I
On Fri, 14 Aug 2009, Lawrence Crowl wrote:
> So, suppose I compile my program A, using libc version X, on
> a processor of type D, which permits me to inline the atomic
> operations. Then suppose that I execute A on a processor of type E,
> which has libc version X, but which supports fewer atomi
Laurent GUERBY wrote:
> gnatmake uses Non_Blocking_Spawn to call the compiler (gnatmake supports
> "-j N" like make), but for the gnatlink call (we see in the "ps fauxww")
> it uses in gcc/ada/make.adb:
>
>procedure Link
> ...
> GNAT.OS_Lib.Spawn (Gnatlink_Path.all, Link_Args, Success);
2009/7/3 Ian Lance Taylor :
> Mohamed Shafi writes:
>
>> I just want to know about the feasibility of implementing an
>> instruction for a port in gcc 4.4
>> The target has 40 bit register where the normal load/store/move
>> instructions will be able to access the 32 bits of the register. In
>> or
> > * Laurent GUERBY wrote on Fri, Aug 14, 2009 at 10:52:35PM CEST:
> > > => gcc/testsuite/ada/acats/run_all.sh
> >
> > > 3/ Here is the point I find surprising: the "ps fauxww" run in the
> > > second "if" show that even if the script is fully sequential
> > > at least one gnatmake subprocess (co
24 matches
Mail list logo
