> 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
>
> in the libstdc++ testsuite. From what I see in bugzilla for PR21674, it
> seems that it should be fixed on gcc trunk, right? Shouldn't t
Hello!
I have a question regarding the Haifa Scheduler in gcc-3.2.3 and your
help would be
very appreciated.
Goal: I would need to get the assembly representation for a single
instruction in haifa-sched.c. The reason for this is that it would be
important to get the opcode which will be produced
Goal: I would need to get the assembly representation for a single
instruction in haifa-sched.c. The reason for this is that it would be
important to get the opcode which will be produced by a single
instruction (ie ADDU or something) for chosing the right candidate in
the ready-list. For instru
On 9/18/06, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> Goal: I would need to get the assembly representation for a single
> instruction in haifa-sched.c. The reason for this is that it would be
> important to get the opcode which will be produced by a single
> instruction (ie ADDU or something)
Benjamin,
So does the fact that 21_strings/basic_string/element_access/char/21674.cc
and 21_strings/basic_string/element_access/wchar_t/21674.cc now XPASS merit
a PR? What sort of debug information should I provide. I've never filed a
bug report on a test that is supposed to fail before so I'm a
Dear All,
Is the LTO branch inactive now? This surprises me! svn info gives me
Path: .
URL: svn://gcc.gnu.org/svn/gcc/branches/lto
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 117025
Node Kind: directory
Schedule: normal
Last Changed
On Mon, Sep 18, 2006 at 04:36:26PM +0200, Basile STARYNKEVITCH wrote:
> Is the LTO branch inactive now? This surprises me! svn info gives me
Why do you think a data of last Thursday means it is inactive? It
isn't, as you can see if you follow gcc-patches.
--
Daniel Jacobowitz
CodeSourcery
> Basile STARYNKEVITCH writes:
Basile> Is the LTO branch inactive now? This surprises me! svn info gives me
Basile> Path: .
Basile> URL: svn://gcc.gnu.org/svn/gcc/branches/lto
Basile> Repository Root: svn://gcc.gnu.org/svn/gcc
Basile> Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Basi
> "Jack" == Jack Howarth <[EMAIL PROTECTED]> writes:
Jack> Has anyone noticed that on Darwin PPC we are building
Jack> the shared library libgcjgc.1.0.2.dylib in the boehm-gc
Jack> subdirectory but it never is installed? Isn't this a bug?
We build the GC as a convenience library. It is p
On 09/15/2006 04:32 PM, Ross Ridge wrote:
Also, I don't think it's safe if you merge only functions in COMDAT
sections.
Consider:
#include
template T foo(T a) { return a; }
template T bar(T a) { return a; }
int
main() {
assert((int (*
Has anyone else noticed that the mipsel-linux-gnu target is generating
bad .eh_frame data lately?
I am running mipsel-linux-gcc (GCC) 4.2.0 20060914 (experimental) which
is svn r116953
I also notice that
http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg00922.html
Shows similar results. So
Does anyone know if the fact that the gfortran.dg
test case vect/vect-5.f90 is now showing a XPASS on
indicates a regression? All three dg-final options that
are marked to fail at lp64 now pass.
Running target unix/-m64
XPASS: gfortran.dg/vect/vect-5.f90 -O scan-tree-dump-times vectorized 2 l
On Sep 15, 2006, at 2:32 PM, Ross Ridge wrote:
Also, I don't think it's safe if you merge only functions in COMDAT
sections.
Sure it is, one just needs to merge them as:
variant1: nop
variant2: nop
variant3: nop
[ ... ]
this way important inequalities still work. This requires multi
On Sep 18, 2006, at 6:32 AM, Jack Howarth wrote:
So does the fact that 21_strings/basic_string/element_access/
char/21674.cc
and 21_strings/basic_string/element_access/wchar_t/21674.cc now
XPASS merit
a PR? What sort of debug information should I provide. I've never
filed a
bug report on
>Does anyone know if the fact that the gfortran.dg
> test case vect/vect-5.f90 is now showing a XPASS on
> indicates a regression? All three dg-final options that
> are marked to fail at lp64 now pass.
>
> Running target unix/-m64
> XPASS: gfortran.dg/vect/vect-5.f90 -O scan-tree-dump-times
Dorit,
I only have access to Darwin PPC at -m64 and
x86_64. However I have only been directly testing
Darwin PPC at -m64 and relying on the gcc-testresults
mailing list archive for the rest of the architectures.
Perhaps someone else here can provide a dump file
generated by -fdump-tree-vect-det
Opps. I meant...
Index: vect-5.f90
===
--- vect-5.f90 (revision 117033)
+++ vect-5.f90 (working copy)
@@ -35,7 +35,7 @@
stop
end
-! { dg-final { scan-tree-dump-times "vectorized 2 loops" 1 "vect" { xfail {
lp64
On Sep 16, 2006, at 10:18 AM, Jack Howarth wrote:
Shouldn't we have something in gcc/testsuite/lib/objc*.exp
to short-circuit out of running any of those -m64 testsuites
for Darwin8 and earlier?
Sure. Bonus points for letting the GNU runtime based tests run (if
that makes sense).
David Daney wrote:
Has anyone else noticed that the mipsel-linux-gnu target is generating
bad .eh_frame data lately?
I am running mipsel-linux-gcc (GCC) 4.2.0 20060914 (experimental) which
is svn r116953
I also notice that
http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg00922.html
Shows s
Mike Stump wrote:
On Sep 15, 2006, at 2:32 PM, Ross Ridge wrote:
Also, I don't think it's safe if you merge only functions in COMDAT
sections.
Sure it is, one just needs to merge them as:
variant1: nop
variant2: nop
variant3: nop
[ ... ]
this way important inequalities still work.
Yes,
Andrew Pinski wrote:
The documention on VECTOR_CST is not clear if we can have missing
elements in that the remaining elements are zero. Right we produce such
VECTOR_CST for things like:
#define vector __attribute__((vector_size(16) ))
vector int a = {1, 2};
But is that valid? We currently pro
> From: Mark Mitchell [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 14, 2006 3:38 PM
> Danny Smith wrote:
>
> > The problem I had was with the second case below. We don't
> know if a
> > method is implicitly virtual until search.c:look_for_overrides_r).
> > Would t be better to unse
Mike Stump <[EMAIL PROTECTED]> writes:
> On Sep 15, 2006, at 2:32 PM, Ross Ridge wrote:
>> Also, I don't think it's safe if you merge only functions in COMDAT
>> sections.
>
> Sure it is, one just needs to merge them as:
>
> variant1: nop
> variant2: nop
> variant3: nop
> [ ... ]
>
> this wa
On Mon, Sep 18, 2006 at 12:09:36PM -0700, Mark Mitchell wrote:
> Mike Stump wrote:
> >On Sep 15, 2006, at 2:32 PM, Ross Ridge wrote:
> >>Also, I don't think it's safe if you merge only functions in COMDAT
> >>sections.
> >
> >Sure it is, one just needs to merge them as:
> >
> >variant1: nop
> >var
Is it possible to combine different options together when
running the testsuite? For example I can run...
make check-objc RUNTESTFLAGS="--target_board=unix/-fgnu-runtime"
and
make check-objc RUNTESTFLAGS='--target_board="unix{,-m64}"'
However I don't see how to combine this so that both
-m3
On Mon, Sep 18, 2006 at 07:49:51PM -0400, Jack Howarth wrote:
> Is it possible to combine different options together when
> running the testsuite? For example I can run...
>
> make check-objc RUNTESTFLAGS="--target_board=unix/-fgnu-runtime"
>
> and
>
> make check-objc RUNTESTFLAGS='--target_
On Sep 18, 2006, at 4:17 PM, Jed Davis wrote:
As a convenient side-effect, setting breakpoints on only one variant
will also still work.
Well, not quite. For it to work nicely, you'd want the jmp version,
and you'd want to defeat the gdb set breakpoint after prologue logic,
and even then,
Daniel Berlin writes
>Please go away and stop trolling.
I'm not the one who's being rude and abusive.
>If your concern is function pointers or global functions, you can
>never eliminate any global function, unless your application doesn't
>call dlopen, or otherwise load anything dynamically, incl
maybe add a filter for messages that are way to short or just plain empty ;-)
On 9/19/06, . <[EMAIL PROTECTED]> wrote:
Hi
I am doing the assembly coding in ARM7TDMI and using the GNU Assembler.
In GNU ARM Assembler Quick Reference, I found 2 register Names which I
am not able to understand, they are ip & fp.
Can anybody explain me about these registers & to which registers are
they mapped.
what is the differen
31 matches
Mail list logo
