Re: extern const and all that
Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > gensupport.c:1122: undefined reference to `insn_elision_unavailable' > gensupport.c:975: undefined reference to `n_insn_conditions' > gensupport.c:977: undefined reference to `insn_conditions' > collect2: ld returned 1 exit status > > > This is an instance of the situations I reported earlier. > Of course, your suggestion is the natural choice, if we did not have > addiional constraint. Indeed, the file (for MD gen-support machinery) > that defines those variables is dummy-conditions.c, with the following > comment: > > /* In order to avoid dragging in all the headers that are needed to >declare things that gensupport.h uses, we duplicate the declaration >of struct c_test here. (In particular we do not want to have to >include tm.h nor rtl.h in this file.) */ > > Given that constraint, it appears to me that putting "extern" in the > definition is the minimal, viable solution. How about creating a new header, call it gen-ctest.h, that just contains the definition of struct c_test, and external declarations for the three constants defined by dummy-conditions.c. dummy-conditions.c can include that, and so can gensupport.h. zw
How to check for MMX registers in function call?
Hello!
A sse function that gets its parameters via xmm regs and returns its result in
xmm reg is defined as:
__m128
func_sse (__m128 x, __m128 y)
{
__m128 xmm;
xmm = _mm_add_ss (x, y);
return xmm;
}
The RTL code that is used to call this function is produced as:
(call_insn/u:HI 30 29 31 0 (set (reg:V4SF 21 xmm0)
(call (mem:QI (symbol_ref:SI ("func_sse") [flags 0x3] ) [0 S1 A8])
(const_int 0 [0x0]))) 529 {*call_value_0} (insn_list:REG_DEP_TRUE 28
(insn_list:REG_DEP_TRUE 29 (nil)))
(insn_list:REG_RETVAL 28 (expr_list:REG_DEAD (reg:V4SF 22 xmm1 [ xmm1 ])
(expr_list:REG_EH_REGION (const_int -1 [0x])
(nil
(expr_list:REG_DEP_TRUE (use (reg:V4SF 21 xmm0 [ xmm0 ]))
(expr_list:REG_DEP_TRUE (use (reg:V4SF 22 xmm1 [ xmm1 ]))
(nil
To implement a LCM pass to switch FPU between MMX and x87 mode (the example
above is a call to SSE function, currently the call to MMX function is wrong,
see PR21981), the type of registers, used to pass parameters is needed for
MODE_NEEDED macro to insert correct mode for the call - that is FPU_MODE_MMX if
there are MMX registers used and FPU_MODE_X87 otherwise:
if (entity == I387_FPU_MODE)
{
if (CALL_P (insn))
{
if ("mmx registers are used")<<< here we should check for MMX regs
return FPU_MODE_MMX;
else
return FPU_MODE_X87;
}
mode = get_attr_unit (insn);
return (mode == UNIT_I387)
? FPU_MODE_X87 : (mode == UNIT_MMX)
? FPU_MODE_MMX : FPU_MODE_ANY;
}
Secondly, if return value is placed in MMX regsister, MODE_AFTER after call insn
should set mode state to FPU_MODE_MMX, otherwise to FPU_MODE_X87.
To properly implement this switching scheme, I would like to ask, what is the
proper way to check if MMX register is used as a parameter passing register in
the call, and how to check if MMX register is used to hold return value. This
information is needed to properly calculate MODE_NEEDED and MODE_AFTER values
for function call in LCM pass.
In the function itself, we can handle entry and exit mode using
MODE_ENTRY and MODE_EXIT macros. Entry mode would be set to FPU_MODE_MMX if MMX
registers are used for parameter passing and exit mode would be set to
FPU_MODE_MMX if MMX reg is used to hold return value. Otherwise, they would both
be set to FPU_MODE_X87.
I would like to obtain the same information in function itself to
properly set MODE_ENTRY and MODE_EXIT in LCM pass. Is there an recommended
approach on how to get this information?
Thanks in advance,
Uros.
Re: obj-c++ on sparc-linux: objc runtime: cannot find class Derived etc...
> Results on x86-64 as of yesterday: > > === obj-c++ tests === > > > Running target unix > FAIL: obj-c++.dg/bitfield-1.mm (test for excess errors) > FAIL: obj-c++.dg/bitfield-2.mm execution test > FAIL: obj-c++.dg/bitfield-4.mm (test for excess errors) > FAIL: obj-c++.dg/cxx-ivars-1.mm execution test > FAIL: obj-c++.dg/cxx-ivars-2.mm execution test > FAIL: obj-c++.dg/cxx-scope-1.mm execution test > FAIL: obj-c++.dg/defs.mm execution test > FAIL: obj-c++.dg/encode-3.mm execution test > FAIL: obj-c++.dg/encode-4.mm (test for excess errors) > WARNING: obj-c++.dg/encode-4.mm compilation failed to produce executable > FAIL: obj-c++.dg/encode-5.mm (test for excess errors) > WARNING: obj-c++.dg/encode-5.mm compilation failed to produce executable > FAIL: obj-c++.dg/encode-6.mm (test for excess errors) > WARNING: obj-c++.dg/encode-6.mm compilation failed to produce executable > FAIL: obj-c++.dg/encode-8.mm execution test > FAIL: obj-c++.dg/isa-field-1.mm (test for excess errors) > FAIL: obj-c++.dg/layout-1.mm (test for excess errors) > FAIL: obj-c++.dg/lookup-2.mm (test for excess errors) > WARNING: obj-c++.dg/lookup-2.mm compilation failed to produce executable > FAIL: obj-c++.dg/method-10.mm execution test > FAIL: obj-c++.dg/method-17.mm execution test > FAIL: obj-c++.dg/method-19.mm (test for excess errors) > WARNING: obj-c++.dg/method-19.mm compilation failed to produce executable > FAIL: obj-c++.dg/proto-qual-1.mm execution test > FAIL: obj-c++.dg/qual-types-1.mm execution test > FAIL: obj-c++.dg/template-1.mm execution test > FAIL: obj-c++.dg/template-4.mm execution test > FAIL: obj-c++.dg/try-catch-2.mm (test for excess errors) > WARNING: obj-c++.dg/try-catch-2.mm compilation failed to produce executable > FAIL: obj-c++.dg/try-catch-9.mm (test for excess errors) > WARNING: obj-c++.dg/try-catch-9.mm compilation failed to produce executable > FAIL: obj-c++.dg/va-meth-1.mm execution test Roughly the same results on SPARC/Solaris (21 failures instead of 25 though). -- Eric Botcazou
Re: GCC 4.01 RC1 Available
> The GCC 4.0.1 RC1 prerelease is available here: > >ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050607/ > > Please test these tarballs, and let me know about showstoppers. SPARC/Solaris is OK: http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00621.html http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00622.html http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00626.html http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00623.html http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00624.html http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00625.html There are a few new failures in 64-bit mode: Fortran: FAIL: gfortran.dg/forall_1.f90 -O1 execution test FAIL: gfortran.dg/forall_1.f90 -O2 execution test FAIL: gfortran.dg/forall_1.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/forall_1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/forall_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/forall_1.f90 -O3 -g execution test FAIL: gfortran.dg/forall_1.f90 -Os execution test libstdc++ FAIL: ext/array_allocator/2.cc execution test but they are *not* regressions. SPARC/Linux is OK too (Christian): http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00616.html -- Eric Botcazou
Re: Fw: Can't bootstrap mainline on powerpc64-linux
On Thu, Jun 09, 2005 at 05:31:06PM -0400, Daniel Berlin wrote: > > > On Thu, 9 Jun 2005, Pat Haugen wrote: > > >[EMAIL PROTECTED] wrote on 06/09/2005 02:43:37 PM: > > > >>cc1: warnings being treated as errors > >>/home/pthaugen/work/src/mainline/gcc/gcc/config/rs6000/rs6000.c:12538: > >>warning: ârs6000_invalid_within_doloopâ defined but not > >>used > > > >ChangeLog looks odd on this, Adrian changed the name of prototype and then > >later Daniel came along and fixed prototype of "old" name. > > > >2005-06-09 Daniel Berlin <[EMAIL PROTECTED]> > > > > * config/rs6000/rs6000.c: (rs6000_insn_valid_within_doloop): Fix > > prototype. > > Before i committed this, we had > > "static bool rs6000_invalid_within_doloop > > static const char * > rs6000_invalid_within_doloop > " > > I had updated rs6000.c repeatedly to make sure i wasn't missing something. > > I simply made the prototype at the top match the function as it actually > exists in the source file. > > "Defined but not used" means it exists in the source file but isn't > actually used, which is a different bug :) > Argh, these two updates were completely wrong: -static bool rs6000_insn_valid_within_doloop (rtx); +static bool rs6000_invalid_within_doloop (rtx); -#define TARGET_INSN_VALID_WITHIN_DOLOOP rs6000_insn_valid_within_doloop +#define TARGET_INSN_VALID_WITHIN_DOLOOP rs6000_invalid_within_doloop They should have looked like that: -static bool rs6000_insn_valid_within_doloop (rtx); +static const char *rs6000_invalid_within_doloop (rtx); -#undef TARGET_INSN_VALID_WITHIN_DOLOOP -#define TARGET_INSN_VALID_WITHIN_DOLOOP rs6000_insn_valid_within_doloop +#undef TARGET_INVALID_WITHIN_DOLOOP +#define TARGET_INVALID_WITHIN_DOLOOP rs6000_invalid_within_doloop Looking at the current sources, it seems like you have fixed that already. Thank you! I'm very much sorry for the inconvenience! Adrian
Re: GCC question
Thanks for your help, David, Please accept my apologies for not asking the public forum. I'll do that now... GCCers, please fill me in on the roadmap and who is working in this area. Thanks and regards, Robert On Thu, 9 Jun 2005, David Edelsohn wrote: > There are plans to implement loop fusion / array contraction in > GCC based on the Tree-SSA data dependence analysis infrastructure now > implemented in GCC. You need to ask the GCC community through the > gcc@gcc.gnu.org mailinglist about the roadmap. A number of members of the > GCC community are working on the problem, but each has his or her own > priority and funding resources. > > You should ask these questions publicly, not contacting individual > developers privately. > > David > > To: David Edelsohn/Watson/[EMAIL PROTECTED] > cc: > Subject:GCC question > > > > Hi, Dr. Edelsohn, > > I just read your Systems Journal article about GCC, > and was wondering if you can answer a question > about it for me: > > I see veiled references to loop fusion/array contraction in GCC on > the web, but it looks like it only works for Fortran code. > Also, a few simple experiments I've made with it seem to > indicate that loop fusion is not performed by the compiler. > > So... > > 1. Are there plans to introduce loop fusion/array contraction > into GCC? > > 2. If so, who would I contact in that regard? > > 3. If not, do you have any idea of the approximate difficulty > of doing that in the post-SSA version of the compiler? > If it's not onerous, I may be able to take on the job, as > I otherwise have to introduce similar facilities into > other compilers, and I'd rather do the job just once... > > The reason I'm doing this is that I'm working on array language > compilers (APL, J, SAC), and these optimizations are key to > getting acceptable run-time performance in those tongues. > > Thanks, > Robert > > > >
Question about new warning system
Hello DJ, I'm updating a piece of code of the C++ frontend which involves a warning, so I was planning on adding the correct warning option to it. The original code is the following: if (warn_missing_braces) warning (0, "missing braces around initializer"); So, what is the correct way of fixing this: [1] if (warn_missing_braces) warning (OPT_Wmissing_braces, "missing braces around initializer"); [2] if (OPT_Wmissing_braces) warning (OPT_Wmissing_braces, "missing braces around initializer"); [3] warning (OPT_Wmissing_braces, "missing braces around initializer"); What is the difference between [1], [2], [3]? Thanks, -- Giovanni Bajo
Re: Question about new warning system
> if (OPT_Wmissing_braces) >warning (OPT_Wmissing_braces, "missing braces around > initializer"); FYI OPT_Wmissing_braces is an enum constant; it will always be nonzero. > [3] > warning (OPT_Wmissing_braces, "missing braces around initializer"); That is what we decided to do. Note, however, if the logic required to determine if a warning is warranted is sufficiently complex, *also* checking the variable is considered an optimization: if (warn_missing_braces && expensive_warning_check()) warning (OPT_Wmissing_braces, "..."); In this case, the warn_missing_braces check is done only to avoid calling expensive_warning_check() if we know in advance we won't be needing it.
Re: Question about new warning system
DJ Delorie <[EMAIL PROTECTED]> wrote: >> if (OPT_Wmissing_braces) >>warning (OPT_Wmissing_braces, "missing braces around >> initializer"); > > FYI OPT_Wmissing_braces is an enum constant; it will always be nonzero. So, I assume this patch is wrong in this regard: http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00392.html >> [3] >> warning (OPT_Wmissing_braces, "missing braces around initializer"); > > That is what we decided to do. > > Note, however, if the logic required to determine if a warning is > warranted is sufficiently complex, *also* checking the variable is > considered an optimization: OK, thanks! -- Giovanni Bajo
Re: Question about new warning system
> So, I assume this patch is wrong in this regard: > http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00392.html Yes, it's wrong in that way.
Re: Question about new warning system
DJ Delorie <[EMAIL PROTECTED]> wrote: >> So, I assume this patch is wrong in this regard: >> http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00392.html > > Yes, it's wrong in that way. Gaby, can you please fix it then? -- Giovanni Bajo
Re: Question about new warning system
"Giovanni Bajo" <[EMAIL PROTECTED]> writes: | Hello DJ, | | I'm updating a piece of code of the C++ frontend which involves a warning, | so I was planning on adding the correct warning option to it. The original | code is the following: | | if (warn_missing_braces) |warning (0, "missing braces around initializer"); | | So, what is the correct way of fixing this: | | [1] | if (warn_missing_braces) |warning (OPT_Wmissing_braces, "missing braces around | initializer"); | | [2] | if (OPT_Wmissing_braces) |warning (OPT_Wmissing_braces, "missing braces around | initializer"); | | [3] | warning (OPT_Wmissing_braces, "missing braces around initializer"); | | What is the difference between [1], [2], [3]? [3] shows which options is used to enable/disable that diagnostic (assumming it is controled by a particular switch). In either case the main diagnostic is always emitted. As pointed out by JSM yesterday, it is not clear whether [1] should be preferred over [2] or the converse. I think having two ways to control the same diagnostic is a bit confusing. I think the difference between [1] and [2] is that warn_xxx can be true even though OPT_W is not explicitly specified -- e.g. it could be set as a consequence of setting another flag. -- Gaby
Re: Question about new warning system
> [3] shows which options is used to enable/disable that diagnostic > (assumming it is controled by a particular switch). In either case > the main diagnostic is always emitted. No, [3] will also enable/disable the warning, as the OPT_* is used to look up the variable, and the variable is checked. If you do [1] you end up checking the variable twice. > As pointed out by JSM yesterday, it is not clear whether [1] should be > preferred over [2] or the converse. I think having two ways to > control the same diagnostic is a bit confusing. I think the > difference between [1] and [2] is that warn_xxx can be true even > though OPT_W is not explicitly specified -- e.g. it could be set > as a consequence of setting another flag. No, if you use Var(warn_foo) in OPT_foo, then passing OPT_foo to warning() will check if warn_foo is set - it does EXACTLY the same logic as [1]. The only time [1] is appropriate is if there's expensive logic between the warn_foo and the warning(), and even then it's only an optimization. As long as the variable is associated with the switch through Var(), it doesn't matter how the variable is set. [2] just doesn't work. Ever. Don't ever do [2]. It's wrong.
Re: Question about new warning system
Gabriel Dos Reis wrote:
As pointed out by JSM yesterday, it is not clear whether [1] should be
preferred over [2] or the converse. I think having two ways to
control the same diagnostic is a bit confusing. I think the
I'm inclined to agree it is confusing. especially as in one place one has to
write warn_ and in the other place one writes OPT_W. It'd be nice if
one just wrote
if (warn_foo && frobbed)
warning ("foo is frobbed");
I don't care if it's spelt warn_foo, OPT_Wfoo, warning_p(foo) or whatever, so
long as it's spelt only one way. The 'warning (OPT_Wfoo, ...)' syntax helps
only where there is no conditional before the warning -- how often does that
occur? The way it currently is, one runs the risk of writing
if (warn_c_cast
&& .
&& .
&& .)
warning (OPT_Wconst_cast, ...)
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
rationale for bss patterns in default_section_type_flags ?
Hello, Is there a rationale for the list of bss patterns matched by default_section_type_flags_1 ? << if (strcmp (name, ".bss") == 0 || strncmp (name, ".bss.", 5) == 0 || strncmp (name, ".gnu.linkonce.b.", 16) == 0 || strcmp (name, ".sbss") == 0 || strncmp (name, ".sbss.", 6) == 0 || strncmp (name, ".gnu.linkonce.sb.", 17) == 0) flags |= SECTION_BSS; >> Would matching, say, ".bss" anywhere-in or at-the-end-of name be appropriate ? If no, why not ? Thanks in advance for your help. Olivier
Re: Question about new warning system
"Giovanni Bajo" <[EMAIL PROTECTED]> writes: | DJ Delorie <[EMAIL PROTECTED]> wrote: | | >> So, I assume this patch is wrong in this regard: | >> http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00392.html | > | > Yes, it's wrong in that way. | | Gaby, can you please fix it then? Sure, see the message I just sent. -- Gaby
Re: Question about new warning system
Nathan Sidwell <[EMAIL PROTECTED]> wrote:
> I'm inclined to agree it is confusing. especially as in one place one has
to
> write warn_ and in the other place one writes OPT_W. It'd be
> nice if one just wrote
> if (warn_foo && frobbed)
> warning ("foo is frobbed");
>
> I don't care if it's spelt warn_foo, OPT_Wfoo, warning_p(foo) or whatever,
> so long as it's spelt only one way. The 'warning (OPT_Wfoo, ...)' syntax
> helps only where there is no conditional before the warning -- how often
> does that occur? The way it currently is, one runs the risk of writing
> if (warn_c_cast
>&& .
> && .
> && .)
> warning (OPT_Wconst_cast, ...)
Actually, the point is that you *never* need to explicitally name the
"warn_" variable unless you are optimizing. In other words, code which
presently is:
if (warn_foo
&& frobbed)
warning (0, "foo is frobbed");
should be replaced with:
if (frobbed)
warning (OPT_Wfoo, "foo is frobbed");
You need to pass the option to warning() also for another reason: we want to
be able to optionally print which flag can be used to disable each warning,
so warning() has to be smarter than it used to be.
--
Giovanni Bajo
Re: position of section() attribute question
> The various exceptions of the form "if an attribute is applied to the type
> of a decl which can only apply to a decl, then apply it to the decl" are
> there because they represent forms used by existing code.
What about this scenario?
typedef int __attribute__((section("foo"))) FOOINT;
FOOINT a;
Would it make sense to allow this sort of thing? Would it be feasible
to implement?
Re: Question about new warning system
> You need to pass the option to warning() also for another reason: we want to > be able to optionally print which flag can be used to disable each warning, > so warning() has to be smarter than it used to be. In addition, we've talked about the idea of having the diagnostic machinery keep track of which warnings should be considered errors, moving the -Werror functionality inside warning() and allowing it to be warning-specific, like -Wprototypes for warnings, and -Werror-prototypes for errors. To implement that, warning() needs to know which command line option it's dealing with.
Re: Question about new warning system
> I don't care if it's spelt warn_foo, OPT_Wfoo, warning_p(foo) or > whatever, so long as it's spelt only one way. The 'warning > (OPT_Wfoo, ...)' syntax helps only where there is no conditional > before the warning -- how often does that occur? The way it > currently is, one runs the risk of writing It's confusing now because it's in transition. Eventually, the use of warn_foo will become rare, and the OPT_foo will be the preferred method of controlling diagnostics. Only 664 more warnings to go!
Re: Question about new warning system
DJ Delorie <[EMAIL PROTECTED]> writes:
| > [3] shows which options is used to enable/disable that diagnostic
| > (assumming it is controled by a particular switch). In either case
| > the main diagnostic is always emitted.
|
| No, [3] will also enable/disable the warning, as the OPT_* is used to
| look up the variable, and the variable is checked. If you do [1] you
| end up checking the variable twice.
Right, I missed:
if (diagnostic->option_index
&& ! option_enabled (diagnostic->option_index))
return;
and was reading only
if (diagnostic_count_diagnostic (context, diagnostic))
{
const char *saved_format_spec = diagnostic->message.format_spec;
if (context->show_option_requested && diagnostic->option_index)
diagnostic->message.format_spec
= ACONCAT ((diagnostic->message.format_spec,
" [", cl_options[diagnostic->option_index].opt_text, "]",
NULL));
pp_prepare_to_format (context->printer, &diagnostic->message,
&diagnostic->location);
(*diagnostic_starter (context)) (context, diagnostic);
pp_format_text (context->printer, &diagnostic->message);
(*diagnostic_finalizer (context)) (context, diagnostic);
pp_flush (context->printer);
diagnostic_action_after_output (context, diagnostic);
diagnostic->message.format_spec = saved_format_spec;
}
Is that behaviour documented somewhere I missed?
-- Gaby
Re: Question about new warning system
DJ Delorie <[EMAIL PROTECTED]> writes: | > I don't care if it's spelt warn_foo, OPT_Wfoo, warning_p(foo) or | > whatever, so long as it's spelt only one way. The 'warning | > (OPT_Wfoo, ...)' syntax helps only where there is no conditional | > before the warning -- how often does that occur? The way it | > currently is, one runs the risk of writing | | It's confusing now because it's in transition. Eventually, the use of | warn_foo will become rare, and the OPT_foo will be the preferred | method of controlling diagnostics. Only 664 more warnings to go! The sooner, the better :-) -- Gaby
Re: Question about new warning system
> Is that behaviour documented somewhere I missed? Sadly, no. Actually, none of the diagnostic calls are documented. The prototypes are even in toplev.h instead of diagnostic.h, between "fatal_insn_not_found() and "rest_of_decl_compilation()". It's quite haphazard. The diagnostic_info structure does have this comment: /* Which OPT_* directly controls this diagnostic. */ int option_index; The word "controls" implies, well, control. But I don't think that counts as the kind of documentation you're thinking about.
Re: position of section() attribute question
On Fri, 10 Jun 2005, DJ Delorie wrote:
> What about this scenario?
>
> typedef int __attribute__((section("foo"))) FOOINT;
>
> FOOINT a;
>
> Would it make sense to allow this sort of thing? Would it be feasible
> to implement?
It might make sense to define "section" as applying to the type - provided
you have clearly defined rules for type compatibility, composite types,
etc. - though it might also break existing code with the attribute in
various positions.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: recommend use of gperf version 3
On Monday, June 6, 2005, at 06:03 AM, Bruno Haible wrote: Joseph S. Myers wrote: If the required version of any tool is changed then the documentation of that version in install.texi needs to be updated accordingly. Here is an updated patch. Looks reasonable to me. Would be good to hear that someone regression tested it.
Re: ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option
I'd put this more simply... On Monday, June 6, 2005, at 02:06 PM, Mathieu Malaterre wrote: I have a question about a valid C code. I am trying to compile the following code in MacOSX (*). I don't understand what the problem is? You must use -fno-common when you are building dynamic libraries on darwin. Could someone please explain me what is going on? You didn't use -fno-common.
Re: Gcc 3.0 and unnamed struct: incorrect offsets
On Monday, June 6, 2005, at 11:04 PM, Atul Talesara wrote: I wanted to know if this is a bug Yes.
Problems with collect2 on hpux
Hi all, I'm running into a strange problem on HPUX 11i with gcc-3.4.2 that I think is related to collect2. For anyone who isn't familiar with it, HPUX has some interesting peculiarities when working with 32 bit executables - they use SHLIB_PATH instead of LD_LIBRARY_PATH, and, to make things more interesting, the linking and loading system ignores SHLIB_PATH unless you pass the +s flag to the linker. By default any shared libraries you create will only work if shared libraries they reference are in exactly the same path as they were when the shared library was created.I've had to rebuild the libstdc++.sl with the -Wl,+s flag so that it can find libgcc_s.sl from the SHLIB_PATH. The strange behaviour I'm seeing is that if I link my shared libraries with -Wl,+s, then some of them work fine and find all of their libraries based on the SHLIB_PATH settings. However, some of my libraries find everything *except* libstdc++.sl from the SHLIB_PATH - these libraries only load if I put libstdc++.sl in the exact same location it was in when I built the library in the first place. My suspicion is that when collect2 relinks things it's not using the +s flag, and that is causing the behaviour I'm seeing... Has anyone seen anything like this before? Any suggestions on how I might resolve it? Warren
Re: How to check for MMX registers in function call?
On Fri, Jun 10, 2005 at 10:38:56AM +0200, Uros Bizjak wrote: > To properly implement this switching scheme, I would like to ask, what is the > proper way to check if MMX register is used as a parameter passing register in > the call CALL_INSN_FUNCTION_USAGE > and how to check if MMX register is used to hold return value. SET_DEST of the CALL. > I would like to obtain the same information in function itself to > properly set MODE_ENTRY and MODE_EXIT in LCM pass. For MODE_EXIT, current_function_return_rtx. For MODE_ENTRY, I think you have to walk DECL_ARGUMENTS of current_function_decl looking at DECL_INCOMING_RTL. You might be able to get away with something like MODE_ENTRY = (current_function_args_info.maybe_vaarg || current_function_args_info.mmx_nregs == MMX_REGPARM_MAX ? I387 : MMX) but I'm not sure that's the best thing to rely on. r~
Re: position of section() attribute question
On Fri, Jun 10, 2005 at 10:50:01AM -0400, DJ Delorie wrote:
> typedef int __attribute__((section("foo"))) FOOINT;
>
> FOOINT a;
>
> Would it make sense to allow this sort of thing?
No more than it would make sense to have
typedef static int FOOINT;
IMO.
r~
Re: rationale for bss patterns in default_section_type_flags ?
On Friday, June 10, 2005, at 07:30 AM, Olivier Hainque wrote: Is there a rationale for the list of bss patterns matched by default_section_type_flags_1 ? That is how bss sections are named?! Would matching, say, ".bss" anywhere-in or at-the-end-of name be appropriate? No, the standard is to be prefix based, this simplifies the impact on the linker scripts.
Re: Use of check_vect() in vectorizer testsuite
"Giovanni Bajo" <[EMAIL PROTECTED]> wrote on 09/06/2005 20:37:43: > Janis Johnson <[EMAIL PROTECTED]> wrote: > > > It sounds as if there should be a check in target-supports.exp for > > SSE2 support that determines whether the default test action is 'run' > > or 'compile' for i686 targets. > > I am not able to code TCL/Expect. Instead, I can easily provide a patch to > make the few missing testcases call check_vect(), as the rest of the > testsuite does. This would shut down the bogus regressions, while a more > correct solution is being developed. Would such a patch be ok? fine with me. by the way, about: > 1) All the ifcvt tests (vect-ifcvt*) seem to require SSE2 > capability to be > vectorized but they do not call check_vect(). Is this a bug? They > surely fail > on my platform (which does not have SSE2). > > 2) The same applies for a vect_int test, vect-dv-2.c. I assume also > vect_int > tests require SSE2 capability and thus should call check_vect()? Devang, is vect-dv-2.c a duplicate of vect-ifcvt-1.c or are they both there on purpose? dorit > -- > Giovanni Bajo >
Re: ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option
On Jun 10, 2005, at 3:45 PM, Mike Stump wrote: I'd put this more simply... On Monday, June 6, 2005, at 02:06 PM, Mathieu Malaterre wrote: I have a question about a valid C code. I am trying to compile the following code in MacOSX (*). I don't understand what the problem is? You must use -fno-common when you are building dynamic libraries on darwin. Could someone please explain me what is going on? You didn't use -fno-common. Can someone please tell me then which one of the three possibilities is the right one: #1. I need to tell the linker to use -single_module #2. Rewrite the code to make a fake initialization #3. I need to pass -fno-common to the compiler I really don't understand why I need to do that, since this is valid C code. Why the linker does not default to proper option, or why the -fno-common option isn't used. At compile time gcc should figure that out, right ? Now compared to the linker option, at least the compiler flag I can specify it for the specific file I want, which is great. But then again why is this up to the user to do it ? Is there a performance reason ? Why isn't it the default ? How do other people do when porting *nix lib to MacOSX ? Is this is trial-and-error process to get the lib compiled ? Thanks Mathieu
gfortran backports to 4.0
I've been added me to the Cc: list for PR 20930, which is a Fortran PR. This is a bug in 4.0 and has been fixed on the mainline. David would like the patch to appear in 4.0.x as well. For the record, it's fine to backport Fortran changes to 4.0. I see Fortran 4.0 as very much a work in progress, with a relatively minimal installed user base, and it's entirely reasonable to make riskier changes there than we would for C or C++, especially to fix critical bugs in 4.0. In fact, I'd encourage the Fortran maintainers to accept backported patches, though, of course, the decision is up to them. I'm not trying to create an obligation for anyone, but, for what it's worth, I think that following up on: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02699.html and, in particular, this statement from Steven: I guess we should re-sync mainline and 4.0 soon, your patch would be included automatically. would be nice. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: rationale for bss patterns in default_section_type_flags ?
> > Is there a rationale for the list of bss patterns matched by > > default_section_type_flags_1 ? > > That is how bss sections are named?! Part of the question is "how bss sections are named" according to evolution, or some crystal clear standard, or what ??? > > Would matching, say, ".bss" anywhere-in or at-the-end-of name be > > appropriate? > > No, the standard is to be prefix based, this simplifies the impact on > the linker scripts. Ok. So a new category of bss sections could be matched by "X.bss" or "X.bss."*. Would that be reasonable?
Re: ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option
On Friday, June 10, 2005, at 02:48 PM, Mathieu Malaterre wrote: Could someone please explain me what is going on? You didn't use -fno-common. Can someone please tell me then which one of the three possibilities is the right one: #1. I need to tell the linker to use -single_module #2. Rewrite the code to make a fake initialization #3. I need to pass -fno-common to the compiler #3. Now compared to the linker option, at least the compiler flag I can specify it for the specific file I want, which is great. But then again why is this up to the user to do it ? Is there a performance reason ? Why isn't it the default ? I refuse to answer that on that basis that marketing people might see my answer. :-) Let's just call it a `bug'. How do other people do when porting *nix lib to MacOSX ? Is this is trial-and-error process to get the lib compiled ? They use libtool, and it `knows' about -fno-common: darwin* | rhapsody*) # PIC is the default on this platform # Common symbols not allowed in MH_DYLIB files _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fno-common' ;;
Re: rationale for bss patterns in default_section_type_flags ?
On Friday, June 10, 2005, at 03:04 PM, Brett Porter wrote: Part of the question is "how bss sections are named" according to evolution, or some crystal clear standard, or what ? Ultimately, people just pick names. Once picked, they form crystal clear standards. Would matching, say, ".bss" anywhere-in or at-the-end-of name be appropriate? No, the standard is to be prefix based, this simplifies the impact on the linker scripts. Ok. So a new category of bss sections could be matched by "X.bss" or "X.bss."*. Would that be reasonable? _prefix_, not suffix. No. You'd first have to explain why the existing standard of prefix can't be made to work I think. .bss.X would be the convention to use.
Re: ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option
> > I'd put this more simply... > > > > On Monday, June 6, 2005, at 02:06 PM, Mathieu Malaterre wrote: > >>I have a question about a valid C code. I am trying to > >> compile the following code in MacOSX (*). I don't understand > >> what the problem is? > > > > You must use -fno-common when you are building dynamic libraries on darwin. > > > >> Could someone please explain me what is going on? > > > > You didn't use -fno-common. > > > > > > > Can someone please tell me then which one of the three > possibilities is the right one: > > #1. I need to tell the linker to use -single_module > #2. Rewrite the code to make a fake initialization > #3. I need to pass -fno-common to the compiler >From a standpoint of just getting the thing deployed, any one of these three is right. > I really don't understand why I need to do that, since this is > valid C code. Why the linker does not default to proper option, or > why the -fno-common option isn't used. At compile time gcc should > figure that out, right ? The code parses, has the right nesting levels of blocks, arrays, parens, has valid types, the statements are valid, ETC. As far as the ANSI standard is concerned, this code is valid, and it's the programmer's buisness to read the documentation for the toolchain and understand that this kind of thing might happen. It is not GCC's buisness, it is not any ANSI compiler's buisness, it is not any pre-ANSI compiler's buisness, it is not any compiler's buisness. GCC does not know and does not care that this might be invalid input to the linker. All that GCC cares about is that it is valid C code and the assembler likes it's assembly output. All other parts of the toolchain are not anyone's buisness but the programmer. The ANSI standard dosen't specify anything about a linker; the only thing that makes GCC a compiler is the assembly source it produces. It isn't the compiler's buisness what goes in the assembler's object file. It isn't the compiler's buinsness what goes in the final executable. > Now compared to the linker option, at least the compiler flag I can > specify it for the specific file I want, which is great. But then > again why is this up to the user to do it ? Is there a performance > reason ? Why isn't it the default ? The compiler dosen't know that you might be making a dynamic library from it's object file. It dosen't know about the linker having that behavior. -fno-common is not default because it causes symbols to be moved out of the BSS. Moving symbols out of the BSS causes extra code to be generated. And most people agree that the BSS is the proper resting place for unitalized symbols. > How do other people do when porting *nix lib to MacOSX ? Is this is > trial-and-error process to get the lib compiled ? Perl does it by initalizing the values. Samuel Lauber -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option
On Friday, June 10, 2005, at 04:15 PM, Sam Lauber wrote: #1. I need to tell the linker to use -single_module #2. Rewrite the code to make a fake initialization #3. I need to pass -fno-common to the compiler From a standpoint of just getting the thing deployed, any one of these three is right. Sigh. #2 doesn't work as the compiler can synthesize common variables that you can't control, and when it does this, things won't work. Forcing people to use -single_module strikes me as wrong. So, from the standpoint of good advice, -fno-common is the only answer.
Re: rationale for bss patterns in default_section_type_flags ?
> Ultimately, people just pick names. Once picked, they form crystal > clear standards. So there is no documented standard involved. > >> No, the standard is to be prefix based, this simplifies the impact on > >> the linker scripts. > > > > Ok. So a new category of bss sections could be matched by > > "X.bss" or "X.bss."*. Would that be reasonable? > > _prefix_, not suffix. No. You'd first have to explain why the > existing standard of prefix can't be made to work I think. .bss.X > would be the convention to use. "X.bss" would be the prefix (like .sbss and .gnu.linkonce.b. in default_section_type_flags_1) and the desire is have a .bss-like section with a difference, that is not included in any .bss.* wildcard patterns in a linker script. The situation is: in an embedded system, certain variables are placed in .persistent.bss (name is not our choice :( ); upon an initial load the section is zeroed just like .bss; there are conditions where the program is restarted but the loader will not zero this section (in battery-backed RAM) during the restart. The easiest implementation would be to add || strcmp (name, ".persistent.bss") == 0 to the list in default_section_type_flags_1 and it doesn't seem likely that .persistent.bss should not have SECTION_BSS set?) Of course, it would only be used in a system where the linker and loader are prepared for it. Brett
Re: rationale for bss patterns in default_section_type_flags ?
On Friday, June 10, 2005, at 05:03 PM, Brett Porter wrote: So there is no documented standard involved. Actually I do believe that some of the standards are documented, but, I don't happen to have pointers to exactly which ones. No, the standard is to be prefix based, this simplifies the impact on the linker scripts. Ok. So a new category of bss sections could be matched by "X.bss" or "X.bss."*. Would that be reasonable? _prefix_, not suffix. No. You'd first have to explain why the existing standard of prefix can't be made to work I think. .bss.X would be the convention to use. "X.bss" would be the prefix Oh, I get it, sorry, there are some languages (prolog among them as I recall), where capitolized letters mean something else entirely. I thought you meant the regular expression .*.bss, where .* is the routine name, or something akin to that. .xbss would be the more traditional style name. (like .sbss and .gnu.linkonce.b. that is not included in any .bss.* wildcard patterns in a linker script. Technically, I suspect most do not do that (yet). If the intent to to exclude it from .bss.*, then, I agree with you, choosing a different prefix would be wise. I was specifically trying to get it to prefix match .bss! :-) The situation is: in an embedded system, certain variables are placed in .persistent.bss Sounds like a fine name. Why not just use that name?
Re: Question about new warning system
Giovanni Bajo wrote: Actually, the point is that you *never* need to explicitally name the "warn_" variable unless you are optimizing. In other words, code which presently is: if (warn_foo && frobbed) warning (0, "foo is frobbed"); should be replaced with: if (frobbed) warning (OPT_Wfoo, "foo is frobbed"); Perhaps a macro should be defined: maybe_warning (OPT_Wfoo, frobbed, "foo is frobbed"); This tests whether Wfoo is enabled *before* it evaluates frobbed. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: rationale for bss patterns in default_section_type_flags ?
> > The situation is: in an embedded system, certain > > variables are placed in .persistent.bss > > Sounds like a fine name. Why not just use that name? Doing an exact match on that name in default_section_type_flags_1 is a nice solution for our needs. The reason for our query was twofold: are there standards (of any form :) that such a choice would be incompatible with?; would anything more general be appropriate (thus the suffix question)? Brett
Re: Question about new warning system
>maybe_warning (OPT_Wfoo, frobbed, "foo is frobbed"); > > This tests whether Wfoo is enabled *before* it evaluates frobbed. In the cases where such a check is warranted, "frobbed" is usually a fairly large collection of tests. It would be impractical (and ugly) to put such logic inside a macro call. There is a option_enabled() function which takes an OPT_* and returns nonzer if the option is enabled, in case you lose track of which OPT_* goes with which warn_* (or if the variable doesn't exist, or is other than a simple integer). But it's easier to use the warn_* variables for such cases.
