[Bug c/34789] New: Missed optimisation on avr - sometimes the compiler keeps addresses in registers unnecessarily
On RISC cpus with many registers, it is often helpful to keep constants (such
as addresses) in registers for later use, since loading a register with a
constant takes longer than moving data between registers, and since
register-constant operations are seldom available. On the AVR, however,
register-constant operations are just as small and fast as register-register
operations (excluding the movw operation), so it is often better to use the
constants directly - it saves a few instructions (time and code space), and
avoids tying up a register pair unnecessarily.
Example:
extern uint16_t data[64];
extern uint16_t foo(uint16_t x);
extern uint16_t a;
uint16_t bar(void) {
uint16_t x;
x = foo(data[a]);
return foo(data[x]);
}
In this case, the compiler caches the address of data in r16:r17 :
59bar:
60/* prologue: frame size=0 */
61 001a 0F93 push r16
62 001c 1F93 push r17
63/* prologue end (size=2) */
64 001e E091 lds r30,a; a, a
65 0022 F091 lds r31,(a)+1; a, a
66 0026 00E0 ldi r16,lo8(data); tmp45,
67 0028 10E0 ldi r17,hi8(data); tmp45,
68 002a EE0F lsl r30 ; a
69 002c FF1F rol r31 ; a
70 002e E00F add r30,r16 ; a, tmp45
71 0030 F11F adc r31,r17 ; a, tmp45
72 0032 8081 ld r24,Z ; , data
73 0034 9181 ldd r25,Z+1 ; , data
74 0036 0E94 call foo ;
75 003a 880F lsl r24 ; tmp50
76 003c 991F rol r25 ; tmp50
77 003e 080F add r16,r24 ; tmp45, tmp50
78 0040 191F adc r17,r25 ; tmp45, tmp50
79 0042 F801 movw r30,r16 ; , tmp45
80 0044 8081 ld r24,Z ; , data
81 0046 9181 ldd r25,Z+1 ; , data
82 0048 0E94 call foo ;
83/* epilogue: frame size=0 */
84 004c 1F91 pop r17
85 004e 0F91 pop r16
86 0050 0895 ret
Better code could be generated by using data directly:
; Prologue avoided - saved 2 words code
lds r30, a
lds r31, (a) + 1
; Load of r16:r17 avoided - saved 2 words code
lsl r30 ; a
rol r31 ; a
subi r30, lo8(-(data))
sbci r31, hi8(-(data))
ld r24, z
ldd r25, Z+1
call foo
lsl r24 ; x
rol r25 ; x
; Using constant for data is just as small as register
subi r24, lo8(-(data))
sbci r25, hi8(-(data))
movw r30, r16
ld r24, z
ldd r25, Z+1
call foo
; Epilogue avoided - saved 2 words code
ret
This saves 6 code words, and corresponding time.
--
Summary: Missed optimisation on avr - sometimes the compiler
keeps addresses in registers unnecessarily
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david at westcontrol dot com
GCC target triplet: avrgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34789
[Bug c/34791] New: Missed optimisation on avr - optimisation of 8-bit logic sometimes fails
As the avr is an 8-bit processor, it is important to handle data as 8-bit when
possible, even though the C standards force 8-bit data to be promoted to 16-bit
ints in many situations. Common cases are when doing logic operations on chars
- when legally valid (i.e., the results are the same as for 16-bit operations),
the generated code should use 8-bit operations. In particular, logic
operations using constants such as 0 and 0xff should be optimised.
Optimisation works well in many cases, but fails when the expressions get
slightly more complex:
extern uint8_t data[64];
uint8_t bar(uint8_t x, uint8_t y) {
return data[y ^ (x 0x0f)];
}
uint8_t bar2(uint8_t x, uint8_t y) {
return data[(y ^ x) 0x0f];
}
40bar:
41/* prologue: frame size=0 */
42/* prologue end (size=0) */
43 E82F mov r30,r24 ; x, x
44 0002 F0E0 ldi r31,lo8(0) ; x,
45 0004 EF70 andi r30,lo8(15) ; x,
46 0006 F070 andi r31,hi8(15) ; x,
47 0008 70E0 ldi r23,lo8(0) ; y,
48 000a E627 eor r30,r22 ; x, y
49 000c F727 eor r31,r23 ; x, y
50 000e E050 subi r30,lo8(-(data)); x,
51 0010 F040 sbci r31,hi8(-(data)); x,
52 0012 8081 ld r24,Z ; tmp51, data
53 0014 90E0 ldi r25,lo8(0) ; result,
54/* epilogue: frame size=0 */
55 0016 0895 ret
56/* epilogue end (size=1) */
57/* function bar size 12 (11) */
61bar2:
62/* prologue: frame size=0 */
63/* prologue end (size=0) */
64 0018 E62F mov r30,r22 ; y, y
65 001a E827 eor r30,r24 ; y, x
66 001c F0E0 ldi r31,lo8(0) ; ,
67 001e EF70 andi r30,lo8(15) ; tmp46,
68 0020 F070 andi r31,hi8(15) ; tmp46,
69 0022 E050 subi r30,lo8(-(data)); tmp46,
70 0024 F040 sbci r31,hi8(-(data)); tmp46,
71 0026 8081 ld r24,Z ; tmp50, data
72 0028 90E0 ldi r25,lo8(0) ; result,
73/* epilogue: frame size=0 */
74 002a 0895 ret
75/* epilogue end (size=1) */
76/* function bar2 size 10 (9) */
The first function bar has several clear improvements - it does all the logic
operations as 16-bit. In the second case, the eor is nicely handled as
8-bit, but the 0x0f is done as 16-bit - there is an unnecessary andi r31,
hi8(15) instruction.
--
Summary: Missed optimisation on avr - optimisation of 8-bit logic
sometimes fails
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david at westcontrol dot com
GCC target triplet: avrgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34791
[Bug c/34790] New: Missed optimisation on avr - no sibling call optimisation
-- Summary: Missed optimisation on avr - no sibling call optimisation Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: david at westcontrol dot com GCC target triplet: avrgcc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34790
[Bug c/34790] Missed optimisation on avr - no sibling call optimisation
--- Comment #1 from david at westcontrol dot com 2008-01-15 08:34 ---
(Sorry - I committed the bug before entering the description!)
Sibling calls are not optimised on avrgcc, even with -foptimize-sibling-calls
enabled (such as for -Os):
extern void foo(void);
void bar(void) {
foo();
}
40bar:
41/* prologue: frame size=0 */
42/* prologue end (size=0) */
43 0E94 call foo ;
44/* epilogue: frame size=0 */
45 0004 0895 ret
46/* epilogue end (size=1) */
47/* function bar size 3 (2) */
Optimising the call foo; ret sequence to jmp foo would reduce the code size
by 1 word, the stack usage by 2 bytes (on most avrs), and save 5 cycles.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34790
[Bug c++/34792] New: Missed optimisation on avr - c++ worse than c compiler at 8-bit optimisations
As noted in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34791 , it is important
on the avr to use 8-bit logic whenever possible. In some cases, the c++
compiler will produce worse code than the c compiler for exactly the same
source:
extern uint8_t data[64];
uint8_t bar2(uint8_t x, uint8_t y) {
return data[(y ^ x) 0x0f];
}
Compiled as c, this gives:
61bar2:
62/* prologue: frame size=0 */
63/* prologue end (size=0) */
64 0018 E62F mov r30,r22 ; y, y
65 001a E827 eor r30,r24 ; y, x
66 001c F0E0 ldi r31,lo8(0) ; ,
67 001e EF70 andi r30,lo8(15) ; tmp46,
68 0020 F070 andi r31,hi8(15) ; tmp46,
69 0022 E050 subi r30,lo8(-(data)); tmp46,
70 0024 F040 sbci r31,hi8(-(data)); tmp46,
71 0026 8081 ld r24,Z ; tmp50, data
72 0028 90E0 ldi r25,lo8(0) ; result,
73/* epilogue: frame size=0 */
74 002a 0895 ret
75/* epilogue end (size=1) */
76/* function bar2 size 10 (9) */
Here there is only one extra instruction, the andi r31, hi8(15). But
compiling as c++, using the same -Os option, gives:
61_Z4bar2hh:
62/* prologue: frame size=0 */
63/* prologue end (size=0) */
64 0018 E62F mov r30,r22 ; y, y
65 001a F0E0 ldi r31,lo8(0) ; y,
66 001c 90E0 ldi r25,lo8(0) ; x,
67 001e E827 eor r30,r24 ; y, x
68 0020 F927 eor r31,r25 ; y, x
69 0022 EF70 andi r30,lo8(15) ; y,
70 0024 F070 andi r31,hi8(15) ; y,
71 0026 E050 subi r30,lo8(-(data)); y,
72 0028 F040 sbci r31,hi8(-(data)); y,
73 002a 8081 ld r24,Z ; tmp51, data
74 002c 90E0 ldi r25,lo8(0) ; result,
75/* epilogue: frame size=0 */
76 002e 0895 ret
77/* epilogue end (size=1) */
78/* function uint8_t bar2(uint8_t, uint8_t) size 12 (11)
*/
This time, the compiler has clearly missed several opportunities to use 8-bit
logic instead of 16-bit logic.
--
Summary: Missed optimisation on avr - c++ worse than c compiler
at 8-bit optimisations
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david at westcontrol dot com
GCC target triplet: avrgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34792
[Bug c++/27177] [4.1/4.2/4.3 Regression] ICE in build_simple_base_path, at cp/class.c:474
--- Comment #18 from rguenth at gcc dot gnu dot org 2008-01-15 09:47 --- Thanks. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2006-04-16 23:13:40 |2008-01-15 09:47:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27177
[Bug c++/27177] [4.1/4.2/4.3 Regression] ICE in build_simple_base_path, at cp/class.c:474
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27177
[Bug c++/33887] [4.1/4.2/4.3 Regression] Reference to bitfield gets wrong value when optimizing
--- Comment #23 from rguenth at gcc dot gnu dot org 2008-01-15 09:45 --- I don't see where there is a problem with widening conversions. The problem is we re-use the (unsigned : 24) i; value for the comparison, which looks reasonable, but this _narrowing_ conversion is not reflected by actual code in expand. I believe the only way without touching expand too much is to make the frontend more explicit (and of course generate code for widening/narrowing conversions). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887
[Bug middle-end/34793] New: [Regression 4.1/4.3] warning: 'areg' may be used uninitialized in this function
After reading all other PRs about uninitialized variable warnings, I believe this one is a different situtation. PR 20968 -- is about inlining, which is not involved here PR 21733 -- is about two concatenated blocks rather than nested ones PR 31707 -- is about setjmp PR 20644 -- is also about unreachable code In this testcase, it is really obvious to the observer that the switch statement explicitly handles all the cases where it could be reached from the outer if statement, and thus always assigns a value to variable areg. GCC 3.x did not warn about it. I verified the warning is still generated with SVN revision 131533. (The code is taken from a project called simulavr, and has been cut down to the minimal test case reproducing the warning.) -- Summary: [Regression 4.1/4.3] warning: 'areg' may be used uninitialized in this function Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: j at uriah dot heep dot sax dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34793
[Bug bootstrap/32287] gas version style changed causes warnings with configure
--- Comment #8 from aldot at gcc dot gnu dot org 2008-01-15 10:10 --- This was recently changed on trunk: http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01574.html via r127745 | drow | 2007-08-23 19:42:08 +0200 (Thu, 23 Aug 2007) | 4 lines * configure.ac (leb128): Modify sed statement to work with any binutils version string. * configure: Regenerate But this doesn't seem to work for me: checking assembler for .sleb128 and .uleb128... /there/toolchain_build_sh4/gcc-4.3.0/gcc/configure: line 14146: test: -eq: unary operator expected /there/build_sh4/staging_dir/usr/bin/sh4-linux-uclibcgnueabi-as --version | sed 1q GNU assembler (Linux/GNU Binutils) 2.18.50.0.3.20071102 Should be fixed before 4.3.0.. -- aldot at gcc dot gnu dot org changed: What|Removed |Added CC||aldot at gcc dot gnu dot ||org, drow at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32287
[Bug middle-end/34793] [Regression 4.1/4.3] warning: 'areg' may be used uninitialized in this function
--- Comment #1 from j at uriah dot heep dot sax dot de 2008-01-15 10:10 --- Created an attachment (id=14942) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14942action=view) Testcase showing the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34793
[Bug c/34781] __builtin_expect()'s first argument should be treated like other conditional expressions
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34781
[Bug libstdc++/34794] New: build of gcc 4.2.2 fails on AIX 6.1 / libstdc++-v3/libmath/stubs.c:47
Hello,
the build of gcc 4.2.2 fails on AIX 6.1 during stage3 / libstdc++.
environment:
IBM AIX 6.1 TL0 SP2
XC C/C++ 9.0
gcc 4.2.2 compiled on AIX 5.3
= stage_current: stage3
gmake[4]: Entering directory
`/opt/freeware/src/packages/BUILD/gcc-build/powerpc-ibm-aix6.1.0.0/libstdc++-v3/libmath'
/opt/freeware/bin/bash ../libtool --tag CC --mode=compile
/opt/freeware/src/packages/BUILD/gcc-build/./gcc/xgcc
-B/opt/freeware/src/packages/BUILD/gcc-build/./gcc/
-B/opt/freeware/powerpc-ibm-aix6.1.0.0/bin/
-B/opt/freeware/powerpc-ibm-aix6.1.0.0/lib/ -isystem
/opt/freeware/powerpc-ibm-aix6.1.0.0/include -isystem
/opt/freeware/powerpc-ibm-aix6.1.0.0/sys-include -DHAVE_CONFIG_H -I.
-I../../../../gcc-4.2.2/libstdc++-v3/libmath -I.. -O2 -O2
-I/opt/freeware/include -c -o stubs.lo
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c
/opt/freeware/src/packages/BUILD/gcc-build/./gcc/xgcc
-B/opt/freeware/src/packages/BUILD/gcc-build/./gcc/
-B/opt/freeware/powerpc-ibm-aix6.1.0.0/bin/
-B/opt/freeware/powerpc-ibm-aix6.1.0.0/lib/ -isystem
/opt/freeware/powerpc-ibm-aix6.1.0.0/include -isystem
/opt/freeware/powerpc-ibm-aix6.1.0.0/sys-include -DHAVE_CONFIG_H -I.
-I../../../../gcc-4.2.2/libstdc++-v3/libmath -I.. -O2 -O2
-I/opt/freeware/include -c ../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c
-o stubs.o
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:47: error: expected
declaration specifiers or '...' before '(' token
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:48: error: conflicting types
for 'fabs'
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c: In function 'fabs':
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:49: error: 'x' undeclared
(first use in this function)
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:49: error: (Each undeclared
identifier is reported only once
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:49: error: for each function
it appears in.)
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c: At top level:
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:64: error: expected
declaration specifiers or '...' before '(' token
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:65: error: conflicting types
for 'acos'
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c: In function 'acos':
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:66: error: 'x' undeclared
(first use in this function)
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c: At top level:
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:81: error: expected
declaration specifiers or '...' before '(' token
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:82: error: conflicting types
for 'asin'
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c: In function 'asin':
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:83: error: 'x' undeclared
(first use in this function)
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c: At top level:
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:98: error: expected
declaration specifiers or '...' before '(' token
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:99: error: conflicting types
for 'atan'
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c: In function 'atan':
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:100: error: 'x' undeclared
(first use in this function)
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c: At top level:
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:115: error: expected
declaration specifiers or '...' before '(' token
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:115: error: expected
declaration specifiers or '...' before '(' token
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:116: error: conflicting
types for 'atan2'
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c: In function 'atan2':
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:117: error: 'x' undeclared
(first use in this function)
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:117: error: 'y' undeclared
(first use in this function)
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c: At top level:
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:132: error: expected
declaration specifiers or '...' before '(' token
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:133: error: conflicting
types for 'ceil'
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c: In function 'ceil':
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:134: error: 'x' undeclared
(first use in this function)
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c: At top level:
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:149: error: expected
declaration specifiers or '...' before '(' token
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:150: error: conflicting
types for 'cos'
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c: In function 'cos':
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:151: error: 'x' undeclared
(first use in this function)
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c: At top level:
../../../../gcc-4.2.2/libstdc++-v3/libmath/stubs.c:166:
[Bug middle-end/34793] warning: 'areg' may be used uninitialized in this function
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-15 10:49 --- This problem is introduced by the default case that gets added to the switch stmt in the IL. Coming from this case, areg is uninitialized. The fix for PR14495 will likely fix this (by removing the default case again). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org BugsThisDependsOn||14495 Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2008-01-15 10:49:47 date|| Summary|[Regression 4.1/4.3]|warning: 'areg' may be used |warning: 'areg' may be used |uninitialized in this |uninitialized in this |function |function| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34793
[Bug libstdc++/34794] build of gcc 4.2.2 fails on AIX 6.1 / libstdc++-v3/libmath/stubs.c:47
--- Comment #1 from pcarlini at suse dot de 2008-01-15 10:45 --- Hi David, can you have a look at this issue? Thanks. -- pcarlini at suse dot de changed: What|Removed |Added CC||dje at watson dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34794
[Bug target/34787] fix -shared + -pthread for mips/linux
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-15 10:37 --- Patches should be sent to [EMAIL PROTECTED] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34787
[Bug fortran/34795] New: inquire statement , direct= specifier incorrectly returns YES
The inquire direct= specifier always returns YES regardless how the file is created or actually opened. The bug has been seen on gfortran versions gcc version 4.1.0 20060304 (Red Hat 4.1.0-3) Target: x86_64-redhat-linux gcc version 4.1.1 20061011 (Red Hat 4.1.1-30) Target: i386-redhat-linux gcc version 4.1.2 20070925 (Red Hat 4.1.2-27) Target: x86_64-redhat-linux gcc version 4.2.0 20060713 (experimental) Target: powerpc-apple-darwin8 Causes code that depends on the returned value to read the file incorrectly and generate an I/O error Bug is reproducible with a simple program == program testdirect character drct*4, acc*12 logical opn open(unit=19,file='testdirect.f',status='OLD',err=170) inquire(unit=19, direct=drct, opened=opn, access=acc) write(*,*) default open drct=,drct, opened=,opn, access=,acc close(19) open(unit=19,file='testdirect.f',status='OLD',err=170, access='SEQUENTIAL') inquire(unit=19, direct=drct, opened=opn, access=acc) write(*,*) Sequent open drct=,drct, opened=,opn, access=,acc close(19) open(unit=19,file='testdirect.f',status='OLD',err=170, form='UNFORMATTED',access='DIRECT',recl=72) inquire(unit=19, direct=drct, opened=opn, access=acc) write(*,*) direct open drct=,drct, opened=,opn, access=,acc close(19) stop 170 write(*,*) ERROR: unable to open testdirect.f end file name: testdirect.f compiled with: gfortran testdirect.f File output: default open drct=YES opened= T access=SEQUENTIAL Sequent open drct=YES opened= T access=SEQUENTIAL direct open drct=YES opened= T access=DIRECT correct output (produced by g77) default open drct=NO opened= T access=SEQUENTIAL Sequent open drct=NO opened= T access=SEQUENTIAL direct open drct=YES opened= T access=DIRECT -- Summary: inquire statement , direct= specifier incorrectly returns YES Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kendrick dot killian at colostate dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34795
[Bug libstdc++/34794] build of gcc 4.2.2 fails on AIX 6.1 / libstdc++-v3/libmath/stubs.c:47
--- Comment #2 from tammer at tammer dot net 2008-01-15 11:28 --- Hello, currently I am working with Ralf Wildenhues (libtool, autconf, automake, config) to get AIX 6.1 in. The libtool (branch-1.5 / HEAD) and config.guess now recognizes AIX 6.1 as - powerpc-ibm-aix6.1.0.0. I have not yet regenerated the complete build environment of gcc 4.2.2 with the above tools. As gcc is a very large project I am not comfortable in rebuilding the whole shebang... Bye Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34794
[Bug middle-end/34793] warning: 'areg' may be used uninitialized in this function
--- Comment #3 from j at uriah dot heep dot sax dot de 2008-01-15 12:54 --- (In reply to comment #2) The fix for PR14495 will likely fix this (by removing the default case again). Alas, no, it doesn't. I applied that patch (and the one it depends one mentioned in the article), rebuilt, but I'm still getting the warning for this test case. If you want me to append some trace data, just tell me how to do it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34793
[Bug fortran/34796] New: [4.3 Regression] Too strict error checking for assumed-shaped array
Compiling gives twice the error message: Error: Element of assumed-shaped array passed to dummy argument 'y' Other compilers give it only for rdiff2; thinking over it, there is no reason to reject it for rdiff as the memory is contiguous which might not be the case for dummy arguments (stripes!). I will try to dig out the exact wording from the standard. The check was added by me in PR34665. A simple fix would be to check for attr.dummy, but maybe one has to do something else. subroutine test(rdiff2) implicit none interface subroutine rlv(y) real :: y(3) end subroutine rlv end interface real, allocatable :: rdiff(:,:,:) real :: rdiff2(:,:,:) call rlv(rdiff(1,1,1)) ! OK, it is contiguous memory (error wrong) call rlv(rdiff2(1,1,1)) ! WRONG, error is ok (non contiguous) end -- Summary: [4.3 Regression] Too strict error checking for assumed- shaped array Product: gcc Version: 4.3.0 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=34796
[Bug libstdc++/34797] New: [parallel mode] Settings are separated for each compilation unit
In settings.h, the Settings class (containing only static variables) is encapsulated in an anonymous namespace. This makes the linker think of a distinct class for each compilation unit. As as result, settings changed in one .cpp file won't affect code from another .cpp file, although they should have global effect. -- Summary: [parallel mode] Settings are separated for each compilation unit Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: singler at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34797
[Bug libstdc++/34797] [parallel mode] Settings are separated for each compilation unit
--- Comment #1 from singler at gcc dot gnu dot org 2008-01-15 13:15 --- First of all, we should get rid of these many static variables in the Settings class, and replace them by usual member variables. Then, there should be one static/global instance of this Settings class. The question remains how to concretely implement this static variable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34797
[Bug c++/33887] [4.1/4.2/4.3 Regression] Reference to bitfield gets wrong value when optimizing
--- Comment #24 from rguenth at gcc dot gnu dot org 2008-01-15 13:23
---
So the issue is that for
void foo(unsigned int) (i)
{
unnamed-unsigned:24 i.0;
bb 2:
i.0 = (unnamed-unsigned:24) i;
sv.f2 = i.0;
if ((unsigned int) i.0 != 0)
we neither emit code for the narrowing nor for the widening, but only
for the bitfield store:
;; i.0 = (unnamed-unsigned:24) i
(insn 6 5 0 t.ii:16 (set (reg:SI 58 [ i.0 ])
(reg/v:SI 59 [ i ])) -1 (nil))
;; sv.f2 = i.0
... proper code
;; if ((unsigned int) i.0 != 0)
(insn 14 13 15 t.ii:18 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 58 [ i.0 ])
(const_int 0 [0x0]))) -1 (nil))
(jump_insn 15 14 0 t.ii:18 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0x0]))
(label_ref 0)
(pc))) -1 (expr_list:REG_BR_PROB (const_int 9900 [0x26ac])
(nil)))
see how we simply re-use the incoming register for the comparison. Neither
did we truncate that, nor do we zero-extend before the comparison.
The C frontend produces the same IL but due to the activated langhook we
instead expand to
;; i.0 = (unnamed-unsigned:24) i
(insn 6 5 0 t.i:12 (parallel [
(set (reg:SI 58 [ i.0 ])
(and:SI (reg/v:SI 59 [ i ])
(const_int 16777215 [0xff])))
(clobber (reg:CC 17 flags))
]) -1 (nil))
;; sv.f2 = i.0
... same code as for C++
;; if ((unsigned int) i.0 != 0)
(insn 14 13 15 t.i:14 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 58 [ i.0 ])
(const_int 0 [0x0]))) -1 (nil))
(jump_insn 15 14 0 t.i:14 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0x0]))
(label_ref 0)
(pc))) -1 (expr_list:REG_BR_PROB (const_int 9900 [0x26ac])
(nil)))
note we also do not emit code for the widening here.
The same is true for the signed case.
We can enable this particular behavior for all frontends with
Index: expr.c
===
--- expr.c (revision 131542)
+++ expr.c (working copy)
@@ -7157,7 +7157,11 @@ expand_expr_real_1 (tree exp, rtx target
mode = TYPE_MODE (type);
unsignedp = TYPE_UNSIGNED (type);
}
- if (lang_hooks.reduce_bit_field_operations
+ if ((lang_hooks.reduce_bit_field_operations
+ /* Always reduce conversion results to the target precision. */
+ || code == NON_LVALUE_EXPR
+ || code == NOP_EXPR
+ || code == CONVERT_EXPR)
TREE_CODE (type) == INTEGER_TYPE
GET_MODE_PRECISION (mode) TYPE_PRECISION (type))
{
but that breaks libjava again.
It also does _not_ fix the original testcase, as that would require
reducing also the increment expression. This can be fixed by properly
lowering increment expressions as with
Index: cp/typeck.c
===
*** cp/typeck.c (revision 131542)
--- cp/typeck.c (working copy)
*** build_unary_op (enum tree_code code, tre
*** 4340,4345
--- 4347,4375
}
val = boolean_increment (code, arg);
}
+ /* If the type is a bitfield, lower the expression to an
+ assignment with a properly promoted bitfield rvalue increment.
+
+[5.3.2/1] If x is not of type bool, the expression ++x is
+equivalent to x+=1.
+
+ thus integer promotions are supposed to happen, and in the
+ case of bitfields it is important for semantics. */
+ else if (INTEGRAL_TYPE_P (argtype)
+ (TYPE_PRECISION (argtype)
+!= GET_MODE_BITSIZE (TYPE_MODE (argtype
+ {
+ tree rarg = arg;
+ if (code == POSTINCREMENT_EXPR || code == POSTDECREMENT_EXPR)
+ rarg = save_expr (arg);
+ if (code == PREINCREMENT_EXPR || code == POSTINCREMENT_EXPR)
+ val = build_binary_op (PLUS_EXPR, rarg, inc, 1);
+ else
+ val = build_binary_op (MINUS_EXPR, rarg, inc, 1);
+ val = build_modify_expr (arg, NOP_EXPR, val);
+ if (code == POSTINCREMENT_EXPR || code == POSTDECREMENT_EXPR)
+ val = build_compound_expr (val, rarg);
+ }
else
val = build2 (code, TREE_TYPE (arg), arg, inc);
but this adjustment alone doesn't fix the original testcase either,
because we still do the comparison in the bitfield type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887
[Bug middle-end/34793] warning: 'areg' may be used uninitialized in this function
--- Comment #4 from rguenther at suse dot de 2008-01-15 13:27 --- Subject: Re: warning: 'areg' may be used uninitialized in this function On Tue, 15 Jan 2008, j at uriah dot heep dot sax dot de wrote: --- Comment #3 from j at uriah dot heep dot sax dot de 2008-01-15 12:54 --- (In reply to comment #2) The fix for PR14495 will likely fix this (by removing the default case again). Alas, no, it doesn't. I applied that patch (and the one it depends one mentioned in the article), rebuilt, but I'm still getting the warning for this test case. If you want me to append some trace data, just tell me how to do it. Oh, indeed - it also needs PR30317 fixed. (the attached patches therein probably no longer apply) The problem is that for the range check we create a fancy unsigned compare, which VRP does not handle yet. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34793
[Bug libstdc++/34797] [parallel mode] Settings are separated for each compilation unit
--- Comment #2 from singler at gcc dot gnu dot org 2008-01-15 13:20 --- There are two general options to fix this bug: 1. Introduce a global variable, to be compiled into libstdc++.a and libstdc++.so. 2. Do the template trick, i. e. pseudo-parametrize Settings as template class, to leave it to the compiler to merge the instantiations. The class would always have to instantiated with the same template arguments, but that could be hidden by a typedef. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34797
[Bug libstdc++/33490] parallel v3: std::accumulate assumes iterators have std::iterator_traits declared
--- Comment #6 from singler at gcc dot gnu dot org 2008-01-15 13:05 --- No further objections. -- singler at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33490
[Bug fortran/34796] [4.3 Regression] Too strict error checking for assumed-shaped array
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-15 14:04 --- From the Fortran 2003 standard (12.4.1.2 Actual arguments associated with dummy data objects) If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual argument is of type default character, of type character with the C character kind (15.1), or is an element or substring of an element of an array that is not an assumed-shape or pointer array. If the procedure is nonelemental and is referenced by a generic name or as a defined operator or defined assignment, the ranks of the actual arguments and corresponding dummy arguments shall agree. If a dummy argument is an assumed-shape array, the rank of the actual argument shall be the same as the rank of the dummy argument; the actual argument shall not be an assumed-size array (including an array element designator or an array element substring designator). In the example posted, the array is of DEFERRED type and not an ASSUMED-SHAPE array and thus the first part of the last paragraph does not apply. As DEFERRED arrays are also not forbidden in the paragraph before, they are allowed. Thus only a) pointer arrays (dummy or not) b) assumed-shape array (which are dummy arguments) should be rejected as they might have strides and thus accessing the next byte in memory might leave the array. -- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-15 14:04:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34796
[Bug c++/33887] [4.1/4.2/4.3 Regression] Reference to bitfield gets wrong value when optimizing
--- Comment #25 from rguenth at gcc dot gnu dot org 2008-01-15 14:05 --- Unassigning. I like to have help from somebody knowing how to debug the libjava failures. The only bitfields are defined in jvmti.h. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #31 from olga at gcc dot gnu dot org 2008-01-15 14:11 ---
I gave it another push. The following is a patch solving inconsistency of the
data structures in struct reorg, and releasing comparison with 0. Please try it
together with the Richard's patch. It should give extra XPASS. If it's ok for
you, I submit it for gcc-patches.
Thank you,
Olga
Index: ipa-struct-reorg.c
===
--- ipa-struct-reorg.c (revision 130927)
+++ ipa-struct-reorg.c (working copy)
@@ -187,7 +187,7 @@
typedef const struct func_alloc_sites *const_fallocs_t;
/* All allocation sites in the program. */
-htab_t alloc_sites;
+htab_t alloc_sites = NULL;
/* New global variables. Generated once for whole program. */
htab_t new_global_vars;
@@ -1246,12 +1248,14 @@
s0 = (str0 != length) ? true : false;
s1 = (str1 != length) ? true : false;
- gcc_assert ((!s0 s1) || (!s1 s0));
+ gcc_assert (s0 || s1);
+ /* For now we allow only comparison with 0 or NULL. */
+ gcc_assert (integer_zerop (arg0) || integer_zerop (arg1));
- str = s0 ? VEC_index (structure, structures, str0):
-VEC_index (structure, structures, str1);
- arg = s0 ? arg0 : arg1;
- pos = s0 ? 0 : 1;
+ str = integer_zerop (arg0) ? VEC_index (structure, structures, str1):
+VEC_index (structure, structures, str0);
+ arg = integer_zerop (arg0) ? arg1 : arg0;
+ pos = integer_zerop (arg0) ? 1 : 0;
for (i = 0; VEC_iterate (tree, str-new_types, i, type); i++)
{
@@ -2339,6 +2343,41 @@
htab_traverse (accs, dump_acc, NULL);
}
+/* This function is a callback for alloc_sites hashtable
+ traversal. SLOT is a pointer to fallocs_t. This function
+ removes all allocations of the structure defined by DATA. */
+
+static int
+remove_str_allocs_in_func (void **slot, void *data)
+{
+ fallocs_t fallocs = *(fallocs_t *) slot;
+ unsigned i = 0;
+ alloc_site_t *call;
+
+ while (VEC_iterate (alloc_site_t, fallocs-allocs, i, call))
+{
+ if (call-str == (d_str) data)
+ VEC_ordered_remove (alloc_site_t, fallocs-allocs, i);
+ else
+ i++;
+}
+
+ return 1;
+}
+
+/* This function remove all entries corresponding to the STR structure
+ from alloc_sites hashtable. */
+
+static void
+remove_str_allocs (d_str str)
+{
+ if (!str)
+return;
+
+ if (alloc_sites)
+htab_traverse (alloc_sites, remove_str_allocs_in_func, str);
+}
+
/* This function removes the structure with index I from structures vector.
*/
static void
@@ -2349,7 +2388,11 @@
if (i = VEC_length (structure, structures))
return;
- str = VEC_index (structure, structures, i);
+ str = VEC_index (structure, structures, i);
+
+ /* Before removing the structure str, we have to remove its
+ allocations from alloc_sites hashtable. */
+ remove_str_allocs (str);
free_data_struct (str);
VEC_ordered_remove (structure, structures, i);
}
@@ -2383,8 +2426,12 @@
s0 = (str0 != length) ? true : false;
s1 = (str1 != length) ? true : false;
+
+ if (!s0 !s1)
+return false;
- if (!((!s0 s1) || (!s1 s0)))
+ /* For now we allow only comparison with 0 or NULL. */
+ if (!integer_zerop (arg0) !integer_zerop (arg1))
return false;
return true;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug java/32484] build of junit 4.3.1 native lib fails
--- Comment #2 from debian-gcc at lists dot debian dot org 2008-01-15 14:54 --- confirmed. Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32484
[Bug middle-end/34793] warning: 'areg' may be used uninitialized in this function
--- Comment #6 from rguenther at suse dot de 2008-01-15 14:54 --- Subject: Re: warning: 'areg' may be used uninitialized in this function On Tue, 15 Jan 2008, j at uriah dot heep dot sax dot de wrote: --- Comment #5 from j at uriah dot heep dot sax dot de 2008-01-15 14:38 --- (In reply to comment #4) Oh, indeed - it also needs PR30317 fixed. (the attached patches therein probably no longer apply) I applied the second of the attached patches there. It applies cleanly, but still does not solve the issue. OK, I patched in somewhat the reverse order (PR 14495 first, then noticed I needed your previous patchset for the find_case_label_index() function, then finally applied the patch for PR 30317), but as the patches could all be applied, I think that doesn't matter much. If you've got a patched tree around, could you give the testcase of this PR here a try? Sorry, I don't have any of those trees left. But if I ever come to revisit those two bugs I'll make sure it fixes this bogus warning. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34793
[Bug middle-end/32628] [4.3 Regression] bogus integer overflow warning
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-01-15 14:44 ---
Reduced testcase:
int f(char *device)
{
return device == ((char *)0 + ~0UL);
}
for building the POINTER_PLUS_EXPR we convert the unsigned offset to
sizetype which causes the double-int (-1, 0) to sign-extend to (-1, -1)
signalling overflow (the positive value doesn't fit in sizetype).
In the context of POINTER_PLUS_EXPRs the sizetype offset depending on
evaluation context has an effective range of [-INT_MIN, UINT_MAX].
So in principle we want to not treat the sign/zero extension
that happens when converting from/to sizetype as overflow.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|pinskia at gcc dot gnu dot |rguenth at gcc dot gnu dot
|org |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32628
[Bug middle-end/34793] warning: 'areg' may be used uninitialized in this function
--- Comment #5 from j at uriah dot heep dot sax dot de 2008-01-15 14:38 --- (In reply to comment #4) Oh, indeed - it also needs PR30317 fixed. (the attached patches therein probably no longer apply) I applied the second of the attached patches there. It applies cleanly, but still does not solve the issue. OK, I patched in somewhat the reverse order (PR 14495 first, then noticed I needed your previous patchset for the find_case_label_index() function, then finally applied the patch for PR 30317), but as the patches could all be applied, I think that doesn't matter much. If you've got a patched tree around, could you give the testcase of this PR here a try? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34793
[Bug c/32455] [4.1/4.2/4.3 regression] ICE with modified va_list, allows declaration of __builtin_*
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-15 15:01 --- I think the frontend should reject identifiers in declarations that touch the __builtin_ namespace. The regression status is dubious (it probably 'regressed' at the point the builtin was introduced). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |c Known to fail||3.3.6 Known to work||2.95.4 Summary|[4.1/4.2/4.3 regression] ICE|[4.1/4.2/4.3 regression] ICE |with modified va_list |with modified va_list, ||allows declaration of ||__builtin_* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32455
[Bug middle-end/33699] [4.1/4.2/4.3 regression], missing optimization on const addr area store
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33699
[Bug java/32484] build of junit 4.3.1 native lib fails
--- Comment #3 from aph at gcc dot gnu dot org 2008-01-15 15:13 --- Fixed in trunk. Tested: zorro:~ $ ~/gcc/trunk/install/bin/gcj -shared -Wl,-Bsymbolic -fPIC -findirect-dispatch -fjni -g0 -O0 -mtune=nocona -march=nocona -pipe -w -save-temps -o libjunit.jar.so junit.jar gcj: warning: -pipe ignored because -save-temps specified zorro:~ $ -- aph at gcc dot gnu dot org changed: What|Removed |Added CC||aph at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32484
[Bug middle-end/18071] [4.0/4.1/4.2/4.3 Regression] -Winline does not respect -fno-default-inline
--- Comment #31 from rguenth at gcc dot gnu dot org 2008-01-15 15:22 --- Created an attachment (id=14943) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14943action=view) other approach to supress the warnings -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug fortran/31298] F2003: use mod, operator(+) = operator(.userOp.) not supported
--- Comment #14 from burnus at gcc dot gnu dot org 2008-01-15 15:21 --- Check that the renamed imported operator is not imported again, see PR 33541. If I recall correctly, this part is missing for the patch in PR 33541 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31298
[Bug ada/34799] New: [Ada] Assertion fails when no component clause is given for generic record member
In the example below gcc reports an assertion failure, when warnings are switched on. gcc -c -gnatwa status.ads fails, while gcc -c status.ads is working. The snapshot 4.3.0 20070921 is correctly warning 'no component clause given for C declared at line 12' while later snapshots (e.g. 4.3.0 20080111) fail. status.ads package STATUS is generic type CUSTOM_T is private; package HANDLER is type STORAGE_T is record A : Boolean; B : Boolean; C : CUSTOM_T; end record; for STORAGE_T use record A at 0 range 0..0; B at 1 range 0..0; end record; end HANDLER; end STATUS; -- Summary: [Ada] Assertion fails when no component clause is given for generic record member Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: markus dot heichel at comsoft dot de GCC build triplet: i686-pc-linux GCC host triplet: i686-pc-linux GCC target triplet: i686-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34799
[Bug middle-end/18071] [4.0/4.1/4.2/4.3 Regression] -Winline does not respect -fno-default-inline
--- Comment #30 from rguenth at gcc dot gnu dot org 2008-01-15 15:21
---
I suggest to tag the DECL with TREE_NO_WARNING if -fno-default-inline is set
and
check this.
On the trunk the functions are inlined anyway, because we inline small
functions by default (and the functions are pure anyway). Also trunk
tests
if (!flag_inline_small_functions !DECL_DECLARED_INLINE_P (decl))
{
if (reason)
*reason = N_(function not inline candidate);
return false;
that is, it uses DECL_DECLARED_INLINE_P (!) which is not affected by
-fno-default-inline.
Better testcase:
volatile int x;
struct Foo {
int a(int r) { return r x; }
virtual int b(int r) { return r x; }
static int c(int r) { return r x; }
};
int bar(int r) {
Foo f; int k = 0;
k |= f.a(r); k |= f.b(r); k |= f.a(r);
return k;
}
which will on the trunk warn with -fno-inline only.
With the proposed approach we'd improve this to
./cc1plus -quiet -Winline t.ii -O -fno-default-inline -fno-inline
t.ii: In constructor 'Foo::Foo()':
t.ii:2: warning: function 'Foo::Foo() throw ()' can never be inlined because it
is suppressed using -fno-inline
t.ii: In function 'int bar(int)':
t.ii:2: warning: inlining failed in call to 'Foo::Foo() throw ()': function not
inlinable
t.ii:9: warning: called from here
that is, the compiler-generated methods are still marked inline and are not
affected by -fno-default-inline.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org, hubicka at gcc dot gnu
||dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug java/32484] build of junit 4.3.1 native lib fails
--- Comment #4 from aph at gcc dot gnu dot org 2008-01-15 15:32 --- . -- aph at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32484
[Bug java/32484] build of junit 4.3.1 native lib fails
--- Comment #5 from aph at gcc dot gnu dot org 2008-01-15 15:32 --- *** This bug has been marked as a duplicate of 33639 *** -- aph at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32484
[Bug java/33639] gcj generates assembler errors
--- Comment #3 from aph at gcc dot gnu dot org 2008-01-15 15:32 --- *** Bug 32484 has been marked as a duplicate of this bug. *** -- aph at gcc dot gnu dot org changed: What|Removed |Added CC||h dot mth at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33639
[Bug middle-end/18071] [4.0/4.1/4.2/4.3 Regression] -Winline does not respect -fno-default-inline
--- Comment #33 from rguenther at suse dot de 2008-01-15 15:54 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] -Winline does not respect -fno-default-inline On Tue, 15 Jan 2008, hubicka at gcc dot gnu dot org wrote: --- Comment #32 from hubicka at gcc dot gnu dot org 2008-01-15 15:47 --- I am bit confused by logic of code here. Middle end now ingore DECL_INLINE consistently, it is still arround since it affect some instantiation decisions in C++ FE. Does fno-default-inline work? I think only way to prevent inlining is to make C++ frontend to drop implicit noinline attribute or split the two meanings of DECL_DECLARED_INLINE (ie meaning to drive inliner and to drive linkage). As I understand it now, DECL_DECLARED_INLINE must be always set for functions that are implicitly inline, even with -fno-default-inline, because it affects linkage, right? Yes, this is what I understand. I think we need a new flag specifying if in the source the 'inline' keyword was used and solely use that for inline warning purposes. (That is, I would not expect to get a warning for non-'inline' class methods either, regardless of -fdefault-inline setting). Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug middle-end/18071] [4.0/4.1/4.2/4.3 Regression] -Winline does not respect -fno-default-inline
--- Comment #32 from hubicka at gcc dot gnu dot org 2008-01-15 15:47 --- I am bit confused by logic of code here. Middle end now ingore DECL_INLINE consistently, it is still arround since it affect some instantiation decisions in C++ FE. Does fno-default-inline work? I think only way to prevent inlining is to make C++ frontend to drop implicit noinline attribute or split the two meanings of DECL_DECLARED_INLINE (ie meaning to drive inliner and to drive linkage). As I understand it now, DECL_DECLARED_INLINE must be always set for functions that are implicitly inline, even with -fno-default-inline, because it affects linkage, right? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug c++/34052] [4.3 regression] Trouble with variadic templates as template-template parameter
--- Comment #9 from dgregor at gcc dot gnu dot org 2008-01-15 16:07 --- Fixed in mainline -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34052
[Bug c++/33964] [4.3 Regression] internal compiler error: in dependent_type_p, at cp/pt.c:15319 (vararg templates)
--- Comment #6 from dgregor at gcc dot gnu dot org 2008-01-15 16:09 --- Fixed on mainline -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33964
[Bug c++/34052] [4.3 regression] Trouble with variadic templates as template-template parameter
--- Comment #8 from dgregor at gcc dot gnu dot org 2008-01-15 16:07 --- Subject: Bug 34052 Author: dgregor Date: Tue Jan 15 16:06:48 2008 New Revision: 131543 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131543 Log: 2008-01-15 Douglas Gregor [EMAIL PROTECTED] PR c++/34052 * pt.c (check_default_tmpl_args): Check for parameter packs that aren't at the end of a primary template. (push_template_decl_real): Remove check for parameter packs that aren't at the end of a primary template; that now happens in check_default_tmpl_args. * semantics.c (finish_template_template_parm): Use check_default_tmpl_args to check for errors in the template parameter list. 2008-01-15 Douglas Gregor [EMAIL PROTECTED] PR c++/34052 * g++.dg/cpp0x/vt-34052.C: New. * g++.dg/template/ttp26.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/vt-34052.C trunk/gcc/testsuite/g++.dg/template/ttp26.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34052
[Bug middle-end/18071] [4.0/4.1/4.2/4.3 Regression] -Winline does not respect -fno-default-inline
--- Comment #34 from hubicka at ucw dot cz 2008-01-15 15:59 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] -Winline does not respect -fno-default-inline Yes, this is what I understand. I think we need a new flag specifying if in the source the 'inline' keyword was used and solely use that for inline warning purposes. (That is, I would not expect to get a warning for non-'inline' class methods either, regardless of -fdefault-inline setting). Here I tend to be more with Geoff: since C++ standard says that inline keyword is imlicit, I don't see why we should not warn on it and why extra inline keyword should make difference. We don't handle those functions specially in other inlining heuristics and thus it is bit instructive to users to force them realize that they really are inline. But if C++ people preffer to not warn, I definitly won't object. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug c++/34756] [4.3 regression] ICE with broken specialization of variadic template
-- dgregor at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-13 15:25:29 |2008-01-15 16:32:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34756
[Bug c++/33964] [4.3 Regression] internal compiler error: in dependent_type_p, at cp/pt.c:15319 (vararg templates)
--- Comment #7 from dgregor at gcc dot gnu dot org 2008-01-15 16:10 --- Subject: Bug 33964 Author: dgregor Date: Tue Jan 15 16:09:28 2008 New Revision: 131544 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131544 Log: 2008-01-15 Douglas Gregor [EMAIL PROTECTED] PR c++/33964 * pt.c (process_partial_specialization): Don't mark template parameters that occur in non-deduced contexts. (struct pair_fn_data): Add include_nondeduced_p. (for_each_template_parm_r): Only visit non-deduced contexts if include_nondeduced_p is set. (for_each_template_parm): Added parameter include_nondeduced_p, which states whether template parameters found in non-deduced contexts should be visited. (uses_template_parms): Visit all template parameters, even those in non-deduced contexts. 2008-01-15 Douglas Gregor [EMAIL PROTECTED] PR c++/33964 * g++.dg/cpp0x/vt-33964.C: New. * g++.dg/template/partial5.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/vt-33964.C trunk/gcc/testsuite/g++.dg/template/partial5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33964
[Bug c++/34755] [4.3 regression] ICE with invalid argument in variadic template function
-- dgregor at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-13 15:24:35 |2008-01-15 16:34:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34755
[Bug c++/34757] [4.3 regression] ICE with invalid parameters in variadic template
-- dgregor at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-12 19:44:46 |2008-01-15 16:35:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34757
[Bug c++/34754] [4.3 regression] ICE with invalid function arguments in variadic template
-- dgregor at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-12 19:44:25 |2008-01-15 16:35:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34754
[Bug c++/34753] [4.3 regression] ICE with invalid template parameter in variadic template
-- dgregor at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-12 19:43:54 |2008-01-15 16:36:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34753
[Bug c++/34752] pointer to member rejected in variadic template
-- dgregor at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-15 16:37:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34752
[Bug c++/34050] [4.3 regression] ICE derived classes and variadic templates
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-15 16:40 --- This is an ice-on-valid, so it should probably be a P2. -- dgregor at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords|ice-on-invalid-code |ice-on-valid-code Last reconfirmed|2007-11-19 05:53:40 |2008-01-15 16:40:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34050
[Bug middle-end/18071] [4.0/4.1/4.2/4.3 Regression] -Winline does not respect -fno-default-inline
--- Comment #35 from manu at gcc dot gnu dot org 2008-01-15 16:44 --- (In reply to comment #33) Yes, this is what I understand. I think we need a new flag specifying if in the source the 'inline' keyword was used and solely use that for inline warning purposes. (That is, I would not expect to get a warning for non-'inline' class methods either, regardless of -fdefault-inline setting). Then, you would need more than a new flag. Currently the problem is to distinguish 1) the explicit 'inline' keyword and the implicit inline keyword of -fdefault-inline from 2) no inline whatsoever and no inline because of -fno-default-inline Currently: explicit inline: DECL_DECLARED_INLINE fdefault-inline : DECL_DECLARED_INLINE fno-default-inline: DECL_DECLARED_INLINE no inline: (DECL_INLINE is an internal note that the function may be inlinable. Neither explicit inline nor -fdefault-inline actually ensure that DECL_INLINE will be always true). Ideally: explicit inline: DECL_DECLARED_INLINE DECL_INLINE_LINKAGE fdefault-inline : DECL_DECLARED_INLINE DECL_INLINE_LINKAGE fno-default-inline: DECL_INLINE_LINKAGE no inline: In your proposal we will need: explicit inline: DECL_EXPLICITLY_DECLARED_INLINE DECL_DECLARED_INLINE DECL_INLINE_LINKAGE fdefault-inline : DECL_DECLARED_INLINE DECL_INLINE_LINKAGE fno-default-inline: DECL_INLINE_LINKAGE no inline: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug c++/34055] [4.3 regression] ICE with invalid specialization of variadic template
--- Comment #3 from dgregor at gcc dot gnu dot org 2008-01-15 16:59 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00650.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34055
[Bug c++/34102] [4.3 regression] ICE with invalid inheritance of variadic templates
--- Comment #3 from dgregor at gcc dot gnu dot org 2008-01-15 16:59 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00650.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34102
[Bug c++/34103] [4.3 regression] ICE with invalid variadic template functions
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-01-15 16:59 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00650.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34103
[Bug rtl-optimization/25609] too agressive printf optimization
--- Comment #16 from gustavodn at gmail dot com 2008-01-15 17:20 --- Glibc being Linux being the world is not really relevant, IMHO. What is relevant is printf() (or any function) is, fundamentally, implemented by library, not by compiler, so compiler should not prevent library from defining behavior not defined in the standard. So I think gcc should either: - provide means to disable printf (or more generaly, any specific function) optimization based on library being linked - not optimize printf in this way, unless requested (i.e. do not include this optimization in any predefined optimizations list - probably other alternatives -- gustavodn at gmail dot com changed: What|Removed |Added CC||gustavodn at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
[Bug c/28706] [4.1 Regression] Compile failure with --combine and explicitly aligned structures
--- Comment #6 from alexandre dot nunes at gmail dot com 2008-01-15 17:40 --- This seems to work as of gcc 4.2.2 (vanilla), using the original commands to reproduce. Anyone denies/confirms this? -- alexandre dot nunes at gmail dot com changed: What|Removed |Added CC||alexandre dot nunes at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28706
[Bug c/34800] New: Compile failure with --combine and a union with an anonymous struct
$ cat pqp.c
typedef union {
struct
{
unsigned char d;
};
unsigned char a, b;
} test_type;
extern test_type whatever;
$ gcc -c pqp.c
$ gcc --combine -c pqp.c pqp.c
pqp.c:9: error: conflicting types for whatever
pqp.c:9: error: previous declaration of whatever was here
This seems like a more strict case of bug 28706 or something.
--
Summary: Compile failure with --combine and a union with an
anonymous struct
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexandre dot nunes at gmail dot com
GCC host triplet: i686-unknow-linux
GCC target triplet: arm-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34800
[Bug c/28706] [4.1 Regression] Compile failure with --combine and explicitly aligned structures
--- Comment #7 from alexandre dot nunes at gmail dot com 2008-01-15 17:55 --- (In reply to comment #6) This seems to work as of gcc 4.2.2 (vanilla), using the original commands to reproduce. Anyone denies/confirms this? ... and please see bug 34800 . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28706
[Bug c/28712] [4.0/4.1 Regression] Compile failure with --combine and packed structures.
--- Comment #5 from alexandre dot nunes at gmail dot com 2008-01-15 17:58 --- (In reply to comment #4) won't fix in GCC-4.0.x. Adjusting milestone. For anyone interested, I think this is fixed for at least gcc 4.2.2; I couldn't reproduce it. -- alexandre dot nunes at gmail dot com changed: What|Removed |Added CC||alexandre dot nunes at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28712
[Bug c++/34314] [4.3 Regression] ICE on invalid code (with variadic templates): tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in template_class_depth
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-15 18:00 --- Subject: Bug 34314 Author: dgregor Date: Tue Jan 15 17:59:44 2008 New Revision: 131546 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131546 Log: 2008-01-15 Douglas Gregor [EMAIL PROTECTED] PR c++/34314 * error.c (dump_simple_decl): Display ellipsis for template non-type parameter packs. (dump_decl): Display ellipsis for template type parameter packs. (dump_template_decl): Display ellipsis for template template parameter packs. * pt.c (redeclare_class_template): When redeclaring a class template, check for collisions between template parameters and template parameter packs. 2008-01-15 Douglas Gregor [EMAIL PROTECTED] PR c++/34314 * g++.dg/cpp0x/vt-34314.C: New. * g++.dg/cpp0x/variadic79.C: Fix the error message to reflect reality (the error message was wrong previously). Added: trunk/gcc/testsuite/g++.dg/cpp0x/vt-34314.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/g++.dg/cpp0x/variadic79.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34314
[Bug fortran/34796] [4.3 Regression] Too strict error checking for assumed-shaped array
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-15 18:00 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00656.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34796
[Bug c/28744] externally_visible attribute not effective with prior declaration of symbol.
--- Comment #16 from alexandre dot nunes at gmail dot com 2008-01-15 18:03 --- vanilla gcc 4.2.2 seems to compile this testcase ok (all five symbols are emmited and externally visible, no warnings) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28744
[Bug c++/34314] [4.3 Regression] ICE on invalid code (with variadic templates): tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in template_class_depth
--- Comment #6 from dgregor at gcc dot gnu dot org 2008-01-15 18:05 --- Fixed on mainline -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34314
[Bug c++/34051] [4.3 regression] ICE in dependent_type_p with variadic templates
--- Comment #8 from dgregor at gcc dot gnu dot org 2008-01-15 18:08 --- Fixed in mainline -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34051
[Bug c++/34055] [4.3 regression] ICE with invalid specialization of variadic template
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-01-15 18:08 --- Subject: Bug 34055 Author: dgregor Date: Tue Jan 15 18:08:00 2008 New Revision: 131547 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131547 Log: 2008-01-15 Douglas Gregor [EMAIL PROTECTED] PR c++/34051 PR c++/34055 PR c++/34102 PR c++/34103 * typeck.c (check_return_expr): If there are bare parameter packs in the return value, set it to error_mark_node. * tree.c (cp_walk_subtrees): Walk USING_DECL nodes. * pt.c (find_parameter_packs_r): Look at the type of IDENTIFIER_NODEs (e.g., for user-defined conversions). (check_for_bare_parameter_packs): Flip the result: now returns TRUE when there were bare parameter packs, FALSE otherwise. (push_template_decl_real): Deal with flipped result of check_for_bare_parameter_packs. * semantics.c (finish_cond): If there are bare parameter packs in the conditional, set it to error_mark_node. (finish_expr_stmt): If there are bare parameter packs in the expression, set it to error_mark_node. (finish_for_expr): Ditto. (finish_switch_cond): If there are bare parameter packs in the conditional, set it to error_mark_node. (finish_mem_initializers): If there are bare parameter packs in the member initializer, set it to error_mark_node. (finish_member_declaration): Check the attributes of the declaration for bare parameter packs, and remove the attributes if any have bare parameter packs. * parser.c (cp_parser_using_declaration): Check the using declaration for bare parameter packs. (cp_parser_base_clause): If there are bare parameter packs in a base specifier, don't add it to the chain. 2008-01-15 Douglas Gregor [EMAIL PROTECTED] PR c++/34051 PR c++/34055 PR c++/34102 PR c++/34103 * g++.dg/cpp0x/vt-34051-2.C: New. * g++.dg/cpp0x/vt-34102.C: New. * g++.dg/cpp0x/vt-34051.C: New. * g++.dg/cpp0x/vt-34055.C: New. * g++.dg/cpp0x/vt-34103.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/vt-34051-2.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-34051.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-34055.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-34102.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-34103.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/cp/tree.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34055
[Bug c++/34051] [4.3 regression] ICE in dependent_type_p with variadic templates
--- Comment #9 from dgregor at gcc dot gnu dot org 2008-01-15 18:08 --- Subject: Bug 34051 Author: dgregor Date: Tue Jan 15 18:08:00 2008 New Revision: 131547 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131547 Log: 2008-01-15 Douglas Gregor [EMAIL PROTECTED] PR c++/34051 PR c++/34055 PR c++/34102 PR c++/34103 * typeck.c (check_return_expr): If there are bare parameter packs in the return value, set it to error_mark_node. * tree.c (cp_walk_subtrees): Walk USING_DECL nodes. * pt.c (find_parameter_packs_r): Look at the type of IDENTIFIER_NODEs (e.g., for user-defined conversions). (check_for_bare_parameter_packs): Flip the result: now returns TRUE when there were bare parameter packs, FALSE otherwise. (push_template_decl_real): Deal with flipped result of check_for_bare_parameter_packs. * semantics.c (finish_cond): If there are bare parameter packs in the conditional, set it to error_mark_node. (finish_expr_stmt): If there are bare parameter packs in the expression, set it to error_mark_node. (finish_for_expr): Ditto. (finish_switch_cond): If there are bare parameter packs in the conditional, set it to error_mark_node. (finish_mem_initializers): If there are bare parameter packs in the member initializer, set it to error_mark_node. (finish_member_declaration): Check the attributes of the declaration for bare parameter packs, and remove the attributes if any have bare parameter packs. * parser.c (cp_parser_using_declaration): Check the using declaration for bare parameter packs. (cp_parser_base_clause): If there are bare parameter packs in a base specifier, don't add it to the chain. 2008-01-15 Douglas Gregor [EMAIL PROTECTED] PR c++/34051 PR c++/34055 PR c++/34102 PR c++/34103 * g++.dg/cpp0x/vt-34051-2.C: New. * g++.dg/cpp0x/vt-34102.C: New. * g++.dg/cpp0x/vt-34051.C: New. * g++.dg/cpp0x/vt-34055.C: New. * g++.dg/cpp0x/vt-34103.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/vt-34051-2.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-34051.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-34055.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-34102.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-34103.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/cp/tree.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34051
[Bug c++/34103] [4.3 regression] ICE with invalid variadic template functions
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-15 18:08 --- Subject: Bug 34103 Author: dgregor Date: Tue Jan 15 18:08:00 2008 New Revision: 131547 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131547 Log: 2008-01-15 Douglas Gregor [EMAIL PROTECTED] PR c++/34051 PR c++/34055 PR c++/34102 PR c++/34103 * typeck.c (check_return_expr): If there are bare parameter packs in the return value, set it to error_mark_node. * tree.c (cp_walk_subtrees): Walk USING_DECL nodes. * pt.c (find_parameter_packs_r): Look at the type of IDENTIFIER_NODEs (e.g., for user-defined conversions). (check_for_bare_parameter_packs): Flip the result: now returns TRUE when there were bare parameter packs, FALSE otherwise. (push_template_decl_real): Deal with flipped result of check_for_bare_parameter_packs. * semantics.c (finish_cond): If there are bare parameter packs in the conditional, set it to error_mark_node. (finish_expr_stmt): If there are bare parameter packs in the expression, set it to error_mark_node. (finish_for_expr): Ditto. (finish_switch_cond): If there are bare parameter packs in the conditional, set it to error_mark_node. (finish_mem_initializers): If there are bare parameter packs in the member initializer, set it to error_mark_node. (finish_member_declaration): Check the attributes of the declaration for bare parameter packs, and remove the attributes if any have bare parameter packs. * parser.c (cp_parser_using_declaration): Check the using declaration for bare parameter packs. (cp_parser_base_clause): If there are bare parameter packs in a base specifier, don't add it to the chain. 2008-01-15 Douglas Gregor [EMAIL PROTECTED] PR c++/34051 PR c++/34055 PR c++/34102 PR c++/34103 * g++.dg/cpp0x/vt-34051-2.C: New. * g++.dg/cpp0x/vt-34102.C: New. * g++.dg/cpp0x/vt-34051.C: New. * g++.dg/cpp0x/vt-34055.C: New. * g++.dg/cpp0x/vt-34103.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/vt-34051-2.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-34051.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-34055.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-34102.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-34103.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/cp/tree.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34103
[Bug c++/34102] [4.3 regression] ICE with invalid inheritance of variadic templates
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-01-15 18:08 --- Subject: Bug 34102 Author: dgregor Date: Tue Jan 15 18:08:00 2008 New Revision: 131547 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131547 Log: 2008-01-15 Douglas Gregor [EMAIL PROTECTED] PR c++/34051 PR c++/34055 PR c++/34102 PR c++/34103 * typeck.c (check_return_expr): If there are bare parameter packs in the return value, set it to error_mark_node. * tree.c (cp_walk_subtrees): Walk USING_DECL nodes. * pt.c (find_parameter_packs_r): Look at the type of IDENTIFIER_NODEs (e.g., for user-defined conversions). (check_for_bare_parameter_packs): Flip the result: now returns TRUE when there were bare parameter packs, FALSE otherwise. (push_template_decl_real): Deal with flipped result of check_for_bare_parameter_packs. * semantics.c (finish_cond): If there are bare parameter packs in the conditional, set it to error_mark_node. (finish_expr_stmt): If there are bare parameter packs in the expression, set it to error_mark_node. (finish_for_expr): Ditto. (finish_switch_cond): If there are bare parameter packs in the conditional, set it to error_mark_node. (finish_mem_initializers): If there are bare parameter packs in the member initializer, set it to error_mark_node. (finish_member_declaration): Check the attributes of the declaration for bare parameter packs, and remove the attributes if any have bare parameter packs. * parser.c (cp_parser_using_declaration): Check the using declaration for bare parameter packs. (cp_parser_base_clause): If there are bare parameter packs in a base specifier, don't add it to the chain. 2008-01-15 Douglas Gregor [EMAIL PROTECTED] PR c++/34051 PR c++/34055 PR c++/34102 PR c++/34103 * g++.dg/cpp0x/vt-34051-2.C: New. * g++.dg/cpp0x/vt-34102.C: New. * g++.dg/cpp0x/vt-34051.C: New. * g++.dg/cpp0x/vt-34055.C: New. * g++.dg/cpp0x/vt-34103.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/vt-34051-2.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-34051.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-34055.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-34102.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-34103.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/cp/tree.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34102
[Bug c++/34055] [4.3 regression] ICE with invalid specialization of variadic template
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-15 18:09 --- Fixed in mainline -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34055
[Bug c++/34102] [4.3 regression] ICE with invalid inheritance of variadic templates
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-15 18:09 --- Fixed in mainline -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34102
[Bug c++/34103] [4.3 regression] ICE with invalid variadic template functions
--- Comment #6 from dgregor at gcc dot gnu dot org 2008-01-15 18:09 --- Fixed in mainline -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34103
[Bug middle-end/28755] [4.0/4.1/4.2 Regression] duplicate members of arrays
--- Comment #9 from alexandre dot nunes at gmail dot com 2008-01-15 18:12 --- (In reply to comment #8) Fixed on the trunk. For anyone else wondering, this is still reproductible on vanilla gcc 4.2.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28755
[Bug c++/34751] [4.3 regression] ICE with pointer to member and variadic templates
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-01-15 18:50 --- Fixed in mainline -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34751
[Bug c++/34751] [4.3 regression] ICE with pointer to member and variadic templates
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-15 18:50 --- Subject: Bug 34751 Author: dgregor Date: Tue Jan 15 18:49:47 2008 New Revision: 131548 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131548 Log: 2008-01-15 Douglas Gregor [EMAIL PROTECTED] PR c++/34751 * pt.c (coerce_template_parameter_pack): When substituting into the type of a non-type template parameter pack. use the deduced/substituted arguments. * parser.c (declarator_can_be_parameter_pack): A pointer-to-member can be a parameter pack with the ellipsis following it. When we have an erroneous declaration, allow it to be a parameter pack. (cp_parser_template_parameter): Complain about default arguments on non-type template parameter packs, and parse them using the new cp_parser_default_argument. (cp_parser_parameter_declaration): Complain about parameter packs with default arguments. Move parsing of default arguments into a new function, cp_parser_default_argument. (cp_parser_default_argument): New; extracted from cp_parser_parameter_declaration. 2008-01-15 Douglas Gregor [EMAIL PROTECTED] PR c++/34751 * g++.dg/cpp0x/vt-34751.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/vt-34751.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34751
[Bug rtl-optimization/25609] too agressive printf optimization
--- Comment #17 from manu at gcc dot gnu dot org 2008-01-15 18:51 --- This will be fixed yesterday if printf(%s\n, s) were equivalent to puts(s) in glibc. Also there is a way to disable the optimization: -fno-builtin-printf. People that don't rely on undefined behaviour don't deserve to be punished with suboptimal code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
[Bug fortran/34795] inquire statement , direct= specifier incorrectly returns YES
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-15 19:12 --- | correct output (produced by g77) | default open drct=NO opened= T access=SEQUENTIAL | Sequent open drct=NO opened= T access=SEQUENTIAL | direct open drct=YES opened= T access=DIRECT How do you know which answer is correct? I think this is the same problem as formatted and unformatted: The answers are only correct with a certain probability. One can even open an UNFORMATTED file as FORMATTED though reading probably produces only garbage. As starting point I would recommend to read: http://groups.google.com/group/comp.lang.fortran/msg/b2ab0a6e106d977c (and maybe also the complete thread). If you can then explain why a certain value is better than another, we might change it. (By the way, the only true answer is UNKNOWN.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34795
[Bug c++/34050] [4.3 regression] ICE derived classes and variadic templates
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-01-15 19:19 --- (In reply to comment #5) This is an ice-on-valid, so it should probably be a P2. Well it is both depending on -std= settings. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34050
[Bug fortran/34788] Error diagnostic issued passing array element to explicit shape dummy argument
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-15 19:30 --- Confirmed. Your bugreport was there even before mine, but since my contains a link to the patch I mark yours as duplicate. Thanks for finding the bug. This diagnostic is (a) misleading - b is NOT an assumed-shape array, and (b) incorrect. I believe the code is standard conforming Fortran under the provision allowing an array element to be passed to an array dummy argument. (a) is true: It is an array of deferred shape and thus the error message is indeed wrong. (Both from the message and from showing an error message at all.) Otherwise the error message is correct: You may not pass an element of an assumed-shape array (or a pointer) to an assumed-shape dummy argument. The reason is that there is no reason for such arrays to be contiguous in memory. Assume for instance: subroutine func(a) integer :: a(:) call func2(a(4)) contains subroutine func2(b) integer :: b(5) ! or integer :: b(*) end subroutine func2 end subroutine func If one now calls func as call func(array(1:100:20)), the array A is not contiguous in memory because of the strides. Passing A(4) now to func2 poses a problem: b(2) is outside of the array A (though within array array). In order to prevent this problem, the standard does not allow to pass elements of assumed-shaped arrays or pointers as actual argument to array dummy arguments. The bug is only that my patch accidentally also rejected arrays with deferred shape (as your example); since here the allocation is in the same subroutine as the call, the memory is contiguous and there is no problem. (In principle, the array A could be copied into a temporary array with no strides, but this is not what the standard mandates here. If one calls func2 as call func2(a(11:15)) this is actually done so - if A has strides.) *** This bug has been marked as a duplicate of 34796 *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34788
[Bug fortran/34796] [4.3 Regression] Too strict error checking for assumed-shaped array
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-15 19:30 --- *** Bug 34788 has been marked as a duplicate of this bug. *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||krefson at googlemail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34796
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #32 from dominiq at lps dot ens dot fr 2008-01-15 20:03 --- With the patches in comments #11 and 31, the error disappears in 32 bit mode on Intel Darwin9 (as with #11 alone), now appears in 64 bit mode with the other errors already reported: FAIL: gcc.dg/struct/wo_prof_global_var.c execution test FAIL: gcc.dg/struct/wo_prof_local_var.c execution test FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c execution test new with patch #31 FAIL: gcc.dg/struct/wo_prof_mult_field_peeling.c execution test FAIL: gcc.dg/struct/wo_prof_two_strs.c execution test FAIL: gcc.dg/struct/w_prof_global_var.c execution,-O3 -fwhole-program -combine -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all FAIL: gcc.dg/struct/w_prof_local_var.c execution,-O3 -fwhole-program -combine -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all FAIL: gcc.dg/struct/w_prof_two_strs.c execution,-O3 -fwhole-program -combine -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug c++/34774] [4.1/4.2/4.3 Regression] templates, enumerations, overflow, ice
--- Comment #14 from tbptbp at gmail dot com 2008-01-15 20:07 --- I keep bumping into this issue and i'd really appreciate a clue about how to workaround for the time being. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34774
[Bug regression/34801] New: FAIL: gcc.dg/Warray-bounds.c
This should have already been reported, but I cannot find any trace of it. gcc.dg/Warray-bounds.c fails on all the platforms I have looked at: FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 59) FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 65) FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 66) where the wernings are missing for the above lines. This can be traced to revision 131502: PR middle-end/32135 * tree-ssa-ccp.c (maybe_fold_offset_to_array_ref): Do not construct references above array bounds. This might trigger bounds checks for pointers to arrays. -- Summary: FAIL: gcc.dg/Warray-bounds.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression 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=34801
[Bug rtl-optimization/25609] too agressive printf optimization
--- Comment #18 from manu at gcc dot gnu dot org 2008-01-15 20:48 --- There is an explanation for the optimisation, a potential fix [*] and there is a workaround. [*] http://sourceware.org/bugzilla/show_bug.cgi?id=5618 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
[Bug fortran/34784] implicit character(s) hides type of selected_int_kind intrinsic
--- Comment #1 from dick dot hendrickson at gmail dot com 2008-01-15 20:49 --- Another example in executable code MODULE s_TESTS IMPLICIT CHARACTER (P) CONTAINS subroutine simple (u,j1) optional :: j1 if (present (j1)) stop end subroutine END MODULE s_TESTS -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34784
[Bug c++/34399] [4.3 regression] ICE on invalid friend declaration of variadic template
--- Comment #6 from dgregor at gcc dot gnu dot org 2008-01-15 20:57 --- Subject: Bug 34399 Author: dgregor Date: Tue Jan 15 20:56:55 2008 New Revision: 131552 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131552 Log: 2008-01-15 Douglas Gregor [EMAIL PROTECTED] PR c++/34399 * friend.c (do_friend): Don't query TYPE_BEING_DEFINED unless we know we have a class type. 2008-01-15 Douglas Gregor [EMAIL PROTECTED] PR c++/34399 * g++.dg/cpp0x/vt-34399.C: New. * g++.dg/template/friend50.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/vt-34399.C trunk/gcc/testsuite/g++.dg/template/friend50.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/friend.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34399
[Bug c++/34399] [4.3 regression] ICE on invalid friend declaration of variadic template
--- Comment #7 from dgregor at gcc dot gnu dot org 2008-01-15 20:59 --- Fixed in mainline -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34399
[Bug rtl-optimization/25609] too agressive printf optimization
--- Comment #19 from gustavodn at gmail dot com 2008-01-15 21:08 --- (In reply to comment #17) This will be fixed yesterday if printf(%s\n, s) were equivalent to puts(s) in glibc. [+] The standard requires them to be equivalent? Per standard, they can't be equivalent if both are undefined when NULL is passed, right? Also there is a way to disable the optimization: -fno-builtin-printf. People that don't rely on undefined behaviour don't deserve to be punished with suboptimal code. It is not undefined, per glibc. GCC is defining undefined behavior, just as much as glibc, to optimize, that should be documented or fixed. (In reply to comment #18) There is an explanation for the optimisation, a potential fix [*] and there is a workaround. [*] http://sourceware.org/bugzilla/show_bug.cgi?id=5618 [+] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
[Bug fortran/34802] New: Unknown symbol name should be included in Error message
gcc-3.x gives this information but gcc-4.2 does not. In the shell snippit below, the unknown symbol name should be embedded in the gcc-4.2 error lines as it is done in gcc-3.4. $ gcc-3.4 foo.f undeclared_variable(index)=0.0 ^ Invalid declaration of ... 'undeclared_variable' at (^) ... $ gcc-4.2 foo.f undeclared_variable(index)=0.0 1 Error: Unexpected STATEMENT FUNCTION statement at (1) another_variable(1)=0.0 1 Error: Unclassifiable statement at (1) -- Summary: Unknown symbol name should be included in Error message Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: harry dot rockefeller at gmail dot com GCC host triplet: 2.6.22-14-generic kernel GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34802
[Bug libfortran/34671] any(kind=1) and all(kind=1)
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-01-15 21:22 --- Subject: Bug 34671 Author: tkoenig Date: Tue Jan 15 21:22:07 2008 New Revision: 131553 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131553 Log: 2008-01-15 Thomas Koenig [EMAIL PROTECTED] PR libfortran/34671 * gfortran.am: Added _gfortran_all_l1, _gfortran_all_l2, _gfortran_any_l1, _gfortran_any_l2, -28,15 _gfortran_count_1_l, _gfortran_count_16_l, _gfortran_count_2_l, _gfortran_count_4_l and _gfortran_count_8_l Removed _gfortran_count_16_l16, _gfortran_count_16_l4, _gfortran_count_16_l8, _gfortran_count_4_l16, _gfortran_count_4_l4, _gfortran_count_4_l8, _gfortran_count_8_l16, _gfortran_count_8_l4 and _gfortran_count_8_l8. * Makefile.am: Added generated/any_l1.c and generated/any_l2.c to i_any_c. Added generated/all_l1. and generated/all_l2.c to i_all_c. Removed generated/count_4_l4.c, generated/count_8_l4.c, generated/count_16_l4.c, generated/count_4_l8.c, generated/count_8_l8.c, generated/count_16_l8.c, generated/count_4_l16.c, generated/count_8_l16.c, and generated/count_16_l16.c from i_count_c. Added count_1_l.c, count_2_l.c, count_4_l.c, count_8_l.c and count_16_l.c to i_count_c. I_M4_DEPS2 depends on ifunction_logical.m4, for any of the files generated from all.m4, any.m4 and count.m4. * Makefile.in: Regenerated. * m4/ifunction_logical.m4: New file. Use GFC_LOGICAL_1 pointer for access to source arrays. * m4/any.m4: Include ifunction_logical.m4 instead of ifunction.m4. Don't check atype_name. * m4/all.m4: Likewise. * m4/count.m4: Likewise. * generated/any_l1.c: New file. * generated/any_l2.c: New file. * generated/all_l1.c: New file. * generated/count_1_l.c: New file. * generated/count_2_l.c: New file. * generated/count_4_l.c: New file. * generated/count_8_l.c: New file. * generated/count_16_l.c: New file. * generated/any_l4.c: Regenerated. * generated/any_l8.c: Regenerated. * generated/any_l16.c: Regenerated. * generated/all_l4.c: Regenerated. * generated/all_l8.c: Regenerated. * generated/all_l16.c: Regenerated. * generated/count_4_l4.c: Removed. * generated/count_4_l8.c: Removed. * generated/count_4_l16.c: Removed. * generated/count_8_l4.c: Removed. * generated/count_8_l8.c: Removed. * generated/count_8_l16.c: Removed. * generated/count_16_l4.c: Removed. * generated/count_16_l8.c: Removed. * generated/count_16_l16.c: Removed. 2008-01-15 Thomas Koenig [EMAIL PROTECTED] PR libfortran/34671 * iresolve.c (gfc_resolve_all): Call resolve_mask_arg. (gfc_resolve_any): Likewise. (gfc_resolve_count): Likewise. Don't append kind of argument to function name. 2008-01-15 Thomas Koenig [EMAIL PROTECTED] PR libfortran/34671 * gfortran.dg/anyallcount_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/anyallcount_1.f90 trunk/libgfortran/generated/all_l1.c trunk/libgfortran/generated/all_l2.c trunk/libgfortran/generated/any_l1.c trunk/libgfortran/generated/any_l2.c trunk/libgfortran/generated/count_16_l.c trunk/libgfortran/generated/count_1_l.c trunk/libgfortran/generated/count_2_l.c trunk/libgfortran/generated/count_4_l.c trunk/libgfortran/generated/count_8_l.c trunk/libgfortran/m4/ifunction_logical.m4 Removed: trunk/libgfortran/generated/count_16_l16.c trunk/libgfortran/generated/count_16_l4.c trunk/libgfortran/generated/count_16_l8.c trunk/libgfortran/generated/count_4_l16.c trunk/libgfortran/generated/count_4_l4.c trunk/libgfortran/generated/count_4_l8.c trunk/libgfortran/generated/count_8_l16.c trunk/libgfortran/generated/count_8_l4.c trunk/libgfortran/generated/count_8_l8.c Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/iresolve.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in trunk/libgfortran/generated/all_l16.c trunk/libgfortran/generated/all_l4.c trunk/libgfortran/generated/all_l8.c trunk/libgfortran/generated/any_l16.c trunk/libgfortran/generated/any_l4.c trunk/libgfortran/generated/any_l8.c trunk/libgfortran/gfortran.map trunk/libgfortran/m4/all.m4 trunk/libgfortran/m4/any.m4 trunk/libgfortran/m4/count.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34671
[Bug libfortran/34671] any(kind=1) and all(kind=1)
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-01-15 21:24 --- Fixed on trunk. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34671
[Bug c/34803] New: wrong code for dereferencing type-punned pointer
No simpler C code is (yet) known to hit this. On request will describe actual package where similar code occurs. In the attached preprocessed code, incorrect arg 3, `%rdx', is passed to `handle_out_external'. Code expects this value, `extlen', to be the same as value that is returned from `__builtin_alloca', stored in `c', passed to `memcpy' as arg 1. It is not. Instead, the following assembler code is output. movq%rbx, %rdi callmemcpy movq-72(%rbp), %rcx movq-40(%rbp), %rdx movq%rbx, -40(%rbp) It passes in `%rbx' uninitialized value that was in `-40(%rbp)' and only then writes into `-40(%rbp)' the correct value to pass. Observing when compiling not only `-O3', but even `-fno-strict-aliasing -O3 -fno-strict-aliasing'. In these 2 invocations assembler output is the same. That is, `-fno-strict-aliasing' no longer disables optimizations that require strict aliasing rules in code. It, however, disables warnings output when `-Wstrict-aliasing=2' is specified. -- Summary: wrong code for dereferencing type-punned pointer Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gin at mo dot msk dot ru 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=34803
[Bug c/34803] wrong code for dereferencing type-punned pointer
--- Comment #1 from gin at mo dot msk dot ru 2008-01-15 21:41 --- Created an attachment (id=14944) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14944action=view) preprocessed code in question Instead of `extptr', uninitialized value is passed to `handle_out_external'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34803
[Bug fortran/34804] New: Porting aid: flag to disable BYTE, INTEGER*1 and INTEGER(KIND=1)
I am currently having fun porting code to the NEC SX-6 vector processor. The native compiler on that platform (as well as NEC's cross compiler) does not support INTEGER*1. It would be useful to have a flag to mimic this behavior by disabling the above mentioned types for declarations, along with the corresponding adjustments to selected_int_kind () at compile time, so that e.g. selected_int_kind (2) == 2 instead of 1. -- Summary: Porting aid: flag to disable BYTE, INTEGER*1 and INTEGER(KIND=1) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34804
