[Bug other/91396] Link error when I use -fvtable-verify=std and -static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91396 --- Comment #9 from niva at niisi dot msk.ru --- I have built gcc-9.2.0 with --enable-vtable-verify for x86_64 under Fedora 22 with the correction https://gcc.gnu.org/viewcvs/gcc?view=revision=274386 Linking with -fvtable-verify and -static is now ok, thank you.
[Bug driver/91396] Link error when I use -fvtable-verify=std and -static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91396 niva at niisi dot msk.ru changed: What|Removed |Added Version|unknown |7.4.0 --- Comment #1 from niva at niisi dot msk.ru --- I've also noticed that small programs (tests) built with "vtable-verify enabled" gcc work slower than programs built with default gcc (even when the -fvtable-verify option is not used). This slowdown mostly concerns dynamically linked programs.
[Bug driver/91396] New: Link error when I use -fvtable-verify=std and -static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91396
Bug ID: 91396
Summary: Link error when I use -fvtable-verify=std and -static
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: niva at niisi dot msk.ru
Target Milestone: ---
I have built gcc-7.4.0 with --enable-vtable-verify for x86_64 under Fedora 27:
$HOME/src/gcc-7.4.0/configure --srcdir=$HOME/src/gcc-7.4.0 --verbose
--enable-vtable-verify --enable-languages=c,c++,fortran --enable-lto
--prefix=$HOME/local-gcc
When I run:
$ ~/local-gcc/bin/g++ -fvtable-verify=std -O2 -static t.C -o t.exe
the following error occurs:
~/local-gcc/lib/gcc/x86_64-pc-linux-gnu/7.4.0/vtv_end.o: In function
`__VLTprotect':
vtv_end.c:(.text.startup+0x0): multiple definition of `__VLTprotect'
~/local-gcc/lib/gcc/x86_64-pc-linux-gnu/7.4.0/../../../../lib64/libvtv.a(vtv_end.o):~/build/native-gcc/x86_64-pc-linux-gnu/libvtv/vtv_end.c:59:
first defined here
$ cat t.C
int main () {return 0;}
I have fixed the problem by deleting vtv_end.o from
~/local-gcc/lib64/libvtv.a but I'm not sure it's OK.
[Bug c/86895] New: Wrong description of -fvect-cost-model in common.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86895 Bug ID: 86895 Summary: Wrong description of -fvect-cost-model in common.opt Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: niva at niisi dot msk.ru Target Milestone: --- gcc --help -v prints the following: Specifies the cost model for vectorization. -fvect-cost-model=[unlimited|dynamic|cheap] Specifies the cost model for vectorization. I think that this results from the defect in gcc/common.opt: fvect-cost-model= Common Joined RejectNegative Enum(vect_cost_model) Var(flag_vect_cost_model) Init(VECT_COST_MODEL_DEFAULT) Optimization Specifies the cost model for vectorization. -fvect-cost-model=[unlimited|dynamic|cheap] Specifies the cost model for vectorization.
[Bug rtl-optimization/65862] [MIPS] IRA/LRA issue: integers spilled to floating-point registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862 --- Comment #17 from niva at niisi dot msk.ru --- (In reply to Wilco from comment #16) > (In reply to niva from comment #15) > > (In reply to Vladimir Makarov from comment #14) ... > If you implement the hook like I did on AArch64 then the problem is worked > around reasonably. : Do you mean the hook TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS? Actually we are using the mips target where this hook is already present. Is this enough?
[Bug rtl-optimization/65862] [MIPS] IRA/LRA issue: integers spilled to floating-point registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862 --- Comment #15 from niva at niisi dot msk.ru --- (In reply to Vladimir Makarov from comment #14) > Author: vmakarov > Date: Thu May 14 20:40:44 2015 > New Revision: 223202 > > URL: https://gcc.gnu.org/viewcvs?rev=223202=gcc=rev > Log: > 2015-05-14 Vladimir Makarov > > PR rtl-optimization/65862 > * target.def (ira_change_pseudo_allocno_class): New hook. > * targhooks.c (default_ira_change_pseudo_allocno_class): Default > value of the hook. > * targhooks.h (default_ira_change_pseudo_allocno_class): New > extern > * doc/tm.texi.in (TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS): Add the > hook. > * ira-costs.c (find_costs_and_classes): Call the hook and change > classes when it is necessary. > * doc/tm.texi: Update. > > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/doc/tm.texi > trunk/gcc/doc/tm.texi.in > trunk/gcc/ira-costs.c > trunk/gcc/target.def > trunk/gcc/targhooks.c > trunk/gcc/targhooks.h : Is it true that this patch fixes the problem? If so then why this bug is not marked as resolved? (I'm asking because I am greatly interested in this fix.)
[Bug c++/84612] Overload resolution of operator* fails for valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84612 --- Comment #3 from niva at niisi dot msk.ru --- Thank you very much!
[Bug c++/84612] New: Overload resolution of operator* fails for valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84612 Bug ID: 84612 Summary: Overload resolution of operator* fails for valarray Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: niva at niisi dot msk.ru Target Milestone: --- Created attachment 43527 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43527=edit source file We use gcc-7.3.0 configured with: /home/sap/gcc-infra-build/gcc/configure --prefix=/home/sap/local-gcc-7 --enable-languages=c,c++ --with-gmp=/home/sap/gcc-infra --with-mpfr=/home/sap/gcc-infra --with-mpc=/home/sap/gcc-infra Compilation of the attached file max.pass.cpp LANG=C ~/local-gcc-7/bin/g++ -std=c++11 -O0 -S max.pass.cpp results in max.pass.cpp: In function 'void cpp_main()': max.pass.cpp:38:19: error: no match for 'operator*' (operand types are 'std::valarray' and 'int') assert((v1*2).max() == 8.0); ~~^~ We expected that template valarray operator* (const valarray&, const T&); is used after conversion of 2 to double. Note that similar line of code (with *= instead of *): assert((v1*=2).max() == 8.0); is compiled successfully.
[Bug target/84260] New: gcc for mips produces an error when called with --help=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84260 Bug ID: 84260 Summary: gcc for mips produces an error when called with --help= Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: niva at niisi dot msk.ru Target Milestone: --- Gcc configured for a mips target: Target: mips64-niisi_ocrv_posix-elf Configured with: /home/sap/src/bt23j-gcc-7.3.1/configure --target=mips64-niisi_ocrv_posix-elf --prefix=/home/sap/local-bt23jj-7.3 --enable-threads=posix --disable-shared --enable-libgomp --enable-libatomic --enable-lto --enable-languages=c,c++ --program-transform-name='s,^,bt23jj-,' --disable-tls --enable-serial-configure --disable-__cxa_atexit --with-sysroot --with-gmp=/home/sap/gcc-infra --with-mpfr=/home/sap/gcc-infra --with-mpc=/home/sap/gcc-infra Thread model: posix gcc version 7.3.0 (GCC) produces the following error when called with --help=target (or other class): cc1: error: position-independent code requires ‘-mabicalls’ The error is issued in mips_option_override because it is called earlier than finish_options where the proper default value global_options.x_flag_pic=0 is set. When mips_option_override is called, global_options.x_flag_pic==-1. Probably mips_option_override should check the condition (flag_pic > 0).
[Bug rtl-optimization/65862] [MIPS] IRA/LRA issue: integers spilled to floating-point registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862 niva at niisi dot msk.ru changed: What|Removed |Added CC||niva at niisi dot msk.ru --- Comment #15 from niva at niisi dot msk.ru --- We are using MIPS target and we are extremely interested in the solution formulated in https://gcc.gnu.org/ml/gcc/2015-04/msg00239.html: "Ideally I'd like a guarantee that FP registers will never be used unless a floating point type is present in the source " In fact we'd like to have an option which disables use of FP registers and makes the compiler to issue an error if any FP operation occurs in the program.
[Bug target/80306] ICE in cfgexpand.c during cross-compilation for mips target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80306 niva at niisi dot msk.ru changed: What|Removed |Added Known to fail||4.7.4 --- Comment #1 from niva at niisi dot msk.ru --- The bug is also reproduced with gcc-7.0.0 20160510 (experimental)
[Bug target/80306] New: ICE in cfgexpand.c during cross-compilation for mips target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80306 Bug ID: 80306 Summary: ICE in cfgexpand.c during cross-compilation for mips target Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: niva at niisi dot msk.ru Target Milestone: --- Created attachment 41119 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41119=edit The source file at which the bug is reproduced. The cross-compiler mips64-none-elf-gcc configured as: /home/niva/src/gcc-6.3.0/configure --target=mips64-none-elf --enable-threads=no --disable-shared --enable-long-long --enable-c99 --enable-languages=c,c++ --enable-multilib --enable-symvers=gnu --disable-libmudflap --disable-libssp --disable-libgcc_eh --with-newlib --disable-libstdc++-v3 --with-dwarf2 --with-system-zlib --enable-checking=release --enable-generated-files-in-srcdir --verbose --prefix=/home/niva/local --enable-cpp ICE during compilation: LC_ALL=C mips64-none-elf-gcc-6.3.0 pr43300.c -O3 -mips64 -S -o pr43300.s pr43300.c: In function 'foo': pr43300.c:20:1: internal compiler error: in commit_one_edge_insertion, at cfgrtl.c:2072 } ^ 0x5faf45 commit_one_edge_insertion(edge_def*) /home/niva/src/gcc-6.3.0/gcc/cfgrtl.c:2072 0x5e8d63 execute /home/niva/src/gcc-6.3.0/gcc/cfgexpand.c:6408 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. The source file is a reduced version of gcc/testsuite/gcc.dg/pr43300.c (attached)
[Bug target/78860] ICE in compilation for MIPS with -mpaired-single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78860
--- Comment #3 from niva at niisi dot msk.ru ---
In trunk, git://gcc.gnu.org/git/gcc.git, the problem
disappears after commit 76825907d9b0e20cbb572d0d70248a4ed332fb29
But the changes in that commit are not applicable to gcc-4.7.4
which we are actually using.
In gcc-4.7.4 I've fixed the problem with the following patch:
diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index 1d72a05..e59d173 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -3030,3 +3030,7 @@ extern GTY(()) struct target_globals *mips16_globals;
with arguments ARGS. */
#define PMODE_INSN(NAME, ARGS) \
(Pmode == SImode ? NAME ## _si ARGS : NAME ## _di ARGS)
+
+/* This macro is introduced for fixing the gcc-4.7.4 #25 bug */
+#define TARGET_VECTOR_ADDRESSABLE 1
+
diff --git a/gcc/tree-ssa.c b/gcc/tree-ssa.c
index 08f908f..82b607f 100644
--- a/gcc/tree-ssa.c
+++ b/gcc/tree-ssa.c
@@ -1887,7 +1887,9 @@ maybe_optimize_var (tree var, bitmap addresses_taken,
bitmap not_reg_needs)
a non-register. Otherwise we are confused and forget to
add virtual operands for it. */
&& (!is_gimple_reg_type (TREE_TYPE (var))
+#ifndef TARGET_VECTOR_ADDRESSABLE
|| TREE_CODE (TREE_TYPE (var)) == VECTOR_TYPE
+#endif
|| TREE_CODE (TREE_TYPE (var)) == COMPLEX_TYPE
|| !bitmap_bit_p (not_reg_needs, DECL_UID (var
{
I think this not a very accurate solution. However it seems to work.
[Bug target/78860] ICE in compilation for MIPS with -mpaired-single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78860 niva at niisi dot msk.ru changed: What|Removed |Added Known to fail||6.3.0 --- Comment #2 from niva at niisi dot msk.ru --- The error was reproduced also with mips64-none-elf-gcc-6.3.0
[Bug target/78860] ICE in compilation for MIPS with -mpaired-single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78860 niva at niisi dot msk.ru changed: What|Removed |Added Target||MIPS CC||niva at niisi dot msk.ru --- Comment #1 from niva at niisi dot msk.ru --- The error was also reproduced with gcc-4.7.4 (similar configuration). The test is successfully compiled with gcc-7.0.0 (similar configuration).
[Bug target/78860] New: ICE in compilation for MIPS with -mpaired-single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78860
Bug ID: 78860
Summary: ICE in compilation for MIPS with -mpaired-single
Product: gcc
Version: 4.9.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: niva at niisi dot msk.ru
Target Milestone: ---
The source file is:
---
typedef unsigned char uint8_t;
typedef float v2sf __attribute__ ((vector_size (8)));
uint8_t _simple_testV2SF (v2sf *pv)
{
const v2sf val = *pv;
const uint8_t *val8 = (uint8_t *)
return val8[0];
}
The compiler used was gcc-4.9.4 configured for mips:
Target: mips64-none-elf
Configured with: /home/niva/src/gcc-4.9.4/configure --target=mips64-none-elf
--enable-threads=no --disable-shared --enable-long-long --enable-c99
--enable-languages=c,c++,fortran --enable-multilib --enable-symvers=gnu
--disable-libmudflap --disable-libssp --disable-libgcc_eh
--disable-libstdc++-v3 --disable-libgfortran --with-newlib --with-dwarf2
--with-system-zlib --without-cloog --enable-generated-files-in-srcdir --verbose
--prefix=/home/niva/local --enable-cpp
The following command line results in internal compiler error:
--
LANG=C mips64-none-elf-gcc -O1 -mips64 -mpaired-single -S tstV2SF.c 2>err
(The output is attached.)
[Bug middle-end/71693] [4.9/5 Regression] ICE: verify_gimple failed (type mismatch in shift expression, -O0, -O1, -O2, -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71693 --- Comment #11 from niva at niisi dot msk.ru --- Thank you very much for such a quick respond. I have adapted the patch to gcc-4.7.4, it works Ok.
[Bug middle-end/71693] ICE: verify_gimple failed (type mismatch in shift expression, -O0, -O1, -O2, -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71693 --- Comment #2 from niva at niisi dot msk.ru --- Is it possible to obtain a patch fixing this bug? (We are using a cross compiler based on 4.7.4, with substantial changes in backend).
[Bug middle-end/71693] New: ICE: verify_gimple failed (type mismatch in shift expression, -O0, -O1, -O2, -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71693 Bug ID: 71693 Summary: ICE: verify_gimple failed (type mismatch in shift expression, -O0, -O1, -O2, -O3) Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: niva at niisi dot msk.ru Target Milestone: --- Created attachment 38785 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38785=edit The source file to reproduce the problem. The error is reproduced with gcc 5.4.0 (and also with earlier versions: 5.3.1, 4.7.4). Target: x86_64-unknown-linux-gnu Configured with: /home/niva/src/gcc-5.4.0/configure --srcdir=/home/niva/src/gcc-5.4.0 --verbose --enable-checking --enable-languages=c --enable-lto --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local --with-isl=/usr/local --with-cloog=/usr/local --prefix=/home/niva/local-gcc54 Thread model: posix gcc version 5.4.0 (GCC) The command line is: gcc -O0 -S small.i The compiler output is: small.i: In function ‘init’: small.i:3:5: error: type mismatch in shift expression int init (signed int m_CL) ^ short unsigned int signed short short unsigned int D.1836 = D.1835 r>> 8; small.i:3:5: internal compiler error: verify_gimple failed 0xb475df verify_gimple_in_seq(gimple_statement_base*) /home/niva/src/gcc-5.4.0/gcc/tree-cfg.c:4739 0x9150ec gimplify_body(tree_node*, bool) /home/niva/src/gcc-5.4.0/gcc/gimplify.c:9329 0x915456 gimplify_function_tree(tree_node*) /home/niva/src/gcc-5.4.0/gcc/gimplify.c:9414 0x758117 cgraph_node::analyze() /home/niva/src/gcc-5.4.0/gcc/cgraphunit.c:634 0x75b1ed analyze_functions /home/niva/src/gcc-5.4.0/gcc/cgraphunit.c:1024 0x75bad5 symbol_table::finalize_compilation_unit() /home/niva/src/gcc-5.4.0/gcc/cgraphunit.c:2453 0x600dda c_write_global_declarations() /home/niva/src/gcc-5.4.0/gcc/c/c-decl.c:10857 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug tree-optimization/71647] New: aligned(x:32) in #pragma omp simd does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71647 Bug ID: 71647 Summary: aligned(x:32) in #pragma omp simd does not work Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: niva at niisi dot msk.ru Target Milestone: --- Created attachment 38759 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38759=edit The source file to reproduce the problem. I use gcc (GCC) 6.1.1 20160623. The command line is: gcc -O3 -S -mavx -fopt-info-vec-optimized -fopenmp-simd test1a.c When I use #pragma omp simd aligned(a,b:32) in the source file (see attachment), the compiler reports: test1a.c:9:8: note: loop vectorized test1a.c:9:8: note: loop peeled for vectorization to enhance alignment But when I use #pragma omp simd aligned(a,b:4*sizeof(double)), the alignment is taken into account, and the compiler output is: test1a.c:9:8: note: loop vectorized gcc 5.3.1 works ok in both cases.
[Bug tree-optimization/71060] New: Compiler reports "loop vectorized" but actually it was not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71060 Bug ID: 71060 Summary: Compiler reports "loop vectorized" but actually it was not Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: niva at niisi dot msk.ru Target Milestone: --- Created attachment 38467 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38467=edit The test case to reproduce the problem I compile the attached test8.c as follows: /usr/local/bin/gcc -O3 -S -mavx -fopt-info-vec-optimized -DSCOUT -Wall -Wextra -Werror -Wno-unknown-pragmas test8.c -o test8.s3 The output is: test8.c:24:2: note: loop vectorized test8.c:24:2: note: loop versioned for vectorization because of possible aliasing But the resulting assembler code contains no vector instructions. Other problems related to this test are: 1. The pointers in this function has the restrict specifier, so there should be no loop versioning. 2. I tried to use -ftree-loop-if-convert-stores but it did not help. Possibly this bug is the same as 65206.
[Bug preprocessor/16358] -Wno-system-headers hides warning caused by user header vs system header conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16358 --- Comment #11 from niva at niisi dot msk.ru --- (in reply to Martin Sebor in comment #10) Implementation of -Wmacro-redefined (with possibility of turning this warning to error) would solve the problem of our users.
[Bug preprocessor/16358] -Wno-system-headers hides warning caused by user header vs system header conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16358 niva at niisi dot msk.ru changed: What|Removed |Added CC||niva at niisi dot msk.ru --- Comment #9 from niva at niisi dot msk.ru --- ISO C treats redefinition of a macro as an error (6.10.3 2). IMHO it is reasonable to add a gcc/cpp option which provides treating redefinition of a macro as an error.
[Bug middle-end/64101] GCC considers that the erf math function does not set errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64101
--- Comment #2 from niva at niisi dot msk.ru ---
Please explain why erf is marked as 'const' and
does not use ATTR_MATHFN_FPROUNDING_ERRNO?
ISO C does not say that erf may not set errno.
And POSIX directly requires that erf, erff, erfl
set errno=ERANGE in case of underflow.
Here is another example:
#include stdio.h
#include errno.h
#include math.h
extern double res;
int main ()
{
errno = 0;
res = erf (-1.2553634935946022721708238314E-308);
printf (errno=%d, res=%g\n, errno, res);
return 0;
}
As a result of
mips64-none-elf-gcc -O1 -S tst2_erf.c -o tst2_erf.s
the following code is generated:
main:
...
addiu$sp,$sp,-40
sd$31,32($sp)
sw$0,%gp_rel(errno)($28)
jalerf
ldc1$f12,%gp_rel($LC0)($28)
sdc1$f0,%gp_rel(res)($28)
lui$4,%hi($LC1)# printf arg 0: format line
addiu$4,$4,%lo($LC1)
dmfc1$6,$f0# printf arg 2: res
jalprintf
move$5,$0#! printf arg 1: zero (must be errno)
move$2,$0
ld$31,32($sp)
j$31
addiu$sp,$sp,40
Zero ($0) is passed to printf instead of errno.
If -fno-builtin-printf is used the compiler generates
lw$5,%gp_rel(errno)($28)
instead of
move$5,$0
in the delay slot after jal printf.
В Птн, 28/11/2014 в 13:24 +, rguenth at gcc dot gnu.org пишет:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64101
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target||x86_64-*-*, mips64-none-elf
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-11-28
Ever confirmed|0 |1
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
I think the issue is that you don't use the result of erf() and the function
is marked as 'const' - thus does not use ATTR_MATHFN_FPROUNDING_ERRNO.
If you make 'res' global then it will work.
[Bug middle-end/64101] New: GCC considers that the erf math function does not set errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64101
Bug ID: 64101
Summary: GCC considers that the erf math function does not set
errno
Product: gcc
Version: 4.7.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: niva at niisi dot msk.ru
Created attachment 34131
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34131action=edit
The preprocessed source of the test program
We use a cross-conpiler configured as follows:
/home/niva/src/gcc-4.7.4/configure --target=mips64-none-elf --enable-threads=no
--disable-shared --enable-long-long --enable-c99 --enable-languages=c
--enable-multilib --enable-symvers=gnu --disable-libmudflap --disable-libssp
--disable-libgcc_eh --with-newlib --with-dwarf2 --with-system-zlib
--enable-generated-files-in-srcdir --verbose --prefix=/home/niva/local
--enable-cpp
The following program (the preprocessed source is attached)
#include assert.h
#include errno.h
#include math.h
int main ()
{
double res;
errno = 0;
res = erf (-1.2553634935946022721708238314E-308);
assert (errno == ERANGE);
return 0;
}
compiled as
mips64-none-elf-gcc -O1 tst_erf.c
produces an assertion though we use a POSIX-compliant math
library and the erf function sets errno = ERANGE
according to erf description in POSIX Programmer's Manual.
The test program works correctly (i.e. without the assertion)
if we compile it with -fno-builtin-erf.
Apparently GCC treats erf as a clean or pure function
(see gcc/builtins.def). IMHO this is not correct.
ISO C 99 (see 7.12.8.1) does not state directly whether erf
may set errno. But in 7.12.1 (6) it is stated that
If the result underflows, the function returns an
implementation-defined value whose magnitude is no greater than the smallest
normalized positive number in the specified type; if the integer expression
math_errhandling MATH_ERRNO is nonzero, whether errno acquires the
value ERANGE is implementation-defined; if the integer expression
math_errhandling MATH_ERREXCEPT is nonzero, whether the ‘‘underflow’’
floating-point exception is raised is implementation-defined.
In many Linux erf man pages we read that
These functions do not set errno.
But there is a bug report
https://sourceware.org/bugzilla/show_bug.cgi?id=6785 :
When erf() is given a subnormal argument, it raises an underflow exception.
However errno is not set. It should be set to ERANGE.
[Bug target/61616] Internal compiler error during reload in gcc-4.7.4 configured as a cross-compiler for a mips target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61616 niva at niisi dot msk.ru changed: What|Removed |Added Known to work||4.8.1 --- Comment #4 from niva at niisi dot msk.ru --- If anybody is interested - the following patch: svn diff -c190703 svn://gcc.gnu.org/svn/gcc/trunk/gcc/config/mips fixes the problem in gcc-4.7.3, gcc-4.7.4. Hunk 3 in mips.md (removal of 2 comment lines) fails but one can easily apply it manually.
[Bug target/61616] New: Internal compiler error during reload in gcc-4.7.4 configured as a cross-compiler for a mips target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61616
Bug ID: 61616
Summary: Internal compiler error during reload in gcc-4.7.4
configured as a cross-compiler for a mips target
Product: gcc
Version: 4.7.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: niva at niisi dot msk.ru
Created attachment 33008
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33008action=edit
The test file.
The cross-compiler gcc-4.7.4:
Configured with: /home/niva/src/gcc-4.7.4/configure --target=mips64-none-elf
--enable-threads=no --disable-shared --enable-long-long --enable-c99
--enable-languages=c --enable-multilib --enable-symvers=gnu
--disable-libmudflap --disable-libssp --disable-libgcc_eh --with-newlib
--with-dwarf2 --with-system-zlib --enable-generated-files-in-srcdir --verbose
--prefix=/home/niva/local --enable-cpp
The command line is:
mips64-none-elf-gcc-4.7.4 prfl.c -O3 -G0 -mips64 -mpaired-single -mabi=o64 -S
The error message:
prfl.c:42:1: error: unable to find a register to spill in class ‘GR_REGS’
prfl.c:42:1: error: this is the insn:
(insn 79 65 117 2 (set (reg:CCV2 360)
(unspec:CCV2 [
(unlt (reg:V2SF 34 $f2 [orig:306 MEM[(float[4] *)s1 + 8B] ]
[306])
(reg:V2SF 33 $f1 [orig:307 MEM[(float[4] *)s2 + 8B] ]
[307]))
] UNSPEC_SCC)) prfl.c:15 701 {sunlt_ps}
(nil))
prfl.c:42: confused by earlier errors, bailing out
The source file is attached. It was produced from
gcc-4.7.4/gcc/testsuite/gcc.c-torture/execute/ieee/pr50310.c
as a result of substitution of the float type instead of double.
[Bug target/61616] Internal compiler error during reload in gcc-4.7.4 configured as a cross-compiler for a mips target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61616 --- Comment #2 from niva at niisi dot msk.ru --- I've checked that gcc-4.8.1 works OK.
[Bug tree-optimization/60694] New: Gcc-4.2.4 hangs during compilation of the attached test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60694 Bug ID: 60694 Summary: Gcc-4.2.4 hangs during compilation of the attached test Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: niva at niisi dot msk.ru Created attachment 32471 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32471action=edit The test file. Native gcc-4.1.2 and gcc-4.2.4 hang during compilation of the attached test. It seems that some analysis pass in cc1 exponentially depends on the size of expressions being analyzed. When I reduce the number of basic blocks in the loop the compilation time varies as follows: $ time gcc -O3 -S smuladd16.c real0m0.431s user0m0.069s sys 0m0.014s $ time gcc -O3 -S smuladd24.c real0m7.041s user0m7.011s sys 0m0.013s $ time gcc -O3 -S smuladd28.c real1m50.267s user1m49.829s sys 0m0.109s I checked that later versions of gcc (4.4.6, 4.7.3, gcc-4.9.0) behave normally. But actually we are using a cross-compiler based on gcc-4.1.2 with plenty of changes and we cannot migrate to to a later gcc version quickly. Is there a patch which solves the problem?
[Bug c/58271] New: ICE in gcc for a MIPS target during compilation with -mpaired-single -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58271 Bug ID: 58271 Summary: ICE in gcc for a MIPS target during compilation with -mpaired-single -ftree-vectorize Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: niva at niisi dot msk.ru Created attachment 30721 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30721action=edit Preprocessed source file Running mips64-none-elf-gcc-4.8.0 mips-ps-7.i -O2 -mpaired-single -ftree-vectorize -S -o mips-ps-7.s produces the following ICE: mips-ps-7.i:1:0: warning: the 'mips3' architecture does not support paired-single instructions [enabled by default] extern float a[], b[], c[]; ^ mips-ps-7.i: In function 'foo': mips-ps-7.i:8:10: internal compiler error: in mips_allocate_fcc, at config/mips/mips.c:4675 a[i] = b[i] == c[i] + 1 ? b[i] : c[i]; ^ 0x860befc gen_vcondv2sfv2sf(rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*) /home/niva/src/gcc-4.8.0/gcc/config/mips/mips-ps-3d.md:722 0x836b1cd maybe_gen_insn(insn_code, unsigned int, expand_operand*) /home/niva/src/gcc-4.8.0/gcc/optabs.c:8222 0x836b3ae maybe_expand_insn(insn_code, unsigned int, expand_operand*) /home/niva/src/gcc-4.8.0/gcc/optabs.c:8242 0x836b3ee expand_insn(insn_code, unsigned int, expand_operand*) /home/niva/src/gcc-4.8.0/gcc/optabs.c:8273 0x836cb43 expand_vec_cond_expr(tree_node*, tree_node*, tree_node*, tree_node*, rtx_def*) /home/niva/src/gcc-4.8.0/gcc/optabs.c:6777 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. The cross-compiler was configured as follows: /home/niva/src/gcc-4.8.0/configure --target=mips64-none-elf --with-threads --without-headers --disable-libssp --enable-languages=c --prefix=/home/niva/local The preprocessed input file is attached. mips64-none-elf-gcc-4.7.3 also produces an ICE on this test. IMHO gcc should just disable -mpaired-single for the architectures which do not support it.
[Bug other/57918] New: Options -funroll-loops, -funroll-all-loops are described twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57918 Bug ID: 57918 Summary: Options -funroll-loops, -funroll-all-loops are described twice Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: niva at niisi dot msk.ru Options -funroll-loops, -funroll-all-loops are described twice in gcc info and man, and the descriptions are different. The second description of these options is in the final part of section Options That Control Optimization, which starts with the following words: The following options control optimizations that may improve performance, but are not enabled by any ‘-O’ options. This section includes experimental options that may produce broken code.
[Bug c/51548] It is impossible to provide translations of some gcc error messages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51548 --- Comment #1 from niva at niisi dot msk.ru 2011-12-14 09:20:37 UTC --- I have reworked c_parse_error in gcc-4.1.2 using c-common.c from gcc-3.4.6 as a sample. I have also used gcc/po/exgettext from gcc-4.5.1 in order to put messages passed from functions c_parse_require, c_parse_require_keyword, etc. (c-parser.c) to gcc.pot. This seems to solve the problem.
[Bug c/51548] New: It is impossible to provide translations of some gcc error messages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51548
Bug #: 51548
Summary: It is impossible to provide translations of some gcc
error messages
Classification: Unclassified
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: n...@niisi.msk.ru
The following gcc-4.1.2 error messages are not present in gcc.pot and thus
cannot be translated to other languages:
expected identifier or '(' before numeric constant
expected declaration specifiers or '...' before numeric constant
expected identifier or '(' before '}' token
expected declaration or statement at end of input
The reason is that error messages of this kind are issued by the
c_parse_error function (c-common.c) which forms them as catenation of its
input argument GMSGID and some additional string, e.g.:
message = catenate_messages (gmsgid, before numeric constant);
Even if each piece of the final message is presnt in gcc.pot the
whole message is not, so it is impossible to provide its translation.
[Bug middle-end/27226] [4.1 Regression] Compiler looses track of alignment for emit_block_move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226 niva at niisi dot msk.ru changed: What|Removed |Added CC||niva at niisi dot msk.ru --- Comment #19 from niva at niisi dot msk.ru 2011-06-15 12:46:58 UTC --- (In reply to comment #18) Fixed. I tried to checkout rev 117018 from svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch/ and build the compiler configured as follows: Configured with: /home/niva/tests/gcc-117018/configure --target=mips64-none-elf --enable-threads=no --disable-shared --enable-long-long --enable-c99 --enable-languages=c --enable-multilib --enable-symvers=gnu --disable-libmudflap --disable-libssp --disable-libgcc_eh --with-newlib --with-dwarf2 --with-system-zlib --enable-checking=release --enable-generated-files-in-srcdir --verbose --prefix=/home/niva/local --srcdir=/home/niva/tests/gcc-117018 --enable-cpp I've compiled the file memcpy-1.c: mips64-none-elf-gcc memcpy-1.c -O2 -fno-show-column -S -o memcpy-1.s117018 and got the assembler code with lbu instructions: lui $3,%hi($LC0+2) addiu $2,$3,%lo($LC0+2) lbu $5,%lo($LC0+2)($3) lbu $4,5($2) lbu $6,1($2) lbu $7,2($2) lbu $8,3($2) lbu $9,4($2) Eventually this bug was not fixed in gcc-4.1.2. But the compiler built in the same way from the trunk (r116641) generated the code with lhu instructions: lui $2,%hi($LC0+2) addiu $3,$2,%lo($LC0+2) lhu $5,%lo($LC0+2)($2) lhu $4,4($3) lhu $6,2($3) lui $2,%hi(c) addiu $3,$2,%lo(c) sh $4,4($3) sh $5,%lo(c)($2) j $31 sh $6,2($3) Probably some significant changes from trunk were not applied to gcc-4_1-branch.
