Question about memory allocation in ifcvt.c

[thorsten]

Hello all,

this might be a noob Question but perhaps someone is so kind as to shed 
some light...


using gcc-4.5.4 to build large files (as in wireshark or qemu) with 
Optimizations enabled (in my case -O2 -pipe -march=core2 
-fomit-frame-pointer) I get segmentation faults due to Stack limits, 
when using the standard stacksize on linux.


I figured out that ifcvt.c uses alloca to reserve mem on the stack. this 
is the point where the segmentation fault occurs.


So beeing curious, I changed alloca to xmalloc to use the heap instead 
of the stack, thinking this is likely to cause a huge penalty in 
compile-speed. But comparing both the gcc-alloca and gcc-xmalloc the 
compiletimes do not differ significantly. And the gcc-xmalloc does not 
crash anymore due to limited stackspace.


So here is my question: What is the reason for using alloca (Stack) 
instead of xmalloc (heap) in ifcvt.c? I have seen, that also gcc-4.7.2 
still uses alloca.


Thanks!

Thorsten

Re: Question about memory allocation in ifcvt.c

[thorsten]

On Sun, Oct 14, 2012 at 1:40 AM, Andrew Pinski  wrote:


Maybe Ian can mention why he used alloca there instead of xmalloc.


It was a long time ago, but I expect it was just because alloca is
usually fine for memory that has to live for just a single function.
As a single-threaded program, GCC doesn't normally have severe limits
on stack size.  This can't have been too big a problem, as I added the
code in GCC 4.2 and this is the first complaint I've seen.

In any case, as Steven points out, this has been fixed in mainline.

Ian


Thanks for the hints, I will try to backport the fix to 4.5


thorsten

ICE: in bitmap_set_replace_value

[thorsten]

Hello all,


trying to compile bash-4.2 with the gcc-4.8-20130106 snapshot I get the 
following error:

 gcc  -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"i686"' -DCONF_OSTYPE='"linux-gnu"' 
-DCONF_MACHTYPE='"i686-pc-linux-gnu"' -DCONF_VENDOR='"pc"' -DLOCALEDIR='"/usr/share/locale"' 
-DPACKAGE='"bash"' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -pipe -O2 -march=core2 -fomit-frame-pointer -c y.tab.c
y.tab.c: In function 'yyparse':
y.tab.c:1842:1: internal compiler error: in bitmap_set_replace_value, at 
tree-ssa-pre.c:867
 yyparse (void)
 ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.


Executing the same command with -O1 instead of -O2 compiles just fine.

Also using the gcc-4.8-20121230 snapshot compiles just fine.

Is this a regression?

Thanks,

thorsten

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Thorsten Glaser]

Paul Eggert dixit:

>  […] gcc -O2 makes no promises without
>  -fwrapv.

gcc -O1 -fwrapv even doesn't work correctly for gcc3,
and gcc2 and gcc <3.3(?) don't even have -fwrapv:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477

bye,
//mirabile
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999

Re: matching constraints in asm operands question

[Thorsten Glaser]

Andrew Pinski dixit:

>> which seems to work, but I'm really concerned about the manuals
>> warning of the input and output operads being in seperate places.

> static __inline__ void atomic_inc(atomic_t *v)
> {
>   __asm__ __volatile__("addql #1,%0" : "+m" (*v));
> }

Hi, I have got the same problem with the following file:

/*  $OpenBSD: _atomic_lock.c,v 1.7 2002/10/11 19:08:41 marc Exp $   */
/* David Leonard, <[EMAIL PROTECTED]>. Public domain. */

/*
 * Atomic lock for i386
 */

#include "spinlock.h"

int
_atomic_lock(volatile _spinlock_lock_t *lock)
{
_spinlock_lock_t old;

/*
 * Use the eXCHanGe instruction to swap the lock value with
 * a local variable containing the locked state.
 */
old = _SPINLOCK_LOCKED;
__asm__("xchg %0,%1"
: "=r" (old), "=m" (*lock)
: "0"  (old), "1"  (*lock));

return (old != _SPINLOCK_UNLOCKED);
}


Thanks in advance,
//mirabile
-- 
> [...] Echtzeit hat weniger mit "Speed"[...] zu tun, sondern damit, daß der
> richtige Prozeß voraussagbar rechtzeitig sein Zeitscheibchen bekommt.
Wir haben uns[...] geeinigt, dass das verwendete Echtzeit-Betriebssystem[...]
weil selbst einfachste Operationen *echt* *Zeit* brauchen.  (aus d.a.s.r)

Re: GCC Status Report (2005-03-09)

[Thorsten Glaser]

Mark Mitchell dixit:

>4.1 Status
>==
>
>The 4.1 projects Wiki page shows that four projects have been checked
>in:

Hello etoh-san, do you have a statement about ProPolice for gcc 4?
Are you working on it, or even bringing it into mainline (maybe even
disabled by default, doesn't matter as long as it's in, I think)?

bye,
//mirabile
-- 
> [...] Echtzeit hat weniger mit "Speed"[...] zu tun, sondern damit, daß der
> richtige Prozeß voraussagbar rechtzeitig sein Zeitscheibchen bekommt.
Wir haben uns[...] geeinigt, dass das verwendete Echtzeit-Betriebssystem[...]
weil selbst einfachste Operationen *echt* *Zeit* brauchen.  (aus d.a.s.r)

Re: Question about "#pragma pack(n)" and "-fpack-struct"

[Thorsten Glaser]

James E Wilson dixit:

>Currently, -fpack-struct is defined
>to have the same effect as attribute ((packed)) for all structures,
>which in turn is equivalent to #pragma pack(1) for all structures.

Let me please add a feature request here.

gcc warns if it cannot pack structs since they're already
in a more or less optimal form.

When you're using headers for structures e.g. used for PXE,
you've got to pack them since the data comes from the BIOS.

Using __attribute__((packed)) on these structures will then
give you a warning on i386 (and maybe none on amd64, but I
have not checked that).

When you're building with -Werror, that plainly sucks.

Luckily, my gcc 3.4.4 seems to not warn if I use #pragma pack;
that's all I request to be retained.

bye,
//mirabile
-- 
> [...] Echtzeit hat weniger mit "Speed"[...] zu tun, sondern damit, daß der
> richtige Prozeß voraussagbar rechtzeitig sein Zeitscheibchen bekommt.
Wir haben uns[...] geeinigt, dass das verwendete Echtzeit-Betriebssystem[...]
weil selbst einfachste Operationen *echt* *Zeit* brauchen.  (aus d.a.s.r)

Re: Getting rid of -fno-unit-at-a-time

