>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 ma
> > 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
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_W
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 im
> 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 matche
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.
> > 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
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"
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
> > 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"
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 prog
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
"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.
>
>
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
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~
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 u
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
On Monday, June 6, 2005, at 11:04 PM, Atul Talesara wrote:
I wanted to know if this is a bug
Yes.
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 librari
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 t
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 -
> 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 structur
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
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
> 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 wr
> 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
> 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;
FOO
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 i
"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
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."
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
> [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 checke
"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,
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
> 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.
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
> 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 t
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 corre
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 l
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:
> 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/2
> 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.m
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
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 ins
44 matches
Mail list logo
