A question about define_insn and force-reg

[Eric Fisher]

>>  (define_insn "loadsf"
>>  [(set (match_operand:SF 0 "register_operand" "=r")
>>(mem:SF (match_operand:SI 1 "immediate_operand" "m")))]


>This makes no sense, because the constraint means that the mem's
operand is >an immediate before reload (and you want it to be a
register), and a mem after >reload. What you want is something like

>(mem:SF (match_operand:SI 1 "general_operand" "r")))]

>which means "the address can be a general operand, but after reload
we only >accept registers here", or

>(mem:SF (match_operand:SI 1 "register_operand" "r")))]

>Paolo

Hey,

Thanks. It seems work now. But... when I define the like insn for QImode,
(define_insn "loadqi_men"
  [(set (match_operand:QI 0 "register_operand" "=r")
(mem:QI (match_operand:SI 1 "general_operand" "r")))]
  ""
  "lbu.u\t%0,0(%1)"
  )

 The compiler comes out such error,
 error: insn does not satisfy its constraints
  (insn 349 53 46 4 ../../gcc-3.4.4/gcc/unwind-pe.h:212 (set (reg:QI 1 $1)
(mem/s:QI (plus:SI (reg/v/f:SI 9 $9 [orig:154 p ] [154])
(const_int 1 [0x1])) [12 S1 A8])) 45 {} (nil)
(nil))

 Well, it seems not work.

 Eric.

Re: backslash whitespace newline

[Kean Johnston]

You still have not demonstrated that this is a real problem.  If someone
is having a real problem, then we can offer them a simple sed script to
fix it.

If I am recalling the original posting correctly, the fact that
gcc behaves differently to "most other compilers" is the actual
problem. Issues relating to code correctness, user brain-deadednes,
or even just sensible practices are rather moot. gcc can be the
only Johnny in step, or it can behave, as Mr. Hinnant was suggesting,
the way everyone else does and adopt the de-facto standard.

Writing sed scripts that change source code is likely to be very
unpalletable to some users. If you're working in an ISO9000
environment where every single source line change is tracked
by a rather burdensome process, the last thing you want to do
is invoke that process for some source base simply because the
new compiler you are moving to behaves differently to the last 5
compilers you used.

Just my $0.02.

Kean

Re: semantics of null lang_hooks.callgraph.expand_function?

[Dueway Qi]

> which has the desited effect of disabling unit-at-a-time, but
> runs aground in cgraph_expand_function() with a segfault,
> when it attempts to call lang_hooks.callgraph.expand_function().
>
> It seems that GCC is handling lang_hooks.callgraph.expand_function
> in an inconsistent fashion.  Is a null value for expand_function
> meaningful?  If it is, then what is the fix for cgraph_expand_function()?
>
I have found another similar case.
lang_hooks.callgraph.analyze_expr  in  gcc/gcc/cgraphunit.c
490   if (lang_hooks.callgraph.analyze_expr)
491 return lang_hooks.callgraph.analyze_expr (tp, walk_subtrees,
492   data);
but in another part of this file
517   if ((unsigned int) TREE_CODE (t) >= LAST_AND_UNUSED_TREE_CODE)
518 return lang_hooks.callgraph.analyze_expr (tp,
walk_subtrees, data);

I am not sure about the run-time features of this piece of code and
just make this conclusion from my point of view of C language.   Am I
missing something?  Any comments are highly appreciated!


--
Dueway

Re: ISO/IEC 14882:2003

[Giovanni Bajo]

Turner, Keith S <[EMAIL PROTECTED]> wrote:

> The man page information for the gcc  c++98 option says that the
> compiler will be compliant with "The 1998 ISO C++ standard plus
> amendments." Are the amendments referring to the changes to the C++
> standard that is now "ISO/IEC 14882:2003". I need to know if "ISO/IEC
> 14882:2003" is supported by gcc 4.0.2.


Yes, it is partly supported. You can look into the source code, directory
gcc/testsuite/g++.dg/tc1, for testcases which record the status with respect to
14882:2003. There is one file per defect report: if you see "xfail" in the
comments, it means that test does not work yet, and thus that defect report is
not implemented yet.

Giovanni Bajo

Successful gcc 4.0.2 build (C,C++ on MinGW i386 WinXP)

[dengxy]

