Re: Idea for Google Summer Code : C Compiler for EFI Byte Code implement in gcc

[Andrew Haley]

On 03/04/2010 07:27 PM, b95705...@ntu.edu.tw wrote:
> 引述 Andrew Haley :
> 
>> There is no reason in principle this shouldn't be part of gcc.
>>
>> I think no-one has responded yet because they don't know what it would
>> be for, and how much work it would involve.
> 
> What compiler doing is: c -> intermediate language -> asm(ex. x86).
> And then, c compiler for efi byte code is: c -> intermediate language ->
> efi byte code.
> For the c -> intermediate language part, I hope to use original  source
> code of gcc,so the main point of the project is implementing
> intermediate language -> efi byte code part
> 
> In my opinion,the project has some how similarity with compiling c
> language to java byte code. And in fact,it has been done by some open
> source project(ex.
> egcs-jvm[http://sourceforge.net/projects/egcs-jvm/]).  I am wondering to
> know that trace some existing c to java byte code project would give
> direction to implement this project or not.

Perhaps.  I don't know if egcs-jvm was ever completed.

>> Is this in any way related to plans for a free BIOS?
> 
> YES, coreboot[http://www.coreboot.org/Welcome_to_coreboot]and
> gnufi[http://www.gnu.org/software/gnufi/]

Ah, good.

>> Who would maintain this EFI back-end?
> 
> The EFI specification was originally developed by Intel, and is now
> managed by the Unified EFI Forum[http://www.uefi.org/home/].

So, you don't know who would maintain the EFI back-end that you're
proposing for gcc?

As others have suggested, there may be severe technical problems
implementing gcc->efi.  There seem to be changes needed to the
front end.  This might work if you could get a group to support
the work, but it may be too much for one person in a summer.

I don't want to dissuade you, but it's important to be realistic.

Andrew.

Re: Use the wctype builtins functions

[Dave Korn]

On 05/03/2010 02:32, Shujing Zhao wrote:
> Hi,
> 
> I want to use the the wctype builtins ISWALPHA and the other ISW*
> functions to handle the wide character string, but I get the following
> error:
> 
> /home/gcc/build/gcc/../../trunk/gcc/opts.c:1190: undefined reference to
> `ISWALPHA'
> collect2: ld returned 1 exist status
> 
> I have tried to grep some examples that use the ISW* builtins, but
> didn't find any one. Does anyone know how to use them?

  The capitalised versions of the IS* functions are macros from safe-ctype.h,
not builtins, and it hasn't been extended with ISW* versions because it's
based on an array and it would need rather a large array to cope with wchars!

  I think you'll probably have to use plain old iswalpha.  Looking at opts.c,
I'm guessing you're trying to extend the help string format to allow unicode?

cheers,
  DaveK

Re: Handling of builtins

[Paulo J. Matos]

On Wed, Mar 3, 2010 at 10:17 AM, Richard Guenther
 wrote:
>
> They are complementary.  The fold_ variants are for simplifications
> throughout tree passes while the expand_ variant translates
> builtin calls to target-specific RTL (with falling back to libcalls).
>

Thanks Richard, that's exactly what I needed to know.

> Richard.
>
>> Cheers,
>>
>> --
>> PMatos
>>
>



-- 
PMatos

Passing compiler option to bootstrap compiler

[Paulo J. Matos]

Hi,

How can I configure gcc and tell it to pass a specific option to the
bootstrap compiler?

-- 
PMatos

Re: Passing compiler option to bootstrap compiler

[Andreas Schwab]

"Paulo J. Matos"  writes:

> How can I configure gcc and tell it to pass a specific option to the
> bootstrap compiler?

http://gcc.gnu.org/install/build.html

Andreas.

-- 
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

Re: Use the wctype builtins functions

[Ian Lance Taylor]

Dave Korn  writes:

>   I think you'll probably have to use plain old iswalpha.  Looking at opts.c,
> I'm guessing you're trying to extend the help string format to allow unicode?

Note that it may be OK to use iswalpha strictly on command line
options, but using it anywhere else gets you into a set of issues
around -finput-charset and -fexec-charset.

Ian

Re: Definition of an instruction

[Jean Christophe Beyler]

Yes, I should have thought about it too. The error message threw me a
bit off, thanks for clearing that. Thanks for that !

Final question about this all:

I have a cost adjustment to make if the register operand 0 is used
later on. Basically, if that one is used, I have a +6 cost otherwise
if it's simply the 66 register, it's +1 cost.

I added this to the adjust_cost function :

/* Otherwise, if one is our instruction, we must check the dependencies */
if (isMyInst (dep_insn))
{
// Get statement
rtx stmt = PATTERN (dep_insn);
// Get target of the set, it's our instruction, we know where
it is exactly
int regno = REGNO (SET_DEST (XVECEXP (stmt, 0, 0)));

/* Depending on if the def of dep_insn is used in insn, we
adjust the cost */
bitmap tmp_uses = BITMAP_ALLOC (®_obstack);

/* Get the uses */
df_simulate_uses (insn, tmp_uses);

/* If ever one of the uses is our Set, add 6 */
if (bitmap_bit_p (tmp_uses, regno))
{
cost += 6;
}

/* Free bitmap */
BITMAP_FREE (tmp_uses), tmp_uses = NULL;
}

Basically, my question is: I'm using the df_simulate_uses because
that's the simplest I know how to get all the uses. Is this safe
without doing a df_analyse at the beginning of the adjust_cost
function ?

It works but I'd like to get some input on it.

Thanks again,
Jc

On Thu, Mar 4, 2010 at 6:42 PM, Andrew Pinski  wrote:
> On Thu, Mar 4, 2010 at 3:38 PM, Jean Christophe Beyler
>  wrote:
>> Yeah that's what I had tried first but I get :
>>
>> genextract: Internal error: abort in VEC_safe_set_locstr
>>
>> And I can't seem to get rid of that error.
>>
>> Any idea why this happens?
>
> Oh because the second time for the match_operand, you should be using
> match_dup (and yes the error message should be better).  I had forgot
> about that :).
> So try this:
> (define_insn "myInst"
>  [
>  (set (match_operand:DI 0 "register_operand" "=r")
>  (unspec:DI [(match_operand:DI 1 "register_operand" "r")
>  (match_operand:DI 2 "register_operand" "r")
>  (reg:DI 66)] 5))
> (set (reg:DI 66)
>  (unspec:DI [(match_dup 1)
>  (match_dup 2)
>  (reg:DI 66)] 6))
>  ]
>  ""
>  "myInst\\t%0,%1,%2"
>  [(set_attr "type"     "arith")
>  (set_attr "mode"     "DI")
>  (set_attr "length"   "1")])
>
>
> Thanks,
> Andrew Pinski
>

Re: Use the wctype builtins functions

[Joseph S. Myers]

On Fri, 5 Mar 2010, Ian Lance Taylor wrote:

> Dave Korn  writes:
> 
> >   I think you'll probably have to use plain old iswalpha.  Looking at 
> > opts.c,
> > I'm guessing you're trying to extend the help string format to allow 
> > unicode?
> 
> Note that it may be OK to use iswalpha strictly on command line
> options, but using it anywhere else gets you into a set of issues
> around -finput-charset and -fexec-charset.

The present issue is help text, as produced by gettext (which produces 
output in the locale's LC_CTYPE, calling iconv internally as needed).  See 
my discussion at  
of the issues with line breaking given a string of multibyte characters, 
whose display width may also vary.

I don't know if there's an existing free software implementation of UAX#14 
(Unicode Line Breaking Algorithm) suitable for use in GCC; that would be 
the very heavyweight approach.  I also don't know if that algorithm would 
actually work well for the peculiarities of option help strings, not 
having studied the details of it.  Hence the suggestion that the existing 
algorithm in opts.c could be reworked to check for L'-', L'/', L' ' and 
use iswalpha.

-- 
Joseph S. Myers
jos...@codesourcery.com

The scope of a for statement

[Magnus Fromreide]

Hello.

I tried to do

for (;; ({ break; }))
printf("Hello\n");

and got an error message:

error: break statement not within loop or switch

when compiling it as C. Given that 9899:1999 §6.8.6.3 says that a break
statement only shall appear in or as a switch or loop body that is expected.

The problem is that when I compile it as C++ i get the same error message and
14882:1998 (and n3035) §6.5.3 says that

The for statement
  for ( for-init-statement conditionopt ; expressionopt ) statement
is equivalent to
  {
for-init-statement
while ( condition ) {
   statement
   expression ;
}
  }

and then goes on to list some exceptions to this, none of which are of
importance here. Looking at §6.6.1 the only requirement on break statement is
that it shall occur in an /iteration-statement/ and that is, among other
things, a for statement, so as I read this the original code should be valid
C++ unless there are any undocumented restrictions on the ({ }) construct.

Are there any such restrictions or have I found a bug in the compiler?

/MF

Re: The scope of a for statement

[Joe Buck]

On Fri, Mar 05, 2010 at 11:38:23AM -0800, Magnus Fromreide wrote:
> Hello.
> 
> I tried to do
> 
> for (;; ({ break; }))
>   printf("Hello\n");
> 
> and got an error message:
> 
> error: break statement not within loop or switch

But it only got through the parser, so that this error message
could be generated, because you're using a GNU extension: statements
and declarations in expressions.  That is, ({ break;}) is a GNU
extension.

> when compiling it as C. Given that 9899:1999 §6.8.6.3 says that a break
> statement only shall appear in or as a switch or loop body that is expected.
> 
> The problem is that when I compile it as C++ i get the same error message and
> 14882:1998 (and n3035) §6.5.3 says that
> 
> The for statement
>   for ( for-init-statement conditionopt ; expressionopt ) statement
> is equivalent to
>   {
> for-init-statement
> while ( condition ) {
>statement
>expression ;
> }
>   }
> 
> and then goes on to list some exceptions to this, none of which are of
> importance here.

But in standard ISO C++, ({ break;}) is not a valid expression.

Ideally a GNU extension should be specified as well as the rest of the
standard is specified, but I'm not surprised that this doesn't work.

Have you tried Cooliris?

[mercy]

Hi there, 

I've been using Cooliris and thought you might be interested in it too. 
Cooliris makes searching and viewing photos and videos on the Web so much 
faster and more fun. It turns your browser into an ever-expanding "3D Wall" 
whenever you launch it from your browser toolbar. It's really hard to explain, 
so you have to try it to see what I mean. You can get it free at 
www.cooliris.com. 

Let me know what you think! 

-- Cheers,

Re: The scope of a for statement

[Magnus Fromreide]

On Fri, Mar 05, 2010 at 12:06:01PM -0800, Joe Buck wrote:
> On Fri, Mar 05, 2010 at 11:38:23AM -0800, Magnus Fromreide wrote:
> > Hello.
> > 
> > I tried to do
> > 
> > for (;; ({ break; }))
> > printf("Hello\n");
> > 
> > and got an error message:
> > 
> > error: break statement not within loop or switch
> 
> But it only got through the parser, so that this error message
> could be generated, because you're using a GNU extension: statements
> and declarations in expressions.  That is, ({ break;}) is a GNU
> extension.

I am aware of that.

> > when compiling it as C. Given that 9899:1999 §6.8.6.3 says that a break
> > ...
> > importance here.
> 
> But in standard ISO C++, ({ break;}) is not a valid expression.

Agreed.

> Ideally a GNU extension should be specified as well as the rest of the
> standard is specified, but I'm not surprised that this doesn't work.

So you would say this points to a buglet in the specification of statement
expressions?

Or is it a bug in the C++ implementation, but one that is unimportant as it
is impossible to detect using standard C++?

/MF

Re: The scope of a for statement

[Joe Buck]

On Fri, Mar 05, 2010 at 02:40:44PM -0800, Magnus Fromreide wrote:
> On Fri, Mar 05, 2010 at 12:06:01PM -0800, Joe Buck wrote:
> > On Fri, Mar 05, 2010 at 11:38:23AM -0800, Magnus Fromreide wrote:
> > > Hello.
> > > 
> > > I tried to do
> > > 
> > > for (;; ({ break; }))
> > >   printf("Hello\n");
> > > 
> > > and got an error message:

...

> > Ideally a GNU extension should be specified as well as the rest of the
> > standard is specified, but I'm not surprised that this doesn't work.
> 
> So you would say this points to a buglet in the specification of statement
> expressions?
> 
> Or is it a bug in the C++ implementation, but one that is unimportant as it
> is impossible to detect using standard C++?

Either way, it's low priority, but if you care, I think that the "fix"
might just be to document that certain uses don't work, and to warn the
user that he/she isn't going to get a very good diagnostic if such uses
are tried.

If I were required to come up with a "fix", I would specify that it's not
valid to break out of the statement expression (with a break, continue, or
goto) and thus forbid ({ break;}), not just here but everywhere.  Throwing
exceptions would be OK because ordinary expression evaluation can throw
exceptions.

expression statements, volatiles, and C vs. C++

[John Regehr]

The question is, what should C and C++ compilers do with this code?

  volatile int x;

  void foo (void) {
x;
  }

This question is not totally stupid: embedded systems use code like this 
when reading a hardware register has a useful side effect (usually 
clearing the register).


It is reasonably clear that a C compiler should load from x and throw 
away the value.  gcc does this, as do most decent C compilers.


However, g++ also loads from x and this does not appear to be supported 
by the 1998 C++ standard.  In 6.2, it is explicitly stated that for an 
expression statement, no conversion from lvalue to rvalue occurs.  If 
there's no rvalue, there should not be a load from x.


Anyway, I'm curious: is the C-like interpretation of a volatile 
expression statement considered to be a feature by the g++ maintainers? 
 If so, what is the rationale?


I haven't do extensive testing, but there do exist compiler families 
(such as those from IAR and Intel) where the C compiler loads from x and 
the C++ compiler does not.


Thanks,

John Regehr