[Bug c/66326] New: Floating point exception with -mfpmath=387 and -fcilkplus.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66326 Bug ID: 66326 Summary: Floating point exception with -mfpmath=387 and -fcilkplus. Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ejolson at unr dot edu Target Milestone: --- Created attachment 35648 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35648action=edit Test code to illustrate bug. Must be run on at least a 2-core system. There appears a regression between the cilkplus-4_8-branch and the gcc-4.9 and gcc-5.1 compilers when merging cilk into mainline. In particular, the flags -mfpmath=387 and -fcilkplus can't be used together. As -mfpmath=sse is not an option on 32-bit, this renders cilk essentially useless on non-64-bit Intel architectures for floating point.
[Bug c/66326] Floating point exception with -mfpmath=387 and -fcilkplus.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66326 --- Comment #1 from Eric ejolson at unr dot edu --- The compilers gcc-5.1 and cilkplus-4_8-branch were bootstrapped using the Debian 4.7.2-5 gcc compiler on Debian Wheezy. Compiling and running the test program yields the following output: $ /usr/local/gcc-5.1/bin/gcc -fcilkplus -Wall \ -mfpmath=387 fpbug.c -o fpbug-gcc510-387 -lcilkrts -lm $ ./fpbug-gcc510-387 Floating point exception $ /usr/local/gcc-5.1/bin/gcc -fcilkplus -Wall \ -mfpmath=sse fpbug.c -o fpbug-gcc510-sse -lcilkrts -lm $ ./fpbug-gcc510-sse f(1)+g(2)=0.850648 $ /usr/local/cilk-4.8/bin/gcc -fcilkplus -Wall \ -mfpmath=387 fpbug.c -o fpbug-cilk48-387 -lcilkrts -lm $ ./fpbug-cilk48-387 f(1)+g(2)=0.850648 $ /usr/local/cilk-4.8/bin/gcc -fcilkplus -Wall \ -mfpmath=sse fpbug.c -o fpbug-cilk48-sse -lcilkrts -lm $ ./fpbug-cilk48-sse f(1)+g(2)=0.850648
[Bug c/66326] Floating point exception with -mfpmath=387 and -fcilkplus.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66326 --- Comment #2 from Eric ejolson at unr dot edu --- Additional information and discussion about this bug may be found on the Intel Cilk Plus developer forum at https://software.intel.com/en-us/forums/topic/558825
[Bug c/67224] UTF-8 support for identifier names in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 --- Comment #12 from Eric ejolson at unr dot edu --- I'm glad to know people like Joseph are working on UTF-8 in gcc. Last year I spent a week adding UTF-8 input support to pcc. At that time Microsoft Studio and clang already supported UTF-8 input files and I expected that gcc would do so in the next release. As this didn't happen, a few months ago I looked and developed a one-line patch to add this support to gcc. It appears the C preprocessor falls back to libiconv when it encounters a conversion not supported internally. From what I can tell this is enabled by default, though it is surely possible to disable it. I'm aware that C strings are often used to store 8-bit data, for example, to display various graphics characters from legacy code pages. I will run the regression tests as soon as possible to see what, if anything, has broken by my one-line patch. UCN quoting of UTF-8 input should happen only if the -finput-charset=UTF-8 flag is set and this is worth checking.
[Bug c/67224] UTF-8 support for identifier names in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 --- Comment #6 from Eric ejolson at unr dot edu --- From the webpage (current as of Aug 17, 2015) http://www.gnu.org/software/libiconv/ under *Details* it is described that the library provides support for the following encodings: Full Unicode UTF-8 UCS-2, UCS-2BE, UCS-2LE UCS-4, UCS-4BE, UCS-4LE UTF-16, UTF-16BE, UTF-16LE UTF-32, UTF-32BE, UTF-32LE UTF-7 C99, JAVA Therefore, I don't understand the statement that libiconv doesn't support C99 or that it isn't, somehow, a character set.
[Bug c/67224] UTF-8 support for identifier names in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 --- Comment #15 from Eric ejolson at unr dot edu --- Created attachment 36206 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36206action=edit Improved UTF-8 identifier patch Improved patch to support UTF-8 identifiers. This version by default does no translation unless -finput-charset=XXX is specified where XXX is something other than C99 and should not affect EBCDIC hosts.
[Bug c/67224] UTF-8 support for identifier names in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 --- Comment #14 from Eric ejolson at unr dot edu --- While there may not be current demand for gcc to accept UTF-8 identifiers, the fact that clang and Visual Studio support this C99 feature means source code using Greek and accented characters in variable names is likely to become more prevalent over time. I have done a little testing to check by default whether string literals can contain arbitrary 8-bit data. This is used, for example, in legacy code which directly includes graphics characters from CP437. The original preprocessor specifies UTF-8 as the default input character set and UTF-8 as the internal character set. Then, if the internal and working character sets are identical no translation is done and arbitrary 8-bit data is passed through cleanly. A slight modification to my patch needs to be made to retain the same behavior. In particular, the patch now specifies both the internal and default input character sets to be C99 so no translation is done by default. The improved patch also includes consideration of EBCDIC hosts. As iconv was installed on every GNU/Linux system I've tried, I'm not sure what is wrong with using the C99 mode present in newer releases. This achieves exactly the suggested result of converting all UTF-8 input to UCNs in the preprocessor while directly allowing other potentially useful conversions. Perhaps the configure script should be modified to check for a compatibile version of iconv and if one is not found resort to a manual conversion. Testing is still underway. After the standard regression tests are finished I will create new tests utf8id-.* which will be versions of the uncid-.* tests for native utf-8 files. I will also include a new test for arbitrary 8-bit string literals, to verify further compatibility.
[Bug c/67224] UTF-8 support for identifier names in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 --- Comment #16 from Eric ejolson at unr dot edu --- With my second patch the command line must now include the options -finput-charset=UTF-8 -fextended-identifiers -fexec-charset=UTF-8 or otherwise C99 will also be used for the default execution character set. A better approach to maintain nearly 8-bit clean string literals by default might result from leaving the default input and execution characters sets as UTF-8 and setting the internal character set to C99 only when -fextended-identifiers is selected. Sorry for too many comments. I'll post a new patch when everything is ready and has been tested.
[Bug c/67224] UTF-8 support for identifier names in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224
--- Comment #18 from Eric ejolson at unr dot edu ---
Thanks Joseph for the clarification about the two different versions of iconv.
I was admittedly confused about this until moments ago. Anyway, I just
discovered that libiconv doesn't support conversions to and from the IBM1047
EBCDIC character set and this causes some of the regression tests to fail.
Coupled with the fact that C99 isn't supported in the glibc version of iconv
this creates a little problem with my patch.
You mention a bigger problem which I had not thought about: the C++ semantics
of raw strings. Processing UCNs in C++ code apparently requires surprisingly
deep syntactic analysis. Raw literals seem to appear in the gnu99 and gnu11
extensions to C as well.
Amusingly, if I understand the C++ specifications
www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf
trigraphs are supposed to be interpreted before any other processing takes
place. However, the simple code
#include stdio.h
int main(){
char p1[]=??/u00E4;
char p2[]=R(??/u00E4);
char p3[]=R(\u00E4);
printf(%s or %s or %s\n,p1,p2,p3);
return 0;
}
compiled with
$ g++ -std=c++11 pp.c
produces output
รค or ??/u00E4 or \u00E4
which illustrates that g++ does not process trigraphs inside raw string
literals. Admittedly I'm looking at the draft standard, but I don't think this
is something which changed suddenly in the final draft. Clearly, my patch
makes a further mess of raw string literals in gcc. My first reaction is that
raw string literals were not well thought out, but I suppose bad standards are
sometimes better than no standards. At anyrate, there appears no easy way of
supporting both UTF-8 identifiers and raw literal strings.
My plan for now is to take a break and keep my UTF-8 identifier support as a
one-line patch reliant on libiconv which breaks EBCDIC encodings and raw string
literals.
[Bug c/67224] UTF-8 support for identifier names in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 --- Comment #7 from Eric ejolson at unr dot edu --- Please look at the Raspberry Pi forum post linked in the original report for more information about testing this patch. As the text describes there, the command line options -finput-charset=UTF-8 -fextended-identifiers are both needed in order to compile a UTF-8 input file containing unicode identifiers. I have included a small test program as another attachment. Searching on UTF-8 Identifiers in GCC will turn up a number of people asking for this feature and additional example codes that use UTF-8 identifers. The document Unicode for the PCC C99 Compiler available at http://pcc.ludd.ltu.se/documentation/ also contains example UTF-8 C99 input files which can be used to test the compiler. The one-line patch submitted above has also been tested in the sense that the compiler still bootstraps and has no trouble compiling thousands of lines of standard ASCII C input. The patch inserts C99 in only one place as the uses of SOURCE_CHARSET are conflicted and changing them all to C99 doesn't yield a working solution. In particular, the C99 in _cpp_convert_input should not be considered the source character set appearing in the input files but rather an internal character set suitable for later parsing. As iconv is already a well debugged library, it would appear the risks of this patch are minor. Note however, the following problem: C99 is probably not the correct for EBCDIC hosts. In that case it might be possible to write UCNs using trigraphs of the form ??/u and ??/U, however, as the number of people wanting to compile C source files with identifiers encoded using UTF-EBCDIC is likely zero, the easiest solution going forward is to modify the patch so it only applies to non-EBCDIC hosts. As there are already #ifdef's in the code to check for this, this does not add any new complexity to the code base.
[Bug c/67224] UTF-8 support for identifier names in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 --- Comment #8 from Eric ejolson at unr dot edu --- Created attachment 36196 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36196action=edit Test program with UTF-8 identifiers... Compile this test program using gcc \ -finput-charset=UTF-8 -fextended-identifiers \ -o circle circle.c to check whether gcc can handle UTF-8 identifiers.
[Bug c/67224] UTF-8 support for identifier names in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 --- Comment #20 from Eric ejolson at unr dot edu --- I've been looking at the code in lex_identifier as well as what goes on in forms_identifier_p and so forth. As some point each identifier needs to be stored in the symbol table using ht_lookup_with_hash. Proper functioning requires that UTF-8 and UCN representations of the same unicode characters are treated as the same symbol. Thus, there needs to be some point at which the identifiers are regularized to be either all UTF-8 or all UCN escaped ASCII. As gcc is working with UCNs right now, the obvious implementation allocates temporary memory to hold the UCN escaped ASCII version of an UTF-8 identifier and then frees it again after calling ht_lookup. Any comments would be appreciated.
[Bug c/67224] New: UTF-8 support for identifier names in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 Bug ID: 67224 Summary: UTF-8 support for identifier names in GCC Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ejolson at unr dot edu Target Milestone: --- Created attachment 36187 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36187action=edit One line patch to add C99 UTF-8 support in identifiers to gcc In response to FAQ What is the status of adding the UTF-8 support for identifier names in GCC? and the request Support for actual UTF-8 in identifiers is still pending (please contribute!) my observation is that UTF-8 in identifiers is easy to add to gcc by changing one line in the cpp preprocessor, provided a recent version of iconv is installed on the system. The patch is attached and has been tested for about 6 months. More information about this patch as well as unrelated information about getting cilkrts to work on ARM is available at https://www.raspberrypi.org/forums/viewtopic.php?p=802657
[Bug c/66326] Floating point exception with -mfpmath=387 and -fcilkplus.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66326 --- Comment #3 from Eric ejolson at unr dot edu --- GCC version 5.2 has come around and the bug is still here. In particular, compiling for 32-bit Intel or using -mfpmath=387 in 64-bit leads to immediate floating point exceptions. The fix was to comment out the define RESTORE_X86_FP_STATE at the top of libcilkrts/runtime/config/x86/os-unix-sysdep.c because the code in the restore and save routines is SSE only. Note that changing floating point rounding modes may not function as expected on 32-bit or with -mfpmath=387 set, however, otherwise this simple fix is effective. As already before, more information and this work-around is at https://software.intel.com/en-us/forums/topic/558825
[Bug c/67224] UTF-8 support for identifier names in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 --- Comment #1 from Eric ejolson at unr dot edu --- To check the installed version of iconv has C99 support type $ iconv --list | grep C99 C99 $ which means that iconv is recent enough.
[Bug c/81828] New: Cilkplus performance regression on ARM...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81828 Bug ID: 81828 Summary: Cilkplus performance regression on ARM... Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ejolson at unr dot edu Target Milestone: --- Created attachment 41979 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41979=edit Graph showing performance regression... Code for gcc version 7.1 using Cilkplus parallel programming extensions on ARM is running much slower than the same code with version 6.2. Details may by viewed graphically as http://fractal.math.unr.edu/~ejolson/bench/dotprod/gcc71-8.png which consistently shows a loss of performance using any combination of 1 to 8 cores on a Samsung/Nexell S5P6818 based SBC. More information and example code is available at https://www.raspberrypi.org/forums/viewtopic.php?p=711196#p1197225 My impression is that this regression affects almost all Cilkplus code on ARM and is possibly the result unaligned cactus stack additional overhead in switching tasks that was not present in the 6.2 version. It is likely that performance-based tests for ARM Cilkplus are needed to insure such regressions do not happen in the future. Note that the performance of serial code is not affected. The test code was compiled for 32-bit mode using options -fcilkplus -O3 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -ffast-math and run under identical circumstances in both cases.
[Bug middle-end/81828] Cilkplus performance regression on ARM...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81828 --- Comment #2 from Eric --- (In reply to Andrew Pinski from comment #1) > Note Cilk+ have been deprecated: > https://gcc.gnu.org/gcc-7/changes.html As 48-core ARM chips have just been announced by Qualcomm, now seems like the wrong time to be deprecating built-in support for parallel processing in gcc. I'd like to think that gcc is continuing to evolve to support new hardware and not turning into a retro-computing project. Presumably OpenMP is still supported and I know new versions of OpenMP support task barriers which suspend until child tasks are complete in a way similar to Cilkplus. Still, the syntax of Cilkplus is easier to read and the vector notation would be useful if it worked. While there doesn't appear to be much interest or expertise in maintaining Cilkplus, my opinion is that parallel programming techniques are essential to make efficient use of modern hardware and deprecating a convenient way of programming multi-core hardware at this point is a mistake. To this end, maybe it would be a good idea to figure out what is causing the slowdown in gcc version 7.1 ARM Cilkplus even though it is deprecated.
[Bug middle-end/81828] Cilkplus performance regression on ARM...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81828 --- Comment #3 from Eric --- (In reply to Andrew Pinski from comment #1) > Note Cilk+ have been deprecated: > https://gcc.gnu.org/gcc-7/changes.html As 48-core ARM chips have just been announced by Qualcomm, now seems like the wrong time to be deprecating built-in support for parallel processing in gcc. I'd like to think that gcc is continuing to evolve to support new hardware and not turning into a retro-computing project. Presumably OpenMP is still supported and I know new versions of OpenMP support task barriers which suspend until child tasks are complete in a way similar to Cilkplus. Still, the syntax of Cilkplus is easier to read and the vector notation would be useful if it worked. While there doesn't appear to be much interest or expertise in maintaining Cilkplus, my opinion is that parallel programming techniques are essential to make efficient use of modern hardware and deprecating a convenient way of programming multi-core hardware at this point is a mistake. To this end, maybe it would be a good idea to figure out what is causing the slowdown in gcc version 7.1 ARM Cilkplus even though it is deprecated.