I managed to build gcc-4.0.2 using MinGW 5.0.0 candidate gcc 3.4.4 with command 
`make bootstrap' and configured with flag --enable-languages=c,c++ in MSys 
together with msysDTK 1.0.1 and upgraded autoconf(2.59), automake(1.82) and 
libtool(1.5) on a WinXP system. Since lack of test tools, testing is skipped, 
while the compilers work indeed :)

Now the output from MSys in the objdir directory:

$ ../gcc-4.0.2/config.guess
i686-pc-mingw32

$ gcc -v
Using built-in specs.
Target: i686-pc-mingw32
Configured with: ../gcc-4.0.2/configure --prefix=/mingw 
--enable-languages=c,c++ --disable-nls --enable-threads
Thread model: win32
gcc version 4.0.2

$ uname
MINGW32_NT-5.1

Build report for AIX 5.1

[Mario Linke]

Hi,

i just built  GCC 4.0.2  on AIX 5.1 using the following commands:
../gcc-4.0.1/configure --with-libiconv-prefix=/usr --disable-nls
--disable-multilib
make bootstrap-lean
make install

$ config.guess
powerpc-ibm-aix5.1.0.0

$ gcc -v
Using built-in specs.
Target: powerpc-ibm-aix5.1.0.0
Configured with: /home/linke/temp/gcc-4.0.2/configure
--with-libiconv-prefix=/usr --disable-nls --disable-multilib
Thread model: aix
gcc version 4.0.2

The system is an IBM pSeries M80 with AIX 5.1 at the latest patchlevel.
The building c-complier is  gcc 4.0.1
Make is  gnu-make 3.80

The disable-xxx configure-options shouldn't be necessary, i used them
for buildtime- and space-saving reasons.

The whole build took less than two hours.

Mario Linke

glibc compilation error

[Jeff Stevens]

I am trying to cross compile GCC for an AMCC 440SP
platform (powerpc-linux).  Binutils and bootstrap GCC
compile fine, but when I make glibc it errors out with
the following:

 snippet 

if test -r
/opt/luan2/toolchain/build/glibc/csu/abi-tag.h.new;
then mv -f
/opt/luan2/toolchain/build/glibc/csu/abi-tag.h.new
/opt/luan2/toolchain/build/glibc/csu/abi-tag.h; \
else echo >&2 'This configuration not matched in
../abi-tags'; exit 1; fi
gawk -f ../scripts/gen-as-const.awk
../linuxthreads/sysdeps/powerpc/tcb-offsets.sym \
| powerpc-linux-gcc -S -o
/opt/luan2/toolchain/build/glibc/tcb-offsets.hT3
-std=gnu99 -O2 -Wall -Winline -Wstrict-prototypes
-Wwrite-strings -g -mnew-mnemonics  -I../include
-I. -I/opt/luan2/toolchain/build/glibc/csu -I..
-I../libio  -I/opt/luan2/toolchain/build/glibc
-I../sysdeps/powerpc/powerpc32/elf
-I../sysdeps/powerpc/elf
-I../linuxthreads/sysdeps/unix/sysv/linux/powerpc/powerpc32
-I../linuxthreads/sysdeps/unix/sysv/linux/powerpc
-I../linuxthreads/sysdeps/unix/sysv/linux
-I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread
-I../linuxthreads/sysdeps/unix/sysv
-I../linuxthreads/sysdeps/unix
-I../linuxthreads/sysdeps/powerpc/powerpc32
-I../linuxthreads/sysdeps/powerpc
-I../sysdeps/unix/sysv/linux/powerpc/powerpc32
-I../sysdeps/unix/sysv/linux/powerpc
-I../sysdeps/unix/sysv/linux -I../sysdeps/gnu
-I../sysdeps/unix/common -I../sysdeps/unix/mman
-I../sysdeps/unix/inet -I../sysdeps/unix/sysv
-I../sysdeps/unix/powerpc -I../sysdeps/unix
-I../sysdeps/posix -I../sysdeps/powerpc/powerpc32/fpu
-I../sysdeps/powerpc/powerpc32
-I../sysdeps/wordsize-32 -I../sysdeps/powerpc/soft-fp
-I../sysdeps/powerpc/fpu -I../sysdeps/powerpc
-I../sysdeps/ieee754/flt-32
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754
-I../sysdeps/generic/elf -I../sysdeps/generic
-nostdinc -isystem
/opt/luan2/toolchain/bin/lib/gcc/powerpc-linux/4.0.2/include
-isystem
/opt/luan2/toolchain/source/linux-2.6.13/include/
-D_LIBC_REENTRANT -include ../include/libc-symbols.h  
-DHAVE_INITFINI -x c - \
-MD -MP -MF
/opt/luan2/toolchain/build/glibc/tcb-offsets.h.dT -MT
'/opt/luan2/toolchain/build/glibc/tcb-offsets.h.d
/opt/luan2/toolchain/build/glibc/tcb-offsets.h'
: In function ‘dummy’:
:11: warning: asm operand 0 probably doesn’t
match constraints
:11: error: impossible constraint in ‘asm’
make[2]: ***
[/opt/luan2/toolchain/build/glibc/tcb-offsets.h] Error
1
make[2]: Leaving directory
`/opt/luan2/toolchain/source/glibc-2.3.5/csu'
make[1]: *** [csu/subdir_lib] Error 2
make[1]: Leaving directory
`/opt/luan2/toolchain/source/glibc-2.3.5'
make: *** [all] Error 2

 snippet 


Here is the configuration I run from a separate
build/glibc directory:

../../source/glibc-2.3.5/configure
--prefix=/opt/luan2/toolchain/bin
--target=powerpc-linux --host=powerpc-linux
--enable-add-ons=linuxthreads
--with-headers=/opt/luan2/toolchain/source/linux-2.6.13/include/
--with-binutils=/opt/luan2/toolchain/bin/powerpc-linux/bin

This seems to complete without any issues.

It seems that gcc is having issues with the following
line in gen-as-const.awk:

printf "asm (\"@@@name@@@%s@@@value@@@%%0@@@end@@@\" :
: \"i\" (%s));\n", name, $0;


Is my configure line incorrect, or have I maybe
incorrectly configured bootstrap gcc prior to building
glibc?

Thanks,
   Jeff Stevens



__ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

Re: glibc compilation error

[Paolo Carlini]

Jeff Stevens wrote:

>I am trying to cross compile GCC for an AMCC 440SP
>platform (powerpc-linux).  Binutils and bootstrap GCC
>compile fine, but when I make glibc it errors out with
>the following:
>
To be sure, are you using a gcc3.4.x compiler together with glibc2.3.5,
as required:

http://sources.redhat.com/ml/libc-announce/2005/msg1.html

???

Paolo.

In the meanwhile, 1.3.0rc1 of SVN will become available ..

[Toon Moene]

Ah, but which is the real one ?

[TXT] md5sums.txt 26-Oct-2005 03:41  389
[TXT] sha1sums.txt26-Oct-2005 03:41  491
[   ] subversion-1.3.0-rc1..> 26-Oct-2005 03:42  4.7M
[TXT] subversion-1.3.0-rc1..> 26-Oct-2005 03:42  189
[CMP] subversion-1.3.0-rc1..> 26-Oct-2005 03:43  6.1M
[CMP] subversion-1.3.0-rc1..> 26-Oct-2005 03:43  189
[   ] subversion-1.3.0-rc1..> 26-Oct-2005 03:44  7.0M
[TXT] subversion-1.3.0-rc1..> 26-Oct-2005 03:44  189
[   ] subversion-1.3.0-rc1..> 26-Oct-2005 03:45  6.5M
[TXT] subversion-1.3.0-rc1..> 26-Oct-2005 03:45  189
[CMP] subversion-1.3.0-rc1..> 26-Oct-2005 03:47  8.3M
[CMP] subversion-1.3.0-rc1..> 26-Oct-2005 03:47  189
[   ] subversion-1.3.0-rc1..> 26-Oct-2005 03:48   11M
[TXT] subversion-1.3.0-rc1..> 26-Oct-2005 03:49  189

:-)

--
Toon Moene, KNMI, The Netherlands
Phone: +31 30 2206443; e-mail: [EMAIL PROTECTED]

Re: In the meanwhile, 1.3.0rc1 of SVN will become available ..

[Daniel Berlin]

On Wed, 2005-10-26 at 11:32 +, Toon Moene wrote:
> Ah, but which is the real one ?
> 
> [TXT] md5sums.txt 26-Oct-2005 03:41  389
> [TXT] sha1sums.txt26-Oct-2005 03:41  491
> [   ] subversion-1.3.0-rc1..> 26-Oct-2005 03:42  4.7M
> [TXT] subversion-1.3.0-rc1..> 26-Oct-2005 03:42  189
> [CMP] subversion-1.3.0-rc1..> 26-Oct-2005 03:43  6.1M
> [CMP] subversion-1.3.0-rc1..> 26-Oct-2005 03:43  189
> [   ] subversion-1.3.0-rc1..> 26-Oct-2005 03:44  7.0M
> [TXT] subversion-1.3.0-rc1..> 26-Oct-2005 03:44  189
> [   ] subversion-1.3.0-rc1..> 26-Oct-2005 03:45  6.5M
> [TXT] subversion-1.3.0-rc1..> 26-Oct-2005 03:45  189
> [CMP] subversion-1.3.0-rc1..> 26-Oct-2005 03:47  8.3M
> [CMP] subversion-1.3.0-rc1..> 26-Oct-2005 03:47  189
> [   ] subversion-1.3.0-rc1..> 26-Oct-2005 03:48   11M
> [TXT] subversion-1.3.0-rc1..> 26-Oct-2005 03:49  189
> 
> :-)
> 


The -nodeps ones don't have apr/apr-util/neon included in the tarball.

Re: backslash whitespace newline

[Paul Brook]

> Writing sed scripts that change source code is likely to be very
> unpalletable to some users. If you're working in an ISO9000
> environment where every single source line change is tracked
> by a rather burdensome process, the last thing you want to do
> is invoke that process for some source base simply because the
> new compiler you are moving to behaves differently to the last 5
> compilers you used.

If you're working in that sort of environment the problem really should never 
occur because your coding standards (enforced by an automatic checker) should 
prohibit broken whitespace-at-end-of-line anyway.

Paul

Re: A question about define_insn and force-reg

[Paolo Bonzini]

Thanks. It seems work now. But... when I define the like insn for QImode,
(define_insn "loadqi_men"
  [(set (match_operand:QI 0 "register_operand" "=r")
(mem:QI (match_operand:SI 1 "general_operand" "r")))]
  ""
  "lbu.u\t%0,0(%1)"
  )

 The compiler comes out such error,
 error: insn does not satisfy its constraints
  (insn 349 53 46 4 ../../gcc-3.4.4/gcc/unwind-pe.h:212 (set (reg:QI 1 $1)
(mem/s:QI (plus:SI (reg/v/f:SI 9 $9 [orig:154 p ] [154])
(const_int 1 [0x1])) [12 S1 A8])) 45 {} (nil)
(nil))

 Well, it seems not work.


Then it's not really that you have registers.  You wanted to use a 
register, but (of course) you have more addressing modes than that.


(mem:QI (match_operand:QI 1 "address_operand" "p"))) will do the trick. 
 You could have searched the gccint documentation for "Constraints" and 
you would have found this:


 An operand that is a valid memory address is allowed.  This is for
 "load address" and "push address" instructions.

 `p' in the constraint must be accompanied by `address_operand' as
 the predicate in the `match_operand'.  This predicate interprets
 the mode specified in the `match_operand' as the mode of the memory
 reference for which the address would be valid.

(Note I have match_operand:QI).

Or you could have grepped a small .md file for "(mem:QI" and see how it 
behaves.


Paolo

Re: backslash whitespace newline

[Mike Stump]

On Oct 25, 2005, at 9:33 PM, Joe Buck wrote:

Be interesting to see the results of a grep on a large software
base.  Does anyone have ready access to, say a linux distro handy?
Of all the hits I know about, none of them were an accident.



