Hi Eric,
it is important for the testcase that the array is that big. In order to
avoid breaking other targets with that I've moved the testcase to the s390
specific directory. I've already committed the patch. Sorry for the
breakage.
Mit freundlichem Gruß / Kind regards,
Andreas Krebbel
**
Hello.
I read this page : http://gcc.gnu.org/java/ and see no news until about one
year. The most links (status, done) have the same old update.
Gcj project do it abandon or stop ? Or just stop web maintain ?
I'm interest by advance of integration of java 1.5 into gcj. When a new
release ? etc.
C
dwarf2out.c:13496: internal compiler error: in extract_insn, at
recog.c:1988
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37045
> arm-rtems4.9-gcc -mfpu=neon -mfloat-abi=softfp -mcpu=arm7tdmi -c
> test_neon.c
>
> #if !defined(__ARM_NEON__)
> #error "Neon not supported"
> #endif
>
> void neon_code(void)
> {
> asm volatile ("vldr d18,[fp,#-32]");
> }
Works fine here. Either your assembler is busted, or there is something
On Wednesday 06 August 2008, Joseph S. Myers wrote:
> On Wed, 6 Aug 2008, Joel Sherrill wrote:
> > $ arm-rtems4.9-gcc -mfpu=neon -mfloat-abi=softfp -mcpu=arm7tdmi -c
> > test_neon.c /tmp/ccBzigjD.s: Assembler messages:
> > /tmp/ccBzigjD.s:13: Error: selected processor does not support `vldr
> > d1
Paul Brook wrote:
On Wednesday 06 August 2008, Joseph S. Myers wrote:
On Wed, 6 Aug 2008, Joel Sherrill wrote:
$ arm-rtems4.9-gcc -mfpu=neon -mfloat-abi=softfp -mcpu=arm7tdmi -c
test_neon.c /tmp/ccBzigjD.s: Assembler messages:
/tmp/ccBzigjD.s:13: Error: selected processor does not supp
Paul Brook wrote:
arm-rtems4.9-gcc -mfpu=neon -mfloat-abi=softfp -mcpu=arm7tdmi -c
test_neon.c
#if !defined(__ARM_NEON__)
#error "Neon not supported"
#endif
void neon_code(void)
{
asm volatile ("vldr d18,[fp,#-32]");
}
Works fine here. Either your assembler is busted, or there is some
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
Joe> Paul Koning <[EMAIL PROTECTED]> writes:
>> > That's sufficient for live debugging but not for corefiles. In
>> that > case you do want caller-saved registers, because they may
>> contain > local variable values that don't live in memory
> We chose arm-elf as the starting point years. If we need to
> move to arm-eabi as the starting point that is OK. We usually
> just chose the CPU-coff or CPU-elf as a starting point
> for CPU-rtems.
I highly recommend switching to the EABI.
If you want to support recent (Thumb-2) CPUs I'd expe
Thanks. We are close to branching an RTEMS release.
Sounds like this will be a good thing to switch to
immediately after that.
--joel
Paul Brook wrote:
We chose arm-elf as the starting point years. If we need to
move to arm-eabi as the starting point that is OK. We usually
just chose the CPU
Hi,
I started with a fresh tree this morning
and get this building the native. Is anyone
else seeing this?
/home/joel/work-gnat/svn/b-native/./prev-gcc/xgcc
-B/home/joel/work-gnat/svn/b-native/./prev-gcc/
-B/home/joel/work-gnat/svn//install/i686-pc-linux-gnu/bin/ -c
-DHAVE_CONFIG_H -g -O2 -
On Thu, Aug 7, 2008 at 7:46 AM, Joel Sherrill <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I started with a fresh tree this morning
> and get this building the native. Is anyone
> else seeing this?
>
> /home/joel/work-gnat/svn/b-native/./prev-gcc/xgcc
> -B/home/joel/work-gnat/svn/b-native/./prev-gcc/
>
Dear GCC-Developers,
I am currently experiencing two problems (which seem related).
(1) I wrote a pass that works after the gimplification is
completed and amongst other things does the following:
It passes the address of a variable to a function. To pass
the address I use the build_fold_addr_ex
On Thu, Aug 7, 2008 at 4:55 PM, Martin Schindewolf <[EMAIL PROTECTED]> wrote:
> Dear GCC-Developers,
>
> I am currently experiencing two problems (which seem related).
>
> (1) I wrote a pass that works after the gimplification is
> completed and amongst other things does the following:
> It passes
Joe> After all, if we have
int func1(int);
void func2(int);
void ordinary_function(void);
void func(int arg) {
int v1 = func1(arg);
func2(v1);
ordinary_function();
}
> Joe> and there's a segfault in ordinary_function, in general v1 isn't
> Joe> going to be kept around for i
Paolo Bonzini wrote:
>
>> That said, updating in trunk is a different matter. There, the question
>> IMHO is mostly which libtool version to update to. The git version may
>> still have a regression or two, but 2.2.4 doesn't have the -fPIC on
>> HP/IA patch from Steve (which would be trivial to
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
Joe> ...OK, consider this case:
Joe> int func1(int); void func2(int); bool test(void); void
Joe> func3(int);
Joe> void func(int arg) { int v1 = func1(arg); func2(v1); if (test())
Joe> { func3(v1); } }
Joe> Here if we put v1 in a register
Hi,
I would like to avoid denormal handling latencies. On Intel, this is turned
ON by default and Intel compiler has the -ftz- option to turn it off. I am
looking for a similar option of GCC. Any ideas?
Thanks a lot in advance!
-Memo
--
View this message in context:
http://www.nabble.com/Tu
On Thu, Aug 7, 2008 at 10:41 AM, MeMooMeM <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I would like to avoid denormal handling latencies. On Intel, this is turned
> ON by default and Intel compiler has the -ftz- option to turn it off. I am
> looking for a similar option of GCC. Any ideas?
>
-ffast-math?
H.J. Lu-30 wrote:
>
> On Thu, Aug 7, 2008 at 10:41 AM, MeMooMeM <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> I would like to avoid denormal handling latencies. On Intel, this is
>> turned
>> ON by default and Intel compiler has the -ftz- option to turn it off. I
>> am
>> looking for a similar opt
Andreas Krebbel1 <[EMAIL PROTECTED]> writes:
> it is important for the testcase that the array is that big. In order to
> avoid breaking other targets with that I've moved the testcase to the s390
> specific directory. I've already committed the patch. Sorry for the
> breakage.
If the test will r
Hi,
As I warned in http://gcc.gnu.org/ml/gcc/2008-07/msg00387.html,
the new technique for generating s-oscons.ads does not work
for RTEMS. The OS .h files are not available when the compiler
is built -- only those strictly owned by the newlib C library.
As indicated by this from the build log,
> As I warned in http://gcc.gnu.org/ml/gcc/2008-07/msg00387.html,
> the new technique for generating s-oscons.ads does not work
> for RTEMS. The OS .h files are not available when the compiler
> is built -- only those strictly owned by the newlib C library.
>
> As indicated by this from the build
* Arnaud Charlet, 2008-08-07 :
> > As I warned in http://gcc.gnu.org/ml/gcc/2008-07/msg00387.html,
> > the new technique for generating s-oscons.ads does not work
> > for RTEMS. The OS .h files are not available when the compiler
> > is built -- only those strictly owned by the newlib C library.
Snapshot gcc-4.3-20080807 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080807/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Ian Lance Taylor wrote on 07 August 2008 19:20:
> If the test will run on most normal targets, then a better approach is
> to add something like
>
> #if defined(STACK_SIZE) && STACK_SIZE < 1000
> exit (0); /* or "return 0" from main, as appropriate"
> #endif
:) Actually, it's a compile test
"Dave Korn" <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor wrote on 07 August 2008 19:20:
>
>> If the test will run on most normal targets, then a better approach is
>> to add something like
>>
>> #if defined(STACK_SIZE) && STACK_SIZE < 1000
>> exit (0); /* or "return 0" from main, as appropria
compiler error)
FAIL: gcc.c-torture/unsorted/conv.c, -Os (internal compiler error)
FAIL: gcc.c-torture/unsorted/conv_tst.c, -Os (internal compiler error)
These are showing up in gcc.log as below.
Jack
Executing on host:
/sw/src/fink.build/gcc44-4.3.999-20080807
On Thu, Aug 7, 2008 at 8:47 PM, Jack Howarth <[EMAIL PROTECTED]> wrote:
> Is anyone else seeing some new internal compiler errors in the gcc
> testsuite on i686-apple-darwin9? I am using the same graphite patch
> I used a couple days back with the current svn of gcc trunk and now
> I see failures
Eric,
Thanks for looking into this. FYI, the problem also occurs in...
FAIL: gcc.dg/torture/fp-int-convert-double.c -Os (internal compiler error)
FAIL: gcc.dg/torture/fp-int-convert-double.c -Os (test for excess errors)
WARNING: gcc.dg/torture/fp-int-convert-double.c -Os compilation faile
On Thu, Aug 7, 2008 at 9:13 PM, Jack Howarth <[EMAIL PROTECTED]> wrote:
> Eric,
> Thanks for looking into this. FYI, the problem also occurs in...
>
> FAIL: gcc.dg/torture/fp-int-convert-double.c -Os (internal compiler error)
> FAIL: gcc.dg/torture/fp-int-convert-double.c -Os (test for excess
On Thu, Aug 7, 2008 at 9:24 PM, Eric Christopher <[EMAIL PROTECTED]> wrote:
> Looks rather fishy that they're all at -Os. I'd look at things that
> went in recently
> that would have affected that.
>
Most likely http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00355.html .
Thanks,
Andrew Pinski
On Thu, Aug 7, 2008 at 9:13 PM, Jack Howarth <[EMAIL PROTECTED]> wrote:
> Eric,
> Thanks for looking into this. FYI, the problem also occurs in...
>
> FAIL: gcc.dg/torture/fp-int-convert-double.c -Os (internal compiler error)
> FAIL: gcc.dg/torture/fp-int-convert-double.c -Os (test for excess
> Please open a bug report. They also fail on Linux with SSE fpmath:
>
>
That'd be why they fail on darwin then - we default to sse2 :)
-eric
> As an alternative to Arno's suggestion, maybe you could use the
> --with-sysroot configure parameter to make the required headers
> available to the build process. I know others have used this method on
> some cross targets.
Another (at least short term) solution would be to use
DUMMY_SOCKETS_TA
35 matches
Mail list logo
