Re: GCC 4.6.0 Released

[Bernd Roesch]

Hello 

On 28.03.11, you wrote:

> 
> I think that the right place for the note is at
> 
> http://gcc.gnu.org/install/specific.html#x-x-cygwin
> 
> It should say something like:
> 
> Versions of Cygwin older than x.y.z fail to build the decimal floating
> point library, libbid.  You will either need to upgrade Cygwin to a newer
> version or disable decimal floating point by specifying 
> --disable-decimal-float
> at configure time.

I think it can too in readme add that on current cygwin on win 64 and multicore 
CPU GCC compile lots
slower as on single CPU systems.
To speed up GCC and compile 3* faster in windows taskmanager can the CPU number 
set to 1 for the
shell task.

But i hope there come some day a fix for this problem.I get sometimes hang and 
after 10-20 sec come
a message that vfork problem is detect.
maybe when GCC use fork for task create or native windows task create it work 
better ? 

> 
> 
Regards

Re: GCC 4.6.0 Released

[Bernd Roesch]

Hello 

On 29.03.11, you wrote:

>> 
>>   This sounds like the generic Cygwin fork-error/BLODA problem and not
>> specific to GCC.
> 
> Indeed.  For what it's worth, gcc itself *does* use the Cygwin spawn* 
> functions
> to avoid this problem, but (curiously) the Cygwin versions of make, bash, and
> expect do not.  Therefore the problem can still be seen during a build.

I add an error in file libiberty/pex-win32.c to check if cygwin build use 
win32_spawn.
but gcc compile ok, so it seem that cygwin build do not use pex-win32.c.Or need 
i set a compile
option for GCC ?

static pi d_t
win32_spawn (const char *executable,

I add now an error in pex_unix.c, and compile file.so cygwin build use vfork 
stuff.

static pid_t
pex_unix_exec_child (struct pex_obj *obj, int flags, const char *executable,

I try to build a gprof build, but i dont know what options i need set for GCC 
build and if gprof
work on
cygwin.

this is in config.log

  $ /bernd/gcc4/configure --target=m68k-amigaos --with-cpu=m68040 
--prefix=/usr/local/amiga 

...

configure:2429: checking build system type
configure:2443: result: i686-pc-cygwin
configure:2490: checking host system type
configure:2503: result: i686-pc-cygwin
configure:2523: checking target system type
configure:2536: result: m68k-unknown-amigaos
configure:2590: checking for a BSD-compatible install
configure:2658: result: /usr/bin/install -c 





> 
> 
> r~
Regards

On Cygwin build i try to use pex_win32 but do not work

[Bernd Roesch]

Hello 

On 30.03.11, you wrote:

> Bernd Roesch  writes:
> 
>> I add an error in file libiberty/pex-win32.c to check if cygwin build use 
>> win32_spawn.
>> but gcc compile ok, so it seem that cygwin build do not use pex-win32.c.Or 
>> need i set a compile
>> option for GCC ?
> 
> The choice is determined in libiberty/configure.ac:
> 
> *-*-mingw* | *-*-winnt*)  pexecute=pex-win32  ;;
> *-*-msdosdjgpp*)  pexecute=pex-djgpp  ;;
> *-*-msdos*)   pexecute=pex-msdos  ;;
> *)pexecute=pex-unix   ;;
> 
> It may be appropriate to use pex-win32 for *-*-cygwin*.  I don't know,
> as I am not a cygwin user myself.

thanks, i add this in configure too, i clear whole objdir, do configure and 
make and i see libiberty
obj dir contain now a pex-win32.o file and no pex-unix.o file.

Compile of GCC package fail when libgcc should compile with the new create xgcc 
compiler.

I install then the compiler files and do a testcompile with netsurf to see more 
errors, but it not
work too.I get only this
message.both new files are in bin dir.maybe somebody can help what i need 
change more, so i can
test if GCC work same fast as with 1 CPU core, when all cores are enable.

 COMPILE: content/content.c
m68k-amigaos-gcc: couldn't run 'm68k-amigaos-gcc-4.5.0': CreateProcess: No
file or directory
make: *** [build-CYGWIN_NT-6.1-WOW64-amigaos3/content_content.o] Error 1

i see on this message, seem GCC do for every compiler run create 2 threads.
1. gcc create gcc-4.5.0.
2. gcc4.5.0 create cc1

so if pex_win is faster, can give high speedup. 

this is what i add in libiberty/configure and libiberty/configure.ac

case "${host}" in
  *-*-cygwin* | *-*-mingw* | *-*-winnt*) pexecute=./pex-win32.o  ;;
 *-*-msdosdjgpp*)   pexecute=./pex-djgpp.o  ;;
 *-*-msdos*)pexecute=./pex-msdos.o  ;;
 *) pexecute=./pex-unix.o   ;;
esac



> 
> Ian
Regards

Re: m68k - GCC 4.4.0 generates not so good code from asm inline

[Bernd Roesch]

Hello 

On 29.07.09, you wrote:

if you have a account you can report that as a Bug.
gcc4 have the advantage its possible to switch in source optimizer on or
off, but how it work, i dont know.

> When I use -O1 with GCC 4.4.0 (-m68060 -fomit-frame-pointer), I get better
> code.
> 
> #include 
> #include 
> 
> inline int64_t MUL64(int a, int b)
> {
> 
> uint32_t resh, resl;
> uint32_t au = a;
> uint32_t bu = b;
> 
> __asm__ ("move.l %0, d5\n\t"
> "move.l %1, d4\n\t"
> "moveq #16, d3\n\t"
> "move.l %0, d2\n\t"
> "mulu %1, %0\n\t"
> "lsr.l d3, d4\n\t"
> "lsr.l d3, d5\n\t"
> "mulu d4, d2\n\t"
> "mulu d5, %1\n\t"
> "mulu d5, d4\n\t"
> "move.l d2, d5\n\t"
> "lsr.l d3, d2\n\t"
> "add.w %1, d5\n\t"
> "addx.l d2, d4\n\t"
> "lsl.l d3, d5\n\t"
> "lsr.l d3, %1\n\t"
> "add.l d5, %0\n\t"
> "addx.l d4, %1\n\t"
> : "=d"(resl), "=d"(resh)
> : "0"(au), "1"(bu)
> : "d2", "d3", "d4", "d5");
> 
> if (a < 0)
> resh -= bu;
> if (b < 0)
> resh -= au;
> 
> return ((uint64_t)resh << 32) | resl;
> }
> 
> GCC 4.4.0 -O3:
> 
> #NO_APP
> .text
> .even
> .globl _MUL64
> _MUL64:
> movem.l #16128,-(sp)
> move.l 28(sp),d0
> move.l 32(sp),a0
> move.l d0,d6
> move.l a0,d1
> #APP
> ;# 11 "mul645.c" 1
> move.l d6, d5
> move.l d1, d4
> moveq #16, d3
> move.l d6, d2
> mulu d1, d6
> lsr.l d3, d4
> lsr.l d3, d5
> mulu d4, d2
> mulu d5, d1
> mulu d5, d4
> move.l d2, d5
> lsr.l d3, d2
> add.w d1, d5
> addx.l d2, d4
> lsl.l d3, d5
> lsr.l d3, d1
> add.l d5, d6
> addx.l d4, d1
> 
> #NO_APP
> tst.l d0
> jlt L6
> tst.l a0
> jlt L7
> L3:
> move.l d1,d2
> clr.l d3
> move.l d2,d0
> move.l d3,d1
> or.l d6,d1
> move.l d0,d6
> move.l d1,d7
> move.l d7,d1
> movem.l (sp)+,#252
> rts
> L7:
> sub.l d0,d1
> move.l d1,d2
> clr.l d3
> move.l d2,d0
> move.l d3,d1
> or.l d6,d1
> move.l d0,d6
> move.l d1,d7
> move.l d7,d1
> movem.l (sp)+,#252
> rts
> L6:
> sub.l a0,d1
> tst.l a0
> jge L3
> jra L7
> 
> GCC 4.4.0 -O2:
> 
> #NO_APP
> .text
> .even
> .globl _MUL64
> _MUL64:
> movem.l #16128,-(sp)
> move.l 28(sp),d0
> move.l 32(sp),a0
> move.l d0,d6
> move.l a0,d1
> #APP
> ;# 11 "mul645.c" 1
> move.l d6, d5
> move.l d1, d4
> moveq #16, d3
> move.l d6, d2
> mulu d1, d6
> lsr.l d3, d4
> lsr.l d3, d5
> mulu d4, d2
> mulu d5, d1
> mulu d5, d4
> move.l d2, d5
> lsr.l d3, d2
> add.w d1, d5
> addx.l d2, d4
> lsl.l d3, d5
> lsr.l d3, d1
> add.l d5, d6
> addx.l d4, d1
> 
> #NO_APP
> tst.l d0
> jlt L6
> tst.l a0
> jlt L7
> L3:
> move.l d1,d2
> clr.l d3
> move.l d2,d0
> move.l d3,d1
> or.l d6,d1
> move.l d0,d6
> move.l d1,d7
> move.l d7,d1
> movem.l (sp)+,#252
> rts
> L7:
> sub.l d0,d1
> move.l d1,d2
> clr.l d3
> move.l d2,d0
> move.l d3,d1
> or.l d6,d1
> move.l d0,d6
> move.l d1,d7
> move.l d7,d1
> movem.l (sp)+,#252
> rts
> L6:
> sub.l a0,d1
> tst.l a0
> jge L3
> jra L7
> 
> GCC 4.4.0 -O1:
> 
> #NO_APP
> .text
> .even
> .globl _MUL64
> _MUL64:
> movem.l #16176,-(sp)
> move.l 40(sp),d0
> move.l 36(sp),a2
> move.l a2,d7
> move.l d0,d6
> #APP
> ;# 11 "mul645.c" 1
> move.l d7, d5
> move.l d6, d4
> moveq #16, d3
> move.l d7, d2
> mulu d6, d7
> lsr.l d3, d4
> lsr.l d3, d5
> mulu d4, d2
> mulu d5, d6
> mulu d5, d4
> move.l d2, d5
> lsr.l d3, d2
> add.w d6, d5
> addx.l d2, d4
> lsl.l d3, d5
> lsr.l d3, d6
> add.l d5, d7
> addx.l d4, d6
> 
> #NO_APP
> tst.l a2
> jge L2
> sub.l d0,d6
> L2:
> tst.l d0
> jge L3
> sub.l a2,d6
> L3:
> move.l d6,d1
> clr.l d2
> or.l d7,d2
> move.l d1,d0
> move.l d2,d1
> movem.l (sp)+,#3324
> rts
> 
> GCC 4.4.0 -O0:
> 
> #NO_APP
> .text
> .even
> .globl _MUL64
> _MUL64:
> lea (-16,sp),sp
> movem.l #16128,-(sp)
> move.l 44(sp),32(sp)
> move.l 48(sp),36(sp)
> move.l 32(sp),d1
> move.l 36(sp),d0
> #APP
> ;# 11 "mul645.c" 1
> move.l d1, d5
> move.l d0, d4
> moveq #16, d3
> move.l d1, d2
> mulu d0, d1
> lsr.l d3, d4
> lsr.l d3, d5
> mulu d4, d2
> mulu d5, d0
> mulu d5, d4
> move.l d2, d5
> lsr.l d3, d2
> add.w d0, d5
> addx.l d2, d4
> lsl.l d3, d5
> lsr.l d3, d0
> add.l d5, d1
> addx.l d4, d0
> 
> #NO_APP
> move.l d1,28(sp)
> move.l d0,24(sp)
> tst.l 44(sp)
> jge L2
> move.l 36(sp),d0
> sub.l d0,24(sp)
> L2:
> tst.l 48(sp)
> jge L3
> move.l 32(sp),d2
> sub.l d2,24(sp)
> L3:
> move.l 24(sp),d7
> clr.l d6
> move.l d7,d0
> clr.l d1
> move.l 28(sp),a1
> lea 0.w,a0
> move.l a0,d2
> move.l a1,d3
> or.l d2,d0
> or.l d3,d1
> movem.l (sp)+,#252
> lea (16,sp),sp
> rts 
> 
> Regards
> 
Regards