You're forgetting something: GNU/Linux distros are built with gcc,
and everyone is now using 3.x.  So there can't be buildable programs
that depend on behavior gcc doesn't support.


?  The claim was made that we cannot change it now, as it would break  
the non-portable code that gcc now compiles.  I said, hogwash, linux  
doesn't have any such code, someone else did the grep, and sure  
enough, there is no such code, so that cannot be a reason why we  
cannot remove support for \ sp nl.


What did you think Andrew's point was?  Maybe I entirely misread it?

Re: backslash whitespace newline

[Mike Stump]

On Oct 25, 2005, at 9:28 PM, Joe Buck wrote:

Are you really saying that someone is using ASCII line art in comments
that tweaks this behavior?


Yes, I'm sorry if previous message didn't make this clear.

Out of curiosity: [EMAIL PROTECTED]

[Paolo Carlini]

What are the plans for it?

Often, I find it very useful, will be renamed to gcc-svn and kept alive?

Thanks,
Paolo.

Re: backslash whitespace newline

[Robert Dewar]

Mike Stump wrote:

On Oct 25, 2005, at 9:28 PM, Joe Buck wrote:


Are you really saying that someone is using ASCII line art in comments
that tweaks this behavior?



Yes, I'm sorry if previous message didn't make this clear.


Why would line art ever tweak this problem, why would lines
in such art have trailing white space?

Re: backslash whitespace newline

[Joe Buck]

On Wed, Oct 26, 2005 at 08:16:31AM +0200, Steven Bosscher wrote:
> On Oct 26, 2005 02:30 AM, Joe Buck <[EMAIL PROTECTED]> wrote:
> > I'm still waiting for an explanation as to why this is an important
> > issue, other than that someone has a customer who says that it is.
> > Why is it important to the customer? Why wouldn't a one-line sed
> > script that eliminates the issue altogether suffice?
>  
> Anything that makes porting from one platform to another is a problem. 
> If some app doesn't compile, this customer (usually an ISV ;-) punts and
> says "it doesn't work" and that is the end of it for them.  Telling them
> that GCC is unique and that they should use a sed script shouldn't be
> necessary.

I have limited sympathy, because I've spent so much time getting past the
oddities of Sun's compiler, and HP's compiler, and Microsoft's compiler,
and everyone else's.  Every single one of those compilers has some
oddities, bugs, and nonconformance to the standard, and in most of those
the compiler is provably wrong.  But in many cases, the vendors will not
fix the bugs (or argued for years against doing so) because of backward
compatibility issues.  And that is for code with specified behavior.

This is a case of unspecified behavior.

> I don't understand why _anyone_ sane of mind would support the idea that
> it is OK that GCC does B if everyone else in the industry does A.

OK, I'll be polite and assume that you don't understand me, rather
than that you think I am insane. :-)

That's what we have standards for: so that compilers work the same way
for standard-conformant code.

But in this case, we are talking about the behavior when the compiler is
given code with *unspecified* behavior.  I believe that people should not
be writing such code.  Also, I believe that people writing code that
depends on behavior A are laying time bombs for their employers, setting
traps that will blow up at some later date.  Specifically, they are
creating code that will malfunction as soon as someone strips the
trailing whitespace from it.

I would prefer to detect and eliminate such code, rather than to enable
it, even if (and *especially if*) all compilers in the world implemented
behavior A and it were required by the standard (I would want a warning
option to object loudly to any code whose behavior would change if
trailing whitespace were eliminated).

This will be my last message on this topic.

Re: backslash whitespace newline

[Mike Stump]

On Oct 25, 2005, at 11:05 PM, Andrew Pinski wrote:

Why did Apple revert that patch, well because there was push back from
internal developers who did not want to fix their code.  Why should
this case be any difference?


I'm sorry you don't understand the differences.  In one, we have  
every expectation that the code will compile on every C++ compiler  
out there, except for gcc, and that makes it a gcc bug that has been  
fixed.  The other is a gcc feature that causes code that does compile  
on every other C++ compiler that I know about to not compile on gcc,  
so I guess you're right after all, there is no difference, we'd call  
it a bug that needs to be fixed.  :-)  Wait, what side were you  
arguing?  :-)



or even worse fork GCC.


Is this like calling someone a Nazi?

Re: backslash whitespace newline

[Howard Hinnant]

On Oct 26, 2005, at 12:18 PM, Robert Dewar wrote:


Mike Stump wrote:


On Oct 25, 2005, at 9:28 PM, Joe Buck wrote:

Are you really saying that someone is using ASCII line art in  
comments

that tweaks this behavior?


Yes, I'm sorry if previous message didn't make this clear.



Why would line art ever tweak this problem, why would lines
in such art have trailing white space?


Some programmers purposefully put trailing whitespace on their art in  
order to prevent translation phase 2 line splicing.  And it actually  
works everywhere but gcc.  Mind you I'm not defending this practice.   
I'm just reporting what happens in the field, and giving the opinion  
that gcc might as well adopt the same behavior as every other  
compiler ... even though the standards say it doesn't have to.


-Howard

Re: backslash whitespace newline

[Steven Bosscher]

On Wednesday 26 October 2005 18:28, Joe Buck wrote:
> That's what we have standards for: so that compilers work the same way
> for standard-conformant code.

And we have de facto standards that you just want to ignore.

Gr.
Steven

Re: backslash whitespace newline

[Andrew Pinski]

> 
> On Oct 26, 2005, at 12:18 PM, Robert Dewar wrote:
> 
> > Mike Stump wrote:
> >
> >> On Oct 25, 2005, at 9:28 PM, Joe Buck wrote:
> >>
> >>> Are you really saying that someone is using ASCII line art in  
> >>> comments
> >>> that tweaks this behavior?
> >>>
> >> Yes, I'm sorry if previous message didn't make this clear.
> >>
> >
> > Why would line art ever tweak this problem, why would lines
> > in such art have trailing white space?
> 
> Some programmers purposefully put trailing whitespace on their art in  
> order to prevent translation phase 2 line splicing.  And it actually  
> works everywhere but gcc.  Mind you I'm not defending this practice.   
> I'm just reporting what happens in the field, and giving the opinion  
> that gcc might as well adopt the same behavior as every other  
> compiler ... even though the standards say it doesn't have to.

But in a way you are defending it as you want GCC to change.  If there
was any other reason besides ASCII art, some people would be more willing
to change but there is a simple fix person's code to get around this issue.
And that is by not using C++ style comments and just use C style ones.
It is a simple two edits to their code.  I still am trying to figure
out why this was even brought up if it was only due to ASCII art, that
seems silly.

-- Pinski

Re: backslash whitespace newline

[Mike Stump]

On Oct 26, 2005, at 9:28 AM, Joe Buck wrote:

This is a case of unspecified behavior.


?


That's what we have standards for: so that compilers work the same way
for standard-conformant code.


But in this case, we are talking about the behavior when the  
compiler is
given code with *unspecified* behavior.  I believe that people  
should not

be writing such code.


?  No.  Please read the C++ standard again:

  1.4.13  unspecified behavior
[defns.unspecified]
  behavior,  for  a well-formed program construct and correct data,  
that
  depends on the implementation.  The implementation is not  
required  to
  document which behavior occurs.  [Note: usually, the range of  
possible

  behaviors is delineated by the Standard.  ]


1 Physical  source file characters are mapped, in an  
implementation-

  defined manner


Now, before you claim that people should not write code that relies  
upon implementation defined behavior, realize that the sentence above  
makes all possible programs reliant upon implementation defined  
behavior.

Re: Out of curiosity: [EMAIL PROTECTED]

[Giovanni Bajo]

Paolo Carlini <[EMAIL PROTECTED]> wrote:

> What are the plans for it?
> Often, I find it very useful, will be renamed to gcc-svn and kept alive?

It'll stay alive, but it'll get less and less useful, since it doesn't give
any information you can't find with "svn log".
-- 
Giovanni Bajo

Re: backslash whitespace newline

[Robert Dewar]

Howard Hinnant wrote:

