How to Properly Set a Tree Member Variable

[Tom Browder]

I'm trying to help Tim Josling get the old gcc cobol front end code
working with the gcc trunk
again.  I'm struggling with trying to learn usage of tree macros while
dealing with code dating from about gcc 3.2 or so.

I have the following lines of code:

 tree parm_decl;
 ...
 /* the following two lines give a gcc error: lvalue required as left
operand of assignment */
 DECL_SOURCE_FILE (parm_decl) = local_input_filename;
 DECL_SOURCE_LINE (parm_decl) = lineno;

Apparently this code worked at one time.

I know I can decode the macros and deal with the "real" variables but
what is the correct way to set the parm_decl members?

I haven't found the right spot in "GCC Compiler Collection Internals"
yet and I'm getting dizzy back tracking macro definitions.

Any hints would be appreciated.

Thanks.

-Tom

Re: Magic incantation for running multilib testsuite.

[Matthias Klose]

Kaveh R. GHAZI writes:
> On Sun, 27 Jan 2008, Matthias Klose wrote:
> 
> > David Daney writes:
> > > I have tried several times (and failed) to run the GCC testsuite on
> > > multilib targets (x86-64 and mips64) and have not been able to figure
> > > out how to get more that a single multilib configuration to be tested.
> > > The instructions on http://gcc.gnu.org/install/test.html are not working
> > > for me.  I think I want something like:
> > >
> > > $ make -k check  RUNTESTFLAGS="--target_board=unix/{,-m32}"
> >
> > when running with make -j, the testsuite is still run sequentially for
> > each pass; is there a way to run the passes in parallel?
> >   Matthias
> 
> I believe yes, I haven't tried it but see the end of item 0.2 here:
> http://gcc.gnu.org/install/test.html
> 
> It says this feature is only supported in the gcc subdirectory.  (I don't
> know if that's current or not.)  I suppose that means the top level target
> library tests are not handled in parallel for their multilibs.
> 
> I'd be interested in your results if you try it out.

- doesn't work for the toplevel makefile

- $ make -j3 -C build/gcc check-{objc,obj-c++}//unix/{,-m64}
+ make -j3 -C build/gcc check-objc//unix/ check-objc//unix/-m64 
check-obj-c++//unix/ check-obj-c++//unix/-m64
make: Entering 
directory`/scratch/packages/gcc/4.3/gcc-4.3-4.3-20080127/build/gcc'
[...]
[print objc summaries]
[...]
make[1]: Leaving 
directory`/scratch/packages/gcc/4.3/gcc-4.3-4.3-20080127/build/gcc'
make: Nothing to be done for `check-obj-c++//unix/'.
make[1]: Leaving 
directory`/scratch/packages/gcc/4.3/gcc-4.3-4.3-20080127/build/gcc'
make: Nothing to be done for `check-obj-c++//unix/-m64'.
make: Leaving 
directory`/scratch/packages/gcc/4.3/gcc-4.3-4.3-20080127/build/gcc'

the arguments are expanded correctly, but the testsuite is only run
for the first check-XXX target. why?

- treelang doesn't support the patterns, will send a patch.

- you have to use different target names for the parallel runs
  (check-g++ instead of check-c++, check-gfortran instead of check-fortran)

- it takes more than adding a check/%% target to the libxxx/testsuite/Makefile's
  the passes are run in parallel, but do use the the testsuite
  directory and overwrite files.

Matthias

Re: How to Properly Set a Tree Member Variable

[Andreas Schwab]

"Tom Browder" <[EMAIL PROTECTED]> writes:

> I have the following lines of code:
>
>  tree parm_decl;
>  ...
>  /* the following two lines give a gcc error: lvalue required as left
> operand of assignment */
>  DECL_SOURCE_FILE (parm_decl) = local_input_filename;
>  DECL_SOURCE_LINE (parm_decl) = lineno;
>
> Apparently this code worked at one time.

You need to set DECL_SOURCE_LOCATION now.

> I know I can decode the macros and deal with the "real" variables but
> what is the correct way to set the parm_decl members?

Take a look at tree.h.

Andreas.

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

inclhacks vs. latest autogen?

[Dave Korn]

Hi all,

  I'm using the very latest autogen:

/gnu/gcc/obj $ autogen --version
autogen (GNU AutoGen) - The Automated Program Generator - Ver. 5.9.4

  It doesn't seem to like our syntax in inclhacks.def any more:

checking whether to enable maintainer-specific portions of Makefiles... yes
configure: creating ./config.status
/bin/sh ./config.status Makefile
config.status: creating Makefile
make[3]: Leaving directory
`/win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes'
make[3]: Entering directory
`/win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes'
cd /gnu/gcc/gcc/fixincludes ; /bin/sh ./genfixes
AutoGen-ing fixincl.x
autogen Error: Invalid input char '*' in inclhack.def on line 1088
Makefile:128: *** [/gnu/gcc/gcc/fixincludes/fixincl.x] Error 1

#0  /gnu/gcc/gcc/fixincludes/fixincl.x at
/win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes/Makefile:128
#1  fixincl.o at
/win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes/Makefile:116
#2  full-stamp at
/win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes/Makefile:105
#3  oneprocess at
/win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes/Makefile:102
#4  all at ??
make[3]: Leaving directory
`/win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes'
Command-line arguments:
"all"
Makefile:2784: *** [all-build-fixincludes] Error 2

  It's pointing at some globs in shell syntax:

/gnu/gcc/obj $ cat -n /gnu/gcc/gcc/fixincludes/inclhack.def | grep -C3 1088
  1085   */
  1086  fix = {
  1087  hackname  = bsd_stdio_attrs_conflict;
  1088  mach  = *-*-*bsd*;
  1089  mach  = *-*-*darwin*;
  1090  files = stdio.h;
  1091  select= "^#define[ \t]*vfscanf[ \t]*__svfscanf[ \t]*$";
/gnu/gcc/obj $


  This isn't a recent change, so I'm assuming autogen has changed.  What
versions are other people running?


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

Re: GCC 4.3 target deprecation proposals (about DJGPP)

[Andris Pavenis]

Ben Elliston wrote:

On Wed, 2008-01-23 at 12:02 -0500, DJ Delorie wrote:


DJGPP,

Please don't deprecate this.  It's actively used, but the test harness
doesn't run under DJGPP so testing it is difficult.  I don't think
we've *ever* run the testsuite for it.


You can't cross-test, with DejaGnu running elsewhere?


Theoretically it maybe could possibly be done, but the main problem
is perhaps available manpower. I released  DJGPP packages
of GCC for long time up to version 4.2.2 (native compiler
and for last versions also Linux to DJGPP cross-compiler RPM
packages).

I have also tried to build 4.3 snapshots as native compiler
for DJGPP, but run into trouble with broken DJGPP port of BASH (latest
we have is bash-2.0.5b), which prevented build to work for
libstdc++-v3. I tried to fix it, but there were still problems.
I don't know when I'll have time to fix them.

Additionally there is rather large set of patches I need to apply
for building GCC for DJGPP. I haven't had time get them in.

Andris

Re: Mainline is now regression and documentation fixes only

[Bernhard Fischer]

On Fri, Jan 25, 2008 at 03:51:27PM +0100, Paolo Bonzini wrote:
> Jakub Jelinek wrote:
>> On Wed, Jan 23, 2008 at 06:50:02PM +0100, Bernhard Fischer wrote:
>>> On Wed, Jan 23, 2008 at 12:06:22PM +0100, Richard Guenther wrote:
 As we now reached the goal of less than 100 open serious regressions
 against GCC 4.3, we are as of now in regression and documentation fixes
 only mode.  This means that for patches going on the trunk the same
 rules as for release branches apply.
>>> While not strictly a regression, is there any chance that we could get
>>> this reviewed an applied?
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00995.html
>>
>> I think an exception could be made for this, the risks are small
>> and it should impact just uclibc.  But you'd need one of the configury
>> maintainers to ack it.
>
> Ok in 48 hours if no one will have objected.

Applied to trunk as revision 131884.

Thanks!

Re: inclhacks vs. latest autogen?

[Ismail Dönmez]

Hi,

Sunday 27 January 2008 16:37:37 tarihinde Dave Korn şunları yazmıştı:
>   I'm using the very latest autogen:
>
> /gnu/gcc/obj $ autogen --version
> autogen (GNU AutoGen) - The Automated Program Generator - Ver. 5.9.4
>
>   It doesn't seem to like our syntax in inclhacks.def any more:
>
> checking whether to enable maintainer-specific portions of Makefiles... yes
> configure: creating ./config.status
> /bin/sh ./config.status Makefile
> config.status: creating Makefile
> make[3]: Leaving directory
> `/win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes'
> make[3]: Entering directory
> `/win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes'
> cd /gnu/gcc/gcc/fixincludes ; /bin/sh ./genfixes
> AutoGen-ing fixincl.x
> autogen Error: Invalid input char '*' in inclhack.def on line 1088
> Makefile:128: *** [/gnu/gcc/gcc/fixincludes/fixincl.x] Error 1
>
> #0  /gnu/gcc/gcc/fixincludes/fixincl.x at
> /win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes/Makefile:128
> #1  fixincl.o at
> /win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes/Makefile:116
> #2  full-stamp at
> /win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes/Makefile:105
> #3  oneprocess at
> /win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes/Makefile:102
> #4  all at ??
> make[3]: Leaving directory
> `/win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes'
> Command-line arguments:
>   "all"
> Makefile:2784: *** [all-build-fixincludes] Error 2
>
>   It's pointing at some globs in shell syntax:
>
> /gnu/gcc/obj $ cat -n /gnu/gcc/gcc/fixincludes/inclhack.def | grep -C3 1088
>   1085   */
>   1086  fix = {
>   1087  hackname  = bsd_stdio_attrs_conflict;
>   1088  mach  = *-*-*bsd*;
>   1089  mach  = *-*-*darwin*;
>   1090  files = stdio.h;
>   1091  select= "^#define[ \t]*vfscanf[ \t]*__svfscanf[ \t]*$";
> /gnu/gcc/obj $
>
>
>   This isn't a recent change, so I'm assuming autogen has changed.  What
> versions are other people running?

I use the attached patch successfully, I didn't submit it yet because I 
couldn't test it with older autogen. Testing is appreciated.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.
--- fixincludes/inclhack.def	2007-12-29 02:14:35.0 +0200
+++ fixincludes/inclhack.def	2007-12-31 04:21:00.0 +0200
@@ -1085,8 +1085,8 @@
  */
 fix = {
 hackname  = bsd_stdio_attrs_conflict;
-mach  = *-*-*bsd*;
-mach  = *-*-*darwin*;
+mach  = "*-*-*bsd*";
+mach  = "*-*-*darwin*";
 files = stdio.h;
 select= "^#define[ \t]*vfscanf[ \t]*__svfscanf[ \t]*$";
 c_fix = format;
@@ -1303,7 +1303,7 @@
  */
 fix = {
 hackname  = freebsd_gcc3_breakage;
-mach  = *-*-freebsd*;
+mach  = "*-*-freebsd*";
 files = sys/cdefs.h;
 select= '^#if __GNUC__ == 2 && __GNUC_MINOR__ >= 7$';
 bypass= '__GNUC__[ \t]*([>=]=[ \t]*[3-9]|>[ \t]*2)';
@@ -1320,7 +1320,7 @@
  */
 fix = {
 hackname  = freebsd_gcc4_breakage;
-mach  = *-*-freebsd*; 
+mach  = "*-*-freebsd*"; 
 files = sys/cdefs.h;
 select= '^#if __GNUC__ == 2 && __GNUC_MINOR__ >= 7 \|\| __GNUC__ == 3$';
 c_fix = format;
@@ -1619,7 +1619,7 @@
 
 fix = {
  hackname  = hppa_hpux_fp_macros;
- mach  = hppa*-hp-hpux11*;
+ mach  = "hppa*-hp-hpux11*";
  files = math.h;
  select= "#[ \t]*define[ \t]*FP_NORMAL.*\n"
 		 "#[ \t]*define[ \t]*FP_ZERO.*\n"
@@ -1728,7 +1728,7 @@
  */
 fix = {
 hackname  = hpux11_abs;
-mach  = ia64-hp-hpux11*;
+mach  = "ia64-hp-hpux11*";
 files = stdlib.h;
 select= "ifndef _MATH_INCLUDED";
 c_fix = format;
@@ -2670,7 +2670,7 @@
  */
 fix = {
 hackname  = netbsd_c99_inline_1;
-mach  = *-*-netbsd*;
+mach  = "*-*-netbsd*";
 files = signal.h;
 select= "extern __inline int";
 
@@ -2683,7 +2683,7 @@
 
 fix = {
 hackname  = netbsd_c99_inline_2;
-mach  = *-*-netbsd*;
+mach  = "*-*-netbsd*";
 files = signal.h;
 select= "#define _SIGINLINE extern __inline";
 
@@ -2705,7 +2705,7 @@
  */
 fix = {
 hackname  = netbsd_extra_semicolon;
-mach  = *-*-netbsd*;
+mach  = "*-*-netbsd*";
 files = sys/cdefs.h;
 select= "#define[ \t]*__END_DECLS[ \t]*};";
 

Re: How to Properly Set a Tree Member Variable

[Tom Tromey]

> "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes:

>> "Tom Browder" <[EMAIL PROTECTED]> writes:
>> /* the following two lines give a gcc error: lvalue required as left
>> operand of assignment */
>> DECL_SOURCE_FILE (parm_decl) = local_input_filename;
>> DECL_SOURCE_LINE (parm_decl) = lineno;
>> Apparently this code worked at one time.

Andreas> You need to set DECL_SOURCE_LOCATION now.

To expand a little -- gcc has 2 possible internal representations of
locations.  The default changed to "mapped locations" in 4.3.  In 4.4
we'll remove the old "expanded location" code entirely.

The reason to use mapped locations is that they use less memory while
also including information about the column number and include file
sequence.

>> I know I can decode the macros and deal with the "real" variables but
>> what is the correct way to set the parm_decl members?

Andreas> Take a look at tree.h.

Also you may want to look at input.h and libcpp/include/line-map.h.
line-map.h declares the API to creating mapped locations.

Tom

Re: How to Properly Set a Tree Member Variable

[Tom Browder]

On Jan 27, 2008 11:11 AM, Tom Tromey <[EMAIL PROTECTED]> wrote:
> > "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes:
...
> >> /* the following two lines give a gcc error: lvalue required as left
> >> operand of assignment */
> >> DECL_SOURCE_FILE (parm_decl) = local_input_filename;
> >> DECL_SOURCE_LINE (parm_decl) = lineno;
> >> Apparently this code worked at one time.
>
> Andreas> You need to set DECL_SOURCE_LOCATION now.
>
> To expand a little -- gcc has 2 possible internal representations of
> locations.  The default changed to "mapped locations" in 4.3.  In 4.4
> we'll remove the old "expanded location" code entirely.
>
> The reason to use mapped locations is that they use less memory while
> also including information about the column number and include file
> sequence.
...
> >> what is the correct way to set the parm_decl members?
>
> Andreas> Take a look at tree.h.
>
> Also you may want to look at input.h and libcpp/include/line-map.h.
> line-map.h declares the API to creating mapped locations.
>
> Tom

Thanks, Tom and Andreas.

-Tom B.

RE: inclhacks vs. latest autogen?

[Dave Korn]

On 27 January 2008 17:37, Ismail Dönmez wrote:

> I use the attached patch successfully, I didn't submit it yet because I
> couldn't test it with older autogen. Testing is appreciated.

  Thanks :) that was exactly the same as I came up with.

  I think you should submit it.  Since we're only using the same quoting style 
that's used elsewhere, and since there's no difference in the generated 
fixincl.x file, I'd think it was safe enough to check-in and wait see if it 
breaks anything.  (I can't test older versions myself, they won't build on 
current cygwin because they rely on old deprecated libguile apis).

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

Re: c++0x concepts in gcc call

[Gerald Pfeifer]

On Fri, 25 Jan 2008, Doug Gregor wrote:
> Organization:
>  - We'll start a fresh branch in the FSF repository dedicated to concepts
>(it's branches/cxx0x-concepts-branch). Initially, Doug and Jason
>will be maintainers of this branch

Thanks for documenting this in svn.html!  Just one quip: in the patch
you documented this new branch but removed the reference to the old 
cxx0x-branch.

Shouldn't that be moved to the "Inactive Development Branches" instead?

Gerald

PS: Thinks for the excellent summary!

Re: Gcc stack alignment branch is created

[Gerald Pfeifer]

On Thu, 17 Jan 2008, H.J. Lu wrote:
> I created gcc stack alignment branch to implement our proposal
> to automatically align stack:
> 
> svn://gcc.gnu.org/svn/gcc/branches/stack

Would you mind also adding an entry to the list of active branches to
http://gcc.gnu.org/svn.html?

Gerald

Re: [gcc-4.3-20080125] Bootstrap failure on i386-unknown-openbsd4.2: missing sentinel in function call

[Andrew Pinski]

2008/1/27 Cauchy Song <[EMAIL PROTECTED]>:
> $ uname -mrsp
> OpenBSD 4.2 i386 Intel(R) Pentium(R) M processor 1.73GHz ("GenuineIntel"
> 686-class)

> ../../gcc-4.3-20080125/gcc/read-rtl.c: In function 'join_c_conditions':
> ../../gcc-4.3-20080125/gcc/read-rtl.c:790: error: missing sentinel in
> function call

We have:
  result = concat ("(", cond1, ") && (", cond2, ")", NULL);


So I think this is a bug in openbsd's headers.

Thanks,
Andrew Pinski

[gcc-4.3-20080125] Bootstrap failure on i386-unknown-openbsd4.2: missing sentinel in function call

[Cauchy Song]

$ uname -mrsp
OpenBSD 4.2 i386 Intel(R) Pentium(R) M processor 1.73GHz ("GenuineIntel"
686-class)

$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-unknown-openbsd4.2/3.3.5/specs
Configured with:
Thread model: single
gcc version 3.3.5 (propolice)

$ bash ../gcc-4.3-20080125/configure --prefix=/usr/local/gcc-4.3.x \
 --enable-languages=c,c++,fortran --with-gmp=/usr/local
--with-mpfr=/usr/local

$ gmake bootstrap
...
echo '[c]' >> tmp-gi.list
echo '../../gcc-4.3-20080125/gcc/c-lang.c' >> tmp-gi.list
echo '../../gcc-4.3-20080125/gcc/c-tree.h' >> tmp-gi.list
echo '../../gcc-4.3-20080125/gcc/c-decl.c' >> tmp-gi.list
echo '../../gcc-4.3-20080125/gcc/c-common.c' >> tmp-gi.list
echo '../../gcc-4.3-20080125/gcc/c-common.h' >> tmp-gi.list
echo '../../gcc-4.3-20080125/gcc/c-pragma.h' >> tmp-gi.list
echo '../../gcc-4.3-20080125/gcc/c-pragma.c' >> tmp-gi.list
echo '../../gcc-4.3-20080125/gcc/c-objc-common.c' >> tmp-gi.list
echo '../../gcc-4.3-20080125/gcc/c-parser.c' >> tmp-gi.list
/bin/sh ../../gcc-4.3-20080125/gcc/../move-if-change tmp-gi.list
gtyp-input.list
echo timestamp > s-gtyp-input
build/gengtype ../../gcc-4.3-20080125/gcc gtyp-input.list
echo timestamp > s-gtype
/home/dongsheng/wc/tmp/obj/./prev-gcc/xgcc
-B/home/dongsheng/wc/tmp/obj/./prev-gcc/
-B/usr/local/gcc-4.3.x/i386-unknown-openbsd4.2/bin/ -c   -g -O2
-fomit-frame-pointer -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
   -Wno-overlength-strings -Werror
-fno-common   -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild
-I../../gcc-4.3-20080125/gcc -I../../gcc-4.3-20080125/gcc/build
-I../../gcc-4.3-20080125/gcc/../include -I./../intl
-I../../gcc-4.3-20080125/gcc/../libcpp/include -I/usr/local/include
-I/usr/local/include -I../../gcc-4.3-20080125/gcc/../libdecnumber
-I../../gcc-4.3-20080125/gcc/../libdecnumber/dpd -I../libdecnumber-o
build/rtl.o ../../gcc-4.3-20080125/gcc/rtl.c
/home/dongsheng/wc/tmp/obj/./prev-gcc/xgcc
-B/home/dongsheng/wc/tmp/obj/./prev-gcc/
-B/usr/local/gcc-4.3.x/i386-unknown-openbsd4.2/bin/ -c   -g -O2
-fomit-frame-pointer -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
   -Wno-overlength-strings -Werror
-fno-common   -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild
-I../../gcc-4.3-20080125/gcc -I../../gcc-4.3-20080125/gcc/build
-I../../gcc-4.3-20080125/gcc/../include -I./../intl
-I../../gcc-4.3-20080125/gcc/../libcpp/include -I/usr/local/include
-I/usr/local/include -I../../gcc-4.3-20080125/gcc/../libdecnumber
-I../../gcc-4.3-20080125/gcc/../libdecnumber/dpd -I../libdecnumber-o
build/read-rtl.o ../../gcc-4.3-20080125/gcc/read-rtl.c
cc1: warnings being treated as errors
../../gcc-4.3-20080125/gcc/read-rtl.c: In function 'join_c_conditions':
../../gcc-4.3-20080125/gcc/read-rtl.c:790: error: missing sentinel in
function call
gmake[3]: *** [build/read-rtl.o] Error 1
gmake[3]: Leaving directory `/home/dongsheng/wc/tmp/obj/gcc'
gmake[2]: *** [all-stage2-gcc] Error 2
gmake[2]: Leaving directory `/home/dongsheng/wc/tmp/obj'
gmake[1]: *** [stage2-bubble] Error 2
gmake[1]: Leaving directory `/home/dongsheng/wc/tmp/obj'
gmake: *** [bootstrap] Error 2

Thanks,

Dongsheng

Re: c++0x concepts in gcc call

[Doug Gregor]

On Jan 27, 2008 8:23 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> On Fri, 25 Jan 2008, Doug Gregor wrote:
> > Organization:
> >  - We'll start a fresh branch in the FSF repository dedicated to concepts
> >(it's branches/cxx0x-concepts-branch). Initially, Doug and Jason
> >will be maintainers of this branch
>
> Thanks for documenting this in svn.html!  Just one quip: in the patch
> you documented this new branch but removed the reference to the old
> cxx0x-branch.
>
> Shouldn't that be moved to the "Inactive Development Branches" instead?

I was planning to kill the cxx0x-branch outright, because it has
nothing that isn't available on mainline (except a not-nearly-complete
delegating constructors implementation), and will not be used. If this
would be better handled by moving the entry to "Inactive Development
Branches", I'll certainly do that. But there isn't really anything of
value in the cxx0x-branch to keep around.

  - Doug

Re: Gcc stack alignment branch is created

[H.J. Lu]

On Mon, Jan 28, 2008 at 02:47:23AM +0100, Gerald Pfeifer wrote:
> On Thu, 17 Jan 2008, H.J. Lu wrote:
> > I created gcc stack alignment branch to implement our proposal
> > to automatically align stack:
> > 
> > svn://gcc.gnu.org/svn/gcc/branches/stack
> 
> Would you mind also adding an entry to the list of active branches to
> http://gcc.gnu.org/svn.html?
> 

Does it look OK? I also updated my email address.


H.J.

Index: svn.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/svn.html,v
retrieving revision 1.72
diff -u -p -r1.72 svn.html
--- svn.html25 Jan 2008 17:42:39 -  1.72
+++ svn.html28 Jan 2008 04:35:05 -
@@ -388,6 +388,16 @@ list therefore provides only some repres
   Richard Guenther and Michael Matz.  Patches should be marked with the
   tag [varmap] in the subject line.
 
+  stack-branch
+  This branch contains a new stack alignment framework to align stack
+  automatically for local variables with alignment requirement. The branch
+  is maintained by
+  H.J. Lu [EMAIL PROTECTED]>,
+  Joey Ye [EMAIL PROTECTED]>
+  and Xuepeng Guo [EMAIL 
PROTECTED]>.
+  Patches should be marked with the tag [stack] in the subject
+  line.
+
 
 
 Architecture-specific
@@ -465,13 +475,13 @@ list therefore provides only some repres
   The goal of this branch is to add support for newer ix86 processors such
   as AMD's Barcelona and Intel's Core 2 to GCC 4.2.x.  The current maintainers
   are Michael Meissner [EMAIL 
PROTECTED]>
-  and H.J. Lu [EMAIL 
PROTECTED]>.
+  and H.J. Lu [EMAIL 
PROTECTED]>.
 
   ix86/gcc-4_1-branch
   The goal of this branch is to add support for newer ix86 processors such
   as AMD's Barcelona and Intel's Core 2 to GCC 4.1.x.  The current maintainers
   are Michael Meissner [EMAIL 
PROTECTED]>
-  and H.J. Lu [EMAIL 
PROTECTED]>.
+  and H.J. Lu [EMAIL 
PROTECTED]>.
 
 
 

Re: [gcc-4.3-20080125] Bootstrap failure on i386-unknown-openbsd4.2: missing sentinel in function call

[Dongsheng Song]

gcc-4.2.3-RC-20080125 is OK, so it's a regress.

2008/1/28, Andrew Pinski <[EMAIL PROTECTED]>:
> 2008/1/27 Cauchy Song <[EMAIL PROTECTED]>:
> > $ uname -mrsp
> > OpenBSD 4.2 i386 Intel(R) Pentium(R) M processor 1.73GHz ("GenuineIntel"
> > 686-class)
>
> > ../../gcc-4.3-20080125/gcc/read-rtl.c: In function 'join_c_conditions':
> > ../../gcc-4.3-20080125/gcc/read-rtl.c:790: error: missing sentinel in
> > function call
>
> We have:
>   result = concat ("(", cond1, ") && (", cond2, ")", NULL);
>
>
> So I think this is a bug in openbsd's headers.
>
> Thanks,
> Andrew Pinski
>