Re: Reg: Deletion of char ptr resulting in segmentation fault - Double to string convertion
Questions not related to GCC should be written to gcc-help@ - and not to gcc-bugs@. While bugs should be submitted via Bugzilla. emailstorbala wrote: double num = 23e45; buffer = new char[sizeof(double) + 1]; Here you allocate 9 bytes. sprintf(buffer, "%lf", num); And here you are writing the string "23000602806197963719130677638070272.00", which is longer than 8 characters. Tobias
[Bug ada/60703] New: System.Address not preelaborable on MIPS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60703 Bug ID: 60703 Summary: System.Address not preelaborable on MIPS Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: jnrhp24 at jorisvr dot nl Created attachment 32483 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32483&action=edit demonstrate bug (fails compilation on MIPS) == Summary == The type System.Address does not support preelaborable initialization on the MIPS architecture. As a result, compilation of a preelaborated package fails if it contains a variable of type System.Address. On other architectures (i386, amd64), the same source code compiles succesfully. I know very little about Ada, but I believe that the language specifies that System.Address must have pragma Preelaborable_Initialization in Ada2005. http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-7-7.html == Command and error message == joris@qmips:~/q gnatmake -gnat05 a.ads gcc-4.8 -c -gnat05 a.ads a.ads:7:05: private object not allowed in preelaborated unit a.ads:7:05: would be legal if pragma Preelaborable_Initialization given for "Address" at system.ads:64 gnatmake: "a.ads" compilation error Source file a.ads attached. Contents of line 7: "hello: System.Address" == Possible cause == Looking at the GCC source gcc-4.8.2/gcc/ada/system-linux-mips.ads I notice that it does not contain a pragma Preelaborable_Initialization while, for example, system-linux-x86.ads does contain that pragma. Although I only tested with GCC 4.8.2, a casual look in GCC SVN suggests that this problem still exists in the latest version. == Version == joris@qmips:~ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/mips-linux-gnu/4.8/lto-wrapper Target: mips-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.2-16' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --disable-libitm --disable-libsanitizer --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-mips/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-mips --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-mips --with-arch-directory=mips --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-multiarch --with-arch-32=mips2 --with-tune-32=mips32 --enable-targets=all --with-arch-64=mips3 --with-tune-64=mips64 --enable-checking=release --build=mips-linux-gnu --host=mips-linux-gnu --target=mips-linux-gnu Thread model: posix gcc version 4.8.2 (Debian 4.8.2-16)
[Bug fortran/60677] [4.7/4.8 Regression] FAIL: gfortran.dg/ichar_3.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60677 --- Comment #6 from Mikael Morin --- (In reply to Jakub Jelinek from comment #5) > Fixed on the trunk. From the referenced PR, seems like this bug now exists > also on 4.7/4.8. Yes, I'm going to fix 4.8 and 4.7 as well. Thanks for reminding me.
[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 #3 from Frank Bergemann --- Hi Yury, ok - thanks! I didn't know, that the default is that high (#1024 for c++11). So you can close it RESOLVED/WORKSFORME or INVALID. - many thanks! best regards, Frank
[Bug target/53090] suboptimal ivopt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53090
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #2 from bin.cheng ---
I tried the simple case, gcc doesn't work as expected on x86_64, but x86 is
fine.
I think there are several issues in ivopt causing this. The first issue is
IVOPT is too conservative when representing iv_use with iv_cand in type with
smaller precision.
Consider below use/cand:
use 0
address
in statement t_mp_11 = *_10;
at position *_10
type int *
base perm_9(D) + 4
step 4
base object (void *) perm_9(D)
related candidates
candidate 5 (important)
var_before ivtmp.8
var_after ivtmp.8
incremented before exit test
type unsigned int
base 1
step 1
candidate 6 (important)
original biv
type int
base 1
step 1
Use 0 is in type "int *" which has precision 64 on x86_64; cand is in type
"int" which has precision 32 on x86_64. In function get_computation_cost_at,
there is below code:
if (TYPE_PRECISION (utype) > TYPE_PRECISION (ctype))
{
/* We do not have a precision to express the values of use. */
return infinite_cost;
}
But this is too conservative because the loop runs for "(j-i)/2" times, which
can be expressed by the candidate. Even though the candidate has smaller type
than iv_use.
We should add some code checking loop niters against candidate's coverage here.
For example, the generated assembly changed into:
.L14:
movl(%rdx), %edi
movslq%eax, %rcx
addl$1, %eax
movl(%r15,%rcx,4), %esi
subq$4, %rdx
movl%edi, (%r15,%rcx,4)
movl%r8d, %ecx
subl%eax, %ecx
movl%esi, 4(%rdx)
cmpl%ecx, %eax
jl.L14
Now the original candidate is chosen as rcs for original induction variable
"i". Unfortunately there are some other issues which prevent IVOPT from
choosing right candidate for original induction variable "j".
I will keep looking into it see what's going on.
[Bug fortran/60677] [4.7/4.8 Regression] FAIL: gfortran.dg/ichar_3.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60677 --- Comment #7 from Mikael Morin --- Author: mikael Date: Sat Mar 29 11:07:57 2014 New Revision: 208932 URL: http://gcc.gnu.org/viewcvs?rev=208932&root=gcc&view=rev Log: fortran/ PR fortran/60677 * trans-intrinsic.c (gfc_conv_intrinsic_ichar): Enlarge argument list buffer. Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/trans-intrinsic.c
[Bug target/60704] New: ICE: in extract_constrain_insn_cached, at recog.c:2156 with -flive-range-shrinkage -march=amdfam10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60704
Bug ID: 60704
Summary: ICE: in extract_constrain_insn_cached, at recog.c:2156
with -flive-range-shrinkage -march=amdfam10
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Created attachment 32484
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32484&action=edit
reduced testcase
Compiler output:
$ gcc -flive-range-shrinkage -march=amdfam10 testcase.c
testcase.c: In function 'foo':
testcase.c:9:1: error: insn does not satisfy its constraints:
}
^
(insn 8 7 9 2 (set (reg:DF 84 [ D.1800 ])
(float:DF (reg:SI 83 [ D.1799 ]))) testcase.c:8 201 {*floatsidf2_sse}
(expr_list:REG_DEAD (reg:SI 83 [ D.1799 ])
(nil)))
testcase.c:9:1: internal compiler error: in extract_constrain_insn_cached, at
recog.c:2156
0xac1ad8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/mnt/svn/gcc-trunk/gcc/rtl-error.c:109
0xac1b44 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/mnt/svn/gcc-trunk/gcc/rtl-error.c:120
0xa7b70d extract_constrain_insn_cached(rtx_def*)
/mnt/svn/gcc-trunk/gcc/recog.c:2156
0xfdc4b7 insn_default_latency_amdfam10(rtx_def*)
/mnt/svn/gcc-trunk/gcc/config/i386/i386.md:23538
0x1348e57 insn_cost(rtx_def*)
/mnt/svn/gcc-trunk/gcc/haifa-sched.c:1401
0x134f9b9 dep_cost_1(_dep*, unsigned int)
/mnt/svn/gcc-trunk/gcc/haifa-sched.c:1454
0x135163b dep_cost
/mnt/svn/gcc-trunk/gcc/haifa-sched.c:1508
0x135163b priority
/mnt/svn/gcc-trunk/gcc/haifa-sched.c:1649
0x1351aba set_priorities(rtx_def*, rtx_def*)
/mnt/svn/gcc-trunk/gcc/haifa-sched.c:6530
0xada77c compute_priorities()
/mnt/svn/gcc-trunk/gcc/sched-rgn.c:2925
0xadd95f schedule_region
/mnt/svn/gcc-trunk/gcc/sched-rgn.c:3018
0xadd95f schedule_insns
/mnt/svn/gcc-trunk/gcc/sched-rgn.c:3416
0xade0eb schedule_insns
/mnt/svn/gcc-trunk/gcc/sched-rgn.c:3401
0xade0eb rest_of_handle_live_range_shrinkage
/mnt/svn/gcc-trunk/gcc/sched-rgn.c:3614
0xade0eb execute
/mnt/svn/gcc-trunk/gcc/sched-rgn.c:3704
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
$ gcc -v
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-20-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-20-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 4.9.0 20140328 (experimental) (GCC)
[Bug target/60648] [4.9 Regression] ICE (segmentation fault) in expand_binop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60648 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Sat Mar 29 11:10:25 2014 New Revision: 208933 URL: http://gcc.gnu.org/viewcvs?rev=208933&root=gcc&view=rev Log: PR target/60648 * g++.dg/pr60648.C: Move test to... * g++.dg/torture/pr60648.C: ... here. Run on all targets, remove dg-options, add for fpic targets dg-additional-options -fPIC. Added: trunk/gcc/testsuite/g++.dg/torture/pr60648.C - copied, changed from r208931, trunk/gcc/testsuite/g++.dg/pr60648.C Removed: trunk/gcc/testsuite/g++.dg/pr60648.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/60704] [4.9 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2156 with -flive-range-shrinkage -march=amdfam10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60704 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-29 CC||jakub at gcc dot gnu.org, ||rth at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|ICE: in |[4.9 Regression] ICE: in |extract_constrain_insn_cach |extract_constrain_insn_cach |ed, at recog.c:2156 with|ed, at recog.c:2156 with |-flive-range-shrinkage |-flive-range-shrinkage |-march=amdfam10 |-march=amdfam10 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r208587.
[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 #7 from Thomas Koenig --- Author: tkoenig Date: Sat Mar 29 11:51:17 2014 New Revision: 208934 URL: http://gcc.gnu.org/viewcvs?rev=208934&root=gcc&view=rev Log: 2014-04-29 Thomas Koenig PR fortran/60522 * frontend-passes.c (cfe_code): Do not walk subtrees for WHERE. 2014-04-29 Thomas Koenig PR fortran/60522 * gfortran.dg/where_4.f90: New test case. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/where_4.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/frontend-passes.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[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 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Thomas Koenig --- Fixed on all open branches, closing.
[Bug fortran/60677] [4.7/4.8 Regression] FAIL: gfortran.dg/ichar_3.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60677 --- Comment #8 from Mikael Morin --- Author: mikael Date: Sat Mar 29 12:14:41 2014 New Revision: 208935 URL: http://gcc.gnu.org/viewcvs?rev=208935&root=gcc&view=rev Log: fortran/ PR fortran/60677 * trans-intrinsic.c (gfc_conv_intrinsic_ichar): Enlarge argument list buffer. Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/trans-intrinsic.c
[Bug fortran/60677] [4.7/4.8 Regression] FAIL: gfortran.dg/ichar_3.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60677 Mikael Morin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Mikael Morin --- This should be fixed now. Please reopen if not.
[Bug c++/60705] New: alias template member access ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60705
Bug ID: 60705
Summary: alias template member access ignored
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: R.HL at gmx dot net
GCC simply ignores the fact, that a private member is inaccessible:
class A
{
struct B {};
};
template
using C = A::B; // Already the declaration of this alias template is ill-formed
int main()
{
C c1;
C c2;
}
This compiles without any warnings/errors using the GCC-4.9 snapshot from the
2nd march, and is obviously ill-formed (because access control applies to all
names in all declarations, ยง11/4).
There is AFAICS no exception for alias templates.
[Bug c++/60705] ill-formed member access in alias template ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60705 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-29 Ever confirmed|0 |1 Severity|major |normal
[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 #59 from Dominique d'Humieres --- Created attachment 32485 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32485&action=edit Patch for gfortran.dg/fmt_en.f90 Could you test the attached patch?
[Bug fortran/60576] [4.8 Regression] FAIL: gfortran.dg/assumed_rank_7.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576 --- Comment #15 from Dominique d'Humieres --- Reduced test case failing on x86_64-apple-darwin13 r208927 with -m64 (4.9.0 and 4.8.3, it succeeds with -m32 as well as the original test). [Book15] f90/bug% cat assumed_rank_7_red.f90 implicit none type t integer :: i end type class(T), allocatable :: ac(:,:) type(T), allocatable :: at(:,:) allocate(ac(2:3,2:4)) allocate(at(2:3,2:4)) call bar(ac) contains subroutine bar(x) type(t) :: x(..) call foo(x) end subroutine subroutine foo(x) class(t) :: x(..) end subroutine end [Book15] f90/bug% gfc assumed_rank_7_red.f90 -fsanitize=address [Book15] f90/bug% a.out = ==40254==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7fff587043c0 at pc 0x10751d678 bp 0x7fff58704230 sp 0x7fff58704208 READ of size 192 at 0x7fff587043c0 thread T0 #0 0x10751d677 (/opt/gcc/gcc4.9w/lib/libasan.1.dylib+0x1a677) #1 0x1074fc968 (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x11968) #2 0x1074fc6c7 (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x116c7) #3 0x1074fc9af (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x119af) #4 0x7fff960745fc (/usr/lib/system/libdyld.dylib+0x35fc) #5 0x0 Address 0x7fff587043c0 is located in stack of thread T0 at offset 0 in frame #0 0x1074fc1fe (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x111fe) This frame has 1 object(s): [32, 104) 'at' <== Memory access at offset 0 partially underflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-underflow ??:0 ?? Shadow bytes around the buggy address: 0x1fffeb0e0820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffeb0e0830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffeb0e0840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffeb0e0850: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffeb0e0860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x1fffeb0e0870: 00 00 00 00 00 00 00 00[f1]f1 f1 f1 00 00 00 00 0x1fffeb0e0880: 00 00 00 00 00 f4 f4 f4 f3 f3 f3 f3 00 00 00 00 0x1fffeb0e0890: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffeb0e08a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffeb0e08b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffeb0e08c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Contiguous container OOB:fc ASan internal: fe ==40254==ABORTING The code executes without error if I comment the line allocate(at(2:3,2:4))
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #204 from Markus Trippelsdorf --- Here is a comparison of libxul sizes (in bytes, unstripped) for different compiler options: gcc (trunk): -O3 90213016 -O3 -flto 79682648 -O3 -flto / PGO 77250512 -Os 70431584 -Os -flto 62474008 clang (trunk): -O3 80574784 -O3 -flto 79394992 -Os 72452776 -Os -flto 65111640
[Bug other/58197] subversion-1.8.x breaks script contrib/gcc_update
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58197 --- Comment #2 from Winfried Magerl --- the bug is already fixed in current gcc-4.8-branch and in TRUNK. gcc-4.8-branch/contrib/ChangeLog: --- 2013-10-21 Mike Stump * gcc_update (configure): Update to handle svn 1.8.1. --- gcc-4.9-branch/contrib/ChangeLog: --- 2013-08-29 Mike Stump * gcc_update (configure): Update to handle svn 1.8.1. --- please confirm/close/ the bug.
[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 #60 from dave.anglin at bell dot net --- On 29-Mar-14, at 12:12 PM, dominiq at lps dot ens.fr wrote: > Could you test the attached patch? Test no longer fails on hppa2.0w-hp-hpux11.11: Unsupported rounding for real(4) Unsupported rounding for real(8) Unsupported rounding for real(16) 0 0 0 PASS: gfortran.dg/fmt_en.f90 -O0 execution test XFAIL: gfortran.dg/fmt_en.f90 -O0 scan-file All kinds rounded to nearest -- John David Anglindave.ang...@bell.net
[Bug other/58197] subversion-1.8.x breaks script contrib/gcc_update
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58197 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Tobias Burnus --- (In reply to Winfried Magerl from comment #2) > please confirm/close/ the bug. Well, you should also be able to close your own bugs yourself. A belated thanks for the report and for the digging.
[Bug c++/60626] [c++1y] ICE with pointer to function with auto parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60626 --- Comment #1 from Adam Butcher --- Author: abutcher Date: Sat Mar 29 19:23:44 2014 New Revision: 208940 URL: http://gcc.gnu.org/viewcvs?rev=208940&root=gcc&view=rev Log: Fix PR c++/60626 PR c++/60626 * parser.c (cp_parser_init_declarator): Handle erroneous generic type usage in non-functions with pushed scope. PR c++/60626 * g++.dg/cpp1y/pr60626.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/cpp1y/pr60626.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/60626] [c++1y] ICE with pointer to function with auto parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60626 Adam Butcher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Adam Butcher --- Fixed in 4.9.
[Bug libfortran/60706] New: FAIL: gfortran.dg/size_kind_2.f90 -O scan-tree-dump original "var2 = 42949673 00;"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60706
Bug ID: 60706
Summary: FAIL: gfortran.dg/size_kind_2.f90 -O scan-tree-dump
original "var2 = 42949673 00;"
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: danglin at gcc dot gnu.org
Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
Build: hppa2.0w-hp-hpux11.11
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B
/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
-B/test/gnu/gcc/objdir/hppa2.
0w-hp-hpux11.11/./libgfortran/
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/size_
kind_2.f90 -fno-diagnostics-show-caret -fdiagnostics-color=never -O
-fdump-t
ree-original -S -o size_kind_2.s(timeout = 300)
spawn /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/test/gnu/gcc
/objdir/gcc/testsuite/gfortran/../../
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.
11/./libgfortran/ /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/size_kind_2.f90
-f
no-diagnostics-show-caret -fdiagnostics-color=never -O -fdump-tree-original -S
-
o size_kind_2.s
PASS: gfortran.dg/size_kind_2.f90 -O (test for excess errors)
PASS: gfortran.dg/size_kind_2.f90 -O scan-tree-dump original "static
integer.
kind=8. A..\\[2\\] = \\{2147483650, 2\\};"
FAIL: gfortran.dg/size_kind_2.f90 -O scan-tree-dump original "var2 =
42949673
00;"
PASS: gfortran.dg/size_kind_2.f90 -O scan-tree-dump original "var3 =
21474836
50;"
Test fails because var2 in original tree dump is ouput in hex:
MAIN__ ()
{
integer(kind=4) b[4];
integer(kind=8) var1[2];
integer(kind=8) var2;
integer(kind=8) var3;
{
static integer(kind=8) A.0[2] = {2147483650, 2};
(void) (MEM[(c_char * {ref-all})&var1] = MEM[(c_char * {ref-all})&A.0]);
var2 = 0x10004;
var3 = 2147483650;
}
}
[Bug tree-optimization/60707] New: FAIL: gfortran.dg/pr45636.f90 -O scan-tree-dump-times forwprop2 "memset" 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60707
Bug ID: 60707
Summary: FAIL: gfortran.dg/pr45636.f90 -O
scan-tree-dump-times forwprop2 "memset" 0
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: danglin at gcc dot gnu.org
Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
Build: hppa2.0w-hp-hpux11.11
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B
/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
-B/test/gnu/gcc/objdir/hppa2.
0w-hp-hpux11.11/./libgfortran/
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/pr456
36.f90 -fno-diagnostics-show-caret -fdiagnostics-color=never -O -O2
-fdump-t
ree-forwprop2 -S -o pr45636.s(timeout = 300)
spawn /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/test/gnu/gcc
/objdir/gcc/testsuite/gfortran/../../
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.
11/./libgfortran/ /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/pr45636.f90
-fno-d
iagnostics-show-caret -fdiagnostics-color=never -O -O2 -fdump-tree-forwprop2 -S
-o pr45636.s
PASS: gfortran.dg/pr45636.f90 -O (test for excess errors)
FAIL: gfortran.dg/pr45636.f90 -O scan-tree-dump-times forwprop2 "memset" 0
Tree dump:
;; Function main (main, funcdef_no=1, decl_uid=832, symbol_order=1) (executed
on
ce)
main (integer(kind=4) argc, character(kind=1) * * argv)
{
character(kind=1) a[1:4];
character(kind=1) b[1:4];
static integer(kind=4) options.0[9] = {68, 1023, 0, 0, 1, 1, 0, 0, 31};
:
_gfortran_set_args (argc_2(D), argv_3(D));
_gfortran_set_options (9, &options.0[0]);
__builtin_memcpy (&a, &"a "[1]{lb: 1 sz: 1}, 2);
__builtin_memset (&MEM[(void *)&a + 2B], 32, 2);
MEM[(c_char * {ref-all})&b] = 98;
__builtin_memset (&MEM[(void *)&b + 1B], 32, 3);
sub (&a, &b, 4, 4);
a ={v} {CLOBBER};
b ={v} {CLOBBER};
return 0;
}
[Bug fortran/60127] ICE with OpenMP and DO CONCURRENT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60127
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment #2 from Thomas Koenig ---
This patchlet
Index: openmp.c
===
--- openmp.c(Revision 208592)
+++ openmp.c(Arbeitskopie)
@@ -1657,7 +1657,7 @@ resolve_omp_do (gfc_code *code)
"at %L", &do_code->loc);
break;
}
- gcc_assert (do_code->op == EXEC_DO);
+ gcc_assert (do_code->op == EXEC_DO || do_code->op ==
EXEC_DO_CONCURRENT);
if (do_code->ext.iterator->var->ts.type != BT_INTEGER)
gfc_error ("!$OMP DO iteration variable must be of type integer at %L",
&do_code->loc);
Index: trans-openmp.c
===
--- trans-openmp.c (Revision 208592)
+++ trans-openmp.c (Arbeitskopie)
@@ -1322,7 +1322,7 @@ gfc_trans_omp_do (gfc_code *code, stmtblock_t *pbl
collapse = 1;
code = code->block->next;
- gcc_assert (code->op == EXEC_DO);
+ gcc_assert (code->op == EXEC_DO || code->op == EXEC_DO_CONCURRENT);
init = make_tree_vec (collapse);
cond = make_tree_vec (collapse);
seems to fix things, without testsuite regressions, and simple code
also seems to run OK.
Am I overlooking something basic here?
[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 #61 from Dominique d'Humieres --- > Test no longer fails on hppa2.0w-hp-hpux11.11: > > Unsupported rounding for real(4) > Unsupported rounding for real(8) > Unsupported rounding for real(16) >0 0 0 > PASS: gfortran.dg/fmt_en.f90 -O0 execution test > XFAIL: gfortran.dg/fmt_en.f90 -O0 scan-file All kinds rounded to nearest Actually all the tests are skipped. I have forgotten to remove the line if (l_skip(i)) cycle Could you rerun the test without this line? You should get something such as 285 0 30 Sorry for the mistake!-(
[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 #62 from dave.anglin at bell dot net --- On 29-Mar-14, at 7:30 PM, dominiq at lps dot ens.fr wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 > > --- Comment #61 from Dominique d'Humieres ens.fr> --- >> Test no longer fails on hppa2.0w-hp-hpux11.11: >> >> Unsupported rounding for real(4) >> Unsupported rounding for real(8) >> Unsupported rounding for real(16) >> 0 0 0 >> PASS: gfortran.dg/fmt_en.f90 -O0 execution test >> XFAIL: gfortran.dg/fmt_en.f90 -O0 scan-file All kinds rounded to >> nearest > > Actually all the tests are skipped. I have forgotten to remove the > line > > if (l_skip(i)) cycle > > Could you rerun the test without this line? You should get something > such as > > 285 0 30 Yes: Unsupported rounding for real(4) Unsupported rounding for real(8) Unsupported rounding for real(16) 285 0 30 -- John David Anglindave.ang...@bell.net
[Bug fortran/60127] ICE with OpenMP and DO CONCURRENT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60127 --- Comment #3 from Tobias Burnus --- (In reply to Thomas Koenig from comment #2) > Am I overlooking something basic here? a) You also can have DO CONCURRENT(i=1:5, j=1:5) but your code only handles one variable (by looking at the wrong variable). b) You also can have a MASK, which your code does not handle. See also my e-mail regarding OpenACC: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01020.html And for an implementation: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01253.html However, that implementation does not handle MASK which require temporaries, see http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01391.html The non-OpenMP/non-OpenACC code always generates a temporary; see PR60661.
