A simple question about virtual destructors.

Hi, My question is what if a compiler will generate a virtual destructor (or convert a nonvirtual to virtual) in a base class if the base class has at least one virtual function and classes down in the hierarchy have nontrivial destructors? In other words make a compiler responsible for pro

Re: A simple question about virtual destructors.

On 06/02/16 13:14, Marcin Baczyński wrote: 2016-06-02 11:55 GMT+02:00 K : Hi, My question is what if a compiler will generate a virtual destructor (or convert a nonvirtual to virtual) in a base class if the base class has at least one virtual function and classes down in the hierarchy have

Re: "Uninitialized array" warnings by c++ with -O2

That snippet invokes undefined behavior at runtime (violates C++ aliasing rules), so just fix it, rather than bother with bugreports. E.g. look for -fstrict-aliasing in GCC documentation, or read the C++ standard. With -fno-strict-aliasing, which is a workaround for broken code you won't ge

Re: "Uninitialized array" warnings by c++ with -O2

On 06/07/2017 04:56 PM, Andrew Haley wrote: On 07/06/17 14:45, K wrote: And I found that that a version which I beleve mustn't have aliasing problems still generates same warnings. It still has aliasing problems: you can't make them magically go away by using an intermedia

GSoC topic: Implement hot cold splitting at GIMPLE IR level

Hi Everyone, I was one of the original authors of hot cold splitting optimization in LLVM. I was wondering if implementing a region based hot cold splitting optimization would be useful in GCC? We already have optimal implementation of SESE region detection in GCC (https://github.com/gcc-mirror/

Fw: GSoC topic: Implement hot cold splitting at GIMPLE IR level

2:47 AM To: Aditya K ; gcc@gcc.gnu.org Cc: Jan Hubicka Subject: Re: GSoC topic: Implement hot cold splitting at GIMPLE IR level Hello. Thank you for idea. I would like to provide some comments about what GCC can currently do and I'm curious we need something extra on top of what we do. Righ

Combined top-down and bottom-up instruction scheduler

IIUC, in the haifa-sched.c, the default scheduling algorithm seems to be top-down (before reload). Is there a way to schedule the other way (bottom up), or both ways? As a use case for bottom-up or some other heuristic: Currently, the first priority in the selection is given to the longest path,

RE: Combined top-down and bottom-up instruction scheduler

> Subject: Re: Combined top-down and bottom-up instruction scheduler > To: hiradi...@msn.com; gcc@gcc.gnu.org > CC: vmaka...@redhat.com > From: l...@redhat.com > Date: Tue, 8 Sep 2015 12:51:24 -0600 > > On 09/08/2015 12:39 PM, Aditya

Help with gcc-plugin (Traverse all loops inside function)

I started with one of the test cases in the plugin testsuite "def_plugin.c". Pasted the code for convenience. I want to traverse all the loops in a function. Maybe use, loops_for_fn (DECL_STRUCT_FUNCTION (fndef)), but this does not seem to work. /* Callback function to invoke after GCC finishe

RE: Proposal for adding splay_tree_find (to find elements without updating the nodes).

> Date: Mon, 9 Mar 2015 15:26:26 -0400 > From: tbsau...@tbsaunde.org > To: gcc@gcc.gnu.org > Subject: Re: Proposal for adding splay_tree_find (to find elements without > updating the nodes). > > On Mon, Mar 09, 2015 at 06:59:10PM +, vax mzn wrote: >>

RE: Proposal for adding splay_tree_find (to find elements without updating the nodes).

> From: stevenb@gmail.com > Date: Mon, 9 Mar 2015 23:59:52 +0100 > Subject: Re: Proposal for adding splay_tree_find (to find elements without > updating the nodes). > To: hiradi...@msn.com > CC: gcc@gcc.gnu.org > > On Mon, Mar 9, 2015 at 7:59 PM, vax

RE: Proposal for adding splay_tree_find (to find elements without updating the nodes).

--- > Date: Tue, 10 Mar 2015 11:20:07 +0100 > Subject: Re: Proposal for adding splay_tree_find (to find elements without > updating the nodes). > From: richard.guent...@gmail.com > To: stevenb@gmail.com > CC: hiradi...@msn.com; gcc@gcc.gnu.org > > On Mon, Ma

RE: Proposal for adding splay_tree_find (to find elements without updating the nodes).

You're right. I'll change this to: /* A stable comparison functor to sort trees.  */ struct tree_compare_decl_uid {   bool  operator ()(const tree &xa, const tree &xb) const   {     return DECL_UID (xa) < DECL_UID (xb);   } }; New patch attached. Thanks, -Aditya --

RE: Examples of GCC plugins

> Date: Sat, 14 Mar 2015 18:22:29 +0300 > From: malts...@gmail.com > To: gcc@gcc.gnu.org; san...@codesourcery.com > Subject: Examples of GCC plugins > > Hi, all. > > When I first tried to write a simple plugin for GCC, it turned out that > existing docs on

RE: Proposal for another approach for Loop transformation with conditional in Loops.

> From: ajit.kumar.agar...@xilinx.com > To: l...@redhat.com; richard.guent...@gmail.com; gcc@gcc.gnu.org > CC: vin...@xilinx.com; shail...@xilinx.com; vid...@xilinx.com; > nmek...@xilinx.com > Subject: Proposal for another approach for Loop transformation

RE: Proposal for another approach for Loop transformation with conditional in Loops.

> From: ajit.kumar.agar...@xilinx.com > To: l...@redhat.com; richard.guent...@gmail.com; gcc@gcc.gnu.org > CC: vin...@xilinx.com; shail...@xilinx.com; vid...@xilinx.com; > nmek...@xilinx.com > Subject: Proposal for another approach for Loop transformation

RE: Proposal for adding splay_tree_find (to find elements without updating the nodes).

strap enabled), I'm not sure if 'omp' related tests were exercised. I'm still unfamiliar with several components of gcc. Any pointers on how to ensure all tests were run, would be useful. -Aditya > > thanks! > > Trev > > On Fri, Mar 13, 2015

