[Bug c++/61538] g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 --- Comment #17 from Joshua Kinard --- (In reply to Joshua Kinard from comment #16) > In 'all-stage2-gcc'. That's right around the commit you're referencing, so > I went ahead and reversed these four commits: > > 1. 39a8c5eaded1e5771a941c56a49ca0a5e9c5eca0 * config/mips/mips.c > (mips_emit_pre_atomic_barrier_p,) > 2. 974f0a74e2116143b88d8cea8e1dd5a9c18ef96c * config/mips/constraints.md > (ZR): New constraint. > 3. 0f8e46b16a53c02d7255dcd6b6e9b5bc7f8ec953 * config/mips/mips.c > (mips_process_sync_loop): Emit cmp result only if > 4. 30c3c4427521f96fb58b6e1debb86da4f113f06f * emit-rtl.c > (need_atomic_barrier_p): New function. Already mentioned to Andrew on IRC, but reversing these four commits solves the problem, but I am still not sure why it affects R1x000 CPUs. I can upload the static binaries of 'sln' for someone to look at if they'd like.
[Bug regression/61538] gcc after commit 39a8c5ea produces bad code for MIPS R1x000 CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 Joshua Kinard changed: What|Removed |Added Component|c++ |regression Version|4.9.0 |4.8.0 See Also||https://bugs.gentoo.org/sho ||w_bug.cgi?id=516548 Summary|g++ compiled binary, linked |gcc after commit 39a8c5ea |to glibc libpthread, hangs |produces bad code for MIPS |on SGI MIPS R1x000 systems |R1x000 CPUs |on Linux| --- Comment #18 from Joshua Kinard --- Known to work: Prior to commit 39a8c5ea (2012-06-19) Known to fail: Anything after commits 39a8c5ea, 974f0a74, 0f8e46b1, and 30c3c442 (2012-06-20)
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 Dominique d'Humieres changed: What|Removed |Added CC||mikael at gcc dot gnu.org, ||pault at gcc dot gnu.org --- Comment #30 from Dominique d'Humieres --- > A trivial workaround is to replace > call process_configuration (new_prt_spec ([prt_in])) > by > call process_configuration ([new_prt_spec (prt_in)]) Confirmed. > However, nevertheless you would want to understand why the elemental > function causes a malloc crash for dim 1 arrays and works for scalars > and dim > 1 arrays as input. Indeed, but I'll need some help!
[Bug target/61855] _MM_MANTISSA_NORM_ENUM in avx512intrin.h disabled when optimization off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61855 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-07-21 Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Ever confirmed|0 |1 --- Comment #1 from Uroš Bizjak --- Created attachment 33164 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33164&action=edit Patch that moves defines out of #ifdef __OPTIMIZE__ Somehow obvious patch.
[Bug target/61855] _MM_MANTISSA_NORM_ENUM in avx512intrin.h disabled when optimization off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61855 Uroš Bizjak changed: What|Removed |Added Target||x86 Target Milestone|--- |4.9.2
[Bug regression/61538] gcc after commit 39a8c5ea produces bad code for MIPS R1x000 CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 --- Comment #19 from Joshua Kinard --- Created attachment 33165 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33165&action=edit Disassembly of the ASM from 'sln' compiled by a known working gcc-4.8.0. This is the objdump disassembly of the '__lll_lock_wait_private()' function from the sln binary from glibc, statically compiled, by a GOOD gcc-4.8.0 checkout (7882e02e) with commits 39a8c5ea, 974f0a74, 0f8e46b1, and 30c3c442 reversed.
[Bug regression/61538] gcc after commit 39a8c5ea produces bad code for MIPS R1x000 CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 --- Comment #20 from Joshua Kinard --- Created attachment 33166 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33166&action=edit Disassembly of the ASM from 'sln' compiled by a non-working gcc-4.8.0. This is the objdump disassembly of the '__lll_lock_wait_private()' function from the sln binary from glibc, statically compiled, by a BAD gcc-4.8.0 checkout (7882e02e) no previous commits reversed. This sln copy will hang trying to print usage instructions.
[Bug target/61855] _MM_MANTISSA_NORM_ENUM in avx512intrin.h disabled when optimization off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61855 --- Comment #2 from Uroš Bizjak --- Author: uros Date: Mon Jul 21 08:47:48 2014 New Revision: 212886 URL: https://gcc.gnu.org/viewcvs?rev=212886&root=gcc&view=rev Log: PR target/61855 * config/i386/avx512fintrin.h: Move constants for mantissa extraction out of #ifdef __OPTIMIZE__. testsuite/ChangeLog: PR target/61855 * gcc.target/i386/pr61855.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr61855.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/avx512fintrin.h trunk/gcc/testsuite/ChangeLog
[Bug target/61827] gcc.target/i386/fuse-caller-save-xmm.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61827 --- Comment #2 from vries at gcc dot gnu.org --- Author: vries Date: Mon Jul 21 09:11:04 2014 New Revision: 212888 URL: https://gcc.gnu.org/viewcvs?rev=212888&root=gcc&view=rev Log: Fix fuse-caller-save-xmm.c test-case 2014-07-21 Tom de Vries PR target/61827 * gcc.target/i386/fuse-caller-save-xmm.c: Add -fomit-frame-pointer to dg-options. Add checks for insns with xmm registers. Remove cfi_def_cfa_offset checks. Generalize checks containing %rsp. (main): Remove. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
[Bug target/61827] gcc.target/i386/fuse-caller-save-xmm.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61827 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from vries at gcc dot gnu.org --- patch committed, fixed.
[Bug go/61865] New: FAIL: go.test/test/fixedbugs/bug272.go execution, -O2 -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61865 Bug ID: 61865 Summary: FAIL: go.test/test/fixedbugs/bug272.go execution, -O2 -g Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ubizjak at gmail dot com CC: cmang at google dot com The go.test/test/fixedbugs/bug272.go fails execution on 32bit x86 targets (Fedora 20): ./bug272.x BUG2 The testcase works OK in 64bit x86_64.
[Bug go/61866] New: FAIL: ./index0-out.go execution, -O0 -g -fno-var-tracking-assignments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61866 Bug ID: 61866 Summary: FAIL: ./index0-out.go execution, -O0 -g -fno-var-tracking-assignments Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ubizjak at gmail dot com CC: cmang at google dot com index0-out.go fails execution with -O0 -g -fno-var-tracking-assignments on 32bit x86 target (Fedora 20) with: BUG ./index0-out.go:113: ai[i64bigger] did not panic ./index0-out.go:113: ai[i64bigger:] did not panic ./index0-out.go:113: ai[ni64bigger] did not panic ./index0-out.go:113: ai[ni64bigger:] did not panic ./index0-out.go:113: ai[nhuge] did not panic ./index0-out.go:113: ai[nhuge:] did not panic ./index0-out.go:113: aib[i64bigger] did not panic ./index0-out.go:113: aib[i64bigger:] did not panic ./index0-out.go:113: aib[ni64bigger] did not panic ./index0-out.go:113: aib[ni64bigger:] did not panic ./index0-out.go:113: aib[nhuge] did not panic ./index0-out.go:113: aib[nhuge:] did not panic ./index0-out.go:113: aq[i64bigger] did not panic ./index0-out.go:113: aq[i64bigger:] did not panic ./index0-out.go:113: aq[ni64bigger] did not panic ./index0-out.go:113: aq[ni64bigger:] did not panic ./index0-out.go:113: aq[nhuge] did not panic ./index0-out.go:113: aq[nhuge:] did not panic ./index0-out.go:113: aqb[i64bigger] did not panic ./index0-out.go:113: aqb[i64bigger:] did not panic ./index0-out.go:113: aqb[ni64bigger] did not panic ./index0-out.go:113: aqb[ni64bigger:] did not panic ./index0-out.go:113: aqb[nhuge] did not panic ./index0-out.go:113: aqb[nhuge:] did not panic ./index0-out.go:113: pai[i64bigger] did not panic ./index0-out.go:113: pai[i64bigger:] did not panic ./index0-out.go:113: pai[ni64bigger] did not panic ./index0-out.go:113: pai[ni64bigger:] did not panic ./index0-out.go:113: pai[nhuge] did not panic ./index0-out.go:113: pai[nhuge:] did not panic ./index0-out.go:113: paib[i64bigger] did not panic ./index0-out.go:113: paib[i64bigger:] did not panic ./index0-out.go:113: paib[ni64bigger] did not panic ./index0-out.go:113: paib[ni64bigger:] did not panic ./index0-out.go:113: paib[nhuge] did not panic ./index0-out.go:113: paib[nhuge:] did not panic ./index0-out.go:113: paq[i64bigger] did not panic ./index0-out.go:113: paq[i64bigger:] did not panic ./index0-out.go:113: paq[ni64bigger] did not panic ./index0-out.go:113: paq[ni64bigger:] did not panic ./index0-out.go:113: paq[nhuge] did not panic ./index0-out.go:113: paq[nhuge:] did not panic ./index0-out.go:113: paqb[i64bigger] did not panic ./index0-out.go:113: paqb[i64bigger:] did not panic ./index0-out.go:113: paqb[ni64bigger] did not panic ./index0-out.go:113: paqb[ni64bigger:] did not panic ./index0-out.go:113: paqb[nhuge] did not panic ./index0-out.go:113: paqb[nhuge:] did not panic ./index0-out.go:113: si[i64bigger] did not panic ./index0-out.go:113: si[i64bigger:] did not panic ./index0-out.go:113: si[ni64bigger] did not panic ./index0-out.go:113: si[ni64bigger:] did not panic ./index0-out.go:113: si[nhuge] did not panic ./index0-out.go:113: si[nhuge:] did not panic ./index0-out.go:113: sib[i64bigger] did not panic ./index0-out.go:113: sib[i64bigger:] did not panic ./index0-out.go:113: sib[ni64bigger] did not panic ./index0-out.go:113: sib[ni64bigger:] did not panic ./index0-out.go:113: sib[nhuge] did not panic ./index0-out.go:113: sib[nhuge:] did not panic ./index0-out.go:113: sq[i64bigger] did not panic ./index0-out.go:113: sq[i64bigger:] did not panic ./index0-out.go:113: sq[ni64bigger] did not panic ./index0-out.go:113: sq[ni64bigger:] did not panic ./index0-out.go:113: sq[nhuge] did not panic ./index0-out.go:113: sq[nhuge:] did not panic ./index0-out.go:113: sqb[i64bigger] did not panic ./index0-out.go:113: sqb[i64bigger:] did not panic ./index0-out.go:113: sqb[ni64bigger] did not panic ./index0-out.go:113: sqb[ni64bigger:] did not panic ./index0-out.go:113: sqb[nhuge] did not panic ./index0-out.go:113: sqb[nhuge:] did not panic ./index0-out.go:113: t.ai[i64bigger] did not panic ./index0-out.go:113: t.ai[i64bigger:] did not panic ./index0-out.go:113: t.ai[ni64bigger] did not panic ./index0-out.go:113: t.ai[ni64bigger:] did not panic ./index0-out.go:113: t.ai[nhuge] did not panic ./index0-out.go:113: t.ai[nhuge:] did not panic ./index0-out.go:113: t.aib[i64bigger] did not panic ./index0-out.go:113: t.aib[i64bigger:] did not panic ./index0-out.go:113: t.aib[ni64bigger] did not panic ./index0-out.go:113: t.aib[ni64bigger:] did not panic ./index0-out.go:113: t.aib[nhuge] did not panic ./index0-out.go:113: t.aib[nhuge:] did not panic ./index0-out.go:113: t.aq[i64bigger] did not panic ./index0-out.go:113: t.aq[i64bigger:] did not panic ./index0-out.go:113: t.aq[ni64bigger] did not panic ./index0-out.go:113: t.aq[ni64bigger:] did not panic ./index0-out.go:113: t.aq[nhuge] did
[Bug target/61827] gcc.target/i386/fuse-caller-save-xmm.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61827
--- Comment #4 from Dominique d'Humieres ---
The following patch
--- ../_clean/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
2014-07-21 11:21:30.0 +0200
+++ gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c2014-07-21
11:44:24.0 +0200
@@ -17,7 +17,7 @@ foo (v2df y)
/* Check presence of all insns on xmm registers. These checks are expected to
pass with both -fuse-caller-save and -fno-use-caller-save. */
-/* { dg-final { scan-assembler-times "addpd\t\\.LC0.*, %xmm0" 1 } } */
+/* { dg-final { scan-assembler-times "addpd\t\\.?LC0.*, %xmm0" 1 } } */
/* { dg-final { scan-assembler-times "addpd\t%xmm1, %xmm0" 1 } } */
/* { dg-final { scan-assembler-times "movapd\t%xmm0, %xmm1" 1 } } */
is needed for darwin (addpdLC0(%rip), %xmm0).
[Bug target/61855] _MM_MANTISSA_NORM_ENUM in avx512intrin.h disabled when optimization off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61855 --- Comment #3 from uros at gcc dot gnu.org --- Author: uros Date: Mon Jul 21 10:09:04 2014 New Revision: 212889 URL: https://gcc.gnu.org/viewcvs?rev=212889&root=gcc&view=rev Log: Backport from mainline 2014-07-21 Uros Bizjak PR target/61855 * config/i386/avx512fintrin.h: Move constants for mantissa extraction out of #ifdef __OPTIMIZE__. testsuite/ChangeLog: Backport from mainline 2014-07-21 Uros Bizjak PR target/61855 * gcc.target/i386/pr61855.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr61855.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/i386/avx512fintrin.h branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug target/61855] _MM_MANTISSA_NORM_ENUM in avx512intrin.h disabled when optimization off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61855 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Uroš Bizjak --- Fixed.
[Bug c++/61863] Data corruption when creating temporary object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61863 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #1 from Mikael Pettersson --- When compiled with g++ 4.9.1 or 4.7.4 I see Length in printLen= 8 when running the executable, but with g++ 4.8.3 I see Length in printLen= 0
[Bug target/61827] gcc.target/i386/fuse-caller-save-xmm.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61827
--- Comment #5 from Uroš Bizjak ---
(In reply to Dominique d'Humieres from comment #4)
> The following patch
>
> --- ../_clean/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
> 2014-07-21 11:21:30.0 +0200
> +++ gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c 2014-07-21
> 11:44:24.0 +0200
> @@ -17,7 +17,7 @@ foo (v2df y)
>
> /* Check presence of all insns on xmm registers. These checks are expected
> to
> pass with both -fuse-caller-save and -fno-use-caller-save. */
> -/* { dg-final { scan-assembler-times "addpd\t\\.LC0.*, %xmm0" 1 } } */
> +/* { dg-final { scan-assembler-times "addpd\t\\.?LC0.*, %xmm0" 1 } } */
> /* { dg-final { scan-assembler-times "addpd\t%xmm1, %xmm0" 1 } } */
> /* { dg-final { scan-assembler-times "movapd\t%xmm0, %xmm1" 1 } } */
>
>
> is needed for darwin (addpd LC0(%rip), %xmm0).
Looks OK, please commit.
[Bug c++/61867] New: gcc can't detect obviously false test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61867
Bug ID: 61867
Summary: gcc can't detect obviously false test
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
I just tried the following code on trunk 20140720
extern int g(int);
void f( int n)
{
int i;
i = g( n) & 0x02;
if (i == 1)
g( 2);
}
$ ~/gcc/results/bin/gcc -c -g -O2 -Wall -Wextra -pedantic -ansi jul21a.cc
$
so gcc has nothing to say about it. Here is cppcheck, a static analyser,
finding the problem
$ ~/cppcheck/trunk/cppcheck --enable=all jul21a.cc
Checking jul21a.cc...
[jul21a.cc:8] -> [jul21a.cc:10]: (style) Mismatching assignment and comparison,
comparison 'i==1' is always false.
$
I note that about six bugs in the linux kernel and about 40 bugs in
Fedora Linux would be detected by implementing this fix.
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #31 from Dominique d'Humieres --- Further reduced test program main implicit none type :: string_t character(LEN=1), dimension(:), allocatable :: chars end type string_t type(string_t) :: prt_in, tmp(1) integer :: i prt_in = string_t(["W"]) do i = 1, 16 print *, i tmp = new_prt_spec ([prt_in]) end do contains elemental function new_prt_spec (name) result (prt_spec) type(string_t), intent(in) :: name type(string_t) :: prt_spec end function new_prt_spec end program main > However, nevertheless you would want to understand why the elemental > function causes a malloc crash for dim 1 arrays and works for scalars > and dim > 1 arrays as input. The faulty block is not used for scalars.
[Bug target/61827] gcc.target/i386/fuse-caller-save-xmm.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61827 --- Comment #6 from vries at gcc dot gnu.org --- Author: vries Date: Mon Jul 21 10:54:47 2014 New Revision: 212890 URL: https://gcc.gnu.org/viewcvs?rev=212890&root=gcc&view=rev Log: Fix fuse-caller-save test-cases 2014-07-21 Tom de Vries PR target/61827 * gcc.target/i386/fuse-caller-save-xmm.c: Allow LC0 without dot prefix for darwin in scan-assembler-times check. * gcc.target/i386/fuse-caller-save.c: Remove cfi-related scan-assembler-not checks. Add checks for insns. (main): Remove. * gcc.target/i386/fuse-caller-save-rec.c: Remove cfi-related scan-assembler-not checks. Copy checks from i386/fuse-caller-save.c. (main): Remove. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c trunk/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c trunk/gcc/testsuite/gcc.target/i386/fuse-caller-save.c
[Bug target/61827] gcc.target/i386/fuse-caller-save-xmm.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61827
--- Comment #7 from Dominique d'Humieres ---
Sorry, another patch for darwin (call_bar)
--- ../_clean/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c
2014-07-21 13:09:41.0 +0200
+++ gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c2014-07-21
13:11:54.0 +0200
@@ -26,5 +26,5 @@ foo (int y)
/* { dg-final { scan-assembler-times "addl\t%\[re\]?dx, %\[re\]?ax" 1 } } */
/* Verify that bar is self-recursive. */
-/* { dg-final { scan-assembler-times "call\tbar" 2 } } */
+/* { dg-final { scan-assembler-times "call\t_?bar" 2 } } */
[Bug target/61827] gcc.target/i386/fuse-caller-save-xmm.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61827 --- Comment #8 from vries at gcc dot gnu.org --- Author: vries Date: Mon Jul 21 11:29:10 2014 New Revision: 212891 URL: https://gcc.gnu.org/viewcvs?rev=212891&root=gcc&view=rev Log: Fix fuse-caller-save-rec.c 2014-07-21 Tom de Vries PR target/61827 * gcc.target/i386/fuse-caller-save-rec.c: Allow underscore prefix to bar symbol in scan-assembler-times call check. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c
[Bug target/61827] gcc.target/i386/fuse-caller-save-xmm.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61827 --- Comment #9 from Dominique d'Humieres --- > New Revision: 212891 ... Thanks!
[Bug target/55701] Inline some instances of memset for ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55701 --- Comment #3 from amker at gcc dot gnu.org --- Author: amker Date: Mon Jul 21 12:24:06 2014 New Revision: 212893 URL: https://gcc.gnu.org/viewcvs?rev=212893&root=gcc&view=rev Log: PR target/55701 * config/arm/arm.md (setmem): New pattern. * config/arm/arm-protos.h (struct tune_params): New fields. (arm_gen_setmem): New prototype. * config/arm/arm.c (arm_slowmul_tune): Initialize new fields. (arm_fastmul_tune, arm_strongarm_tune, arm_xscale_tune): Ditto. (arm_9e_tune, arm_v6t2_tune, arm_cortex_tune): Ditto. (arm_cortex_a8_tune, arm_cortex_a7_tune): Ditto. (arm_cortex_a15_tune, arm_cortex_a53_tune): Ditto. (arm_cortex_a57_tune, arm_cortex_a5_tune): Ditto. (arm_cortex_a9_tune, arm_cortex_a12_tune): Ditto. (arm_v7m_tune, arm_v6m_tune, arm_fa726te_tune): Ditto. (arm_const_inline_cost): New function. (arm_block_set_max_insns): New function. (arm_block_set_non_vect_profit_p): New function. (arm_block_set_vect_profit_p): New function. (arm_block_set_unaligned_vect): New function. (arm_block_set_aligned_vect): New function. (arm_block_set_unaligned_non_vect): New function. (arm_block_set_aligned_non_vect): New function. (arm_block_set_vect, arm_gen_setmem): New functions. * gcc.target/arm/memset-inline-1.c: New test. * gcc.target/arm/memset-inline-2.c: New test. * gcc.target/arm/memset-inline-3.c: New test. * gcc.target/arm/memset-inline-4.c: New test. * gcc.target/arm/memset-inline-5.c: New test. * gcc.target/arm/memset-inline-6.c: New test. * gcc.target/arm/memset-inline-7.c: New test. * gcc.target/arm/memset-inline-8.c: New test. * gcc.target/arm/memset-inline-9.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/memset-inline-1.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-2.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-3.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-4.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-5.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-6.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-7.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-8.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm-protos.h trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.md trunk/gcc/testsuite/ChangeLog
[Bug go/60874] FAIL: go.test/test/recover.go execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874 Uroš Bizjak changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Uroš Bizjak --- (In reply to Ian Lance Taylor from comment #2) > The patch is committed so this bug may be fixed. I haven't tested it on > Alpha, though. The testcase recover.go doesn't fail outright with not-implemented error. However, tests test11reflect2, test13reflect2 and test14reflect2 currently fail.
[Bug c++/61867] gcc can't detect obviously false test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61867 --- Comment #1 from Jonathan Wakely --- I'm pretty sure gcc does detect it and optimizes appropriately, it just doesn't warn (because it's not a static analyzer)
[Bug driver/61868] New: -frandom-seed always results in random_seed of 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61868
Bug ID: 61868
Summary: -frandom-seed always results in random_seed of 0
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: bmei at broadcom dot com
Compile any simple file with -frandom-seed and -flto option.
#include
extern int foo (int);
int bar (int a)
{
return a * 5;
}
int main ()
{
printf("%d\n", foo (100));
return 0;
}
~/scratch/install-x86/bin/gcc tst2.c -flto -c -frandom-seed=12345
objdump -D tst2.o|less
You can see all the lto section has suffix of 0 instead of the random_seed
specified.
<.gnu.lto_.inline.0>
This is because of the following code in toplev.c. If flag_random_seed is true,
then init_random_seed is not called in get_random_seed despite the piece of
code trying to generate random_seed if flag_random_seed is true.
static void
init_random_seed (void)
{
if (flag_random_seed)
{
char *endp;
/* When the driver passed in a hex number don't crc it again */
random_seed = strtoul (flag_random_seed, &endp, 0);
if (!(endp > flag_random_seed && *endp == 0))
random_seed = crc32_string (0, flag_random_seed);
}
else if (!random_seed)
random_seed = local_tick ^ getpid (); /* Old racey fallback method */
}
/* Obtain the random_seed. Unless NOINIT, initialize it if
it's not provided in the command line. */
HOST_WIDE_INT
get_random_seed (bool noinit)
{
if (!flag_random_seed && !noinit)
init_random_seed ();
return random_seed;
}
[Bug tree-optimization/61869] New: Spurious uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61869 Bug ID: 61869 Summary: Spurious uninitialized warning Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: y.gribov at samsung dot com CC: jakub at gcc dot gnu.org Host: x86_64-unknown-linux-gnu Target: x86_64-unknown-linux-gnu Created attachment 33167 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33167&action=edit Reprocase Current gcc reports spurious warning on attached code (based upon gcc/asan.c with some local changes): $ g++ repro.i -c -Wmaybe-uninitialized -O2 /home/ygribov/repro.i: In function ‘void f(list*)’: /home/ygribov/repro.i:30:12: warning: ‘i’ may be used uninitialized in this function [-Wmaybe-uninitialized] iterator i; ^ /home/ygribov/repro.i:30:12: warning: ‘*((void*)& i +8)’ may be used uninitialized in this function [-Wmaybe-uninitialized] It looks like lim1 pass exploits conditional NULL dereference in start() and introduces read of uninitialized variable.
[Bug c++/61870] New: internal compiler error: in get_expr_operands, at tree-ssa-operands.c:1035
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61870
Bug ID: 61870
Summary: internal compiler error: in get_expr_operands, at
tree-ssa-operands.c:1035
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dzidzitop at vfemail dot net
When I compile source code I see the following error.
src/lastfm_scrobbler.cpp: In lambda function:
src/lastfm_scrobbler.cpp:193:1: internal compiler error: in get_expr_operands,
at tree-ssa-operands.c:1035
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Preprocessed source stored into /tmp/cc6F4c5e.out file, please attach this to
your bugreport.
The line that does not compile is:
m_scrobblingThread = std::thread([this]() { backgroundScrobbling(); });
The following change fixes this:
m_scrobblingThread = std::thread([this]() { this->backgroundScrobbling(); });
[Bug c++/61870] internal compiler error: in get_expr_operands, at tree-ssa-operands.c:1035
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61870 --- Comment #1 from dzidzitop at vfemail dot net --- Created attachment 33168 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33168&action=edit The preprocessed file.
[Bug go/60874] FAIL: go.test/test/recover.go execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874
--- Comment #4 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Ian Lance Taylor from comment #2)
> > The patch is committed so this bug may be fixed. I haven't tested it on
> > Alpha, though.
>
> The testcase recover.go doesn't fail outright with not-implemented error.
> However, tests test11reflect2, test13reflect2 and test14reflect2 currently
> fail.
The problem with test11reflect2 was due to unhandled FFI_TYPE_VOID case in
ffi_closure_osf_inner, fixed by following patch:
--cut here-
Index: src/alpha/ffi.c
===
--- src/alpha/ffi.c (revision 212882)
+++ src/alpha/ffi.c (working copy)
@@ -237,6 +237,7 @@ ffi_closure_osf_inner(ffi_closure *closure, void *
switch (arg_types[i]->type)
{
+ case FFI_TYPE_VOID:
case FFI_TYPE_SINT8:
case FFI_TYPE_UINT8:
case FFI_TYPE_SINT16:
--cut here--
It looks that test13reflect2 and test14reflect2 tests fail on non-split stack
targets, since everything works OK with slightly modified testcase:
--cut here--
Index: testsuite/go.test/test/recover.go
===
--- testsuite/go.test/test/recover.go (revision 212882)
+++ testsuite/go.test/test/recover.go (working copy)
@@ -432,7 +432,7 @@
}
// enormous receiver, so wrapper splits stack to call M
-type T5 [8192]byte
+type T5 [2048]byte
func (T5) M() {
mustRecoverBody(doubleRecover(), recover(), recover(), 13)
@@ -459,12 +459,12 @@
// enormous receiver + enormous method frame, so wrapper splits stack to call
M,
// and then M splits stack to allocate its frame.
// recover must look back two frames to find the panic.
-type T6 [8192]byte
+type T6 [2048]byte
var global byte
func (T6) M() {
- var x [8192]byte
+ var x [2048]byte
x[0] = 1
x[1] = 2
for i := range x {
--cut here--
It looks that the later problem points to a generic problem with non
split-stack targets.
[Bug go/60874] FAIL: go.test/test/recover.go execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874 --- Comment #5 from Uroš Bizjak --- I forgot to tell that reflect test from libgo testsuite now passes: PASS: reflect
[Bug go/61871] New: FAIL: regexp from libgo testsuite on non-split stack targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61871
Bug ID: 61871
Summary: FAIL: regexp from libgo testsuite on non-split stack
targets
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: ubizjak at gmail dot com
CC: cmang at google dot com
regexp test from libgo testsuite FAILs on alpha (non-split stack target) due to
too demanding testcase, even with 8G of RAM.
Applying the following testsuite patch, test passes without problems.
--cut here--
Index: go/regexp/all_test.go
===
--- go/regexp/all_test.go (revision 212885)
+++ go/regexp/all_test.go (working copy)
@@ -475,7 +475,7 @@
// This ran out of stack before issue 7608 was fixed.
func TestOnePassCutoff(t *testing.T) {
- MustCompile(`^(?:x{1,1000}){1,1000}$`)
+// MustCompile(`^(?:x{1,1000}){1,1000}$`)
}
func BenchmarkLiteral(b *testing.B) {
--cut here--
[Bug fortran/61847] bug in gfortran runtime on OSX: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #3 from e2cd58e1 at opayq dot com --- but what I want to do is read in values with point as decimal separator. Using open(unit=1,file='bug.dat', decimal="point") doesn't seem to change anything.
[Bug lto/61526] relocation R_X86_64_PC32 in shared object with static and extern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61526 Sandra Loosemore changed: What|Removed |Added CC||sandra at codesourcery dot com --- Comment #3 from Sandra Loosemore --- The testcase added for this bug in GCC 4.9.1 is failing with a link error on an arm-none-eabi target that doesn't support -shared. Should it be restricted to linux targets?
[Bug lto/61526] relocation R_X86_64_PC32 in shared object with static and extern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61526 --- Comment #4 from Uroš Bizjak --- (In reply to Sandra Loosemore from comment #3) > The testcase added for this bug in GCC 4.9.1 is failing with a link error on > an arm-none-eabi target that doesn't support -shared. Should it be > restricted to linux targets? Probably the best way is to add check_effective_target_shared to lib/target-supports.exp (similar to existing c_e_t_static) procedure and use it through the testsuite.
[Bug c++/61872] New: Assigning to "long double" causes memset to be improperly elided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61872
Bug ID: 61872
Summary: Assigning to "long double" causes memset to be
improperly elided
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: coleb at eyesopen dot com
Created attachment 33169
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33169&action=edit
Intermediate file generated by the compiler for the above test case
The following code zeros out memory being used as a "long double" in order to
be able to memcmp the memory later. However, assigning to the long double later
causes the optimizer to omit the preceding memset of zero.
The following code boils this down to a simple test case:
#include
#include
#include
#include
void Dump( const void * mem, size_t n )
{
const unsigned char * p = reinterpret_cast< const unsigned char *>( mem );
for ( size_t i = 0; i < n; i++ )
{
std::cout << std::hex << std::setw(2) << std::setfill( std::cout.widen('0')
) << int(p[i]) << " ";
}
std::cout << std::endl;
}
int main()
{
long double a;
memset(&a, '\0', sizeof(long double));
//Dump(&a, sizeof(long double)); // Uncomment me to make the test pass
a = 1.0;
long double b;
memset(&b, '\0', sizeof(long double));
//Dump(&b, sizeof(long double)); // Uncomment me to make the test pass
b = 1.0;
std::cout << memcmp(&a, &b, sizeof(long double)) << std::endl;
Dump(&a, sizeof(long double));
Dump(&b, sizeof(long double));
assert(memcmp(&a, &b, sizeof(long double)) == 0);
}
Uncommenting the "Dump" function calls causing the test to pass, presumably
because the optimizer notices the zero'd out memory is now being used by Dump
before the assignment.
Note, this only occurs with -O1 or higher.
I've attached the associated .ii files from the following command:
coleb@rhel7:~> g++ -v -save-temps -O1 ./LongDoubleMemSetElided.cpp && ./a.out
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --disable-libgcj
--with-isl=/builddir/build/BUILD/gcc-4.8.2-20131106/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131106/obj-x86_64-redhat-linux/cloog-install
--with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.2 20131106 (Red Hat 4.8.2-3) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/cc1plus -E -quiet -v -D_GNU_SOURCE
./LongDoubleMemSetElided.cpp -mtune=generic -march=x86-64 -O1 -fpch-preprocess
-o LongDoubleMemSetElided.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.8.2/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/x86_64-redhat-linux
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/backward
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/include
/usr/local/include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/cc1plus -fpreprocessed
LongDoubleMemSetElided.ii -quiet -dumpbase LongDoubleMemSetElided.cpp
-mtune=generic -march=x86-64 -auxbase LongDoubleMemSetElided -O1 -version -o
LongDoubleMemSetElided.s
GNU C++ (GCC) version 4.8.2 20131106 (Red Hat 4.8.2-3) (x86_64-redhat-linux)
compiled by GNU C version 4.8.2 20131106 (Red Hat 4.8.2-3), GMP version
5.1.1, MPFR version 3.1.1, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.8.2 20131106 (Red Hat 4.8.2-3) (x86_64-redhat-linux)
compiled by GNU C version 4.8.2 20131106 (Red Hat 4.8.2-3), GMP version
5.1.1, MPFR version 3.1.1, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 854a658c8d093bd199c43bf0150da7d8
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
as -v --64 -o
[Bug c++/61873] New: with -openmp, -E does not produce preprocessed output on stdout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61873 Bug ID: 61873 Summary: with -openmp, -E does not produce preprocessed output on stdout Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mib.bugzilla at gmail dot com % g++ -c -E omp1.cpp # 1 "omp1.cpp" # 1 "" # 1 "" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 1 "" 2 # 1 "omp1.cpp" int i; % g++ -c -openmp -E omp1.cpp %
[Bug fortran/61847] bug in gfortran runtime on OSX: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to e2cd58e1 from comment #3) > but what I want to do is read in values with point as decimal separator. > Using > > open(unit=1,file='bug.dat', decimal="point") > > doesn't seem to change anything. gfortran's IO for floating point numbers using the operating systems strtof, strtod, and strtold. Are you sure that these functions on yuor OS actual have working locale support?
[Bug fortran/61847] bug in gfortran runtime on OSX: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #5 from e2cd58e1 at opayq dot com --- I actually don't know - how can I test this? But either way, shouldn't open(unit=1,file='bug.dat', decimal="point") read 1.234 in as 1.234 no matter what the locale settings are?
[Bug fortran/61847] bug in gfortran runtime on OSX: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #6 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #4) > (In reply to e2cd58e1 from comment #3) > > but what I want to do is read in values with point as decimal separator. > > Using > > > > open(unit=1,file='bug.dat', decimal="point") > > > > doesn't seem to change anything. > > gfortran's IO for floating point numbers using the operating > systems strtof, strtod, and strtold. Are you sure that these > functions on yuor OS actual have working locale support? Yeah, replying to myself. What happens if you give strtod "1.2345' and "1,2345" in your locale? I missed a section of code in io/read.c: case ',': if (dtp->u.p.current_unit->decimal_status != DECIMAL_COMMA) goto bad_float; /* Fall through. */ case '.': if (seen_dp) goto bad_float; if (!seen_int_digit) *(out++) = '0'; *(out++) = '.'; seen_dp = 1; break; This implicitly changes a comma into a decimal point prior to the call to strtod.
[Bug fortran/61847] bug in gfortran runtime on OSX: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847
--- Comment #7 from e2cd58e1 at opayq dot com ---
For
printf("Test 1 = %.4f\n",strtod("1.2345",NULL));
printf("Test 2 = %.4f\n",strtod("1,2345",NULL));
I get
Test 1 = 1,
Test 2 = 1,2345
[Bug fortran/61847] bug in gfortran runtime on OSX: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847
--- Comment #8 from Steve Kargl ---
On Mon, Jul 21, 2014 at 06:18:14PM +, e2cd58e1 at opayq dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847
>
> --- Comment #7 from e2cd58e1 at opayq dot com ---
> For
>
> printf("Test 1 = %.4f\n",strtod("1.2345",NULL));
> printf("Test 2 = %.4f\n",strtod("1,2345",NULL));
>
> I get
>
> Test 1 = 1,
> Test 2 = 1,2345
>
That's what I would expect. Here's another test;
#include
#include
#include
int
main(void)
{
char *s1 = "1.2345", *s2 = "5,4321";
double d1, d2;
setlocale(LC_ALL, "en_US.ISO8859-1");
d1 = strtod(s1, NULL);
d2 = strtod(s2, NULL);
printf("%s = %.4lf and %s = %.4lf\n", s1, d1, s2, d2);
setlocale(LC_ALL, "de_DE.UTF-8");
d1 = strtod(s1, NULL);
d2 = strtod(s2, NULL);
printf("%s = %.4lf and %s = %.4lf\n", s1, d1, s2, d2);
return 0;
}
I get
troutmask:sgk[204] ./z
1.2345 = 1.2345 and 5,4321 = 5.
1.2345 = 1, and 5,4321 = 5,4321
So, the section of code that I posted in comment 6 is
ensuring that the fraction separator is always a decimal
point, and your locale and strtod are expecting a comma.
[Bug fortran/61847] bug in gfortran runtime on OSX: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #9 from e2cd58e1 at opayq dot com --- Just what I get: 1.2345 = 1.2345 and 5,4321 = 5. 1.2345 = 1, and 5,4321 = 5,4321
[Bug tree-optimization/61869] Spurious uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61869 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-21 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez --- (In reply to Yury Gribov from comment #0) > Created attachment 33167 [details] > /home/ygribov/repro.i:30:12: warning: ‘*((void*)& i +8)’ may be used > uninitialized in this function [-Wmaybe-uninitialized] Sad we are still printing this to the user (even if the warning were valid)
[Bug middle-end/61396] [4.10 regression] ICE in simplify_immed_subreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61396 --- Comment #4 from Pat Haugen --- (In reply to Iain Sandoe from comment #3) > Revision r209530 is OK, r210534 is not, likely a wide-int fallout. > The problem first appeared in trunk revision 210113.
[Bug c++/61867] gcc can't detect obviously false test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61867 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org Severity|normal |enhancement --- Comment #2 from Manuel López-Ibáñez --- There are many cases where this may trigger false positives. The mask used in the assignment or the value used in the comparison may come from a macro expansion, and be compile-time dependent. Or the comparison may be some kind of debug/assert check to ensure people don't mess up the assignment. Does cppcheck document what is actually warned and what is not and how to work-around the warning in case the code is actually valid? I am sure cppcheck warns about a lot of things that GCC does not, but the difficulty lies in getting the corner-cases right and the right level of warning versus annoying users.
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #32 from paul.richard.thomas at gmail dot com ---
Dear Dominique,
The problem is due to:
atmp.10.offset = 0;
{
integer(kind=8) S.12;
S.12 = 0;
while (1)
{
if (S.12 > 0) goto L.4;
{
struct string_t D.2386;
struct string_t D.2385;
D.2385 = (*(struct string_t[1] * restrict)
atmp.7.data)[S.12];
D.2386 = new_prt_spec (&D.2385);
if (D.2385.chars.data != 0B)
/* between here */
{
__builtin_free ((void *) D.2385.chars.data);
}
D.2385.chars.data = 0B;
/* and here */
(*(struct string_t[1] * restrict)
atmp.10.data)[S.12] = D.2386;
}
S.12 = S.12 + 1;
}
L.4:;
}
process_configuration (&atmp.10);
if ((struct string_t[1] * restrict) atmp.10.data != 0B)
I cannot see yet, where it comes in nor when it was introduced.
Paul
On 21 July 2014 12:51, dominiq at lps dot ens.fr
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
>
> --- Comment #31 from Dominique d'Humieres ---
> Further reduced test
>
> program main
> implicit none
>
> type :: string_t
> character(LEN=1), dimension(:), allocatable :: chars
> end type string_t
>
> type(string_t) :: prt_in, tmp(1)
> integer :: i
> prt_in = string_t(["W"])
> do i = 1, 16
> print *, i
> tmp = new_prt_spec ([prt_in])
> end do
>
> contains
>
> elemental function new_prt_spec (name) result (prt_spec)
> type(string_t), intent(in) :: name
> type(string_t) :: prt_spec
> end function new_prt_spec
>
> end program main
>
>> However, nevertheless you would want to understand why the elemental
>> function causes a malloc crash for dim 1 arrays and works for scalars
>> and dim > 1 arrays as input.
>
> The faulty block is not used for scalars.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
[Bug fortran/61847] bug in gfortran runtime: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847
Dominique d'Humieres changed:
What|Removed |Added
Summary|bug in gfortran runtime on |bug in gfortran runtime:
|OSX: digits cut off when|digits cut off when reading
|reading floating point |floating point number
|number |
--- Comment #10 from Dominique d'Humieres ---
I can reproduce this PR on a linux box with gcc version 4.6.3 20120306 (Red Hat
4.6.3-2), so the bug is not darwin specific.
I have noticed that the file generated by running the test is
1.2345
and does not change if I put the line
setlocale(LC_ALL, "de_DE.UTF-8");
before the line
f = fopen("bug.dat", "w");
Now if I change the content of bug.dat to
1,2345
suppress the file generation in bug.c and use
open(unit=1,file='bug.dat', decimal='comma')
in bugf.f90, running the executable does not give any output (success).
So apparently strtod uses the locale to read 1.2345, giving 1.0 as a result for
"de_DE.UTF-8" (or "fr_FR.UTF-8"), using "en_US.ISO8859-1" gives 1.2345.
The only solution I see is to save the current locale, set it to "C" before
using strtod, and restore it upon completion.
[Bug c++/61867] gcc can't detect obviously false test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61867 --- Comment #3 from David Binderman --- (In reply to Jonathan Wakely from comment #1) > I'm pretty sure gcc does detect it and optimizes appropriately, it just > doesn't warn. I've checked the output from using -S and I agree. All the code to do the detection & reduction seems to be in place. I think that all that needs to happen is a warning is produced where either the detection or reduction takes place. As ever, users are free to ignore warnings. egrep -v is useful, I find.
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #33 from Dominique d'Humieres ---
Dear Paul,
> I cannot see yet, where it comes in nor when it was introduced.
Unfortunately I has been introduced by me, see comment 5. The code is
+ if (expr->ts.type == BT_DERIVED && expr->rank
+ && !gfc_is_finalizable (expr->ts.u.derived, NULL)
+ && expr->ts.u.derived->attr.alloc_comp
+ && expr->expr_type != EXPR_VARIABLE)
+{
+ tree tmp;
+
+ tmp = build_fold_indirect_ref_loc (input_location, se->expr);
+ tmp = gfc_deallocate_alloc_comp (expr->ts.u.derived, tmp, expr->rank);
+
+ /* The components shall be deallocated before
+ their containing entity. */
+ gfc_prepend_expr_to_block (&se->post, tmp);
+}
Question: what condition should be added to the 'if' to get a false for
'expr->expr_type == EXPR_ARRAY' and an elemental function?
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 James Clarke changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com --- Comment #14 from James Clarke --- The issue with Availability.h has been fixed as of Developer Preview 4, however `all-stage1-target-libsanitizer` still fails with Error 2.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #15 from James Clarke --- (In reply to James Clarke from comment #14) > The issue with Availability.h has been fixed as of Developer Preview 4, > however `all-stage1-target-libsanitizer` still fails with Error 2. I should note that I am building 4.8.3 with Homebrew.
[Bug fortran/61847] bug in gfortran runtime: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #11 from Jerry DeLisle --- After all that has been said here, I am almost afraid to add any more. This is not a bug. Fortran and GFortran are not locale aware. The ',' or '.' are read from the file or device literally as is. From this read, a numeric string is constructed. If the unit was opened with decimal='comma' and a comma was seen, the comma is converted to '.'. If decimal='point' and a comma is read, an error occurs. After the above described numeric string is constructed it is passed to the glibc library strtod (sring to double). The glibc library is locale aware and if the locale has defined the decimal token to be a ',' (comma), it see the decimal 'point' and interprets it as end of string conversion. We do not want to take a performance it by checking the locale setting on every I/O operation, so the only logical place to do that is in main.c. However, in the example, the original poster is only compiling a gfortran subroutine. There is no gfortran program, so there is no gfortran main.c So the responsibility for addressing the locale has to fall on the C program side or within the users subroutine using maybe system calls that are extensions and not Fortran standard code. This users code would query the current runtime environment for current decimal setting and then do the I/O with the appropriate decimal= specifier. To avoid confusion, remember that gfortran is reading the characters in the file literally. So if there is a 1,2345 it sees the comma. If there is a 1.234 it sees the point. The conversion to internal floating point representation occurs after the character data is read. The easiest solution is to do what I said in in Comment #2 on the C side. The equivalent can be done on the fortran side as well, just not as easily. One possible enhancement we could consider is providing some set and get locale intrinsics. This would be helpful for some folks. But, thats a lot more work.
[Bug fortran/61847] bug in gfortran runtime: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847
--- Comment #12 from e2cd58e1 at opayq dot com ---
Sorry but I still have a problem with this, maybe I didn't get what you are
saying or I wasn't clear enough.
Suppose I cannot change the C-wrapper and the locale might be set to whatever.
The file bug.dat already exists and uses point decimals. So I want a fortran
routine that always reads in a file in the usual point separated format.
If in the fortran routine I call
open(unit=1,file='bug.dat', decimal="point")
I expect the keyword to be more important than the locale setting: I explicitly
specify to read point separated values, but in the example below, it still
returns 1.0 instead of 1.2345. Is that really expected behavior?
- bug.c --
#include /* strtod */
#include
#include
int badcall_();
int main()
{
setlocale(LC_ALL, "de_DE.UTF-8");
badcall_();
return 0;
}
- bug.dat --
1.2345
- bugf.f90 --
subroutine badcall()
implicit none
double precision :: res
open(unit=1,file='bug.dat',decimal="point")
read(1,*) res
write(*,*) 'res =', res
end subroutine badcall
[Bug debug/61874] New: Missing DW_AT_location for "this" parameter when using always_inline attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61874
Bug ID: 61874
Summary: Missing DW_AT_location for "this" parameter when using
always_inline attribute
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: apepper at blueshiftinc dot com
Dwarf output for formal parameter “this”, includes no DW_AT_location, for a
member function that is decorated with “__attribute__ ((always_inline))”.
Test case:
---
class A
{
public:
void accessMemberInline(int a) __attribute__ ((always_inline))
{
m_a = a;
}
int m_a;
};
int main()
{
A my_a;
my_a.accessMemberInline(5);
}
g++ -g -O0
[Bug fortran/61847] bug in gfortran runtime: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #13 from Steve Kargl --- On Tue, Jul 22, 2014 at 01:39:30AM +, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 > > --- Comment #11 from Jerry DeLisle --- > After all that has been said here, I am almost afraid to add any more. > > This is not a bug. Fortran and GFortran are not locale aware. The ',' or '.' > are read from the file or device literally as is. From this read, a numeric > string is constructed. If the unit was opened with decimal='comma' and a > comma > was seen, the comma is converted to '.'. If decimal='point' and a comma is > read, an error occurs. I never claimed it to be bug. You've simply restated what I was trying to convey in much more coherent manner in a single post. > After the above described numeric string is constructed it is passed to the > glibc library strtod (sring to double). The glibc library is locale aware and > if the locale has defined the decimal token to be a ',' (comma), it see the > decimal 'point' and interprets it as end of string conversion. I do however note that OP is using MacOS and I use FreeBSD. Neither uses glibc. strtod is a C99/POSIX specified function, so correctly implmented strtod function should give the same results (up to whether C99/POSIX requires adherence to locale).
[Bug c++/53361] Could not convert ‘{0, 0, 0}’ from ‘’ to ‘std::array’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53361 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #8 from nightstrike --- This SO post claims that GCC is in error: http://stackoverflow.com/questions/8192185/using-stdarray-with-initialization-lists
[Bug fortran/61847] bug in gfortran runtime: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #14 from Jerry DeLisle --- (In reply to e2cd58e1 from comment #12) --- snip --- > Suppose I cannot change the C-wrapper and the locale might be set to > whatever. The file bug.dat already exists and uses point decimals. So I want > a fortran routine that always reads in a file in the usual point separated > format. > > If in the fortran routine I call > > open(unit=1,file='bug.dat', decimal="point") > > I expect the keyword to be more important than the locale setting: I > explicitly specify to read point separated values, but in the example below, > it still returns 1.0 instead of 1.2345. Is that really expected behavior? > My first bad assumption was that for some reason you wanted the current locale, whatever it is, to remain active. My second bad assumption was that you could easily change your C-wrapper. :) In reading up on the locale business, setting locale to "POSIX" is suppose to be fully portable. So, we could easily force the locale to POSIX in the open statement. I need to think about whether this will mess up something else.
[Bug fortran/61847] bug in gfortran runtime: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #15 from Jerry DeLisle --- Maybe something like this: Index: open.c === --- open.c(revision 212498) +++ open.c(working copy) @@ -26,6 +26,7 @@ see the files COPYING3 and COPYING.RUNTIME respect #include "io.h" #include "fbuf.h" #include "unix.h" +#include "locale.h" #ifdef HAVE_UNISTD_H #include @@ -725,6 +726,10 @@ st_open (st_parameter_open *opp) library_start (&opp->common); + /* For portability, set locale to "POSIX". */ + + setlocale(LC_ALL, "POSIX"); + /* Decode options. */ flags.access = !(cf & IOPARM_OPEN_HAS_ACCESS) ? ACCESS_UNSPECIFIED :
[Bug target/61396] [4.10 regression] ICE in simplify_immed_subreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61396 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED CC||segher at gcc dot gnu.org Component|middle-end |target Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #5 from Segher Boessenkool --- It's a target problem. I have a patch.
[Bug fortran/61847] bug in gfortran runtime: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #16 from Steve Kargl --- On Tue, Jul 22, 2014 at 04:27:58AM +, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 > > --- Comment #15 from Jerry DeLisle --- > Maybe something like this: I think that you'll need to use configure to check for locale.h. > > Index: open.c > === > --- open.c(revision 212498) > +++ open.c(working copy) > @@ -26,6 +26,7 @@ see the files COPYING3 and COPYING.RUNTIME respect > #include "io.h" > #include "fbuf.h" > #include "unix.h" > +#include "locale.h" #ifdef HAVE_LOCALE_H #include #endif > > #ifdef HAVE_UNISTD_H > #include > @@ -725,6 +726,10 @@ st_open (st_parameter_open *opp) > >library_start (&opp->common); #ifdef HAVE_LOCALE_H > + /* For portability, set locale to "POSIX". */ > + > + setlocale(LC_ALL, "POSIX"); > + #endif
[Bug c++/53361] Could not convert ‘{0, 0, 0}’ from ‘’ to ‘std::array’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53361 --- Comment #9 from Andrew Pinski --- (In reply to nightstrike from comment #8) > This SO post claims that GCC is in error: Yes and it was fixed in 4.8.
[Bug c++/53361] Could not convert ‘{0, 0, 0}’ from ‘’ to ‘std::array’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53361 --- Comment #10 from nightstrike --- Oh, strange. I thought I was still experiencing this on 4.8.2. I'll check again. Sorry for the noise.