Re: GCC 4..4.x speed regression - help?

[Bernd Roesch]

please correct the Bugreport 40454 with the values of gcc 4.1.2 4.2.5.

it seem 4.1.2 reach near same speed as 3.4.0 but all later gcc are
slower in some programs.

this can also see on ffmpeg. also on X86 ffmpeg see here it is see.

what is change after 4.1.2 that can cause slower executable speed ?

here can also see on ffmpeg X86 that GCC compiler upto 4.1.2 get near same
speed, then on 4.2.4 it get suddenly slower.

http://multimedia.cx/eggs/intel-beats-up-gcc/

On 16.08.09, you wrote:

> Hi,
> 
> I found out that GCC 4.4.x build of minigzip from zlib package is a lot
> slower compared to GCC 3.4.0 build. Maybe someone can compile minigzip for
> his system with GCC 3.4.x and GCC 4.4.x and compare time of compression
> with bigger file? This way we would know if this regression only happens
> on the m68k GCC or maybe on other platforms too.
> 
> I really don't like regressions like this :/
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454
> 
> Regards
> 
Regards

Re: "-fno-unswitch-loops" option have no effect?

[Bernd Roesch]

Hello ami_stuff

On 17.08.09, you wrote:

> Hi,
> 
>> Hundreds and hundreds of people read this list, so every low-detail
>> "I think there may be a bug" message you send wastes hours of other
>> people's time.
> 
> Ok, Ok, but if someone will reproduce the same problem on his system I can
> fill bugreport, otherwise I will only waste my time, hours of my time, to
> start detailed bugreport. Maybe this is only fault of my GCC's build?

gcc > 4 AOS 68k builds are build from offical gcc sourcetree and there are
no changes 


> 
>> If it *is* a bug, on the bug tracker, it will be picked up by people
>> interested in that specific area
> 
> It may takes months before someone will look at the bugreport. If it's
> really a bug IMHO it's a bit critical bug.
> 
>> though you don't seem to do much
>> in-depth research, nor do you supply any detail of what you did and
>> what you expected.
> 
> There is no need for much detail, just compile any bigger sourcecode with
> -O3 -fno-.. and after that with -O2  When the object files are not
> identical, something is wrong and I can start a bug report.

how much is size diffrent ?

You use
-finline-functions -fpredictive-commoning -fgcse-after-reload
-ftree-vectorize 

right ?

I see in Gcc source that there is more set on -O3.
 flag_ipa_cp_clone = opt3;
  if (flag_ipa_cp_clone)
flag_ipa_cp = 1; 

.but i
think you can easy test, compile the ffmpeg, if it give no internal
compiler error with -fno then it work.

here is from source opt.c what is set on opt3

opt3 = (optimize >= 3); 
flag_predictive_commoning = opt3;
  flag_inline_functions = opt3;
  flag_unswitch_loops = opt3;
  flag_gcse_after_reload = opt3;
  flag_tree_vectorize = opt3;
  flag_ipa_cp_clone = opt3;
  if (flag_ipa_cp_clone)
flag_ipa_cp = 1; 



> 
> Regards
> 
Regards