Some programmers purposefully put trailing whitespace on their art in  
order to prevent translation phase 2 line splicing.  And it actually  
works everywhere but gcc.  Mind you I'm not defending this practice.   
I'm just reporting what happens in the field, and giving the opinion  
that gcc might as well adopt the same behavior as every other  compiler 
... even though the standards say it doesn't have to.


-Howard


Seems a weak argument to me. Changing gcc would create incompatibilities
with previous behavior of gcc, and that is FAR more significant than
worrying about other compilers in my opinion. Having gcc compile
non-portable code accepted by other compilers is a useful goal, but
one of low priority compared to maintaining compatibility as far as
possible between gcc versions.

Re: backslash whitespace newline

[Robert Dewar]

Steven Bosscher wrote:

On Wednesday 26 October 2005 18:28, Joe Buck wrote:


That's what we have standards for: so that compilers work the same way
for standard-conformant code.



And we have de facto standards that you just want to ignore.


No, conflicting "de facto" behaviors (certainly not standards), that
cannot all be resolved. In this case, we have to worry about past
gcc behavior and behavior of foreign compilers. The former is far
more important. The burden of introducing gratuitous incompatibilities
with existing code is very high. It is met if the standard insists
on a change, or if everyone agrees that a change is important enough
to tolerate the incompatibility. It is clear that in this case neither
case holds. So given the argument for change has failed to create a
consensus, it fails and should be ignored.

Re: backslash whitespace newline

[Mike Stump]

On Oct 26, 2005, at 9:39 AM, Andrew Pinski wrote:
I still am trying to figure out why this was even brought up if it  
was only due to ASCII art, that seems silly.


sorry ("I find ascii line art silly");  ;-)

We could do that!

If we didn't have any customers or if we expected they wouldn't bring  
new code in to gcc that traditionally had been compiled by other  
compilers, I'd see no point in doing it either.  When one has no  
customers or no code being ported into the platform, life is easier.   
gcc has had a long colorful history of actually having customers (Hi  
Joe) and having new code ported into the platform, I don't see a  
reason to abandon that tradition just yet.

Re: backslash whitespace newline

[Mike Stump]

On Oct 26, 2005, at 9:58 AM, Robert Dewar wrote:

No, conflicting "de facto" behaviors (certainly not standards), that
cannot all be resolved. In this case, we have to worry about past
gcc behavior and behavior of foreign compilers.


Yes.  I've asked, how many lines exist that rely upon this, the  
answer was zero.  We can have someone that has ready access to  
sourceforge or the google cache to count there (Hi Matt), to improve  
the answer, but my guess is that it would remain fairly low.

Re: backslash whitespace newline

[Dale Johannesen]

On Oct 25, 2005, at 5:40 PM, Joe Buck wrote:

The problem, I think, is that the behavior of both GCC *and* the
other compilers does not serve the users.

The reason is that there simply isn't any reason why a user would
use a backslash to continue a C++ comment on purpose, and plenty of
reason why she might do it by accident.

...users think they can put anything in a comment.  A backslash at the 
end is likely to be an accident,

since just starting the next line with a // is easy enough.


Yes.  From the user's point of view, the best thing appears to be
treating backslashes in C++ comments as part of the comment,
regardless of what follows them; that seems to follow the principle
of least surprise. That's not standard conforming, and therefore I'm
not advocating it for gcc, but it probably wouldn't break anything
outside compiler testsuites.  Maybe this treatment should be made
standard conforming...?

Re: backslash whitespace newline

[Andrew Pinski]

> 
> On Oct 26, 2005, at 9:39 AM, Andrew Pinski wrote:
> > I still am trying to figure out why this was even brought up if it  
> > was only due to ASCII art, that seems silly.
> 
> sorry ("I find ascii line art silly");  ;-)
> 
> We could do that!

That is just stupid, that is infact would be invalid to what the standards
says so it is not silly at all.  What I am trying to say is that
the only reason why this was brought up was because of some little
ASCII art (ASCII art does have its place in comments, see rs6000.c for
an example of where ASCII art actually helps).  If there was another
reason, like for an example someone depends on implementation defined
behavior which actually changes the meaning of the code like bitwise operators
See: 
http://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html#Integers-implementation

Another compiler could define >> with signed types the same as the
unsigned >> (I think there might be such a compiler too). 

We could have it defined as such that >> with signed types is the same as >> 
with
unsigned types, and the major other compilers do it a different way.

This is one case where changing is much harder and even worse as almost all
people depend on >> with signed types to act like the other compilers.

But since we are not dealing with comments, why this is not a hard decision
to make to stay with what we have already.  I am just trying to point
out that it was silly to bring the issue up if it only concerns comments.

-- Pinski

Re: backslash whitespace newline

[Andrew Pinski]

> 
> On Oct 26, 2005, at 9:58 AM, Robert Dewar wrote:
> > No, conflicting "de facto" behaviors (certainly not standards), that
> > cannot all be resolved. In this case, we have to worry about past
> > gcc behavior and behavior of foreign compilers.
> 
> Yes.  I've asked, how many lines exist that rely upon this, the  
> answer was zero.  We can have someone that has ready access to  
> sourceforge or the google cache to count there (Hi Matt), to improve  
> the answer, but my guess is that it would remain fairly low.

How many lines depend on this the other way?

The answer none.


-- Pinski

Re: backslash whitespace newline

[Kean Johnston]

worrying about other compilers in my opinion. Having gcc compile
non-portable code accepted by other compilers is a useful goal, but
one of low priority compared to maintaining compatibility as far as
possible between gcc versions.

You mean like the change between 2.95 that worked the way Howard
wanted it to, and 3.x (I dont know the value of x where the change
happened) where it doesn't?

This compiles on 2.95.3:

(There is whitespace at the end of the following line)
// comment \\
int x = 0;
int y = 1;
int foo() { return x + y;}

But doesn't on 3.4.4. I dont have earlier versions of 2.x or 3.x
to narrow it down further. Sorry. I beleive Pinski posted the
actual changelog entry where the change occured.

Kean

Re: backslash whitespace newline

[Robert Dewar]

Mike Stump wrote:

Yes.  I've asked, how many lines exist that rely upon this, the  answer 
was zero.  We can have someone that has ready access to  sourceforge or 
the google cache to count there (Hi Matt), to improve  the answer, but 
my guess is that it would remain fairly low.


of course that is only a part of the total source base, but I agree
it would be indicative. Of course you are probably also showing that
this is an unimportant issue not worth making a change for.

Re: backslash whitespace newline

[Robert Dewar]

Dale Johannesen wrote:


Yes.  From the user's point of view, the best thing appears to be
treating backslashes in C++ comments as part of the comment,
regardless of what follows them; that seems to follow the principle
of least surprise. That's not standard conforming, and therefore I'm
not advocating it for gcc, but it probably wouldn't break anything
outside compiler testsuites.  Maybe this treatment should be made
standard conforming...?


I agree this would be a far preferable definition, allowing comments
to be continued with a \ seems a truly silly feature.

Re: backslash whitespace newline

[Steven Bosscher]

On Wednesday 26 October 2005 18:58, Robert Dewar wrote:
> Steven Bosscher wrote:
> > On Wednesday 26 October 2005 18:28, Joe Buck wrote:
> >>That's what we have standards for: so that compilers work the same way
> >>for standard-conformant code.
> >
> > And we have de facto standards that you just want to ignore.
>
> No, conflicting "de facto" behaviors (certainly not standards), that
> cannot all be resolved. In this case, we have to worry about past
> gcc behavior and behavior of foreign compilers. The former is far
> more important.

The behavior changed from GCC 2.95 to GCC 3, so we already broke
compatibility with past GCC releases.
And most "outsider" people are only now beginning to port things
from 2.95 to something newer...

Gr.
Steven

Re: Out of curiosity: [EMAIL PROTECTED]

[DJ Delorie]

> It'll stay alive, but it'll get less and less useful, since it
> doesn't give any information you can't find with "svn log".

That's not the purpose of that list.  That list is to notify people of
commits that they might not have been aware of.  It needs to give
enough information to let the reader determine if they need to follow
up on that commit in some way.

The fact that you can manually obtain the information elsewhere is
irrelevant.

Re: backslash whitespace newline

