how multi-line strings handled in gcc-4.0.0?

how multi-line strings handled in gcc-4.0.0?

[cyclops]

Dear all,

We have ported gcc-3.2.3 to our target machine successfully about one year ago. 

Now we are trying to upgrade it from 3.2.3 to 4.0.0.

I found that some files like cpplex.c disappeared from 4.0.0. (Maybe
in earlier version, i do not know)

The thing is in 3.2.3, when compile code like

 __asm__ ("
           .set  noat
           mov   r5,%0
           mov   r8,%1
           mov   r9,%2
           mov   r10,%3
           svc
           .set  at"
           :
           : "r"(SVC_LSEEK), "r"(file), "r"(ptr), "r"(dir)
           : "r5", "r8", "r9", "r10"
           );


It only gives an warning:  "warning: multi-line string literals are
deprecated". The code is still generated correctly.

However, in gcc-4.0.0, it treats the same piece code as error:

"error: missing terminating " character"

I know this problem can be solved by add "\" at the end of each line. 
However, we have a lot of code written in that way, we may not want to
change them all.  Is there a way to make gcc-4.0.0 to treat those
multi-line strings as gcc-3.2.3 did?

Thanks very much!

Regards,
zeal

Re: how multi-line strings handled in gcc-4.0.0?

[Ian Lance Taylor]

cyclops <cyclops64@gmail.com> writes:

> I found that some files like cpplex.c disappeared from 4.0.0. (Maybe
> in earlier version, i do not know)

It moved to libcpp/lex.c, although I don't know why it matters.

> The thing is in 3.2.3, when compile code like
> 
>  __asm__ ("
>            .set  noat
>            mov   r5,%0
>            mov   r8,%1
>            mov   r9,%2
>            mov   r10,%3
>            svc
>            .set  at"
>            :
>            : "r"(SVC_LSEEK), "r"(file), "r"(ptr), "r"(dir)
>            : "r5", "r8", "r9", "r10"
>            );
> 
> 
> It only gives an warning:  "warning: multi-line string literals are
> deprecated". The code is still generated correctly.
> 
> However, in gcc-4.0.0, it treats the same piece code as error:
> 
> "error: missing terminating " character"
> 
> I know this problem can be solved by add "\" at the end of each line. 
> However, we have a lot of code written in that way, we may not want to
> change them all.  Is there a way to make gcc-4.0.0 to treat those
> multi-line strings as gcc-3.2.3 did?

No.  Sorry.

The easiest fix is to use string concatenation, or to simply put a
backslash (or perhaps "\n\") at the end of each line.

Ian

Re: how multi-line strings handled in gcc-4.0.0?

[cyclops]

Ian,

Thanks for your quick answer. 

I just did what you said on our newlib-1.10.0, and I got the newlib
built succesfully (at least no error reported).

Then, I tried to build a very simple small program, however, I got error as:

/home/zeal/z64/local/bin/../lib/gcc/z6464-linux-elf/4.0.0/libgcc.a(__main.o):
In function `__do_global_dtors':
/home/zeal/z64/src/gcc-4.0.0/gcc/libgcc2.c:1951: undefined reference
to `__EH_FRAME_BEGIN__'
/home/zeal/z64/src/gcc-4.0.0/gcc/libgcc2.c:1951: undefined reference
to `__EH_FRAME_BEGIN__'
/home/zeal/z64/local/bin/../lib/gcc/z6464-linux-elf/4.0.0/libgcc.a(__main.o):
In function `__do_global_ctors':
/home/zeal/z64/src/gcc-4.0.0/gcc/libgcc2.c:1967: undefined reference
to `__EH_FRAME_BEGIN__'
/home/zeal/z64/src/gcc-4.0.0/gcc/libgcc2.c:1967: undefined reference
to `__EH_FRAME_BEGIN__'

I checked the bugzilla of gcc, it seems somebody report this two month
ago. (It's an unconfirmed bug)

A comment says "This more looks like a missing define rather than
missing symbol."

Any suggestion for solving this?

Thanks for all your kind help.




On 25 May 2005 22:16:35 -0400, Ian Lance Taylor <ian@airs.com> wrote:
> cyclops <cyclops64@gmail.com> writes:
> 
> > I found that some files like cpplex.c disappeared from 4.0.0. (Maybe
> > in earlier version, i do not know)
> 
> It moved to libcpp/lex.c, although I don't know why it matters.
> 
> > The thing is in 3.2.3, when compile code like
> >
> >  __asm__ ("
> >            .set  noat
> >            mov   r5,%0
> >            mov   r8,%1
> >            mov   r9,%2
> >            mov   r10,%3
> >            svc
> >            .set  at"
> >            :
> >            : "r"(SVC_LSEEK), "r"(file), "r"(ptr), "r"(dir)
> >            : "r5", "r8", "r9", "r10"
> >            );
> >
> >
> > It only gives an warning:  "warning: multi-line string literals are
> > deprecated". The code is still generated correctly.
> >
> > However, in gcc-4.0.0, it treats the same piece code as error:
> >
> > "error: missing terminating " character"
> >
> > I know this problem can be solved by add "\" at the end of each line.
> > However, we have a lot of code written in that way, we may not want to
> > change them all.  Is there a way to make gcc-4.0.0 to treat those
> > multi-line strings as gcc-3.2.3 did?
> 
> No.  Sorry.
> 
> The easiest fix is to use string concatenation, or to simply put a
> backslash (or perhaps "\n\") at the end of each line.
> 
> Ian
>

Re: how multi-line strings handled in gcc-4.0.0?

[Ian Lance Taylor]

cyclops <cyclops64@gmail.com> writes:

> I just did what you said on our newlib-1.10.0, and I got the newlib
> built succesfully (at least no error reported).
> 
> Then, I tried to build a very simple small program, however, I got error as:
> 
> /home/zeal/z64/local/bin/../lib/gcc/z6464-linux-elf/4.0.0/libgcc.a(__main.o):
> In function `__do_global_dtors':
> /home/zeal/z64/src/gcc-4.0.0/gcc/libgcc2.c:1951: undefined reference
> to `__EH_FRAME_BEGIN__'
> /home/zeal/z64/src/gcc-4.0.0/gcc/libgcc2.c:1951: undefined reference
> to `__EH_FRAME_BEGIN__'
> /home/zeal/z64/local/bin/../lib/gcc/z6464-linux-elf/4.0.0/libgcc.a(__main.o):
> In function `__do_global_ctors':
> /home/zeal/z64/src/gcc-4.0.0/gcc/libgcc2.c:1967: undefined reference
> to `__EH_FRAME_BEGIN__'
> /home/zeal/z64/src/gcc-4.0.0/gcc/libgcc2.c:1967: undefined reference
> to `__EH_FRAME_BEGIN__'

These are odd errors to get for an ELF target.  I don't know what
z6464 is.  But you can only get those references in libgcc2.c for a
target whose tm.h file does not define OBJECT_FORMAT_ELF or does not
define either INIT_SECTION_ASM_OP or INIT_ARRAY_SECTION_ASM_OP.  That
should not be true for any ELF target.  If you are using your own
compiler port, you need to update your tm.h file, probably just by
including elfos.h as most ELF targets do.  If you are not using your
own compiler port, what is z6464-linux-elf?

Ian