[Thorsten Glaser]

Daniel Jacobowitz dixit:

>On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote:
>> BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
>> or so... I still lean on that crutch.
>
>A user!  Can you explain why?

If you're "just" looking for users:

I need -fno-unit-at-a-time because -funit-at-a-time in 3.4 breaks
ProPolice. Of course, that's totally non-standard, and ProPolice
will have to be redesigned for gcc 4 anyway, IIRC.
(Also, with -funit-at-a-time, I get .L123 symbols in the generated
shared libraries, which I do not get without.)

Probably not too much importance, I just wanted to speak up
I guess.

bye,
//mirabile

sjlj exceptions?

[Thorsten Glaser]

Hi,

when porting gcc (still 3.4.4), how do I exactly know whether I
need to pass --enable-sjlj-exceptions to configure?

Is there a test case which fails if I need it and have it not
enabled, and passes otherwise (disabled and not needed, or
enabled)?

TIA,
//mirabile
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Re: GCC 4.1: Buildable on GHz machines only?

[Thorsten Glaser]

Zack Weinberg dixit:

>This could be made substantially easier if libgcc moved to the top
>level.  You wanna help out with that?

What about crtstuff?

//mirabile

libjava/3.4.4 problem (was Re: GCC 3.4.4 Status (2005-04-29))

[Thorsten Glaser]

Mark Mitchell dixit:

>In general, GCC 3.4.3 is working for people

I've been playing around a lot with the various 3.4.4 snapshots
lately, and got everything to work, except for libjava:

gmake[1]: Entering directory `/usr/obj/gcc/libjava'
/bin/ksh ./libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. 
-I/usr/src/gcc/libjava -I./include -I./gcj -I/usr/src/gcc/libjava -Iinclude 
-I/usr/src/gcc/libjava/include -I/usr/src/gcc/boehm-gc/include  
-DHAVE_DLFCN_H=1 -DSILENT=1 -DNO_SIGNALS=1 -DALL_INTERIOR_POINTERS=1 
-DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1   
-I/usr/src/gcc/libjava/libltdl -I/usr/src/gcc/libjava/libltdl 
-I../libstdc++-v3/include -I../libstdc++-v3/include/i386-ecce-mirbsd8 
-I/usr/src/gcc/libjava/../libstdc++-v3/libsupc++ 
-I/usr/src/gcc/libjava/.././libjava/../gcc  
-I/usr/src/gcc/libjava/../libffi/include -I../libffi/include  -isystem 
/usr/src/gcc/libjava -fno-rtti -fnon-call-exceptions  -fdollars-in-identifiers 
-Wswitch-enum -ffloat-store  -I/usr/X11R6/include -W -Wall -D_GNU_SOURCE 
-DPREFIX="\"/usr\"" -DLIBDIR="\"/usr/lib\"" 
-DBOOT_CLASS_PATH="\"/usr/share/java/libgcj-3.4.4.jar\"" -O2 -c 
/usr/src/gcc/libjava/prims.cc
mkdir .libs
 c++ -DHAVE_CONFIG_H -I. -I/usr/src/gcc/libjava -I./include -I./gcj 
-I/usr/src/gcc/libjava -Iinclude -I/usr/src/gcc/libjava/include 
-I/usr/src/gcc/boehm-gc/include -DHAVE_DLFCN_H=1 -DSILENT=1 -DNO_SIGNALS=1 
-DALL_INTERIOR_POINTERS=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 
-DATOMIC_UNCOLLECTABLE=1 -I/usr/src/gcc/libjava/libltdl 
-I/usr/src/gcc/libjava/libltdl -I../libstdc++-v3/include 
-I../libstdc++-v3/include/i386-ecce-mirbsd8 
-I/usr/src/gcc/libjava/../libstdc++-v3/libsupc++ 
-I/usr/src/gcc/libjava/.././libjava/../gcc 
-I/usr/src/gcc/libjava/../libffi/include -I../libffi/include -isystem 
/usr/src/gcc/libjava -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers 
-Wswitch-enum -ffloat-store -I/usr/X11R6/include -W -Wall -D_GNU_SOURCE 
-DPREFIX=\"/usr\" -DLIBDIR=\"/usr/lib\" 
-DBOOT_CLASS_PATH=\"/usr/share/java/libgcj-3.4.4.jar\" -O2 
-Wp,-MD,.deps/prims.pp -c /usr/src/gcc/libjava/prims.cc  -fPIC -DPIC -o 
.libs/prims.o
In file included from /usr/src/gcc/libjava/java/lang/Object.h:16,
 from /usr/src/gcc/libjava/gcj/cni.h:16,
 from ./include/platform.h:40,
 from /usr/src/gcc/libjava/prims.cc:12:
/usr/src/gcc/libjava/gcj/javaprims.h:486: error: declaration of C function 
`java::lang::Thread* _Jv_AttachCurrentThread(java::lang::String*, 
java::lang::ThreadGroup*)' conflicts with
/usr/src/gcc/libjava/gcj/javaprims.h:484: error: previous declaration `jint 
_Jv_AttachCurrentThread(java::lang::Thread*)' here
In file included from ./java/lang/String.h:9,
 from /usr/src/gcc/libjava/java/lang/Class.h:18,
 from /usr/src/gcc/libjava/gcj/cni.h:17,
 from ./include/platform.h:40,
 from /usr/src/gcc/libjava/prims.cc:12:
/usr/src/gcc/libjava/gcj/array.h: In function `jsize 
JvGetArrayLength(__JArray*)':
/usr/src/gcc/libjava/gcj/array.h:29: error: previous declaration of `jsize 
JvGetArrayLength(__JArray*)' with Java linkage
/usr/src/gcc/libjava/gcj/array.h:138: error: conflicts with new declaration 
with C linkage
In file included from /usr/src/gcc/libjava/gcj/cni.h:17,
 from ./include/platform.h:40,
 from /usr/src/gcc/libjava/prims.cc:12:
/usr/src/gcc/libjava/java/lang/Class.h: At global scope:
/usr/src/gcc/libjava/java/lang/Class.h:366: error: declaration of C function 
`void _Jv_InitField(java::lang::Object*, java::lang::Class*, int)' conflicts 
with
/usr/src/gcc/libjava/java/lang/Class.h:365: error: previous declaration `void 
_Jv_InitField(java::lang::Object*, java::lang::Class*, _Jv_Field*)' here
In file included from ./include/platform.h:40,
 from /usr/src/gcc/libjava/prims.cc:12:
/usr/src/gcc/libjava/gcj/cni.h: In function `java::lang::Object* 
JvAllocObject(java::lang::Class*, jsize)':
/usr/src/gcc/libjava/gcj/cni.h:31: error: declaration of C function 
`java::lang::Object* JvAllocObject(java::lang::Class*, jsize)' conflicts with
/usr/src/gcc/libjava/gcj/cni.h:25: error: previous declaration 
`java::lang::Object* JvAllocObject(java::lang::Class*)' here
/usr/src/gcc/libjava/gcj/cni.h: In function `java::lang::String* 
JvNewStringLatin1(const char*)':
/usr/src/gcc/libjava/gcj/cni.h:64: error: declaration of C function 
`java::lang::String* JvNewStringLatin1(const char*)' conflicts with
/usr/src/gcc/libjava/gcj/cni.h:58: error: previous declaration 
`java::lang::String* JvNewStringLatin1(const char*, jsize)' here
/usr/src/gcc/libjava/prims.cc: In function `void unblock_signal(int)':
/usr/src/gcc/libjava/prims.cc:136: warning: right-hand operand of comma has no 
effect
/usr/src/gcc/libjava/prims.cc: At global scope:
/usr/src/gcc/libjava/prims.cc:132: warning: 'void unblock_signal(int)' defined 
but not used
gmake[1]: *** [prims.lo] Error 1
gmake[1]: Leaving directory `/usr/obj/

Re: libjava/3.4.4 problem

[Thorsten Glaser]

Andrew Pinski dixit:

>> Does anyone have an idea where to look?
>
> This is a bug in your config, you forgot to define NO_IMPLICIT_EXTERN_C.

Thanks a lot, I will try that after I updated to 20050429.

bye,
//mirabile

Re: libjava/3.4.4 problem (SOLVED)

[Thorsten Glaser]

Dixi:

>Mark Mitchell dixit:
>
>>In general, GCC 3.4.3 is working for people
>
>I've been playing around a lot with the various 3.4.4 snapshots
>lately, and got everything to work, except for libjava:

With the change in the configuration file, it works now. However,
I'm curious about why FreeBSD defines it while NetBSD and OpenBSD
do not, and which implications it might have elsewhere.

gcj works now, as in "99 Bottles of Beer" compiled from source to
bytecode and executed with sunjdk-1.4.2 (native), compiled from
source or bytecode to executable. gij does not work because boehm-gc
is (still) broken on all OpenBSD/ELF platforms (and, apparently,
OpenBSD derivates like MirOS). I'll try with GC disabled now.

libjava is a pain in the ass, regarding "writes to build directory
during installation time". libtool relinking issues, and the list
of headers to be installed. I have worked around these, but it's
probably unportable. Also, having its own libltdl is... weird.

But I'm really happy with the huge (and I mean it) increase in
overall quality between 3.2.3 and 3.4.4 (prerelease).

There's still one thing I miss: a list of all flags allowed for
a specific compiler/language. For example, I cannot specify -Wformat
for Ada, -DPIC for Java, etc. (at the moment, during libstdc++-v3
and libjava build I ignore the user-settable CFLAGS (/etc/mk.conf)
and for Ada I remove some via gmake features).
I suppose I might be able to dig it out from the source, though.
(What I was talking about is an easy to read overview, e.g. a table.)

bye,
//mirabile
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Re: libjava build times

[Thorsten Glaser]

Andrew Haley dixit:

>Richard Henderson writes:
> > 
> > Now, unless I've done something drastically wrong, it appears as if we
> > are spending 2/3 of our time in the libtool script.
>
>Yes, that's right.  That's similar to what my oprofile experiments suggest.

Could you please go to http://wiki.mirbsd.de/MirbsdKsh, get the source,
compile it and try with it instead of your usual /bin/sh (I suppose GNU
bash) again?

I'd be interested if that warrants a noticeable speedup. I've done only
a few comparisions regarding string handling, and ksh both used less
memory and was by times faster. Also, GNU bash started getting MUCH
slower at 16 KiB strings, while ksh was linear until 256 KiB strings.

Thanks,
//mirabile
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Re: volatile semantics

[Thorsten Glaser]

Mike Stump dixit:

> int avail;
> int main() {
>  while (*(volatile int *)&avail == 0)
>continue;
>  return 0;
> }

3.4.4 fetches too. I get:

.L2:
mov %eax, DWORD PTR avail
test%eax, %eax
je  .L2

This is at -O99, other levels produce similar results.

//mirabile
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

gij problem (3.4.4)

[Thorsten Glaser]

Hello,

I've got Java classes from source ("99 bottles of beer") compiled
to bytecode and from source or bytecode to a dynamically linked
executable working just fine, also Sun's JDK works on the generated
bytecode - however, gij does not, even without boehm-gc (which
prevented it from working before):

[EMAIL PROTECTED]:/home/tg/tmp $ gdb --args /usr/bin/gij bottles
GNU gdb 6.3.50.20050107
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-ecce-mirbsd8"...(no debugging symbols found)

(gdb) r
Starting program: /usr/bin/gij bottles
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
0x02b88fa6 in _Jv_ClassReader::handleFieldsEnd () from /usr/lib/libgcj.so.5.0
(gdb) bt
#0  0x02b88fa6 in _Jv_ClassReader::handleFieldsEnd () from 
/usr/lib/libgcj.so.5.0
#1  0x02b8c408 in _Jv_ClassReader::read_fields () from /usr/lib/libgcj.so.5.0
#2  0x02b8c749 in _Jv_ClassReader::parse () from /usr/lib/libgcj.so.5.0
#3  0x02b8c974 in _Jv_DefineClass () from /usr/lib/libgcj.so.5.0
#4  0x02bab6eb in java::lang::VMClassLoader::defineClass () from 
/usr/lib/libgcj.so.5.0
#5  0x02bbb57a in java::lang::ClassLoader::defineClass () from 
/usr/lib/libgcj.so.5.0
#6  0x02cb6e37 in java::security::SecureClassLoader::defineClass () from 
/usr/lib/libgcj.so.5.0
#7  0x02c9d201 in java::net::URLClassLoader::findClass () from 
/usr/lib/libgcj.so.5.0
#8  0x02ba34e6 in gnu::gcj::runtime::VMClassLoader::findClass () from 
/usr/lib/libgcj.so.5.0
#9  0x02bbb748 in java::lang::ClassLoader::loadClass () from 
/usr/lib/libgcj.so.5.0
#10 0x02babae4 in _Jv_FindClass () from /usr/lib/libgcj.so.5.0
#11 0x02bab32b in java::lang::Class::forName () from /usr/lib/libgcj.so.5.0
#12 0x02bab44d in java::lang::Class::forName () from /usr/lib/libgcj.so.5.0
#13 0x02c27199 in gnu::gcj::runtime::FirstThread::run () from 
/usr/lib/libgcj.so.5.0
#14 0x02bb1962 in _Jv_ThreadRun () from /usr/lib/libgcj.so.5.0
#15 0x02b7d998 in _Jv_RunMain () from /usr/lib/libgcj.so.5.0
#16 0x1c000ade in ?? ()
#17 0x1c000870 in ?? ()
#18 0x0002 in ?? ()
#19 0xcfbf4540 in ?? ()
#20 0xcfbf454c in ?? ()
#21 0x1c000d40 in ?? ()
#22 0x in ?? ()
(gdb) disas 0x02b88fa6
Dump of assembler code for function _ZN15_Jv_ClassReader15handleFieldsEndEv:
0x02b88ea8 <_ZN15_Jv_ClassReader15handleFieldsEndEv+0>: push   %ebp
0x02b88ea9 <_ZN15_Jv_ClassReader15handleFieldsEndEv+1>: mov%esp,%ebp
0x02b88eab <_ZN15_Jv_ClassReader15handleFieldsEndEv+3>: push   %edi
0x02b88eac <_ZN15_Jv_ClassReader15handleFieldsEndEv+4>: push   %esi
0x02b88ead <_ZN15_Jv_ClassReader15handleFieldsEndEv+5>: sub$0x40,%esp
0x02b88eb0 <_ZN15_Jv_ClassReader15handleFieldsEndEv+8>: mov0x8(%ebp),%eax
0x02b88eb3 <_ZN15_Jv_ClassReader15handleFieldsEndEv+11>:movl   
$0x0,0xffe0(%ebp)
0x02b88eba <_ZN15_Jv_ClassReader15handleFieldsEndEv+18>:mov
%eax,0xffe4(%ebp)
0x02b88ebd <_ZN15_Jv_ClassReader15handleFieldsEndEv+21>:mov
0x1c(%eax),%edx
0x02b88ec0 <_ZN15_Jv_ClassReader15handleFieldsEndEv+24>:movswl 
0x34(%edx),%eax
0x02b88ec4 <_ZN15_Jv_ClassReader15handleFieldsEndEv+28>:lea
0x(%eax),%esi
0x02b88ec7 <_ZN15_Jv_ClassReader15handleFieldsEndEv+31>:mov
0x80(%edx),%ecx
0x02b88ecd <_ZN15_Jv_ClassReader15handleFieldsEndEv+37>:cmp
%esi,0xffe0(%ebp)
0x02b88ed0 <_ZN15_Jv_ClassReader15handleFieldsEndEv+40>:mov
0x2c(%edx),%edi
0x02b88ed3 <_ZN15_Jv_ClassReader15handleFieldsEndEv+43>:mov
%ecx,0xffdc(%ebp)
0x02b88ed6 <_ZN15_Jv_ClassReader15handleFieldsEndEv+46>:jge
0x2b88fa0 <_ZN15_Jv_ClassReader15handleFieldsEndEv+248>
0x02b88edc <_ZN15_Jv_ClassReader15handleFieldsEndEv+52>:mov
0xffe0(%ebp),%eax
0x02b88edf <_ZN15_Jv_ClassReader15handleFieldsEndEv+55>:shl$0x4,%eax
0x02b88ee2 <_ZN15_Jv_ClassReader15handleFieldsEndEv+58>:testb  
$0x8,0x8(%eax,%edi,1)
0x02b88ee7 <_ZN15_Jv_ClassReader15handleFieldsEndEv+63>:je 
0x2b88fc8 <_ZN15_Jv_ClassReader15handleFieldsEndEv+288>
0x02b88eed <_ZN15_Jv_ClassReader15handleFieldsEndEv+69>:incl   
0xffe0(%ebp)
0x02b88ef0 <_ZN15_Jv_ClassReader15handleFieldsEndEv+72>:cmp
%esi,0xffe0(%ebp)
0x02b88ef3 <_ZN15_Jv_ClassReader15handleFieldsEndEv+75>:jl 
0x2b88edc <_ZN15_Jv_ClassReader15handleFieldsEndEv+52>
0x02b88ef5 <_ZN15_Jv_ClassReader15handleFieldsEndEv+77>:lea
0x0(%esi),%esi
0x02b88ef8 <_ZN15_Jv_ClassReader15handleFieldsEndEv+80>:cmp
%esi,0xffe0(%ebp)
0x02b88efb <_ZN15_

Re: gij problem (3.4.4)

[Thorsten Glaser]

Andrew Haley dixit:

>No, but I do know that I would not even attempt to start looking at
>this with no debugging info in libgcj.  libgcj builds by default with
>full debugging info, so something (someone) must have removed it.

Yes, our libraries are stripped by default. I can build one with
full debugging information (and, if requested, -O0) if someone
wants to help looking into this. I don't have much experience
with either Java(TM) or gdb myself, though.

//mirabile
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Re: gij problem (3.4.4)

[Thorsten Glaser]

Andrew Haley dixit:

>In which case it would be best to post a bug report at
>gcc.gnu.org/bugzilla and attach both source and class files.

What for? I'm 99% sure nobody else has got the bug, since
most probably haven't even heard of the MirOS operating
system. And it's only in the latest snapshot.

The source is at http://www.99-bottles-of-beer.net//j.html#Java

//mirabile
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Re: gij problem (3.4.4)

[Thorsten Glaser]

Andrew Haley dixit:

>Do you have any reason to suspect this might be MirOS specific?

We have to patch a lot. Some of it is OpenBSD legacy, some from
NetBSD, some from newer GNU tools, some patches are build system
specific. And since it happened on execution of a class with only
one page source code, I think it's specific to my configuration.

//mirabile
-- 
Hey, I just realized that OpenBSD CDs are $45.  Any chance I could get
you to update your sig?
-- Steve Shockley after reading my previous signature

should libgcc depend on libc?

[Thorsten Glaser]

objdump -p says:

Dynamic Section:
  NEEDED  libc.so.37.0
  SONAME  libgcc_s.so.1.1
[...]

nm | sort says:

 U _exit
 U abort
 U dl_iterate_phdr
 U free
 U malloc
 U memcpy
 U memset
 U mprotect
 U perror
 U sysconf
 w _Jv_RegisterClasses
 w __cxa_finalize

Should I really not use -nostandardlibs for libgcc_s ?
I just got a linker warning because I had bumped libc
from .36.1 to .37.0 and am recompiling gcc... this
yields executables linking against libgcc_s (.1.1)
and libc (.37.0 AND .36.1). No problems, but a warning.

Also, libgcc could be used with libc-replacements this
way (not truly an issue with libgcc.so, but think of
bootloaders).

Do I overlook something?

Thanks,
//mirabile
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt

Re: updating libtool, etc.

[Thorsten Glaser]

Daniel Jacobowitz dixit:

>> >Geoff> Does anyone mind if I update libtool to the latest released  
>> >version,
>> >Geoff> 1.5.18, and regenerate everything with automake 1.9.5?
>> >
>> >If everyone agrees to go forward with this
>> 
>> Oh, I should have said:  "and if you don't mind, how do you feel  
>> about a GCC project fork of libtool?"

>If you want to update libtool, you get to play the all-of-src-uses-it
>game.  I have been updating src directories to more recent autoconf
>versions in the hope of getting rid of our outdated libtool someday. I
>believe the only remaining holdout is newlib, but I didn't check
>everything.

The MirOS version of Libtool also works with autoconf 2.13 and automake 1.4
(in addition to autoconf 2.59 and automake 1.9), though we broke one AIX
related macro in the process. It's based upon branch-1-5 of GNU libtool,
and copyright assignment has already been done.

If interested, check these (and the diff to -rFSF) out:
* http://mirbsd.mirsolutions.de/cvs.cgi/contrib/gnu/libtool/libtool.m4
* http://mirbsd.mirsolutions.de/cvs.cgi/contrib/gnu/libtool/ltmain.in

I use it (obviously) to build all ports which use it, plus stuff in
the base system (binutils, gdb, gcc 3.4.5 but not newlib). The broken
macro was _LT_AC_SYS_LIBPATH_AIX because one of the macros it invokes
are not in autoconf 2.13.

//mirabile
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt

Re: Big Classpath Merge warning

[Thorsten Glaser]

Tom Tromey dixit:

>I'm finally ready to check in the big classpath merge, and I wanted to
>post a short warning before I went ahead with it.

Is it possible to use a current libgcj or classpath with gcc 3.4?

Thanks,
//mirabile
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt

[RFD] Insane alignment of read-only arrays

[Thorsten Glaser]

Hi,

(tl;dr: skip to “questions from me to the GCC developers”)

I’ve recently spotted the following in some code I inherited:

struct foo {
char name[4];
uint8_t len;
uint8_t type;
};

static const struct foo fooinfo[] = {
/* list of 43 members */
};

I’ve seen the obvious two-byte padding (on i386, with -Os)
and thought to restructure this into:

static const char fooname[][4] = { … };
static const uint8_t foolen[] = { … };
static const uint8_t footype[] = { … };

Colour me surprised when this made the code over fifty
bytes longer. After some debugging, I found that the
assembly code generated had “.align 32” in front of
each of the new structs.

After some (well, lots) more debugging, I eventually
discovered -fdump-translation-unit (which, in the version
I was using, also worked for C, not just C++), which showed
me that the alignment was 256 even (only later reduced to
32 as that’s the maximum alignment for i386).

Lots of digging later, I found this gem in gcc/config/i386/i386.c:

int
ix86_data_alignment (tree type, int align)
{
  if (AGGREGATE_TYPE_P (type)
   && TYPE_SIZE (type)
   && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST
   && (TREE_INT_CST_LOW (TYPE_SIZE (type)) >= 256
   || TREE_INT_CST_HIGH (TYPE_SIZE (type))) && align < 256)
return 256;

Voilà, there we have my culprit – commenting this out resulted
in a 12-byte yield (not 42*2 byte, as the code generated for e.g.
“strncmp(foo, opname[i], (size_t)oplen[i])” is a bit less optimal
than for “strncmp(foo, opinfo[i].name, (size_t)opinfo[i].len)”,
but that’s okay)… and a 206-byte reduction for the rest of the
codebase.

Seeing that ix86_data_alignment() also contains amd64-specific
alignment, and that MMX stuff generally needs more alignment,
I first did this:

&& (TREE_INT_CST_LOW (TYPE_SIZE (type)) >= 256
-  || TREE_INT_CST_HIGH (TYPE_SIZE (type))) && align < 256)
+  || TREE_INT_CST_HIGH (TYPE_SIZE (type)))
+   && (TARGET_MMX || !optimize_size)
+   && align < 256)
 return 256;

The idea here being that both TARGET_SSE and TARGET_64BIT
enable TARGET_MMX, and to do this only for -Os.

Then I went into the svn history for this function and
discovered that its predecessor in gcc/config/i386/i386.h
(the DATA_ALIGNMENT(TYPE, ALIGN) macro) was added in around
2000, before MMX was even a thing, to “improve floating point
performance”, but that architectures apparently can do without.

Now I’m trying roughly this:

[…]
 ix86_constant_alignment (tree exp, int align)
 {
+  if (optimize_size && !TARGET_MMX)
+return align;
[…]
 ix86_data_alignment (tree type, int align)
 {
+  if (optimize_size && !TARGET_MMX)
+return align;
[…]
 ix86_local_alignment (tree type, int align)
 {
+  if (optimize_size && !TARGET_MMX)
+return align;
[…]

This opens up some questions from me to the GCC developers
though:

– Is this safe to do? (My baseline here is 3.4.6, so
  if someone still remembers, please do answer, but
  the scope of this eMail in total goes beyond that.)

– Is this something that GCC trunk could benefit from?

– Is the exclusion of MMX and 64BIT required? (Since
  this code has been there “ever” since even before
  MMX support landed in GCC, I fear that some of the
  “required alignment” are done inside this function
  instead of in other places.)

– Even better: is this something we could do for *all*
  platforms in general? Something like this, in gcc/varasm.c:

 #ifdef DATA_ALIGNMENT
+  if (!optimize_size)
-  align = DATA_ALIGNMENT (TREE_TYPE (decl), align);
+align = DATA_ALIGNMENT (TREE_TYPE (decl), align);
 #endif

My aim here is to tighten the density (reduce the size
of the individual sections in the .o file and, ideally,
the file size of the final executable) of the generated
code for -Os while not breaking anything, and leaving
the case of not-Os completely alone.

Of course I’ll do a full rebuild of MirBSD (which uses
-Os in almost all code, only some legacy crap from the
1970s like AT&T nroff uses -O1 or even -O0 as the code
doesn’t conform to ISO C) to see if things break, but
I’m also interested in the bigger picture, besides I
have invested into embedded systems (FreeWRT/OpenADK,
but also dietlibc, klibc, etc.) which love small code.

Thanks in advance,
//mirabilos
PS: Please do Cc me, I’m not subscribed.
PPS: I’ve exchanged assignment papers with the FSF about GCC,
 so feel free to just commit anything, if it makes sense.
-- 
ObCaptcha: null

[RFD] Extremely large alignment of read-only strings

[Thorsten Glaser]

Hi,

(tl;dr: skip to “questions from me to the GCC developers”)

I’ve recently spotted the following in some code I inherited:

struct foo {
char name[4];
uint8_t len;
uint8_t type;
};

static const struct foo fooinfo[] = {
/* list of 43 members */
};

I’ve seen the obvious two-byte padding (on i386, with -Os)
and thought to restructure this into:

static const char fooname[][4] = { … };
static const uint8_t foolen[] = { … };
static const uint8_t footype[] = { … };

Colour me surprised when this made the code over fifty
bytes longer. After some debugging, I found that the
assembly code generated had “.align 32” in front of
each of the new structs.

After some (well, lots) more debugging, I eventually
discovered -fdump-translation-unit (which, in the version
I was using, also worked for C, not just C++), which showed
me that the alignment was 256 even (only later reduced to
32 as that’s the maximum alignment for i386).

Lots of digging later, I found this gem in gcc/config/i386/i386.c:

int
ix86_data_alignment (tree type, int align)
{
  if (AGGREGATE_TYPE_P (type)
   && TYPE_SIZE (type)
   && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST
   && (TREE_INT_CST_LOW (TYPE_SIZE (type)) >= 256
   || TREE_INT_CST_HIGH (TYPE_SIZE (type))) && align < 256)
return 256;

Voilà, there we have my culprit – commenting this out resulted
in a 12-byte yield (not 42*2 byte, as the code generated for e.g.
“strncmp(foo, opname[i], (size_t)oplen[i])” is a bit less optimal
than for “strncmp(foo, opinfo[i].name, (size_t)opinfo[i].len)”,
but that’s okay)… and a 206-byte reduction for the rest of the
codebase.

Seeing that ix86_data_alignment() also contains amd64-specific
alignment, and that MMX stuff generally needs more alignment,
I first did this:

&& (TREE_INT_CST_LOW (TYPE_SIZE (type)) >= 256
-  || TREE_INT_CST_HIGH (TYPE_SIZE (type))) && align < 256)
+  || TREE_INT_CST_HIGH (TYPE_SIZE (type)))
+   && (TARGET_MMX || !optimize_size)
+   && align < 256)
 return 256;

The idea here being that both TARGET_SSE and TARGET_64BIT
enable TARGET_MMX, and to do this only for -Os.

Then I went into the svn history for this function and
discovered that its predecessor in gcc/config/i386/i386.h
(the DATA_ALIGNMENT(TYPE, ALIGN) macro) was added in around
2000, before MMX was even a thing, to “improve floating point
performance”, but that architectures apparently can do without.

Now I’m trying roughly this:

[…]
 ix86_constant_alignment (tree exp, int align)
 {
+  if (optimize_size && !TARGET_MMX)
+return align;
[…]
 ix86_data_alignment (tree type, int align)
 {
+  if (optimize_size && !TARGET_MMX)
+return align;
[…]
 ix86_local_alignment (tree type, int align)
 {
+  if (optimize_size && !TARGET_MMX)
+return align;
[…]

This opens up some questions from me to the GCC developers
though:

– Is this safe to do? (My baseline here is 3.4.6, so
  if someone still remembers, please do answer, but
  the scope of this eMail in total goes beyond that.)

– Is this something that GCC trunk could benefit from?

– I’ve also been wondering whether this applies to
  regular strings (not arrays that technically are
  strings too) as well…

– Is the exclusion of MMX and 64BIT required? (Since
  this code has been there “ever” since even before
  MMX support landed in GCC, I fear that some of the
  “required alignment” are done inside this function
  instead of in other places.)

– Even better: is this something we could do for *all*
  platforms in general? Something like this, in gcc/varasm.c:

 #ifdef DATA_ALIGNMENT
+  if (!optimize_size)
-  align = DATA_ALIGNMENT (TREE_TYPE (decl), align);
+align = DATA_ALIGNMENT (TREE_TYPE (decl), align);
 #endif

My aim here is to tighten the density (reduce the size
of the individual sections in the .o file and, ideally,
the file size of the final executable) of the generated
code for -Os while not breaking anything, and leaving
the case of not-Os completely alone.

Of course I’ll do a full rebuild of MirBSD (which uses
-Os in almost all code, only some legacy crap from the
1970s like AT&T nroff uses -O1 or even -O0 as the code
doesn’t conform to ISO C) to see if things break, but
I’m also interested in the bigger picture, besides I
have invested into embedded systems (FreeWRT/OpenADK,
but also dietlibc, klibc, etc.) which love small code.

Thanks in advance,
//mirabilos
PS:  Please do Cc me, I’m not subscribed.
PPS: I’ve exchanged assignment papers with the FSF about GCC,
 so feel free to just commit anything, if it makes sense.
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh

Re: [RFD] Extremely large alignment of read-only strings

[Thorsten Glaser]

(apologies for the double post, GMane had a hiccup. The latter,
which this is a reply to, has one discussion item more, so please
ignore the other)

Re: [RFD] Extremely large alignment of read-only strings

[Thorsten Glaser]

Alexander Monakov dixit:

>First of all, I think option -malign-data=abi (new in GCC 5) addresses your
>need: it can be used to reduce the default (excessive) alignment to just the
>psABI-dictated value (you can play with this at https://gcc.godbolt.org even if

Ah, nice!

>Note that like with other ABI-affecting options you need to consider
>implications for linking with code you're not building yourself: if the other
>code expects bigger alignment, you'll have a bug.

Yes, of course, but in this case, “the other code” is libc,
and it “better behave”. ☺

>> I was using, also worked for C, not just C++), which showed
>> me that the alignment was 256 even (only later reduced to
>> 32 as that’s the maximum alignment for i386).
>
>Most likely the quoted figures from GCC dumps are in bits, not bytes.

Oh, or that. That makes more sense, yes, thanks.

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

Re: [RFD] Extremely large alignment of read-only strings

[Thorsten Glaser]

Dixi quod…

>Alexander Monakov dixit:
>
>>First of all, I think option -malign-data=abi (new in GCC 5) addresses your
>>need: it can be used to reduce the default (excessive) alignment to just the
>>psABI-dictated value (you can play with this at https://gcc.godbolt.org even 
>>if
>
>Ah, nice!

… except -malign-data=abi is, apparently, cris-only.

bye,
//mirabilos
-- 
Gast: „Ein Bier, bitte!“
Wirt: „Geht auch alkoholfrei?“
Gast: „Geht auch Spielgeld?“

Re: [RFD] Extremely large alignment of read-only strings

[Thorsten Glaser]

Hans-Peter Nilsson dixit:

>> ? except -malign-data=abi is, apparently, cris-only.

>ITYM "i386-only".  I see "malign-data=" in
>gcc/config/i386/i386.opt.

No (actually tested on amd64, which didn’t support it).

>(Not sure why the CRIS port was mentioned at all.

The GCC 6 texinfo documentation *only* lists this for cris.

>There's no option named "-malign-data=abi" for
>cris-*; the closest is an option named "-mdata-align".)

Hmm… maybe that’s the confusion.

Thanks,
//mirabilos
-- 
Stéphane, I actually don’t block Googlemail, they’re just too utterly
stupid to successfully deliver to me (or anyone else using Greylisting
and not whitelisting their ranges). Same for a few other providers such
as Hotmail. Some spammers (Yahoo) I do block.

Re: build system: gcc_cv_libc_provides_ssp and NATIVE_SYSTEM_HEADER_DIR

[Thorsten Glaser]

Thomas Schwinge dixit:

>First, the check for gcc_cv_libc_provides_ssp is not complete, as has
>already pointed out (with patches!) before, but is still not fixed on
>trunk.  Let me revisit that: in configure.ac it is being checked for
>``case "$target" in *-*-linux*)'' which should rather match ``*-*-linux*
>| *-*-*-gnu* | *-*-gnu*'' to catch all GNU/Linux, GNU/Hurd, GNU/k*BSD
>systems.

FWIW, DragonFly, MirBSD and OpenBSD (at least) also provide the SSP
functions in their respective C libraries.

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"

Re: build system: gcc_cv_libc_provides_ssp and NATIVE_SYSTEM_HEADER_DIR

[Thorsten Glaser]

Thomas Schwinge dixit:

>Ideally, IMO, this test (for stack-smashing-protection support in glibc)
>should not be done by grepping through SYSROOT's features.h, but instead
>by using the CPP for doing that.

Why not just autoconf?

Check for the presence of __stack_smash_handler() in libc… or am I missing
something important here?

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"

Re: build system: gcc_cv_libc_provides_ssp and NATIVE_SYSTEM_HEADER_DIR

[Thorsten Glaser]

Joseph S. Myers dixit:

>It's desirable to be able to configure GCC correctly in the presence of 
>installed headers and only a dummy libc.so, so as to get a GCC that can be 
>used to build the full glibc.

Ah, right, the GNU case. Sorry, I totally did not have that one in mind,
even though I know of similar things as I’m also a FreeWRT developer,
which cross-bootstraps a gcc/µClibc system.

So the best option for the (non-glibc) BSDs would probably be to hard-code
SSP-in-libc support depending on the operating system version from the
target tuple?

bye,
//mirabilos
-- 
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there was ffs, and in the middle, there was ffs, and at the end, there
was still ffs, and the sys admins knew it was good. :)  -- Ted Unangst über *fs

Re: Reconsidering gcjx

[Thorsten Glaser]

Tom Tromey dixit:

>In my preferred approach we would simply delete a portion of the
>existing gcj and turn jc1 into a purely bytecode-based compiler.

>ecj is written in java.  This will complicate the bootstrap process.

Why not keep enough support in jc1 to bootstrap ecj?
Maybe split out so that it can be used for only bootstrapping
(calling it jc1source or something, and being built only once
during a make bootstrap)?

>However, the situation will not be quite as severe as the Ada

Indeed. Try to build gcc 3.4 with gcc 4.0 (the Ada part)...

But having front-ends written in languages other than
C really is no good idea. On the other hand, in this
case the technical and maintenance (dropping off the
work to other people) benefits may outweigh it.

bye,
//mirabile
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt

Re: Reconsidering gcjx

[Thorsten Glaser]

Andrew Haley dixit:

> > Thorsten> Why not keep enough support in jc1 to bootstrap ecj?
> > 
> > We don't know how much of the language that would be.
>
>And we can't tell _a priori_.  As I understand it, the intention is to
>use upstream sources, and they will change.

Just keep the current state then - maybe in a separate frontend
only used for bootstrapping, sharing some code with the final,
class-only, frontend. And expand it if needed for ecj.

bye,
//mirabile
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt

Re: Moving to an alternate VCS

[Thorsten Glaser]

Chris Jefferson dixit:

> As someone who just started submitting code, I'd say for a beginner the most
> important features of the version control system are (in particular relating 
> to
> CVS)

4) [svn] Get rid of the forced "ChangeLog" entry
   - writing (it's already the changeset's commit message)
   - formatting (can't that be done automagically?)
   - rotating (d'oh)

  I've always found the FSF's ChangeLog policy a bit weird
  (for CVS projects - for RCS projects it's understandable).

bye,
//mirabile
-- 
> [...] Echtzeit hat weniger mit "Speed"[...] zu tun, sondern damit, daß der
> richtige Prozeß voraussagbar rechtzeitig sein Zeitscheibchen bekommt.
Wir haben uns[...] geeinigt, dass das verwendete Echtzeit-Betriebssystem[...]
weil selbst einfachste Operationen *echt* *Zeit* brauchen.  (aus d.a.s.r)

Re: Moving to an alternate VCS

[Thorsten Glaser]

Joe Buck dixit:

>On Fri, Feb 11, 2005 at 01:49:34PM +0000, Thorsten Glaser wrote:
>>   I've always found the FSF's ChangeLog policy a bit weird
>>   (for CVS projects - for RCS projects it's understandable).
>
>The ChangeLog fulfills a sometimes-ignored legal requirement of the GPL:

Sure, but other projects do it differently.

On every checkin, an eMail is generated and an entry appended
to an automatically rotated ChangeLog file. (Thanks to the
(neglected by the other BSDs) update to GNU cvs 1.12, I can
even add changeset-like facilities.)

>But we have
>to wind up with something like a ChangeLog in any distributed version of
>GCC.

Sure, it's a change. I was just trying to hint people
that it might be worthwhile to think about it, and a
bit curious myself what the GNU developers say about
that.

bye,
//mirabile

"stable" version bootstrapping

[Thorsten Glaser]

Hi,

the GCC wiki says:

“We will periodically pick a stable version of GCC, and require that that
version of GCC be able to build all versions of GCC up to and including
the next stable version. E.g., we may decide that all newer versions of
GCC should be buildable with GCC 4.3.5.”

Which version has currently been picked, and where can such information
reliably (thinking of a permanent weblink) be found?

Background to this question is that MirBSD might be transitioning to use
pcc in the base system instead of the old GCC 3.4, and thus will need a
series of bootstrap/stable compilers ported in order to be able to build
the modern C++ beasts (LLVM/Clang and GCC 4.8 and up), so I’d like to know
which version(s) I should pick, since pcc is C-only.

(Also, general curiosity. This information might also be of interest and
possibly value to other porters to minority operating environments such
as FreeMiNT, the other BSDs, etc.)

Thanks in advance,
//mirabilos

Re: Intentional or accidental backward-incompatibility w.r.t. process attributes?

[Thorsten Glaser]

NightStrike  gmail.com> writes:

> > ... used to work, with the attribute from the declaration being applied also
> > to the definition.

I stumbled upon this as well recently.

> Someone else just asked not too long ago:
> 
> http://gcc.gnu.org/ml/gcc-help/2013-03/msg00012.html

Yes, but there’s no solution to the question of whether this was
deliberate (and, if so, why).

bye,
//mirabilos

Re: "stable" version bootstrapping

[Thorsten Glaser]

Tobias Burnus  net-b.de> writes:

> GCC since 4.8 requires a C++98 compiler, i.e. GCC since 3.4 should be 
> fine. However, who knows when some C++11 features will start to get 

Hrm, indeed.

> used. Thus, why not using the latest compiler which still builds with C, 
> i.e. GCC 4.6 or GCC 4.7. (The latter bootstraps with C++, unless you use 
> --disable-build-poststage1-with-cxx)

Ah, ok, thanks for that bit. I’ll have to see whether they bootstrap
reliably with pcc (did not try that yet, plus I’ll have to write the
appropriate target support for them).

> (My impression that simply different host compilers get used without 
> anyone singling out a specific version. If problems with a host compiler 
> pops up, one can still fix GCC. To do so, it helps if the issue is 
> reported while the version of GCC, which you try to build, is still 
> maintained.)

I think that’s the key point here: the versions in question are
probably no longer maintained when a problem pops up.

But I kind of like the approach of having a “stable” version every
once in a while, which can then build all later versions up to and
including the next “stable” one, possibly with fixes related to that
aim being officially included later even when the “stable” version
itself is already otherwise closed. It will make compiling almost
arbitrary GCC versions easy, as one doesn’t have to build every
in-between version, which is still quite the task.

And in things like BSD ports, the usual way *is* to start from just
a “base system” and compile everything from source, every time, the
availability of some binary packages notwithstanding (these are just
convenience and not the “good” way to do things). That’s why this
point is kind of important.

But no need to hurry, I’m asking a bit in advance, just in case
this needs to get decided first or something.

bye,
//mirabilos

Re: "stable" version bootstrapping

[Thorsten Glaser]

Richard Biener dixit:

>in the install instructions (gcc/doc/install.texi) in the
>pre-requesites section.

Ah yes, I saw that, but…

>Currently it reads:

ⓐ that’s “curently”, plus it doesn’t specificially say
  that 3.4 is the “stable” version currently picked,
  which is one of the reasons I thought to ask here;

>which you can read as "bootstrapping with GCC 3.4 works, earlier
>versions may, but you are not supported here".

and ⓑ does anyone regularily test bootstrapping from
gcc 3.4 on various platforms?

Especially the C++ case is interesting, as I had to
apply several patches (some of them backported myself)
to it to even get LLVM to *compile* (and link), some
years ago.

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh

Re: [PATCH v17 2/2] c: Add __countof__ operator

[Thorsten Glaser]

Hi Alejandro,

>On Sun, Oct 27, 2024 at 01:40:23AM GMT, mirabilos wrote:
>> Not too sure what the root context of this thread is, but in BSD land
>
>The root context is that
>
>-  _Lengthof was added to C2y in the Minnesota meeting.  It was proposed

where/how would this be used for? Also, do you have the n.pdf link
handy? I don’t actively follow C other than what thephd posts.

>-  I'm sending a patch to GCC proposing __countof__, since overloading
>   length for both string length and array number of elements is (IMO)
>   going to promote off-by-one bugs in string-handling code (and I've

Definitely! The string length is one less than the amount of array
elements it has (works for char and wide strings).

>-  _Nelementsof
>-  _Nelemsof

If you want to shorten elements, elts is probably seen more
often than elems, at least in my experience. But this is very
low-grade bikeshedding, so just me pointing it out but putting
not much weight behind it.

bye,
//mirabilos
PS: Got any contacts in the OpenBSD and NetBSD worlds that can
add input? They invest a lot into good C code as well, in
the OpenBSD case rather heavily (if opinionated).
-- 
 exceptions: a truly awful implementation of quite a nice idea.
 just about the worst way you could do something like that, afaic.
 it's like anti-design.   that too… may I quote you on that?
 sure, tho i doubt anyone will listen ;)

Re: [PATCH v17 2/2] c: Add __countof__ operator

[Thorsten Glaser]

Alejandro Colomar dixit:

>Yes; there are four n papers.  See below, plus the history of why
>four papers.

Thanks, will look at them but probably on Tuesday.

>> >-  _Nelementsof
>> >-  _Nelemsof
>>
>> If you want to shorten elements, elts is probably seen more
>> often than elems, at least in my experience. But this is very
>> low-grade bikeshedding, so just me pointing it out but putting
>> not much weight behind it.
>
>That was my original proposal, but everybody I've talked so far told me
>they preferred _Nelemsof.  I don't care about it at all, so whatever.

Ah, okay.

>> PS: Got any contacts in the OpenBSD and NetBSD worlds that can
>> add input? They invest a lot into good C code as well, in
>> the OpenBSD case rather heavily (if opinionated).
>
>I don't.  If you do, please let them know.  Theo doesn't seem to have a
>good opinion of me, but maybe he could help.

I fear we share this property but I can try to reach out via
Miod, he might have an idea, and via bsiegert to NetBSD.

bye,
//mirabilos

Re: [PATCH v17 2/2] c: Add __countof__ operator

[Thorsten Glaser]

On Fri, 8 Nov 2024, Alejandro Colomar wrote:

>I've just checked that JeanHeyd opened a survey about the name.
>It's here: .

Yes, I saw it on Fedi, where it was announced big, and filled it in.

Thanks,
//mirabilos
-- 
11:56⎜«liwakura:#!/bin/mksh» also, i wanted to add mksh to my own distro │
i was disappointed that there is no makefile │ but somehow the Build.sh is
the least painful built system i've ever seen │ honours CC, {CPP,C,LD}FLAGS
properly │ looks cleary like done by someone who knows what they are doing