[Scott Robert Ladd]

Robert Dewar wrote:

Seems a weak argument to me. Changing gcc would create incompatibilities
with previous behavior of gcc, and that is FAR more significant than
worrying about other compilers in my opinion. Having gcc compile
non-portable code accepted by other compilers is a useful goal, but
one of low priority compared to maintaining compatibility as far as
possible between gcc versions.


Wouldn't it be possible to implement a compile-time option to enable the 
desired behavior only for those poor folk who have this problem?


It's not as if GCC has been shy about adding options before. :)

The *default* behavior of the compiler should follow published standards 
first and past GCC behavior second (and both whenever possible). Support 
for "other compilers" is desirable, if it can be implemented without 
compromising those primary objectives.


--
Scott Robert Ladd <[EMAIL PROTECTED]>

Coyote Gulch Productions
http://www.coyotegulch.com

Re: Out of curiosity: [EMAIL PROTECTED]

[Paolo Carlini]

DJ Delorie wrote:

>>It'll stay alive, but it'll get less and less useful, since it
>>doesn't give any information you can't find with "svn log".
>>
>>
>That's not the purpose of that list.  That list is to notify people of
>commits that they might not have been aware of.  It needs to give
>enough information to let the reader determine if they need to follow
>up on that commit in some way.
>
>The fact that you can manually obtain the information elsewhere is
>irrelevant.
>  
>
Well, I agree ;) even if most of the times I'm using it via web as a
"point&click" replacement for cvs commands.

Paolo.

Re: Out of curiosity: [EMAIL PROTECTED]

[Daniel Berlin]

On Wed, 2005-10-26 at 18:18 +0200, Paolo Carlini wrote:
> What are the plans for it?

It will stay alive, and svn log messages will be sent there.


> 
> Often, I find it very useful, will be renamed to gcc-svn and kept alive?

I have no care in the world as to whether we rename it or not.  It's a
single line in the mailer.conf file for me :)

Others may have stronger opinions.


> 
> Thanks,
> Paolo.

Re: Out of curiosity: [EMAIL PROTECTED]

[Gabriel Dos Reis]

DJ Delorie <[EMAIL PROTECTED]> writes:

| The fact that you can manually obtain the information elsewhere is
| irrelevant.

Fully agreed.  I've found that list very useful for notifying me of
commits I've not been following closely.

-- Gaby

Inserting statements in tree-ssa form

[Mihai Burcea]

Hi, 

I have my own pass that is trying to insert some statements in the code; the
statements would be of the form var_name = constant_value;

This is gcc-4.0.0, on debian testing 2.6.8, on an Intel Pentium 4.

I am obviously missing something, but I am not sure what. I don't exactly
know how (or if I need) to create a new ssa number for that variable.
This happens for global and local variables.

What I am trying: (t->var_decl is the var_decl).

  gcc_assert (DECL_P (t->var_decl)); //this succeeds...
  new_var = duplicate_ssa_name (t->var_decl, NULL);
  //this crashes in an assert: gcc_assert (DECL_P (var) || TREE_CODE (var) == 
INDIRECT_REF);
  //I tried 2nd argument = NULL, and also SSA_NAME_DEF_STMT (t->var_decl).

If I do use duplicate_ssa_name(), I get the error pointed out above, i.e.,
in tree-flow-inline.h, in var_ann():

var_ann (tree t) {
  gcc_assert (t);
  gcc_assert (DECL_P (t)); //this assert fails

However, as you can see, t->var_decl IS a DECL, because it is a VAR_DECL,
since I evaluate it just above.

Ok, so I tried NOT using duplicate_ssa_name():

For global variables: if I don't use duplicate_ssa_name() (should I?), 
I can create and print the statement, but it crashes when I try to insert
it. The current pass dump file is completely generated, however, after my
pass I rerun the alias pass, and that is the one crashing.
So I am guessing I am screwing up the alias analysis info somehow.

I tried using get_var_ann (t->var_decl), to replicate the annotation
information in the newly created statement, but it didn't produce any
noticeable effect.

For local variables, I can even insert the statement, but, after the
function is processed, I get the same error as I was getting when using
duplicate_ssa_name(): failed gcc assert in var_ann(), in tree-flow-inline.h,
line 34 (gcc_assert (DECL_P(t))).

Any feedback would be appreciated, as it is probably obvious I am not really
certain exactly what I need to be able to generate new statements in the ssa
form...


thank you
mihai

HowTo Cross Compile GCC on x86 Host for PowerPC Target

[Jeff Stevens]

Is there a HowTo out there on how to cross compile GCC
to run on another platform?  I have an x86 host
running linux, and an embedded PowerPC 440SP target
running linux.  I would like to compile GCC to run on
the target but am having some difficulties.  I have
compiled the cross compiler fine, but when I try to
compile a native compiler, it acts just like the cross
compiler (runs on the host and not the target).  All I
did was re-run gcc configure and "make all install". 
Here is the configuration I ran:

../../source/gcc-3.4.4/configure
--target=powerpc-linux --host=powerpc-linux
--prefix=/opt/luan2/toolchain/bin --enable-shared
--enable-threads --enable-languages=c

I'm obviously missing something, but can't seem to
find anything on the internet that explains
cross-compiling gcc for another target.

Thanks,
   Jeff Stevens



__ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

Re: backslash whitespace newline

[Robert Dewar]

Scott Robert Ladd wrote:

Wouldn't it be possible to implement a compile-time option to enable the 
desired behavior only for those poor folk who have this problem?


Of course this is possible, but it is only worth it if

a) there are a substantial number of such poor folk

b) it is not easy for them to do what they want without the option

I don't see either is true here.

Re: backslash whitespace newline

[Eric Christopher]

I don't see either is true here.



Actually, I agree. While I'd like the change to the compiler, I don't  
want it to be a switch. Either we do it, or we don't.


-eric

RE: backslash whitespace newline

[Dave Korn]

Scott Robert Ladd wrote:
> Robert Dewar wrote:
>> Seems a weak argument to me. Changing gcc would create incompatibilities
>> with previous behavior of gcc, and that is FAR more significant than
>> worrying about other compilers in my opinion. Having gcc compile
>> non-portable code accepted by other compilers is a useful goal, but
>> one of low priority compared to maintaining compatibility as far as
>> possible between gcc versions.
> 
> Wouldn't it be possible to implement a compile-time option to enable the
> desired behavior only for those poor folk who have this problem?

  Yes, absolutely so.  Just add a flag in the usual way, test for it in
cpplex.c/skip_escaped_newlines, and change the bit that says

  if (saved_cur != buffer->cur - 1
  && !pfile->state.lexing_comment)
cpp_error (pfile, DL_WARNING,
   "backslash and newline separated by space");

so that according to the flag setting, it could either issue a DL_WARNING as
it currently does, or the level could be changed to DL_PEDWARN or DL_ERROR, or
it could skip the cpp_error call altogether.

  Generating the actual patch is left as an exercise for the reader[*]!


cheers,
  DaveK

[*]  Or whoever else actually _cares_ about this more than I do!
-- 
Can't think of a witty .sigline today

RE: HowTo Cross Compile GCC on x86 Host for PowerPC Target

[Dave Korn]

Jeff Stevens wrote:
> Is there a HowTo out there on how to cross compile GCC
> to run on another platform?  I have an x86 host
> running linux, and an embedded PowerPC 440SP target
> running linux.  I would like to compile GCC to run on
> the target but am having some difficulties.  I have
> compiled the cross compiler fine, but when I try to
> compile a native compiler, it acts just like the cross
> compiler (runs on the host and not the target).  All I

  *All* compilers "run on the host"; the term "host" is defined as "the
machine on which the compiler runs".  The target is the machine on which the
_generated_ code runs.  So for a native compiler, host==target, and for a
cross-compiler, host!=target.

> did was re-run gcc configure and "make all install".
> Here is the configuration I ran:
> 
> ../../source/gcc-3.4.4/configure
> --target=powerpc-linux --host=powerpc-linux
> --prefix=/opt/luan2/toolchain/bin --enable-shared
> --enable-threads --enable-languages=c

  If you want a native compiler, you would want to have an x86 target where
