[Bug fortran/40006] allow type cheating for procedures with an implicit interface
--- Comment #9 from pault at gcc dot gnu dot org 2009-05-12 06:07 --- Since I am working on it, I had better take it :-) Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-12 06:07:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40006
[Bug fortran/40110] New: Bind(C): gfortran rejects the questionable but formally correct INTEGER(C_CHAR)
The following program is formally valid though the use of of C_CHAR as INTEGER kind is doubtful and will not work on all systems. (C_CHAR is for CHARACTERS; there is C_SIGNED_CHAR for INTEGERS, which may or may not have the same kind number; in gfortran is has.) However, it is simply a PARAMETER (of value 1) and as an integer of kind=1 exists, it may not be rejected according to the standard. gfortran currently rejects it. It should print a big warning but it is formally correct. See also: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/026a820711ab1e70 use iso_c_binding implicit none Character(kind=c_char):: OK_1 Integer( kind=c_signed_char) :: OK_2 Integer( kind=c_char):: doubtful ! Formally OK, but bad usage print *, 'c_char = ', c_char ! is 1 print *, 'c_signed_char = ', c_signed_char ! is 1 end -- Summary: Bind(C): gfortran rejects the questionable but formally correct INTEGER(C_CHAR) Product: gcc Version: unknown Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40110
[Bug target/27308] Compiler generates incorrect code when calling a function with the result of an inline function as parameter
--- Comment #7 from ramana at gcc dot gnu dot org 2009-05-12 09:36 --- Confirmed with r147377 -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-12 09:36:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
[Bug c++/40111] New: for loop wrong code generation
This for loop for(unsigned i=object::min(_digits, (int)NATIVE_DIGITS);iNATIVE_DIGITS;++i) inside_digit[i]=0; generates the following incorrect code. .L182: .loc 12 59 0 movl-8(%rbp), %eax movq-24(%rbp), %rdx mov %eax, %eax movq$0, (%rdx,%rax,8) .loc 12 58 0 addl$1, -8(%rbp) .L181: cmpl$3, -8(%rbp) jbe .L182 jmp .L183 This code always runs the body at least once, which, I think is incorrect. I'm sorry I cannot include a simple test case to reproduce it, but it is very hard to trigger and trying to isolate it just makes it go away. -- Summary: for loop wrong code generation Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: face dot mitev at gmail dot com GCC build triplet: x86_64 linux gnu GCC host triplet: x86_64 linux gnu GCC target triplet: x86_64 linux gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40111
[Bug rtl-optimization/40107] [4.5 Regression] gcc.c-torture/execute/builtins/memmove.c and gcc.c-torture/execute/builtins/memmove-chk.c fail at -O1 on spu-elf
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40107
[Bug c++/40111] for loop wrong code generation
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-12 09:51 --- We need a testcase that is reproducible. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40111
[Bug c++/40111] for loop wrong code generation
--- Comment #2 from face dot mitev at gmail dot com 2009-05-12 09:54 --- Not a gcc bug, sorry for the confusion. -- face dot mitev at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40111
[Bug target/35296] init_expr_once suboptimal for Thumb
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-12 10:05 --- init_expr_once is now renamed to init_expr_target, though I see that the comments / code you refer to in the bug report still exist . Can you give any examples of optimizations that might be enabled if we went ahead and tried to get this going ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35296
[Bug c++/40112] New: C++, __attribute__((__progmem__)) lost in typedefs.
data incorrectly placed into .data or .rodata instead of .progmem. This makes
impossible using avr-libc predefined types (avr/pgmspace.h).
test.cpp:
char __attribute__((__progmem__)) Test1[] = test1;
char const __attribute__((__progmem__)) Test2[] = test2;
typedef char __attribute__((__progmem__)) prog_char;
prog_char Test3[] = Test3;
prog_char const Test4[] = Test4;
void const * array[] =
{
Test1, Test2, Test3, Test4
};
listing:
8.global Test1
9.section.progmem.data,a,@progbits
12Test1:
13 7465 7374 .string test1
13 3100
14.global Test3
15.data
18Test3:
19 5465 7374 .string Test3
19 3300
20.global array
23array:
24 0006 .word Test1
25 0008 .word _ZL5Test2
26 000a .word Test3
27 000c .word _ZL5Test4
28.section.progmem.data
31_ZL5Test2:
32 0006 7465 7374 .string test2
32 3200
33.data
36_ZL5Test4:
37 000e 5465 7374 .string Test4
37 3400
First two forms leads to correct placement, but generates incorrect warning
(bug 34734)
--
Summary: C++, __attribute__((__progmem__)) lost in typedefs.
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sb-sf at users dot sourceforge dot net
GCC host triplet: x86
GCC target triplet: AVR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40112
[Bug c++/40113] New: C++, -fdata-sections not works with .progmem data
all data placed to single .progmem.data section.
test.cpp:
char __attribute__((__progmem__)) Test1[] = test1;
char const __attribute__((__progmem__)) Test2[] = test2;
void const * array[] =
{
Test1, Test2
};
cmd line:
avr-gcc -mmcu=atmega8 -fdata-sections -Wall -Os -Wa,-ahlmsd=test.lst -c
test.cpp -o test.o
listing:
8.global Test1
9.section.progmem.data,a,@progbits
12Test1:
13 7465 7374 .string test1
13 3100
14.global array
15.section.data.array,aw,@progbits
18array:
19 .word Test1
20 0002 .word _ZL5Test2
21.section.progmem.data
24_ZL5Test2:
25 0006 7465 7374 .string test2
25 3200
here array placed into unique section .data.array, while Test1 and Test2 into
single section .progmem.data
--
Summary: C++, -fdata-sections not works with .progmem data
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sb-sf at users dot sourceforge dot net
GCC host triplet: x86
GCC target triplet: AVR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40113
[Bug c++/40114] New: Incomplete flow analysis in template produces spurious diagnostic
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.3.3/configure --prefix=/mingw --build=mingw32
--enable-languages=c,ada,c++,fortran,objc,obj-c++
--with-bugurl=http://www.tdragon.net/recentgcc/bugs.php --disable-nls
--disable-win32-registry --enable-libgomp --disable-werror --enable-threads
--disable-symvers --enable-cxx-flags='-fno-function-sections
-fno-data-sections' --enable-fully-dynamic-string
--enable-version-specific-runtime-libs --enable-sjlj-exceptions
--with-pkgversion='4.3.3-tdm-1 mingw32'
Thread model: win32
gcc version 4.3.3 (4.3.3-tdm-1 mingw32)
The following code produces an incorrect diagnostic
warning: left shift count = width of type
template unsigned M, unsigned N
unsigned frob(unsigned q)
{
if(M N)
return (q (M-N));
else
return (q (N-M));
}
int main()
{
return frob3,2 (7U);
}
This happens at -O0 and -O3, with default warnings.
Since I compile with -Werror, this is a minor pain (although it can be worked
around easily). Since M and N are template parameters, is it possible for flow
analysis to deduce that this is can not actually happen?
(The code on which this is based comes from a routine converting between fixed
point numbers with different radix position).
--
Summary: Incomplete flow analysis in template produces spurious
diagnostic
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gowen at innovative-technology dot co dot uk
GCC build triplet: 4.3.3-tdm-1 mingw32
GCC host triplet: Win32
GCC target triplet: mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40114
[Bug c/40115] New: -O2 and higher causes wrong label address calculation
The following program:
cat -n main.c
1 #include stdio.h
2
3
4 int main()
5{
6__label__ lab3;
7__label__ lab4;
8
9int i = 0;
10
11i++;
12lab1: fprintf(stderr, i=%d\n, i);
13
14i++;
15lab2: fprintf(stderr, i=%d\n, i);
16
17i++;
18lab3: fprintf(stderr, i=%d\n, i);
19
20i++;
21lab4: fprintf(stderr, i=%d\n, i);
22
23fprintf(stderr, lab1=%08x\n, (unsigned)lab1);
24fprintf(stderr, lab2=%08x\n, (unsigned)lab2);
25fprintf(stderr, lab3=%08x\n, (unsigned)lab3);
26fprintf(stderr, lab4=%08x\n, (unsigned)lab4);
27
28return 0;
29}
after being compiled as
/mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.3.3/binsh/gcc -O1 -Wall -Wextra
main.c -o main_-O1
produces:
./main_-O1
i=1
i=2
i=3
i=4
lab1=08048435
lab2=08048452
lab3=0804846f
lab4=0804848c
which is correct in a sense all the labels have different addresses.
When compiled as
/mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.3.3/binsh/gcc -O2 -Wall -Wextra
main.c -c -o main_-O2.o
it produces
./main_-O2
i=1
i=2
i=3
i=4
lab1=08048430
lab2=08048430
lab3=08048430
lab4=08048430
,
which is wrong in the sense all the addresses are the same.
Please note that labels have intentionally been put against 'fprintf'
statements which are _not_ eliminated by optimization ('objdump' easily proves
this).
I have read pages ## 246 .. 248 in
http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc.pdf
, they don't mention optimizations (or did I miss it ?).
The problem also exists with gcc-3.4.6.
--
Summary: -O2 and higher causes wrong label address calculation
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sergstesh at yahoo dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40115
[Bug target/35296] init_expr_once suboptimal for Thumb
--- Comment #2 from drow at gcc dot gnu dot org 2009-05-12 11:36 --- Sorry, I don't know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35296
[Bug target/37197] -msse4 ICE on __builtin_parityl
--- Comment #6 from uros at gcc dot gnu dot org 2009-05-12 11:43 --- Subject: Bug 37197 Author: uros Date: Tue May 12 11:42:53 2009 New Revision: 147429 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147429 Log: PR target/37197 * config/i386/driver-i386.c (processor_signatures): New enum. (SIG_GEODE): Move from vendor_signatures to processor_signatures. (host_detect_local_cpu): For SIG_AMD vendor, check for SIG_GEODE processor signature to detect geode processor. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/driver-i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37197
[Bug middle-end/40106] Time increase with inlining for the Polyhedron test air.f90
--- Comment #1 from hubicka at gcc dot gnu dot org 2009-05-12 11:52 --- Hmm, the inlined functions has loop depth of 4, that makes it predicted to iterate quite few times. My guess would be that inlining increases loop depth that in turn makes GCC to conclude that one of loops that are in fact internal hot loops are cold. decreasing --param hot-bb-frequency-fraction might help in this case. I've seen this in past, just hope it is quite rare. If we find enough testcases like this, it might make sense to alter the predicate deciding on hot-bb to always consider innermost loops hot no mater on their relative frequency. Woud need to have flag on BB or loop structure always available though. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106
[Bug target/39714] [meta-bug] cond-optab fallout meta-bug
--- Comment #1 from bonzini at gnu dot org 2009-05-12 12:04 --- If you work between r147424 and r147425, there should be no other spurious changes to the code besides those described in the bug reports. -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-12 12:04:29 date|| Summary|cond-optab fallout meta-bug |[meta-bug] cond-optab ||fallout meta-bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39714
[Bug target/39715] [4.5 Regression][cond-optab] extra sign extensions on Thumb
-- bonzini at gnu dot org changed: What|Removed |Added Summary|[cond-optab] extra sign |[4.5 Regression][cond-optab] |extensions on Thumb |extra sign extensions on ||Thumb Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39715
[Bug target/39717] [4.5 Regression][cond-optab] CSE does not put subregs into COMPAREs on many CC0 machines
-- bonzini at gnu dot org changed: What|Removed |Added Priority|P3 |P4 Summary|[cond-optab] CSE does not |[4.5 Regression][cond-optab] |put subregs into COMPAREs on|CSE does not put subregs |many CC0 machines |into COMPAREs on many CC0 ||machines Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39717
[Bug target/39716] [4.5 Regression][cond-optab] worse MAX_EXPR expansion for Thumb
-- bonzini at gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39716
[Bug target/39718] [4.5 Regression][cond-optab] crash on crx in IRA
-- bonzini at gnu dot org changed: What|Removed |Added Priority|P3 |P4 Summary|[cond-optab] crash on crx in|[4.5 Regression][cond-optab] |IRA |crash on crx in IRA Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39718
[Bug target/39719] [4.5 Regression][cond-optab] uses libcall instead of branch on m68hc11
-- bonzini at gnu dot org changed: What|Removed |Added Priority|P3 |P4 Summary|[cond-optab] uses libcall |[4.5 Regression][cond-optab] |instead of branch on m68hc11|uses libcall instead of ||branch on m68hc11 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39719
[Bug target/39720] [4.5 Regression][cond-optab] combine does not use LOAD_EXTEND_OP?
-- bonzini at gnu dot org changed: What|Removed |Added Priority|P3 |P4 Summary|[cond-optab] combine does |[4.5 Regression][cond-optab] |not use LOAD_EXTEND_OP? |combine does not use ||LOAD_EXTEND_OP? Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39720
[Bug target/39721] [4.5 Regression][cond-optab] worse register allocation on mn10300
-- bonzini at gnu dot org changed: What|Removed |Added Priority|P3 |P4 Summary|[cond-optab] worse register |[4.5 Regression][cond-optab] |allocation on mn10300 |worse register allocation on ||mn10300 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39721
[Bug target/37197] -msse4 ICE on __builtin_parityl
--- Comment #7 from ubizjak at gmail dot com 2009-05-12 12:07 --- Oops, wrong PR number. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37197
[Bug target/39722] [4.5 Regression][cond-optab] worse code with bitfields on v850, mn10300, avr
-- bonzini at gnu dot org changed: What|Removed |Added Priority|P3 |P4 Summary|[cond-optab] worse code with|[4.5 Regression][cond-optab] |bitfields on v850, mn10300, |worse code with bitfields on |avr |v850, mn10300, avr Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39722
[Bug target/39723] [4.5 Regression][cond-optab] worse code with long long shifts on v850
-- bonzini at gnu dot org changed: What|Removed |Added Priority|P3 |P4 Summary|[cond-optab] worse code with|[4.5 Regression][cond-optab] |long long shifts on v850|worse code with long long ||shifts on v850 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39723
[Bug target/39724] [4.5 Regression][cond-optab] reload_cse_simplify_operands complicates code on vax
-- bonzini at gnu dot org changed: What|Removed |Added Priority|P3 |P4 Summary|[cond-optab]|[4.5 Regression][cond-optab] |reload_cse_simplify_operands|reload_cse_simplify_operands |complicates code on vax |complicates code on vax Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39724
[Bug target/39725] [4.5 Regression][cond-optab] MIPS pessimizations on floating-point
-- bonzini at gnu dot org changed: What|Removed |Added Summary|[cond-optab] MIPS |[4.5 Regression][cond-optab] |pessimizations on floating- |MIPS pessimizations on |point |floating-point Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39725
[Bug target/37179] gcc emits bad opcode 'ffreep'
--- Comment #14 from ubizjak at gmail dot com 2009-05-12 12:08 --- Author: uros Date: Tue May 12 11:42:53 2009 New Revision: 147429 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147429 Log: PR target/37197 * config/i386/driver-i386.c (processor_signatures): New enum. (SIG_GEODE): Move from vendor_signatures to processor_signatures. (host_detect_local_cpu): For SIG_AMD vendor, check for SIG_GEODE processor signature to detect geode processor. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/driver-i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37179
[Bug target/39726] [4.5 Regression][cond-optab] ColdFire pessimizations on QImode/HImode tests
-- bonzini at gnu dot org changed: What|Removed |Added Summary|[cond-optab] ColdFire |[4.5 Regression][cond-optab] |pessimizations on |ColdFire pessimizations on |QImode/HImode tests |QImode/HImode tests Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39726
[Bug ada/40116] New: GNAT BUG get_memory_rtx, at builtins.c:1087
Did some research, I see a bug for this, but it is closed as fixed in 4.2, I have updated to 4.2.4 (Ubuntu Hardy Updates), but still have the problem. If you need any other info, let me know and I'll be happy to provide it. The source code listing (gcc said to cat about 2 lines of our code) was too long to submit in the bug report, so not sure what to do about that. Command Line: gcc-4.2 -c -I./lss_executive_source/ -g -fstack-check -O1 -I/DataShare/csci_home/floristlib -I./lss_executive_source -I./lss_hci_source -I./lss_lib -I./mm_executive_source -I./mm_hci_source -I./lib -I- -o /home/users/jrice/mm/lss_executive_source/hci_server.o ./lss_executive_source/hci_server.adb Bug Box: +===GNAT BUG DETECTED==+ | 4.2.4 (Ubuntu 4.2.4-1ubuntu3) (i486-pc-linux-gnu) GCC error: | | in get_memory_rtx, at builtins.c:1087| | Error detected at hci_server.adb:2060:1 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc-4.2 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ gcc -v output: Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3) -- Summary: GNAT BUG get_memory_rtx, at builtins.c:1087 Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: critical Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: james dot rice2 at navy dot mil GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40116
[Bug ada/40116] GNAT BUG get_memory_rtx, at builtins.c:1087
--- Comment #1 from charlet at gcc dot gnu dot org 2009-05-12 12:32 --- Well, there's nothing we can do without a stand alone (if possible simplified) reproducer. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40116
[Bug fortran/40117] New: F2008: Type-bound procedure: allow list after PROCEDURE
Put it here before it goes out of sight and submerges as minor item in the F2008 standard: TYPE T CONTAINS PROCEDURE :: foo, bar is invalid in F2003 since no list is allowed, but with F2008 there will be a list allowed; see item 6 - Paper 09-208r1 at http://j3-fortran.org/pipermail/j3/attachments/20090512/817b9628/attachment.txt, which is the following paper: http://j3-fortran.org/doc/year/09/09-208r2.txt Disclaimer: Fortran 2008 is not yet a formal standard, the route to it is listed here: ftp://ftp.nag.co.uk/sc22wg5/N1751-N1800/N1781.txt -- Summary: F2008: Type-bound procedure: allow list after PROCEDURE Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40117
[Bug bootstrap/40118] New: cond-optab breaks powerpc bootstrap
The powerpc bootstrap fails due to an inner block that has: rtx op1 = XVECEXP (op1, 0, 0); and this triggers the error: error: op1 may be used uninitialized in this function -- Summary: cond-optab breaks powerpc bootstrap Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: meissner at linux dot vnet dot ibm dot com GCC build triplet: powerpc64-unknown-linux-gnu GCC host triplet: powerpc64-unknown-linux-gnu GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40118
[Bug bootstrap/40118] cond-optab breaks powerpc bootstrap
--- Comment #1 from meissner at gcc dot gnu dot org 2009-05-12 12:52 --- Subject: Bug 40118 Author: meissner Date: Tue May 12 12:52:45 2009 New Revision: 147434 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147434 Log: Fix PR bootstrap/40118 Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40118
[Bug bootstrap/40118] cond-optab breaks powerpc bootstrap
--- Comment #2 from meissner at linux dot vnet dot ibm dot com 2009-05-12 12:54 --- Created an attachment (id=17854) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17854action=view) Patch to fix bootstrap error message. Patch applied to the tree as obvious. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40118
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #11 from luisgpm at linux dot vnet dot ibm dot com 2009-05-12 12:55 --- Any updates? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2
--- Comment #11 from danglin at gcc dot gnu dot org 2009-05-12 13:06 --- Build no longer ICEs. I believe this PR was fixed by the following change: 2009-05-10 Michael Matz m...@suse.de PR target/40031 * config/arm/arm.c (require_pic_register): Emit on entry edge, not at entry of function. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39978
[Bug middle-end/40119] New: ICE with --param hot-bb-frequency-fraction=0
-- Summary: ICE with --param hot-bb-frequency-fraction=0 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40119
[Bug middle-end/40119] ICE with --param hot-bb-frequency-fraction=0
--- Comment #1 from dominiq at lps dot ens dot fr 2009-05-12 13:11 --- Since the manual only gives: hot-bb-frequency-fraction Select fraction of the maximal frequency of executions of basic block in function given basic block needs to have to be considered hot for --param hot-bb-frequency-fraction without giving the allowed range, I have tried --param hot-bb-frequency-fraction=0 and it gave: air.f90:1027: internal compiler error: Floating point exception -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40119
[Bug fortran/39865] ICE in gfc_conv_scalarized_array_ref
--- Comment #11 from jakub at gcc dot gnu dot org 2009-05-12 13:19 --- Partial fix: http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00637.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39865
[Bug middle-end/40106] Time increase with inlining for the Polyhedron test air.f90
--- Comment #2 from dominiq at lps dot ens dot fr 2009-05-12 13:23 --- decreasing --param hot-bb-frequency-fraction might help in this case. I have tried --param hot-bb-frequency-fraction=1 (which seems the smallest possible value, see pr40119), but it did not changed anything. What I find very surprising is that the ~15% slow-down appears as soon as one call is inlined, but without further slow-down with more inlining (I have tested 4 and -fwhole-file inline 28 of them). If the block was misoptimized I would expect a slow-down increasing with the number of inlined calls. Could the problem be related to cache management instead (L1, since L2 is 4Mb on my core2Duo)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106
[Bug c/40120] New: aliasing of __m128i is not allowed
emmintrin.h says
/* The Intel API is flexible enough that we must allow aliasing with other
vector types, and their scalar components. */
typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));
but the following testcase fails:
#include emmintrin.h
#include stdio.h
int main()
{
const __m128i d = _mm_set1_epi32(1);
int i;
for (i = 0; i 4; ++i) {
if (((const int *)d)[i] != 1) {
printf(%d %d %d %d\n,
((const int *)d)[0],
((const int *)d)[1],
((const int *)d)[2],
((const int *)d)[3]);
return 1;
}
}
return 0;
}
It does not fail when compiled with -fno-strict-aliasing. It also does not fail
when using __m128, _mm_set1_ps and casts to float *.
According to my tests the above does not fail with gcc 4.2, and still fails
with 4.4.0.
--
Summary: aliasing of __m128i is not allowed
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kretz at kde dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40120
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #12 from matz at gcc dot gnu dot org 2009-05-12 13:37 --- The problem is that for PHI node expansion something has to be inserted on the backedge of a single BB loop, splitting it into two BBs (where one just contains one instruction). Something in the RTL passes then moves stuff into that first BB somehow limiting the scheduler then. I'm working on a fix. Earlier compilers contained a hack for this (because swing modulo scheduling can only deal with single BB loops), which I removed as part of SSA expand, see PR34263 and PR19038. I'm working on an alternative solution that places the copy somewhere more intelligently than now. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-12 13:37:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug middle-end/40121] New: [4.5 Regression] Revision 147418 failed gcc.target/i386/ssefp-[12].c
Revision 147418: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00393.html caused: FAIL: gcc.target/i386/ssefp-1.c scan-assembler maxsd FAIL: gcc.target/i386/ssefp-2.c scan-assembler minsd on Linux/ia32 and Linux/x86-64. -- Summary: [4.5 Regression] Revision 147418 failed gcc.target/i386/ssefp-[12].c Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40121
[Bug middle-end/40122] New: missed optimization when using union of __m128i and int[4]
The following testcase
#include emmintrin.h
typedef union {
__m128i v;
int m[4];
} VectorUnion;
VectorUnion one()
{
VectorUnion r = { _mm_set1_epi32(1) };
return r;
}
int main()
{
VectorUnion x = one();
if (0x == _mm_movemask_epi8(_mm_cmpeq_epi32(x.v, x.v))) {
return 0;
}
return 1;
}
compiles (-Wall -Wextra -O2 -mssse3) to
004004d0 main:
4004d0: 66 0f 6f 05 38 01 00 00 movdqa 0x138(%rip),%xmm0
4004d8: 66 0f 7f 44 24 d8 movdqa %xmm0,-0x28(%rsp)
4004de: 48 8b 44 24 d8 mov-0x28(%rsp),%rax
4004e3: 48 89 44 24 e8 mov%rax,-0x18(%rsp)
4004e8: 48 8b 44 24 e0 mov-0x20(%rsp),%rax
4004ed: 48 89 44 24 f0 mov%rax,-0x10(%rsp)
4004f2: 66 0f 6f 44 24 e8 movdqa -0x18(%rsp),%xmm0
4004f8: 66 0f 76 c0 pcmpeqd %xmm0,%xmm0
4004fc: 66 0f d7 c0 pmovmskb %xmm0,%eax
As can be seen the xmm0 register is stored on the stack, then copied via two 64
bit moves on the stack and then, from there, loaded back into xmm0. The values
on the stack are not needed/used later on.
I expected gcc to note those no-op moves and produce code like
movdqa 0x138(%rip),%xmm0
pcmpeqd %xmm0,%xmm0
pmovmskb %xmm0,%eax
--
Summary: missed optimization when using union of __m128i and
int[4]
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kretz at kde dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40122
[Bug middle-end/40121] [4.5 Regression] Revision 147418 failed gcc.target/i386/ssefp-[12].c
--- Comment #1 from bonzini at gnu dot org 2009-05-12 13:52 --- The commit was temporary to more easily pinpoint changes due to the cond-optab branch, and has already been reverted. The two testcases do not fail anymore with current trunk. Thanks! -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40121
[Bug middle-end/40106] Time increase with inlining for the Polyhedron test air.f90
--- Comment #3 from rguenther at suse dot de 2009-05-12 14:47 --- Subject: Re: Time increase with inlining for the Polyhedron test air.f90 On Tue, 12 May 2009, dominiq at lps dot ens dot fr wrote: --- Comment #2 from dominiq at lps dot ens dot fr 2009-05-12 13:23 --- decreasing --param hot-bb-frequency-fraction might help in this case. I have tried --param hot-bb-frequency-fraction=1 (which seems the smallest possible value, see pr40119), but it did not changed anything. What I find very surprising is that the ~15% slow-down appears as soon as one call is inlined, but without further slow-down with more inlining (I have tested 4 and -fwhole-file inline 28 of them). If the block was misoptimized I would expect a slow-down increasing with the number of inlined calls. Could the problem be related to cache management instead (L1, since L2 is 4Mb on my core2Duo)? You may be hitting some analysis limits either for maximum loop depth or similar stuff. There is no other way to analyze what is the difference in optimizations produced. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106
[Bug c++/40114] Incomplete flow analysis in template produces spurious diagnostic
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-12 14:49 --- *** This bug has been marked as a duplicate of 4210 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40114
[Bug middle-end/4210] should not warning with dead code
--- Comment #20 from pinskia at gcc dot gnu dot org 2009-05-12 14:49 --- *** Bug 40114 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gowen at innovative- ||technology dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
[Bug middle-end/39456] Functions/variables of a file in different named sections
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-12 14:51 --- *** Bug 40113 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||sb-sf at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39456
[Bug target/40113] [avr] C++, -fdata-sections not works with .progmem data
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-12 14:51 --- *** This bug has been marked as a duplicate of 39456 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40113
[Bug c/40115] -O2 and higher causes wrong label address calculation
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-12 14:55 --- No labels are not designed that way. They are designed only for jumping and when they are taken the address of, there should only be used for jumping and nothing else. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40115
[Bug libstdc++/39546] parallel mode doesn't support implicit string conversion
--- Comment #22 from singler at gcc dot gnu dot org 2009-05-12 14:57 --- Subject: Bug 39546 Author: singler Date: Tue May 12 14:57:35 2009 New Revision: 147439 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147439 Log: 2009-05-12 Johannes Singler sing...@ira.uka.de PR libstdc++/39546 * include/parallel/algo.h (find_switch): Parametrize binder2nd with const T instead of T. * testsuite/25_algorithms/find/39546.cc: new test case Added: branches/gcc-4_4-branch/libstdc++-v3/testsuite/25_algorithms/find/39546.cc Modified: branches/gcc-4_4-branch/libstdc++-v3/ChangeLog branches/gcc-4_4-branch/libstdc++-v3/include/parallel/algo.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39546
[Bug middle-end/40122] missed optimization when using union of __m128i and int[4]
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-12 15:00 ---
The union copy confuses GCC:
r.v = VIEW_CONVERT_EXPRvector long long int({1, 1, 1, 1});
D.6990 = r;
x = D.6990;
D.6997 = VIEW_CONVERT_EXPRvector int(x.v);
D.6994 = __builtin_ia32_pcmpeqd128 (D.6997, D.6997);
D.7000 = __builtin_ia32_pmovmskb128 (VIEW_CONVERT_EXPRvector
char(VIEW_CONVERT_EXPRvector long long int(D.6994)));
return D.7000 != 65535;
this will likely be fixed with the new SRA or is a duplicate of PR36327.
Martin, can you check this (and maybe add a testcase)?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org, mjambor at suse dot cz
Severity|normal |enhancement
Keywords||missed-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40122
[Bug middle-end/40123] New: [4.5 Regression] Revision 147395 failed libstc++ tests
On Linux/x86-64, with checking enabled, revision 147395 http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00369.html caused FAIL: 26_numerics/random/independent_bits_engine/operators/equal.cc execution test FAIL: 26_numerics/random/independent_bits_engine/operators/serialize.cc execution test with -m32. -- Summary: [4.5 Regression] Revision 147395 failed libstc++ tests Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40123
[Bug target/40120] aliasing of __m128i is not allowed
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-12 15:01 --- The aliasing is directional - you may access ints via a pointer to __m128i but not the other way around. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40120
[Bug ada/40116] GNAT BUG get_memory_rtx, at builtins.c:1087
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-12 15:02 --- GCC 4.2 is no longer maintained, please reproduce with at least GCC 4.3.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40116
[Bug middle-end/40123] [4.5 Regression] Revision 147395 failed libstc++ tests
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40123
[Bug middle-end/40122] missed optimization when using union of __m128i and int[4]
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-12 15:24 --- This is a dup of bug 36327. *** This bug has been marked as a duplicate of 36327 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40122
[Bug tree-optimization/36327] SCCVN should look through struct copies
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-12 15:24 --- *** Bug 40122 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||kretz at kde dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36327
[Bug libstdc++/39546] parallel mode doesn't support implicit string conversion
--- Comment #23 from paolo dot carlini at oracle dot com 2009-05-12 15:27 --- Fixed for 4.4.1. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39546
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-05-12 15:29 --- (In reply to comment #12) I'm working on a fix. Earlier compilers contained a hack for this (because swing modulo scheduling can only deal with single BB loops), It was not just SMS which only can deal with single BB loops, that change improved other loops in general because the register allocator was not able to get rid of the extra basic block (just SMS showed it more). Since my name is on that change, my motivation at the time the part of the patch was written was not SMS (SMS was an after thought to me). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug c/40115] -O2 and higher causes wrong label address calculation
--- Comment #2 from sergstesh at yahoo dot com 2009-05-12 15:43 ---
No, the documentation explicitly says
( http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc.pdf , page 247 .. 248):
5.3 Labels as Values
...
To use these values, you need to be able to jump to one. This is done with
the computed
goto statement1 , goto *exp ;. For example,
goto *ptr;
Any expression of type void * is allowed.
One way of using these constants is in initializing a static array that will
serve as a jump
table:
static void *array[] = { foo, bar, hack };
Then you can select a label with indexing, like this:
goto *array[i];
Note that this does not check whether the subscript is in boundsâarray
indexing in C never
does that.
Such an array of label values serves a purpose much like that of the switch
statement.
The switch statement is cleaner, so use that rather than an array unless the
problem does
not fit a switch statement very well.
Another use of label values is in an interpreter for threaded code. The
labels within the
interpreter function can be stored in the threaded code for super-fast
dispatching.
You may not use this mechanism to jump to code in a different function. If
you do that,
totally unpredictable things will happen. The best way to avoid this is to
store the label
address only in automatic variables and never pass it as an argument.
An alternate way to write the above example is
static const int array[] = { foo - foo, bar - foo,
hack - foo };
goto *(foo + array[i]);
,
i.e. the documentation explicitly allows to rely upon labels as values.
I actually checked putting label addresses into an array - the same problem. I
didn't publish the code here - didn't want to over-complicate the test case.
--
sergstesh at yahoo dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40115
[Bug fortran/40110] Bind(C): gfortran rejects the questionable but formally correct INTEGER(C_CHAR)
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-12 15:55:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40110
[Bug c/40115] -O2 and higher causes wrong label address calculation
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-05-12 15:58 --- The intention of address of labels is only for use of flow control and nothing else. So taking the address of a label and using it to find the current PC is not a valid use of this extension. This extension was not designed to be very generic it was designed only for flow control usage with the computed goto. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40115
[Bug inline-asm/40124] New: Inline asm should support limited control flow
Right now gcc does not officially support local control flow of any kind. The
user is free to jump around within an asm block using local labels but this is
cumbersome and bug-prone. Jumping out of an asm block in any way is
(un?)officially verboten.
This RFE is for support of jumping from an asm block to a label defined
somewhere in the enclosing function. It does not deal with jumps between asm
blocks or non-local control flow like function calls (both of which are
understandably nasty).
Rationale:
1. There is demand for this feature. MSVC supports it (see
http://msdn.microsoft.com/en-us/library/aa279405(VS.60).aspx), and people
currently kludge it in gcc by defining assembler labels in other asm blocks and
jumping to them, even though the gcc docs explicitly forbid it (e.g.
http://stackoverflow.com/questions/744055/gcc-inline-assembly-jump-to-label-outside-block).
Jumping to a C label is less error-prone, more general, and significantly
easier to implement than asm-asm jumps (see #4).
2. It's already implemented. The assembler label corresponding to a C label is
accessible like this -- asm(jmp %l0 ::i(label)) -- where %l emits the
label with the syntax expected of a jump target (Brennan's inline asm guide).
All that's left is for the compiler to mark such labels as
used-by-computed-goto so the optimizer plays nice; even that can be faked with
judicious use of computed gotos (see example code, below).
3. Its effect is basically the same as for a computed goto, which is already
supported. I suspect that every argument that jumping from asm to C is
inherently unsafe or difficult to implement applies equally well to computed
gotos (e.g. Bug #37722).
4. It would encourage smaller asm blocks because internal control flow would
seldom be necessary any more. The resulting code would be easier to write and
debug, more portable, and less fragile. Further, the example below suggests
that the compiler may generate better code as well.
Example: Efficient use of condition codes
Currently the only way to use condition codes generated within an asm block is
to either convert them to an output value (which requires extra instructions to
create and test) or to embed the if/else inside the asm block (forcing the user
to write extra assembly code even if it was otherwise portable). Support for
jumping from asm to local labels would allow a better idiom:
void handle_overflow(int a, int b, int* dest);
int ideal_foo(int a, int b) {
int rval = a;
asm(adc%[src], %[dest]\n\t
jno%l[no_overflow]
: [dest] +r(rval)
: [src] r(b), [no_overflow] i(done));
handle_overflow(a, b, rval);
done:
return rval;
}
int current_foo(int a, int b) {
int overflow = 0;
int rval = a;
asm(adc%[src], %[dest]\n\t
cmovo %[true], %[overflow]
: [dest] +r(rval), [overflow] +r(overflow)
: [src] r(b), [true] r(1));
if(overflow)
handle_overflow(a, b, rval);
return rval;
}
int hacked_foo(int a, int b) {
static void* volatile labels[] = {overflow, no_overflow};
int rval=a;
asm(adc%[src], %[dest]\n\t
jno%l[no_overflow]\n\t
jmp%l[overflow]
: [dest] =r(rval)
: [src] r(b), [dest](rval),
[no_overflow] i(no_overflow), [overflow] i( overflow));
goto *labels[0];
overflow:
handle_overflow(a, b, rval);
no_overflow:
return rval;
}
Extracts of x86_64 assembler output for x86_64-unknown-linux-gnu-gcc-4.2.2 -S
-O3 follows. Notice that ideal_foo is clearly the best, *except* that the
optimizer broke it by moving .L9 to the top of the loop (it should be just
above the addq). If it were optimized better it would take only four
instructions on the short path. hacked_foo would also beat current_foo by quite
a bit, except the compiler decided to set up a stack frame for it:
ideal_foo:
.L9:
subq$16, %rsp
movl%edi, %eax
leaq12(%rsp), %rdx
movl%edi, 12(%rsp)
#APP
adc %esi, %eax
jno .L9
#NO_APP
movl%eax, 12(%rsp)
callhandle_overflow
movl12(%rsp), %eax
addq$16, %rsp
ret
current_foo:
pushq %rbx
xorl%eax, %eax
movl$1, %edx
movl%eax, %ebx
movl%edi, %ecx
subq$16, %rsp
#APP
adc %esi, %ecx
cmovo %edx, %ebx
#NO_APP
testl %ebx, %ebx
movl%edi, 12(%rsp)
movl%ecx, %eax
movl%ecx, 12(%rsp)
je .L12
leaq12(%rsp), %rdx
callhandle_overflow
movl12(%rsp), %eax
.L12:
addq$16, %rsp
popq%rbx
ret
hacked_foo:
movq%rbx, -16(%rsp)
movq%rbp, -8(%rsp)
subq$32, %rsp
movl%edi, 12(%rsp)
movl%edi, %eax
#APP
adc %esi, %eax
jno .L4
jmp .L5
#NO_APP
movl%eax,
[Bug inline-asm/40124] Inline asm should support limited control flow
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-12 16:05 --- GCC can already produce good code for overflow catching on x86. I think it is better if you don't use inline-asm for this case at all and just write the overflow detection in C90/C99 (which means don't cause an overflow). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40124
[Bug inline-asm/40124] Inline asm should support limited control flow
--- Comment #2 from scovich at gmail dot com 2009-05-12 16:13 --- Overflow and adc were only examples. Other instructions that set cc, or other conditions (e.g. parity) would not have that optimization. Another use is the ability to jump out of an inline asm to handle an uncommon case (if writing hand-tuned asm for speed, for example). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40124
[Bug middle-end/40106] Time increase with inlining for the Polyhedron test air.f90
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-12 16:18 --- Assembly code for the inlined inner loop: L123: movsd (%rdx), %xmm15 movsd 8(%rdx), %xmm6 mulsd (%rax), %xmm15 mulsd 1200(%rax), %xmm6 movsd 16(%rdx), %xmm4 movsd 24(%rdx), %xmm3 mulsd 2400(%rax), %xmm4 mulsd 3600(%rax), %xmm3 addsd %xmm15, %xmm0 movsd 32(%rdx), %xmm9 movsd 40(%rdx), %xmm1 mulsd 4800(%rax), %xmm9 mulsd 6000(%rax), %xmm1 addsd %xmm6, %xmm0 movsd 48(%rdx), %xmm7 movsd 56(%rdx), %xmm2 addq$64, %rdx mulsd 7200(%rax), %xmm7 mulsd 8400(%rax), %xmm2 addq$9600, %rax addsd %xmm4, %xmm0 cmpq%rax, %rcx addsd %xmm3, %xmm0 addsd %xmm9, %xmm0 addsd %xmm1, %xmm0 addsd %xmm7, %xmm0 addsd %xmm2, %xmm0 jne L123 and in the subroutine DERIVX: L953: movsd (%rax), %xmm9 addl$8, %ebx movsd 8(%rax), %xmm8 mulsd (%rcx), %xmm9 mulsd 1200(%rcx), %xmm8 movsd 16(%rax), %xmm7 movsd 24(%rax), %xmm6 mulsd 2400(%rcx), %xmm7 mulsd 3600(%rcx), %xmm6 addsd %xmm9, %xmm0 movsd 32(%rax), %xmm5 movsd 40(%rax), %xmm4 mulsd 4800(%rcx), %xmm5 mulsd 6000(%rcx), %xmm4 addsd %xmm8, %xmm0 movsd 48(%rax), %xmm3 movsd 56(%rax), %xmm1 addq$64, %rax mulsd 7200(%rcx), %xmm3 mulsd 8400(%rcx), %xmm1 addq$9600, %rcx cmpl%edi, %ebx addsd %xmm7, %xmm0 addsd %xmm6, %xmm0 addsd %xmm5, %xmm0 addsd %xmm4, %xmm0 addsd %xmm3, %xmm0 addsd %xmm1, %xmm0 jne L953 The structure of the outer loops seems quite comparable in both cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106
[Bug middle-end/39666] [4.3/4.4/4.5 Regression] spurious warning with ranged-switch statements
--- Comment #7 from jakub at gcc dot gnu dot org 2009-05-12 16:19 --- Subject: Bug 39666 Author: jakub Date: Tue May 12 16:19:29 2009 New Revision: 147440 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147440 Log: PR middle-end/39666 * gimplify.c (gimplify_switch_expr): If case labels cover the whole range of the type, but default label is missing, add it with one of the existing labels instead of adding a new label for it. * gcc.dg/pr39666-1.c: New test. * gcc.dg/pr39666-2.c: Likewise. * g++.dg/warn/Wuninitialized-4.C: Likewise. * g++.dg/warn/Wuninitialized-5.C: Likewise. * gfortran.dg/pr39666-1.f90: Likewise. * gfortran.dg/pr39666-2.f90: Likewise. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/warn/Wuninitialized-4.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/warn/Wuninitialized-5.C branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr39666-1.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr39666-2.c branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr39666-1.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr39666-2.f90 Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/gimplify.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39666
[Bug inline-asm/40124] Inline asm should support limited control flow
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-12 16:23 --- We are investigating if we need to add non-SSE intrinsics into gcc. If you can show me an example where gcc can't generate similar code automatically vs inline asm statement, I will look into if we should add some appropriate intrinsics. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40124
[Bug middle-end/39666] [4.3 Regression] spurious warning with ranged-switch statements
--- Comment #8 from jakub at gcc dot gnu dot org 2009-05-12 16:24 --- Fixed for 4.4/4.5 so far. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3/4.4/4.5 Regression]|[4.3 Regression] spurious |spurious warning with |warning with ranged-switch |ranged-switch statements|statements http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39666
[Bug target/37179] gcc emits bad opcode 'ffreep'
--- Comment #15 from hjl at gcc dot gnu dot org 2009-05-12 16:33 --- Subject: Bug 37179 Author: hjl Date: Tue May 12 16:33:14 2009 New Revision: 147441 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147441 Log: PR target/37179: * Correct PR number for revision 147429. Modified: trunk/gcc/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37179
[Bug inline-asm/40124] Inline asm should support limited control flow
--- Comment #4 from scovich at gmail dot com 2009-05-12 16:36 ---
I'm actually running sparcv9-sun-solaris2.10 (the examples used x86 because
more people know it and its asm is easier to read).
My use case is the following: I'm implementing high-performance synchronization
primitives and the compiler isn't generating good enough code -- partly because
it doesn't pipeline spinloops, and partly because it has no way to know what
stuff is truly critical path and what just needs to happen eventually.
Here's a basic idea of what I've been looking at:
long mcs_lock_acquire(mcs_lock* lock, mcs_qnode* me) {
again:
/* initialize qnode, etc */
membar_producer();
mcs_qnode* pred = atomic_swap(lock-tail, me);
if(pred) {
pred-next = me;
while(int flags=me-wait_flags) {
if(flags ERROR) {
/* recovery code */
goto again;
}
}
}
membar_enter();
return (long) pred;
}
This code is absolutely performance-critical because every instruction on the
critical path delays O(N) other threads -- even a single extra load or store
causes noticeable delays. I was trying to rewrite just the while loop above in
asm to be more efficient, but it is hard because of that goto inside.
Basically, the error isn't going anywhere once it shows up, so we don't have to
check it nearly as often as the flags==0 case, and it can be interleaved across
as many loop iterations as needed to make its overhead disappear. Manually
unrolling and pipelining the loop helped a bit, but the compiler still tended
to cluster things together more than was strictly necessary (leading to bursts
of saturated pipeline alternating with slack).
For CC stuff, especially x86-related, I bet places like fftw and gmp are good
sources of frustration to mine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40124
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #17 from vvv at ru dot ru 2009-05-12 16:40 ---
(In reply to comment #16)
Created an attachment (id=17783)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17783action=view) [edit]
gcc45-pr39942.patch
Patch that attempts to take into account .p2align directives that are emitted
for (some) CODE_LABELs and also the gen_align insns that the pass itself
inserts. For a CODE_LABEL, say .p2align 16,,10 means either that the .p2align
directive starts a new 16 byte page (then insns before it are never
interesting), or nothing was skipped because more than 10 bytes would need to
be skipped. But that means the current group could contain only 5 or less
bytes of instructions before the label, so again, we don't have to look at
instructions not in the last 5 bytes.
Another fix is that for MAX_SKIP 7, ASM_OUTPUT_MAX_SKIP_ALIGN shouldn't emit
the second .p2align 3, which might (and often does) skip more than MAX_SKIP
bytes (up to 7).
Nice path. Code looks better. It checked on Linux kernel 2.6.29.2.
But 2 notes:
1.There is no garanty that .p2align will be translated to NOPs. Example:
# cat test.c
void f(int i)
{
if (i == 1) F(1);
if (i == 2) F(2);
if (i == 3) F(3);
if (i == 4) F(4);
if (i == 5) F(5);
}
# gcc -o test.s test.c -O2 -S
# cat test.s
.file test.c
.text
.p2align 4,,15
.globl f
.type f, @function
f:
.LFB0:
.cfi_startproc
cmpl$1, %edi
je .L7
cmpl$2, %edi
je .L7
cmpl$3, %edi
je .L7
cmpl$4, %edi
.p2align 4,,5--- attempt of padding
je .L7
cmpl$5, %edi
je .L7
rep
ret
.p2align 4,,10
.p2align 3
.L7:
xorl%eax, %eax
jmp F
.cfi_endproc
.LFE0:
.size f, .-f
.ident GCC: (GNU) 4.5.0 20090512 (experimental)
.section.note.GNU-stack,,@progbits
# gcc -o test.out test.s -O2 -c
# objdump -d test.out
f:
0: 83 ff 01cmp$0x1,%edi
3: 74 1b je 20 f+0x20
5: 83 ff 02cmp$0x2,%edi
8: 74 16 je 20 f+0x20
a: 83 ff 03cmp$0x3,%edi
d: 74 11 je 20 f+0x20
f: 83 ff 04cmp$0x4,%edi
12: 74 0c je 20 f+0x20 no NOP here
14: 83 ff 05cmp$0x5,%edi
17: 74 07 je 20 f+0x20
19: f3 c3 repz retq
IMHO, better to insert not .p2align, but NOPs directly. ( I mean line -
emit_insn_before (gen_align (GEN_INT (padsize)), insn); )
2. IMHO, it's bad idea to insert somthing between CMP and conditional jmp.
Quote from Intel 64 and IA-32 Architectures Optimization Reference Manual
3.4.2.2 Optimizing for Macro-fusion
Macro-fusion merges two instructions to a single μop. Intel Core
Microarchitecture
performs this hardware optimization under limited circumstances.
The first instruction of the macro-fused pair must be a CMP or TEST
instruction. This
instruction can be REG-REG, REG-IMM, or a micro-fused REG-MEM comparison. The
second instruction (adjacent in the instruction stream) should be a
conditional
branch.
So if we need to insert NOPs, better to do it _before_ CMP.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug inline-asm/40124] Inline asm should support limited control flow
--- Comment #5 from hjl dot tools at gmail dot com 2009-05-12 16:42 --- (In reply to comment #4) I'm actually running sparcv9-sun-solaris2.10 (the examples used x86 because more people know it and its asm is easier to read). My use case is the following: I'm implementing high-performance synchronization primitives and the compiler isn't generating good enough code -- partly because it doesn't pipeline spinloops, and partly because it has no way to know what stuff is truly critical path and what just needs to happen eventually. I think intrinsic is a better solution than inline asm statement for this. If you find any x86 intrinsics are missing, please let me know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40124
[Bug inline-asm/40124] Inline asm should support limited control flow
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-05-12 16:48 --- Sounds like you want to use __builtin_expect. Also GCC uses heuristics to figure out: if(pred) is taken most of the time because it is comparing a pointer to NULL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40124
[Bug inline-asm/40124] Inline asm should support limited control flow
--- Comment #7 from scovich at gmail dot com 2009-05-12 17:01 --- Isn't __builtin_expect a way to send branch prediction hints? I'm not having trouble with that AFAIK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40124
[Bug inline-asm/40124] Inline asm should support limited control flow
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-05-12 17:08 --- (In reply to comment #7) Isn't __builtin_expect a way to send branch prediction hints? Not just prediction hints, it helps other optimizations of not moving code around inter block which seems like what you need. Maybe it is better to file a bug about the code you want optimized and the way you want it optimized instead of asking for another feature. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40124
[Bug bootstrap/40105] SH: 4.3/4.4 compilers segfault when recompiling itself on gentoo system
--- Comment #2 from armin76 at gentoo dot org 2009-05-12 17:27 --- (In reply to comment #1) Your compilers are the gentoo special versions, aren't they? Nope, there's no patch applied in this case. If you meant that we don't 'make bootstrap-lean make install', yes. If so, you should try the original FSF compiler sources for both build/target compilers. See http://gcc.gnu.org/bugs.html#dontwant. FSF 4.3/4.4 release compilers are bootstraped without problems on sh4-unknown-linux-gnu for me. Only I can say from the log in #1 is that your xgcc driver looks to segfault with -dumpspecs option. Since it doesn't happen with your gcc-4.1.2, it seems that your 4.3 compiler miscompiles something for xgcc. If it's the case, you can bisect the problem with replacing objects and libraries for xgcc with those compiled by your 4.1.2 compiler. Can you build gcc-4.3.3 using gcc-4.3.3 and with the following command? make -j3 LDFLAGS=-Wl,-O1 STAGE1_CFLAGS=-O 'BOOT_CFLAGS= -O2 -pipe' bootstrap-lean Not sure if you saw what i said on #4. Anyway, i'll try a more cleaner way, but in that case this bug can't be here. Can you try with the command i pasted? Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40105
[Bug middle-end/39509] [4.3/4.4/4.5 Regression] bad optimization(?) pure virtual function call with -O2
--- Comment #13 from jakub at gcc dot gnu dot org 2009-05-12 18:56 --- In 4.4.0/x86_64-linux at -O2 at least the problem seems to be that in: _ZNK5boost9xpressive6detail17xpression_adaptorINS1_16static_xpressionINS1_17alternate_matcherINS1_15alternates_listINS3_INS1_13regex_matcherIN9__gnu_cxx17__normal_iteratorIPKcSsNS3_INS1_21alternate_end_matcherENS1_7no_nextENS5_ISG_NS_6fusion3nilENS0_16cpp_regex_traitsIcNS3_INS1_11end_matcherESE_NS1_12matchable_exISB_EEE5matchERNS1_11match_stateISB_EE adaptor is destructed before the push_context_match call. In *.optimized dump we have: bb 9: adaptor.D.166953._vptr.matchable = _ZTVN5boost9xpressive6detail17xpression_adaptorINS_17reference_wrapperIKNS1_17stacked_xpressionINS1 _16static_xpressionINS1_11end_matcherENS1_7no_nextEEENS5_INS1_21alternate_end_matcherES7_EENS1_9matchableIN9__gnu_cxx17__normal_itera torIPKcSsEE[2]; adaptor.xpr_.t_ = (const struct stacked_xpression *) (const struct stacked_xpression ) this-xpr_.D.142582.alternates_.D.142415.cdr.D .142229.car.next_; adaptor.D.166953._vptr.matchable = _ZTVN5boost9xpressive6detail9matchableIN9__gnu_cxx17__normal_iteratorIPKcSs[2]; D.187198 = push_context_match (this-xpr_.D.142582.alternates_.D.142415.cdr.D.142229.car.D.142156.impl_, state, adaptor.D.166953); goto bb 11; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39509
[Bug middle-end/39509] [4.3/4.4/4.5 Regression] bad optimization(?) pure virtual function call with -O2
--- Comment #14 from jakub at gcc dot gnu dot org 2009-05-12 19:06 --- In *.pre it still looks correct: adaptor.D.166953._vptr.matchable = _ZTVN5boost9xpressive6detail17xpression_adaptorINS_17reference_wrapperIKNS1_17stacked_xpressionINS1 _16static_xpressionINS1_11end_matcherENS1_7no_nextEEENS5_INS1_21alternate_end_matcherES7_EENS1_9matchableIN9__gnu_cxx17__normal_itera torIPKcSsEE[2]; adaptor.xpr_.t_ = D.187226_39; D.187223_40 = this_1(D)-xpr_.D.142582.alternates_.D.142415.cdr.D.142229.car.D.142156.impl_; D.187198_41 = push_context_match (D.187223_40, state_4(D), adaptor.D.166953); and adaptor.D.166953._vptr.matchable = _ZTVN5boost9xpressive6detail17xpression_adaptorINS_17reference_wrapperIKNS1_17stacked_xpressionINS1 _16static_xpressionINS1_11end_matcherENS1_7no_nextEEENS5_INS1_21alternate_end_matcherES7_EENS1_9matchableIN9__gnu_cxx17__normal_itera torIPKcSsEE[2]; adaptor.xpr_.t_ = D.187218_33; D.187221_34 = this_1(D)-xpr_.D.142582.alternates_.D.142415.car.D.142156.impl_; D.187216_35 = push_context_match (D.187221_34, state_4(D), adaptor.D.166953); but *.sink already breaks the first push_context_match call: D.187227_38 = this_1(D)-xpr_.D.142582.alternates_.D.142415.cdr.D.142229.car.next_; D.187226_39 = (const struct stacked_xpression ) D.187227_38; adaptor.D.166953._vptr.matchable = _ZTVN5boost9xpressive6detail17xpression_adaptorINS_17reference_wrapperIKNS1_17stacked_xpressionINS1 _16static_xpressionINS1_11end_matcherENS1_7no_nextEEENS5_INS1_21alternate_end_matcherES7_EENS1_9matchableIN9__gnu_cxx17__normal_itera torIPKcSsEE[2]; adaptor.xpr_.t_ = D.187226_39; D.187223_40 = this_1(D)-xpr_.D.142582.alternates_.D.142415.cdr.D.142229.car.D.142156.impl_; adaptor.D.166953._vptr.matchable = _ZTVN5boost9xpressive6detail9matchableIN9__gnu_cxx17__normal_iteratorIPKcSs[2]; D.187198_41 = push_context_match (D.187223_40, state_4(D), adaptor.D.166953); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39509
[Bug bootstrap/40061] [4.3 Regression] Bootstrap failure in dwarf2out.c, function add_subscript_info: 'dimension_number' undefined
--- Comment #4 from burnus at gcc dot gnu dot org 2009-05-12 19:27 --- Subject: Bug 40061 Author: burnus Date: Tue May 12 19:26:46 2009 New Revision: 147445 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147445 Log: 2009-05-12 Tobias Burnus bur...@net-b.de PR bootstrap/40061 * dwarf2.out.c (add_subscript_info): Initialize dimension for MIPS_DEBUGGING_INFO. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40061
[Bug middle-end/39509] [4.3/4.4/4.5 Regression] bad optimization(?) pure virtual function call with -O2
--- Comment #15 from jakub at gcc dot gnu dot org 2009-05-12 19:34 --- Ah, there are two different adaptor variables after inlining, so this might as well be a dup of PR39604. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39509
[Bug bootstrap/40061] [4.3 Regression] Bootstrap failure in dwarf2out.c, function add_subscript_info: 'dimension_number' undefined
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-12 19:42 --- FIXED on the 4.3 branch. Thanks for reporting the problem and sorry for the breakage. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40061
[Bug target/40125] New: libgcc_s DLL installed in wrong directory in cross toolchain
GCC 4.4 or later configured with --enable-shared for i686-mingw32 installs a libgcc DLL (e.g. libgcc_s_dw2-1.dll) in $(bindir). As this is a binary for the target not the host, this is an inappropriate location in a cross toolchain; some target-specific directory (e.g. i686-mingw32/bin or i686-mingw32/lib) should be used instead. -- Summary: libgcc_s DLL installed in wrong directory in cross toolchain Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org GCC target triplet: i?86-*-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40125
[Bug debug/40126] New: [4.5 regression] -O2 -g results in: can't resolve `.LFE95' {*UND* section} - `.Ltext0' {.text section}
When building tools/widl/typelib.c from Wine with -O2 -g, we started
getting the following some three days ago:
/var/tmp//cc43jwq2.s: Assembler messages:
/var/tmp//cc43jwq2.s:2059: Error: can't resolve `.LFE95' {*UND* section} -
`.Ltext0' {.text section}
This is on i386-unknown-freebsd7.1 with GNU as 2.15.
Both -O2 and -g are needed; neither -O1 -g nor just -O2 reproduces this.
--
Summary: [4.5 regression] -O2 -g results in: can't resolve
`.LFE95' {*UND* section} - `.Ltext0' {.text section}
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gerald at pfeifer dot com
GCC host triplet: i386-unknown-freebsd7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40126
[Bug debug/40126] [4.5 regression] -O2 -g results in: can't resolve `.LFE95' {*UND* section} - `.Ltext0' {.text section}
--- Comment #1 from gerald at pfeifer dot com 2009-05-12 20:40 --- Created an attachment (id=17855) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17855action=view) Preprocessed source file; test with $GCC -g -O2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40126
[Bug fortran/34153] Debugging: Cannot set breakpoint in comment lines or END PROGRAM
--- Comment #3 from burnus at gcc dot gnu dot org 2009-05-12 21:10 --- I have a patch for this. Note, however, that the compiler - even with default options - (too) aggressively optimizes your program, i.e. the assignment is optimized away even with -O0 and thus for your program the value is alway some random value. (This is also the the case for the analogous C program - if you think it should be fixed, please fill a middle-end bug.) If you do: subroutine test save ! or actual argument or in common or ... i = 1 ! Breakpoint here ! a break point here becomes a b. in the next line end subroutine test ! the breakpoint can be set to this line with my patch, it properly prints the value 1 for i after the assignment. -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-11-20 13:10:19 |2009-05-12 21:10:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34153
[Bug c++/40127] New: Fails to identify template function with default args
This code:
templatetypename T
voidfoo(int i, void(*f)(T*) = 0, T* a = 0) {}
int main() {
foo(5);
return 0;
}
gets you:
foo.cc: In function int main():
foo.cc:5: error: no matching function for call to foo(int)
So I figured that binding required an actual type, so I tried making it
explicit in the default values:
templatetypename T
voidfoo(int i, void(*f)(T*) = static_castvoid(*)(void*)(0),
T* a = static_castvoid*(0)) {}
int main() {
foo(5);
return 0;
}
But that gets me the same error.
I'm not sure whether argument types can be bound from default arguments in the
standard, but if they can't then I should get a diagnostic at the declaration
of the template. The actual message is cryptic and unhelpful.
--
Summary: Fails to identify template function with default args
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40127
[Bug fortran/39489] [4.3 regression] write_atom(): Writing negative integer
--- Comment #12 from burnus at gcc dot gnu dot org 2009-05-12 22:05 --- Some more data: ==16952== Conditional jump or move depends on uninitialised value(s) ==16952==at 0x4470FC: write_atom (module.c:1339) ==16952==by 0x4472DD: mio_integer (module.c:1450) ==16952==by 0x447DAC: mio_typespec (module.c:1870) ==16952==by 0x449710: mio_symbol (module.c:3048) That are lines such as: mio_integer (ts-is_c_interop); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39489
[Bug bootstrap/40118] cond-optab breaks powerpc bootstrap
--- Comment #3 from bje at gcc dot gnu dot org 2009-05-12 22:19 --- Fixed. -- bje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40118
[Bug tree-optimization/40049] Incorrect tree made for vector shifted by constant on powerpc, spu
--- Comment #11 from bje at gcc dot gnu dot org 2009-05-12 22:21 --- Fixed. -- bje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40049
[Bug target/40105] SH: 4.3/4.4 compilers segfault when recompiling itself on gentoo system
--- Comment #3 from kkojima at gcc dot gnu dot org 2009-05-12 22:37 --- Ah, now I understand the issue and find that what we need in the bug report http://gcc.gnu.org/bugs.html#need is in http://bugs.gentoo.org/show_bug.cgi?id=267247. Next time, please give the minimal information to reproduce the problem in the bug report itself, not in some URL. The real problem will be the wrong code problem with -O1 for 4.3 compiler on SH, rather than a bootstrap problem. It might be very hard to solve, though. Perhaps we can find what part of the compiler is miscompiled with the 4.3 compiler with -O by replacing gcc/*.o objects compiled with -O2. Even if we can detect a problematic .o, it will be very large and it'd be difficult to get an appropriate test case which is wrongly compiled with -O. We can't go forward without such a test case. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Component|bootstrap |target Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-12 22:37:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40105
[Bug libstdc++/39491] [4.3 regression] symbol __signb...@glibcxx_3.4 in libstdc++ exported
--- Comment #35 from bkoz at gcc dot gnu dot org 2009-05-12 22:43 --- Closing. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491
[Bug fortran/40110] Bind(C): gfortran rejects the questionable but formally correct INTEGER(C_CHAR)
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-12 22:43 --- Subject: Bug 40110 Author: burnus Date: Tue May 12 22:42:45 2009 New Revision: 147452 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147452 Log: 2009-05-12 Tobias Burnus bur...@net-b.de PR fortran/40110 * decl.c (gfc_match_kind_spec): Turn C kind error into a * warning. 2009-05-12 Tobias Burnus bur...@net-b.de PR fortran/40110 * gfortran.dg/bind_c_usage_18.f90: Change dg-error into dg-warning. * gfortran.dg/c_kind_tests_2.f03: Ditto. * gfortran.dg/interop_params.f03: Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bind_c_usage_18.f90 trunk/gcc/testsuite/gfortran.dg/c_kind_tests_2.f03 trunk/gcc/testsuite/gfortran.dg/interop_params.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40110
[Bug fortran/40110] Bind(C): gfortran rejects the questionable but formally correct INTEGER(C_CHAR)
--- Comment #2 from burnus at gcc dot gnu dot org 2009-05-12 22:44 --- FIXED on the trunk (4.5). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40110
[Bug target/39561] -mno-expand-cbranchdi broken
--- Comment #2 from kkojima at gcc dot gnu dot org 2009-05-12 22:47 --- Subject: Bug 39561 Author: kkojima Date: Tue May 12 22:47:03 2009 New Revision: 147453 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147453 Log: PR target/39561 * config/sh/sh.h (OPTIMIZATION_OPTIONS): Don't set TARGET_EXPAND_CBRANCHDI4. * config/sh/sh.md (cbranchdi4): Don't check TARGET_EXPAND_CBRANCHDI4. * config/sh/sh.opt (mexpand-cbranchdi): Remove. (cmpeqdi): Fix comment. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.h trunk/gcc/config/sh/sh.md trunk/gcc/config/sh/sh.opt -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39561
[Bug libstdc++/40038] [4.4/4.5 regression] symbols ce...@glibcxx_3.4.3 not exported
--- Comment #10 from bkoz at gcc dot gnu dot org 2009-05-12 23:01 --- Sorry for the delay Paolo, this fix looks fine. I see tanhl missing too in that log, yet the gnu.ver exports have it and so does src/math_compatibility_long_double.cc, although depending on _GLIBCXX_HAVE_TANHL. What gives? Is this some kind of temporary build issue or is this still indicative of configure/build issues? Please note that there are no arm ABI baselines. Is this due to multilib/configure issues and or large numbers of variants? Can Debian volunteers fix this or elaborate? Hopefully the necessity of this is now apparent. I appreciate the current efforts to get Debian builds back on track, but am a bit alarmed at the releases w/ known ABI fails on secondary arches. What can be done to improve this situation? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40038
