Re: Is PR21674 really fixed for gcc 4.2?
> 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 the xfail > line be dropped now from those two test cases for the gcc 4.2 release? It is expected that these tests fail. Ie: %COMP.sh "-g -O0 -D_GLIBCXX_DEBUG" 21_strings/basic_string/element_access/char/21674.cc %./a.out /mnt/share/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:709: typename _Alloc::rebind<_CharT>::other::reference std::basic_string<_CharT, _Traits, _Alloc>::operator[](typename _Alloc::rebind<_CharT>::other::size_type) [with _CharT = char, _Traits = std::char_traits, _Alloc = std::allocator]: Assertion '__pos <= size()' failed. Abort Thus, the xfail marking. If this is not asserting on darwin, then something is wrong and this particular test is failing. -benjamin
rtl to asm conversion in scheduler
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 by a single instruction (ie ADDU or something) for chosing the right candidate in the ready-list. For instructions that are represented by patterns evaluating to more lines of asm-code it would be necessary to get at least the very first and the last opcode. It would be best to have all opcodes for sure. In its final pass gcc-3.2.3 emits assembly code using functions in final.c. As far as I have seen the work is always done for a single function at once using the following calls (main.c)main --> (toplev.c)toplev_main --> (toplev.c)do_compile --> (toplev.c)compile-file --> (c-parse.c)yyparse --> then ie: (c-decl.c)finish_function --> (c-decl.c)c_expand_body --> (toplev.c)rest_of_compilation --> where there are several passes and in the end: (final.c)final --> (final.c)final_scan_insn I would need something similar for outputting a single instruction such that the internal representation of the program being parsed is not hurt. It seems that I somehow need that functionality or some suitable macro for use within the scheduler. Somehow I will have to invoke the output part of the patterns assigned to an 'rtx insn', but I just can't figure out how to do that. A Macro returning some char* would be fine; or some function that writes to Disk (not to asm_out_file but somewhere else) would still do the job. Please feel free to correct mistakes I have made in the description above; I did not find too much documentation regarding that problem. Thanks a lot, Philipp Glatz. -- Philipp Maria Glatz student of telematics @ TUGraz [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: rtl to asm conversion in scheduler
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 instructions that are represented by patterns evaluating to more lines of asm-code it would be necessary to get at least the very first and the last opcode. It would be best to have all opcodes for sure. Insns can still be split after scheduling, which makes it a bit problematic to know which opcode will be produced. You can use an attribute for that: what most GCC schedulers do is have an attribute that maps to the functional unit where the instruction goes, and then define an automaton that specifies the latency, the length of each functional unit's reservations and so on. However, I suggest that you use a newer version because I don't think this technique was available in 3.2.3 (and the old-style scheduler descriptions were removed in 4.0 after all the descriptions were upgraded). Paolo
Re: rtl to asm conversion in scheduler
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) for chosing the right candidate in > the ready-list. For instructions that are represented by patterns > evaluating to more lines of asm-code it would be necessary to get at > least the very first and the last opcode. It would be best to have all > opcodes for sure. Insns can still be split after scheduling, which makes it a bit problematic to know which opcode will be produced. You can use an attribute for that: what most GCC schedulers do is have an attribute that maps to the functional unit where the instruction goes, and then define an automaton that specifies the latency, the length of each functional unit's reservations and so on. However, I suggest that you use a newer version because I don't think this technique was available in 3.2.3 (and the old-style scheduler descriptions were removed in 4.0 after all the descriptions were upgraded). Paolo Thanks for your answer. Unfortunately I cannot switch to a newer version as I am building a Crosscompiler for mips with the crosstool-0.42 from Dan Kegel. On my Host only few versions (all around 3.2.3) can be built. As you mentionend, insns can still be split after scheduling: If the opcode that is retrieved is not correct all the time; that would not be a problem if it still gives 'good' results that are correct most of the time. If results are differently good for different programs that would still be fine. The information that is given by the name of the opcode would be used later on to do analysis in heuristics and these heuristics are not supposed to give exact results, but they should show trends. BTW: I have done manual 'evaluation' of the output patterns in mips.md by simply hardcoding an array for each of the 335 patterns and mapping it to opcodes for which i thought that they could be produced by the pattern, but this does not give results that are 'good enough' for the heuristics. So, if there were any macro or anything that tells me which asm or which asms could come out of an rtx it would be fine. Any ideas for gcc-3.x (esp. gcc-3.2.3)? Regards, Philipp. -- Philipp Maria Glatz student of telematics @ TUGraz [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Is PR21674 really fixed for gcc 4.2?
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 little unclear on the correct approach. Jack
LTO (link time optimisation) branch (and IPO)?
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 Author: sandra Last Changed Rev: 116947 Last Changed Date: 2006-09-14 17:17:36 +0200 (Thu, 14 Sep 2006) Is there some common work or ideas between LTO (link time optimisation) and IPO (inter procedural optimisation) branches? Regards -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet aliases: basiletunesorg = bstarynknerimnet 8, rue de la Faïencerie, 92340 Bourg La Reine, France
Re: LTO (link time optimisation) branch (and IPO)?
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
Re: LTO (link time optimisation) branch (and IPO)?
> 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 Basile> Revision: 117025 Basile> Node Kind: directory Basile> Schedule: normal Basile> Last Changed Author: sandra Basile> Last Changed Rev: 116947 Basile> Last Changed Date: 2006-09-14 17:17:36 +0200 (Thu, 14 Sep 2006) How does an update a few days ago translate into inactive? The information you posted answers your own question. Basile> Is there some common work or ideas between LTO (link time optimisation) and Basile> IPO (inter procedural optimisation) branches? I assume you mean IPA branch. The IPA branch is waiting for Stage 1 of GCC development to merge features into mainline. David
Re: Darwin doesn't install libgcjgc from boehm-gc
> "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 pulled into libgcj but not installed on its own. Tom
Re: Merging identical functions in GCC
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 (*)(int)) foo != (int (*)(int)) bar);
}
Both foo and bar get put in their own COMDAT section and their
RTL and assembly are the same, but it's not safe to merge them.
Merge can be safely done like this:
If both functions A and B are not inlined functions, and they have single
entry points, and memcmp of their asm code is zero, and the code is large
enough, then the asm code of the functions B is replaced by "jmp A" instruction.
Regards,
Roman
MIPS exception handling is broken...
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 I don't think it is just my problem. A month ago everything was working well, so I don't know what happened. I have tracked the problem down to the fact that GCC is generating unwind data with absolute addressing, but when ld links the runtime libraries, it is trying to convert to PC relative addressing and screwing up the .eh_frame data in the process. I posted a message to the binutils list showing the problem: http://sourceware.org/ml/binutils/2006-09/msg00131.html In the next few days I may try to track down the offending patches, but if anyone has any pointers they are of course welcome. David Daney.
XPASS: gfortran.dg/vect/vect-5.f90 on PPC64
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 loops 1 XPASS: gfortran.dg/vect/vect-5.f90 -O scan-tree-dump-times Alignment of access forced using peeling 1 XPASS: gfortran.dg/vect/vect-5.f90 -O scan-tree-dump-times Vectorizing an unaligned access 2 I see the same behavior for x86_64 but not for ia64. The sparc64-sun-solaris2.10 only shows... XPASS: gfortran.dg/vect/vect-5.f90 -O scan-tree-dump-times vectorized 2 loops 1 Again, I am mainly interested to know if passing these tests on PPC64 is a good thing or indicative of a regression. Jack
Re: Merging identical functions in GCC
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 multiple entry points for a function, which will give some platforms fits, but, oh well. Further, the optimizer can do enough analysis to squeeze out some of the nops, some of the time. This should be slightly better than the jmp scheme Roman proposed.
Re: Is PR21674 really fixed for gcc 4.2?
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 a test that is supposed to fail before so I'm a little unclear on the correct approach. I'd just state it as plainly as in this thread and maybe a link to Benjamin's reply... Oh course, the more digesting of the results, like explaining why it fails to fail, would make the bug report even better.
Re: XPASS: gfortran.dg/vect/vect-5.f90 on PPC64
>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 loops 1 > XPASS: gfortran.dg/vect/vect-5.f90 -O scan-tree-dump-times > Alignment of access forced using peeling 1 > XPASS: gfortran.dg/vect/vect-5.f90 -O scan-tree-dump-times > Vectorizing an unaligned access 2 > > I see the same behavior for x86_64 but not for ia64. > The sparc64-sun-solaris2.10 only shows... > > XPASS: gfortran.dg/vect/vect-5.f90 -O scan-tree-dump-times > vectorized 2 loops 1 > > Again, I am mainly interested to know if passing these tests on PPC64 > is a good thing or indicative of a regression. It's a good thing :-) Looks like lp64 should be removed from the xfail. That's why ppc64 and x86_64 XPASS on all three checks. sparc64 XPASSes only the first check (and not the other two alignment related checks) because it is a "vect_no_align" target. For the same reason ia64 doesn't have the two alignment related XPASSes. It remains to understand why ia64 still fails to vectorize the 2 loops - potentially this is not ilp64 related. Do you have the dump file generated by -fdump-tree-vect-details on ia64 for this testcase? dorit >Jack
Re: XPASS: gfortran.dg/vect/vect-5.f90 on PPC64
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-details on ia64 for
gfortran.dg/vect/vect-5.f90.
Jack
ps for now I guess we can just adjust the test along
these lines...
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 } } } }
+! { dg-final { scan-tree-dump-times "vectorized 2 loops" 1 "vect" { xfail {
target {lp64 && !{powerpc-*-darwin*} && !{x86_64-*-*}} } } } }
! { dg-final { scan-tree-dump-times "Alignment of access forced using peeling"
1 "vect" { xfail { vect_no_align || lp64 } } } }
! { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect"
{ xfail { vect_no_align || lp64 } } } }
! { dg-final { scan-tree-dump-times "Alignment of access forced using
versioning." 3 "vect" { target { ilp32 && vect_no_align } } } }
Re: XPASS: gfortran.dg/vect/vect-5.f90 on PPC64
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 } } } }
+! { dg-final { scan-tree-dump-times "vectorized 2 loops" 1 "vect" { xfail {
target {lp64 && !{powerpc*-*-*} && !{x86_64-*-*}} } } } }
! { dg-final { scan-tree-dump-times "Alignment of access forced using peeling"
1 "vect" { xfail { vect_no_align || lp64 } } } }
! { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect"
{ xfail { vect_no_align || lp64 } } } }
! { dg-final { scan-tree-dump-times "Alignment of access forced using
versioning." 3 "vect" { target { ilp32 && vect_no_align } } } }
and likewise for the next two tests as well.
Jack
Re: Why test objc at -m64 for Darwin8?
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).
Re: MIPS exception handling is broken...
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 similar results. So I don't think it is just my problem. A month ago everything was working well, so I don't know what happened. I have tracked the problem down to the fact that GCC is generating unwind data with absolute addressing, but when ld links the runtime libraries, it is trying to convert to PC relative addressing and screwing up the .eh_frame data in the process. I posted a message to the binutils list showing the problem: http://sourceware.org/ml/binutils/2006-09/msg00131.html In the next few days I may try to track down the offending patches, but if anyone has any pointers they are of course welcome. svn r116604 is the culprit: 2006-08-31 Roger Sayle <[EMAIL PROTECTED]> PR other/22313 * dwarf2out.c (add_fde_cfi): Use a set_loc if the current label is NULL, otherwise use an advance_loc4 to adjust relative to the current label. (output_cfi) : Update the current label. (dwarf2out_switch_text_section): Reset the current label to avoid using advance_loc4 over section boundaries. I just posted a reply to Roger on gcc-patches. David Daney.
Re: Merging identical functions in GCC
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, that will work. But, in practice, people will also want the mode where you do not insert the nops, and just accept that some functions compare equal when they shouldn't. So, we should have a switch for that mode too. I think it's reasonable -- a priori -- to consider doing this optimization in both the compiler and in the linker. In the compiler, when generating a single object file, eliminate duplicates. In the linker, when linking stuff, we can do it again. I don't think we can know how much bang comes from either approach without measuring some sample programs. Pick a random application (maybe an KDE office application?) and measure how many functions, if any, in the final link image are duplicates. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Missing elements in VECTOR_CST
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 produce a VECTOR_CST with just two
elements instead of 4. Should we always have the same number of
elements in a VECTOR_CST as there are elements in the vector type?
I think it is reasonable for front-ends to elide initializers and to
follow the usual C semantics that elided initializers are (a) zero, if
the constant is appearing as an initializer for static storage, or (b)
unspecified, "random" values elsewhere.
Requiring explicit zeros is just a way to take up memory. We clearly
wouldn't want to do it for big arrays, and I think we might as well
treat vectors the same way, since we already need logic to handle the
implicit zeros in the back end for arrays and structures.
The counter-argument is that front ends should be explicit. However,
explicit doesn't need to mean verbose; as long as we specify the
semantics I give above, eliding the elements is still perfectly clear.
This is why PR 29091 is failing currently. output_constant assumes
VECTOR_CST have the correct number of elements but the C front-end via
digest_init creates a VECTOR_CST with only 2 elements.
Thus, I think that output_constant should be changed to add the
additional zeros.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
RE: pr27650 - dllimport of virtual methods broken.
> 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 unset DECL_DLLIMPORT_P (and remove the
> attribute
> > as well) there?
>
> Ah, right, good point. I always forget that case,.partly because I
> really think that processing should be done when the function is
> declared. We can know whether it's virtual at that point, so
> I think we
> should. But, that's not how things work now. :-(
>
> So, perhaps the best place would be in check_for_override. That's
> called for all methods when the class is complete.
>
Revised patch.
Tested on i686-pc-mingw32
Danny
cp/ChangeLog
PR target/27650
* class.c (check_for_override): Remove dllimport from virtual
methods.
testsuite/Changelog
PR target/27650
* g++.dg/ext/dllimport12.C: New file.
Index: cp/class.c
===
*** cp/class.c (revision 117005)
--- cp/class.c (working copy)
*** check_for_override (tree decl, tree ctyp
*** 2342,2347
--- 2342,2357
if (!DECL_VINDEX (decl))
DECL_VINDEX (decl) = error_mark_node;
IDENTIFIER_VIRTUAL_P (DECL_NAME (decl)) = 1;
+ if (DECL_DLLIMPORT_P (decl))
+ {
+ /* When we handled the dllimport attribute we may not have
known
+that this function is virtual We can't use dllimport
+semantics for a virtual method because we need to
initialize
+the vtable entry with a constant address. */
+ DECL_DLLIMPORT_P (decl) = 0;
+ DECL_ATTRIBUTES (decl)
+ = remove_attribute ("dllimport", DECL_ATTRIBUTES (decl));
+ }
}
}
Index: testsuite/g++.dg/ext/dllimport12.C
===
*** testsuite/g++.dg/ext/dllimport12.C (revision 0)
--- testsuite/g++.dg/ext/dllimport12.C (revision 0)
***
*** 0
--- 1,22
+ // PR target/27650
+ // Don't use dllimport semantics on virtual methods
+ // { dg-do compile { target i?86-*-cygwin* i?86-*-mingw*} }
+
+ // Don't import explicitly virtual method.
+ struct base
+ {
+ virtual void key_method();
+ __attribute__((dllimport)) virtual ~base();
+ };
+
+ void base::key_method() {}
+
+
+ // Nor an implicitly virtual method.
+ struct derived : public base
+ {
+ void key_method();
+ __attribute__((dllimport)) ~derived();
+ };
+
+ void derived::key_method() {}
Re: Merging identical functions in GCC
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 way important inequalities still work. As a convenient side-effect, setting breakpoints on only one variant will also still work. -- (let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map ((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l)) (lambda (f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l)) (C k)))'((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)
Re: Merging identical functions in GCC
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 > >variant2: nop > >variant3: nop > >[ ... ] > > > >this way important inequalities still work. > > Yes, that will work. But, in practice, people will also want the mode > where you do not insert the nops, and just accept that some functions > compare equal when they shouldn't. So, we should have a switch for that > mode too. It certainly is true that if we generate one set of routines for vector, vector, and vector for all T, a program that uses them all could have a lot of nops. But there's another possibility: we can implement the variants as inline functions that call the common implementation. If the address of the function is not taken in a given file, we can make a direct call. If the address is taken, we need an "outlined" copy of the function. These out-of-line copies can be handled in the usual linkonce/COMDAT way, so that they resolve to one copy. So it seems that just having address-taking block inlining suffices.
how to combine make check options?
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
-m32 and -m64 testsuite runs will occur that both also
use -fgnu-runtime. Thanks in advance or any suggestions.
Jack
Re: how to combine make check options?
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_board="unix{,-m64}"'
>
> However I don't see how to combine this so that both
> -m32 and -m64 testsuite runs will occur that both also
> use -fgnu-runtime. Thanks in advance or any suggestions.
I've used this:
RUNTESTFLAGS="--verbose --verbose --target_board=unix'{-m32,-m64}{-DDBG=1}'"
Janis
Re: Merging identical functions in GCC
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, only breakpoints at the start of the function would `work'.
.
Re: Merging identical functions in GCC
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, including through >shared libs. I hope that doesn't include global functions like list::sort() and list::sort(), otherwise your optimization is pretty much useless. If your optimization does merge such functions then you're still left with the problem that their member function pointers might be compared in another compilation unit. Ross Ridge
Re: .
maybe add a filter for messages that are way to short or just plain empty ;-) On 9/19/06, . <[EMAIL PROTECTED]> wrote:
what is ip , fp registers ?
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 difference between pc & ip ? regards Chandan