you've written powerpc-linux.

  Even better, to get a native compiler, just don't specify --target or --host
at all; configure will assume by default that you want a native compiler, work
out what machine it thinks you're running on, and set up everything just right
for you, automatically!
 
> I'm obviously missing something, but can't seem to
> find anything on the internet that explains
> cross-compiling gcc for another target.

  Check the cross-gcc mailing list http://sourceware.org/ml/crossgcc/, and Dan
Kegel's crosstool http://kegel.com/crosstool/.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

RE: HowTo Cross Compile GCC on x86 Host for PowerPC Target

[Dave Korn]

Dave Korn wrote:
> Jeff Stevens wrote:
>> Is there a HowTo out there on how to cross compile GCC
>> to run on another platform?  I have an x86 host
>> running linux, and an embedded PowerPC 440SP target
>> running linux.  I would like to compile GCC to run on
>> the target but am having some difficulties.  I have
>> compiled the cross compiler fine, but when I try to
>> compile a native compiler, it acts just like the cross
>> compiler (runs on the host and not the target).  All I
> 
>   *All* compilers "run on the host"; the term "host" is defined as "the
> machine on which the compiler runs".  The target is the machine on which
> the _generated_ code runs.  So for a native compiler, host==target, and
> for a cross-compiler, host!=target.

  Doh.  I misread this; I see now that what you mean is you wanted a native
compiler on the target.  

>> did was re-run gcc configure and "make all install".
>> Here is the configuration I ran:
>> 
>> ../../source/gcc-3.4.4/configure
>> --target=powerpc-linux --host=powerpc-linux
>> --prefix=/opt/luan2/toolchain/bin --enable-shared
>> --enable-threads --enable-languages=c

  So, this should have worked.  Did you perhaps re-build in the same directory
that you had already configured the cross-compiler in without first running
"make clean" perhaps?  Was the powerpc-linux cross compiler placed in your
$PATH setting, so that configure could find the powerpc-linux-gcc executable?

  [ This is OT for this list really; we really should take it to crossgcc ]


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: HowTo Cross Compile GCC on x86 Host for PowerPC Target

[Richard Guenther]

On 10/26/05, Dave Korn <[EMAIL PROTECTED]> wrote:
> Jeff Stevens wrote:
> > Is there a HowTo out there on how to cross compile GCC
> > to run on another platform?  I have an x86 host
> > running linux, and an embedded PowerPC 440SP target
> > running linux.  I would like to compile GCC to run on
> > the target but am having some difficulties.  I have
> > compiled the cross compiler fine, but when I try to
> > compile a native compiler, it acts just like the cross
> > compiler (runs on the host and not the target).  All I
>
>   *All* compilers "run on the host"; the term "host" is defined as "the
> machine on which the compiler runs".  The target is the machine on which the
> _generated_ code runs.  So for a native compiler, host==target, and for a
> cross-compiler, host!=target.

I think he wants to build a native powerpc compiler using the previously
built cross-compiler.  Of course you need to use the cross-compiler just
built, so specify CC=gcc-powerpc-whatever ./configure ...

Richard.

> > did was re-run gcc configure and "make all install".
> > Here is the configuration I ran:
> >
> > ../../source/gcc-3.4.4/configure
> > --target=powerpc-linux --host=powerpc-linux
> > --prefix=/opt/luan2/toolchain/bin --enable-shared
> > --enable-threads --enable-languages=c
>
>   If you want a native compiler, you would want to have an x86 target where
> you've written powerpc-linux.
>
>   Even better, to get a native compiler, just don't specify --target or --host
> at all; configure will assume by default that you want a native compiler, work
> out what machine it thinks you're running on, and set up everything just right
> for you, automatically!
>
> > I'm obviously missing something, but can't seem to
> > find anything on the internet that explains
> > cross-compiling gcc for another target.
>
>   Check the cross-gcc mailing list http://sourceware.org/ml/crossgcc/, and Dan
> Kegel's crosstool http://kegel.com/crosstool/.
>
>
> cheers,
>   DaveK
> --
> Can't think of a witty .sigline today
>
>

notes, presentations from GCC Improvement for Itanium sessions at Gelato meeting, Oct 3-4, 2005

[Mark K. Smith]

http://gcc.gelato.org/PortoAlegreMeeting

We had excellent sessions and extended time to discuss improving GCC
on Itanium. Please refer to the discussion notes for additional
information. Many thanks to the presenters and to Shin-ming Liu (HP)
for leading the discussion.

RE: HowTo Cross Compile GCC on x86 Host for PowerPC Target

[Jeff Stevens]

Yes I added the cross-compiler to the path and created
a separate build directory (ppc_gcc).  

Thanks,
   Jeff Stevens

--- Dave Korn <[EMAIL PROTECTED]> wrote:

> Dave Korn wrote:
> > Jeff Stevens wrote:
> >> Is there a HowTo out there on how to cross
> compile GCC
> >> to run on another platform?  I have an x86 host
> >> running linux, and an embedded PowerPC 440SP
> target
> >> running linux.  I would like to compile GCC to
> run on
> >> the target but am having some difficulties.  I
> have
> >> compiled the cross compiler fine, but when I try
> to
> >> compile a native compiler, it acts just like the
> cross
> >> compiler (runs on the host and not the target). 
> All I
> > 
> >   *All* compilers "run on the host"; the term
> "host" is defined as "the
> > machine on which the compiler runs".  The target
> is the machine on which
> > the _generated_ code runs.  So for a native
> compiler, host==target, and
> > for a cross-compiler, host!=target.
> 
>   Doh.  I misread this; I see now that what you mean
> is you wanted a native
> compiler on the target.  
> 
> >> did was re-run gcc configure and "make all
> install".
> >> Here is the configuration I ran:
> >> 
> >> ../../source/gcc-3.4.4/configure
> >> --target=powerpc-linux --host=powerpc-linux
> >> --prefix=/opt/luan2/toolchain/bin --enable-shared
> >> --enable-threads --enable-languages=c
> 
>   So, this should have worked.  Did you perhaps
> re-build in the same directory
> that you had already configured the cross-compiler
> in without first running
> "make clean" perhaps?  Was the powerpc-linux cross
> compiler placed in your
> $PATH setting, so that configure could find the
> powerpc-linux-gcc executable?
> 
>   [ This is OT for this list really; we really
> should take it to crossgcc ]
> 
> 
> cheers,
>   DaveK
> -- 
> Can't think of a witty .sigline today
> 
> 




__ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

Re: backslash whitespace newline

[Howard Hinnant]

On Oct 26, 2005, at 1:16 PM, Andrew Pinski wrote:


What I am trying to say is that
the only reason why this was brought up was because of some little
ASCII art (ASCII art does have its place in comments, see rs6000.c for
an example of where ASCII art actually helps).  If there was another
reason, like for an example someone depends on implementation defined
behavior which actually changes the meaning of the code like  
bitwise operators


I believe I may have not described the situation sufficiently  
clearly.  My apologies.


Yes, this does have to do with ASCII art.  But no, it is not simply a  
matter of messing up the comments.  Code behavior can change.  What  
was working code can stop working.  Or even worse, the code can  
compile and have different run time behavior:


int x = 0;

void f()
{
// ascii art \  
   int x = 1;
   if (x)
   do_thing1();
   else
   do_thing2();
}

If end-of-line white space is stripped in phase 1, do_thing2() is  
called.  If end-of-line white space is not stripped, do_thing1() is  
called.


-Howard

Re: backslash whitespace newline

[Stan Shebs]

Joe Buck wrote:


On Tue, Oct 25, 2005 at 08:22:15PM -0400, Howard Hinnant wrote:

