> 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
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
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
> # I'm not trying to dereference any of these nonstandard pointers.
Not *now*. I'd like to in the future.
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
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.
>
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
-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
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 -
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
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
>
>
> 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
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
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
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
... 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...
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
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 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, 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: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
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
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
>
> 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
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
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
>
>
> 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
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
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
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
30 matches
Mail list logo