char drawstrings[DRAW_MAX][] = { " .. give error

[Bernd Roesch]

Hi, 

I compile an old code which use this and i think its compile with Gcc 2.95
and the
PPC GCC 1998 or 1999
it fail to compile with newer compiler.

#define DRAW_MAX4
char drawstrings[DRAW_MAX][] = {
"Number of points drawn using 3D hardware:",
"Number of lines drawn using 3D hardware:",
"Number of triangles drawn using 3D hardware:",
"Number of quads drawn using 3D hardware:"};

give error on GCC3.4.0

98 E:\amiga\AmiDevCpp\bernd\StormMesaNew\src\AMIGA\src\ADisp_HW.h elements
of array `drawstrings' have incomplete type 

gcc4.5.0 report this.

6 E:\amiga\AmiDevCpp\bernd\StormMesaNew\src\AMIGA\src\ADisp_HW.h:98 array
type has incomplete element type 

Is this a GGC Bug, or is that syntax no longer support ?.

I change code to this, thats more easy and it compile ok but must check if
its same.

const char * drawstrings[] = {
"Number of points drawn using 3D hardware:",
"Number of lines drawn using 3D hardware:",
"Number of triangles drawn using 3D hardware:",
"Number of quads drawn using 3D hardware:"
};

Bye

Re: Strange optimisation problem - gcc 4.3.2

[Bernd Roesch]

Hello 

I notice maybe a simular problem.when there is a constant pointer then GCC
>4.0 do not inline the func.gcc 3 do.

that can see on this old whetstone benchmark.with gcc 3.4.0 run faster.

http://www.netlib.org/benchmark/whetstone.c

as soon the term double *Z is change to double Z the func is inline and run
faster on GCC >4.
In GCC 3.4.0 its always inline.

void
P3(double X, double Y, double *Z)
{
double X1, Y1;

X1 = X;
Y1 = Y;
X1 = T * (X1 + Y1);
Y1 = T * (X1 + Y1);
*Z  = (X1 + Y1) / T2;
}




> Hi everyone,
> 
> I've been looking at adding some code to a performance-critical section 
> of OpenBIOS, and I'm quite confused by how some of the changes I am 
> making are affecting the overall performance.
> 
> For a benchmark, I am using a recursive fibonacci function to test the 
> effect of any changes that I have made. The test machines is an Intel 
> Core 2 x86 running under a 64-bit Debian Lenny installation.
> 
> Firstly, here are the benchmark results running from the unmodified SVN 
> source tree:
> 
> 
> bu...@zeno:~/src/openbios/openbios-devel$ time echo "28 fib-rec u. bye" 
> | ./obj-x86/openbios-unix ./obj-x86/openbios-x86.dict
> Welcome to OpenBIOS v1.0 built on Nov 9 2009 17:12
>   Type 'help' for detailed information
> 
> [unix] Booting default not supported.
> 
>> 28 fib-rec u. bye 6197ecb
> Farewell!
> 
>  ok
> 
> real0m37.946s
> user0m37.178s
> sys 0m0.020s
> 
> 
> I then add a simple C function pointer below to the top of the forth 
> kernel file (which is currently not referenced by any other code changes):
> 
> 
> void (*debughook) (void);
> 
> 
> If I then re-build and re-run the same benchmark, the results now look 
> like this:
> 
> 
> bu...@zeno:~/src/openbios/openbios-devel$ time echo "28 fib-rec u. bye" 
> | ./obj-x86/openbios-unix ./obj-x86/openbios-x86.dict
> Welcome to OpenBIOS v1.0 built on Nov 9 2009 17:17
>   Type 'help' for detailed information
> 
> [unix] Booting default not supported.
> 
>> 28 fib-rec u. bye 6197ecb
> Farewell!
> 
>  ok
> 
> real0m52.564s
> user0m52.027s
> sys 0m0.012s
> 
> 
> So I'm really confused as to how adding a simply function pointer in the 
> global declaration section (without even adding any code to reference 
> it) suddenly incurs an extra 40% overhead? Can anyone explain why this 
> is, and/or point me to any suitable gcc optimisation guides?
> 
> For reference, the gcc compiler is gcc 4.3.2 under Debian Lenny and the 
> compile flags are:
> 
> -Os -g -Wall -Wredundant-decls -Wshadow -Wpointer-arith
> -Wstrict-prototypes -Wmissing-declarations -Wundef -Wendif-labels 
> -Wstrict-aliasing -Wwrite-strings -Wmissing-prototypes
> 
> 
> Many thanks,
> 
> Mark.
> 
Regards

where can find source snapshots of first GCC 4.5.0 ?

[Bernd Roesch]

Hi, 

Because of this regression, 

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41311

Problem is in m68k-elf too, but happen not with any older GCC as 4.5.0

i want try out if the first GCC 4.5.0 snapshot
have this Problem or not.

The first GCC 4.5.0 i compile was in month 08.this have the Bug.
But i find on the mirror sites
only first snapshots now that are from month 10.

So maybe somebody can post me a link to older versions of GCC 4.5.0

Bye

Regression in GCC4.5.0 m68k-elf with r146817 (Author: matz)

[Bernd Roesch]

Hi, 

http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01459.html

This do the problem when compile ffmpeg.all gcc Versions that contain the
Patch fail 

-m68020 -m68881 -O1 ("Abort trap")

but work when do 

-m68020 -m68881 -O1 -fno-tree-ccp -fno-tree-dominator-opts (works ok).

.See here for more about the Problem.(the testprogram that show what code is
execute is also add)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41311

In a testprogram i cant reproduce the Problem, seem only happen on special
register usage.It seem have nothing to do with the backend.

But whats the line that fail i cant find out, because there are too many
changes at once in the Patch.

maybe somebody can help me so i can reproduce the problem better or add log
output for GCC in this special functions ?

Here is the changelog of the Patch

"""
2009-04-26  Michael Matz  

Expand from SSA.
* builtins.c (fold_builtin_next_arg): Handle SSA names.
* tree-ssa-copyrename.c (rename_ssa_copies): Use ssa_name() directly.
* tree-ssa-coalesce.c (create_outofssa_var_map): Mark only useful
SSA names. 
(compare_pairs): Swap cost comparison.
(coalesce_ssa_name): Don't use change_partition_var.
* tree-nrv.c (struct nrv_data): Add modified member.
(finalize_nrv_r): Set it.
(tree_nrv): Use it to update statements.
(pass_nrv): Require PROP_ssa.
* tree-mudflap.c (mf_decl_cache_locals,
mf_build_check_statement_for): Use make_rename_temp.
(pass_mudflap_2): Require PROP_ssa, run ssa update at finish.
* alias.c (find_base_decl): Handle SSA names.
* emit-rtl (set_reg_attrs_for_parm): Make non-static.
(component_ref_for_mem_expr): Don't leak SSA names into RTL.
* rtl.h (set_reg_attrs_for_parm): Declare.
* tree-optimize.c (pass_cleanup_cfg_post_optimizing): Rename
to "optimized", remove unused locals at finish.
(execute_free_datastructures): Make global, call
delete_tree_cfg_annotations.
(execute_free_cfg_annotations): Don't call
delete_tree_cfg_annotations.

* ssaexpand.h: New file.
* expr.c (toplevel): Include ssaexpand.h.
(expand_assignment): Handle SSA names the same as register
variables.
(expand_expr_real_1): Expand SSA names.
* cfgexpand.c (toplevel): Include ssaexpand.h.
(SA): New global variable.
(gimple_cond_pred_to_tree): Fold TERed comparisons into predicates.
(SSAVAR): New macro.
(set_rtl): New helper function.
(add_stack_var): Deal with SSA names, use set_rtl.
(expand_one_stack_var_at): Likewise.
(expand_one_stack_var): Deal with SSA names.
(stack_var_size_cmp): Use code (SSA_NAME / DECL) as tie breaker
before unique numbers.
(expand_stack_vars): Use set_rtl.
(expand_one_var): Accept SSA names, add asserts for them, feed them
to above subroutines.
(expand_used_vars): Expand all partitions (without default defs),
then only the local decls (ignoring those expanded already).
(expand_gimple_cond): Remove edges when jumpif() expands an
unconditional jump.
(expand_gimple_basic_block): Don't clear EDGE_EXECUTABLE here,
or remove abnormal edges.  Ignore insns setting the LHS of a TERed
SSA name.
(gimple_expand_cfg): Call into rewrite_out_of_ssa, initialize
members of SA; deal with PARM_DECL partitions here; expand
all PHI nodes, free tree datastructures and SA.  Commit instructions
on edges, clear EDGE_EXECUTABLE and remove abnormal edges here.
(pass_expand): Require and destroy PROP_ssa, verify SSA form, flow
info and statements at start, collect garbage at finish.
* tree-ssa-live.h (struct _var_map): Remove partition_to_var member.
(VAR_ANN_PARTITION) Remove.
(change_partition_var): Don't declare.
(partition_to_var): Always return SSA names.
(var_to_partition): Only accept SSA names.
(register_ssa_partition): Only check argument.
* tree-ssa-live.c (init_var_map): Don't allocate partition_to_var
member.
(delete_var_map): Don't free it.
(var_union): Only accept SSA names, simplify.
(partition_view_init): Mark only useful SSA names as used.
(partition_view_fini): Only deal with SSA names.
(change_partition_var): Remove.
(dump_var_map): Use ssa_name instead of partition_to_var member.
* tree-ssa.c (delete_tree_ssa): Don't remove PHI nodes on RTL
basic blocks.
* tree-outof-ssa.c (toplevel): Include ssaexpand.h and expr.h.
(struct _elim_graph): New member const_dests; nodes member vector of
ints.
(set_location_for_edge): New static helper.
(create_temp): Remove.
(insert_partition_copy_on_edge, insert_part_to_rtx_on_edge,
insert_value_copy_on_edge, insert_rtx_to_part_on_edge): New
functions.
(new_elim_graph): Allocate const_dests member.
(clean_elim_graph): Truncate const_dests member.
(delete_elim_graph): Free const_dests member.
(elim_graph_size): Adapt to new type of nodes member.
(elim_graph_add_node): Likewise.
(eliminate_name

what 68k platform config switch put float return values in fpu register ?

[Bernd Roesch]

Hi, 

I use same compiler settings -m68060 

a call of a function and return value with double float is on all
m68k-amigaos compiler (that use only other 68k config files but same main
source) as this.

  jsr testfunc
move.l d1,-(sp)
move.l d0,-(sp)
fdmove.d (sp)+,fp1
fsmove.x fp1,fp0
lea (16,sp),sp
fjgt L6 

You see the func always return the values in Integer Register d0 and d1 put
it to stack and then move it from stack to FPU regsiter.

the m68k-elf compiler have the return value in the FPU Register

jsr tesfunc
fsmove.x %fp0,%fp0
lea (16,%sp),%sp
fjgt .L9 



m68k-elf use the FPU Register and produce shorter and faster code

What Option i need set that GCC do this in FPU register ?


Bye

Re: gcc -O1 performs better than gcc -O2

[Bernd Roesch]

Hello 

On 14.02.10, you wrote:

> 
> Glad to hear that newer versions are back on track, does than mean
> that this won't be fixed in gcc 4.3.x series?

maybe you test the GCC 4.5.0 Version.

I notice in zlib (used in PNG image compression) when there is a image that
contain lots same pixel values a speedup of 30-50%

was no X86 CPU but i post only to show, that GCC 4.5.0 have a speedup get.

> 
>> 
>> Richard.
>> 
>>> # > gcc -O1  CRC16.c ;./a.out
>>> crc1:f532 crc2:f532
>>> crc16 tv_res:0 :12768
>>> CRC16 tv_res:0 :10795
>>> # > gcc -O2  CRC16.c ;./a.out
>>> crc1:f532 crc2:f532
>>> crc16 tv_res:0 :17092
>>> CRC16 tv_res:0 :11581
>>> 
>>> #> gcc --version
>>> gcc (Gentoo 4.3.4 p1.0, pie-10.1.5) 4.3.4
>>> 
>>> cpu:
>>> vendor_id       : GenuineIntel
>>> cpu family      : 6
>>> model           : 23
>>> model name      : Intel(R) Core(TM)2 Duo CPU     E8500  @ 3.16GHz
>>> stepping        : 10
>>> cpu MHz : 3159.236
>>> 
>>> Here is the CRC16.c:
>>> 
>>> #define u32 unsigned long
>>> #define u16 unsigned short
>>> #define u8 unsigned char
>>> 
>>> #include 
>>> 
>>> #include 
>>> #include 
>>> 
>>> /** CRC table for the CRC-16. The poly is 0x8005 (x^16 + x^15 + x^2 +
>> 1) */
>>> u16 const crc16_table[256] = {
>>>        0x, 0xC0C1, 0xC181, 0x0140, 0xC301, 0x03C0, 0x0280, 0xC241,
>>>        0xC601, 0x06C0, 0x0780, 0xC741, 0x0500, 0xC5C1, 0xC481, 0x0440,
>>>        0xCC01, 0x0CC0, 0x0D80, 0xCD41, 0x0F00, 0xCFC1, 0xCE81, 0x0E40,
>>>        0x0A00, 0xCAC1, 0xCB81, 0x0B40, 0xC901, 0x09C0, 0x0880, 0xC841,
>>>        0xD801, 0x18C0, 0x1980, 0xD941, 0x1B00, 0xDBC1, 0xDA81, 0x1A40,
>>>        0x1E00, 0xDEC1, 0xDF81, 0x1F40, 0xDD01, 0x1DC0, 0x1C80, 0xDC41,
>>>        0x1400, 0xD4C1, 0xD581, 0x1540, 0xD701, 0x17C0, 0x1680, 0xD641,
>>>        0xD201, 0x12C0, 0x1380, 0xD341, 0x1100, 0xD1C1, 0xD081, 0x1040,
>>>        0xF001, 0x30C0, 0x3180, 0xF141, 0x3300, 0xF3C1, 0xF281, 0x3240,
>>>        0x3600, 0xF6C1, 0xF781, 0x3740, 0xF501, 0x35C0, 0x3480, 0xF441,
>>>        0x3C00, 0xFCC1, 0xFD81, 0x3D40, 0xFF01, 0x3FC0, 0x3E80, 0xFE41,
>>>        0xFA01, 0x3AC0, 0x3B80, 0xFB41, 0x3900, 0xF9C1, 0xF881, 0x3840,
>>>        0x2800, 0xE8C1, 0xE981, 0x2940, 0xEB01, 0x2BC0, 0x2A80, 0xEA41,
>>>        0xEE01, 0x2EC0, 0x2F80, 0xEF41, 0x2D00, 0xEDC1, 0xEC81, 0x2C40,
>>>        0xE401, 0x24C0, 0x2580, 0xE541, 0x2700, 0xE7C1, 0xE681, 0x2640,
>>>        0x2200, 0xE2C1, 0xE381, 0x2340, 0xE101, 0x21C0, 0x2080, 0xE041,
>>>        0xA001, 0x60C0, 0x6180, 0xA141, 0x6300, 0xA3C1, 0xA281, 0x6240,
>>>        0x6600, 0xA6C1, 0xA781, 0x6740, 0xA501, 0x65C0, 0x6480, 0xA441,
>>>        0x6C00, 0xACC1, 0xAD81, 0x6D40, 0xAF01, 0x6FC0, 0x6E80, 0xAE41,
>>>        0xAA01, 0x6AC0, 0x6B80, 0xAB41, 0x6900, 0xA9C1, 0xA881, 0x6840,
>>>        0x7800, 0xB8C1, 0xB981, 0x7940, 0xBB01, 0x7BC0, 0x7A80, 0xBA41,
>>>        0xBE01, 0x7EC0, 0x7F80, 0xBF41, 0x7D00, 0xBDC1, 0xBC81, 0x7C40,
>>>        0xB401, 0x74C0, 0x7580, 0xB541, 0x7700, 0xB7C1, 0xB681, 0x7640,
>>>        0x7200, 0xB2C1, 0xB381, 0x7340, 0xB101, 0x71C0, 0x7080, 0xB041,
>>>        0x5000, 0x90C1, 0x9181, 0x5140, 0x9301, 0x53C0, 0x5280, 0x9241,
>>>        0x9601, 0x56C0, 0x5780, 0x9741, 0x5500, 0x95C1, 0x9481, 0x5440,
>>>        0x9C01, 0x5CC0, 0x5D80, 0x9D41, 0x5F00, 0x9FC1, 0x9E81, 0x5E40,
>>>        0x5A00, 0x9AC1, 0x9B81, 0x5B40, 0x9901, 0x59C0, 0x5880, 0x9841,
>>>        0x8801, 0x48C0, 0x4980, 0x8941, 0x4B00, 0x8BC1, 0x8A81, 0x4A40,
>>>        0x4E00, 0x8EC1, 0x8F81, 0x4F40, 0x8D01, 0x4DC0, 0x4C80, 0x8C41,
>>>        0x4400, 0x84C1, 0x8581, 0x4540, 0x8701, 0x47C0, 0x4680, 0x8641,
>>>        0x8201, 0x42C0, 0x4380, 0x8341, 0x4100, 0x81C1, 0x8081, 0x4040
>>> };
>>> #include 
>>> #define tole(x) __constant_cpu_to_le16(x)
>>> u16 const crc16_table_le[256] = {
>>> tole(0x), tole(0xC0C1), tole(0xC181), tole(0x0140), tole(0xC301),
>>> tole(0x03C0), tole(0x0280), tole(0xC241), tole(0xC601), tole(0x06C0),
>>> tole(0x0780), tole(0xC741), tole(0x0500), tole(0xC5C1), tole(0xC481),
>>> tole(0x0440), tole(0xCC01), tole(0x0CC0), tole(0x0D80), tole(0xCD41),
>>> tole(0x0F00), tole(0xCFC1), tole(0xCE81), tole(0x0E40), tole(0x0A00),
>>> tole(0xCAC1), tole(0xCB81), tole(0x0B40), tole(0xC901), tole(0x09C0),
>>> tole(0x0880), tole(0xC841), tole(0xD801), tole(0x18C0), tole(0x1980),
>>> tole(0xD941), tole(0x1B00), tole(0xDBC1), tole(0xDA81), tole(0x1A40),
>>> tole(0x1E00), tole(0xDEC1), tole(0xDF81), tole(0x1F40), tole(0xDD01),
>>> tole(0x1DC0), tole(0x1C80), tole(0xDC41), tole(0x1400), tole(0xD4C1),
>>> tole(0xD581), tole(0x1540), tole(0xD701), tole(0x17C0), tole(0x1680),
>>> tole(0xD641), tole(0xD201), tole(0x12C0), tole(0x1380), tole(0xD341),
>>> tole(0x1100), tole(0xD1C1), tole(0xD081), tole(0x1040), tole(0xF001),
>>> tole(0x30C0), tole(0x3180), tole(0xF141), tole(0x3300), tole(0xF3C1),
>>> tole(0xF281), tole(0x3240), tole(0x3600), tole(0xF6C1), tole(0xF781),
>>> tole(0x3740), tole(0xF501), tole(0x35C0), tole(0x3480), tole(0xF441),
>>> tole(0x3C00), tole(0xFCC1), tole(0xFD81), tole(0x3D40), tole(0xFF01),
>>> tole(

Re: GCC porting tutorials

[Bernd Roesch]

Hello 

On 24.04.10, you wrote:


> I don't know of a tutorial, but I want to make sure that you are
> looking at the internal docs: http://gcc.gnu.org/onlinedocs/gccint/ .
> They include the information you need for a new port, though not
> organized as a tutorial.

I know only Porting GCC for Dunces from Hans Peter-Nillson May 21. 2000
Its here

ftp://ftp.axis.se/pub/users/hp/pgccfd/pgccfd-0.5.pdf

It help me to understand GCC better, but i think this is now outdate, because 
of lots internal
changes.
maybe here can somebody update it.

> 
> Ian
Regards

gcc source: how can access asmspec_tree in function push_parm_decl

[Bernd Roesch]

Hello 

in gcc/c-decl.c

I see in finish_decl 

"""
finish_decl (tree decl, tree init, tree asmspec_tree)
{


there is access possible to asmspec_tree.

but the func

push_parm_decl 

have no parameter asmspec_tree.

is there a way to get access to it, without many code changes, or below func
can use to a better place  ?

the amiga os target need that functions.does somebody can tell me a more
easy way to add this feature, so not so many gcc source must change when
make a amiga OS Port ?.  

here is a short testprog to see what need.it is the feature to tell what
variable must put in which register or what register must put in which
variable

long GfxBase;

void (*Old_Text)(long rp asm("a1"),
  long string asm("a0"),
 long count asm("d0"),
 long GfxBase asm("a6"));

 void New_Text(long rp __asm("a1"),
  long string __asm("a0"),
  long count __asm("d0"))

{
(*Old_Text)(rp, string, count,GfxBase);

}

But it is much more easy, when there is a way to get access to asmspec and
need not 1 additional parameter.

The current way is change many lines in c-parse.in (see below)

here is change that is need in c-decl.c
the changes are from 3.4.0 i find out, 

diff -rupN gcc-3.4.0/gcc/c-decl.c gcc-3.4.0-gg/gcc/c-decl.c
--- gcc-3.4.0/gcc/c-decl.c  Mon Mar 22 18:58:18 2004
+++ gcc-3.4.0-gg/gcc/c-decl.c   Tue Apr 27 11:12:30 2004
@@ -2943,7 +2943,7 @@ finish_decl (tree decl, tree init, tree 
and push that on the current scope.  */
 
 void
-push_parm_decl (tree parm)
+push_parm_decl (tree parm, tree asmspec)
 {
   tree decl;
 
@@ -2956,6 +2956,75 @@ push_parm_decl (tree parm)
 TREE_PURPOSE (TREE_PURPOSE (parm)),
 PARM, 0, NULL);
   decl_attributes (&decl, TREE_VALUE (parm), 0);
+
+  /* begin-GG-local: explicit register specification for parameters */
+  if (asmspec)
+#ifdef TARGET_AMIGAOS
+{
+  const char *regname=TREE_STRING_POINTER(asmspec);
+  int regnum;
+  if ((regnum=decode_reg_name(regname))>=0)
+   {
+ tree type=TREE_TYPE(decl);
+ if (HARD_REGNO_MODE_OK(regnum, TYPE_MODE(type)))
+   {
+ tree t, attrs;
+ /* Build tree for __attribute__ ((asm(regnum))). */
+#if 0
+ /* This doesn't work well because of a bug in
+attribute_list_contained(), which passes list of arguments to
+simple_cst_equal() instead of passing every argument
+separately. */
+ attrs=tree_cons(get_identifier("asm"), tree_cons(NULL_TREE,
+   build_int_2_wide(regnum, 0), NULL_TREE), NULL_TREE);
+#else
+ attrs=tree_cons(get_identifier("asm"),
+ build_int_2_wide(regnum, 0), NULL_TREE);
+#endif
+#if 0
+ /* build_type_attribute_variant() would seem to be more
+appropriate here. However, that function does not support
+attributes for parameters properly. It modifies
+TYPE_MAIN_VARIANT of a new type. As a result, comptypes()
+thinks that types of parameters in prototype and definition
+are different and issues error messages. See also comment
+below. */
+ type=build_type_attribute_variant(type, attrs);
+#else
+ /* First check whether such a type already exists - if yes, use
+that one. This is very important, since otherwise
+common_type() would think that it sees two different
+types and would try to merge them - this could result in
+warning messages. */
+ for (t=TYPE_MAIN_VARIANT(type); t; t=TYPE_NEXT_VARIANT(t))
+   if (comptypes(t, type, COMPARE_STRICT)==1
+   && attribute_list_equal(TYPE_ATTRIBUTES(t), attrs))
+ break;
+ if (t)
+   type=t;
+ else
+   {
+ /* Create a new variant, with differing attributes.
+(Hack! Type with differing attributes should no longer be
+a variant of its main type. See comment above for
+explanation why this was necessary). */
+ type=build_type_copy(type);
+ TYPE_ATTRIBUTES(type)=attrs;
+   }
+#endif
+ TREE_TYPE(decl)=type;
+   }
+ else
+   error ("%Jregister specified for '%D' isn't suitable for data type",
+  decl, decl);
+   }
+  else
+   error ("invalid register name `%s'", regname);
+}
+#else /* !TARGET_AMIGAOS */
+error("explicit register specification for parameters is not supported
for this target");
+#endif /* !TARGET_AMIGAOS */
+  /* end-GG-local */
 
   decl = pushdecl (decl); 





..

diff -rupN gcc-3.4.0/gcc/c-parse.in gcc-3.4.0-gg/gcc/c-parse.in
--- gcc-3.4.0/gcc/c-parse.inSun Feb  8 21:56:44 2004
+++ gcc-3.4.0-gg/gcc/c-parse.in Tue Apr 27 11:12:30 2004
@@ -29,7 +29,7 @@ Software Foundation, 59 Temple Place - S
written by AT&T, but I have never seen it.  */
 
 @@ifc
-%expect 10 /* shift/reduce conflicts, and no reduce/reduce conflicts.  */
+%expect 11 /* shift/reduce conflicts, and no reduce/reduce conflicts.  */
 @@end_ifc
 

gcc source: how can access asmspec_tree in function push_parm_decl

[Bernd Roesch]

Hello 

Is this best List to get help for  GCC coding problems ?

in gcc/c-decl.c

I see in fnction finish_decl 

"""
finish_decl (tree decl, tree init, tree asmspec_tree)
{


there is access possible to asmspec_tree.

but the func

push_parm_decl 

have no parameter asmspec_tree.

is there a way to get access to it, without many code changes, or below func
can use in a better place  ?

the amigaos target need that functions.
does somebody can tell me a more
easy way to add this feature, so not so many gcc source must change when
make a amiga OS Port ?.  

here is a short testprog to see what need.it is the feature to tell what
variable must put in which register or what register must put in which
variable

long GfxBase;

void (*Old_Text)(long rp asm("a1"),
  long string asm("a0"),
 long count asm("d0"),
 long GfxBase asm("a6"));

 void New_Text(long rp __asm("a1"),
  long string __asm("a0"),
  long count __asm("d0"))

{
(*Old_Text)(rp, string, count,GfxBase);

}

But it is much more easy, when there is a way to get access to asmspec and
need not 1 additional parameter.

The current way is change many lines in c-parse.in (see below)

here is change that is need in c-decl.c
the changes are from 3.4.0 i find out, 

diff -rupN gcc-3.4.0/gcc/c-decl.c gcc-3.4.0-gg/gcc/c-decl.c
--- gcc-3.4.0/gcc/c-decl.c  Mon Mar 22 18:58:18 2004
+++ gcc-3.4.0-gg/gcc/c-decl.c   Tue Apr 27 11:12:30 2004
@@ -2943,7 +2943,7 @@ finish_decl (tree decl, tree init, tree 
and push that on the current scope.  */
 
 void
-push_parm_decl (tree parm)
+push_parm_decl (tree parm, tree asmspec)
 {
   tree decl;
 
@@ -2956,6 +2956,75 @@ push_parm_decl (tree parm)
 TREE_PURPOSE (TREE_PURPOSE (parm)),
 PARM, 0, NULL);
   decl_attributes (&decl, TREE_VALUE (parm), 0);
+
+  /* begin-GG-local: explicit register specification for parameters */
+  if (asmspec)
+#ifdef TARGET_AMIGAOS
+{
+  const char *regname=TREE_STRING_POINTER(asmspec);
+  int regnum;
+  if ((regnum=decode_reg_name(regname))>=0)
+   {
+ tree type=TREE_TYPE(decl);
+ if (HARD_REGNO_MODE_OK(regnum, TYPE_MODE(type)))
+   {
+ tree t, attrs;
+ /* Build tree for __attribute__ ((asm(regnum))). */
+#if 0
+ /* This doesn't work well because of a bug in
+attribute_list_contained(), which passes list of arguments to
+simple_cst_equal() instead of passing every argument
+separately. */
+ attrs=tree_cons(get_identifier("asm"), tree_cons(NULL_TREE,
+   build_int_2_wide(regnum, 0), NULL_TREE), NULL_TREE);
+#else
+ attrs=tree_cons(get_identifier("asm"),
+ build_int_2_wide(regnum, 0), NULL_TREE);
+#endif
+#if 0
+ /* build_type_attribute_variant() would seem to be more
+appropriate here. However, that function does not support
+attributes for parameters properly. It modifies
+TYPE_MAIN_VARIANT of a new type. As a result, comptypes()
+thinks that types of parameters in prototype and definition
+are different and issues error messages. See also comment
+below. */
+ type=build_type_attribute_variant(type, attrs);
+#else
+ /* First check whether such a type already exists - if yes, use
+that one. This is very important, since otherwise
+common_type() would think that it sees two different
+types and would try to merge them - this could result in
+warning messages. */
+ for (t=TYPE_MAIN_VARIANT(type); t; t=TYPE_NEXT_VARIANT(t))
+   if (comptypes(t, type, COMPARE_STRICT)==1
+   && attribute_list_equal(TYPE_ATTRIBUTES(t), attrs))
+ break;
+ if (t)
+   type=t;
+ else
+   {
+ /* Create a new variant, with differing attributes.
+(Hack! Type with differing attributes should no longer be
+a variant of its main type. See comment above for
+explanation why this was necessary). */
+ type=build_type_copy(type);
+ TYPE_ATTRIBUTES(type)=attrs;
+   }
+#endif
+ TREE_TYPE(decl)=type;
+   }
+ else
+   error ("%Jregister specified for '%D' isn't suitable for data type",
+  decl, decl);
+   }
+  else
+   error ("invalid register name `%s'", regname);
+}
+#else /* !TARGET_AMIGAOS */
+error("explicit register specification for parameters is not supported
for this target");
+#endif /* !TARGET_AMIGAOS */
+  /* end-GG-local */
 
   decl = pushdecl (decl); 





..

diff -rupN gcc-3.4.0/gcc/c-parse.in gcc-3.4.0-gg/gcc/c-parse.in
--- gcc-3.4.0/gcc/c-parse.inSun Feb  8 21:56:44 2004
+++ gcc-3.4.0-gg/gcc/c-parse.in Tue Apr 27 11:12:30 2004
@@ -29,7 +29,7 @@ Software Foundation, 59 Temple Place - S
written by AT&T, but I have never seen it.  */
 
 @@ifc
-%expect 10 /* shift/reduce conflicts, and no reduce/reduce conflicts.  */
+%expect 11 /* shift/r

Re: gcc source: how can access asmspec_tree in function push_parm_decl

[Bernd Roesch]

Hello Ian

On 03.10.08, you wrote:


>> but the func
>> 
>> push_parm_decl 
>> 
>> have no parameter asmspec_tree.
> 
> It shouldn't need one.
> 
> I'm not sure what the semantics of this should be.  Are you trying to
> change the calling convention for a function?  Should it change what
> callers of the function do?

amigaos need Explicit register specification.see below the docu.

it seem other targets need this feature not, i dont know how this on other
OS work when they have a register ABI to OS functions.
 
Dont understand me wrong, i dont want that this feature is in gcc(i think if
it is not in, other developers need it not), i only want ask, if there is
on newest gcc a more easy way to add this feature, so i must not merge so
much in gcc files in.

i can build a workable gcc4.4.0 for amigaos but of course not usefull
because this feature is often need.

And here is what docu say to the amigaos extension.


[EMAIL PROTECTED] Explicit register specification, Case sensitive CPP, 
Miscellaneous,
Miscellaneous

+In certain situations, like writing callback hooks, ``patchers'',
+standard shared libraries, etc., functions have to receive arguments
+in particular registers.

+To overcome this problem in the AmigaOS port of @samp{GCC}, explicit
+register specification has been extended to be available for function
+arguments, as well:
+
[EMAIL PROTECTED]
+void myhook(struct Hook* hook __asm("a0"), APTR object __asm("a2"),
+APTR message __asm("a1"))
[EMAIL PROTECTED]
+   ...
[EMAIL PROTECTED]
[EMAIL PROTECTED] example
+
[EMAIL PROTECTED]
[EMAIL PROTECTED]: This feature is currently not available in @samp{G++}.
+
+Only the @samp{ANSI}-style declarations (prototypes) are supported.
+
+Registers have to be specified both in function declarations
+(prototypes) and definitions (function code).
[EMAIL PROTECTED] quotation
+
+This feature was first made available in the @samp{GCC} 2.7.2.1,
[EMAIL PROTECTED] Gadgets} snapshot @samp{961012}. 


on old amigaos code, i get gcc workung with that header file and replace
some gcc functions.here i can code in seperate file.

Note:

below code contain much more than really need, amiga os target have regparm
option, to transfer arguments not in stack.but this is only a theoretical
speed feature i dont need, becaue inline func and optimizer work good on
GCC above gcc2.9

Only the feature Explicit register specification i like to add if it is
possible.

maybe this feature can too code in seperate file ?

here is in short what gcc functions are remap to  a seperate file called
amigaos.c 

#undef INIT_CUMULATIVE_ARGS
#define INIT_CUMULATIVE_ARGS(CUM, FNTYPE, LIBNAME, INDIRECT, N_NAMED_ARGS) \
  (amigaos_init_cumulative_args(&(CUM), (FNTYPE)))

/* Update the data in CUM to advance over an argument
   of mode MODE and data type TYPE.
   (TYPE is null for libcalls where that information may not be available.) 
*/

#undef FUNCTION_ARG_ADVANCE
#define FUNCTION_ARG_ADVANCE(CUM, MODE, TYPE, NAMED)\
  (amigaos_function_arg_advance (&(CUM)))

/* A C expression that controls whether a function argument is passed
   in a register, and which register. */

#undef FUNCTION_ARG
#define FUNCTION_ARG(CUM, MODE, TYPE, NAMED) \
  (amigaos_function_arg (&(CUM), (MODE), (TYPE)))
#endif //REGPARMS_68K
/* end-GG-local */

/* Stack checking and automatic extension support.  */

#define PROLOGUE_BEGIN_HOOK(STREAM, FSIZE)  \
  (amigaos_prologue_begin_hook ((STREAM), (FSIZE)))

#define HAVE_ALTERNATE_FRAME_SETUP_F(FSIZE) TARGET_STACKEXTEND

#define ALTERNATE_FRAME_SETUP_F(STREAM, FSIZE)  \
  (amigaos_alternate_frame_setup_f ((STREAM), (FSIZE)))

#define HAVE_ALTERNATE_FRAME_SETUP(FSIZE) TARGET_STACKEXTEND

#define ALTERNATE_FRAME_SETUP(STREAM, FSIZE)\
  (amigaos_alternate_frame_setup ((STREAM), (FSIZE)))

#define HAVE_ALTERNATE_FRAME_DESTR_F(FSIZE) \
  (TARGET_STACKEXTEND && current_function_calls_alloca)

#define ALTERNATE_FRAME_DESTR_F(STREAM, FSIZE)  \
  (asm_fprintf ((STREAM), "\tjra %U__unlk_a5_rts\n"))

#define HAVE_ALTERNATE_RETURN   \
  (TARGET_STACKEXTEND && frame_pointer_needed &&\
   current_function_calls_alloca)

#define ALTERNATE_RETURN(STREAM)

#define HAVE_restore_stack_nonlocal TARGET_STACKEXTEND
#define gen_restore_stack_nonlocal gen_stack_cleanup_call

#define HAVE_restore_stack_function TARGET_STACKEXTEND
#define gen_restore_stack_function gen_stack_cleanup_call

#define HAVE_restore_stack_block TARGET_STACKEXTEND
#define gen_restore_stack_block gen_stack_cleanup_call

#undef TARGET_ALTERNATE_ALLOCATE_STACK
#define TARGET_ALTERNATE_ALLOCATE_STACK 1

#define ALTERNATE_ALLOCATE_STACK(OPERANDS)  \
do  \
  { \
amigaos_alternate_allocate_stack (OPERANDS);\
DONE;   \
  } \
while (0)

/* begin-GG-local: dynamic lib

"__throw_logic_error" abort, but print no error message out

[Bernd Roesch]

Hello

the file in bits/basic_string.tcc call it.

template
template 
  _CharT*
  basic_string<_CharT, _Traits, _Alloc>::
  _S_construct(_InIterator __beg, _InIterator __end, const _Alloc& __a, 
  forward_iterator_tag)
  {
#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
if (__beg == __end && __a == _Alloc())
  return _S_empty_rep()._M_refdata();
#endif  // NB: Not required, but considered best practice.
if (__builtin_expect(__is_null_pointer(__beg) && __beg != __end, 0))
  __throw_logic_error(__N("basic_string::_S_construct NULL not valid"));



But in libstdc++v3/src/functexcept.cc 

 void 
__throw_logic_error(const char*)
  { std::abort(); } 

this call abort and there is no string print out, because abort get no
Parameter as far i see.

How can this work ? 

When i add testcode  

std::__throw_logic_error("error text\n");

then also text is print out but program is quit

I have a gcc4.3.2 68k amigaos build, maybe problem is here, but i dont
understand how this can work with the current source and what i must change
in the build, without change in gcc core Files.

Please help

bye Bernd

"__throw_logic_error" abort, but print no error message out

[Bernd Roesch]

Hello

the file in bits/basic_string.tcc call it.

template
template 
  _CharT*
  basic_string<_CharT, _Traits, _Alloc>::
  _S_construct(_InIterator __beg, _InIterator __end, const _Alloc& __a, 
  forward_iterator_tag)
  {
#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
if (__beg == __end && __a == _Alloc())
  return _S_empty_rep()._M_refdata();
#endif  // NB: Not required, but considered best practice.
if (__builtin_expect(__is_null_pointer(__beg) && __beg != __end, 0))
  __throw_logic_error(__N("basic_string::_S_construct NULL not valid"));
  <---



But in libstdc++v3/src/functexcept.cc 

 void 
__throw_logic_error(const char*)
  { std::abort(); } 

this call abort and there is no string print out, because abort get no
Parameter as far i see.

How can this work ? 

When i add testcode  

std::__throw_logic_error("error text\n");

then also NO text is print out but program is quit

I have a gcc4.3.2 68k amigaos build, maybe problem is here, but i dont
understand how this can work with the current source and what i must change
in the build, without change in gcc core Files.

Please help

bye Bernd

"__throw_logic_error" abort, but print no error message out

[Bernd Roesch]

Hello

the file in bits/basic_string.tcc call it.

template
template 
  _CharT*
  basic_string<_CharT, _Traits, _Alloc>::
  _S_construct(_InIterator __beg, _InIterator __end, const _Alloc& __a, 
  forward_iterator_tag)
  {
#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
if (__beg == __end && __a == _Alloc())
  return _S_empty_rep()._M_refdata();
#endif  // NB: Not required, but considered best practice.
if (__builtin_expect(__is_null_pointer(__beg) && __beg != __end, 0))
  __throw_logic_error(__N("basic_string::_S_construct NULL not valid"));
  <---



But in libstdc++v3/src/functexcept.cc 

 void 
__throw_logic_error(const char*)
  { std::abort(); } 

this call abort and there is no string print out, because abort get no
Parameter as far i see.

How can this work ? 

When i add testcode  

std::__throw_logic_error("error text\n");

then also NO text is print out but program is quit

I have a gcc4.3.2 68k amigaos build, maybe problem is here, but i dont
understand how this can work with the current source and what i must change
in the build, without change in gcc core Files.

Please help

bye Bernd

Re: " throw logic error" abort, but print no error message out

[Bernd Roesch]

Hello Jonathan

On 14.11.08, you wrote:

>If exceptions are enabled
> __throw_logic_error will throw std::logic_error, otherwise it will
> call abort().

On the amigaos compiler is sjlj enabled, i see in asm debugger after
single
stepping long it call std::logic_error.but this func do nothing print.

so i simplyfy the testprogram and see std::logic_error("test\n"); does not
output anything.

I test this too on cygwin gcc 3.4 x86 compiler(on amigaos i use 4.3.2
compiler and the attached libstdc++).Its the same output(cout and assert
work ok) but std::logic_error not.

i look to find in sourcecode the place where logic_error do any action and
print out text, but i dont find a print command.
maybe you can tell me the place where logic_error do action to print, so i
can set a breakpoint on that
place and singlestep to see whats go wrong.


---the testprog --


#include 
#include 

int main(int argc, char *argv[])
{

 std::cout<<"Hallo World\n";
 std::logic_error("test\n");
assert(0);

}  



 

If so assert does not work when 



> 2008/11/12 Bernd Roesch:
>> 
>> But in libstdc++v3/src/functexcept.cc
>> 
>>  void
>> __throw_logic_error(const char*)
>>  { std::abort(); }
>> 
>> this call abort and there is no string print out, because abort get no
>> Parameter as far i see.
>> 
>> How can this work ?
> 
> It works by calling abort(), as intended.
> 
> If you take another look in functexcept.cc you'll see that when
> __EXCEPTIONS is defined the following definition is used:
> 
>  void
>  __throw_logic_error(const char* __s)
>  { throw logic_error(_(__s)); }
> 
> This allows the library to call __throw_logic_error without caring
> whether the target supports exceptions, or whether they have been
> disabled with -fno-exceptions.  If exceptions are enabled
> __throw_logic_error will throw std::logic_error, otherwise it will
> call abort().
> 
> It seems that the 68k amigaos port does not support exceptions, or
> your GCC was configured without support for exceptions.
> 
> Hope that helps,
> 
> Jonathan
Regards

Re: GCC 4.4.0 Status Report (2008-11-17)

[Bernd Roesch]

Hello 

On 17.11.08, you wrote:

> Hi,
> 
> I'd like to pointer that  the new __optimize__  attribute doesn't work
> correctly:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565
> 
> Will it be fixed in 4.4?

68k amigaos target on 4.4 give no error, when type this to try to switch
optimizer off. 

void foo (void) __attribute__
((__optimize__(0)));

but the optimizer is not switch off.

default option is -O3.

I have a file (ws-key.cpp) from openredalert(big endian Version) and
generate wrong code on GCC 4.4.0 31.10.2008 when use -O2 or -O3 in
commandline.(gcc4.3.2 work with -O3) 

I want search the function that produce wrong code and when the optimizer
can switch on or off per function help a lot.
Or do i something wrong ?

 is there a working example of that func ?

> 
> H.J.
> ---
> On Mon, Nov 17, 2008 at 2:15 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
>> Status
>> ==
>> 
>> We are now in regression and documentation fixes only mode.
>> 
>> When the number of P1 bugs drops to zero and the number of
>> P1, P2 and P3 bugs reaches 100, we'll branch 4.4.0 and open
>> 4.5 stage 1.
>> 
>> The old register allocator hasn't been removed yet, but will be before
>> branching.  There are still several targets that haven't been converted
>> to IRA; unless they are converted soon, they will be dropped.  The
>> unconverted targets are:
>> 
>> arc
>> m32c
>> m68hc11
>> mmix
>> pdp11
>> score
>> vax
>> 
>> Quality Data
>> 
>> 
>> Priority  # Change from Last Report
>> --- ---
>> P1   13 -  4
>> P2  114 - 27
>> P33 +- 0
>> --- ---
>> Total   130 - 31
>> 
>> We've made a good progress on fixing P1 and especially P2 bugs, but
>> File /tmp/X not changed so no update needed
>> [EMAIL PROTECTED] gcc]$ cat /tmp/X
>> "Joseph S. Myers" <[EMAIL PROTECTED]>
>> GCC 4.4.0 Status Report (2008-11-17)
>> 
>> Status
>> ==
>> 
>> We are now in regression and documentation fixes only mode.
>> 
>> When the number of P1 bugs drops to zero and the number of
>> P1, P2 and P3 bugs reaches 100, we'll branch 4.4.0 and open
>> 4.5 stage 1.
>> 
>> The old register allocator hasn't been removed yet, but will be before
>> branching.  There are still several targets that haven't been converted
>> to IRA, so unless they are converted soon, they will be dropped.  The
>> unconverted targets are:
>> 
>> arc
>> m32c
>> m68hc11
>> mmix
>> pdp11
>> score
>> vax
>> 
>> Quality Data
>> 
>> 
>> Priority  # Change from Last Report
>> --- ---
>> P1   13 -  4
>> P2  114 - 27
>> P33 +- 0
>> --- ---
>> Total   130 - 31
>> 
>> We've made a good progress on fixing P1 and especially P2 bugs, but
>> still have many to fix before we reach the criteria for branching
>> 4.4.0.  Several of the P2 and P1 bugs have patches posted, but
>> not reviewed yet.
>> 
>> All but one P1s are regressions from 4.3 and there are 25 P2 regressions
>> from 4.3, especially those should be given attention.
>> 
>> Previous Report
>> ===
>> 
>> http://gcc.gnu.org/ml/gcc/2008-11/msg7.html
>> 
>> The next report for 4.4.0 will be sent by Joseph.
>> 
Regards

Re: This is a Cygwin failure yeah?

[Bernd Roesch]

Hello Andy

On 07.01.09, you wrote:


> Cygwin one:
> 
> When it gets to stage 3 (after many hours) I get the following printed
> out to the console (not redirected) -
> 
> 217 [unknown (0x1B0)] conftest 3408 _cygtls::handle_exceptions: Error
> while dumping state (probably corrupted stack)
> 

I think its a problem that cygwin cant use more stack.and in some case there
get a stack overflow.but it seem not possible to increase the stack for the
cygwin bash(i read many about that in inet but no solution see).only
solution seem to build the build gcc with the stack option that the fvork
for start cc1 use more stack than the bash process.

maybe on GGC code can add that it use always 2 MB stack 
cygwin bash only have 400 kb of stack.Unix commad for stack increase(forget
the name) dont work

the exception handler of cygwin seem too broken, because a abort give always
this message and no abort text.

I btw get such crashes from binutil 2.14 assembler and can reproduce them
when i forget on writing asm inline code a \n\ at end.

normaly the assembler give error messages, but i guess due too much stack of
assembler error writing, gcc crash because of too few stack.

strange, compiler 2.95 and older binutil work without \n\ at end

> By the looks of this I wold say that some part of the Cygwin runtime
> has failed. I've not seen this one in Cygwin at any other time than
> building GCC which leads me to assume (which is dangerous I realise)
> that there is an issue with my version and how GCC builds. Placing the
> "blame" on the Cygwin runtime.
> 
> Is this a correct assumption can anyone tell me? [obviously if it is a
> Cygwin issue then I'll track it down a bit more before posting on
> their forums]
> 
> GCC Build One:
> 
> Again stage3 part of build, and this is what actually stops the build
> the above issue doesn't seem to (I think it happens in stage 2), I get
> the following:
> 
> 
> 
> /home/andy/live-gcc/my_gcc/./gcc/xgcc
> -B/home/andy/live-gcc/my_gcc/./gcc/ -B/usr/local/i686-pc-cygwin/bin/
> -B/usr/local/i686-pc-cygwin/lib/ -isystem
> /usr/local/i686-pc-cygwin/include -isystem
> /usr/local/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -g -O2-I.
> -I../../../gcc/libiberty/../include  -W -Wall -Wwrite-strings
> -Wc++-compat -Wstrict-prototypes -pedantic
> ../../../gcc/libiberty/strsignal.c -o pic/strsignal.o; \
>   else true; fi
> /home/andy/live-gcc/my_gcc/./gcc/xgcc -B/home/andy/live-gcc/my_gcc/./gcc/
> -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem
> /usr/local/i686-pc-cygwin/include -isystem
> /usr/local/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -g -O2 -I.
> -I../../../gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
> -Wstrict-prototypes -pedantic ../../../gcc/libiberty/strsignal.c -o
> strsignal.o ../../../gcc/libiberty/strsignal.c:408: error: conflicting
> types for 'strsignal' /usr/include/string.h:78: note: previous declaration
> of 'strsignal' was here make[2]: *** [strsignal.o] Error 1 make[2]:
> Leaving directory `/home/andy/live-gcc/my_gcc/i686-pc-cygwin/libiberty'
> make[1]: *** [all-target-libiberty] Error 2 make[1]: Leaving directory
> `/home/andy/live-gcc/my_gcc' make: *** [all] Error 2
> 
> Which seems like a possible setup/build issue. If this is so anyone
> seen it before and any helpful hints on how to get rid of it?
> 
> Thanks.
> 
> Andy
Regards

Re: This is a Cygwin failure yeah?

[Bernd Roesch]

Hello Andy

On 07.01.09, you wrote:


> Cygwin one:
> 
> When it gets to stage 3 (after many hours) I get the following printed
> out to the console (not redirected) -
> 
> 217 [unknown (0x1B0)] conftest 3408 _cygtls::handle_exceptions: Error
> while dumping state (probably corrupted stack)
> 

I think its a problem that cygwin cant use more stack.and in some case there
get a stack overflow.but it seem not possible to increase the stack for the
cygwin bash(i read many about that in inet but no solution see).only
solution seem to build the build gcc with the stack option that the fvork
for start cc1 use more stack than the bash process.

maybe on GGC code can add that it use always 2 MB stack 
cygwin bash only have 400 kb of stack.Unix commad for stack increase(forget
the name) dont work

the exception handler of cygwin seem too broken, because a abort give always
this message and no abort text.

I btw get such crashes from binutil 2.14 assembler and can reproduce them
when i forget on writing asm inline code a \n\ at end.

normaly the assembler give error messages, but i guess due too much stack of
assembler error writing, gcc crash because of too few stack.

strange, compiler 2.95 and older binutil work without \n\ at end

> By the looks of this I wold say that some part of the Cygwin runtime
> has failed. I've not seen this one in Cygwin at any other time than
> building GCC which leads me to assume (which is dangerous I realise)
> that there is an issue with my version and how GCC builds. Placing the
> "blame" on the Cygwin runtime.
> 
> Is this a correct assumption can anyone tell me? [obviously if it is a
> Cygwin issue then I'll track it down a bit more before posting on
> their forums]
> 
> GCC Build One:
> 
> Again stage3 part of build, and this is what actually stops the build
> the above issue doesn't seem to (I think it happens in stage 2), I get
> the following:
> 
> 
> 
> /home/andy/live-gcc/my_gcc/./gcc/xgcc
> -B/home/andy/live-gcc/my_gcc/./gcc/ -B/usr/local/i686-pc-cygwin/bin/
> -B/usr/local/i686-pc-cygwin/lib/ -isystem
> /usr/local/i686-pc-cygwin/include -isystem
> /usr/local/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -g -O2-I.
> -I../../../gcc/libiberty/../include  -W -Wall -Wwrite-strings
> -Wc++-compat -Wstrict-prototypes -pedantic
> ../../../gcc/libiberty/strsignal.c -o pic/strsignal.o; \
>   else true; fi
> /home/andy/live-gcc/my_gcc/./gcc/xgcc -B/home/andy/live-gcc/my_gcc/./gcc/
> -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem
> /usr/local/i686-pc-cygwin/include -isystem
> /usr/local/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -g -O2 -I.
> -I../../../gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
> -Wstrict-prototypes -pedantic ../../../gcc/libiberty/strsignal.c -o
> strsignal.o ../../../gcc/libiberty/strsignal.c:408: error: conflicting
> types for 'strsignal' /usr/include/string.h:78: note: previous declaration
> of 'strsignal' was here make[2]: *** [strsignal.o] Error 1 make[2]:
> Leaving directory `/home/andy/live-gcc/my_gcc/i686-pc-cygwin/libiberty'
> make[1]: *** [all-target-libiberty] Error 2 make[1]: Leaving directory
> `/home/andy/live-gcc/my_gcc' make: *** [all] Error 2
> 
> Which seems like a possible setup/build issue. If this is so anyone
> seen it before and any helpful hints on how to get rid of it?
> 
> Thanks.
> 
> Andy
Regards

Re: This is a Cygwin failure yeah?

[Bernd Roesch]

Hello Dave

On 09.01.09, you wrote:

> 
>  You can't assume that actually was a stack overflow just because the
> stack ended up corrupted.
> 

yes thats the problem, because a assert give this message too.maybe the
program do assert.
maybe theres a way that cygwin print out the assert text earlier when call
assert
?
and cygwin show on this message how many stack is currently value =
stackpointer -stackbase

this maybe help to see better whats the problem.

> 
>> Unix commad for stack increase(forget the name)
> 
>  'ulimit'

ah yes i see, I update from time and time and now its more.my bash show this
now.Maybe Andy can do this test what his bash show.

$ ulimit -a
core file size  (blocks, -c) unlimited
data seg size   (kbytes, -d) unlimited
file size   (blocks, -f) unlimited
open files  (-n) 256
pipe size(512 bytes, -p) 8
stack size  (kbytes, -s) 2033
cpu time   (seconds, -t) unlimited
max user processes  (-u) 63
virtual memory  (kbytes, -v) 2097152


> 
>  It does often fail. It can't unwind the stack through Windows API
> functions where the system DLL was compiled with FPO. (It may have bugs,
> of course, as well.)

I do test program some time ago, I try assert and throw_logic_error it get
always the known error and print no text on cygwin.

I try the cygwin gcc3 and 4 from installer.

> 
>> I btw get such crashes from binutil 2.14 assembler and can reproduce them
>> when i forget on writing asm inline code a \n\ at end.
> 
>  That's a very old version, and there used to be a lot of bugs handling
> corrupt or over-long lines; it was probably trying to read the whole thing
> into a buffer that was only really big enough for one line.
> 
>> normaly the assembler give error messages, but i guess due too much stack
>> of assembler error writing, gcc crash because of too few stack.
>> 
>> strange, compiler 2.95 and older binutil work without \n\ at end
> 
>  ? ISTR there have been minor tweaks down the years to the behaviour of
> the preprocessor when it comes to continued strings across line-ends.
> Might be related.

I see on gcc programs (gcc source) always have a /n/ at end of line.seem the
syntax is change.I find the old syntax better, because i need not type so
much chars

when i see programs that are compile on gcc 2.95 well, these are not in and
it seem work with older binutil.

for example on older compiler this work

 asm (" 
movel a5,a0 
lea   Lget_sr,a5 
movel 4:w,a6
jsr   a6@(-0x1e) 
movel a1,%0 
bra   Lskip 
Lget_sr: 
movew sp@,a1| get sr register from the calling function \n\
rte 
Lskip: 
movel a0,a5 
" : "=g" (sr) : : "a0", "a1", "a6");
} 

compiler > = 3.4.0 and above crashes or print out large error messages.
Now i do the test, no cygwin crash only assembler errors.maybe the larger
stack help...

../../../kern_sig.c:783: error: missing terminating " character
../../../kern_sig.c:784: error: `movel' undeclared (first use in this
function)
../../../kern_sig.c:784: error: (Each undeclared identifier is reported only
onc
e
../../../kern_sig.c:784: error: for each function it appears in.)
../../../kern_sig.c:784: error: syntax error before "a5"
../../../kern_sig.c:787: error: stray '@' in program
../../../kern_sig.c:791: error: stray '@' in program
../../../kern_sig.c:795: error: missing terminating " character

only this version below compile correct.

 asm volatile (" \n\
movel a5,a0 \n\
lea   Lget_sr,a5 \n\
movel 4:w,a6 \n\
jsr   a6@(-0x1e) \n\
movel a1,%0 \n\
bra   Lskip \n\
Lget_sr: \n\
movew sp@,a1| get sr register from the calling function \n\
rte \n\
Lskip: \n\
movel a0,a5 \n\
" : "=g" (sr) : : "a0", "a1", "a6");

> 
>cheers,
>  DaveK
Regards

lrint lrintf problems

[Bernd Roesch]

Hi, 

I see in compiler source there is in builtin.c lrint lrintf.so the gcc need
no extern linker lib when i understand right. 

But get linker error when use them.I test compiler 3.4.0 4.3.2 and 4.4.0

I also link with libgcc.but does not help

also my includes-fixed/math.h

contain a declaration but it is long int.
extern long int lrint _PARAMS((double)); 

This mean 64 bit int ?

But i use 32 bit 68k compiler and as far i see lrint return a long in docu.

only solution i find short is add in library.

 long lrintf(float x)
{
  return (long)x;
}

But when do this code, then there should be used current rounding.68k for
example support a simple fmove.l fp0,d0 and use current rounding to convert
from float.

But gcc (test with 4.3.2)output this code in -m68020 -m68881 -03.

FMOVE.S #+1.2344999E+4,FP0 
FADD.L  D4,FP0 
FINTRZ.X FP0   
FMOVE.L FP0,-(A7)  

But i think there is no fintrz need and this code do the same job and use
the correct rounding setting.

FMOVE.S #+1.2344999E+4,FP0 
FADD.L  D4,FP0 
FMOVE.L FP0,-(A7)  

Or i am wrong ?.Or is "return (long)x;" specified to always round to zero ?

How can i then implement lrint func without asm Code ? 

please help

Handling of extern inline in c99 mode

[Bernd Roesch]

Hi, 

I find this mails here

http://gcc.gnu.org/ml/gcc/2006-11/msg6.html

But i find no answer how i can do same as extern inline and get no problems
in C99 mode and other modes

I use for longer functions this code

extern __inline long func()
{
}

but when a makefile set -std=c99 then get linker error, multiple definition.

what commands gcc have and do same as extern __inline  and this way do not
clash with C99 ?

I can then change the header files.

i know static inline work, but this increase code size a lot.

Bye

cmath call builtin sqrtf but many platforms seem miss that(was Re: lrint lrintf problems )

[Bernd Roesch]

Hello Richard

On 06.03.09, you wrote:

ah thanks for info, i understand now too wy sqrtf, fmod (work in C programs)
get linker error on C++ programs but sqrt and some other work on platform
68k.
in c++/4.3.2/cmath include 

is this code.

using ::sqrt;

  inline float
  sqrt(float __x)
  { return __builtin_sqrtf(__x); }
 
But .md file of many architetures contain no entry for this.I see only i386,
rs6000, ia64, sh contain code for this.(I search for sqrtf and list files
that contain this) 
the header files are build during GCC build, i change nothing.

Is there something wrong during compiler Build process ?

>> 
>> How can i then implement lrint func without asm Code ?
> 
> If the backend does not support inlining lrint then you need to link
> against a C99 math library (-lm).  You can add lrint
> patterns to m68k.md to provide inline expansions.
> 
> Richard.
> 
>> please help
>> 
>> 
Regards

Re: cmath call builtin sqrtf but many platforms seem miss that(was Re: lrint lrintf problems )

[Bernd Roesch]

Hello Gabriel

On 09.03.09, you wrote:

> The above sqrt() function is distinct from the C version, because
> it has a C++ linkage.  Consequently, I would expect that if
> __builtin_sqrtf() is not available, the compiler would emit a
> library call to the out-of-line C version.

But it dont work.

I have define in math.h this func.see my below
example source that show important parts.look a little ugly, but this is
done to avoid in -o3 the remove of some function calls.
real problem i see in libdirac

inline float sqrtf(float x)
{
 return sqrt(x);
}

...

int main(int argc, char** argv)
{

printf("%f\n",sqrtf((float)argc));// work
printf("%f\n",std::sqrt(static_cast(argc)));  // work not
printf("%f\n",std::sqrt(static_cast(argc))); // work

..

when i change c++/4.3.2/cmath to this code, then all work 


using ::sqrt;

  inline float
  sqrt(float __x)
-  { return __builtin_sqrtf(__x); }
+  { return sqrtf(__x); } 

.

now you can come to the idea and add it as link func, maybe then it work.

But then i get error at that line, but other lines work.

printf("%f\n",sqrtf((float)argc)); 

undefined reference to `sqrtf(float)'

You see there is the _ not in.normaly funcs that not find have a _ before

To get all work, it seem i need add the same function add in math.h and in
the linker
lib or change cmath file and remove all __builtin_ commands the architecture
not have.

> On Mon, Mar 9, 2009 at 2:42 AM, Bernd Roesch  wrote:
>> Hello Richard
>> 
>> On 06.03.09, you wrote:
>> 
>> ah thanks for info, i understand now too wy sqrtf, fmod (work in C
>> programs)
>> get linker error on C++ programs but sqrt and some other work on
>> platform
>> 68k.
>> in c++/4.3.2/cmath include
>> 
>> is this code.
>> 
>> using ::sqrt;
>> 
>>  inline float
>>  sqrt(float __x)
>>  { return __builtin_sqrtf(__x); }
>> 
>> But .md file of many architetures contain no entry for this.I see only
>> i386,
>> rs6000, ia64, sh contain code for this.(I search for sqrtf and list
>> files
>> that contain this)
>> the header files are build during GCC build, i change nothing.
>> 
>> Is there something wrong during compiler Build process ?
> 
> The above sqrt() function is distinct from the C version, because
> it has a C++ linkage.  Consequently, I would expect that if
> __builtin_sqrtf() is not available, the compiler would emit a
> library call to the out-of-line C version.
> 
> -- Gaby
Regards

Re: cmath call builtin sqrtf but many platforms seem miss that(was Re: lrint lrintf problems )

[Bernd Roesch]

Hello Richard

On 09.03.09, you wrote:

>> I believe one should convince the middle end to emit libcall
>> for __builtin_xxx when the target has no builtint support.
> 
> It of course does.

On what codeplace is the redefine do in GCC source ?

I see in my c++config.h file

this stand here

/* Define if the compiler/host combination has __builtin_sqrtf. */
/* #undef _GLIBCXX_HAVE___BUILTIN_SQRTF */ 

I find now a solution that work without change of cmath

when i add in math.h this line then it work.the function can too stand as
static inline in the math.h file.

#define __builtin_sqrtf sqrtf

> On Mon, Mar 9, 2009 at 3:59 PM, Gabriel Dos Reis 
> wrote:
>> On Mon, Mar 9, 2009 at 7:11 AM, Bernd Roesch  wrote:
>>> Hello Gabriel
>> [...]
>>> 
>>> You see there is the _ not in.normaly funcs that not find have a _
>>> before
>>> 
>>> To get all work, it seem i need add the same function add in math.h and
>>> in
>>> the linker
>>> lib or change cmath file and remove all __builtin_ commands the
>>> architecture
>>> not have.
>> 
>> I believe one should convince the middle end to emit libcall
>> for __builtin_xxx when the target has no builtint support.
> 
> It of course does.
> 
> Richard.
Regards

Re: cmath call builtin sqrtf but many platforms seem miss that(was Re: lrint lrintf problems )

[Bernd Roesch]

Hallo Gunther

Am 22.03.09 schriebst Du

> How about using the original C-library of your system together with its
> headers? After all the version you are currently using is an "alien" and

without changed headers old ompiler and libs do not work, because for C
there is no
sqrtf and other C99 funcs and many C++ programs get also many errors.

i see old libstdc++ contain sqrtf but get many other linker errors.

there is also a sqrtf not undef in cmath as many other functions are.
When i define sqrtf in math.h then the sqrtf func in libstdc++ is maybe not
add and this strange linker error come.but wy it work not correct when i
add sqrtf to libc i dont know.only solution below work.

only this funcs are undef.

// Get rid of those macros defined in  in lieu of real functions.
#undef abs
#undef div
#undef acos
#undef asin
#undef atan
#undef atan2
#undef ceil
#undef cos
#undef cosh
#undef exp
#undef fabs
#undef floor
#undef fmod
#undef frexp
#undef ldexp
#undef log
#undef log10
#undef modf
#undef pow
#undef sin
#undef sinh
#undef sqrt
#undef tan
#undef tanh 

> Bernd Roesch wrote:
>> I see in my c++config.h file
>> 
>> this stand here
>> 
>> /* Define if the compiler/host combination has __builtin_sqrtf. */
>> /* #undef _GLIBCXX_HAVE___BUILTIN_SQRTF */ 
>> 
>> I find now a solution that work without change of cmath
>> 
>> when i add in math.h this line then it work.the function can too stand as
>> static inline in the math.h file.
>> 
>> #define __builtin_sqrtf sqrtf
> 
> How about using the original C-library of your system together with its
> headers? After all the version you are currently using is an "alien" and
> doesn't fit for your system despite the fact that it was based on your
> systems C-library and its headers. Carefully merging changes back to the
> original version would be the better solution.
> 
> Gunther
> 
>>> On Mon, Mar 9, 2009 at 3:59 PM, Gabriel Dos Reis 
>>> wrote:
>>>> On Mon, Mar 9, 2009 at 7:11 AM, Bernd Roesch  wrote:
>>>>> Hello Gabriel
>>>> [...]
>>>>> You see there is the _ not in.normaly funcs that not find have a _
>>>>> before
>>>>> 
>>>>> To get all work, it seem i need add the same function add in math.h
>>>>> and
>>>>> in
>>>>> the linker
>>>>> lib or change cmath file and remove all __builtin_ commands the
>>>>> architecture
>>>>> not have.
>>>> I believe one should convince the middle end to emit libcall
>>>> for __builtin_xxx when the target has no builtint support.
>>> It of course does.
>>> 
>>> Richard.
>> Regards
> 
> 
> 
> 
mfg Bernd

Re: stdint.h type information needed

[Bernd Roesch]

Hello Joseph

On 01.04.09, you wrote:

I add this file some time ago to Amiga OS 68k target, and build compiler, in
config.log files during compiler build, it seem detect right, are there
still defines in config.gcc need and other defines ?

configure:3626: $? = 0
configure:3629: test -s conftest.o
configure:3632: $? = 0
configure:3643: result: yes
configure:3597: checking for stdint.h
configure:3613: m68k-amigaos-gcc -c   conftest.c >&5
configure:3619: $? = 0
configure:3623: test -z 
 || test ! -s conftest.err
configure:3626: $? = 0
configure:3629: test -s conftest.o
configure:3632: $? = 0
configure:3643: result: yes 

Also in libstdc++ defines it is detect right automatic.

/* Define to 1 if you have the  header file. */
#define _GLIBCXX_HAVE_STDINT_H 1

/* Define to 1 if you have the  header file. */
#define _GLIBCXX_HAVE_STDLIB_H 1 


> GCC now supports providing the header  (required by C99 of 
> freestanding implementations) and having information within the compiler 
> about the types used in this header.  For further discussion of this and 
> its benefits, see 
> .
> 
> Right now, the information is present in GCC for targets using glibc or
> uClibc, bare-metal and RTEMS targets (which are taken to use newlib's
> default stdint.h types) and Solaris targets. To get the full benefits of
> this support, the information needs adding for all OSes supported by GCC.
> This is information about all the types C99 specifies for , plus
> sig_atomic_t whose limits go in that header.
> 
> To add information for a target OS, put definitions such as those in
> glibc-stdint.h, newlib-stdint.h or sol2.h in a suitable target header, and
> set use_gcc_stdint in config.gcc. It should be set to "wrap" if the system
> has its own stdint.h header, or "provide" if it doesn't. (There might be
> special cases when some other arrangement is needed, but I expect those
> two generally to suffice.) Make sure the new c99-stdint-*.c tests pass; if
> they show up bugs in the system's stdint.h header (as wrapped by GCC with
> the "wrap" setting) then report those upstream and fix them in GCC with
> fixincludes.
> 
> If the system does not have stdint.h, then suitable types may be found in 
> one of the following places:
> 
> * A later OS version.
> 
> * inttypes.h (some systems have headers from C9x drafts that had only 
> inttypes.h and not stdint.h).
> 
> * Other headers such as sys/types.h, including possibly variant type names
> such as u_int32_t in those headers.
> 
> * As a last resort, for OSes that are no longer maintained or whose 
> maintainers have had no interest in defining those types for the OS, the 
> types may be invented for GCC.
> 
> At least the following OSes need the information added (for all supported 
> architectures):
> 
> * Darwin
> * FreeBSD
> * NetBSD
> * OpenBSD
> * VxWorks
> * alpha*-dec-osf[45]*
> * VMS
> * SymbianOS
> * WinCE
> * HP-UX
> * DJGPP
> * LynxOS
> * Netware
> * QNX
> * Cygwin
> * MinGW
> * Interix
> * IRIX
> * AIX
> * s390x-ibm-tpf*
> 
Regards

align of local char array seem not work.

[Bernd Roesch]

Hi, 

i see simular lines in a program.

char buf[256] __attribute__((aligned(16)));
   printf("%x\n",&buf[0]);

this short test program give no error or warning and do not align as
expect.i test with several 68k amigaos compilers (3.4.0 /4.3.2/4.4.0), and
i think this is no target problem.at least a syntax error should come.or is
there some define need in platform specific file ?

Bye

gcc 4.4.0 error at postreload.c:396

[Bernd Roesch]

Hi,

I search gcc ML and find this.

http://gcc.gnu.org/ml/gcc/2009-05/msg00413.html

but here i have source with no 64 bit CPU.
is the fix now in and should i test current gcc4.4 ?

I also like to know if there is possible to build a gcc with better error
messages ?
It show as error place last bracket of the function.

Get a report of GCC 4.4.0 internal compiler error.happen on the last
bracket of the function.see --> mark
he report that GCC 4.3.2 work ok with same source.

the source is in ffmpeg package and gcc4.4.0 (release)run on cygwin.
A preprocessed source i do not have, hope this can help and somebody can
tell me what problem can be or how get more precise info about problem.

Here is output:

$ make_68k_v4
/bin/ffmpeg8/version.sh "/bin/ffmpeg8" version.h
/usr/local/amiga/bin/m68k-amigaos-gcc-4.4.0.exe -V 4.4.0 
-DHAVE_AV_CONFIG_H -I.
-I"/bin/ffmpeg8" -mnobitfield -m68060 -std=c99  
-Wdeclaration-after-statement -W
disabled-optimization -fno-math-errno -D_ISOC99_SOURCE 
-D_POSIX_C_SOURCE=200112
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-common 
-fomit-frame-pointer -Wal
l -Wno-switch -Wpointer-arith -Wredundant-decls -Wcast-qual 
-Wwrite-strings -Wun
def -O3  -c -o libavcodec/mpegvideo.o libavcodec/mpegvideo.c
libavcodec/mpegvideo.c: In function 'init_rl':
libavcodec/mpegvideo.c:760: warning: pointer targets in assignment 
differ in sig
nedness
libavcodec/mpegvideo.c:765: warning: pointer targets in assignment 
differ in sig
nedness
libavcodec/mpegvideo.c: In function 'MPV_motion_lowres':
libavcodec/mpegvideo.c:1707: error: insn does not satisfy its constraints:
(insn 937 3765 3766 59 libavcodec/mpegvideo.c:1488 (set (reg:SI 0 d0 
[931])
(plus:SI (mem/f:SI (reg:SI 9 a1) [7 S4 A16])
(reg:SI 0 d0 [931]))) 131 {*addsi3_internal} (nil))
libavcodec/mpegvideo.c:1707: internal compiler error: in 
reload_cse_simplify_ope
rands, at postreload.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

GCC 4.3.2 don't have this error - compiles "mpegvideo.c" file without 
problems.

Regards

static inline void MPV_motion_lowres(MpegEncContext *s,
  uint8_t *dest_y, uint8_t *dest_cb, uint8_t
*dest_cr,
  int dir, uint8_t **ref_picture,
  h264_chroma_mc_func *pix_op)
{
int mx, my;
int mb_x, mb_y, i;
const int lowres= s->avctx->lowres;
const int block_s= 8>>lowres;

mb_x = s->mb_x;
mb_y = s->mb_y;

switch(s->mv_type) {
case MV_TYPE_16X16:
mpeg_motion_lowres(s, dest_y, dest_cb, dest_cr,
0, 0, 0,
ref_picture, pix_op,
s->mv[dir][0][0], s->mv[dir][0][1], 2*block_s);
break;
case MV_TYPE_8X8:
mx = 0;
my = 0;
for(i=0;i<4;i++) {
hpel_motion_lowres(s, dest_y + ((i & 1) + (i >> 1) *
s->linesize)*block_s,
ref_picture[0], 0, 0,
(2*mb_x + (i & 1))*block_s, (2*mb_y + (i
>>1))*block_s,
s->width, s->height, s->linesize,
s->h_edge_pos >> lowres, s->v_edge_pos >>
lowres,
block_s, block_s, pix_op,
s->mv[dir][i][0], s->mv[dir][i][1]);

mx += s->mv[dir][i][0];
my += s->mv[dir][i][1];
}

if(!CONFIG_GRAY || !(s->flags&CODEC_FLAG_GRAY))
chroma_4mv_motion_lowres(s, dest_cb, dest_cr, ref_picture,
pix_op, mx, my);
break;
case MV_TYPE_FIELD:
if (s->picture_structure == PICT_FRAME) {
/* top field */
mpeg_motion_lowres(s, dest_y, dest_cb, dest_cr,
1, 0, s->field_select[dir][0],
ref_picture, pix_op,
s->mv[dir][0][0], s->mv[dir][0][1], block_s);
/* bottom field */
mpeg_motion_lowres(s, dest_y, dest_cb, dest_cr,
1, 1, s->field_select[dir][1],
ref_picture, pix_op,
s->mv[dir][1][0], s->mv[dir][1][1], block_s);
} else {
if(s->picture_structure != s->field_select[dir][0] + 1 &&
s->pict_type != FF_B_TYPE && !s->first_field){
ref_picture= s->current_picture_ptr->data;
}

mpeg_motion_lowres(s, dest_y, dest_cb, dest_cr,
0, 0, s->field_select[dir][0],
ref_picture, pix_op,
s->mv[dir][0][0], s->mv[dir][0][1], 2*block_s);
}
break;
case MV_TYPE_16X8:
for(i=0; i<2; i++){
uint8_t ** ref2picture;

if(s->picture_structure == s->field_select[dir][i] + 1 ||
s->pict_type == FF_B_TYPE || s->first_field){
ref2picture= ref_picture;
}else{
ref2picture= s->current_pict

-funswitch-loops slowdown.is it possible to change settings in backend ?

[Bernd Roesch]

Hello 

The -funswitch-loops Option seem work on gcc 4.3.0 and above not good for
speed.Test on m68k gcc.

It generate much larger code(wma123) and code is slower in many case (try
out ffmpeg H264 decode)i get report from a Athlon 2600+ with single channel
ram
running amiga 68k emulator.

But on my System use a AMD64 3000+ and Dual Channel ram running amiga
emulator
-funswitch-loops cause only large files but no slowdown.

but i guess on a real 68k/coldfire CPU without 2. level cache,
-funswitch-loops is more
not optimal.
gcc 3.4.0 have too this option set on -O3 or i am wrong ?
and here the speed is better and code is smaller

Is there a way to tweak some values on backend for specific CPU so
-funswitch-loops works 3.4.0(maybe unroll not so much loops ?

for now best solution for speed (H264 decode work on the system with single
Channel ram same ot little faster as 3.4.0 build.) is let disable
-funswitch-loops disable as far i get speedvalue reports. 

here are some values that show too slowdown on compilers 4.2.4 and 4.3.0 but
on
X86

http://multimedia.cx/eggs/compiler-performance-profiling-with-ffmpeg/

Regards

GCC seem output error messages in UTF8.Dev-cpp cant show it.Can this change in target declaration ?

[Bernd Roesch]

Hi 

I compile the GCC4.5.0 on cygwin and when i use it in cygwin shell, all is ok.
But when i use it on dev-cpp the output contain some crap chars, because GCC 
output utf8 error
messages

Is there a way to avoid that GCC output text in utf8 ?

Here is dev-cpp source.Its since long time not fortherdevelop.I think it cant 
output UTF8 text and
nobody enhance it.but its a good IDE that can easy use for crosscompile and use 
diffrent compiler
sets.

http://sourceforge.net/projects/dev-cpp/

older GCC compiler have no problems.

Or maybe somebody can suggest a better IDE for windows that let easy choose in 
GUI a Target Compiler

Bye

Re: Using C++ in GCC is OK

[Bernd Roesch]

Hello 

On 01.06.10, you wrote:

> making
>> it take a hundred times more specifically in the changed places would
>> magnify the 0.1% overall change to a measurable delta of 10%.
> Your argument is applicable to any changes in GCC, not just to C to C++
> conversions. Do patches that slow down the current C code base by 0.1% get
> rejected? They do not.

compile a program in g++ mode really slowdown lots.A build of GCC need on my 
system 25 minutes, when
gcc compile in g++ mode i think it need to compile more than 1 hour.

you can see that when you look at C++ programs with same exe size.compile time 
is around 3* higher
in compare to C program, even if c++ is called not make so small code.

when i look on Visual C++ in C++ programs i see not so much slowdown.

maybe G++ can speedup in any way ?

> 
> --
> VH
> 
Regards

C++ va_list wromng code generation in class::method(...,va_list args) only

[Bernd Roesch]

hello

there is a C++ game called dunelegacy which work on other GCC architecture ok
On G++ 68k it compile ok, but produce wrong code, because there seem something 
diffrent in
va_list. The value of
SDL_RWops is transfer wrong.

I do not understand what backend problem is possible to cause this. Please 
help.va_list use the
builtin GCC functions

this happen on all 68k compilers i test. (3.x and some 4.x)

See also the source attached of this class

the program flow of the critical part begin here. 

Wsafile::Wsafile(SDL_RWops* RWop)
{
readdata(1,RWop);
}

..


now there are 2 Methods named readdata, and gcc call the 2. one. This work 
wrong. Only when called
the first is ok.

.

void Wsafile::readdata(int NumFiles, ...) {
va_list args;
va_start(args,NumFiles);
readdata(NumFiles,args);
va_end(args);
}

/// Helper method for reading and concatinating various WSA-Files.
/**
This methods reads from the RWops all data and concatinates all the frames 
to one animation. The
SDL_RWops
can be readonly but must support seeking.
\param  NumFilesNumber of SDL_RWops
\param  argsSDL_RWops for each wsa-File should be in this va_list. 
(can be readonly)
*/
void Wsafile::readdata(int NumFiles, va_list args) {
unsigned char** Filedata;
Uint32** Index;
Uint16* NumberOfFrames;
bool* extended;

if((Filedata = (unsigned char**) malloc(sizeof(unsigned char*) * NumFiles)) 
== NULL) {
fprintf(stderr, "Wsafile::readdata(): Unable to allocate memory!\n");
exit(EXIT_FAILURE);
}


.


when i change code to this and rename the first readdata method to 
readdata_first then it work

Wsafile::Wsafile(SDL_RWops* RWop)
{
readdata_first(1,RWop);   < I change that line
}

now there is called this method before and all work ok


void Wsafile::readdata_frist(int NumFiles, ...) {   < I rename readdata to 
readdata_first.
va_list args;
va_start(args,NumFiles);
readdata(NumFiles,args);
va_end(args);
}

/// Helper method for reading and concatinating various WSA-Files.
/**
This methods reads from the RWops all data and concatinates all the frames 
to one animation. The
SDL_RWops
can be readonly but must support seeking.
\param  NumFilesNumber of SDL_RWops
\param  argsSDL_RWops for each wsa-File should be in this va_list. 
(can be readonly)
*/
void Wsafile::readdata(int NumFiles, va_list args) {
unsigned char** Filedata;
Uint32** Index;
Uint16* NumberOfFrames;
bool* extended;

if((Filedata = (unsigned char**) malloc(sizeof(unsigned char*) * NumFiles)) 
== NULL) {
fprintf(stderr, "Wsafile::readdata(): Unable to allocate memory!\n");
exit(EXIT_FAILURE);
}

..

   int WsaFilesize;
RWop = va_arg(args,SDL_RWops*);   
Filedata[i] = readfile(RWop,&WsaFilesize); <--- here crash, when not 
the 1. method is called
before

Bye