And it is not my assertion that gcc's behavior is better or worse  
than other compilers.  Only that gcc's behavior is unique in the  
industry (I actually haven't tried all other modern compilers) and  
that uniqueness in this way is not an asset to gcc.




gcc is "unique in the industry" in any number of ways, as is every
other compiler -- in that each of them will have some kind of behavior
that is perhaps odd, but might have been accidentally exploited by
a programmer who just whacks away at code and accepts anything that
happens to compile.

I'm still waiting for an explanation as to why this is an important
issue, other than that someone has a customer who says that it is.
Why is it important to the customer?


With all that's going on in politics right now :-) , we Appleites
are being somewhat careful to not give away too much detail
about the users in question. I think it's safe to say that they
are large important code bases, and that this is a historic
opportunity for GCC to displace proprietary compilers out of
some longtime strongholds. Thus we want to ease the transition,
not put up additional obstacles, especially over borderline-
pedantic issues (one-line sed script is easy, revving multiple
multi-million-line source bases, not so much).

Again, I think this could be easily addressed in Apple's GCC only,
but that will mean that the software in question will compile on Macs,
but not on GNU/Linux. Of course, having apps on OS X that can't
be ported to Linux is not necessarily a bad thing from Apple's
point of view... :-)

Stan

Re: HowTo Cross Compile GCC on x86 Host for PowerPC Target

[Andreas Schwab]

Jeff Stevens <[EMAIL PROTECTED]> writes:

> Here is the configuration I ran:
>
> ../../source/gcc-3.4.4/configure
> --target=powerpc-linux --host=powerpc-linux
> --prefix=/opt/luan2/toolchain/bin --enable-shared
> --enable-threads --enable-languages=c

You need to specify --build, otherwise it defaults to host.

> I'm obviously missing something, but can't seem to
> find anything on the internet that explains
> cross-compiling gcc for another target.

Try looking up "gcc canadian cross".

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Inserting statements in tree-ssa form

[Diego Novillo]

On Wednesday 26 October 2005 14:34, Mihai Burcea wrote:

> I have my own pass that is trying to insert some statements in the code;
> the statements would be of the form var_name = constant_value;
>
After you create the variables with create_tmp_var, you mark them to be 
rewritten by adding them to vars_to_rename.  See the section 'Preserving 
SSA form' in the internals documentation.  For examples on how this work 
you can browse tree-ssa-pre.c, which inserts new code and does some of the 
things you're trying to do.

What is really a new line in most compilers

[Andrew Pinski]

Take the following C program, and try to compile the resulting
code it outputs:
#include 
int main(void)
{
  printf("// \\\r\n a\n int i;\n");
  printf("// \\\r a\r int i1;\n");
  printf("int f(void) { return i1;}\n");
}

Here is the results:
GCC accepts it as \r is consider a newline
ICC rejects it as \r is not considered a newline.

This seems inconstaint for ICC as it considers \r\n as a newline but \r as a 
white space.

-- Pinski

Re: What is really a new line in most compilers

[DJ Delorie]

> This seems inconstaint for ICC as it considers \r\n as a newline but
> \r as a white space.

Note that on Windows/DOS/CPM based platforms, \r\n *is* a newline.  It
is not defined what happens if you see those characters separately in
a text file, and different applications do different things upon
encountering them alone.  For example, DJGPP and Borland hosted
programs discard all \r characters and look for any remaining \n's as
newlines, but Windows Notepad will treat bare \n's as printable
characters!

To add to that, Mac text files use a bare \r as a newline.

So it's not surprising that odd things happen to bare \r's, and IMHO
we've been around and around about them enough in the past that we
don't need to do it again, nor should we change how gcc intreprets
\r's without a LOT of good justification.

So IMHO any oddities due to bare \r's are the user's problem.

Re: What is really a new line in most compilers

[Howard Hinnant]

On Oct 26, 2005, at 4:58 PM, DJ Delorie wrote:


To add to that, Mac text files use a bare \r as a newline.


Just a nit:  5 years ago that was true.  Now \n is "native" but most  
Mac software is pretty tolerant of newline representation due to its  
history.


-Howard

Re: What is really a new line in most compilers

[DJ Delorie]

> Just a nit:  5 years ago that was true.  Now \n is "native"

Was that part of the OS/X migration, or otherwise?  Just curious.

> but most Mac software is pretty tolerant of newline representation
> due to its history.

Of course, that only makes it *more* of a mess, and *less* likely that
gcc is going to please everyone :-P

Re: What is really a new line in most compilers

[Howard Hinnant]

On Oct 26, 2005, at 5:17 PM, DJ Delorie wrote:





Just a nit:  5 years ago that was true.  Now \n is "native"



Was that part of the OS/X migration, or otherwise?  Just curious.


 Part of the migration.  OS X /is/ unix.  Ok, I'm sure that's an  
inaccurate statement and I trust the more experienced Apple guys here  
will gently correct me.  But it really is... ;-)



but most Mac software is pretty tolerant of newline representation
due to its history.



Of course, that only makes it *more* of a mess, and *less* likely that
gcc is going to please everyone :-P


Yeah, I figured I should've defined "tolerant" a little better. :-)

-Howard

Re: backslash whitespace newline

[Robert Dewar]

Howard Hinnant wrote:

If end-of-line white space is stripped in phase 1, do_thing2() is  
called.  If end-of-line white space is not stripped, do_thing1() is  
called.


SO this is truly appallingly bad code, given its behavior depends
so radically on an implementation defined feature!

Probably this shows that some warnings are needed in this situation
at the very least.

Re: backslash whitespace newline

[Robert Dewar]

Stan Shebs wrote:


Again, I think this could be easily addressed in Apple's GCC only,
but that will mean that the software in question will compile on Macs,
but not on GNU/Linux. Of course, having apps on OS X that can't
be ported to Linux is not necessarily a bad thing from Apple's
point of view... :-)

Stan


Don't you think it is reasonable to fix horrible coding
errors like this, you are just asking for maintenance
problems. In the short term, kludging may make sense,
in the long term it sounds a bad idea to keep such
non-portable code around.

Re: backslash whitespace newline

[Eric Christopher]

Don't you think it is reasonable to fix horrible coding
errors like this, you are just asking for maintenance
problems. In the short term, kludging may make sense,
in the long term it sounds a bad idea to keep such
non-portable code around.


The problem is that it's portable to every other compiler we've
tested. I am curious what icc and xlc do, but those are the only
two not tested.

-eric

Re: backslash whitespace newline

[Andrew Pinski]

> 
> >
> > Don't you think it is reasonable to fix horrible coding
> > errors like this, you are just asking for maintenance
> > problems. In the short term, kludging may make sense,
> > in the long term it sounds a bad idea to keep such
> > non-portable code around.
> 
> The problem is that it's portable to every other compiler we've
> tested. I am curious what icc and xlc do, but those are the only
> two not tested.

I already tested ICC and it does exactly what EDG does because well
it just uses the EDG front-end.  Now one could agrue that ICC has
a bug in their GCC compatibility code as they mention they are
source compatible with GCC.

-- Pinski

Re: backslash whitespace newline

[Robert Dewar]

Eric Christopher wrote:


Don't you think it is reasonable to fix horrible coding
errors like this, you are just asking for maintenance
problems. In the short term, kludging may make sense,
in the long term it sounds a bad idea to keep such
non-portable code around.



The problem is that it's portable to every other compiler we've
tested. I am curious what icc and xlc do, but those are the only
two not tested.


Sorry, I have a different meaning of portable, for me the term is
related to the standard, meaning that standard conforming compilers
are required to process the code correctly.

"Happens to work on (some/most/all) compilers" is not the same
thing at all for me. COmpetent programmers write portable code
by knowing what the standard requires, not by trial and error :-)

Re: semantics of null lang_hooks.callgraph.expand_function?

[Jim Wilson]

Gary Funck wrote:

While working with GCC's language hooks, we found that
certain places in GCC test for a null value of
lang_hooks.callgraph.expand_function, but
cgraph_expand_function() calls the hook directly:


When cgraph was first added, it was optional, and could be disabled if 
-fno-unit-at-a-time was used, or if the language front-end did not 
support cgraph.


For a while, our intentions have been to make this mandatory, and 
eliminate the -fno-unit-at-a-time option.  It appears that we have 
already reached the point where front end support for cgraph is 
mandatory, as the code no longer works when callgraph.expand_function is 
NULL.  This means all of the checks for NULL are now obsolete and can be 
removed.  The -fno-unit-at-a-time options still exists meanwhile, but 
will eventually be dropped.