RE: Proposal for adding splay_tree_find (to find elements without updating the nodes).

> From: lopeziba...@gmail.com > Date: Mon, 16 Mar 2015 15:16:55 +0100 > Subject: Re: Proposal for adding splay_tree_find (to find elements without > updating the nodes). > To: tbsau...@tbsaunde.org; gcc@gcc.gnu.org; hiradi...@msn.com > >>> Thanks for the

RE: Proposal for adding splay_tree_find (to find elements without updating the nodes).

> From: lopeziba...@gmail.com > Date: Mon, 16 Mar 2015 17:04:58 +0100 > Subject: Re: Proposal for adding splay_tree_find (to find elements without > updating the nodes). > To: jwakely@gmail.com > CC: hiradi...@msn.com; tbsau...@tbsaunde.org; gcc@gcc.g

RE: Proposal for adding splay_tree_find (to find elements without updating the nodes).

> From: hiradi...@msn.com > To: lopeziba...@gmail.com; jwakely@gmail.com > CC: tbsau...@tbsaunde.org; gcc@gcc.gnu.org > Subject: RE: Proposal for adding splay_tree_find (to find elements without > updating the nodes). > Date: Mon, 16 Mar 2015 18:45:22

RE: Proposal for adding splay_tree_find (to find elements without updating the nodes).

gnu.org > > On Mon, Mar 16, 2015 at 4:33 AM, Aditya K wrote: >> >> >> >>> Date: Sun, 15 Mar 2015 02:32:23 -0400 >>> From: tbsau...@tbsaunde.org >>> To: gcc@gcc.gnu.org >>> Subject: Re: Proposa

RE: Proposal for adding splay_tree_find (to find elements without updating the nodes).

.@gmail.com; tbsau...@tbsaunde.org; gcc@gcc.gnu.org > > On 18 March 2015 at 21:20, Aditya K wrote: >> >> >> >>> Date: Wed, 18 Mar 2015 11:50:16 +0100 >>> Subject: Re: Proposal for adding splay_tree_find (to find elemen

RE: Proposal for adding splay_tree_find (to find elements without updating the nodes).

athamesh.kulka...@linaro.org >> To: hiradi...@msn.com >> CC: richard.guent...@gmail.com; tbsau...@tbsaunde.org; gcc@gcc.gnu.org >> >> On 18 March 2015 at 21:20, Aditya K wrote: >>> >>> >>> >>>>

RE: Proposal for adding splay_tree_find (to find elements without updating the nodes).

out > updating the nodes). > Date: Tue, 31 Mar 2015 09:09:24 +0200 > > Hi! > > On Mon, 30 Mar 2015 22:28:41 +, Aditya K wrote: >> So I have modified the patch to use hash_map instead of std::map. The patch >> is attached. >> >> However, I got one regres

