One of users managed to add '-fkeep-inline-functions' flag to his CFLAGS and
managed to break build of our project. Simple example:
/* a.c: */
extern int foo(void);
static inline int unused_function(void) { return foo(); }
int main(void){ return 42; }
/* shell: */
$ /tmp:gcc a.c -o a # all ok
$
--- Comment #4 from zsojka at seznam dot cz 2009-12-26 10:50 ---
Created an attachment (id=19393)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19393action=view)
even more reduced testcase
I have a suspicion this warning is valid. There is an app that (sometimes)
crashes when code
--- Comment #1 from jakub at gcc dot gnu dot org 2009-12-26 10:55 ---
It is not useless, the reason you in some cases want to keep out of line copies
of inline functions is e.g. debugging, if there is no out of line copy of a
function, you can't call it from within the debugger.
--
--- Comment #9 from paolo dot carlini at oracle dot com 2009-12-26 11:03
---
I understand can be closed as fixed now.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
I get an ICE when compiling this file using this command (file to be attached.)
C:\g++ -c -Wreturn-type -fno-strict-aliasing -O2 -frtti -fexceptions
-mthreads -o RenderMenuList.o RenderMenuList.ii
rendering/RenderMenuList.cpp: In member function
'WebCore::RenderMenuList::contr
olClipRect(int,
+++ This bug was initially created as a clone of Bug #42290 +++
Command line:
g++ -O1 -fipa-sra testcase.cpp ./a.out
(-Wall shows valid (but misleading?) warnings as described in bug 42290)
Tested versions:
r155434 - broken
r154886 - broken
r154830 - OK
r153685 - OK
Output:
g++ -O1 -fipa-sra
--- Comment #1 from zsojka at seznam dot cz 2009-12-26 11:20 ---
Created an attachment (id=19394)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19394action=view)
testcase
Command line:
g++ -O1 -fipa-sra pr42508.cpp ./a.out
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42508
--- Comment #5 from zsojka at seznam dot cz 2009-12-26 11:23 ---
I opened the wrong code bug as pr42508
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42290
current trunk (including all changes from 20091223), native build configured
with --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16
--with-mode=thumb, fails in stage3 (--with-mode=thumb the option to trigger
this):
if [ x-fPIC != x ]; then \
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-26 12:38
---
Has been fixed a lot of time ago.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #5 from paolo dot carlini at oracle dot com 2009-12-26 12:43
---
Works in mainline, not a regression, closing.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-26 12:47
---
Fixed a lot of time ago.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #8 from paolo dot carlini at oracle dot com 2009-12-26 13:52
---
Will not be fixed in 4_3-branch.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #8 from paolo dot carlini at oracle dot com 2009-12-26 13:53
---
Will not be fixed in 4_3-branch.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-26 13:57
---
Works fine in mainline indeed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #7 from paolo dot carlini at oracle dot com 2009-12-26 14:04
---
Please provide a self-contained .ii, see:
http://gcc.gnu.org/bugs/#report
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42355
--- Comment #8 from paolo dot carlini at oracle dot com 2009-12-26 14:06
---
Also, please do your best to minimize it, see:
http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42355
--- Comment #5 from paolo dot carlini at oracle dot com 2009-12-26 14:20
---
Feedback not forthcoming.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-26 14:32
---
Yes, fixed long time ago.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-26 14:38
---
Fixed a long time ago.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from mikpe at it dot uu dot se 2009-12-26 14:59 ---
Reverting r155171 allows gcc-4.4-20091215 to build a working libjava again.
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155171
Log:
2009-12-11 Ramana Radhakrishnan ramana.radhakrish...@arm.com
PR
--- Comment #2 from slyfox at inbox dot ru 2009-12-26 15:34 ---
(In reply to comment #1)
It is not useless, the reason you in some cases want to keep out of line
copies
of inline functions is e.g. debugging, if there is no out of line copy of a
function, you can't call it from
gcc.dg/graphite/block-4.c fails at random. On Linux/x86-64, valgrind
reports:
==11194== Invalid read of size 8
==11194==at 0xC714EE: lst_interchange_select_inner
(graphite-interchange.c:708)
==11194==by 0xC72725: lst_interchange_select_outer
(graphite-interchange.c:732)
==11194==by
--- Comment #1 from hjl dot tools at gmail dot com 2009-12-26 16:22 ---
Gcc 4.4.2 runs cleanly under valgrind.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #9 from jason at gcc dot gnu dot org 2009-12-26 16:25 ---
Subject: Bug 42331
Author: jason
Date: Sat Dec 26 16:24:53 2009
New Revision: 155474
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155474
Log:
PR c++/42331
* typeck.c (cp_build_modify_expr):
--- Comment #10 from jason at gcc dot gnu dot org 2009-12-26 16:25 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
seen with trunk 20091226, lowering optimization to -O1 works around the
problem.
Matthias
if [ x-fPIC != x ]; then \
/home/doko/gcc/gcc-4.5-4.5-20091226/build/./prev-gcc/xgcc
-B/home/doko/gcc/gcc-4.5-4.5-20091226/build/./prev-gcc/
-B/usr/alpha-linux-gnu/bin/ -B/usr/alpha-linux-gnu
--- Comment #1 from debian-gcc at lists dot debian dot org 2009-12-26
18:01 ---
Created an attachment (id=19395)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19395action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42511
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-26 18:20
---
The error message is fine in the released 4.4.0, not a regression, closing.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-26 18:23
---
No feedback for 20 months, closing. CC-ing David in case he wants to add
something...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #5 from paolo dot carlini at oracle dot com 2009-12-26 18:31
---
Let's CC Jason about this (frankly, I have *always* used double parentheses, I
thought that was the only legal syntax ;)
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #8 from paolo dot carlini at oracle dot com 2009-12-26 18:36
---
Will not be fixed in 4_3-branch.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-26 18:43
---
This is definitely invalid. The linkage isn't weak, and you get exactly into
the same problem of a plain:
struct u
{
static int const v;
};
int const u::v = 42;
--
paolo dot carlini at oracle dot com
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-26 18:50
---
Yes, this is exactly what the Standard says, see 27.3/2, the behavior changed,
we are more conforming lately.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38543
--- Comment #7 from paolo dot carlini at oracle dot com 2009-12-26 19:03
---
Jakub, I guess we can close this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39554
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-26 19:10
---
I find this disturbing. Let's CC Jason...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-26 19:12
---
Maybe related to c++/36625 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40821
--- Comment #6 from paolo dot carlini at oracle dot com 2009-12-26 19:13
---
Maybe related to c++/40821 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36625
--- Comment #10 from paolo dot carlini at oracle dot com 2009-12-26 19:16
---
Dodji, can we close this one at this point?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39987
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-26 19:19
---
Fix (by Jason, I think) in mainline, not a regression, closing.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2009-12-26 19:22 ---
This is caused by revision 155418:
http://gcc.gnu.org/ml/gcc-cvs/2009-12/msg00562.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42510
--- Comment #8 from jakub at gcc dot gnu dot org 2009-12-26 19:26 ---
The feature has been removed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
reg...@john-home:~$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/home/regehr/z/tmp/gcc-r155465-install/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-12-26 19:44
---
Jan, you're responsible for fixing things you broke. There is a reduced
testcase and the ICE can be reproduced with a cross on x86_64-linux.
--
ebotcazou at gcc dot gnu dot org changed:
What
--- Comment #1 from jakub at gcc dot gnu dot org 2009-12-26 20:00 ---
This breaks during ivopts.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from janus at gcc dot gnu dot org 2009-12-26 20:11 ---
There is a pass 'diagnose_omp_blocks', which generates the error message for
the C code. Its execution function is 'diagnose_omp_structured_block_errors' in
omp-low.x, which is correctly called also for Fortran code.
--- Comment #11 from dodji at gcc dot gnu dot org 2009-12-26 20:31 ---
Yes, I forgot to do it. Sorry about that.
Setting the target milestone to 4.4 and closing.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2009-12-26 21:04 ---
It is caused by revision 154880:
http://gcc.gnu.org/ml/gcc-cvs/2009-12/msg00024.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #6 from rupp at gnat dot com 2009-12-26 21:18 ---
ICE on alpha64-dec-openvms* with 20091224 sources.
--
rupp at gnat dot com changed:
What|Removed |Added
When using all O3 flags without -ftree-vectorize, all work good.
So, I think there is a trouble which can be determined by testing this option
on sys-libs/zlib - package.
--
Summary: -ftree-vectorize and zlib: firefox crashes with
segmentation faults on start
--- Comment #1 from hjl dot tools at gmail dot com 2009-12-26 21:44 ---
Try adding -mstackrealign.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42513
--- Comment #4 from janus at gcc dot gnu dot org 2009-12-26 21:44 ---
I'm curious why this problem only appears for Fortran code and not for C. If it
is a 'glibc feature', then both should be equally affected, or am I mistaken?
The following C program does not show the runtime segfault
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37260
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33492
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40749
--- Comment #2 from mecareful at gmail dot com 2009-12-26 22:01 ---
(In reply to comment #1)
Try adding -mstackrealign.
Now firefox works and does not segfaults on start and works later.
(And thunderbird works now too)
Thanks a lot! :-)
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-12-26 22:10 ---
Still a glibc feature as using the shared glibc/pthreads works. Also does on
darwin and other targets.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-12-26 22:11 ---
Oh and the most likely reason is that why Fortran fails and C works is because
libgfortran weakly imports some pthread symbols which causes the pthread static
library not to be fully included.
--
--- Comment #2 from hjl dot tools at gmail dot com 2009-12-26 22:13 ---
It may be caused by revision 147716:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00693.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2009-12-26 22:16 ---
It is related to PR 41497.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2009-12-26 22:19 ---
*** This bug has been marked as a duplicate of 40838 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #66 from hjl dot tools at gmail dot com 2009-12-26 22:19
---
*** Bug 42513 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-26 22:27
---
Not a regression, works in current release branch and mainline. Closing.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from janus at gcc dot gnu dot org 2009-12-26 22:31 ---
Here are test cases in Fortran and C, which both use GOTOs. Again, the Fortran
code ICEs, while the C code gives an error message:
subroutine sub
integer :: nRead
!$omp critical
if (nRead3) goto 100
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-26 22:40
---
Feedback not forthcoming.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #5 from janus at gcc dot gnu dot org 2009-12-26 22:46 ---
For the Fortran test case in comment #4, diagnose_sb_2 (omp-low.c) is called
six times, with the following statements:
* GIMPLE_BIND
* GIMPLE_OMP_CRITICAL
* GIMPLE_COND
* GIMPLE_LABEL
* GIMPLE_LABEL
* GIMPLE_ASSIGN
--- Comment #2 from steven at gcc dot gnu dot org 2009-12-27 00:45 ---
*** This bug has been marked as a duplicate of 21803 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2009-12-27 00:45 ---
*** Bug 42496 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-27 01:47
---
Feedback not forthcoming.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-27 01:54
---
Fixed for 4.5.0, not a regression, closing as fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Obviously the following code of the definition of class destructor is wrong,
but it passed g++ 4.4.2 in Fedora 12. However g++ 4.1.2 and g++ 3.4.6 in Fedora
12 reported the error.
The testing code is list below:
#include iostream
template typename T
class Base
{
public:
Base();
73 matches
Mail list logo