It looks like gcc-3.4 supports a NULL callgraph.expand_function hook, 
and gcc-4.0 and later do not, so I'd guess this transition happened when 
tree-ssa got merged in.  Or maybe it was enabled by the tree-ssa work.

--
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: semantics of null lang_hooks.callgraph.expand_function?

[Jim Wilson]

Dueway Qi wrote:

I have found another similar case.
lang_hooks.callgraph.analyze_expr  in  gcc/gcc/cgraphunit.c
490   if (lang_hooks.callgraph.analyze_expr)
491 return lang_hooks.callgraph.analyze_expr (tp, walk_subtrees,
492   data);
but in another part of this file
517   if ((unsigned int) TREE_CODE (t) >= LAST_AND_UNUSED_TREE_CODE)
518 return lang_hooks.callgraph.analyze_expr (tp,
walk_subtrees, data);


The docs say that analyze_expr is used for unrecognized tree codes.  So 
if a front end will generate unrecognized tree codes, then it must 
define the analyze_expr hook.  This explains the second part of this. 
If we see an unrecognized tree code, then there is no real need to check 
if analyze_expr is defined, because it must be defined.  This means 
someone writing a language front end would get an ICE here, but an end 
user would not.  This could be a bit nicer for a language front end 
writer, but this doesn't look like a serious problem.


For the first part of this, we don't know for sure if we have any 
unrecognized tree codes, so we can't assume that the analyze_expr hook 
is defined.  We must check first.


This is an analysis from just looking at the code.  I haven't tried to 
debug it and see what is really going on.

--
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: semantics of null lang_hooks.callgraph.expand_function?

[Neil Booth]

Jim Wilson wrote:-

> Gary Funck wrote:
> >While working with GCC's language hooks, we found that
> >certain places in GCC test for a null value of
> >lang_hooks.callgraph.expand_function, but
> >cgraph_expand_function() calls the hook directly:
> 
> When cgraph was first added, it was optional, and could be disabled if 
> -fno-unit-at-a-time was used, or if the language front-end did not 
> support cgraph.
> 
> For a while, our intentions have been to make this mandatory, and 
> eliminate the -fno-unit-at-a-time option.  It appears that we have 
> already reached the point where front end support for cgraph is 
> mandatory, as the code no longer works when callgraph.expand_function is 
> NULL.  This means all of the checks for NULL are now obsolete and can be 
> removed.  The -fno-unit-at-a-time options still exists meanwhile, but 
> will eventually be dropped.
> 
> It looks like gcc-3.4 supports a NULL callgraph.expand_function hook, 
> and gcc-4.0 and later do not, so I'd guess this transition happened when 
> tree-ssa got merged in.  Or maybe it was enabled by the tree-ssa work.

In general I think the idea with hooks, whether language or target,
was that they were all non-NULL and so we avoided this issue and
scattering conditionals everywhere.  If you wanted to do nothing you
used an empty hook, which was usually the default.

Neil.

Re: backslash whitespace newline

[Vincent Lefevre]

On 2005-10-26 12:39:31 -0400, Andrew Pinski wrote:
> But in a way you are defending it as you want GCC to change.  If there
> was any other reason besides ASCII art, some people would be more willing
> to change but there is a simple fix person's code to get around this issue.
> And that is by not using C++ style comments and just use C style ones.

Adding a line

//

just after the ASCII art would be even easier.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: backslash whitespace newline

[Vincent Lefevre]

On 2005-10-25 21:25:03 -0700, Joe Buck wrote:
> Code that depends on invisible whitespace to function correctly is
> already broken.  At some point, someone will do the equivalent of
  ^^^
> delete-trailing-whitespace and break it.

or some software. I've already seen that with mailing-list archives
on the web.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: backslash whitespace newline

[Howard Hinnant]

On Oct 26, 2005, at 6:50 PM, Robert Dewar wrote:


The problem is that it's portable to every other compiler we've
tested. I am curious what icc and xlc do, but those are the only
two not tested.



Sorry, I have a different meaning of portable, for me the term is
related to the standard, meaning that standard conforming compilers
are required to process the code correctly.

"Happens to work on (some/most/all) compilers" is not the same
thing at all for me. COmpetent programmers write portable code
by knowing what the standard requires, not by trial and error :-)


I couldn't agree with you more on that statement.  But I'll follow it  
up with:  competent tool writers make their tools so robust that even  
incompetent programmers have trouble abusing them.


Now I know that no tool is fool proof.  We all know the fools are  
getting more clever every year.  But here is a little thing we could  
do to make our tool a little more fool proof.


-Howard

[Steven Woody] M16C development using GCC, Is It Possible?

[Steven Woody]

i am currently working on a project of building M16C programs. i have an IRA
M16C/I8C C/C++ compiler on hand, but it is for Windows and i just can not live
w/o my Linux box. another reason i have to use GCC is that i must use some unit
test tools which ask for gcc.

i heard that gcc is also a cross-compiler, so i want to get know if it can
be used as an M16C compiler? in GCC's home page, there is one item:

'July 20, 2005
Red Hat Inc has contributed a port for the Renesas R8C/M16C/M32C families'

what that really means?  and in this page
'http://a15177702.alturo-server.de/gcc-m16c/20050419.html', it said, GCC
M16C project is totally bugy.

so, what's the fact and what's your suggestion? (BTW: i need compile C++ not C
only)

thanks!

-- 
steven woody (id: narke)

Re: backslash whitespace newline

[Joe Buck]

On Thu, Oct 27, 2005 at 01:48:57AM +0200, Vincent Lefevre wrote:
> On 2005-10-26 12:39:31 -0400, Andrew Pinski wrote:
> > But in a way you are defending it as you want GCC to change.  If there
> > was any other reason besides ASCII art, some people would be more willing
> > to change but there is a simple fix person's code to get around this issue.
> > And that is by not using C++ style comments and just use C style ones.
> 
> Adding a line
> 
> //
> 
> just after the ASCII art would be even easier.

Eureka!

Re: [Steven Woody] M16C development using GCC, Is It Possible?

[DJ Delorie]

> i heard that gcc is also a cross-compiler, so i want to get know if
> it can be used as an M16C compiler?

Yes.  The target you want to use to build gcc et al is "m32c-elf".

To compile for the m16c specifically, use "m32c-elf-gcc -mcpu=m16c ..."

> in GCC's home page, there is one item:
>
> 'July 20, 2005
> Red Hat Inc has contributed a port for the Renesas R8C/M16C/M32C families'
> 
> what that really means?

It means that Red Hat Inc has modified gcc (and binutils and newlib)
to support the r8c/m16c/m32c family of processors from Renesas, and
given those changes to the FSF to be integrated into their official
sources.

gdb and a simulator are still in progress.

> and in this page
> 'http://a15177702.alturo-server.de/gcc-m16c/20050419.html', it said, GCC
> M16C project is totally bugy.

That's a different attempt to port gcc to m16c, and has nothing to do
with what I did.

> (BTW: i need compile C++ not C only)

Note that I haven't gotten around to supporting C++ yet.  You can try
to build it if you want, but I had deferred it due to other more
important issues, and haven't had a chance to work on it.  It might
"just work", you never know ;-)

Re: backslash whitespace newline

[Eric Christopher]

On Oct 26, 2005, at 5:55 PM, Joe Buck wrote:


On Thu, Oct 27, 2005 at 01:48:57AM +0200, Vincent Lefevre wrote:

On 2005-10-26 12:39:31 -0400, Andrew Pinski wrote:
But in a way you are defending it as you want GCC to change.  If  
there
was any other reason besides ASCII art, some people would be more  
willing
to change but there is a simple fix person's code to get around  
this issue.
And that is by not using C++ style comments and just use C style  
ones.


Adding a line

//

just after the ASCII art would be even easier.


Eureka!


Yup. I've mentioned it. Boy have I mentioned it. :)

However, the "this is a small implementation defined issue that's  
easy to change for users that are migrating from other compilers"  
issue remains.


-eric

re: M16C development using GCC, Is It Possible?

[Dan Kegel]

> i am currently working on a project of building M16C programs. i have an IRA
> M16C/I8C C/C++ compiler on hand, but it is for Windows and i just can not live
> w/o my Linux box.

Could you perhaps run the compiler under Wine?