Re: C as intermediate language, signed integer overflow and -ftrapv
On Fri, Jul 25, 2014 at 12:35, Richard Biener wrote: > On Fri, Jul 25, 2014 at 10:43 AM, Thomas Mertes wrote: > > On Thu, Jul 24 at 10:36 PM, Richard Biener > > wrote: > >> Fact is that if somebody is interested in > >> -ftrapv he/she is welcome to contribute patches. Especially testing > >> coverage is poor. > > > > As I said I have test programs for integer overflow (not written > > in C). Now I have converted one test program to C. This program > > checks if an int64_t overflow raises SIGABRT or SIGILL. The name of > > the program is chkovf64.c and I have uploaded it to > > > > http://sourceforge.net/projects/seed7/files/ > > > > It is licenced with GPL. You can use it to improve the testing > > coverage of gcc. When I compile it with: > > > > gcc -ftrapv chkovf64.c -o chkovf64 > > > > it writes a lot of warnings about "integer overflow in expression". > > Running chkovf64 shows that -ftrapv does not work correct. > > That's https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61893 - basically > as soon as we can constant-fold we lose the trap. Which is probably > not important for practical purposes, but you have a point here. For human programmers it is probably ok to have a warning instead of the trap. But when the C program has been generated (C as intermediate language) it is important that the trap is not lost. Isn't possible that constant-fold has the result "it will overflow"? Hopefully it is not necessary to omit an optimization because of -ftrapv. For my use-case that would be bad. I need -ftrapv together with all optimizations for production code and NOT for debugging purposes. > > Maybe all -ftrapv problems uncovered by chkovf64.c are because > > of this. Unfortunately there are also other test cases where > > a signal is not raised although a signed integer overflow occurred. > > This happens in a much bigger program and until now I was not > > able to create a simple test case from it. > > Yes, not all optimizations may be aware of -ftrapv. In the case above (the much bigger program) the error (overflow without raising SIGABRT) happens when I compile without -O and without -g. When I use -g the signal SIGABRT is raised. I still don't have a simple test case, sorry. Did you have a look at chkovf64.c? Is it useable as test program for -ftrapv? Greetings Thomas Mertes -- Seed7 Homepage: http://seed7.sourceforge.net Seed7 - The extensible programming language: User defined statements and operators, abstract data types, templates without special syntax, OO with interfaces and multiple dispatch, statically typed, interpreted or compiled, portable, runs under linux/unix/windows.
New architecture port: legal matters and copyright assignment
Hi, I'm coordinating the effort to prepare the OpenRISC architecture GCC port for mainline review. The website https://gcc.gnu.org/contribute.html recommends reaching out to this mailing list for all the latest and greatest help to make this happen. I'm aware of the process of assigning copyright via ass...@gnu.org (the form that requests a list of all changed files), that was the process we followed for binutils. Is there anything else that needs to be done? Thanks in advance, Christian
Ann: MELT plugin 1.1 release available for GCC 4.8 & 4.9
Dear All,
It is my pleasure to announce the MELT plugin 1.1 release for GCC 4.8 &
4.9 (hosted preferably on Linux). I've corrected all the bugs found in
MELT 1.1rc1.
MELT -see http://gcc-melt.org/ for more - is a domain specific language
and meta-plugin (free software GPLv3+ licensed, FSF copyrighted) to
easily extend and customize the GCC compiler.
The MELT plugin 1.1 release (for GCC 4.8 or 4.9, with major
updates since previous MELT plugin 1.0.2) is available (since july 27th,
2014) from
http://gcc-melt.org/melt-1.1-plugin-for-gcc-4.8-or-4.9.tar.bz2
This is a bzipped2 source tar archive of 3891501 bytes (3.8 Mbytes) of
md5sum dcd4332f91140f12bee51ae4d33f66f0
This MELT 1.1 plugin is extracted from the GCC MELT branch svn revision
213094
NEWS for 1.1 MELT plugin for GCC 4.8 & 4.9
[[july 27th, 2014]]
This is a major release (with perhaps some small incompatibilities
with previous MELT plugin releases).
End-user improvements
=
***
The module list files *.modlis accept conditioned extra
modules. Within them, a line like
?findgimple xtramelt-ana-simple.optimized
means that: if the mode is findgimple, load the xtramelt-ana-simple
module in its optimized flavour.
The predefined modules now are named libmelt*.melt for standard
library modules and xtramelt*.melt for extra modules.
Language improvements
=
Add support for JSON (parsing and emitting JSON format) and
JSONRPC2 client with TCP/IP transport. See
DO_BLOCKING_JSONRPC2_CALL, MAKE_JSON_PARSER, OUTPUT_JSON, etc...
This requires an UTF-8 locale.
***
Several bug fixes, notably MELT-SFT-8. Better variadic binding.
Many small improvements.
***
The MODULE_IS_GPL_COMPATIBLE directive is now required to avoid
warnings. Your modules should be GPL compatible, and state that with
a directive like
(MODULE_IS_GPL_COMPATIBLE )
for example
(MODULE_IS_GPL_COMPATIBLE "GPLv3")
Runtime improvements
***
The old GTKmm (or Qt/Python) probe is becoming deprecated. A
partial support for JSON & JsonRpc2 client is available. A
web-based MELT monitor is in the works, but not yet released.
***
Input channel handlers can be either paragraph oriented (like in
previous MELT releases) or raw input.
***
We don't use setjmp but C++ exceptions
***
melt_walk_use_def_chains adapted for GCC 4.9, and compatibility with
GCC 4.9
***
The successful modes list is printed.
***
Nearly systematic use of hooks.
***
Improved support of pragmas, with both REGISTER_EXPANDED_PRAGMA &
REGISTER_PLAIN_PRAGMA function.
***
Sorting primitives like multiple_sort are fully reentrant, so their
compare routine might do a sort itself!
***
Remove old option handling, REGISTER_OPTION is removed.
Bug and success reports are welcome on gcc-m...@googlegroups.com
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
[GSoC] support for literals
Hi,
I was wondering if it would be a good idea to have the following syntax
for literals:
(type val) ?
type would be one of the tree-codes representing cst types like
INTEGER_CST, REAL_CST, etc.
eg:
(negate (integer_cst 3))
would be equivalent to the following:
(negate INTEGER_CST_P@0)
if (TREE_INT_CST_LOW (@0) == 3)
{ .. }
Also possibly provide a short-hand for some literals
like integer and floating point, so just writing
3 would be short-hand for (integer_cst 3) ?
Many patterns from [1] have integral constants to match.
eg: (a >> 2) >=3 -> a >= (3 << 2)
so this could be written as:
(gte (rshift @0 2) 3)
(gte @0 (lshift 3 2))
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14753
Thanks,
Prathamesh
gcc-4.10-20140727 is now available
Snapshot gcc-4.10-20140727 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.10-20140727/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.10 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 213104 You'll find: gcc-4.10-20140727.tar.bz2Complete GCC MD5=6273b304f429aa8d6122ef5a5d8c76d3 SHA1=425f1fd138c23aab40a68a0c3d6253e6b1b2c2da Diffs from 4.10-20140720 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.10 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Help w/ PR61538?
On 07/05/2014 23:43, Joshua Kinard wrote: > Hi, > > I filed PR61538 about two weeks ago, regarding gcc-4.8.x and up not > compiling a g++/pthreads-linked app correctly on SGI R1x000-based systems > (Octane, Onyx2), running Linux. Running the subsequently-compiled > application simply hangs in a futex syscall until terminated via Ctrl+C. I > suspect it's a double-locking bug of some design, as evidenced by strace > showing two consecutive syscall()'s w/ 0x108e passed as the syscall # (4238 > or futex on o32 MIPS), but I am stumped as to what else I can do to debug it > and help fix it. > [snip] > Full details: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 So I've spent the last few weeks bisecting the gcc tree, and I've narrowed down the set of commits that appear to have introduced this problem: 1. 39a8c5eaded1e5771a941c56a49ca0a5e9c5eca0 * config/mips/mips.c (mips_emit_pre_atomic_barrier_p,) 2. 974f0a74e2116143b88d8cea8e1dd5a9c18ef96c * config/mips/constraints.md (ZR): New constraint. 3. 0f8e46b16a53c02d7255dcd6b6e9b5bc7f8ec953 * config/mips/mips.c (mips_process_sync_loop): Emit cmp result only if 4. 30c3c4427521f96fb58b6e1debb86da4f113f06f * emit-rtl.c (need_atomic_barrier_p): New function. There's a build failure somewhere in the middle of there that is blocking me from figuring out which specific one is the cause, but they all appear to be related anyways. All four were added on 2012-06-20. When I took a git checkout from 2012-06-26 and reverted those four commits, I was able to compile glibc-2.19 and get a working "sln" binary. I am unable to easily test the C++ side because I built the checkouts in my $HOME, and it's too risky to try and shoehorn one of them in as the system compiler. However, I think the C++ issue is also fixed by reverting the four, as that also involved hanging in Linux futex syscalls. Obviously, reverting these four commits is obviously not an option for gcc releases, as over the last two years, a lot of code has been added that uses some of the new bits (like the ZR constraint). So do any of the gcc MIPS people have an idea what in these four commits could possibly be breaking R1x000-series CPUs on SGI systems under gcc-4.8 and gcc-4.9, so a proper patch can be made? Thanks! -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