RE: AutoFDO profile toolchain is open-sourced

-C $SRC/SingleSource/Benchmarks/Linpack clean $MAKE -C $SRC/SingleSource/Benchmarks/Linpack -k TEST=simple TARGET_LLVMGCC=$CC TARGET_CXX=$CXX LLI_OPTFLAGS= TARGET_CC=$CC TARGET_LLVMGXX=$CXX CC_UNDER_TEST_IS_GCC=1 TARGET_FLAGS= USE_REFERENCE_OUTPUT=1         CC_UNDER_TEST_TARGET_IS_AARCH64=1 OP

RE: Compiler warnings while compiling gcc with clang‏

> CC: hiradi...@msn.com; gcc@gcc.gnu.org > From: pins...@gmail.com > Subject: Re: Compiler warnings while compiling gcc with clang‏ > Date: Tue, 5 May 2015 01:11:38 -0700 > To: renato.go...@linaro.org > > > > > >> On May 5, 2015, at 1:00 AM, Renato Golin

RE: Compiler warnings while compiling gcc with clang‏

~ ../../gcc/gcov-tool.c:462:10: note: initialize the variable 'ret' to silence this warning   int ret;          ^           = 0 I think I can fix few of these if we want them to be fixed. For some e.g. ( gcc/gcov-tool.c:225:7: warning: array index 1 is past the end of the

RE: Compiler warnings while compiling gcc with clang‏

gt; > >> On May 5, 2015, at 8:13 PM, Aditya K wrote: >> >> So, I analyzed other warnings and following is the list of relevant warning >> that I could collect. Hope this is useful. >> >> >> gcc/ipa-icf.c:508:12: warning: logical not is only applied to

RE: AutoFDO profile toolchain is open-sourced

> Date: Fri, 8 May 2015 11:19:12 -0700 > Subject: Re: AutoFDO profile toolchain is open-sourced > From: de...@google.com > To: i.palac...@samsung.com > CC: davi...@google.com; hubi...@ucw.cz; gcc@gcc.gnu.org; > v.bari...@samsung.com; dnovi...@google.com;

RE: AutoFDO profile toolchain is open-sourced

Recently we found an ICE while compiling a program with auto-fdo (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65972). The ICE was caused because SSA is not in a valid state when the early inliner is run. The fix was to update_ssa before running the early inliner (https://gcc.gnu.org/bugzilla/sh

returning struct or union with just double on Win32/x86

typedef struct { double d; } Struct; Struct f1 () { Struct res = {3.0}; return res; } typedef union { double d; } Union; Union f2 () { Union res = {3.0}; return res; } x86 mingw 7.3.0 The first returns in ST0, the  second in edx:eax. Msvc returns first in edx:eax. Seems like a bug? Thank

computed goto, const, truncated int, C++, etc.

computed goto. ​ ​ The documentation advertises read only relative address.​ ​ Like this:​ ​ https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html​ ​ ```​ static const int array[] = { &&foo - &&foo, &&bar - &&foo,​                              &&hack - &&foo };​ goto *(&&foo + array[i]);​ ```​ ​

Wrong header included in cross build with asymmetric GCC versions

A non-bootstrapped build: build triplet is x86_64-linux-gnu host,target triplet is x86_64-none-linux-musl host compiler is gcc version 6.3.0 ./configure --prefix=/usr --sysconfdir=/etc --target=x86_64-none-linux-musl --host=x86_64-none-linux-musl --libexecdir=/usr/lib --enable-threads=posix --libd

extern const initialized warns in C

extern const int foo = 123; Why does this warn? This is a valid portable form, with the same meaning across all compilers, and, importantly, portably to C and C++. I explicitly do not want to say:   const int foo = 123 because I want the code to be valid and have the same meaning in C and C++

Re: extern const initialized warns in C

e are many arguments for and against file level static.  - Jay From: David Brown Sent: Monday, January 22, 2018 8:32 AM To: Jay K; gcc Subject: Re: extern const initialized warns in C   On 21/01/18 08:12, Jay K wrote: > extern const int foo = 123; > > > > Why does this warn? &

Re: extern const initialized warns in C

and if I need to make    the symbol extern in future, I can afford a rename to do it.        - Jay From: Jay K Sent: Monday, January 22, 2018 9:31 AM To: David Brown; gcc Subject: Re: extern const initialized warns in C   By this argument there is a missing warning for the equivalent:   con

Re: extern const initialized warns in C

___ From: David Brown Sent: Monday, January 22, 2018 10:14 AM To: Jay K; gcc Subject: Re: extern const initialized warns in C Hi, I made some points in my other reply. But for completeness, I'll tackle these too. On 22/01/2018 10:38, Jay K wrote: > Also the warning did not i

Re: extern const initialized warns in C

exported if they are annotated in source or listed in a separate file. Not just by being non-static. - Jay From: David Brown Sent: Monday, January 22, 2018 10:42 AM To: Jay K; gcc Subject: Re: extern const initialized warns in C On 22/01/2018 11:14, Ja

r9 on ARM32?

I'm wondering what is the role of r9 on ARM32, on Linux and Android.   On Apple it is documented as long ago reserved, these days available for scratch. I've looked around a bit but haven't gotten the full answer. It is "the PIC register", I see. What does that imply? Volatile? Von-volatile? I

suggest more inhibit_libc for ia64-linux -- problems with exception handling when haven't yet built glibc.

Building cross gcc and binutils is easy, but for the libc/libgcc parts. I've wrestled with this a lot. I'm trying to build an ia64-linux cross toolset from a Mac. Including cross building glibc. I've gone through many options and errors, including sysroot and not, following the LFS stuff and

FW: gcc uses too much stack?

Have people considered that stack space should be used more conservatively by gcc? More malloc, less alloca, fewer/smaller local variables? More std::stack or such, less recursion on the machine stack? (Yes, I know std::stack has no existing use in gcc yet.) Don't make the amount of stack used

Adding memory write to a sparc fsqrts insn

Hello everybody, I'd like to patch gcc's sparc machine descritpion so that the destination register of a fpu sqareroot operation fsqrts is stored into memory after each fsqrts. like this: fsqrts %f2,%f4 st %f4, -4[%fp] <= add this after every fsqrts where -4[%fp] is

Generating store after fdivd: how to avoid delay slot

I try to patch gcc so that after a fdivd the destination register is stored to the stack. fdivd %f0,%f2,%f4; std %f4, [%sp] I generate the rtl for divdf3 using a emit_insn,DONE sequence in a define_expand pattern (see below). In the assembler output phase I use a define_insn and write out "fdivd

Issue on Solaris box

Hi, I'm running my C program on a Solaris machine with the following gcc version installed. >>gcc version 3.4.6 >>Thread model 3.4.6 >>/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.6/spec Issue: The same code seems to compile and execute fine on mingw running on Windows with gcc version 3.4

gcc 4.5.0 vms-gcc_shell_handler.c needs #define __NEW_STARLET

/src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c: In function 'get_dyn_handler_pointer': /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:3: error: 'PDSCDEF' undeclared (first use in this function) /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handl

gcc 4.5.0 stddef.h clobbers __size_t with #define, breaks VMS (code already avoids similar on FreeBSD)

VMS decc$types.h:     typedef unsigned int __size_t; but with GCC 4.5.0 this preprocesses as:     typedef unsigned int ;     and there are ensuing errors e.g. when compiling gcc/libiberty/regex.c probably because of: /usr/local/lib/gcc/alpha-dec-vms/4_5_0/include/stddef.h (it does get includ

gcc-4.5.0 internal compiler error on alpha-dec-vms compiling libiberty/regex.c without -mbwx

> src/gcc-4.5.0/libiberty/regex.c: In function 'byte_insert_op2': > /src/gcc-4.5.0/libiberty/regex.c:4279:1: error: unrecognizable insn: > (insn 62 61 63 5 /src/gcc-4.5.0/libiberty/regex.c:4276 (set (reg:DI 135) > (plus:SI (subreg/s:SI (reg/v/f:DI 109 [ pfrom ]) 0) > (const_int

gcc4.5.0/libiberty/pex-common.h missing pid_t on vms

In file included from /src/gcc-4.5.0/libiberty/pex-common.c:23:0: /src/gcc-4.5.0/libiberty/pex-common.h:73:3: error: expected specifier-qualifier-list before 'pid_t' the code: /* pid_t is may defined by config.h or sys/types.h needs to be    included.  */ #if !defined(pid_t) && defined(HAVE_SY

gcc 4.5.0 libiberty .o vs. .obj confusion

build=i386-darwin host=alpha-dec-vms target=alpha-dec-vms alpha-dec-vms-ar rc ./libiberty.a \       ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatfo

RE: gcc 4.5.0 libiberty .o vs. .obj confusion

I'm guessing that every ".o" in libiberty/Makefile.in should be changed to $(OBJEXT). Thanks,  - Jay > From: jay.kr...@cornell.edu > To: gcc@gcc.gnu.org > Subject: gcc 4.5.0 libiberty .o vs. .obj confusion > Date: Mon, 3 May 2010 11:29:15 + > > > bui

internal compiler error compiling gmp/get_d/gmpn_get_d for alpha-dec-vms

build=i386-darwin host=alpha-dec-vms target=alpha-dec-vms /bin/sh ../libtool --mode=compile alpha-dec-vms-gcc -mbwx -std=gnu99 -DHAVE_CONFIG_H -I. -I/src/gcc-4.5.0/gmp/mpn -I.. -D__GMP_WITHIN_GMP -I/src/gcc-4.5.0/gmp -DOPERATION_`echo get_d | sed 's/_$//'`    -g -O2 -c -o get_d.lo get_d.c  al

RE: gcc4.5.0/libiberty/pex-common.h missing pid_t on vms

> Use #ifdef HAVE_UNISTD_H instead. There are many examples in > libiberty. > > Ian Thanks Ian, that worked. --- /src/orig/gcc-4.5.0/libiberty/pex-common.h    2009-04-13 03:45:58.0 -0700 +++ /src/gcc-4.5.0/libiberty/pex-common.h    2010-05-04 06:43:24.0 -0700 @@ -31,6 +31,9 @@

RE: gcc 4.5.0 libiberty .o vs. .obj confusion

> CC: gcc@ > From: iant@ > > Jay: >> I'm guessing that every ".o" in libiberty/Makefile.in should be changed to >> $(OBJEXT). > > Yes. > > Ian Thanks. Specifically ".o" goes to "@objext@". There's no way I'm going to be able to get "the papers" in. I can try to squeak by via triviality of

RE: gcc 4.5.0 libiberty .o vs. .obj confusion

oops, also need like: --- /src/orig/gcc-4.5.0/libiberty/configure    2010-01-04 15:46:56.0 -0800 +++ /src/gcc-4.5.0/libiberty/configure    2010-05-05 05:40:52.0 -0700 @@ -6533,10 +6533,10 @@    # Figure out which version of pexecute to use.  case "${host}" in - *-*-mingw* | *

more .o vs. .obj targeting VMS

Here's the next one: alpha-dec-vms-ar cru libdecnumber.a decNumber.o decContext.o decimal32.o decimal64.o decimal128.o alpha-dec-vms-ar: decNumber.o: No such file or directory make[2]: *** [libdecnumber.a] Error 1 make[1]: *** [all-libdecnumber] Error 2 make: *** [all] Error 2 jbook2:vms jay$

gcc/resource.h conflicts with sysroot/usr/include/resource.h (alpha-dec-vms)

lpha-dec-vms-gcc -c   -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attri bute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -I. - I. -I/src/gcc-4.5.0/gcc -I/

builtin ffs vs. renamed ffs (vms-crtl.h)

In gcc for VMS there is some mechanism to rename functions. See the files: /src/gcc-4.5.0/gcc/config/vms/vms-crtl-64.h /src/gcc-4.5.0/gcc/config/vms/vms-crtl.h which are mostly just lists of function from/to. As well in gcc there is a mechanism for optimizing various "builtin" functions, lik

vmsdbgout.c int-to-enum cast and #define globalref

vmsdbgout.c has an int-to-enum warning and needs some form of "globalref" when host=alpha-dec-vms since that #includes the VMS system headers. Perhaps gcc should recognize globalref when target=*vms* and at least interpret it as extern. Thanks,  - Jay diff -u /src/orig/gcc-4.5.0/gcc/vmsdbgout.

pic+64bit+sun assembler+unwind-tables => illegal cross section subtraction

I haven't tried 4.5.0 yet. -bash-4.1$ /opt/csw/gcc4/bin/g++ -v Using built-in specs. Target: i386-pc-solaris2.10 Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4 --exec-prefix=/op t/csw/gcc4 --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/ usr/ccs/bin/ld --en

RE: pic+64bit+sun assembler+unwind-tables => illegal cross section subtraction

- > From: pins...@gmail.com > To: jay.kr...@cornell.edu > Subject: Re: pic+64bit+sun assembler+unwind-tables => illegal cross section > subtraction > Date: Sun, 9 May 2010 17:48:04 -0700 > CC: gcc@gcc.gnu.org > > > > Sent from my iPhone > > On May 9, 2010, at 5:42 P

RE: pic+64bit+sun assembler+unwind-tables => illegal cross section subtraction

- >> From: pins...@gmail.com >> To: jay.kr...@cornell.edu >> Subject: Re: pic+64bit+sun assembler+unwind-tables => illegal cross section >> subtraction >> Date: Sun, 9 May 2010 17:48:04 -0700 >> CC: gcc@gcc.gnu.org >> >> >> >> Sen

-disable-fixincludes doesn't quite work, minor

-disable-libgcc and/or -disable-fixincludes are useful, depending on your goal.  Like if you just want to compile C to assembly or object files. It fails, but only after doing what I want anyway. make[2]: *** No rule to make target `../build-sparc-sun-solaris2.10/fixincludes/fixinc.sh', neede

RE: pic+64bit+sun assembler+unwind-tables => illegal cross section subtraction

assembler" ; fi ) >> >> :) which addresses why I wasn't using GNU as. >> >> (Yes, I've heard of autoconf.) >> >> Thanks, later, >> - Jay >> >> >> >>> From: pins...@gmail.com >&g

RE: -disable-fixincludes doesn't quite work, minor

n't quite work, minor > From: i...@google.com > Date: Mon, 10 May 2010 09:50:01 -0700 > > Jay K writes: > >> -disable-libgcc and/or -disable-fixincludes are useful, depending on your >> goal. >> >> Like if you just want to compile C to assembly or object

rep prefix doesn't work with Solaris 2.9 Sun assembler

Solaris 2.9 x86 gcc 4.5.0 configure -without-gnu-as -with-as=/usr/ccs/bin/as => Assembly syntax errors in gcov.c whereever there is rep prefix. I was actually looking for a problem with lock prefixes on 4.3 -- testing 4.5.0, found this instead, which is about about the same. See: http

RE: rep prefix doesn't work with Solaris 2.9 Sun assembler

Understood, but I'll have to stick to "small" changes as I can't get the papers. Uros pointed to: http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00657.html which appears to just be *very* coincident timing. So I Rainer will fix it soon. I have a patch now based on that discussion. I used:     cas

FW: [Bug c/44166] New: -fvisibility=protected doesn't work?

> Date: Mon, 17 May 2010 13:41:57 + > Subject: [Bug c/44166] New: -fvisibility=protected doesn't work? > To: jay.kr...@cornell.edu > From: gcc-bugzi...@gcc.gnu.org > > -fvisibility=protected doesn't work? > > a...@xlin2:~$ cat 1.c > void F1() { } > voi

alpha-dec-osf5.1 4.5 built/installed

per http://gcc.gnu.org/install/finalinstall.html Built/installed 4.5 on alpha-dec-osf. alphaev67-dec-osf5.1 bash-4.1$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/jayk/libexec/gcc/alphaev67-dec-osf5.1/4.5.0/lto-wrapper Target: alphaev67-dec-osf5.1 Configured with: /hom

how to get instruction codes in gcc passes?

Hi all. (I have never used these maillists before. Sorry if something wrong here.) I am newbie in gcc and I need some help. I am performing some research work in theme of code optimization. Now I have to write my own optimization pass for gcc. And in this pass I need to get the instruction codes

Re: how to get instruction codes in gcc passes?

On Sun, Jun 13, 2010 at 6:38 PM, Richard Guenther wrote: > On Sun, Jun 13, 2010 at 4:29 PM, Ilya K wrote: >> Hi all. >> (I have never used these maillists before. Sorry if something wrong here.) >> >> I am newbie in gcc and I need some help. >> >> I am pe

Re: how to get instruction codes in gcc passes?

hought that if gcc already have the base of optimizations then this will be a best place to put another one. I do not know now if these assembler tools have a room for optimization. Ilya K

Re: how to get instruction codes in gcc passes?

ybe is not the best place for my optimizations. I will try to see if binutils or mao provides better environment for this developing. Thanks for pointing out the places where the low-level optimizations are more suitable. Ilya K

Re: how to get instruction codes in gcc passes?

heless I have to work on the low-level. At the back-end. It is a feature of my work :). So, maybe I'll just switch to inserting my code into binutils, or mao project. Ilya K

ARM FLOOR_MOD_EXPR?

Do FLOOR_DIV_EXPR and FLOOR_MOD_EXPR work on ARM, for 64bit signed integer? I have a front end (sort of), using gcc 4.3, generates trees, doesn't work.    type_for_mode(TImode) is NULL and that is dereferenced. I realize TRUNC_* would be far more "normal", but I can't change that. I guess I'll jus

RE: ARM FLOOR_MOD_EXPR?

in calls.c:   tfom = lang_hooks.types.type_for_mode (outmode, 0);   if (aggregate_value_p (tfom, 0)) for 64bit mod, outmode ends up TImode. Our frontend doesn't support TImode -- reasonable? -- and so type_for_mode returns NULL here. aggregate_value_p then derefences that NULL. At leas

suggest assert wide_int larger than hashval_t

I get this in 4.3.5: ../../gcc/gcc/varasm.c: In function `const_rtx_hash_1': ../../gcc/gcc/varasm.c:3387: warning: right shift count >= width of type ./include/hashtab.h:typedef unsigned int hashval_t;   unsigned HOST_WIDE_INT hwi;   hashval_t h, *hp;  ...     const int shift = sizeof (hashval_

RE: suggest assert wide_int larger than hashval_t (32bit hwint?)

Hm, it seems on some 32bit systems, where there is no -m64, wideint can be a mere 32bits. In which case the code should probably say: hwi = ((hwi >> (shift - 1)) >> 1); This was targeting OpenBSD/x86. Maybe I should just stick need_64bit_hwint = yes on config.gcc for that and move along? Assu

RE: suggest assert wide_int larger than hashval_t

Subject: Re: suggest assert wide_int larger than hashval_t > Date: Mon, 19 Jul 2010 00:36:06 -0700 > > Jay K writes: > > > I get this in 4.3.5: > > > > ../../gcc/gcc/varasm.c: In function `const_rtx_hash_1': > > ../../gcc/gcc/varasm.c:3387: warning: rig

http://gcc.gnu.org/install/specific.html maybe should mention memory settings for OpenBSD

Possibly a note for: http://gcc.gnu.org/install/specific.html under OpenBSD. or just for the mail archives: Building a *slight* fork of 4.5.1 on OpenBSD/x86 4.7 I hit gcc -c  -g -O2 -static -DIN_GCC   -W -Wall -Wwrite-strings \ -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attr

built-in atomic functions

Hello, Are there any new built-in implementations equivalent to atomic_read and atomic_write in latest releases ? if not should I rely on trick suggested in one of the earlier discussions as below ? ">>We don't have atomic read or atomic write builtins (ok, you could >>abuse __sync_fetch_and

64 bit porting guide

Hello, I am porting my application from 32bit to 64bit architecture on intel. Can anyone point me to some good references for 64bit porting on intel platform(32bit i686 to 64bit x86_64) Thanks, manju

internal compiler error: in referenced_var_lookup, at tree-dfa.c

So..we have a custom frontend. That uses process boundaries to avoid GPL crossing into BSDish licensed code. So maybe you don't want to help me. Understood. But just in case: We generate trees. Probably they aren't of great quality. e.g. relatively devoid of types and do field accesses by offset

RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c

@gcc.gnu.org > Subject: Re: internal compiler error: in referenced_var_lookup, at tree-dfa.c > > On 9/10/2010 11:08 AM, Ian Lance Taylor wrote: > > Jay K writes: > > > >> That uses process boundaries to avoid GPL crossing into BSDish licensed > >> code. >

RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c

[licensing dealt with separately] > > Variable: D.1093058884, UID D.1093058884, int_32gimple_default_def > > 0x412130a8 1093058884 > This is clearly wrong, though I have no idea what caused it. > > Is it valid for uids to be so high? > No. Thanks, that helps. > From your description, you've

RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c

> I kind of suspect it might be a type mismatch, overwriting part of a tree node configure -enable-checking: ?"Bmr?: In function 'FPrint__xCombine': `?"Bmr?:13:0: internal compiler error: tree check: expected ssa_name, have var_decl in copy_phis_for_bb, at tree-inline.c:1950 and some other pro

RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c

arg..well, I had replaced xmalloc with alloca, leading to some of the garbage below, but I am indeed still running afoul of the garbage collector. I don't know if that is my original problem but I should probably fix this first.  ie: now that I'm using -enable-checking, and I think it collects e

RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c

I have it seemingly working now, much better, thanks for the nudges -- that indeed high id is invalid, and to look again at my GTY use. I don't know if it made the difference but I changed some whitespace to match others, and typedef struct foo_t { ... } foo_t; to typedef struct foo { ... } foo_

eliminating mpc/mpfr and reducing gmp

Hi. You know, gmp/mpfr/mpc are a significant portion of building any frontend/backend. So I looked at it. mpc of course is only for complex numbers. Our frontend doesn't use them. Maybe only for "builtins" as well. #define do_mpc_arg1(a, b, c) NULL_TREE and such. mpfr appears to be used fo

RE: eliminating mpc/mpfr and reducing gmp

lots others, but then the linkage between gcc and gmp gets messy.   i.e. as gmp changes.  - Jay > Date: Mon, 27 Sep 2010 11:37:04 +0100 > From: a...@redhat.com > To: jay.kr...@cornell.edu > CC: gcc@gcc.gnu.org > Subject: Re: eliminating mpc

RE: eliminating mpc/mpfr and reducing gmp

+0100 > From: dave.korn.cyg...@gmail.com > To: jay.kr...@cornell.edu > CC: a...@redhat.com; gcc@gcc.gnu.org > Subject: Re: eliminating mpc/mpfr and reducing gmp > > On 27/09/2010 12:39, Jay K wrote: > > > gmp > > time sh -c "CC=gcc-4.2 ./configure n

RE: eliminating mpc/mpfr and reducing gmp

> Well, the other thing is: why not just build them once and install them to > your $prefix? There's no need to build them in-tree every time if you have > sufficiently up-to-date versions installed. > > cheers, > DaveK I have a CVS tree, used by others, that builds a frontend. "Others" are

atomicity of x86 bt/bts/btr/btc?

gcc-4.5/gcc/config/i386/i386.md: ;; %%% bts, btr, btc, bt. ;; In general these instructions are *slow* when applied to memory, ;; since they enforce atomic operation. When applied to registers, I haven't found documented confirmation that these instructions are atomic without a lock prefix, ha

RE: atomicity of x86 bt/bts/btr/btc?

> Subject: Re: atomicity of x86 bt/bts/btr/btc? > From: foxmuldrsterm > To: jay.krell > CC: gcc@gcc.gnu.org > Date: Tue, 19 Oct 2010 02:52:34 -0500 > > > ;; %%% bts, btr, btc, bt. > > ;; In general these instructions are *slow* when applied to memory, > > ;

RE: atomicity of x86 bt/bts/btr/btc?

> Subject: RE: atomicity of x86 bt/bts/btr/btc? > From: foxmuldrster > To: jay > CC: gcc > Date: Tue, 19 Oct 2010 03:05:26 -0500 > > > > They do not automatically lock the bus. They will lock the bus with the > > > explicit LOCK prefix, and BTS is typically

is gcc garbage collector compacting?

Is the gcc garbage collector compacting? In particular I want to have ".def" file (like tree.def) where the macros generate struct declarations, and the fields might be tree. That won't work with the gcc garbage collection scheme. However, I'm willing also store all trees that go in these st

RE: is gcc garbage collector compacting?

> Are you coding inside your branch, or just your plugin?  > [implied] What are you actually doing? It isn't relevant or short, but if you really want to know: It is a front end, and indeed, a branch, it won't ever be contributed. It is the Modula-3 frontend, which plays slight licensing gam

RE: is gcc garbage collector compacting?

> I believe that your case is a very good example of why front-ends > should be able to become plugins. It is not the case yet, and adding Currently we do define a new tree code, I think just one. And the implementation is *slightly* invasive. I was tempted to write up a proposal to this list

asm_fprintf inefficiency?

so..I was bemaining to self extra #ifs, extra autoconf.. the checking for puts_locked... the fact that asm_fprintf calls putc one character at a time, which probably benefits from _unlocked. 1) asm_fprintf probably should skip from % to %, calling puts on each span, instead of putc one at a tim

RE: asm_fprintf

> And putc_unlocked is a macro which appends to a buffer. puts is not. I *assumed* there is puts_unlocked like all the other *_unlocked. Maybe not. > (Really I'd rather gcc just output .o files directly...) > It would be an interesting project, but it's not a major component of > opti

extern "C" applied liberally?

I know it is debatable and I could be convinced otherwise, but I would suggest: #ifdef __cplusplus extern "C" { #endif ... #ifdef __cplusplus } /* extern "C" */ #endif be applied liberally in gcc. Not "around" #includes, it is the job of each .h file, and mindful of #ifdefs (ie: cor

  1   2   3   >