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

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 nospamn...@gmx.de 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: 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: 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

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: 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

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

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): 

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

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

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: -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

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: 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 stdio.h
 #include stdint.h
 
 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

-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 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 http://gcc.gnu.org/bugs.html 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= 8lowres;

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;i4;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-flagsCODEC_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; i2; 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_picture_ptr-data;
}

mpeg_motion_lowres(s, 

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

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 stdint.h header file. */
#define _GLIBCXX_HAVE_STDINT_H 1

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


 GCC now supports providing the header stdint.h (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 
 http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00305.html.
 
 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 stdint.h, 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

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 math.h 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 dosr...@gmail.com
 wrote:
 On Mon, Mar 9, 2009 at 7:11 AM, Bernd Roesch nospamn...@web.de 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: 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 dosr...@gmail.com
 wrote:
 On Mon, Mar 9, 2009 at 7:11 AM, Bernd Roesch nospamn...@web.de 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

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 lrintsrcmodedestmode
 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_castfloat(argc)));  // work not
printf(%f\n,std::sqrt(static_castdouble(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 nospamn...@web.de 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

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

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

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

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:
 
 many, many, many lines of log deleted
 
 /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: 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:  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 iostream
#include stdexcept

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

 std::coutHallo 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

__throw_logic_error abort, but print no error message out

[Bernd Roesch]

Hello

the file in bits/basic_string.tcc call it.

templatetypename _CharT, typename _Traits, typename _Alloc
template typename _InIterator
  _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.

templatetypename _CharT, typename _Traits, typename _Alloc
template typename _InIterator
  _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.

templatetypename _CharT, typename _Traits, typename _Alloc
template typename _InIterator
  _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

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 libraries */


#define DO_COLLECTING 

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 ATT, but I have never seen it.  */
 
 @@ifc
-%expect 10 /* shift/reduce conflicts, and no reduce/reduce conflicts.  */
+%expect 11 /* shift/reduce conflicts, and no 

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 ATT, 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
 
 %{
@@ -1927,20 +1927,25 @@ absdcl: 

68k amiga OS and gcc4

[Bernd Roesch]

Hi, 

On 68k amiga OS the last working GCC compiler is 3.4.3

The porting gcc for dummies is from 2000 and i see not that it help for
newer versions.

I like to get the gcc 4.3.2  compiler working for 68k amiga OS.

mostly i need better gcc for c++.Is it possible to use 4.3.2 g++ with 3.4.3
rest of files ?
there seem on g++ no CPU specific things.

Can you tell me in short what i must do, or point to a docu ?.
I hear 68k support seem remove in gcc4

please help.


Bye