On Aug 17, 2006, at 5:43 PM, Mike Stump wrote:
On Aug 17, 2006, at 4:26 PM, Jack Howarth wrote:
I assume the linker is choking on the line...
.stabs "i:G(0,3)",32,0,4,0
...right?
Yes. The linker is complaining that there is no _i in the program.
If you add one, it would have wor
On Aug 17, 2006, at 4:26 PM, Jack Howarth wrote:
I assume the linker is choking on the line...
.stabs "i:G(0,3)",32,0,4,0
...right?
Yes. The linker is complaining that there is no _i in the program.
If you add one, it would have worked. I'm asking our linker and
debugger peopl
FX,
That was spot on. If I reduce the test case down to...
! { dg-do run }
! Program to test ASSIGNing a label to common variable. PR18827.
program test
integer i
common i
end
I still get the linkage error...
gfortran -O3 -g -m64 assign.f90
can't find atom for N_GSYM s
>
>
> Two part question:
>
> 1) Does the control flow graph exist at the time we're emitting assembler
> instructions?
Not really because we delete the CFG because some passes right after the last
scheduling does not understand CFG (reorg is one example).
Thanks,
Andrew Pinski
Snapshot gcc-4.0-20060817 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060817/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Aug 8, 2006, at 5:56 AM, Andrew Haley wrote:
Juerg Lehni writes:
I compiled the lastest GCJ from SVN head today, and when linking to
my application that uses JNI invocation and worked well before, I
recieved a "undefined symbols" error about _JNI_CreateJavaVM and
_JNI_GetDefaultJavaVMInitArgs
>
> Two part question:
>
> 1) Does the control flow graph exist at the time we're emitting
assembler
> instructions?
>
> 2) If so, how do I go at getting at the basic block info, specifically
> successor info, if the only thing I have is a rtx for a conditional jump
> insn?
>
>
> Okay, maybe a 3-p
Two part question:
1) Does the control flow graph exist at the time we're emitting assembler
instructions?
2) If so, how do I go at getting at the basic block info, specifically
successor info, if the only thing I have is a rtx for a conditional jump
insn?
Okay, maybe a 3-part question. Give
Paolo,
I would argue that if the failures are targeted at Darwin8,
which is MacOS X 10.4, and the problems are resolved in a
later point release like 10.4.7, they should be marked as
as passing. The point releases on MacOS X are free and contain
essential security fixes. Encouraging users to not
On Aug 17, 2006, at 11:42 AM, Jack Howarth wrote:
Well, I note sure how to handle some of these testcases. For
instance,
1_strings/basic_string/element_access/char/21674.cc has...
// { dg-require-debug-mode "" }
// { dg-options "-O0 -D_GLIBCXX_DEBUG" }
// { dg-do run { xfail *-*-* } }
Wel
On Thu, Aug 17, 2006 at 12:26:12PM -0700, Mike Stump wrote:
> On Aug 17, 2006, at 11:57 AM, Joe Buck wrote:
> >Can the test framework distinguish based on the OS release?
>
> Yes. It's a fundamental feature:
>
> set host_triplet powerpc-apple-darwin9.0.0d1
> set build_triplet powerpc-apple-darwi
On Aug 17, 2006, at 11:57 AM, Joe Buck wrote:
Can the test framework distinguish based on the OS release?
Yes. It's a fundamental feature:
set host_triplet powerpc-apple-darwin9.0.0d1
set build_triplet powerpc-apple-darwin9.0.0d1
set target_triplet powerpc-apple-darwin9.0.0d1
set target_alias
On Thu, 17 Aug 2006, Zdenek Dvorak wrote:
> here is the updated patch.
Hi Zdenek, some lines look a bit long, would you mind reformatting
(Emacs has a nice automated mode, for example) before committing?
Gerald
On Thu, Aug 17, 2006 at 08:51:04PM +0200, Paolo Carlini wrote:
> ... just an obvious remark, then I leave the issue to the darwin
> maintainers, of course: if some, probably most, of those XPASS are
> because of a more recent release of the OS, and the previous ones are
> still widespread and su
... just an obvious remark, then I leave the issue to the darwin
maintainers, of course: if some, probably most, of those XPASS are
because of a more recent release of the OS, and the previous ones are
still widespread and supported, I'm not sure you really want to see
FAILs on the latter...
Mike,
Well, I note sure how to handle some of these testcases. For instance,
1_strings/basic_string/element_access/char/21674.cc has...
// { dg-require-debug-mode "" }
// { dg-options "-O0 -D_GLIBCXX_DEBUG" }
// { dg-do run { xfail *-*-* } }
...which I assume implies that it really should only
The bug hits about 38 other test in gfortran. These include...
FAIL: gfortran.dg/actual_array_constructor_1.f90 -O3 -g (test for excess
errors)
FAIL: gfortran.dg/assign.f90 -O3 -g (test for excess errors)
[...SNIP...]
Just in case, you can detect any sort of pattern from that set of
tests
On Aug 16, 2006, at 10:41 PM, Jack Howarth wrote:
We have accumulated five XPASS instances in the libstdc++
testsuite on MacOS X...
XPASS: 21_strings/basic_string/element_access/char/21674.cc
execution test
XPASS: 21_strings/basic_string/element_access/wchar_t/21674.cc
execution test
>
>
> Pat Haugen <[EMAIL PROTECTED]> wrote on 08/08/2006 11:07:58 AM:
>
> > Jan Hubicka <[EMAIL PROTECTED]> wrote on 08/08/2006 01:04:33 AM:
> >
> > > The code there is basically avoiding loops with many exists to be
> > > predicted to not loop at all (ie if you have 10 exits, having every
> exi
Here is the documentation for the data dependence analysis.
@node Dependency analysis
@section Data Dependency Analysis
@cindex Data Dependency Analysis
The code for the data dependence analysis can be found in
@file{tree-data-ref.c} and its interface and data structures are
described in @file{t
Mark Mitchell wrote:
>I think you really have to accept that the change you want to make goes
>to a relatively fundamental invariant of C++.
I don't see how you can call this a realatively fundamental invariant
of C++, given how various C++ implementations have supported multiple
pointer sizes for
Bernd Jendrissek wrote:
> May I jog your memory about "named address spaces". Are "near" and
> "far" pointers something that might be able to be shoehorned into any
> [future] infrastructure for supporting these named address spaces? Same
> for DJ's oddball pointers - could they fit?
Maybe so -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Aug 17, 2006 at 07:35:58AM -0700, Mark Mitchell wrote:
> If you're willing to use integers, you'll have an easy time. If you
> want the more elegant language semantics of multiple pointer sizes,
> you'll have to take the time to read through t
DJ Delorie wrote:
> At the moment, there are no language issues to resolve.
No, rather, at the moment there is a class of programs which are
accidentally accepted by the C++ front end and happen to do some of the
things that you want. That is different from saying that the compiler
supports the
Hello,
> >> Apologies for the previous incomplete reply. Here's the rest of the
> >> comments I had for this patch.
> >
> > here is the updated patch. Daniel, did you write something regarding
> > the lambda framework, or should I do it?
>
> I've attached a modified version with lambda docs.
>
Zdenek Dvorak wrote:
> Hello,
>
>> Apologies for the previous incomplete reply. Here's the rest of the
>> comments I had for this patch.
>
> here is the updated patch. Daniel, did you write something regarding
> the lambda framework, or should I do it?
I've attached a modified version with lam
> # I'm not trying to dereference any of these nonstandard pointers.
Not *now*. I'd like to in the future.
Utilisation des specs internes.
Target: i686-pc-linux-gnu
Configuré avec: ../gcc-4.1.1/configure
--prefix=/users/home/anpichot/downloads/gccvishnubuild/vishnu
Modèle de thread: posix
version gcc 4.1.1
i686-pc-linux-gnu
SuSE Linux 9.2 (i586)
kernel : 2.6.8-24.20-default
glibc-2.3.3-118
DJ Delorie <[EMAIL PROTECTED]> writes:
| > Good! In that case, you don't need them to be pointers at all. :-)
| >
| > I think you should just declare them as integer types.
|
| That makes initializing function pointers messy.
|
| Besides, they're not integers. They're pointers. I'd *like* to
> Sure, it would be nice if these things were pointers.
At the moment, they are.
> However, I will reject any patch to support these alternative
> pointers in C++ until all the language issues have been resolved.
At the moment, there are no language issues to resolve. The only
thing people we
30 matches
Mail list logo
