> check for double "close" of a FD (CWE-1341).
> check for read/write of a closed file descriptor
These sound good but kinda non general or incomplete to me.
I mean, isn't the "right" thing, to disallow passing
a closed fd to "almost any" function?
But I realize "almost any" is diffic
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]);
```
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
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
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
___
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
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
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?
&
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++
--
> Date: Sat, 9 Feb 2013 23:41:24 -0800
> Subject: Re: problems compiling 4.7, with Solaris cc and/or Solaris CC (C++)
> From: pins...@gmail.com
> To: jay.kr...@cornell.edu
> CC: gcc@gcc.gnu.org
>
> On Sat, Feb 9, 2013 at 3:49 PM, Jay K wrote:
> > p
problems compiling 4.7, with Solaris cc and/or Solaris CC (C++)
1) ENUM_BITFIELD is not portable. I've reported this before.
It should be more like:
#ifdef __cplusplus
#define ENUM_BITFIELD(TYPE, NAME, SIZE) enum TYPE NAME : SIZE
#elif (GCC_VERSION > 2000)
#define ENUM_BITFI
They clause client code taking the address
=> cause
structs adn classes
=> and
> On Tue, Jun 12, 2012 at 03:57:44PM +0000, Jay K wrote:
> >
> > Our front end is wierd.
> > The input is unusually low level, and so are the trees it produces.
> > I do have a hankering to fix that (or maybe just to output more portable
C...)
> >
Our front end is wierd.
The input is unusually low level, and so are the trees it produces.
I do have a hankering to fix that (or maybe just to output more portable C...)
But for now:
It doesn't use component_refs, and doesn't
define types much, but uses either
either (type*)(base + offset) or bit
ok. 1) my mistake for not reading the FAQ, sorry.
2) add to the FAQ, for the diligent folks who read it? Sorry, good point.
It's tough, you know, bootstrap compilers vary widely in quality. gcc 4.0
pretty good, old vendor cc sometimes really bad, though they are falling out of
support (e.g. HP-U
./../gcc-4.7/gcc/pretty-print.h:324: warning: ‘__gcc_tdiag__’ is an
unrecognized format function type
../../gcc-4.7/gcc/pretty-print.h:327: warning: ‘__gcc_tdiag__’ is an
unrecognized format function type
I get a lot of those.
Yes, I'm using -disable-bootstrap.
It is a warning, not an error.
gcc-4.7.0/gcc/config/alpha/alpha.c
word1 = expand_and (DImode, word1, GEN_INT (0x0ffffff0), NULL);
That "big" constant isn't portable since it doesn't fit in 32bits.
1) append LL
or 2) break it up into an expression, like
((HOST_WIDE_INT)0x0fff) << 8) | 0x0fff0
or such.
At the bottom of mkconfig.sh in 4.6.2 and 4.7.0:
# Avoid changing the actual file if possible.
if [ -f $output ] && cmp ${output}T $output >/dev/null 2>&1; then
echo $output is unchanged >&2
rm -f ${output}T
else
mv -f ${output}T $output
fi
# Touch a stamp file for Make's benefit.
r
ng go? (older g++,
> -disable-bootstrap)
> Date: Mon, 21 May 2012 06:48:08 -0700
>
> Jay K writes:
>
> >> --enable-stage1-languages=go. (Mail to the OP is bouncing for me, by
> >> the way.)
> >
> > I don't know why.
> > I'm getting them,
> --enable-stage1-languages=go. (Mail to the OP is bouncing for me, by
> the way.)
I don't know why.
I'm getting them, at least via the list.
> Since the OP is apparently seeing Go build in stage 1, I assume that the
> OP is configuring with --disable-bootstrap or with
Right. I thought I was
gcc-4.6.2/gcc/Makefile.in:
tree-nomudflap.o : $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(TREE_INLINE_H) \
$(C_TREE_H) $(C_COMMON_H) $(GIMPLE_H) $(DIAGNOSTIC_H) $(HASHTAB_H) \
output.h langhooks.h tree-mudflap.h $(TM_H) coretypes.h \
$(GGC_H) gt-tree-mudflap.h $(TREE_PASS_H) $(DIAGNOSTIC_CORE_H
/src/gcc-4.7.0/configure -disable-bootstrap -enable-languages=go
book2:gccgo-4.7 jay$ g++ -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-checking
-enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++
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
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
I somewhat tracked down the odd/dubious reason extern "C" is "good".
Some wierd interaction on Darwin with Apple's gcc and gdb.
Breakpoints don't work on non-extern "C", at least if a library is involved.
This isn't necessarily a problem with gcc, or current gcc, or non-Apple gcc,
or gdb, or n
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
> 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
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
> 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
> 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
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
> 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
> 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,
> > ;
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
> 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
+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
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
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
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_
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
> 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
[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
@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.
>
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
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
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
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
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_
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
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
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
> 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
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
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
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
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
-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
-
>> 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
-
> 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
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
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.
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
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/
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$
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* | *
> 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
> 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 @@
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
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
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
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
> 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
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
/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
74 matches
Mail list logo
