[Bug fortran/60661] DO CONCURRENT with MASK: Avoid using a temporary for the mask
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60661 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- Quote from the standard: http://mailman.j3-fortran.org/pipermail/j3/2014-March/007259.html The key paragraph is [176:22]: At the completion of the execution of the DO statement, the execution cycle begins. Figuring out the list of index values is part of the execution of the DO CONCURRENT statement [176:20-21].
[Bug ipa/60315] [4.8/4.9 Regression] template constructor switch optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315 --- Comment #17 from rguenther at suse dot de rguenther at suse dot de --- On March 26, 2014 10:58:18 PM CET, hubicka at ucw dot cz gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315 --- Comment #16 from Jan Hubicka hubicka at ucw dot cz --- forwprop would do that, but the enum is unsigned int while the switch value is int and thus simplify_gimple_switch bails out because the conversion is not value-preserving. So the frontend would need to be changed here or we need to complicate the transform by not looking at the type of the existing switch argument but instead by looking at the actual switch label values to see if their value would be preserved. But yes, that enum - int conversion asked for by the C++ standard seems to be common that this should be worth the trouble. Yep, it seems that the complicate transform is actually the most generic thing to do. (we won't need to modify all FE's and we will likely get more simplifications done) Shall I try to dig into it or you know how to do that better? I've posted a patch but it causes some regressions I need to investigate.
[Bug other/60681] New: Libbacktrace library doesn't work with QEMU in application mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60681 Bug ID: 60681 Summary: Libbacktrace library doesn't work with QEMU in application mode Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: chefmax at gcc dot gnu.org CC: v.garbuzov at samsung dot com, y.gribov at samsung dot com The libbacktrace library doesn't work well with QEMU in application mode. $ arm-linux-gnueabi-gcc -fsanitize=address -g gcc/testsuite/c-c++-common/asan/null-deref-1.c $ qemu-arm -cpu cortex-a15 -L /home/max/install/gcc-upstream-arm/arm-linux-gnueabi/sys-root/ -R 0 -E LD_LIBRARY_PATH=/home/max/install/gcc-upstream-arm/arm-linux-gnueabi/lib/ ./a.out ... #0 0x873f (/home/max/build/gcc-upstream-arm/a.out+0x873f) #1 0x876f (/home/max/build/gcc-upstream-arm/a.out+0x876f) #2 0x40ddb507 (/lib/libc.so.6+0x18507) When running the same binary on the target board, libbacktrace works well: -sh-4.1$ ./a.out ... #0 0x873f in NullDeref /home/m.ostapenko/null-deref-1.c:10 #1 0x876f in main /home/m.ostapenko/null-deref-1.c:15 #2 0xb6855507 in __libc_start_main /home/max/build.arm.cortex-a15/sources/glibc/libc/csu/libc-start.c:269 After investigation I discovered that libbacktrace scans /proc/self/exe to init symbolizer and in QEMU case it finds information about qemu-arm binary itself, not a.out. Is it a real bug or we should leave this as it is now? Perhaps I should report this to QEMU developers?
[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- This fixes this for me, based on: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/BABIDBHE.html If gas accepts some other value beyond those, the conditions can be tweaked of course, or it could be solved through more tight predicates and/or more correct/tight constraints (don't see how 0-32 or any power of 2 applies here, plus the ICE is that const_int_operand + no specific condition allowed combine to match garbage insn and once you match it with a wrong number, when the operand doesn't have a register possibility, there is no way to reload it). Can somebody please test this (together with the testcase, dunno if -march=armv7-a is tested often enough that the testcase could be just added to gcc.c-torture/compile/pr60657.c or if you really want to add the -march=armv7-a option explicitly). I'd also think that it would be worthwhile to look at all arm insns with const_int_operand and constraint that doesn't accept all CONST_INT values and check if it shouldn't be tightened. --- gcc/config/arm/arm.md.jj2014-01-03 11:41:20.0 +0100 +++ gcc/config/arm/arm.md2014-03-27 08:53:48.267277083 +0100 @@ -4581,7 +4581,9 @@ (define_insn *extv_reg (sign_extract:SI (match_operand:SI 1 s_register_operand r) (match_operand:SI 2 const_int_operand M) (match_operand:SI 3 const_int_operand M)))] - arm_arch_thumb2 + arm_arch_thumb2 +IN_RANGE (INTVAL (operands[3]), 0, 31) +IN_RANGE (INTVAL (operands[2]), 1, 32 - INTVAL (operands[3])) sbfx%?\t%0, %1, %3, %2 [(set_attr length 4) (set_attr predicable yes) @@ -4594,7 +4596,9 @@ (define_insn extzv_t2 (zero_extract:SI (match_operand:SI 1 s_register_operand r) (match_operand:SI 2 const_int_operand M) (match_operand:SI 3 const_int_operand M)))] - arm_arch_thumb2 + arm_arch_thumb2 +IN_RANGE (INTVAL (operands[3]), 0, 31) +IN_RANGE (INTVAL (operands[2]), 1, 32 - INTVAL (operands[3])) ubfx%?\t%0, %1, %3, %2 [(set_attr length 4) (set_attr predicable yes)
[Bug target/54083] FAIL: gcc.dg/torture/pr53922.c on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54083 --- Comment #21 from Dominique d'Humieres dominiq at lps dot ens.fr --- See this thread: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01222.html Please commit your patch, I'll adjust mine.
[Bug tree-optimization/57169] fully unrolled matrix multiplication not vectorized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57169 Ilya Palachev iliyapalachev at gmail dot com changed: What|Removed |Added CC||iliyapalachev at gmail dot com --- Comment #2 from Ilya Palachev iliyapalachev at gmail dot com --- (In reply to Richard Biener from comment #1) This is because basic-block SLP does not support vectorizing reductions. At page http://gcc.gnu.org/wiki/VectorizationTasks it is written that the generalization of reduction support (http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00172.html) can help to fix this PR25621 Has this bug the same reason as the bug discussed in PR25621 ?
[Bug middle-end/60682] New: [4.9 Regression][OpenMP] ICE on an assignment of local variable inside SIMD loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60682
Bug ID: 60682
Summary: [4.9 Regression][OpenMP] ICE on an assignment of local
variable inside SIMD loop
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: izamyatin at gmail dot com
Seems r207629 (fix for PR59984) introduces given issue.
Test is
class V3
{
public:
float v[1];
V3() {}
V3(const V3 x)
{
v[0] = x.v[0];
}
};
struct CCC
{
V3 a[16];
};
void foo(int num, CCC cc)
{
#pragma omp simd
for(int i = 0; i num; ++i)
{
V3 v3;
cc.a[i] = v3;
}
}
compilation flags: -O1 -fopenmp
ICE:
internal compiler error: in create_tmp_var, at gimple-expr.c:506
cc.a[i] = v3;
^
0x97ab03 create_tmp_var(tree_node*, char const*)
Note that v3's privatization makes ICE disappear.
[Bug target/60580] aarch64 generates wrong code for __attribute__ ((optimize(no-omit-frame-pointer)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60580 mshawcroft at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from mshawcroft at gcc dot gnu.org --- Patch applied to trunk r208862
[Bug c++/60683] New: confused by earlier errors, bailing out on incorrect std::initializer_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60683
Bug ID: 60683
Summary: confused by earlier errors, bailing out on incorrect
std::initializer_list
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
The following code leads to error confused by earlier errors, bailing out:
namespace std
{
templateclass T
struct initializer_list
{
};
}
struct X
{
explicit X(std::initializer_listint x);
};
int test()
{
X x = {10, 10, 10};
}
[Bug c++/60683] confused by earlier errors, bailing out on incorrect std::initializer_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60683
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-03-27
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
The code has undefined behaviour, you are not allowed to add declarations to
namespace std, especially not std::initializer_list which is very closely tied
to the compiler.
On trunk we get the following stack trace:
il.cc: In function ‘int test()’:
il.cc:16:23: error: converting to ‘X’ from initializer list would use explicit
constructor ‘X::X(std::initializer_listint)’
X x = {10, 10, 10};
^
il.cc:16:23: internal compiler error: Segmentation fault
0xb5682f crash_signal
/home/jwakely/src/gcc/gcc/gcc/toplev.c:337
0x553bd9 contains_struct_check
/home/jwakely/src/gcc/gcc/gcc/tree.h:2826
0x553bd9 convert_like_real
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:6129
0x555121 build_over_call
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:7010
0x5537ec convert_like_real
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:6032
0x55310c convert_like_real
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:6162
0x558196 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:9091
0x6a3617 ocp_convert(tree_node*, tree_node*, int, int, int)
/home/jwakely/src/gcc/gcc/gcc/cp/cvt.c:863
0x6b0c0d expand_default_init
/home/jwakely/src/gcc/gcc/gcc/cp/init.c:1618
0x6b0c0d expand_aggr_init_1
/home/jwakely/src/gcc/gcc/gcc/cp/init.c:1787
0x6b33aa build_aggr_init(tree_node*, tree_node*, int, int)
/home/jwakely/src/gcc/gcc/gcc/cp/init.c:1538
0x566e6c build_aggr_init_full_exprs
/home/jwakely/src/gcc/gcc/gcc/cp/decl.c:5591
0x566e6c check_initializer
/home/jwakely/src/gcc/gcc/gcc/cp/decl.c:5726
0x579d75 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/home/jwakely/src/gcc/gcc/gcc/cp/decl.c:6394
0x66bcff cp_parser_init_declarator
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:16858
0x66d5fe cp_parser_simple_declaration
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:11225
0x651c00 cp_parser_block_declaration
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:11106
0x652cc0 cp_parser_declaration_statement
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:10753
0x653327 cp_parser_statement
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:9486
0x6540ae cp_parser_statement_seq_opt
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:9764
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 other/60684] New: [4.9 Regression] cp-demangle.c:2149:13: error: ‘gnu_v3_unified_dtor’ undeclared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60684 Bug ID: 60684 Summary: [4.9 Regression] cp-demangle.c:2149:13: error: ‘gnu_v3_unified_dtor’ undeclared Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu gcc-4.6 -c -DHAVE_CONFIG_H -g -O2 -I/usr/include/libiberty -I. -I../../../gcc/li biberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -p edantic ../../../gcc/libiberty/cp-demangle.c -o cp-demangle.o yes checking for gcc-4.6 option to accept ISO C89... ../../../gcc/libiberty/cp-deman gle.c: In function ‘d_ctor_dtor_name’: ../../../gcc/libiberty/cp-demangle.c:2120:13: error: ‘gnu_v3_unified_ctor’ undec lared (first use in this function) ../../../gcc/libiberty/cp-demangle.c:2120:13: note: each undeclared identifier i s reported only once for each function it appears in ../../../gcc/libiberty/cp-demangle.c:2149:13: error: ‘gnu_v3_unified_dtor’ undec lared (first use in this function) Breaks build in stage1.
[Bug target/54083] FAIL: gcc.dg/torture/pr53922.c on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54083 --- Comment #22 from dave.anglin at bell dot net --- On 27-Mar-14, at 5:37 AM, dominiq at lps dot ens.fr wrote: Please commit your patch, I'll adjust mine. Done. -- John David Anglindave.ang...@bell.net
[Bug other/60684] [4.9 Regression] cp-demangle.c:2149:13: error: ‘gnu_v3_unified_dtor’ undeclared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60684 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from John David Anglin danglin at gcc dot gnu.org --- Don't know what caused it but it's not reproducible.
[Bug middle-end/60682] [4.9 Regression][OpenMP] ICE on an assignment of local variable inside SIMD loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60682 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Mar 27 13:18:52 2014 New Revision: 208864 URL: http://gcc.gnu.org/viewcvs?rev=208864root=gccview=rev Log: PR middle-end/60682 * omp-low.c (lower_omp_1): For gimple_clobber_p stmts, if they need regimplification, just drop them instead of calling gimple_regimplify_operands on them. * g++.dg/gomp/pr60682.C: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/pr60682.C Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/60682] [4.9 Regression][OpenMP] ICE on an assignment of local variable inside SIMD loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60682 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug c++/60685] New: exception not caught by enclosing catch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60685 Bug ID: 60685 Summary: exception not caught by enclosing catch Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jens.maurer at gmx dot net Created attachment 32465 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32465action=edit source code to reproduce the issue When compiling and linking the attached two files, I get a core dump, although I expect the catch(Ex): $ g++ -v -std=c++11 x.cc y.cc ... GNU C++ (GCC) version 4.8.2 (x86_64-unknown-linux-gnu) ... $ gdb ./a.out (gdb) run Starting program: /home/jmaurer/IDMS/svn/trunk/libs/tlfr/fundamental/./a.out terminate called after throwing an instance of 'Ex' Program received signal SIGABRT, Aborted. (gdb) bt #0 0x7722bf77 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x7722f5e8 in __GI_abort () at abort.c:90 #2 0x77b376e5 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #3 0x77b35856 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #4 0x77b34919 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #5 0x77b354ca in __gxx_personality_v0 () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #6 0x775cc7f3 in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1 #7 0x775ccb8b in _Unwind_RaiseException () from /lib/x86_64-linux-gnu/libgcc_s.so.1 #8 0x77b35aa1 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #9 0x0040094e in B::B() () #10 0x00400978 in A::f() () #11 0x00400923 in S::S(A) () #12 0x004008ba in main () $ ld --version GNU ld (GNU Binutils for Ubuntu) 2.23.52.20130913 This is also reproducible with $ ld --version GNU gold (GNU Binutils for Ubuntu 2.23.52.20130913) 1.11
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
--- Comment #53 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Dave, Rainer,
Could you test the following code?
[karma] f90/bug% cat fmt_en_1.f90
! { dg-do run }
! PR60128 Invalid outputs with EN descriptors
! Test case provided by Walt Brainerd.
program pr60128
use ISO_FORTRAN_ENV
implicit none
integer, parameter :: j(size(real_kinds)+4)=[REAL_KINDS, [4, 4, 4, 4]]
logical :: l_skip(4) = .false.
integer :: i
integer :: n_tst = 0, n_cnt = 0
character(len=20) :: s
open (unit = 10, file = 'fmt_en.res')
! Check that the default rounding mode is to nearest and to even on tie.
do i=1,size(real_kinds)
if (i == 1) then
write(s, '(2(1PE9.1))') real(9950.0,kind=j(1)),
real(9750.0,kind=j(1))
else if (i == 2) then
write(s, '(2(1PE9.1))') real(9950.0,kind=j(2)),
real(9750.0,kind=j(2))
else if (i == 3) then
write(s, '(2(1PE9.1))') real(9950.0,kind=j(3)),
real(9750.0,kind=j(3))
else if (i == 4) then
write(s, '(2(1PE9.1))') real(9950.0,kind=j(4)),
real(9750.0,kind=j(4))
end if
if (s /= ' 1.0E+04 9.8E+03') then
l_skip(i) = .true.
print ('Unsupported rounding for real(',i0,')'), j(i)
write (10, ('Unsupported rounding for real(',i0,')')) j(i)
end if
end do
call checkfmt((en15.0), 9500.0, 10.E+03)
call checkfmt((en15.1), 9950.0,10.0E+03)
call checkfmt((en15.0), -9500.0,-10.E+03)
call checkfmt((en15.1), -9950.0, -10.0E+03)
call checkfmt((en15.1), 987350., 987.4E+03)
call checkfmt((en15.2), 98765.,98.76E+03)
call checkfmt((en15.1), -987350., -987.4E+03)
call checkfmt((en15.2), -98765., -98.76E+03)
print *, n_tst, n_cnt
if (n_cnt /= 0) call abort
contains
subroutine checkfmt(fmt, x, cmp)
implicit none
integer :: i
character(len=*), intent(in) :: fmt
real, intent(in) :: x
character(len=*), intent(in) :: cmp
do i=1,size(real_kinds)
if (l_skip(i)) cycle
if (i == 1) then
write(s, fmt) real(x,kind=j(1))
else if (i == 2) then
write(s, fmt) real(x,kind=j(2))
else if (i == 3) then
write(s, fmt) real(x,kind=j(3))
else if (i == 4) then
write(s, fmt) real(x,kind=j(4))
end if
n_tst = n_tst + 1
if (s /= cmp) then
print (a,1x,a,' expected: ',1x,a), fmt, s, cmp
n_cnt = n_cnt + 1
end if
end do
end subroutine
end program
! { dg-final { scan-file-not fmt_en.res Unsupported rounding { xfail {
i?86-*-solaris2.9* hppa*-*-hpux11* } } } }
! { dg-final { cleanup-saved-temps } }
[Bug c++/60685] exception not caught by enclosing catch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60685
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-03-27
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
Reduced to a single file:
struct B {
B() { throw 1; }
};
B f() { return B(); }
struct S {
B b = f();
};
int main()
{
try {
S s;
} catch(int) {
}
}
In __cxa_throw we return from _Unwind_RaiseException and run:
82// Some sort of unwinding error. Note that terminate is a handler.
83__cxa_begin_catch (header-exc.unwindHeader);
84std::terminate ();
85 }
[Bug c++/60685] exception not caught by enclosing catch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60685 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- When an exception is thrown in an NSDMI we unwind the stack in _Unwind_RaiseException but reach: 101 if (code == _URC_END_OF_STACK) 102 /* Hit end of stack with no handler found. */ 103 return _URC_END_OF_STACK;
[Bug c++/60680] unqualified-id expected, gcc fails to diagnose and accepts invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60680 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-27 Ever confirmed|0 |1
[Bug c++/60686] message only declarations of constructors can be ‘explicit’ now conflicting with C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60686 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-27 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Confirmed, it should probably just say only declarations can be marked explicit
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
--- Comment #54 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE ---
--- Comment #53 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Dave, Rainer,
Could you test the following code?
Sure: passes on both i386-pc-solaris2.{9,10} with XFAILs on Solaris 9.
! { dg-final { scan-file-not fmt_en.res Unsupported rounding { xfail {
i?86-*-solaris2.9* hppa*-*-hpux11* } } } }
! { dg-final { cleanup-saved-temps } }
Somehow long lines are broken if you put code inline. Perhaps better
attach it to the PR?
Thanks.
Rainer
[Bug c/50347] unexpected -Wconversion error from gcc builtin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50347 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #55 from dave.anglin at bell dot net --- On 3/27/2014 11:00 AM, dominiq at lps dot ens.fr wrote: Could you test the following code? Here is output: Unsupported rounding for real(4) Unsupported rounding for real(8) (en15.2) 98.77E+03 expected:98.76E+03 (en15.2) -98.77E+03 expected: -98.76E+03 8 2 Program aborted. Backtrace: ** Something went wrong while running addr2line. ** ** Falling back to a simpler backtrace scheme. ** #1 c033b5bf FAIL: gfortran.dg/fmt_en_1.f90 -O0 execution test XPASS: gfortran.dg/fmt_en_1.f90 -O0 scan-file-not Unsupported rounding So, probably abort shouldn't be called when rounding isn't supported. I would change hpux11* to hpux*.
[Bug c/50347] unexpected -Wconversion error from gcc builtin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50347 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Thu Mar 27 15:59:07 2014 New Revision: 208870 URL: http://gcc.gnu.org/viewcvs?rev=208870root=gccview=rev Log: PR c/50347 * doc/extend.texi (ffs Builtins): Change unsigned types to signed types. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi
[Bug c++/60687] New: [4.8.0] Infinite loop compiling recursive templates indirectly by local class in function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60687 Bug ID: 60687 Summary: [4.8.0] Infinite loop compiling recursive templates indirectly by local class in function Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: FBergemann at web dot de [g++ 4.8.0 on Red Hat Linux 6.2 or Ubuntu Linux 12.04.3] the g++ compiler is in an endless loop and has to be killed for compiling main.cpp (attached next). Then i get following error trace: /opt/gcc-4.8.0/bin/g++ -O0 -g3 -Wall -c -fmessage-length=0 -std=c++11 -MMD -MP -MFmain.d -MTmain.d -o main.o ../main.cpp g++: internal compiler error: Terminated (program cc1plus) 0x40cba1 execute ../../gcc/gcc.c:2822 0x40cee4 do_spec_1 ../../gcc/gcc.c:4614 0x40f865 process_brace_body ../../gcc/gcc.c:5871 0x40f865 handle_braces ../../gcc/gcc.c:5785 0x40de07 do_spec_1 ../../gcc/gcc.c:5268 0x40f865 process_brace_body ../../gcc/gcc.c:5871 0x40f865 handle_braces ../../gcc/gcc.c:5785 0x40de07 do_spec_1 ../../gcc/gcc.c:5268 0x40daff do_spec_1 ../../gcc/gcc.c:5373 0x40f865 process_brace_body ../../gcc/gcc.c:5871 0x40f865 handle_braces ../../gcc/gcc.c:5785 0x40de07 do_spec_1 ../../gcc/gcc.c:5268 0x40f865 process_brace_body ../../gcc/gcc.c:5871 0x40f865 handle_braces ../../gcc/gcc.c:5785 0x40de07 do_spec_1 ../../gcc/gcc.c:5268 0x40f865 process_brace_body ../../gcc/gcc.c:5871 0x40f865 handle_braces ../../gcc/gcc.c:5785 0x40de07 do_spec_1 ../../gcc/gcc.c:5268 0x40f865 process_brace_body ../../gcc/gcc.c:5871 0x40f865 handle_braces ../../gcc/gcc.c:5785 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. make: *** [main.o] Error 4
[Bug c++/60687] [4.8.0] Infinite loop compiling recursive templates indirectly by local class in function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60687 --- Comment #1 from Frank Bergemann FBergemann at web dot de --- Created attachment 32466 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32466action=edit test program
[Bug bootstrap/60688] New: ICE in real_to_decimal_for_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60688
Bug ID: 60688
Summary: ICE in real_to_decimal_for_mode
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: rth at gcc dot gnu.org
Building stage1 libstdc++:
/home/rth/work/gcc/bld/./gcc/xgcc -shared-libgcc -B/home/rth/work/gcc/bld/./gcc
-nostdinc++
-L/home/rth/work/gcc/bld/armv7l-unknown-linux-gnueabihf/libstdc++-v3/src
-L/home/rth/work/gcc/bld/armv7l-unknown-linux-gnueabihf/libstdc++-v3/src/.libs
-L/home/rth/work/gcc/bld/armv7l-unknown-linux-gnueabihf/libstdc++-v3/libsupc++/.libs
-B/home/rth/work/gcc/run/armv7l-unknown-linux-gnueabihf/bin/
-B/home/rth/work/gcc/run/armv7l-unknown-linux-gnueabihf/lib/ -isystem
/home/rth/work/gcc/run/armv7l-unknown-linux-gnueabihf/include -isystem
/home/rth/work/gcc/run/armv7l-unknown-linux-gnueabihf/sys-include
-I/home/rth/work/gcc/git-master/libstdc++-v3/../libgcc
-I/home/rth/work/gcc/bld/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/armv7l-unknown-linux-gnueabihf
-I/home/rth/work/gcc/bld/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include
-I/home/rth/work/gcc/git-master/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=ios.lo -g -O2 -D_GNU_SOURCE -c
../../../../../git-master/libstdc++-v3/src/c++98/ios.cc -fPIC -DPIC
-D_GLIBCXX_SHARED -o ios.o
In file included from
../../../../../git-master/libstdc++-v3/src/c++98/ios.cc:30:0:
/home/rth/work/gcc/bld/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/limits:1558:7:
internal compiler error: in real_to_decimal_for_mode, at real.c:1799
min() _GLIBCXX_USE_NOEXCEPT { return __FLT_MIN__; }
^
0x9c43af real_to_decimal_for_mode(char*, real_value const*, unsigned int,
unsigned int, int, machine_mode)
../../git-master/gcc/real.c:1799
0x4bec7f lazy_hex_fp_value
../../git-master/gcc/c-family/c-cppbuiltin.c:1149
(gdb) where
#0 fancy_abort (file=0x13d11d8 ../../git-master/gcc/real.c, line=1799,
function=0x13d1740 real_to_decimal_for_mode(char*, real_value const*,
unsigned int, unsigned int, int, machine_mode)::__FUNCTION__
real_to_decimal_for_mode) at ../../git-master/gcc/diagnostic.c:1190
#1 0x009c43b0 in real_to_decimal_for_mode (
str=0x7effeae4 1.1754943508222875e-38, r_orig=0x7effec24, buf_size=64,
digits=0, crop_trailing_zeros=0, mode=SFmode)
at ../../git-master/gcc/real.c:1799
#2 0x004bec80 in lazy_hex_fp_value (pfile=0x17b7bc0, node=0x76d9cb38)
at ../../git-master/gcc/c-family/c-cppbuiltin.c:1149
#3 0x013140c0 in enter_macro_context (pfile=0x17b7bc0, node=0x76d9cb38,
result=0x17e7790, location=4858974) at ../../git-master/libcpp/macro.c:1052
#4 0x013166bc in cpp_get_token_1 (pfile=0x17b7bc0, location=0x7effeda4)
at ../../git-master/libcpp/macro.c:2439
#5 0x01316878 in cpp_get_token_with_location (pfile=0x17b7bc0, loc=0x7effeda4)
at ../../git-master/libcpp/macro.c:2541
#6 0x004c895c in c_lex_with_flags (value=0x7effeda8, loc=0x7effeda4,
cpp_flags=0x7effed9e \001, lex_flags=2)
at ../../git-master/gcc/c-family/c-lex.c:302
#7 0x002d9ce4 in cp_lexer_get_preprocessor_token (lexer=0x76da4768,
token=0x7effed9c) at ../../git-master/gcc/cp/parser.c:761
#8 0x002d98c8 in cp_lexer_new_main () at ../../git-master/gcc/cp/parser.c:641
#9 0x002ddb20 in cp_parser_new () at ../../git-master/gcc/cp/parser.c:3407
#10 0x0031dca4 in c_parse_file () at ../../git-master/gcc/cp/parser.c:31650
#11 0x004d30a8 in c_common_parse_file ()
at ../../git-master/gcc/c-family/c-opts.c:1061
#12 0x00ab35e4 in compile_file () at ../../git-master/gcc/toplev.c:548
#13 0x00ab65e4 in do_compile () at ../../git-master/gcc/toplev.c:1914
#14 0x00ab67d0 in toplev_main (argc=59, argv=0x7effef84)
at ../../git-master/gcc/toplev.c:1990
#15 0x012ce4c0 in main (argc=59, argv=0x7effef84)
at ../../git-master/gcc/main.c:36
(gdb) up
#1 0x009c43b0 in real_to_decimal_for_mode (
str=0x7effeae4 1.1754943508222875e-38, r_orig=0x7effec24, buf_size=64,
digits=0, crop_trailing_zeros=0, mode=SFmode)
at ../../git-master/gcc/real.c:1799
1799 gcc_assert (real_identical (r, r_orig));
(gdb) p r
$1 = {cl = 0, decimal = 0, sign = 0, signalling = 0, canonical = 0, uexp = 0,
sig = {0, 0, 0, 0, 0}}
(gdb) p *r_orig
$3 = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0,
uexp = 67108739, sig = {0, 0, 0, 0, 2147483648}}
I don't have time to backtrack this further just now. Saving state.
[Bug target/60604] [4.9 Regression] GCC incorrectly compiles s_csinh function on MIPS32 (32bit fp)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60604 --- Comment #6 from Steve Ellcey sje at gcc dot gnu.org --- I think the underlying bug here is the code we generate for builtin_fabs. In emit-rtl.c (validate_subreg) I see this comment: /* Subregs involving floating point modes are not allowed to change size. Therefore (subreg:DI (reg:DF) 0) is fine, but (subreg:SI (reg:DF) 0) isn't. */ But on mips, builtin_fabs calls expand_absneg_bit and that generates this RTL: ;; _11 = ABS_EXPR _4; (insn 26 25 27 (set (subreg:SI (reg:DF 199 [ D.3267 ]) 0) (and:SI (subreg:SI (reg:DF 194 [ D.3267 ]) 0) (const_int 2147483647 [0x7fff]))) x.c:25 -1 (nil)) (insn 27 26 0 (set (subreg:SI (reg:DF 199 [ D.3267 ]) 4) (subreg:SI (reg:DF 194 [ D.3267 ]) 4)) x.c:25 -1 (nil)) Which would seem to violate the restrictions in the comment.
prefavour
e vase, so is the v
[Bug target/60606] [ARM] ICE with asm (mov ..., pc)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60606 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-27 CC||ramana at gcc dot gnu.org Summary|ICE [ARM] error: insn does |[ARM] ICE with asm (mov |not satisfy its constraints |..., pc) Ever confirmed|0 |1 --- Comment #5 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to D.Salikhov from comment #4) (In reply to Richard Earnshaw from comment #3) register unsigned long pc asm(pc); I think it's a mistake to permit this sort of construct. What does: a = pc; b = a+pc; generate for b? Is it exactly twice a (the compiler doesn't see pc changing, so is free to assume that it doesn't), just more than twice a (how much more?) or just less than twice a (different scheduling)? What happens if the user writes pc = 3; // ??? The point is that while it might be valid to use pc in assembly instructions, the constructs you get in high-level languages are essentially meaningless. Well, even if I use PC incorrectly (actually I don't), it shouldn't lead to ICE. At least, there should be a sensible error message from compiler but not internal error. True, the compiler shouldn't ICE, but writing an inline assembler statement of that form, to read the value of the PC is just broken. The value of PC you read may not be what you expect it to be and allowing such a form is just wrong. It would be just any old PC. In a function asm (mov ..., pc) will not give you the same result relative to other statements in the function all the time. From your program it appears as though you want to check Thumbness - is a static time answer not good enough ? You can get information that from pre-processor macros. Anyway, patches welcome if you want to fix it.
[Bug middle-end/60647] [4.9 Regression] ICE in visit_ref_for_mod_analysis, at ipa-prop.c:2112
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60647
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
Note the reduced testcase has implicit types, while that isn't necessary to
reproduce this:
struct _wincore
{
int width, height;
};
static void
foo (dpy, winInfo, offset)
void *dpy;
struct _wincore *winInfo;
int offset;
{
fn1 (winInfo-height);
}
static void
bar (dpy, winInfo, visrgn)
void *dpy;
int winInfo;
int *visrgn;
{
foo ((void *) 0, winInfo, 0);
fn2 (0, 0, visrgn);
}
void
baz (dpy, win, prop)
void *dpy;
int win;
int prop;
{
bar ((void *) 0, 0, (int *) 0);
}
ICEs in the same spot and:
struct _wincore
{
int width, height;
};
static void
foo (dpy, winInfo, offset)
void *dpy;
struct _wincore *winInfo;
int offset;
{
fn1 (winInfo-height);
}
static void
bar (dpy, winInfo, visrgn)
void *dpy;
int winInfo;
int *visrgn;
{
foo ((void *) 0, winInfo, 0);
fn2 (visrgn);
}
void
baz (dpy, win, prop)
void *dpy;
int win;
int prop;
{
bar ((void *) 0, 0, (int *) 0);
}
ICEs during expansion. And yes, I think IPA-SRA should give up in these cases.
Note even the original testcase looks wrong, there is:
typedef unsigned long XID;
typedef XID Window;
static Region
GetWindowRegion(dpy, winInfo, offset)
Display *dpy;
WinGeneric *winInfo;
int offset;
{
return MakeRegionFromRect(
offset ? winInfo-core.x : 0,
offset ? winInfo-core.y : 0,
winInfo-core.width,
winInfo-core.height
);
}
static void
SubtractWindowFromVisibleRegion(dpy, winInfo, visrgn)
Display *dpy;
Window winInfo;
Region visrgn;
{
Region winrgn = GetWindowRegion(dpy, winInfo, 1);
XSubtractRegion(visrgn, winrgn, visrgn);
XDestroyRegion(winrgn);
}
So, GetWindowRegion is called with unsigned long that is passed to a function
expecting a structure pointer.
[Bug libstdc++/60612] Throwing exception, catching and rethrowing (std::exception_ptr) in destructor leads to segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60612 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Thu Mar 27 18:07:25 2014 New Revision: 208871 URL: http://gcc.gnu.org/viewcvs?rev=208871root=gccview=rev Log: PR libstdc++/60612 * libsupc++/eh_ptr.cc: Assert __cxa_dependent_exception layout is compatible with __cxa_exception. * libsupc++/unwind-cxx.h (__cxa_dependent_exception): Add padding. Fix typos in comments. * testsuite/18_support/exception_ptr/60612-terminate.cc: New. * testsuite/18_support/exception_ptr/60612-unexpected.cc: New. Added: trunk/libstdc++-v3/testsuite/18_support/exception_ptr/60612-terminate.cc trunk/libstdc++-v3/testsuite/18_support/exception_ptr/60612-unexpected.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/eh_ptr.cc trunk/libstdc++-v3/libsupc++/unwind-cxx.h
[Bug libstdc++/60612] Throwing exception, catching and rethrowing (std::exception_ptr) in destructor leads to segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60612 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.8.3 |4.9.0 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed for 4.9.0
[Bug target/60604] [4.9 Regression] GCC incorrectly compiles s_csinh function on MIPS32 (32bit fp)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60604 --- Comment #7 from Steve Ellcey sje at gcc dot gnu.org --- I didn't notice that just before the emit-rtl.c (validate_subregs) comment that says: /* Subregs involving floating point modes are not allowed to change size. Therefore (subreg:DI (reg:DF) 0) is fine, but (subreg:SI (reg:DF) 0) isn't. */ Is another comment (and code) that has: /* ??? This should not be here. Temporarily continue to allow word_mode subregs of anything. The most common offender is (subreg:SI (reg:DF)). Generally, backends are doing something sketchy but it'll take time to fix them all. */ if (omode == word_mode) ; This is why we are creating the 'bad' subregs.
[Bug rtl-optimization/60650] [ARM] LRA ICE in assign_by_spills
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60650 --- Comment #4 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Thu Mar 27 18:49:44 2014 New Revision: 208876 URL: http://gcc.gnu.org/viewcvs?rev=208876root=gccview=rev Log: 2014-03-27 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/60650 * lra-asign.c (find_hard_regno_for, spill_for): Add parameter first_p. Use it. (find_spills_for): New. (assign_by_spills): Pass the new parameter to find_hard_regno_for. Spill all pseudos on the second iteration. 2014-03-27 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/60650 * gcc.target/arm/pr60650.c: New. Added: trunk/gcc/testsuite/gcc.target/arm/pr60650.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-assigns.c trunk/gcc/testsuite/ChangeLog
[Bug c++/60689] New: Bogus error with atomic::exchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60689
Bug ID: 60689
Summary: Bogus error with atomic::exchange
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roman at binarylife dot net
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux-gnu
$ cat test.cc
#include atomic
templateint N
struct X { char stuff[N]; };
templateint N
void test() {
XN x;
std::atomicXN a;
x = a;
a.exchange(x);
}
int main() {
test9();
return 0;
}
$ g++ -std=c++11 -O2 -l atomic test.cc
In file included from test.cc:1:0:
/home/abend/local/gcc-4.9/include/c++/4.9.0/atomic: In instantiation of ‘_Tp
std::atomic_Tp::exchange(_Tp, std::memory_order) [with _Tp = X9;
std::memory_order = std::memory_order]’:
test.cc:11:3: required from ‘void test() [with int N = 9]’
test.cc:15:11: required from here
/home/abend/local/gcc-4.9/include/c++/4.9.0/atomic:225:41: error: invalid
conversion from ‘X9*’ to ‘long unsigned int’ [-fpermissive]
__atomic_exchange(_M_i, __i, tmp, _m);
^
/home/abend/local/gcc-4.9/include/c++/4.9.0/atomic:225:41: error: cannot
convert ‘std::memory_order’ to ‘void*’ for argument ‘4’ to ‘void
__atomic_exchange(long unsigned int, volatile void*, void*, void*, int)’
$ g++ --version
g++ (GCC) 4.9.0 20140327 (experimental)
...
[Bug c++/60417] [DR 1518] Bogus error on C++03 aggregate initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60417
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org ---
Still a regression for aggregate-initialization of arrays:
struct A { explicit A(int = 0); };
int main()
{
A a[1] = { };
}
zzz.cc: In function ‘int main()’:
zzz.cc:5:14: error: converting to ‘A’ from initializer list would use explicit
constructor ‘A::A(int)’
A a[1] = { };
^
And similarly for array members that are list-initialized:
struct A { explicit A(int = 0); };
struct B { A a[1]; B() : a{} {} };
int main()
{
B b;
}
zz.cc: In constructor ‘B::B()’:
zz.cc:2:28: error: converting to ‘A’ from initializer list would use explicit
constructor ‘A::A(int)’
struct B { A a[1]; B() : a{} {} };
^
[Bug lto/60690] New: Chromium build error with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60690
Bug ID: 60690
Summary: Chromium build error with LTO
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Created attachment 32467
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32467action=edit
testcase
markus@x4 tmp % cat simple_idct.i
static int __attribute__ ((used)) wm1010;
void fn1 ()
{
__asm__( \nmovq 0, %%mm3 \nmovq wm1010(%%rip), %%mm4
\nmovq %%mm0, 0 \nmovq %%mm0,0 \nmovq %%mm0,0
\nmovq %%mm0,0 \n2:
\nmovq 0, %%mm0 \nmovq 0, %%mm1 \nmovq 0,
%%mm2 \nmovq 0, %%mm3 \nmovq %%mm0, %%mm4
\npsrad $20, %%mm2 \npsrad $20, %%mm5 \nmovq %%mm6,
%%mm2 \npsrad $20, %%mm5 \nmovq %%mm6, %%mm4
\npsrad $20, %%mm0 \npsrad $20, %%mm2 \npackssdw
%%mm7, %%mm7 \nmovd %%mm7,0 \npackssdw %%mm0,
%%mm2 \npsrad $20, %%mm5 \nmovq %%mm6, %%mm4
\nmovd %%mm6,0 \nmovd %%mm4,0 \nmovd %%mm4, %%eax
\norl %%eax, %%eax \njz 0
\nmovq 0, %%mm4 \npmaddwd %%mm0, %%mm5
\npsrad $11, %%mm7 \npsrad $11, %%mm4
\n# .p2align \n6: movq 0, %%mm1
\npsrad $20, %%mm6 \npsrad $20, %%mm2 \n9: \n
:);
}
markus@x4 tmp % gcc -flto -O2 -fPIC -shared dsputil_init.i simple_idct.i
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: /tmp/ccQnT34K.ltrans1.ltrans.o: requires dynamic R_X86_64_PC32 reloc
against 'wm1010' which may overflow at runtime; recompile with -fPIC
collect2: error: ld returned 1 exit status
(dsputil_init.i is just a unit to trigger LTO partitioning)
markus@x4 tmp % gcc -O2 -fPIC -shared dsputil_init.i simple_idct.i
markus@x4 tmp % gcc -flto -flto-partition=none -O2 -fPIC -shared dsputil_init.i
simple_idct.i
markus@x4 tmp %
[Bug c++/60691] New: Build fails in libstdc++ with --enable-sjlj-exceptions on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60691 Bug ID: 60691 Summary: Build fails in libstdc++ with --enable-sjlj-exceptions on ARM Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: fab...@ritter-vogt.de Created attachment 32468 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32468action=edit Assembly produced if gcc invoked manually I try to compile gcc with sjlj exceptions enabled, however, the build fails at libstdc++. It's probably a gcc bug but it triggers an assertion in gas as well. GCC command: /opt/nspire/Ndless/ndless-sdk/toolchain/build/./gcc/xgcc -shared-libgcc -B/opt/nspire/Ndless/ndless-sdk/toolchain/build/./gcc -nostdinc++ -L/opt/nspire/Ndless/ndless-sdk/toolchain/build/arm-none-eabi/libstdc++-v3/src -L/opt/nspire/Ndless/ndless-sdk/toolchain/build/arm-none-eabi/libstdc++-v3/src/.libs -B/opt/nspire/Ndless/ndless-sdk/toolchain/install/arm-none-eabi/bin/ -B/opt/nspire/Ndless/ndless-sdk/toolchain/install/arm-none-eabi/lib/ -isystem /opt/nspire/Ndless/ndless-sdk/toolchain/install/arm-none-eabi/include -isystem /opt/nspire/Ndless/ndless-sdk/toolchain/install/arm-none-eabi/sys-include -I/opt/nspire/Ndless/ndless-sdk/toolchain/gcc-4.8.2/libstdc++-v3/../libgcc -I/opt/nspire/Ndless/ndless-sdk/toolchain/build/arm-none-eabi/libstdc++-v3/include/arm-none-eabi -I/opt/nspire/Ndless/ndless-sdk/toolchain/build/arm-none-eabi/libstdc++-v3/include -I/opt/nspire/Ndless/ndless-sdk/toolchain/gcc-4.8.2/libstdc++-v3/libsupc++ -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=eh_alloc.lo -mcpu=arm926ej-s -fpic -mlong-calls -c ../../../../gcc-4.8.2/libstdc++-v3/libsupc++/eh_alloc.cc -o eh_alloc.o Output: /tmp/cc6EsAB0.s: Assembler messages: /tmp/cc6EsAB0.s:320: Error: missing .fnstart before unwinding directive /tmp/cc6EsAB0.s:320: Error: duplicate .personality directive /tmp/cc6EsAB0.s:321: Error: missing .fnstart before unwinding directive /tmp/cc6EsAB0.s:321: Internal error! Assertion failure in create_unwind_entry at ../../binutils-2.24/gas/config/tc-arm.c line 20915. Please report this bug. Sadly I can't give the commands gcc executes as this doesn't happen if I execute the command manually. Probably other environment vars set in the GCC Makefile. I attached the .s file gcc gives me with -s if I execute it manually, maybe it's helpful. GCC configure options: --target=arm-none-eabi --prefix=$PREFIX --enable-interwork --disable-multilib --enable-languages=c,c++ --enable-sjlj-exceptions --with-system-zlib --with-newlib --disable-shared --with-gnu-as --with-gnu-ld --with-float=soft --disable-werror binutils configure options: --target=arm-none-eabi --prefix=$PREFIX --enable-interwork --disable-multilib --with-system-zlib --with-gnu-as --with-gnu-ld --disable-nls --with-float=soft --disable-werror I run make with CXXFLAGS_FOR_TARGET=-mcpu=arm926ej-s -fpic -mlong-calls
[Bug lto/60690] Chromium build error with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60690 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- May be related to PR57703.
[Bug testsuite/60672] FAIL: g++.dg/cpp1y/auto-fn25.C -std=gnu++1y (test for errors, line 7)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60672 --- Comment #1 from Michael Meissner meissner at gcc dot gnu.org --- Author: meissner Date: Thu Mar 27 20:07:16 2014 New Revision: 208877 URL: http://gcc.gnu.org/viewcvs?rev=208877root=gccview=rev Log: [gcc] 2014-03-27 Michael Meissner meiss...@linux.vnet.ibm.com * config/rs6000/constraints.md (wD constraint): New constraint to match the constant integer to get the top DImode/DFmode out of a vector in a VSX register. * config/rs6000/predicates.md (vsx_scalar_64bit): New predicate to match the constant integer to get the top DImode/DFmode out of a vector in a VSX register. * config/rs6000/rs6000-builtins.def (VBPERMQ): Add vbpermq builtin for ISA 2.07. * config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Add vbpermq builtins. * config/rs6000/rs6000.c (rs6000_debug_reg_global): If -mdebug=reg, print value of VECTOR_ELEMENT_SCALAR_64BIT. * config/rs6000/vsx.md (vsx_extract_mode, V2DI/V2DF modes): Optimize vec_extract of 64-bit values, where the value being extracted is in the top word, where we can use scalar instructions. Add direct move and store support. Combine the big endian/little endian vector select load support into a single insn. (vsx_extract_mode_internal1): Likewise. (vsx_extract_mode_internal2): Likewise. (vsx_extract_mode_load): Likewise. (vsx_extract_mode_store): Likewise. (vsx_extract_mode_zero): Delete, big and little endian insns are combined into vsx_extract_mode_load. (vsx_extract_mode_one_le): Likewise. * config/rs6000/rs6000.h (VECTOR_ELEMENT_SCALAR_64BIT): Macro to define the top 64-bit vector element. * doc/md.texi (PowerPC and IBM RS6000 constraints): Document wD constraint. PR target/60672 * config/rs6000/altivec.h (vec_xxsldwi): Add missing define to enable use of xxsldwi and xxpermdi builtin functions. (vec_xxpermdi): Likewise. * doc/extend.texi (PowerPC AltiVec/VSX Built-in Functions): Document use of vec_xxsldwi and vec_xxpermdi builtins. [gcc/testsuite] 2014-03-27 Michael Meissner meiss...@linux.vnet.ibm.com * gcc.target/powerpc/p8vector-vbpermq.c: New test to test the vbpermq builtin. * gcc.target/powerpc/vsx-extract-1.c: New test to test VSX vec_select optimizations. * gcc.target/powerpc/vsx-extract-2.c: Likewise. * gcc.target/powerpc/vsx-extract-3.c: Likewise. PR target/60672 * gcc.target/powerpc/pr60676.c: New file, make sure xxsldwi and xxpermdi builtins are supported. Added: trunk/gcc/testsuite/gcc.target/powerpc/p8vector-vbpermq.c trunk/gcc/testsuite/gcc.target/powerpc/pr60676.c trunk/gcc/testsuite/gcc.target/powerpc/vsx-extract-1.c trunk/gcc/testsuite/gcc.target/powerpc/vsx-extract-2.c trunk/gcc/testsuite/gcc.target/powerpc/vsx-extract-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/altivec.h trunk/gcc/config/rs6000/altivec.md trunk/gcc/config/rs6000/constraints.md trunk/gcc/config/rs6000/predicates.md trunk/gcc/config/rs6000/rs6000-builtin.def trunk/gcc/config/rs6000/rs6000-c.c trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.h trunk/gcc/config/rs6000/vsx.md trunk/gcc/doc/extend.texi trunk/gcc/doc/md.texi trunk/gcc/testsuite/ChangeLog
[Bug c++/60691] Build fails in libstdc++ with --enable-sjlj-exceptions on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60691 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Why are you trying to compile with SJLJ exceptions? The unwinding tables on arm are part of the EABI.
[Bug c++/60689] Bogus error with atomic::exchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60689
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-03-27
CC||rth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
#ifndef N
#define N 9
#endif
struct S { char a[N]; };
int main()
{
S a, b, c;
__atomic_exchange(a, b, c, __ATOMIC_SEQ_CST);
}
$ g++ -std=c++11 aa.cc -DN=8
$ g++ -std=c++11 aa.cc
aa.cc: In function ‘int main()’:
aa.cc:10:49: error: invalid conversion from ‘S*’ to ‘long unsigned int’
[-fpermissive]
__atomic_exchange(a, b, c, __ATOMIC_SEQ_CST);
^
aa.cc:10:49: error: invalid conversion from ‘int’ to ‘void*’ [-fpermissive]
aa.cc:10:49: error: too few arguments to function ‘void __atomic_exchange(long
unsigned int, volatile void*, void*, void*, int)’
built-in: note: declared here
[Bug c++/60689] Bogus error with atomic::exchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60689 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- when the object is bigger than the wordsize the generic __atomic_exchange gets expanded incorrectly $ g++11 aa.cc -DN=4 -m32 $ g++11 aa.cc -DN=5 -m32 aa.cc: In function ‘int main()’: aa.cc:10:49: error: invalid conversion from ‘S*’ to ‘unsigned int’ [-fpermissive] __atomic_exchange(a, b, c, __ATOMIC_SEQ_CST); ^ aa.cc:10:49: error: invalid conversion from ‘int’ to ‘void*’ [-fpermissive] aa.cc:10:49: error: too few arguments to function ‘void __atomic_exchange(unsigned int, volatile void*, void*, void*, int)’ built-in: note: declared here
[Bug c++/60689] Bogus error with atomic::exchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60689 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 32469 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32469action=edit gcc49-pr60689.patch Untested fix. 4.8 needs the same fix I think. In any case, no idea where to put a test for this. libstdc++-v3? libatomic? g++.dg and just make it compile test?
[Bug c++/60691] Build fails in libstdc++ with --enable-sjlj-exceptions on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60691 --- Comment #2 from Fabian Vogt fab...@ritter-vogt.de --- It crashes and produces weird results if linked to bFLT. If SJLJ isn't supported for ARM, why does --enable-sjlj-exceptions still exist?
[Bug c++/60691] Build fails in libstdc++ with --enable-sjlj-exceptions on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60691 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Fabian Vogt from comment #2) It crashes and produces weird results if linked to bFLT. Yes because EABI is an elf only abi, if it does not have a place for the unwind tables, then it is incompatible with the ABI :). If SJLJ isn't supported for ARM, why does --enable-sjlj-exceptions still exist? Because it is supported for some other targets, mainly windows based ones.
[Bug c++/60642] Unclear diagnostic with invalid use of abi_tag attribute on explicit instantiation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60642 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Keywords||ABI Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug testsuite/60672] FAIL: g++.dg/cpp1y/auto-fn25.C -std=gnu++1y (test for errors, line 7)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60672 --- Comment #2 from Michael Meissner meissner at gcc dot gnu.org --- Author: meissner Date: Thu Mar 27 21:15:16 2014 New Revision: 208878 URL: http://gcc.gnu.org/viewcvs?rev=208878root=gccview=rev Log: [gcc] 2014-03-27 Michael Meissner meiss...@linux.vnet.ibm.com Back port from main line: 2014-03-27 Michael Meissner meiss...@linux.vnet.ibm.com * config/rs6000/constraints.md (wD constraint): New constraint to match the constant integer to get the top DImode/DFmode out of a vector in a VSX register. * config/rs6000/predicates.md (vsx_scalar_64bit): New predicate to match the constant integer to get the top DImode/DFmode out of a vector in a VSX register. * config/rs6000/rs6000-builtins.def (VBPERMQ): Add vbpermq builtin for ISA 2.07. * config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Add vbpermq builtins. * config/rs6000/rs6000.c (rs6000_debug_reg_global): If -mdebug=reg, print value of VECTOR_ELEMENT_SCALAR_64BIT. * config/rs6000/vsx.md (vsx_extract_mode, V2DI/V2DF modes): Optimize vec_extract of 64-bit values, where the value being extracted is in the top word, where we can use scalar instructions. Add direct move and store support. Combine the big endian/little endian vector select load support into a single insn. (vsx_extract_mode_internal1): Likewise. (vsx_extract_mode_internal2): Likewise. (vsx_extract_mode_load): Likewise. (vsx_extract_mode_store): Likewise. (vsx_extract_mode_zero): Delete, big and little endian insns are combined into vsx_extract_mode_load. (vsx_extract_mode_one_le): Likewise. * config/rs6000/rs6000.h (VECTOR_ELEMENT_SCALAR_64BIT): Macro to define the top 64-bit vector element. * doc/md.texi (PowerPC and IBM RS6000 constraints): Document wD constraint. PR target/60672 * config/rs6000/altivec.h (vec_xxsldwi): Add missing define to enable use of xxsldwi and xxpermdi builtin functions. (vec_xxpermdi): Likewise. * doc/extend.texi (PowerPC AltiVec/VSX Built-in Functions): Document use of vec_xxsldwi and vec_xxpermdi builtins. [gcc/testsuite] 2014-03-27 Michael Meissner meiss...@linux.vnet.ibm.com Back port from main line: 2014-03-27 Michael Meissner meiss...@linux.vnet.ibm.com * gcc.target/powerpc/p8vector-vbpermq.c: New test to test the vbpermq builtin. * gcc.target/powerpc/vsx-extract-1.c: New test to test VSX vec_select optimizations. * gcc.target/powerpc/vsx-extract-2.c: Likewise. * gcc.target/powerpc/vsx-extract-3.c: Likewise. PR target/60672 * gcc.target/powerpc/pr60676.c: New file, make sure xxsldwi and xxpermdi builtins are supported. Added: branches/ibm/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/p8vector-vbpermq.c - copied unchanged from r208877, trunk/gcc/testsuite/gcc.target/powerpc/p8vector-vbpermq.c branches/ibm/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/pr60676.c - copied unchanged from r208877, trunk/gcc/testsuite/gcc.target/powerpc/pr60676.c branches/ibm/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/vsx-extract-1.c - copied unchanged from r208877, trunk/gcc/testsuite/gcc.target/powerpc/vsx-extract-1.c branches/ibm/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/vsx-extract-2.c - copied unchanged from r208877, trunk/gcc/testsuite/gcc.target/powerpc/vsx-extract-2.c branches/ibm/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/vsx-extract-3.c - copied unchanged from r208877, trunk/gcc/testsuite/gcc.target/powerpc/vsx-extract-3.c Modified: branches/ibm/gcc-4_8-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_8-branch/gcc/config/rs6000/altivec.h branches/ibm/gcc-4_8-branch/gcc/config/rs6000/altivec.md branches/ibm/gcc-4_8-branch/gcc/config/rs6000/constraints.md branches/ibm/gcc-4_8-branch/gcc/config/rs6000/predicates.md branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000-builtin.def branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000-c.c branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.c branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.h branches/ibm/gcc-4_8-branch/gcc/config/rs6000/vsx.md branches/ibm/gcc-4_8-branch/gcc/doc/extend.texi branches/ibm/gcc-4_8-branch/gcc/doc/md.texi branches/ibm/gcc-4_8-branch/gcc/testsuite/ChangeLog.ibm
[Bug fortran/58880] [4.9 Regression] [OOP] ICE on valid with FINAL function and type extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58880 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Thu Mar 27 21:17:43 2014 New Revision: 208879 URL: http://gcc.gnu.org/viewcvs?rev=208879root=gccview=rev Log: 2014-03-27 Tobias Burnus bur...@net-b.de PR fortran/58880 * trans-expr.c (gfc_conv_scalar_to_descriptor): Fix handling of nonpointers. 2014-03-27 Tobias Burnus bur...@net-b.de PR fortran/58880 * gfortran.dg/finalize_24.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/finalize_24.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug c++/60692] New: ICE with template template parameter (invalid code)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60692
Bug ID: 60692
Summary: ICE with template template parameter (invalid code)
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alexbolz at web dot de
The following (invalid) code results in an internal compiler error:
template class
struct T {};
template template class class T
struct X {};
template class... A
void fun(XA... const p)
{
}
int main()
{
fun(XT());
}
Using a single parameter instead of a parameter pack gives an error message:
error: type/value mismatch at argument 1
[GNU C++ (GCC) version 4.8.2 (x86_64-w64-mingw32)]
[Bug target/60676] Add vec_xxsldi, vec_xxpermdi to altivec.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60676 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Michael Meissner meissner at gcc dot gnu.org --- Fixed in subversion revision 208880.
[Bug bootstrap/60688] ICE in real_to_decimal_for_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60688 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Henderson rth at gcc dot gnu.org --- Bah! Buggy system libmpfr. No ICE with a fresh built copy.
[Bug fortran/60522] [4.7/4.8/4.9 Regression] WHERE construct causes an ICE in gfc_trans_where_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60522 --- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org --- Author: tkoenig Date: Thu Mar 27 22:21:35 2014 New Revision: 208883 URL: http://gcc.gnu.org/viewcvs?rev=208883root=gccview=rev Log: 2014-04-27 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/60522 * frontend-passes.c (cfe_code): Do not walk subtrees for WHERE. 2014-04-27 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/60522 * gfortran.dg/where_4.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/where_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #56 from Dominique d'Humieres dominiq at lps dot ens.fr --- So, probably abort shouldn't be called when rounding isn't supported. The problem is that the rounding to even on tie seems supported by hpux, but for 98765.0_16 or -98765.0_16: 6 successes out of 8 tests. Could you post the output of print '(3PE10.3)', 987350._4 print '(3PE10.3)', 987350._8 print '(3PE10.3)', 987350._16 print '(2PE10.3)', 98765.0_4 print '(2PE10.3)', 98765.0_8 print '(2PE10.3)', 98765.0_16 end My problem is to know if this is coming from the default printing libs or from the EN format in libfortran. On *-*-darwin* I get 987.4E+03 987.4E+03 987.4E+03 98.76E+03 98.76E+03 98.76E+03
[Bug debug/57519] DW_TAG_imported_declaration put in wrong class (base class instead of derived class)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57519 --- Comment #1 from Siva Chandra sivachandra at google dot com --- I sent out a patch for this PR: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01332.html
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #57 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Your results on Darwin match gfortran and ifort on x86-64.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #58 from dave.anglin at bell dot net --- On 27-Mar-14, at 6:31 PM, dominiq at lps dot ens.fr wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #56 from Dominique d'Humieres dominiq at lps dot ens.fr --- So, probably abort shouldn't be called when rounding isn't supported. The problem is that the rounding to even on tie seems supported by hpux, but for 98765.0_16 or -98765.0_16: 6 successes out of 8 tests. Could you post the output of print '(3PE10.3)', 987350._4 print '(3PE10.3)', 987350._8 print '(3PE10.3)', 987350._16 print '(2PE10.3)', 98765.0_4 print '(2PE10.3)', 98765.0_8 print '(2PE10.3)', 98765.0_16 end My problem is to know if this is coming from the default printing libs or from the EN format in libfortran. On *-*-darwin* I get 987.4E+03 987.4E+03 987.4E+03 98.76E+03 98.76E+03 98.76E+03 Results are on hppa2.0w-hp-hpux11.11: 987.3E+03 987.3E+03 987.4E+03 98.77E+03 98.77E+03 98.77E+03 -- John David Anglindave.ang...@bell.net
[Bug other/59545] Signed integer overflow issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59545 --- Comment #12 from ian at gcc dot gnu.org ian at gcc dot gnu.org --- Author: ian Date: Fri Mar 28 05:20:48 2014 New Revision: 20 URL: http://gcc.gnu.org/viewcvs?rev=20root=gccview=rev Log: PR other/59545 compiler: Fix bogus invalid static_cast to Unary_expression. Modified: trunk/gcc/go/gofrontend/expressions.cc
