[Bug fortran/39178] Generate main() rather than using a main in libgfortran/fmain.c
--- Comment #3 from burnus at gcc dot gnu dot org 2009-05-20 06:01 --- Patch: http://gcc.gnu.org/ml/fortran/2009-05/msg00310.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39178
[Bug fortran/40070] Some math expressions containing exponents fail on a Windows 64 build
--- Comment #12 from jb at gcc dot gnu dot org 2009-05-20 08:37 --- Both the mixed C/Fortran and the pure Fortran version by Dominique works as expected for me on x86_64-linux. I.e. I get the same results as reported by Dominique in comments #1 and #6. This looks like a target bug. -- jb at gcc dot gnu dot org changed: What|Removed |Added CC||jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40070
[Bug fortran/40070] Some math expressions containing exponents fail on a Windows 64 build
--- Comment #13 from dominiq at lps dot ens dot fr 2009-05-20 08:55 --- This looks like a target bug. This looks also like a problem with the way arguments and results are handled (this is why I have suggested an alignement problem in comment #9). The result in comment #2: Function 3: result 1: -4171845731254704300. result 2: 142007.828125 seems also to point in this direction. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40070
[Bug middle-end/40204] [4.3/4.4/4.5 Regression] segfault with bitfields in structs
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-20 09:20 --- Confirmed. We endlessly recurse in folding #2 0x0076b333 in fold_binary (code=BIT_AND_EXPR, type=0x75f5f540, op0=0x77ff9580, op1=0x75f76870) at /space/rguenther/src/svn/trunk/gcc/fold-const.c:11388 11388 return fold_build2 (BIT_AND_EXPR, type, tem, (gdb) l 11383TREE_OPERAND (arg0, 1)); 11384 tem = fold_convert (type, tem); 11385 } 11386 else 11387 tem = op0; 11388 return fold_build2 (BIT_AND_EXPR, type, tem, 11389 build_int_cst_type (TREE_TYPE (op1), 11390 newmask)); 11391 } 11392 } (gdb) call debug_generic_expr (op0) (unnamed-unsigned:4) ((unsigned char) c 4) (gdb) call debug_generic_expr (op1) 15 (gdb) call debug_generic_expr (tem) (unnamed-unsigned:4) ((unsigned char) c 4) (gdb) p newmask $1 = 255 and 255 is truncated to 15 again. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.3.3 4.4.0 Known to work||4.2.4 Last reconfirmed|-00-00 00:00:00 |2009-05-20 09:20:22 date|| Summary|segfault with bitfields in |[4.3/4.4/4.5 Regression] |structs |segfault with bitfields in ||structs Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40204
[Bug tree-optimization/40087] [4.3/4.4 Regression] Number of iterations analysis wrong
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-05-20 09:21 --- Fixed on trunk sofar. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.0.4 |4.0.4 4.5.0 Summary|[4.3/4.4/4.5 Regression]|[4.3/4.4 Regression] Number |Number of iterations|of iterations analysis wrong |analysis wrong | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40087
[Bug fortran/40205] New: OpenMP do loop with MAXINT gives wrong trip count
When the largest integer is used as the upper bound of a for loop which is parallelised using OpenMP, thread n-1 will execute at most one iteration. The code below demonstrates this by printing at most one message. This is shown most clearly by first setting the OMP_NUM_THREADS environment variable to 1. We would then expect ten I get printed once or less. messages, but we get only one. (With OMP_NUM_THREADS set to 2, we would again expect ten, but only get six messages). The OpenMP runtime library is used in this example only to make explicit that the error relates to the last thread of the team. ( i.e. use omp_lib allows us to call omp_get_thread_num() and omp_get_num_threads() ) I tried using the -fdump-tree-original switch, and it occurs to me that the use of = in the generated loops may play a part in this. ( OpenMP for loop tests are permitted only to use ,=, or = ) The example code follows, and is compiled with gfortran -Wall -save-temps -fopenmp ompbug3.f95 gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12) x86_64-linux-gnu Ubuntu 8.10 program main use omp_lib integer(kind=4) :: i, lower, upper upper = huge(maxint) lower = upper - 9! The 9 can of course be changed !$omp parallel do do i = lower, upper if (omp_get_thread_num() == (omp_get_num_threads() - 1)) then print *, I get printed once or less. end if end do !$end omp parallel do end program -- Summary: OpenMP do loop with MAXINT gives wrong trip count Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pkeir at dcs dot gla dot ac dot uk 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=40205
[Bug middle-end/40205] OpenMP do loop with MAXINT gives wrong trip count
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-20 11:28 --- Confirmed. extract_omp_for_data canonicalizes = and = to and by adding/subtracting one to/from the bound. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|fortran |middle-end Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2009-05-20 11:28:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40205
[Bug fortran/40206] New: [gfortran] Incorrect warning with -Wuninitialized
gfortran from the current trunk gives a warning for the code below:
module fitsmod2
implicit none
contains
function char2type (char)
character, intent(in) :: char
integer :: char2type
select case (char)
case ('E','e')
char2type=1
case default
char2type=-1234
end select
end function
function fixkey (input)
character(len=*), intent(in) :: input
character(len=1024) fixkey
fixkey=input
end function
end module fitsmod2
/scratch/blah5/planck/LevelS/bugrepgfortran -v -Wuninitialized -c -O
fitsmod2.f90
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /scratch/martin/gcc/configure
--prefix=/afs/mpa/data/martin/ugcc --with-mpfr-include=/usr/include
--with-mpfr-lib=/usr/lib --with-gmp-include=/usr/include
--with-gmp-lib=/usr/lib --enable-languages=c++,fortran
--enable-checking=release
Thread model: posix
gcc version 4.5.0 20090520 (experimental) [trunk revision 147731] (GCC)
COLLECT_GCC_OPTIONS='-v' '-Wuninitialized' '-c' '-O' '-mtune=generic'
/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.5.0/f951
fitsmod2.f90 -quiet -dumpbase fitsmod2.f90 -mtune=generic -auxbase fitsmod2 -O
-Wuninitialized -version -fintrinsic-modules-path
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.5.0/finclude -o
/tmp/ccPgtd3C.s
GNU Fortran (GCC) version 4.5.0 20090520 (experimental) [trunk revision 147731]
(i686-pc-linux-gnu)
compiled by GNU C version 4.5.0 20090520 (experimental) [trunk revision
147731], GMP version 4.2.1, MPFR version 2.3.2
warning: GMP header version 4.2.1 differs from library version 4.2.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran (GCC) version 4.5.0 20090520 (experimental) [trunk revision 147731]
(i686-pc-linux-gnu)
compiled by GNU C version 4.5.0 20090520 (experimental) [trunk revision
147731], GMP version 4.2.1, MPFR version 2.3.2
warning: GMP header version 4.2.1 differs from library version 4.2.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
fitsmod2.f90: In function 'char2type':
fitsmod2.f90:23: warning: '__result_char2type' may be used uninitialized in
this function
fitsmod2.f90:23: note: '__result_char2type' was declared here
COLLECT_GCC_OPTIONS='-v' '-Wuninitialized' '-c' '-O' '-mtune=generic'
as -V -Qy -o fitsmod2.o /tmp/ccPgtd3C.s
GNU assembler version 2.18 (i686-pc-linux-gnu) using BFD version (GNU Binutils)
2.18
COMPILER_PATH=/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.5.0/:/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.5.0/:/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/:/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.5.0/:/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/
LIBRARY_PATH=/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.5.0/:/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-Wuninitialized' '-c' '-O' '-mtune=generic'
Several things are odd about this warning:
- the line number in question is not inside the function char2type
- the warning is given for a variable that is not defined by the user
- the result of char2type is actually initialised in all code paths
--
Summary: [gfortran] Incorrect warning with -Wuninitialized
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
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=40206
[Bug fortran/40206] [gfortran] Incorrect warning with -Wuninitialized
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-20 12:43 ---
The dump is the following. gfortran_select_string returns only 0, 1, or 2, but
the middle end does not know this.
Manuel, do you have an idea how to solve this?
case_num.1 = _gfortran_select_string ((void *) jumptable.0, 3, char, 1);
switch (case_num.1)
{
case 1 ... 1:;
case 2 ... 2:;
__result_char2type = 1;
goto L.1;
case 0 ... 0:;
__result_char2type = -1234;
goto L.1;
}
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||manu at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build triplet|i686-pc-linux-gnu |
GCC host triplet|i686-pc-linux-gnu |
GCC target triplet|i686-pc-linux-gnu |
Last reconfirmed|-00-00 00:00:00 |2009-05-20 12:43:26
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40206
[Bug fortran/40206] [gfortran] Incorrect warning with -Wuninitialized
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-05-20 12:48 --- I'd suspect this to be a related to Jakub's recent changes applied for PR39666 (i.e. r147136)? Does your testcase work for r147135? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40206
[Bug fortran/40206] [gfortran] Incorrect warning with -Wuninitialized
--- Comment #3 from martin at mpa-garching dot mpg dot de 2009-05-20 13:03 --- (In reply to comment #2) I'd suspect this to be a related to Jakub's recent changes applied for PR39666 (i.e. r147136)? Does your testcase work for r147135? I cannot check this quickly. However I tried with gfortran 4.2.3 and the head of the 4.4 branch and got similar warnings. Surprisingly, these compilers warn about line 22 (instead of 23), which is still wrong... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40206
[Bug middle-end/40028] RFE - Add GPU acceleration library to gcc
--- Comment #3 from rob1weld at aol dot com 2009-05-20 13:10 --- Some of the newest cards will run at over a PetaFLOP ... I meant a TeraFLOP :( . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40028
[Bug fortran/40206] [gfortran] Incorrect warning with -Wuninitialized
--- Comment #4 from manu at gcc dot gnu dot org 2009-05-20 13:12 --- (In reply to comment #2) I'd suspect this to be a related to Jakub's recent changes applied for PR39666 (i.e. r147136)? Does your testcase work for r147135? On the contrary, I think this is a missed testcase from Jakub's changes, because the default label is added during gimplification. Perhaps the patch of Jakub can be extended to handle this, or the fortran FE can add the default label in the correct place. In addition, why gfortran does not name the variable char2type? Can you access that variable when debugging? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40206
[Bug rtl-optimization/36712] Inefficient loop unrolling
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-20 13:19 --- Can be reproduced with trunk today. -- 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-20 13:19:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712
[Bug fortran/40206] [gfortran] Incorrect warning with -Wuninitialized
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-20 13:40 ---
switch (case_num.1)
{
case 1 ... 1:;
case 2 ... 2:;
__result_char2type = 1;
goto L.1;
case 0 ... 0:;
__result_char2type = -1234;
goto L.1;
}
Wouldn't this solved by adding a default: as C does for default: ?
In addition, why gfortran does not name the variable char2type?
Good question. it clashes with the name of the function, but I don't know
whether that is a problem or not. In any case: you are right, it makes
debugging harder ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40206
[Bug rtl-optimization/36712] Inefficient loop unrolling
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-20 14:09 --- I think there is no induction variable optimization on RTL anymore. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712
[Bug fortran/40206] [gfortran] Incorrect warning with -Wuninitialized
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-05-20 14:14 --- The FE should use a default label for the last case in the switch stmt. I also think the FE does premature optimization here, but ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40206
[Bug rtl-optimization/36712] Inefficient loop unrolling
--- Comment #3 from ramana at gcc dot gnu dot org 2009-05-20 14:14 --- There was a discussion thread here. http://gcc.gnu.org/ml/gcc/2008-07/msg00037.html and one of the solutions that Bingfeng was investigating was loop unrolling before ivopts in certain cases being useful . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712
[Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] unoptimal code generated
-- 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-20 14:17:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
[Bug tree-optimization/39839] [4.3/4.4/4.5 regression] loop invariant motion causes stack spill
-- 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-20 14:17:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39839
[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to inferior CSE
-- 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-20 14:17:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871
[Bug rtl-optimization/36712] Inefficient loop unrolling
--- Comment #4 from bmei at broadcom dot com 2009-05-20 14:17 --- I implemented a tree-level loop-unrolling pass in our private porting, which takes advantage of later tree ivopt pass. It produces much better code than rtl-level loop unrolling in such scenarios. Not sure whether should submit for 4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712
[Bug c++/40202] warning about passing non-POD objects through �...� should include name and location of declaration being called
--- Comment #2 from jason dot orendorff at gmail dot com 2009-05-20 14:28 --- No, I'm asking for the extra line: nonpod.cpp:1: calling `void f(...)' declared here -- jason dot orendorff at gmail dot com changed: What|Removed |Added Summary|warning about passing non- |warning about passing non- |POD objects through ... |POD objects through |should include name and |�...� should include |location of declaration |name and location of |being called|declaration being called http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40202
[Bug fortran/40206] [gfortran] Incorrect warning with -Wuninitialized
--- Comment #7 from jakub at gcc dot gnu dot org 2009-05-20 14:32 --- For all involved strings being non-array CHAR with length 1 I fail to see why normal SWITCH_EXPR isn't used instead (though that would just be an optimization). The middle-end can't know the _gfortran_select_string function will never return numbers bigger than the size of the jump table it is called with, so the Fortran FE should help it. If the table contains a default label, it should use a default: case label instead of corresponding number, and if there is no case label, but all possible strings are covered, it can pick a random case label as the default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40206
[Bug c++/40202] warning about passing non-POD objects through �...� should include name and location of declaration being called
--- Comment #3 from jason dot orendorff at gmail dot com 2009-05-20 14:33 --- I should clarify that in the real-world case, the apparently relevant declaration doesn't use ... at all, hence the tentative diagnosis of something weird. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40202
[Bug c++/32142] gcc crashes when creating coverage info and optimization
--- Comment #4 from dominik dot strasser at onespin-solutions dot com 2009-05-20 14:57 --- Works fine in 4.3.3 -- dominik dot strasser at onespin-solutions dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32142
[Bug libstdc++/34730] Legal program doesn't compile with -D_GLIBCXX_DEBUG
--- Comment #11 from dominik dot strasser at onespin-solutions dot com 2009-05-20 14:58 --- Works fine, thanks. -- dominik dot strasser at onespin-solutions dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34730
[Bug c/35526] ICE on memcpy
--- Comment #9 from dominik dot strasser at onespin-solutions dot com 2009-05-20 14:58 --- Works fine -- dominik dot strasser at onespin-solutions dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35526
[Bug libstdc++/35541] [4.3 Regression] Legal C++ program can't be compiled with -D_GLIBCXX_DEBUG
--- Comment #10 from dominik dot strasser at onespin-solutions dot com 2009-05-20 14:59 --- Works fine -- dominik dot strasser at onespin-solutions dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35541
[Bug libstdc++/36333] stable_sort calling merge; problems when _GLIBCXX_DEBUG is switched on
--- Comment #6 from dominik dot strasser at onespin-solutions dot com 2009-05-20 14:59 --- Works fine -- dominik dot strasser at onespin-solutions dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36333
[Bug c++/36334] [4.2 Regression] typedef to function type leads to problems
--- Comment #7 from dominik dot strasser at onespin-solutions dot com 2009-05-20 14:59 --- Works fine in 4.3.3 -- dominik dot strasser at onespin-solutions dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36334
[Bug target/6786] [sparcv9-solaris] throwing expection causes segv with -m64
--- Comment #2 from dominik dot strasser at onespin-solutions dot com 2009-05-20 15:03 --- Work fine -- dominik dot strasser at onespin-solutions dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6786
[Bug c/40207] New: request for enhancement: delay argument loading until needed
While working on some Linux kernel code, I've found that functions that
are declared as 'static inline' are having their arguments evaluated
well before they are used. For example I have a function:
static inline void trace(arg1, arg2)
{
if (unlikely(enabled)) {
use the arguments
}
}
To make this more concrete here is a simple .c program:
#include stdio.h
# define unlikely(x)__builtin_expect(!!(x), 0)
int enabled = 0;
struct foo {
int value;
};
struct foo a = {
.value = 10
};
static inline evaluate(int value) {
if (unlikely(enabled)) {
printf(value is: %d\n, value);
}
}
/*
#define evaluate(val) \
do { \
if (unlikely(enabled)) { \
printf(value is: %d\n, val); \
} \
} while (0)
*/
int main() {
evaluate((a)-value);
}
With the macro commented out I get:
004004cc main:
4004cc: 55 push %rbp
4004cd: 48 89 e5mov%rsp,%rbp
4004d0: 48 83 ec 10 sub$0x10,%rsp
4004d4: 8b 3d 22 04 20 00 mov0x200422(%rip),%edi#
6008fc a
4004da: e8 02 00 00 00 callq 4004e1 evaluate
Thus, a is loaded before the call to 'evaluate'
However, if i compile the macro version of 'evaluate' i get:
004004cc main:
4004cc: 55 push %rbp
4004cd: 48 89 e5mov%rsp,%rbp
4004d0: 48 83 ec 10 sub$0x10,%rsp
4004d4: 8b 05 ee 03 20 00 mov0x2003ee(%rip),%eax#
6008c8 enabled
4004da: 85 c0 test %eax,%eax
4004dc: 0f 95 c0setne %al
4004df: 0f b6 c0movzbl %al,%eax
4004e2: 48 85 c0test %rax,%rax
4004e5: 74 15 je 4004fc main+0x30
4004e7: 8b 35 c7 03 20 00 mov0x2003c7(%rip),%esi#
6008b4 a
4004ed: bf f8 05 40 00 mov$0x4005f8,%edi
4004f2: b8 00 00 00 00 mov$0x0,%eax
4004f7: e8 bc fe ff ff callq 4003b8 pri...@plt
Thus, the load of 'a' happens after the 'unlikely' test as I would like it. It
would be nice if gcc could optimize the 'unlikely' case in the 'static inline'
function case.
thanks.
--
Summary: request for enhancement: delay argument loading until
needed
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jbaron at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40207
[Bug middle-end/38486] Missing warning about type punning
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-05-20 15:15 --- Note that I am going to fix the missing warning because of comment #2 only. For 4.3 comment #2 does not apply, instead you get a warning with -Wstrict-aliasing=1 g++-4.3 -Wall -O3 -S t.C -UWARN -fdump-tree-all -Wstrict-aliasing=1 t.C: In function Term term(const Func): t.C:13: warning: dereferencing type-punned pointer might break strict-aliasing rules t.C: In function const Func func(const Term): t.C:23: warning: dereferencing type-punned pointer might break strict-aliasing rules -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38486
[Bug middle-end/40208] Redundant (dead) virtual-stack-vars stores related to tree-loop-im
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-20 15:59 --- This works on the trunk and there is no ADDRESSABLE set on the tmp_union. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40208
[Bug c++/32142] gcc crashes when creating coverage info and optimization
--- Comment #5 from dominik dot strasser at onespin-solutions dot com 2009-05-20 15:45 --- Works fine in 4.3 -- dominik dot strasser at onespin-solutions dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32142
[Bug rtl-optimization/36712] Inefficient loop unrolling
--- Comment #5 from dje dot gcc at gmail dot com 2009-05-20 17:51 --- Subject: Re: Inefficient loop unrolling I implemented a tree-level loop-unrolling pass in our private porting, which takes advantage of later tree ivopt pass. It produces much better code than rtl-level loop unrolling in such scenarios. Not sure whether should submit for 4.5. Why not sure? The worst anyone can say is no. Of course you should submit it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712
[Bug tree-optimization/38747] [4.4 Regression] Wrong code due to VIEW_CONVERT_EXPR
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-05-20 15:26 ---
On a second thought this transformation is even wrong for non-indirect
references.
extern C void abort (void);
inline void *operator new (__SIZE_TYPE__, void *__p) throw () { return __p; }
int __attribute__((noinline))
foo(void)
{
float f = 0;
int *i = new (f) int (1);
return *(int *)f;
}
int main()
{
if (foo() != 1)
abort ();
return 0;
}
it is wrong to turn the float read into an int read converted via a
VIEW_CONVERT_EXPR.
I will remove all this VIEW_CONVERT_EXPR generation again.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38747
[Bug rtl-optimization/40209] New: ICE in iv opts caused by stale REG_UNUSED note
An ICE occurs in iv_analyze_def because the register referred to by a def is not the same register referred to by the set in an rtx. The rtx in question actually has multiple set's, but single_set only returns one of them because of a stale REG_UNUSED note. The stale REG_UNUSED note is created in gcse. At the beginning of gcse, the REG_UNUSED note is added (and is correct). At the end of gcse, if expensive optimizations are on, it will make a call to cse_main which will merge two defs with the same expression. This makes the REG_UNUSED note stale, however it is not removed from the operation. Later in iv_analyze_def, the call to single_set trips over this stale REG_UNUSED note. I have verified that the problem is resolved if df_analyze (with the notes problem added) corrects the stale note and avoids the problem. However discussions with Ian suggest that this might not be the correct approach to fixing the problem, so I'm filing this bug. I've attached a test case which will cause the ICE if compiled with the following command line: gcc -c -O2 -fprofile-use test.c Note that no .gcda file is necessary. -- Summary: ICE in iv opts caused by stale REG_UNUSED note Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nvachhar at google dot com GCC host triplet: i686-unknown-linux GCC target triplet: x86_64-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40209
[Bug tree-optimization/40210] New: gcc needs byte swap builtins
gcc needs some built in functions for byte swapping.
I've been experimenting with the various versions of byte swapping functions
out there, and they either result in code that's opaque to the optimizer (i.e.
swapping something twice is not considered a null operation) or the optimizer
doesn't recognize that a byte swap is what's happening and renders it as a
complex series of shift, and and or instructions.
I know very little about the internals of gcc, but my ignorant preference would
be to make tree-ssa recognize that code like this:
inline uint64_t byteswap_64(const uint64_t x)
{
return
x) 0xff00ull) 56)
| (((x) 0x00ffull) 40)
| (((x) 0xff00ull) 24)
| (((x) 0x00ffull) 8)
| (((x) 0xff00ull) 8)
| (((x) 0x00ffull) 24)
| (((x) 0xff00ull) 40)
| (((x) 0x00ffull) 56));
}
is a byte swap and optimize appropriately. If this were being done to an
entire array, it might even be possible to vectorize it efficiently.
This would also mean that code to pull specific bits out of a pre or post swap
value could be moved around and fiddled to get the value out of a different
place if it made for more efficient register usage.
--
Summary: gcc needs byte swap builtins
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric-bugs at omnifarious dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40210
[Bug rtl-optimization/40209] ICE in iv opts caused by stale REG_UNUSED note
--- Comment #1 from nvachhar at google dot com 2009-05-20 18:48 --- Created an attachment (id=17896) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17896action=view) Test case that causes an ICE Compile with: gcc -c -O2 -Wall -fprofile-use test.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40209
[Bug middle-end/40204] [4.3/4.4/4.5 Regression] segfault with bitfields in structs
--- Comment #3 from jakub at gcc dot gnu dot org 2009-05-20 16:11 --- As I've caused this by PR29749, I'm taking this up. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-05-20 09:20:22 |2009-05-20 16:11:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40204
[Bug tree-optimization/40210] gcc needs byte swap builtins
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-20 19:01 --- http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Other-Builtins.html#Other-Builtins Built-in Function: int32_t __builtin_bswap32 (int32_t x) Returns x with the order of the bytes reversed; for example, 0xaabbccdd becomes 0xddccbbaa. Byte here always means exactly 8 bits. Built-in Function: int64_t __builtin_bswap64 (int64_t x) Similar to __builtin_bswap32, except the argument and return types are 64-bit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40210
[Bug tree-optimization/40210] gcc needs byte swap builtins
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-20 19:03 --- Also see http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00421.html . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40210
[Bug tree-optimization/40210] gcc needs byte swap builtins
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-05-20 19:04 --- So there are builtins in 4.3.0 and above. And there is a patch floating around to automatically change the manually written byte swap into the builtins. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40210
[Bug libstdc++/21244] [4.0/4.1 Regression] Vectorbool anonymous enum problem
--- Comment #19 from dominik dot strasser at onespin-solutions dot com 2009-05-20 15:45 --- Works fine -- dominik dot strasser at onespin-solutions dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21244
[Bug middle-end/40207] request for enhancement: delay argument loading until needed
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-20 15:21 ---
The define and the static inline functions are not equivalent at all.
#define evaluate(val) \
do { \
typeof(val) tmpval = val; \
if (unlikely(enabled)) { \
printf(value is: %d\n, tmpval); \
} \
} while (0)
makes the define equivalent to the static inline funciton.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Component|c |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40207
Re: 64 bit linux build problem for gcc 4.4.0
Jerry, Thanks for the reply. Do you have the stuff necessary for doing 32-bit builds installed also? I do, and it feels like that might be the issue. I can send you logs if you really want to see the gory details. Thanks, Arnold Date: Tue, 19 May 2009 17:05:29 -0700 From: Jerry DeLisle jvdeli...@verizon.net To: Aharon Robbins arn...@skeeve.com Cc: bug-...@gnu.org Subject: Re: 64 bit linux build problem for gcc 4.4.0 Aharon Robbins wrote: Hi. After several tries and a modicum of googling, I found that CFLAGS=-m64 ../gcc-4.4.0/configure --disable-multilib was the magic incantation to get gcc to get into the second stage of the boostrap. This is on a Fedora Core 10 system. This seems to be an old issue; google turns things up dating back to 2003. I suspect that x86_64 systems are only going to be more popular with time; the build process on those systems needs to be as easy as for 32 bit systems. Thanks, Arnold Robbins (the gawk guy :-) Aharon, I have been building gcc for several years now with no issues on x86-64 and on Fedora Core 10 ever since it was released. What exactly has been your problem? Its been as easy as 123. I have never had to set CCFLAGS or disable-multilib. Jerry
[Bug c/40208] New: Redundant (dead) virtual-stack-vars stores related to tree-loop-im
The following code:
long long foo (long long);
void
FIR(short In[],short Out[],int nsamples)
{
long long * vIn = (long long*)In;
long long * vOut = (long long*)Out;
int i;
long long sum0, sum1;
for (i = 0; i nsamples; i++) {
sum0 = vIn[i];
vOut[i+1] = foo(
({union {long long d; int w[2];} tmp_union;
tmp_union.w[0] = ( ({ union {long long d; int w[2];} tmp_union;
tmp_union.d = (sum0);
tmp_union.w[0]; }));
tmp_union.w[1] = ( ({ union {long long d; int w[2];} tmp_union;
tmp_union.d = (sum1);
tmp_union.w[0]; }));
tmp_union.d; })
);
}
}
Compiled with:
gcc -O2 -S ttt.c
gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-threads=posix
--prefix=/prj/x86_gcc_4.4/bin --enable-languages=c,c++ --disable-checking
Thread model: posix
gcc version 4.4.0 (GCC)
produces redundant (dead) stores to local stack location. The problem goes away
with tree loop invariant code motion disabled (-fno-tree-loop-im flag).
It also works fine with gcc 4.3.2 -O2
I could track it down to the point of TREE_ADDRESSABLE flag (improperly) set to
tmp_union declaration tree during tree-loop-im:
#0 build_fold_addr_expr_with_type_1 (t=0x2b88d7d5b780, ptrtype=0x2b88d7d62e40,
in_fold=0 '\0') at fold-const.c:7945
#1 0x00a1201d in get_inner_reference_aff (ref=value optimized out,
addr=0x7fffd31e6330, size=0x7fffd31e6430) at tree-affine.c:844
#2 0x007eab9d in ref_indep_loop_p (loop=0x2b88d7c0cea0, ref=0xdea300)
at tree-ssa-loop-im.c:1643
#3 0x007eb7f7 in determine_max_movement (stmt=0x2b88d7c01850,
must_preserve_exec=value optimized out) at tree-ssa-loop-im.c:589
#4 0x007efce0 in determine_invariantness_stmt (dw_data=value
optimized out, bb=value optimized out) at tree-ssa-loop-im.c:971
#5 0x009c8546 in walk_dominator_tree (walk_data=0x7fffd31e6770,
bb=0x2b88d7d5e720) at domwalk.c:196
#6 0x007ea458 in determine_invariantness () at tree-ssa-loop-im.c:1005
#7 0x007ef0c0 in tree_ssa_lim () at tree-ssa-loop-im.c:2299
#8 0x0080d4e5 in tree_ssa_loop_im () at tree-ssa-loop.c:110
#9 0x00687a79 in execute_one_pass (pass=0xcae480) at passes.c:1277
#10 0x00687c7c in execute_pass_list (pass=0xcae480) at passes.c:1326
#11 0x00687c95 in execute_pass_list (pass=0xcae540) at passes.c:1327
#12 0x00687c95 in execute_pass_list (pass=0xcad5e0) at passes.c:1327
#13 0x0077acfd in tree_rest_of_compilation (fndecl=0x2b88d7d41a00) at
tree-optimize.c:420
#14 0x008ffb15 in cgraph_expand_function (node=0x2b88d7d41b00) at
cgraphunit.c:1047
#15 0x0090182a in cgraph_optimize () at cgraphunit.c:1106
#16 0x00416a1f in c_write_global_declarations () at c-decl.c:8102
#17 0x00723b46 in toplev_main (argc=value optimized out, argv=0x0) at
toplev.c:981
When present, it causes severe performance degradation.
--
Summary: Redundant (dead) virtual-stack-vars stores related to
tree-loop-im
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sergei_lus at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40208
[Bug tree-optimization/40210] gcc needs byte swap builtins
--- Comment #4 from eric-bugs at omnifarious dot org 2009-05-20 19:17 --- Ahh, OK. I hunted a bit to find something like that, but didn't find it. Thank you. I now have a slightly different bug, which is a mild inadequate optimization bug. :-) I'll cut it down to size and paste it in here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40210
[Bug middle-end/40207] request for enhancement: delay argument loading until needed
--- Comment #2 from fche at redhat dot com 2009-05-20 16:56 --- (In reply to comment #1) The define and the static inline functions are not equivalent at all. Right, in general, but if the expressions are side-effect-free, gcc could move their evaluation farther down. -- fche at redhat dot com changed: What|Removed |Added CC||fche at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40207
[Bug tree-optimization/38747] [4.4 Regression] Wrong code due to VIEW_CONVERT_EXPR
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-05-20 15:26 --- Mine. -- 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 Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38747
[Bug middle-end/40208] Redundant (dead) virtual-stack-vars stores related to tree-loop-im
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-20 19:22 --- Fixed by alias-improvements branch merge. Or rather http://gcc.gnu.org/viewcvs?root=gccview=revrev=145142 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40208
[Bug tree-optimization/40210] gcc byte swap builtins inadequately optimized
--- Comment #5 from eric-bugs at omnifarious dot org 2009-05-20 19:39
---
This code:
#include stdint.h
#include stddef.h
inline uint64_t byteswap_64(const uint64_t x)
{
return __builtin_bswap64(x);
}
inline uint32_t byteswap_32(const uint32_t x)
{
return __builtin_bswap32(x);
}
extern void random_function(uint32_t a, uint64_t b, uint32_t c, uint64_t d);
void swapping(const uint32_t x32, const uint64_t x64)
{
random_function(byteswap_32(x32), byteswap_64(x64),
byteswap_32(byteswap_32(x32)), byteswap_64(byteswap_64(x64)));
}
void swaparray(uint64_t outvals[], char outtop[], const uint64_t invals[],
const size_t size)
{
size_t i = 0;
for (i = 0; i size; ++i) {
outvals[i] = byteswap_64(invals[i]);
outtop[i] = (byteswap_64(invals[i]) 56) 0xffull;
}
}
results in this assembly:
.globl swaparray
.type swaparray, @function
swaparray:
.LFB5:
testq %rcx, %rcx
je .L8
xorl%r8d, %r8d
.p2align 4,,7
.p2align 3
.L7:
movq(%rdx,%r8,8), %rax
bswap %rax
movq%rax, (%rdi,%r8,8)
movq(%rdx,%r8,8), %rax
bswap %rax
shrq$56, %rax
movb%al, (%rsi,%r8)
incq%r8
cmpq%r8, %rcx
ja .L7
.L8:
rep
ret
.LFE5:
.size swaparray, .-swaparray
.p2align 4,,15
.globl swapping
.type swapping, @function
swapping:
.LFB4:
bswap %rsi
bswap %edi
movq%rsi, %rcx
movl%edi, %edx
bswap %rcx
bswap %edx
jmp random_function
.LFE4:
.size swapping, .-swapping
when compiled with gcc -O3 -mtune=native -march=native on an Opteron system.
Notice that in swapping bswap is used twice rather than having two move
instructions and two bswap instructions. The optimizer is apparently unaware
that bswap is its own inverse.
In swaparray the bswap operation is not subject to an obvious CSE optimization,
nor is it realized that the latter line might be more efficiently implemented
by movb %al, (%rsi,%r8) before the bswap operation.
--
eric-bugs at omnifarious dot org changed:
What|Removed |Added
Summary|gcc needs byte swap builtins|gcc byte swap builtins
||inadequately optimized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40210
[Bug tree-optimization/40210] gcc byte swap builtins inadequately optimized
--- Comment #6 from jakub at gcc dot gnu dot org 2009-05-20 20:05 ---
There are plenty other possible builtin bswap optimizations. E.g.
extern void bar (void);
void foo (int x)
{
if (__builtin_bswap32 (x) == __builtin_bswap32 (0x1234567))
bar ();
}
should be optimized into if (x == 0x1234567) (only for EQ_EXPR/NE_EXPR),
similarly __builtin_bswap32 (x) == 0x1234567 should be optimized into
x == __builtin_bswap32 (0x1234567) because the latter can be swapped at compile
time, similarly __builtin_bswap32 (__builtin_bswap32 (x) | 0x1234) could
be optimized into x | __builtin_bswap32 (0x1234) (similarly for ^ or or ~),
etc. The question is if enough projects start using these builtins to make it
worth spending compile time on it and what exact optimizations are useful on
real-world code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40210
[Bug tree-optimization/40210] gcc byte swap builtins inadequately optimized
--- Comment #7 from eric-bugs at omnifarious dot org 2009-05-20 20:22 --- I've been playing around a bit more, and I've noticed that gcc in general does not do a spectacular job of optimizing bitwise operations of any kind. Some kind of general framework for tracking the movements of individual bits and details like 16 bit values only have 16 bits, so using to ensure this in various ways is a null operation. might actually do a lot to speed up a lot of code. I distinctly remember a time long past when I and a co-worker fiddled some complex bit operations this way and that to get the assembly out we knew was close to optimal for a tight inner loop. The resulting expression was significantly less clear than the most obvious way of stating the same thing and I also knew that if DEC changed their compiler in certain ways we'd have to do it all over again. As an example, there is no reason that: (x 8) | (x 8) should result in better code than ((x 0xffu) 8) | ((x 0xff00u) 8) when x is of type uint16_t, but it does. And recognizing that either can be done in one instruction on an x86 would be even better. So, while I think you are likely correct that the byteswap builtins do not need a lot of extensive optimization, I do think that bit operations in general could be handled a lot better, and that would help out a whole lot of code. Once that framework was in place optimizing the byteswap builtin would be trivial. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40210
[Bug libgomp/40174] Memory leak when using '#pragma omp parallel'
--- Comment #3 from jakub at gcc dot gnu dot org 2009-05-20 20:55 --- Subject: Bug 40174 Author: jakub Date: Wed May 20 20:54:45 2009 New Revision: 147747 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147747 Log: PR libgomp/40174 * team.c (gomp_thread_start): Destroy thr-release semaphore. (gomp_free_pool_helper): Likewise. Modified: trunk/libgomp/ChangeLog trunk/libgomp/team.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40174
[Bug libgomp/40174] Memory leak when using '#pragma omp parallel'
--- Comment #4 from jakub at gcc dot gnu dot org 2009-05-20 20:55 --- Subject: Bug 40174 Author: jakub Date: Wed May 20 20:55:25 2009 New Revision: 147748 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147748 Log: PR libgomp/40174 * team.c (gomp_thread_start): Destroy thr-release semaphore. (gomp_free_pool_helper): Likewise. Modified: branches/gcc-4_4-branch/libgomp/ChangeLog branches/gcc-4_4-branch/libgomp/team.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40174
[Bug middle-end/40204] [4.3/4.4/4.5 Regression] segfault with bitfields in structs
--- Comment #4 from jakub at gcc dot gnu dot org 2009-05-20 21:09 --- Subject: Bug 40204 Author: jakub Date: Wed May 20 21:09:11 2009 New Revision: 147749 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147749 Log: PR middle-end/40204 * fold-const.c (fold_binary) case BIT_AND_EXPR: Avoid infinite recursion if build_int_cst_type returns the same INTEGER_CST as arg1. * gcc.c-torture/compile/pr40204.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr40204.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40204
[Bug middle-end/40204] [4.3/4.4/4.5 Regression] segfault with bitfields in structs
--- Comment #5 from jakub at gcc dot gnu dot org 2009-05-20 21:11 --- Subject: Bug 40204 Author: jakub Date: Wed May 20 21:11:10 2009 New Revision: 147750 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147750 Log: PR middle-end/40204 * fold-const.c (fold_binary) case BIT_AND_EXPR: Avoid infinite recursion if build_int_cst_type returns the same INTEGER_CST as arg1. * gcc.c-torture/compile/pr40204.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40204.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/fold-const.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40204
[Bug libgomp/40174] Memory leak when using '#pragma omp parallel'
--- Comment #5 from jakub at gcc dot gnu dot org 2009-05-20 21:15 --- Fixed for 4.4/4.5. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40174
[Bug middle-end/40204] [4.3 Regression] segfault with bitfields in structs
--- Comment #6 from jakub at gcc dot gnu dot org 2009-05-20 21:15 --- 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] segfault |segfault with bitfields in |with bitfields in structs |structs | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40204
[Bug c++/40139] [4.4/4.5 Regression] ICE on invalid use of destructor
--- Comment #5 from jakub at gcc dot gnu dot org 2009-05-20 21:16 --- Fixed, thanks. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40139
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #57 from dave dot korn dot cygwin at gmail dot com 2009-05-20 21:16 --- Bah. In case anyone else was about to point this out to me, +gcc_GAS_CHECK_FEATURE([.comm with alignment], gcc_cv_as_comm_has_align, + [2,19,52],, + [.comm foo,1,32],, +[AC_DEFINE(HAVE_GAS_ALIGNED_COMM, 1, + [Define if your assembler supports specifying the alignment + of objects allocated using the GAS .comm command.])]) ... that won't work with ... +mpe-aligned-commons +Target Var(use_pe_aligned_common) Init(HAVE_GAS_ALIGNED_COMM) ... that, because it's undefined, not zero, when the feature isn't detected. I'll have to respin it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug middle-end/40208] Redundant (dead) virtual-stack-vars stores related to tree-loop-im
--- Comment #3 from sergei_lus at yahoo dot com 2009-05-20 21:23 --- Yes. This is the problem. Thank you very much. -- sergei_lus at yahoo dot com changed: What|Removed |Added Severity|enhancement |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40208
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #49 from vvv at ru dot ru 2009-05-20 21:38 ---
(In reply to comment #48)
How this patches work? Is it required some special options?
# /media/disk-1/B/bin/gcc --version
gcc (GCC) 4.5.0 20090520 (experimental)
# 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);
}
extern int F(int m);
void func(int x)
{
int u = F(x);
while (u)
u = F(u)*3+1;
}
# /media/disk-1/B/bin/gcc -o t test.c -O2 -c -mtune=k8
# objdump -d t
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
14: 83 ff 05cmp$0x5,%edi
17: 74 07 je 20 f+0x20
19: f3 c3 repz retq
1b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
20: 31 c0 xor%eax,%eax
22: e9 00 00 00 00 jmpq 27 f+0x27
27: 66 0f 1f 84 00 00 00nopw 0x0(%rax,%rax,1)
2e: 00 00
0030 func:
30: 48 83 ec 08 sub$0x8,%rsp
34: e8 00 00 00 00 callq 39 func+0x9
39: 85 c0 test %eax,%eax
3b: 89 c7 mov%eax,%edi
3d: 74 0e je 4d func+0x1d
3f: 90 nop
40: e8 00 00 00 00 callq 45 func+0x15
45: 8d 7c 40 01 lea0x1(%rax,%rax,2),%edi
49: 85 ff test %edi,%edi
4b: 75 f3 jne40 func+0x10
4d: 48 83 c4 08 add$0x8,%rsp
51: c3 retq
I can't see any padding in function f :(
PS. In file config/i386/i386.c (ix86_avoid_jump_mispredicts)
/* Look for all minimal intervals of instructions containing 4 jumps.
...
Not jumps, but _branches_ (CALL, JMP, conditional branches, or returns)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #50 from jakub at gcc dot gnu dot org 2009-05-20 22:09 --- nopl 0x0(%rax,%rax,1) and nopw 0x0(%rax,%rax,1) aren't padding (though, it has been added in this case for label alignment or function entry alignment, not to avoid 4+ jumps in one 16byte page)? Anyway, you want to look at both -S output and objdump -d of -c output, there you'll see needed .p2align added. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug tree-optimization/40211] New: 13.2 SSA Operands needs to be updated for tuples
While helping a new developer here at Sony, I noticed that the 13.2 SSA
Operands section in the GCC's internals manual still refers to statements that
were tree types.
For an example:
If you wish to iterate over some or all operands, use the
FOR_EACH_SSA_{USE,DEF,TREE}_OPERAND iterator. For example, to print all the
operands for a statement:
void
print_ops (tree stmt)
{
ssa_op_iter;
tree var;
FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_ALL_OPERANDS)
print_generic_expr (stderr, var, TDF_SLIM);
}
That refers to tree statement rather than gimple_stmt.
There are more examples in this section which needs to be updated too.
--
Summary: 13.2 SSA Operands needs to be updated for tuples
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40211
[Bug libfortran/40212] New: Failure on building libgfortran
Hi, this is my first time building gcc compiler. After going through many settings, I stuck on fixing this error. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29867 has discussed the similar error, but forgive me, I really have hard time understanding what exactly I should do. Can anyone help me on this multiple definition error? .libs/backtrace.o(.text+0x780):/usr/include/bits/stdio.h:43: first defined here .libs/in_unpack_generic.o(.text+0xaf0): In function `vprintf': /usr/include/bits/stdio.h:36: multiple definition of `vprintf' .libs/backtrace.o(.text+0x790):/usr/include/bits/stdio.h:36: first defined here .libs/in_unpack_generic.o(.text+0xb10): In function `atoll': /usr/include/stdlib.h:379: multiple definition of `atoll' .libs/backtrace.o(.text+0x7b0):/usr/include/stdlib.h:379: first defined here .libs/in_unpack_generic.o(.text+0xb20): In function `atof': /usr/include/stdlib.h:327: multiple definition of `atof' .libs/backtrace.o(.text+0x7c0):/usr/include/stdlib.h:327: first defined here .libs/in_unpack_generic.o(.text+0xb30): In function `atol': /usr/include/stdlib.h:333: multiple definition of `atol' .libs/backtrace.o(.text+0x7d0):/usr/include/stdlib.h:333: first defined here .libs/in_unpack_generic.o(.text+0xb40): In function `atoi': /usr/include/stdlib.h:398: multiple definition of `atoi' .libs/backtrace.o(.text+0x7e0):/usr/include/stdlib.h:398: first defined here collect2: ld returned 1 exit status make[3]: *** [libgfortran.la] Error 1 make[3]: Leaving directory `/home/software/gcc-4.4.0/x86_64-unknown-linux-gnu/libgfortran' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/software/gcc-4.4.0/x86_64-unknown-linux-gnu/libgfortran' make[1]: *** [all-target-libgfortran] Error 2 make[1]: Leaving directory `/home/software/gcc-4.4.0' make: *** [all] Error 2 Thanks in advance! Kai -- Summary: Failure on building libgfortran Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ksong at lbl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40212
[Bug libfortran/40213] New: Failure on building libgfortran
Hi, this is my first time building gcc compiler. After going through many settings, I stuck on fixing this error. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29867 has discussed the similar error, but forgive me, I really have hard time understanding what exactly I should do. Can anyone help me on this multiple definition error? .libs/backtrace.o(.text+0x780):/usr/include/bits/stdio.h:43: first defined here .libs/in_unpack_generic.o(.text+0xaf0): In function `vprintf': /usr/include/bits/stdio.h:36: multiple definition of `vprintf' .libs/backtrace.o(.text+0x790):/usr/include/bits/stdio.h:36: first defined here .libs/in_unpack_generic.o(.text+0xb10): In function `atoll': /usr/include/stdlib.h:379: multiple definition of `atoll' .libs/backtrace.o(.text+0x7b0):/usr/include/stdlib.h:379: first defined here .libs/in_unpack_generic.o(.text+0xb20): In function `atof': /usr/include/stdlib.h:327: multiple definition of `atof' .libs/backtrace.o(.text+0x7c0):/usr/include/stdlib.h:327: first defined here .libs/in_unpack_generic.o(.text+0xb30): In function `atol': /usr/include/stdlib.h:333: multiple definition of `atol' .libs/backtrace.o(.text+0x7d0):/usr/include/stdlib.h:333: first defined here .libs/in_unpack_generic.o(.text+0xb40): In function `atoi': /usr/include/stdlib.h:398: multiple definition of `atoi' .libs/backtrace.o(.text+0x7e0):/usr/include/stdlib.h:398: first defined here collect2: ld returned 1 exit status make[3]: *** [libgfortran.la] Error 1 make[3]: Leaving directory `/home/software/gcc-4.4.0/x86_64-unknown-linux-gnu/libgfortran' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/software/gcc-4.4.0/x86_64-unknown-linux-gnu/libgfortran' make[1]: *** [all-target-libgfortran] Error 2 make[1]: Leaving directory `/home/software/gcc-4.4.0' make: *** [all] Error 2 Thanks in advance! Kai -- Summary: Failure on building libgfortran Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ksong at lbl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40213
[Bug libfortran/40212] Failure on building libgfortran
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-20 23:40 --- *** Bug 40213 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40212
[Bug libfortran/40213] Failure on building libgfortran
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-20 23:40 --- *** This bug has been marked as a duplicate of 40212 *** -- 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=40213
[Bug libfortran/40214] New: Failure on building libgfortran
Hi, this is my first time building gcc compiler. After going through many settings, I stuck on fixing this error. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29867 has discussed the similar error, but forgive me, I really have hard time understanding what exactly I should do. Can anyone help me on this multiple definition error? .libs/backtrace.o(.text+0x780):/usr/include/bits/stdio.h:43: first defined here .libs/in_unpack_generic.o(.text+0xaf0): In function `vprintf': /usr/include/bits/stdio.h:36: multiple definition of `vprintf' .libs/backtrace.o(.text+0x790):/usr/include/bits/stdio.h:36: first defined here .libs/in_unpack_generic.o(.text+0xb10): In function `atoll': /usr/include/stdlib.h:379: multiple definition of `atoll' .libs/backtrace.o(.text+0x7b0):/usr/include/stdlib.h:379: first defined here .libs/in_unpack_generic.o(.text+0xb20): In function `atof': /usr/include/stdlib.h:327: multiple definition of `atof' .libs/backtrace.o(.text+0x7c0):/usr/include/stdlib.h:327: first defined here .libs/in_unpack_generic.o(.text+0xb30): In function `atol': /usr/include/stdlib.h:333: multiple definition of `atol' .libs/backtrace.o(.text+0x7d0):/usr/include/stdlib.h:333: first defined here .libs/in_unpack_generic.o(.text+0xb40): In function `atoi': /usr/include/stdlib.h:398: multiple definition of `atoi' .libs/backtrace.o(.text+0x7e0):/usr/include/stdlib.h:398: first defined here collect2: ld returned 1 exit status make[3]: *** [libgfortran.la] Error 1 make[3]: Leaving directory `/home/software/gcc-4.4.0/x86_64-unknown-linux-gnu/libgfortran' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/software/gcc-4.4.0/x86_64-unknown-linux-gnu/libgfortran' make[1]: *** [all-target-libgfortran] Error 2 make[1]: Leaving directory `/home/software/gcc-4.4.0' make: *** [all] Error 2 Thanks in advance! Kai -- Summary: Failure on building libgfortran Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ksong at lbl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40214
[Bug libfortran/40214] Failure on building libgfortran
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-20 23:41 --- *** This bug has been marked as a duplicate of 40212 *** -- 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=40214
[Bug libfortran/40212] Failure on building libgfortran
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-20 23:41 --- *** Bug 40214 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40212
[Bug libfortran/40212] Failure on building libgfortran
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-05-20 23:42 --- You are building in the source directory which is currently known to be broken, see PR 35619. *** This bug has been marked as a duplicate of 35619 *** -- 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=40212
[Bug bootstrap/35619] [4.3/4.4/4.5 Regression] fixed includes not being found if building in src dir
--- Comment #26 from pinskia at gcc dot gnu dot org 2009-05-20 23:42 --- *** Bug 40212 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ksong at lbl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35619
[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test
--- Comment #4 from danglin at gcc dot gnu dot org 2009-05-21 00:49 --- This is the backtrace for the last delete: (gdb) bt #0 operator delete (p=0x8001e4f8) at deallocate_global.cc:51 #1 0x4000eafc in __gnu_cxx::new_allocatorchar::deallocate ( this=0x83fffdff0fc8, __p=0x8001e4f8 ) at /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/ext/new_allocator.h:95 #2 0x4000e90c in __gnu_cxx::throw_allocatorchar::deallocate ( this=0x83fffdff0f20, __p=0x8001e4f8 , __n=35) at /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/ext/throw_allocator.h:335 #3 0x4000e35c in std::basic_stringchar, std::char_traitschar, __gnu_cxx::throw_allocatorchar ::_Rep::_M_destroy (this=0x8001e4f8, _...@0x83fffdff0de8) at /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.tcc:426 #4 0x4000efe0 in std::basic_stringchar, std::char_traitschar, __gnu_cxx::throw_allocatorchar ::_Rep::_M_dispose (this=0x8001e4f8, _...@0x83fffdff0de8) at /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:231 #5 0x4000ed6c in ~basic_string (this=0x80011580) at /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:498 #6 0x4000eca0 in __static_initialization_and_destruction_0 ( ---Type return to continue, or q return to quit--- __initialize_p=0, __priority=65535) at deallocate_global.cc:68 #7 0x4000f0a8 in global destructors keyed to _Znwm () at deallocate_global.cc:73 #8 0x40008bc4 in __do_global_dtors_aux () #9 0xc0032aa0 in TE_do_list#HLO_CL_#i1_0x0 () from /usr/lib/pa20_64/dld.sl #10 0xc000d198 in TE_do_program_exit () from /usr/lib/pa20_64/dld.sl #11 0x83fffdcd762c in exit () from /lib/pa20_64/libc.2 #12 0xc000b394 in UT_exit () from /usr/lib/pa20_64/dld.sl #13 0xc000b3b4 in exit () from /usr/lib/pa20_64/dld.sl #14 0xc000b478 in $START$ () from /usr/lib/pa20_64/dld.sl -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094
[Bug pch/40215] New: Generated GCH for c++ file fails to honor include guards with -no-integrated-cpp
When the integrated preprocessor is not used (due to -no-integrated-cpp,
-save-temps, -E, etc), the generated .h.gch file appears to be a valid
precompiled header file, but it does not #define the preprocessor guards (and
perhaps other symbols) from the files it brought in. This causes duplicate
symbols:
% gcc-4.3.3 -v -no-integrated-cpp -o stdafx.h.gch stdafx.h
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../gcc-4.3.3/configure
--prefix=/ati/devel/tools/gcc-4.3.3/install/linux --enable-shared
--enable-threads --enable-languages=c,c++
--with-gmp=/ati/devel/tools/gmp-4.2/install/linux
--with-mpfr=/ati/devel/tools/mpfr-2.3.1/install/linux : (reconfigured)
../../gcc-4.3.3/configure --prefix=/ati/devel/tools/gcc-4.3.3/install/linux
--enable-shared --enable-threads --enable-languages=c,c++
--with-gmp=/ati/devel/tools/gmp-4.2/install/linux
--with-mpfr=/ati/devel/tools/mpfr-2.3.1/install/linux : (reconfigured)
../../gcc-4.3.3/configure --prefix=/ati/devel/tools/gcc-4.3.3/install/linux
--enable-shared --enable-threads --enable-languages=c,c++
--with-gmp=/ati/devel/tools/gmp-4.2/install/linux
--with-mpfr=/ati/devel/tools/mpfr-2.3.1/install/linux
Thread model: posix
gcc version 4.3.3 (GCC)
COLLECT_GCC_OPTIONS='-v' '-no-integrated-cpp' '-o' 'stdafx.h.gch'
'-mtune=generic'
/ati/devel/tools/gcc-4.3.3/install/linux/libexec/gcc/i686-pc-linux-gnu/4.3.3/cc1
-E -quiet -v stdafx.h -mtune=generic -o /tmp/ccnbPxzf.i
ignoring nonexistent directory
/ati/devel/tools/gcc-4.3.3/install/linux/lib/gcc/i686-pc-linux-gnu/4.3.3/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/ati/devel/tools/gcc-4.3.3/install/linux/include
/ati/devel/tools/gcc-4.3.3/install/linux/lib/gcc/i686-pc-linux-gnu/4.3.3/include
/ati/devel/tools/gcc-4.3.3/install/linux/lib/gcc/i686-pc-linux-gnu/4.3.3/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-no-integrated-cpp' '-o' 'stdafx.h.gch'
'-mtune=generic'
/ati/devel/tools/gcc-4.3.3/install/linux/libexec/gcc/i686-pc-linux-gnu/4.3.3/cc1
-fpreprocessed /tmp/ccnbPxzf.i -quiet -dumpbase stdafx.h -mtune=generic
-auxbase stdafx -version -o /tmp/ccGZpv2j.s --output-pch= stdafx.h.gch
GNU C (GCC) version 4.3.3 (i686-pc-linux-gnu)
compiled by GNU C version 4.3.3, GMP version 4.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 49856469fbae50dcb90f9b2de0dd77b2
% file stdafx.h.gch
stdafx.h.gch: GCC precompiled header (version 013) for C
% gcc-4.3.3 -v -c -o pchtest.o pchtest.c
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../gcc-4.3.3/configure
--prefix=/ati/devel/tools/gcc-4.3.3/install/linux --enable-shared
--enable-threads --enable-languages=c,c++
--with-gmp=/ati/devel/tools/gmp-4.2/install/linux
--with-mpfr=/ati/devel/tools/mpfr-2.3.1/install/linux : (reconfigured)
../../gcc-4.3.3/configure --prefix=/ati/devel/tools/gcc-4.3.3/install/linux
--enable-shared --enable-threads --enable-languages=c,c++
--with-gmp=/ati/devel/tools/gmp-4.2/install/linux
--with-mpfr=/ati/devel/tools/mpfr-2.3.1/install/linux : (reconfigured)
../../gcc-4.3.3/configure --prefix=/ati/devel/tools/gcc-4.3.3/install/linux
--enable-shared --enable-threads --enable-languages=c,c++
--with-gmp=/ati/devel/tools/gmp-4.2/install/linux
--with-mpfr=/ati/devel/tools/mpfr-2.3.1/install/linux
Thread model: posix
gcc version 4.3.3 (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-o' 'pchtest.o' '-mtune=generic'
/ati/devel/tools/gcc-4.3.3/install/linux/libexec/gcc/i686-pc-linux-gnu/4.3.3/cc1
-quiet -v pchtest.c -quiet -dumpbase pchtest.c -mtune=generic -auxbase-strip
pchtest.o -version -o /tmp/cc11Ilvb.s
ignoring nonexistent directory
/ati/devel/tools/gcc-4.3.3/install/linux/lib/gcc/i686-pc-linux-gnu/4.3.3/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/ati/devel/tools/gcc-4.3.3/install/linux/include
/ati/devel/tools/gcc-4.3.3/install/linux/lib/gcc/i686-pc-linux-gnu/4.3.3/include
/ati/devel/tools/gcc-4.3.3/install/linux/lib/gcc/i686-pc-linux-gnu/4.3.3/include-fixed
/usr/include
End of search list.
GNU C (GCC) version 4.3.3 (i686-pc-linux-gnu)
compiled by GNU C version 4.3.3, GMP version 4.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 49856469fbae50dcb90f9b2de0dd77b2
In file included from pchtest.c:2:
decls.h:3: error: redefinition of struct Foo
make: *** [pchtest.o] Error 1
/decls.h/
#if !defined(DECLS_H)
#define DECLS_H
struct Foo {};
#endif
/stdafx.h/
#if !defined(STDAFX_H)
#define STDAFX_H
#include decls.h
#endif
/pchtest.c/
#include stdafx.h
#include decls.h
int main(void) { return 0; }
--
Summary: Generated GCH for c++ file fails to honor include guards
with -no-integrated-cpp
Product: gcc
[Bug pch/40215] Generated GCH fails to honor include guards with -no-integrated-cpp
--- Comment #1 from sacolcor at provide dot net 2009-05-21 02:06 --- (Adjusting summary; additional testing revealed that this is not confined to C++) -- sacolcor at provide dot net changed: What|Removed |Added Summary|Generated GCH for c++ file |Generated GCH fails to honor |fails to honor include |include guards with -no- |guards with -no-integrated- |integrated-cpp |cpp | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40215
[Bug c/40216] New: Optimization error when compiling bfd/ecofflink.c on x86_64
When compiling bfd/ecofflink.c from binutils-2.15.94.0.2.2 on an x86_64, there is an optimization bug which can cause the ld command to segfault. One can see the problem in the output of objdump -S ecofflink.o: (my comments are preceded by ^) newbuf = (char *) bfd_realloc (*buf, (bfd_size_type) have + want); 2018: 48 8d 2c 02 lea(%rdx,%rax,1),%rbp 201c: 48 89 eemov%rbp,%rsi 201f: e8 00 00 00 00 callq 2024 bfd_ecoff_debug_one_external+0xf4 if (newbuf == NULL) 2024: 48 85 c0test %rax,%rax 2027: 0f 84 b3 00 00 00 je 20e0 bfd_ecoff_debug_one_external+0x1b0 return FALSE; *buf = newbuf; *bufend = *buf + have + want; 202d: 48 8b b3 10 01 00 00mov0x110(%rbx),%rsi ^ this is putting the current value of debug-external_ext (which may be null) into %rsi 2034: 48 8b 93 b0 00 00 00mov0xb0(%rbx),%rdx want = ALLOC_SIZE; } newbuf = (char *) bfd_realloc (*buf, (bfd_size_type) have + want); if (newbuf == NULL) return FALSE; *buf = newbuf; 203b: 48 89 83 10 01 00 00mov%rax,0x110(%rbx) ^ this is putting the newly allocated pointer into debug-external_ext *bufend = *buf + have + want; 2042: 48 01 e8add%rbp,%rax 2045: 48 89 83 20 01 00 00mov%rax,0x120(%rbx) (char **) debug-external_ext_end, (symhdr-iextMax + 1) * (size_t) external_ext_size)) return FALSE; } esym-asym.iss = symhdr-issExtMax; 204c: 48 8b 0c 24 mov(%rsp),%rcx 2050: 48 8b 83 80 00 00 00mov0x80(%rbx),%rax (*swap_ext_out) (abfd, esym, 2057: 48 8b 7c 24 08 mov0x8(%rsp),%rdi (char **) debug-external_ext_end, (symhdr-iextMax + 1) * (size_t) external_ext_size)) return FALSE; } esym-asym.iss = symhdr-issExtMax; 205c: 48 89 41 08 mov%rax,0x8(%rcx) (*swap_ext_out) (abfd, esym, 2060: 49 0f af 54 24 48 imul 0x48(%r12),%rdx 2066: 48 8d 14 16 lea(%rsi,%rdx,1),%rdx ^ This is using %rsi, which is the (possbily null) value of debug-external_ext *before* it was set to the proper allocated value. 206a: 48 89 cemov%rcx,%rsi 206d: ff 54 24 10 callq *0x10(%rsp) ((char *) debug-external_ext + symhdr-iextMax * swap-external_ext_size)); The *(swap_ext_out) function will then segfault if its third parameter is null. The compiler command line and output follows: $ gcc -v -save-temps -DHAVE_CONFIG_H -I. -I../../binutils-2.15.94.0.2.2/bfd -I. -D_GNU_SOURCE -I../../binutils-2.15.94.0.2.2/include -I../../binutils-2.15.94.0.2.2/intl -I../intl -W -Wall -Wstrict-prototypes -Wmissing-prototypes -g -O2 -c ../../binutils-2.15.94.0.2.2/bfd/ecofflink.c Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-cpu=generic --build=x86_64-redhat-linux Thread model: posix gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-DHAVE_CONFIG_H' '-I.' '-I../../binutils-2.15.94.0.2.2/bfd' '-I.' '-D_GNU_SOURCE' '-I../../binutils-2.15.94.0.2.2/include' '-I../../binutils-2.15.94.0.2.2/intl' '-I../intl' '-W' '-Wall' '-Wstrict-prototypes' '-Wmissing-prototypes' '-g' '-O2' '-c' '-E' '-mtune=generic' /usr/libexec/gcc/x86_64-redhat-linux/4.3.0/cc1 -E -quiet -v -I. -I../../binutils-2.15.94.0.2.2/bfd -I. -I../../binutils-2.15.94.0.2.2/include -I../../binutils-2.15.94.0.2.2/intl -I../intl -DHAVE_CONFIG_H -D_GNU_SOURCE ../../binutils-2.15.94.0.2.2/bfd/ecofflink.c -mtune=generic -W -Wall -Wstrict-prototypes -Wmissing-prototypes -fworking-directory -O2 -fpch-preprocess ignoring nonexistent directory /usr/lib/gcc/x86_64-redhat-linux/4.3.0/include-fixed ignoring nonexistent directory /usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../x86_64-redhat-linux/include ignoring duplicate directory . #include ... search starts here: #include ... search starts here: . ../../binutils-2.15.94.0.2.2/bfd ../../binutils-2.15.94.0.2.2/include ../../binutils-2.15.94.0.2.2/intl ../intl /usr/local/include /usr/lib/gcc/x86_64-redhat-linux/4.3.0/include /usr/include
[Bug c/40216] Optimization error when compiling bfd/ecofflink.c on x86_64
--- Comment #1 from dahowell at directv dot com 2009-05-21 03:47 --- Created an attachment (id=17897) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17897action=view) ecofflink.i preprocessed source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40216
