[Bug fortran/58225] New: In show_locus at fortran/error.c:391 pointer beyond end of line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58225 Bug ID: 58225 Summary: In show_locus at fortran/error.c:391 pointer beyond end of line Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com In show_locus at fortran/error.c:391 statement spaces = gfc_widechar_display_length (*p++); *p points beyond the end of input line, cmax too big Maybe connected to bug 54382? two versions of test case follow ! free format !1 format(i5) !print'()j' !END ! fixed format !3 FORMAT(BZ, (I5, F5.0, BN, F5.2, 2I5)) ! print '()J' ! END
[Bug fortran/58226] New: negative subscript pos at fortran/options.c:1205
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58226 Bug ID: 58226 Summary: negative subscript pos at fortran/options.c:1205 Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com gfortran 4.8.2 negative subscript pos at fortran/options.c:1205 statement result[--pos] = '\0'; compiling the following use iso_fortran_env print *,compiler_options() end
[Bug fortran/58225] In show_locus at fortran/error.c:391 pointer beyond end of line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58225
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
Index: io.c
===
--- io.c(revision 201791)
+++ io.c(working copy)
@@ -1173,7 +1173,7 @@ check_format_string (gfc_expr *e, bool i
if (e-value.character.string[i] != ' ')
{
format_locus.nextc += format_length + 1;
- gfc_warning (Extraneous characters in format at %L,
format_locus);
+ gfc_warning (Extraneous characters in format at %C);
break;
}
return rv;
laptop-kargl:kargl[218] cat g.f90
1 format(i5)
print'()j'
END
laptop-kargl:kargl[219] gfc4x -c g.f90
g.f90:2.10:
print'()j'
1
Warning: Extraneous characters in format at (1)
[Bug tree-optimization/58223] [4.8/4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58223 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-23 Summary|wrong code at -O3 on|[4.8/4.9 Regression] wrong |x86_64-linux-gnu|code at -O3 on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- ldist pass replaces the a[b]=0 statements with a call to memset after the loop, apparently missing the aliasing with a[0]=1.
[Bug tree-optimization/58223] [4.8/4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58223 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Yep, thus -fno-tree-loop-distribute-patterns is a workaround.
[Bug tree-optimization/58223] [4.8/4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58223 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Known to work||4.7.3 Target Milestone|--- |4.8.3 Known to fail||4.8.1, 4.9.0
[Bug tree-optimization/58227] New: wrong code (hangs) at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58227
Bug ID: 58227
Summary: wrong code (hangs) at -O3 on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk produces wrong code (that hangs) for the following
testcase on x86_64-linux when compiled at -O3 in both 32-bit and 64-bit modes.
This is a regression from 4.8.x.
It might be related to 58143, but 58143 also fails for 4.8.
$ gcc-trunk -v
gcc version 4.9.0 20130822 (experimental) [trunk revision 201915] (GCC)
$ gcc-4.8 -O3 reduced.c
$ a.out
$ gcc-trunk -O2 reduced.c
$ a.out
$ gcc-trunk -O3 reduced.c
$ a.out
^C
$
--
int a, b, d, e, f, *g, h, i;
volatile int c;
char foo (unsigned char p)
{
return p + 1;
}
int bar ()
{
for (h = 0; h 3; h = foo (h))
{
c;
for (f = 0; f 1; f++)
{
i = a 0 -2147483647 - h ? 0 : 1;
if (e)
for (; d;)
b = 0;
else
g = 0;
}
}
return 0;
}
int main ()
{
bar ();
return 0;
}
[Bug target/57932] Aligned stack wastes more than k bytes (as needed), if preferred stack boundary k=2**n, n=4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57932 Markus Eisenmann meisenmann@fh-salzburg.ac.at changed: What|Removed |Added Target|IA-32/x86-64|i386 --- Comment #1 from Markus Eisenmann meisenmann@fh-salzburg.ac.at --- After further investigations within [gcc-4.6.4\]gcc\config\i386\i386.c I have found (maybe) the issue: Within function ix86_compute_frame_layout there are 2 stack-realignments: a) the local stack is aligned first, w/o including stack-needs (see b afterwards) /* Align start of frame for local function. */ if (stack_realign_fp || offset != frame-sse_reg_save_offset || size != 0 || !current_function_is_leaf || cfun-calls_alloca || ix86_current_function_calls_tls_descriptor) offset = (offset + stack_alignment_needed - 1) -stack_alignment_needed; b) after that a second re-calculation takes place, including the size of alloca/pushed args/sub-calls: offset += size; ... /* Align stack boundary. Only needed if we're calling another function or using alloca. */ if (!current_function_is_leaf || cfun-calls_alloca || ix86_current_function_calls_tls_descriptor) offset = (offset + preferred_alignment - 1) -preferred_alignment; Based on my understanding - the waste/gap of stack includes a) and b) together. In my opinion - if stack_alignment_needed == preferred_alignment the first alignment isn't nedded; I.e. a) is already included by b) At leats, are there an further comments to my findings ... ?
[Bug tree-optimization/58227] wrong code (hangs) at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58227 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- I think this invokes undefined behavior in third iteration, when h is 2. Works with s/-2147483647/-2147483647L/.
[Bug tree-optimization/58209] [4.7 Regression] ICE in extract_range_from_binary_expr, at tree-vrp.c:2294
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58209 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.2, 4.9.0 Summary|[4.7/4.8/4.9 Regression]|[4.7 Regression] ICE in |ICE in |extract_range_from_binary_e |extract_range_from_binary_e |xpr, at tree-vrp.c:2294 |xpr, at tree-vrp.c:2294 | Known to fail|4.9.0 | --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Aug 23 07:30:40 2013 New Revision: 201935 URL: http://gcc.gnu.org/viewcvs?rev=201935root=gccview=rev Log: PR tree-optimization/58209 * tree-tailcall.c (process_assignment): Handle POINTER_PLUS_EXPR. (find_tail_calls): Give up for pointer result types if m is non-NULL. (adjust_return_value_with_ops): For PLUS_EXPR and pointer result type emit POINTER_PLUS_EXPR. (create_tailcall_accumulator): For pointer result type accumulate in sizetype type. * gcc.c-torture/execute/pr58209.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr58209.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-tailcall.c Author: jakub Date: Fri Aug 23 07:35:01 2013 New Revision: 201937 URL: http://gcc.gnu.org/viewcvs?rev=201937root=gccview=rev Log: PR tree-optimization/58209 * tree-tailcall.c (find_tail_calls): Give up for pointer result types if m or a is non-NULL. * gcc.c-torture/execute/pr58209.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr58209.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-tailcall.c
[Bug tree-optimization/58227] wrong code (hangs) at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58227 --- Comment #2 from Zhendong Su su at cs dot ucdavis.edu --- But similar to 58143, because of short circuiting (since a == 0), the expression 0 -2147483647 - h ? 0 : 1 shouldn't be evaluated at all, correct? Or maybe I'm mistaken? Thanks for looking into this Marek!
[Bug tree-optimization/58228] New: wrong code (with vectorization?) at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58228
Bug ID: 58228
Summary: wrong code (with vectorization?) at -O3 on
x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk, as well as gcc 4.7 and 4.8, produces wrong code for the
following testcase on x86_64-linux when compiled at -O3 in both 32-bit and
64-bit modes. This is a regression from 4.6.x.
This seems to do with vectorization, as it goes away with -fno-tree-vectorize.
$ gcc-trunk -v
gcc version 4.9.0 20130822 (experimental) [trunk revision 201915] (GCC)
$ gcc-4.6 -O3 reduced.c
$ a.out
1
$ gcc-4.7 -O3 reduced.c
$ a.out
0
$ gcc-4.8 -O3 reduced.c
$ a.out
0
$ gcc-trunk -O3 reduced.c
$ a.out
0
$ gcc-trunk -O3 -fno-tree-vectorize reduced.c
$ a.out
1
$
int printf (const char *, ...);
int a[8][8] = {{1}};
int b, c, d, e;
int main ()
{
for (c = 0; c 8; c++)
for (b = 0; b 2; b++)
a[b + 4][c] = a[c][0];
printf (%d\n, a[4][4]);
return 0;
}
[Bug tree-optimization/58227] wrong code (hangs) at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58227 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-23 Ever confirmed|0 |1 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Yes, sorry. Loop invariant motion moves the condition here as well, I suppose (works with -fno-tree-loop-im). Thus confirmed.
[Bug tree-optimization/58223] [4.8/4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58223 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r188186 . Richard, can you please have a look?
[Bug tree-optimization/58227] [4.9 Regression] wrong code (hangs) at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58227 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.1 Target Milestone|--- |4.9.0 Summary|wrong code (hangs) at -O3 |[4.9 Regression] wrong code |on x86_64-linux-gnu |(hangs) at -O3 on ||x86_64-linux-gnu Known to fail||4.9.0
[Bug tree-optimization/58228] [4.7/4.8/4.9 Regression] wrong code (with vectorization?) at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58228 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-23 CC||mpolacek at gcc dot gnu.org Known to work||4.6.3 Summary|wrong code (with|[4.7/4.8/4.9 Regression] |vectorization?) at -O3 on |wrong code (with |x86_64-linux-gnu|vectorization?) at -O3 on ||x86_64-linux-gnu Ever confirmed|0 |1 Known to fail||4.7.3, 4.8.1, 4.9.0 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug fortran/58113] [4.9 Regression] gfortran.dg/round_4.f90 FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58113 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #4 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 30692 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30692action=edit determine rounding support at runtime How about this? With this patch the test case should pass most of the time.
[Bug tree-optimization/58143] [4.8/4.9 regression] wrong code at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added Attachment #30681|0 |1 is obsolete|| --- Comment #10 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 30693 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30693action=edit possible fix, next try... This variant eliminates the infer_loop_bounds_from_signedness function and some of the invokes undefined behavior warnings. Bootstrapped, and regression tested on i686-pc-linux-gnu. And by the way, it fixes PR57904 too. How do you like it now ?
[Bug tree-optimization/58143] [4.8/4.9 regression] wrong code at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- No, that is wrong as well.
[Bug tree-optimization/58228] [4.7/4.8/4.9 Regression] wrong code (with vectorization?) at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58228 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.7.4 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r175704 .
[Bug fortran/58229] New: Memory leak with overloaded operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58229 Bug ID: 58229 Summary: Memory leak with overloaded operator Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jwmwalrus at gmail dot com The following, reduced version of the actual code (sorry if it's still too big), leaks memory quite fast when compiled with gfortran 4.8/4.9: !gfortran-4.9 -o test_leak ~/test_leak.f90 module mod1 implicit none type :: pointtype real :: x = 0, y = 0, z = 0 end type interface operator(*) module procedure point_times_scalar module procedure scalar_times_point end interface contains elemental function point_times_scalar(point, scalar) result(res) !type(pointtype) :: res type(pointtype), allocatable :: res type(pointtype), intent(IN) :: point real, intent(IN) :: scalar res = pointtype(point%x * scalar, point%y * scalar, point%z * scalar) end function elemental function scalar_times_point(scalar, point) result(res) !type(pointtype) :: res type(pointtype), allocatable :: res real, intent(IN) :: scalar type(pointtype), intent(IN) :: point res = point * scalar end function end module mod1 use mod1 implicit none integer :: i, j real :: x(3) type(pointtype), allocatable :: a(:,:) allocate (a(100,100)) do j = 1, SIZE(a,2) do i = 1, SIZE(a, 1) call RANDOM_NUMBER(x) a(i,j) = pointtype(x(1), x(2), x(3)) a(i,j) = 2. * a(i,j) a(i,j) = 3. * a(i,j) a(i,j) = 4. * a(i,j) enddo enddo end Version 4.9 seems to be leaking more memory than version 4.8. Valgrind's output is: ==10718== Memcheck, a memory error detector ==10718== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==10718== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==10718== Command: ./test_leak ==10718== Parent PID: 31089 ==10718== --10718-- --10718-- Valgrind options: --10718----suppressions=/usr/lib/valgrind/debian-libc6-dbg.supp --10718---v --10718----log-file=./valgrind.log --10718----num-callers=100 --10718----leak-check=full --10718----undef-value-errors=no --10718-- Contents of /proc/version: --10718-- Linux version 3.10-2-amd64 (debian-ker...@lists.debian.org) (gcc version 4.7.3 (Debian 4.7.3-6) ) #1 SMP Debian 3.10.5-1 (2013-08-07) --10718-- Arch and hwcaps: AMD64, amd64-sse3-cx16-lzcnt --10718-- Page sizes: currently 4096, max supported 4096 --10718-- Valgrind library directory: /usr/lib/valgrind --10718-- Reading syms from /tmp/test_leak --10718-- Reading syms from /lib/x86_64-linux-gnu/ld-2.17.so --10718-- Considering /lib/x86_64-linux-gnu/ld-2.17.so .. --10718-- .. CRC mismatch (computed 1a41d356 wanted 031d690d) --10718-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.17.so .. --10718-- .. CRC is valid --10718-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux --10718-- Considering /usr/lib/valgrind/memcheck-amd64-linux .. --10718-- .. CRC mismatch (computed 5a0963b7 wanted f2a7ec16) --10718-- Considering /usr/lib/debug/usr/lib/valgrind/memcheck-amd64-linux .. --10718-- .. CRC is valid --10718--object doesn't have a dynamic symbol table --10718-- Scheduler: using generic scheduler lock implementation. --10718-- Reading suppressions file: /usr/lib/valgrind/debian-libc6-dbg.supp --10718-- Reading suppressions file: /usr/lib/valgrind/default.supp ==10718== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-10718-by-jwm-on-??? ==10718== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-10718-by-jwm-on-??? ==10718== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-10718-by-jwm-on-??? ==10718== ==10718== TO CONTROL THIS PROCESS USING vgdb (which you probably ==10718== don't want to do, unless you know exactly what you're doing, ==10718== or are doing some strange experiment): ==10718== /usr/lib/valgrind/../../bin/vgdb --pid=10718 ...command... ==10718== ==10718== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==10718== /path/to/gdb ./test_leak ==10718== and then give GDB the following command ==10718== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=10718 ==10718== --pid is optional if only one valgrind process is running ==10718== --10718-- REDIR: 0x4017870 (strlen) redirected to 0x3806e381 (vgPlain_amd64_linux_REDIR_FOR_strlen) --10718-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so --10718-- Considering /usr/lib/valgrind/vgpreload_core-amd64-linux.so .. --10718-- .. CRC mismatch (computed 2f3ef0a4 wanted fa342ee8) --10718-- Considering /usr/lib/debug/usr/lib/valgrind/vgpreload_core-amd64-linux.so .. --10718-- .. CRC is valid --10718-- Reading syms from
[Bug libmudflap/58230] New: mutliple test fail in german language version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58230 Bug ID: 58230 Summary: mutliple test fail in german language version Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libmudflap Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de Hello, multiple libmudflap tests fail because the test scripts use the english warning text, but the compiler prints the german translation. libmudflap.c/pass35-frag.c libmudflap.c++/error1-frag.cxx libmudflap.c++/error2-frag.cxx libmudflap.c++/pass57-frag.cxx Probably the test environment should set the LANG=C somewhere? from libmudflap.log: spawn /home/ed/gnu/gcc-build/gcc/xgcc -B/home/ed/gnu/gcc-build/gcc/ -ggdb3 -DDEBUG_ASSERT -I/home/ed/gnu/gcc-4.9-20130818/libmudflap/testsuite -I/home/ed/gnu/gcc-4.9-20130818/libmudflap/testsuite/.. -I.. -L/home/ed/gnu/gcc-build/i686-pc-linux-gnu/./libmudflap/.libs /home/ed/gnu/gcc-4.9-20130818/libmudflap/testsuite/libmudflap.c/pass35-frag.c -O0 -fmudflap -lmudflap -L/home/ed/gnu/gcc-build/i686-pc-linux-gnu/./libmudflap/testsuite -ldl -lm -o ./pass35-frag.exe^M /home/ed/gnu/gcc-4.9-20130818/libmudflap/testsuite/libmudflap.c/pass35-frag.c:14:1: Warnung: Schmutzfänger kann nicht externes »end« unbekannter Größe verfolgen [-Wmudflap]^M }^M ^^M output is: /home/ed/gnu/gcc-4.9-20130818/libmudflap/testsuite/libmudflap.c/pass35-frag.c:14:1: Warnung: Schmutzfänger kann nicht externes »end« unbekannter Größe verfolgen [-Wmudflap]^M }^M ^^M FAIL: libmudflap.c/pass35-frag.c (-O0) cannot track unknown size extern (test for warnings, line ) FAIL: libmudflap.c/pass35-frag.c (-O0) (test for excess errors) Excess errors: /home/ed/gnu/gcc-4.9-20130818/libmudflap/testsuite/libmudflap.c/pass35-frag.c:14:1: Warnung: Schmutzfänger kann nicht externes »end« unbekannter Größe verfolgen [-Wmudflap]
[Bug target/58218] -mcmodel=medium cause assembler warning ignoring incorrect section type for .lbss
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58218 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Aug 23 09:57:44 2013 New Revision: 201938 URL: http://gcc.gnu.org/viewcvs?rev=201938root=gccview=rev Log: PR target/58218 * config/i386/x86-64.h (TARGET_SECTION_TYPE_FLAGS): Define. * config/i386/i386.c (x86_64_elf_section_type_flags): New function. * gcc.target/i386/pr58218.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr58218.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/x86-64.h trunk/gcc/testsuite/ChangeLog Author: jakub Date: Fri Aug 23 10:01:34 2013 New Revision: 201939 URL: http://gcc.gnu.org/viewcvs?rev=201939root=gccview=rev Log: PR target/58218 * config/i386/x86-64.h (TARGET_SECTION_TYPE_FLAGS): Define. * config/i386/i386.c (x86_64_elf_section_type_flags): New function. * gcc.target/i386/pr58218.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr58218.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/i386/i386.c branches/gcc-4_8-branch/gcc/config/i386/x86-64.h branches/gcc-4_8-branch/gcc/testsuite/ChangeLog Fixed for 4.8+.
[Bug regression/58221] [4.9 Regression]: Immense amount of execution regressions and increased test-time for cris-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58221 --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org --- No significant change in results for regress-446 - regress-444 for r201882 from r201874 (some libstdc++ changes pass again, but others now fail). Maybe r201883 is the winner; checking.
[Bug c/58231] New: Using post-decrement as a boolean expression in if statement leads to crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58231 Bug ID: 58231 Summary: Using post-decrement as a boolean expression in if statement leads to crash Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: soulofdeity at gmail dot com This works: if (!i) ;//code i--; This crashes: if (!i--) ;//code
[Bug c/58231] Using post-decrement as a boolean expression in if statement leads to crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58231 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-08-23 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Please provide whole testcase, GCC options, version, etc. I can't see this crashing in a simple code.
[Bug c++/50436] Crash or hang on invalid template code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50436 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Currently both hang for me (after a rather useful error message). We can certainly do better, of course. Interesting that the error messages produced by clang and icc are completely different.
[Bug c++/55677] Virtual inheritance, 'this' pointer used as constructor parameter, parameter specialized in derived method, generated binary dumps core
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55677 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Resolution|INVALID |WORKSFORME
[Bug c++/55677] Virtual inheritance, 'this' pointer used as constructor parameter, parameter specialized in derived method, generated binary dumps core
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55677 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com --- Can't reproduce with currently maintained branches.
[Bug tree-optimization/58143] [4.8/4.9 regression] wrong code at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143
--- Comment #12 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Jakub Jelinek from comment #11)
No, that is wrong as well.
Because it is too destructive? Maybe.
I think this is a general problem here.
1. the undefined behavior warning may be triggered by artefacts
from the lim pass or in the class_48.f90 case.
2. surprise optimizations may happen without this warning, see my
previous comment #9.
3. in the case of integer overflow, reliable does only say
that the operation is executed in every iteration, but not
that the result is acually used for something, as in Zhedong's
example.
With array bounds I have not the same problem, here as I'd
say if the array is accessed beyond the limit, the guarantee
is void anyway, and the lim pass would never move an array access
out of the if statement, right? But there are examples where
the undefined behavior warning is not emitted after a possible
array bounds exception.
A nice example for this is gmp-4.3.2/tests/mpz/t-scan.c
This example has a array bounds error:
static const int offset[] = {
-2, -1, 0, 1, 2, 3
};
...
for (oindex = 0; oindex = numberof (offset); oindex++) // +-1 error here
{
o = offset[oindex];
...
if (got != want)
{
...
exit (1); // this cancels the aggressive-loop-optimizations warning
}
...
}
The generated code at -O2 is without the loop termination check,
surprise surprise...
What do you think?
[Bug regression/58221] [4.9 Regression]: Immense amount of execution regressions and increased test-time for cris-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58221 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2013-08-23 CC||tejohnson at gcc dot gnu.org --- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org --- (In reply to Hans-Peter Nilsson from comment #1) Maybe r201883 is the winner; checking. Yes, that's it. I'll have to leave for a few hours but I'll extract a small test-case, probably just one of the regressions as-is. CC to committer. N.B. cris-* does not have target support for section-switching - at least I don't remember putting in any specific support. Regarding the patch, I can't say at a glance what could possibly be so damaging about *not* skipping the first non-active insn.
[Bug regression/58221] [4.9 Regression]: Immense amount of execution regressions and increased test-time for cris-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58221 Kazumoto Kojima kkojima at gcc dot gnu.org changed: What|Removed |Added CC||kkojima at gcc dot gnu.org --- Comment #3 from Kazumoto Kojima kkojima at gcc dot gnu.org --- SH also gets many execution failures at r201833. I've reported it as PR58220. It looks NEXT_INSN vs. next_insn problem.
[Bug tree-optimization/58143] [4.8/4.9 regression] wrong code at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org --- Because the bug is in lim, so hacking around it in other parts of the compiler and removing desirable optimizations just to mitigate the bug is not the right way to fix it. Either lim shouldn't move the expressions if they are conditional in the loop body and might trigger undefined behavior in the place where it has been moved to while it might not trigger undefined behavior originally, or lim should transform them into expressions that won't trigger undefined behavior while moving them if it can't prove this will not happen (in this case that would mean performing the arithmetics in a type that doesn't have undefined behavior on overflow).
[Bug regression/58221] [4.9 Regression]: Immense amount of execution regressions and increased test-time for cris-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58221 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Patch to change that bogus next_insn call to NEXT_INSN is preapproved, please put these two PRs into the ChangeLog entry.
[Bug regression/58221] [4.9 Regression]: Immense amount of execution regressions and increased test-time for cris-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58221 --- Comment #5 from Teresa Johnson tejohnson at google dot com --- Thanks, and sorry for the trouble. Kaz, are you planning to apply your patch, or do you want me to test it and commit it? I'm kicking off x86_64 tests with it right now, but I didn't get the failure on that target and don't have on hand yet a reproducer. Teresa On Fri, Aug 23, 2013 at 6:13 AM, jakub at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58221 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Patch to change that bogus next_insn call to NEXT_INSN is preapproved, please put these two PRs into the ChangeLog entry. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug regression/58221] [4.9 Regression]: Immense amount of execution regressions and increased test-time for cris-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58221 --- Comment #6 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Teresa Johnson from comment #5) Kaz, are you planning to apply your patch, or do you want me to test it and commit it? I'm kicking off x86_64 tests with it right now, but I didn't get the failure on that target and don't have on hand yet a reproducer. I've tested it on sh4-linux only. I've just fired bootstrap and the usual tests on i686-linux. It will take hours on my slow host, though. Could you apply the patch after your x86_64 tests?
[Bug regression/58221] [4.9 Regression]: Immense amount of execution regressions and increased test-time for cris-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58221 --- Comment #7 from Teresa Johnson tejohnson at google dot com --- On Fri, Aug 23, 2013 at 6:49 AM, kkojima at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58221 --- Comment #6 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Teresa Johnson from comment #5) Kaz, are you planning to apply your patch, or do you want me to test it and commit it? I'm kicking off x86_64 tests with it right now, but I didn't get the failure on that target and don't have on hand yet a reproducer. I've tested it on sh4-linux only. I've just fired bootstrap and the usual tests on i686-linux. It will take hours on my slow host, though. Could you apply the patch after your x86_64 tests? Will do, thanks. Teresa -- You are receiving this mail because: You are on the CC list for the bug.
[Bug regression/58221] [4.9 Regression]: Immense amount of execution regressions and increased test-time for cris-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58221
--- Comment #8 from Teresa Johnson tejohnson at google dot com ---
Tested on x86_64-unknown-linux-gnu, and also reproduced the failure
listed in PR rtl-optimization/58220 and verified the fix with it.
Committed as r201941:
Index: final.c
===
--- final.c (revision 201940)
+++ final.c (revision 201941)
@@ -1650,7 +1650,7 @@ reemit_insn_block_notes (void)
rtx insn, note;
insn = get_insns ();
- for (; insn; insn = next_insn (insn))
+ for (; insn; insn = NEXT_INSN (insn))
{
tree this_block;
Index: ChangeLog
===
--- ChangeLog (revision 201940)
+++ ChangeLog (revision 201941)
@@ -1,3 +1,10 @@
+2013-08-23 Kaz Kojima kkoj...@gcc.gnu.org
+
+ PR rtl-optimization/58220
+ PR regression/58221
+ * final.c (reemit_insn_block_notes): Use NEXT_INSN to
+ handle SEQUENCE insns properly.
+
2013-08-23 Gabriel Dos Reis g...@integrable-solutions.net
* pretty-print.h (pp_newline_and_flush): Declare. Remove macro
Thanks,
Teresa
On Fri, Aug 23, 2013 at 6:54 AM, Teresa Johnson tejohn...@google.com wrote:
On Fri, Aug 23, 2013 at 6:49 AM, kkojima at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58221
--- Comment #6 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
(In reply to Teresa Johnson from comment #5)
Kaz, are you planning to apply your patch, or do you want me to test
it and commit it? I'm kicking off x86_64 tests with it right now, but
I didn't get the failure on that target and don't have on hand yet a
reproducer.
I've tested it on sh4-linux only. I've just fired bootstrap
and the usual tests on i686-linux. It will take hours on my
slow host, though. Could you apply the patch after your x86_64
tests?
Will do, thanks.
Teresa
--
You are receiving this mail because:
You are on the CC list for the bug.
--
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
[Bug tree-optimization/58223] [4.8/4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58223
--- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org ---
Ok, so what happens here is that rdg_build_partitions builds two partitions,
that essentially means we split the loop in the original test case into two
loops:
for (b = 0; b 2; b++)
a[0] = 1;
for (b = 0; b 2; b++)
a[b] = 0;
Now, we go over all partitions and classify_partition them, in both loops we
have only one store and no load, thus we're in
if (single_store !single_load)
{
...
}
condition. For the first loop we bail out, since const_with_all_bytes_same is
true for 1 and TYPE_MODE for that 1 is not the same as TYPE_MODE for unsigned
char (had the a array been of the char type, it would be the same TYPE_MODE).
But for second loop we happily set the PKIND_MEMSET, thus replace it later with
memset.
I don't know much about partitioning, but it seems that we shouldn't split the
loop in the first place.
[Bug fortran/58229] [F03] Memory leak with allocatable function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58229 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-23 CC||janus at gcc dot gnu.org Summary|Memory leak with overloaded |[F03] Memory leak with |operator|allocatable function result Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- Confirmed. Reduced test case: implicit none type :: pointtype real :: x = 0, y = 0, z = 0 end type integer :: i, j real :: x(3) type(pointtype), allocatable :: a(:,:) allocate (a(10,10)) do j = 1, SIZE(a,2) do i = 1, SIZE(a, 1) call RANDOM_NUMBER(x) a(i,j) = pointtype(x(1), x(2), x(3)) a(i,j) = scalar_times_point (2. , a(i,j)) enddo enddo contains function scalar_times_point(scalar, point) result(res) type(pointtype), allocatable :: res real, intent(IN) :: scalar type(pointtype), intent(IN) :: point res = pointtype(point%x * scalar, point%y * scalar, point%z * scalar) end function end It is not really connected to operators, but rather to allocatable function results in general. The variant above shows two leaks with 4.9 trunk: ==31477== 1,200 bytes in 1 blocks are definitely lost in loss record 1 of 2 ==31477==at 0x4C2C27B: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==31477==by 0x400986: MAIN__ (c0.f90:11) ==31477==by 0x400C9E: main (c0.f90:13) ==31477== ==31477== 1,200 bytes in 100 blocks are definitely lost in loss record 2 of 2 ==31477==at 0x4C2C27B: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==31477==by 0x400898: scalar_times_point.1878 (c0.f90:27) ==31477==by 0x400C0E: MAIN__ (c0.f90:17) ==31477==by 0x400C9E: main (c0.f90:13) The first one is the ALLOCATE in the main program, which (according to F08) is *not* required to be auto-deallocated (4.8 does it, but 4.9 doesn't, so this explains the difference between the two). This is not a bug. The second one is the allocate-on-assignment inside the function, which nevers gets freed. This *is* a bug. What should be done is: Create a temporary for the function result and free it after the call. This is also one of the cases where finalization still needs to be handled (cf. PR 37336).
[Bug fortran/57798] [4.8 Regression] Incorrect handling of sum over first dimension of a product of automatic arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57798 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Summary|[4.8/4.9 Regression]|[4.8 Regression] Incorrect |Incorrect handling of sum |handling of sum over first |over first dimension of a |dimension of a product of |product of automatic arrays |automatic arrays --- Comment #6 from Mikael Morin mikael at gcc dot gnu.org --- Author: mikael Date: Fri Aug 23 17:49:39 2013 New Revision: 201947 URL: http://gcc.gnu.org/viewcvs?rev=201947root=gccview=rev Log: fortran/ PR fortran/57798 * trans-array.c (gfc_conv_ss_startstride, set_loop_bounds, gfc_set_delta): Generate preliminary code before the outermost loop. testsuite/ PR fortran/57798 * gfortran.dg/inline_sum_5.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/inline_sum_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog
[Bug libmudflap/58232] New: False mudflap positive on std::setw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58232
Bug ID: 58232
Summary: False mudflap positive on std::setw
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libmudflap
Assignee: unassigned at gcc dot gnu.org
Reporter: andrey.vihrov at gmail dot com
Created attachment 30694
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30694action=edit
Preprocessed source
Compiling and running the following code with g++ -O2 -Wall -Wextra -fmudflap
-lmudflap seems to produce a false mudflap violation positive:
#include iostream
#include iomanip
int main()
{
std::cout std::setw(6);
}
Program output:
***
mudflap violation 1 (check/read): time=1377279836.003018 ptr=0x7fec50b2cd00
size=8
pc=0x7fec50b50208 location=`/usr/include/c++/4.8.1/iomanip:237:7 (main)'
/usr/lib/libmudflap.so.0(__mf_check+0x18) [0x7fec50b50208]
./a.out(main+0x8e) [0x400a9e]
/usr/lib/libc.so.6(__libc_start_main+0xf5) [0x7fec4ffa1bc5]
number of nearby objects: 0
gcc -v is:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-4.8-20130725/configure
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl
--disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default
--enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu
--disable-install-libiberty --enable-multilib --disable-libssp --disable-werror
--enable-checking=release
Thread model: posix
gcc version 4.8.1 20130725 (prerelease) (GCC)
[Bug c++/57610] Reference initialized with temporary instead of sub-object of conversion result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610
Hubert Tong hstong at ca dot ibm.com changed:
What|Removed |Added
CC||hstong at ca dot ibm.com
--- Comment #8 from Hubert Tong hstong at ca dot ibm.com ---
Affects the candidate list for direct binding to a result of a conversion.
struct Z { };
struct A {
operator Z () const = delete; // GCC like this
operator Z();
};
void zip() {
Z x = A();
}
[Bug fortran/58233] New: null pointer cm in gfc_conv_structure at fortran/trans-expr.c:6132
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58233 Bug ID: 58233 Summary: null pointer cm in gfc_conv_structure at fortran/trans-expr.c:6132 Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com ! null pointer cm in gfc_conv_structure at fortran/trans-expr.c:6132 ! if (!c-expr || (gcc_assert(cm),(cm-attr.allocatable ! cm-attr.flavor != FL_PROCEDURE))) ! compiling the following type t integer g end type type(t) :: u=t(1) data u%g /2/ ! should emit diagnostic here end To show the null pointer I added a gcc_assert(cm) !gfbug63.f: In function ‘MAIN__’: !gfbug63.f:2:0: internal compiler error: in gfc_conv_structure, at fortran/trans-expr.c:6132 ! type t ! ^ !0x5ba439 gfc_conv_structure(gfc_se*, gfc_expr*, int) !../../gcc-4.8.1/gcc/fortran/trans-expr.c:6132 !0x5ba6a0 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) !../../gcc-4.8.1/gcc/fortran/trans-expr.c:5690 !0x5aa1bd gfc_get_symbol_decl(gfc_symbol*) !../../gcc-4.8.1/gcc/fortran/trans-decl.c:1501 !0x5aab2f generate_local_decl !../../gcc-4.8.1/gcc/fortran/trans-decl.c:4606 !0x57e133 do_traverse_symtree !../../gcc-4.8.1/gcc/fortran/symbol.c:3575 !0x5aeaf2 generate_local_vars !../../gcc-4.8.1/gcc/fortran/trans-decl.c:4765 !0x5aeaf2 gfc_generate_function_code(gfc_namespace*) !../../gcc-4.8.1/gcc/fortran/trans-decl.c:5339 !0x552ab0 translate_all_program_units !../../gcc-4.8.1/gcc/fortran/parse.c:4474 !0x552ab0 gfc_parse_file() !../../gcc-4.8.1/gcc/fortran/parse.c:4688 !0x58ddf5 gfc_be_parse_file !../../gcc-4.8.1/gcc/fortran/f95-lang.c:189 !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 c++/57610] Reference initialized with temporary instead of sub-object of conversion result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610 --- Comment #9 from Hubert Tong hstong at ca dot ibm.com --- CWG 1604 may address the issues with performance and slicing mentioned in CWG 1287 which led to CWG 1650.
[Bug preprocessor/39029] #pragma once is not exported from the precompiled headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39029 Johan Boulé bohan.gnu at retropaganda dot info changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #6 from Johan Boulé bohan.gnu at retropaganda dot info --- I highly suspect it was caused by having two copies of the same header files: - one in the source tree, - the other in a staged-install include dir. The PCH would have been built with the one in the source tree. And later, when trying to use the PCH, some -I flag was pointing to the staged-install include dir, not the original source tree. GCC would then see these are different headers than the one in the PCH, which is technically correct. No bug in GCC here. It's a build-system bug.
[Bug inline-asm/58234] New: In-line asm version of __FD_ZERO in /usr/include/bits/select.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58234
Bug ID: 58234
Summary: In-line asm version of __FD_ZERO in
/usr/include/bits/select.h
Product: gcc
Version: 4.4.7
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: baker at usgs dot gov
I encountered a run-time error using the -check=uninit Intel icc compiler
option on Linux:
Run-Time Check Failure: The variable '__d1' is being used without being
initialized
I tracked the problem to the FD_ZERO macro, which is ultimately expanded using
the __FD_ZERO macro in /usr/include/bits/select.h. A very simple program will
trigger the run-time failure:
#include sys/select.h
int main( void ) {
fd_set rfds;
FD_ZERO( rfds );
return 0;
}
Compiled with:
# icc -check=uninit intel.c
The fix is to disable the in-line asm code for __FD_ZERO; -no-gcc will suffice:
# icc -no-gcc -check=uninit intel.c
That is fine for this case. But the code I am working with needs other GNUC
header options that also get disabled when -no-gcc is used. If I add -no-gcc,
I get lots of compilation errors.
I realize this is not technically a GCC library/headers error. I think the
Intel icc compiler does not properly account for in-line asm side-effects in
its uninitialized variable tracking.
However, I decided to see if I could make the __FD_ZERO macro asm work. I was
able to rearrange the in-line asm for a workaround in this case. I think this
is an improvement, and also cures a subtle flaw in the original that (luckily)
makes absolutely no difference.
The original __FD_ZERO macro definition (in /usr/include/bits/select.h) is:
# define __FD_ZERO(fdsp) \
do { \
int __d0, __d1; \
__asm__ __volatile__ (cld; rep; __FD_ZERO_STOS \
: =c (__d0), =D (__d1) \
: a (0), 0 (sizeof (fd_set) \
/ sizeof (__fd_mask)), \
1 (__FDS_BITS (fdsp)[0]) \
: memory); \
} while (0)
I cannot tell exactly where in the expansion the Intel run-time error occurs --
gdb shows ?? for the backtrace beyond the Intel __intel_rtc_uninit_use()
service routine (compiled with -g):
(gdb) bt
#0 0x00130430 in __kernel_vsyscall ()
#1 0x001a3b11 in raise () from /lib/libc.so.6
#2 0x001a53ea in abort () from /lib/libc.so.6
#3 0x080489e1 in __intel_rtc_uninit_use ()
#4 0x0001 in ?? ()
#5 0x in ?? ()
The assembly language generated by gcc -O0 (-m32 or -m64) always includes a
store into __d0 and __d1 after the execution of the stosl/stosq instruction.
Maybe it is that store which is tripping up the Intel code.
I rewrote the asm to remove __d0 and __d1, since they go out-of-scope anyway
after the asm executes:
# define __FD_ZERO(fdsp) \
do {\
__asm__ __volatile__ (cld; rep; __FD_ZERO_STOS \
: \
: a (0), \
c (sizeof (fd_set) / sizeof (__fd_mask)), \
D (__FDS_BITS (fdsp)[0]) \
: memory);\
} while (0)
This generated slightly different code, which I believe is correct.
Here is the original assembly output for gcc -m32 and gcc -m64:
Original __FD_ZERO, gcc -m32
.filejunk.c
.text
.globl main
.typemain, @function
main:
pushl%ebp
movl%esp, %ebp
pushl%edi
subl$144, %esp
movl$0, %eax
movl$32, %ecx
leal-140(%ebp), %edx
movl%edx, %edi
#APP
# 45 junk.c 1
cld; rep; stosl
# 0 2
#NO_APP
movl%edi, %edx
movl%ecx, -12(%ebp)
movl%edx, -8(%ebp)
movl$0, %eax
addl$144, %esp
popl%edi
popl%ebp
ret
.sizemain, .-main
.identGCC: (GNU) 4.4.7 20120313 (Red Hat 4.4.7-3)
.section.note.GNU-stack,,@progbits
Original __FD_ZERO, gcc -m64
.filejunk.c
.text
.globl main
.typemain, @function
main:
.LFB0:
.cfi_startproc
pushq%rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
pushq%rbx
subq$32, %rsp
movl$0, %eax
movl$16, %edx
leaq-160(%rbp), %rbx
.cfi_offset 3, -24
movq%rdx, %rcx
movq%rbx, %rdi
#APP
# 45 junk.c 1
cld; rep; stosq
# 0 2
#NO_APP
movl%edi, %eax
movl%ecx, %edx
movl%edx, -24(%rbp)
movl%eax, -20(%rbp)
movl$0, %eax
[Bug inline-asm/58234] In-line asm version of __FD_ZERO in /usr/include/bits/select.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58234 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- First FD_ZERO comes from glibc so this is not a GCC bug. Second this question should go to ICC rather than GCC since it is their compiler which is causing the complaint in the end rather than GCC. And third the inline-asm is correct to begin with as both rcx and rdi are changed by rep;stosl/stosq so having an output constraints is correct; otherwise the compiler could decide to reuse those values that were in them.
[Bug c/58235] New: Missing diagnostic on assignment to array in c89
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58235
Bug ID: 58235
Summary: Missing diagnostic on assignment to array in c89
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: olivier.gay at a3 dot epfl.ch
struct bla
{
int x[1];
} s = {{0}};
struct bla foo(void)
{
return s;
}
void bar(void)
{
int c[1];
c = foo().x;
}
gcc in c89 mode (-std=c89 -Wall -pedantic) does not issue a diagnostic for the
assignment to a non-modifiable lvalue in bar function. -std=c99 or -std=c11 do
issue the required diagnostic.
[Bug target/58208] dequestd::string 32-bit -O3 bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58208 Tammy Hsu tammy at Cadence dot COM changed: What|Removed |Added Severity|normal |major --- Comment #2 from Tammy Hsu tammy at Cadence dot COM --- Can you assign someone to take a look this issue?
[Bug inline-asm/58234] In-line asm version of __FD_ZERO in /usr/include/bits/select.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58234 --- Comment #2 from Larry Baker baker at usgs dot gov --- Andrew, Thank you for your prompt reply. Fair enough. Can you direct me to where glibc bugs are reported? I have already filed a bug report with Intel. The in-line asm is not quite correct. But the flaw is benign. I would like to repair my replacement asm. The issue you raised is exactly what I am concerned about. Can you tell me how it is possible to specify the clobber side effects without requiring output constraints? Is it legal to specify output constraints without variables? I tried following the example 4 in the GCC-Inline-Assembly-HOWTO.html, which looks extremely similar to what I want. But, I received the error I wrote about. Thanks for your time. Larry Baker US Geological Survey
[Bug target/58208] dequestd::string 32-bit -O3 bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58208 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Severity|major |normal
[Bug inline-asm/58234] In-line asm version of __FD_ZERO in /usr/include/bits/select.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58234 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Larry Baker from comment #2) Andrew, Thank you for your prompt reply. Fair enough. Can you direct me to where glibc bugs are reported? Except there is no bug in glibc's headers as I explained.
[Bug c/58235] Missing diagnostic on assignment to array in c89
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58235 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This seems correct: See also bug 461. non-lvalue arrays do not decay to pointers in C90/C89.
[Bug inline-asm/58234] In-line asm version of __FD_ZERO in /usr/include/bits/select.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58234 --- Comment #4 from Larry Baker baker at usgs dot gov --- Actually, there is: the useless movl instead of a movq of the updated address pointer into __d1 on x86_64. But, that is a benign flaw. Can you answer either of my questions?
[Bug c/58235] Missing diagnostic on assignment to array in c89
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58235 --- Comment #2 from Olivier Gay olivier.gay at a3 dot epfl.ch --- Still, constraint of assignment (c90, 6.3.16) requires the left operand of assignment to be a modifiable lvalue. But c object array is not a modifiable lvalue as arrays are not modifiable lvalues (6.2.2.1).
[Bug inline-asm/58234] In-line asm version of __FD_ZERO in /usr/include/bits/select.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58234 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- Can you tell me how it is possible to specify the clobber side effects without requiring output constraints? It is too hard if you have inputs in those registers too. You could push/pop on the stack those registers if you want instead Is it legal to specify output constraints without variables? No. the useless movl instead of a movq of the updated address pointer into __d1 on x86_64. That is due to use of int rather than long/long long but really one instruction is not an issue really and the resulting of that instruction is not used at all.
[Bug inline-asm/58234] In-line asm version of __FD_ZERO in /usr/include/bits/select.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58234 --- Comment #6 from Larry Baker baker at usgs dot gov --- Thank you. The example I found (mov_blk) that does not use output constraints, but specifies that the input registers are clobbered, is from a 2003 document. It too fails using today's gcc. I appreciate your time.
[Bug libgcc/58061] internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58061 --- Comment #3 from Whitequill Riclo whitequill at abstractions dot me --- I can not proceseed with a project due to this bug, is there anything I can do in the mean time?
[Bug c/58235] Missing diagnostic on assignment to array in c89
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58235 farouk jouti farouk.jouti at live dot co.uk changed: What|Removed |Added CC||farouk.jouti at live dot co.uk --- Comment #3 from farouk jouti farouk.jouti at live dot co.uk --- http://stackoverflow.com/questions/18412094/a-legal-lvalue-array-is-it-possible/18413586?noredirect=1#18413586
[Bug c/58235] Missing diagnostic on assignment to array in c89
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58235 --- Comment #4 from farouk jouti farouk.jouti at live dot co.uk --- the link contains all the necessary information about the bug (just check the comments and answers) ;)
[Bug libstdc++/56779] [4.8/4.9 Regression] libstdc++.so: undefined reference to `libintl_textdomain'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56779 --- Comment #4 from Dâniel Fraga fragabr at gmail dot com --- Nobody?
[Bug c++/54485] g++ should diagnose default arguments in out-of-line definitions for template class member functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54485 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.9.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
