The symptoms are that for some inputs, my C++ program gets stuck after a
`throw' and before the corresponding `catch', with CPU running. With an
appropriate DYLD_LIBRARY_PATH, the problem disappears.
The problem comes IMHO from libgcc/config/t-slibgcc-darwin (lines 29-35) where
--- Comment #6 from jay dot krell at cornell dot edu 2010-05-13 07:56
---
Another I didn't understand from the other mail thread: why not always output
;?
In particular, the warning that would be disabled -- that is for hand written
assembly only, right? Is it disable for the entire
--- Comment #1 from paolo dot carlini at oracle dot com 2010-05-13 08:41
---
Mike, can you have a look?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #18 from pluto at agmk dot net 2010-05-13 09:13 ---
(In reply to comment #17)
Not a bug, you need to configure libstdc++ and stlport the same if you want
them to work together.
__thread/pthread in eh_globals.cc is an implemetation detail.
how this could conflicts with
--- Comment #10 from sebastian dot huber at embedded-brains dot de
2010-05-13 09:42 ---
Binary search through trunk revisions yield:
r159321 BROKEN
r15 BROKEN
r14 BROKEN
r135000 BROKEN
r132500 BROKEN
r131024 BROKEN
r130512 BROKEN
r130256 BROKEN
r130128 BROKEN
r130064 BROKEN
--- Comment #11 from sebastian dot huber at embedded-brains dot de
2010-05-13 09:50 ---
Created an attachment (id=20654)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20654action=view)
Difference between bdbuf.s in revsions 130051 and 130052
This clearly shows how the frame usage
--- Comment #4 from tkoenig at gcc dot gnu dot org 2010-05-13 09:58 ---
This works now.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ramana at gcc dot gnu dot org 2010-05-13 10:08 ---
Confirmed . I think this is a result of DSE not being able to remove this
because the prologue rtx pattern doesn't show the writes of the actual
registers.
Ramana
--
ramana at gcc dot gnu dot org changed:
--- Comment #19 from redi at gcc dot gnu dot org 2010-05-13 10:24 ---
(In reply to comment #15)
the problematic is eh_globals.o which was merged into libstlport.a.
If stlport imports files which are implementation details, then it depends on
those implementation details. isn't that
--- Comment #12 from mikpe at it dot uu dot se 2010-05-13 10:28 ---
r130052 is a generic scheduling tweak originally described here:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01814.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-13 10:31 ---
Initial patch (trans-decl.c, trans.io.c) here:
http://gcc.gnu.org/ml/fortran/2010-05/msg00124.html
Mapping formal arguments to fnspec should be doable, but I'm experienced enough
in tree-things to continue.
--- Comment #6 from jakub at gcc dot gnu dot org 2010-05-13 10:41 ---
Subject: Bug 43983
Author: jakub
Date: Thu May 13 10:40:51 2010
New Revision: 159357
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159357
Log:
PR debug/43983
* var-tracking.c (track_expr_p):
--- Comment #20 from pluto at agmk dot net 2010-05-13 10:46 ---
(In reply to comment #19)
(In reply to comment #15)
the problematic is eh_globals.o which was merged into libstlport.a.
If stlport imports files which are implementation details, then it depends on
those
--- Comment #7 from jakub at gcc dot gnu dot org 2010-05-13 10:53 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44104
Like PR c/43981, but still happening with 4.6.0 20100513 (Last Changed Rev:
159356
), which is why I copied and editted the title.
In case a const variable is used for array sizing it is not considered to be
read whereas a non-const variable would be considered to be read. It does NOT
happen when
--- Comment #1 from rubidium at openttd dot org 2010-05-13 11:04 ---
Created an attachment (id=20655)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20655action=view)
Simple testcase
Compile with g++ -Wunused-but-set-variable testcase.cpp
--
Built/installed gcc under openSUSE 11.1 with:
../configure --prefix=$pre --enable-languages=c,java
Test program AssertionTest.java:
class AssertionTest {
static public void main( String args[] ) {
assert false: test assertion;
System.out.println(Hello World!);
}
}
At r159354 I see the following new failures in the testsuite:
FAIL: gfortran.dg/proc_ptr_23.f90 -O3 -g (test for excess errors)
FAIL: gfortran.dg/proc_ptr_25.f90 -O3 -g (test for excess errors)
FAIL: gfortran.dg/proc_ptr_comp_9.f90 -O3 -g (test for excess errors)
They give errors like
--- Comment #1 from pkeller at globalphasing dot com 2010-05-13 11:14
---
Created an attachment (id=20656)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20656action=view)
Output from compile/link step of test program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44109
--- Comment #2 from pkeller at globalphasing dot com 2010-05-13 11:15
---
Created an attachment (id=20657)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20657action=view)
Preprocessor output from compiling test program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44109
--- Comment #21 from redi at gcc dot gnu dot org 2010-05-13 11:29 ---
(In reply to comment #20)
stlport includes some gcc archives in libstlport.a for simplier linking
for some definition of simpler :)
Either don't use static linking or rebuild libstlport.a with the gcc version
Bootstrap failure for powerpc-apple-darwin9 from revision 159339:
...
/opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/
-B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/lib/ -isystem
--- Comment #1 from dominiq at lps dot ens dot fr 2010-05-13 11:54 ---
Fixed by revision 159359, see
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00932.html .
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #11 from jakub at gcc dot gnu dot org 2010-05-13 12:03 ---
Subject: Bug 44036
Author: jakub
Date: Thu May 13 12:02:50 2010
New Revision: 159361
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159361
Log:
PR fortran/44036
* openmp.c
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44108
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44103
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-05-13 12:30 ---
Patch:
http://gcc.gnu.org/ml/fortran/2010-05/msg00130.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35779
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-13 12:30 ---
Suggested patch:
http://gcc.gnu.org/ml/fortran/2010-05/msg00116.html
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-13 12:31 ---
Suggested patch:
http://gcc.gnu.org/ml/fortran/2010-05/msg00109.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44055
--- Comment #12 from jakub at gcc dot gnu dot org 2010-05-13 12:36 ---
Subject: Bug 44036
Author: jakub
Date: Thu May 13 12:35:52 2010
New Revision: 159363
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159363
Log:
PR fortran/44036
* openmp.c
--- Comment #13 from jakub at gcc dot gnu dot org 2010-05-13 12:39 ---
Subject: Bug 44036
Author: jakub
Date: Thu May 13 12:39:17 2010
New Revision: 159365
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159365
Log:
PR fortran/44036
* openmp.c
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-05-13
13:02 ---
Also seen on powerpc-apple-darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44103
Revision 159354:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00406.html
caused:
FAIL: gfortran.dg/proc_ptr_23.f90 -O3 -g (test for excess errors)
FAIL: gfortran.dg/proc_ptr_25.f90 -O3 -g (test for excess errors)
FAIL: gfortran.dg/proc_ptr_comp_9.f90 -O3 -g (test for excess errors)
--
--- Comment #2 from steve dot chapel at a2pg dot com 2010-05-13 13:15
---
Excellent! The new warning is far more understandable than the old.
X'R IN CALL RANDOM MAY NOT BE USED OUTSIDE THE BLOCK CONTAINING T
1
Warning: Initialization string starting at (1) was truncated
--- Comment #14 from jakub at gcc dot gnu dot org 2010-05-13 13:22 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-13 13:26 ---
That's easily doable. Alternative patch for data.c below gives:
$ gfortran-svn pr38404.f
pr38404.f:5.7:
X'R IN CALL RANDOM MAY NOT BE USED OUTSIDE THE BLOCK CONTAINING T
1
Warning: Initialization
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-13 13:39 ---
*** This bug has been marked as a duplicate of 44112 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-13 13:39 ---
*** Bug 44110 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
With gdb 7.1 / gcc 4.5.0 I noticed that unrolled loops have very poor
debugging information. The body cannot be single stepped, but a next
in gdb jumps over the whole iteration space.
For example:
main()
{
int i;
for (i = 0; i 10; i++)
printf(%d\n,i );
}
--- Comment #1 from andi-gcc at firstfloor dot org 2010-05-13 13:44 ---
Hmm sorry actually it stepped over everything except the last iteration.
Still unexpected
--
andi-gcc at firstfloor dot org changed:
What|Removed |Added
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-13 13:50 ---
This (a) didn't turn out as much of an issue and (b) the general problem is
known. Closing this specific incarnation as WONTFIX.
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-13 13:50 ---
This (a) didn't turn out as much of an issue and (b) the general problem is
known. Closing this specific incarnation as WONTFIX.
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-13 13:51 ---
It is caused by revision 159315:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00367.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-13 14:08 ---
Subject: Bug 35779
Author: dfranke
Date: Thu May 13 14:08:05 2010
New Revision: 159366
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159366
Log:
gcc/fortran/:
2010-05-13 Daniel Franke
--- Comment #8 from dfranke at gcc dot gnu dot org 2010-05-13 14:09 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
COLLECT_LTO_WRAPPER=/home/ig25/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../trunk/configure --prefix=/home/ig25
--enable-languages=all,ada --with-mpc=/usr/local/
Thread model: posix
gcc version 4.6.0 20100513 (experimental) (GCC
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44114
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-13 14:18 ---
I'm fairly sure I have regtested the patch with lto and these failures didn't
appear, so I guess only some concurrent lto/cgraph changes yesterday made this
trigger. The fix is to add mod_type_die check, will commit
On Linux/x86-64, revision 159357 gave
FAIL: gcc.dg/guality/sra-1.c -O1 line 20 a.j == 14
FAIL: gcc.dg/guality/sra-1.c -O1 line 20 a.j == 14
FAIL: gcc.dg/guality/sra-1.c -O2 line 20 a.j == 14
FAIL: gcc.dg/guality/sra-1.c -O2 line 20 a.j == 14
FAIL: gcc.dg/guality/sra-1.c -O2 -flto line
--- Comment #13 from pinskia at gcc dot gnu dot org 2010-05-13 14:22
---
*** This bug has been marked as a duplicate of 38644 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from pinskia at gcc dot gnu dot org 2010-05-13 14:22
---
*** Bug 44091 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-13 14:24 ---
Subject: Bug 44104
Author: jakub
Date: Thu May 13 14:24:36 2010
New Revision: 159367
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159367
Log:
PR debug/44104
* dwarf2out.c (modified_type_die):
--- Comment #8 from dominiq at lps dot ens dot fr 2010-05-13 14:25 ---
*** This bug has been marked as a duplicate of 44114 ***
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #1 from dominiq at lps dot ens dot fr 2010-05-13 14:25 ---
*** Bug 43924 has been marked as a duplicate of this bug. ***
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2010-05-13 14:28
---
Indeed, fixed for 4.6.0 by the patch which fixed PR34491.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #9 from hjl dot tools at gmail dot com 2010-05-13 14:31 ---
Reopen. This bug report has more info than PR 44114.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-13 14:31 ---
*** This bug has been marked as a duplicate of 43924 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #10 from hjl dot tools at gmail dot com 2010-05-13 14:31
---
*** Bug 44114 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2010-05-13 14:34 ---
Buggy gdb, see http://bugzilla.redhat.com/589467
The lto/whopr issues are LTO bugs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44115
FAIL: gfortran.dg/proc_ptr_23.f90 -O3 -g (test for excess errors)
WARNING: gfortran.dg/proc_ptr_23.f90 -O3 -g compilation failed to produce
executable
FAIL: gfortran.dg/proc_ptr_25.f90 -O3 -g (test for excess errors)
WARNING: gfortran.dg/proc_ptr_25.f90 -O3 -g compilation failed to produce
On multi-TB storage array with XFS filesystem I have to enable 64bit inodes
recently (inode64 mount option). Having test.c with:
int main(void){
return 0;
}
compiles fine for one file, but if i copy it to another one (several times till
it got the right inode number) it produces:
--- Comment #1 from tkoenig at gcc dot gnu dot org 2010-05-13 14:37 ---
Depends on both -O3 and -g:
i...@linux-fd1f:/tmp gfortran proc_ptr_23.f90
i...@linux-fd1f:/tmp gfortran -O3 proc_ptr_23.f90
i...@linux-fd1f:/tmp gfortran -O3 -g proc_ptr_23.f90
/tmp/ccALU2k0.o:(.debug_info+0x81):
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-13 14:44 ---
*** This bug has been marked as a duplicate of 44110 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-13 14:44 ---
*** Bug 44117 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from amonakov at gcc dot gnu dot org 2010-05-13 14:46
---
r...@matylda1: /mnt/data/kasparek# LC_ALL=C gcc -o test.o test-10356.c
cc1: error: test-10356.c: Value too large for defined data type
The first this I need to help with is how to
check if the code that
--- Comment #3 from janus at gcc dot gnu dot org 2010-05-13 14:47 ---
(In reply to comment #0)
fff.f90:26:0: internal compiler error: in gfc_conv_structure, at
fortran/trans-expr.c:4390
It turns out this ICE is actually due to the NULL() initialization of the class
pointer and has
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-13 14:49 ---
Fix posted: http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00960.html
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from janus at gcc dot gnu dot org 2010-05-13 14:55 ---
When removing the NULL initialization in comment #3, the dump shows:
static struct .class.parent.p this = {.$data=0B};
Zeroing the $data pointer is probably not needed without NULL initialization.
With NULL
Tested revisions:
r159305 - crash (after pr34491 fix)
4.5 r158978 - crash
4.4 r158133 - crash
Compiler output:
$ /mnt/svn/gcc-trunk/binary-159305-lto-fortran/bin/g++ testcase.C
testcase.C:2:30: error: template parameters not used in partial specialization:
testcase.C:2:30: error:
--- Comment #1 from zsojka at seznam dot cz 2010-05-13 15:11 ---
Created an attachment (id=20658)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20658action=view)
reduced testcase
$ g++ pr44118.C
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44118
--with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r159348-install
--program-prefix=r159348- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20100513 (experimental) (GCC)
[reg...@gamow tmp413]$ current-gcc -O2 -c small.c
small.c: In function 'func_96
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-13 15:27 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-13 15:27 ---
The PRE change again.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44112
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-13 15:31 ---
This is know. GCC does not use LFS and thus fails. A patch to fix that
was once applied but broke AIX and thus was reverted.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-13 15:33 ---
We throw away DECL_DEBUG_EXPR in free-lang-data (and do not try to stream it).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-13 15:36 ---
Well, you step to the next line-number and only lines #5 are remaining, so
I think you just get what you asked for. I don't know if we could (or should)
signal to gdb that there are multiple lines #5 now. Jakub?
I imagine this will affect all targets.
dpd -I../libdecnumber/GCC/gcc-live-trunk/gcc/objc/objc-act.c \
-o objcp/objcp-act.o
/GCC/gcc-live-trunk/gcc/objc/objc-act.c: In function
build_typed_selector_reference:
/GCC/gcc-live-trunk/gcc/objc/objc-act.c:2709:8: error: too few
--- Comment #3 from andi-gcc at firstfloor dot org 2010-05-13 16:16 ---
I think it should describe multiple lines.
next is expected to iterate through loops, not skip them.
If I wanted to skip I would use until
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44113
--- Comment #8 from paolo dot carlini at oracle dot com 2010-05-13 16:21
---
On it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from steve dot chapel at a2pg dot com 2010-05-13 16:28
---
:)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38404
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-13 16:45 ---
Patch:
http://gcc.gnu.org/ml/fortran/2010-05/msg00135.html
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from iains at gcc dot gnu dot org 2010-05-13 16:48 ---
Created an attachment (id=20659)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20659action=view)
fix PR44120
this is a quick-fix,
FWIW we seem to be getting an ever-increasing number of #ifdef OBJCPLUS - I
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-05-13 16:58
---
I have a revised patch that handles default integer and negative error codes.
It is testing and I will submit when I get an opportunity.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43851
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-05-13 17:02 ---
Related to PR 43630.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Keywords||diagnostic
--- Comment #2 from johnkhord at gmail dot com 2010-05-13 17:12 ---
I re-compiled both GMP and MPFR (using the --with-gmp directive) and am now
getting a new nastygram when make-ing gcc
: Assembler messages:
:5148: Error: symbol `fstatat64' is already defined
:5185: Error: symbol
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-05-13 17:13 ---
Confirmed. Though with the 4.5.0 and above we do have a debug_stmt with the
correct line info at the tree level ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-05-13 17:14 ---
(In reply to comment #2)
I re-compiled both GMP and MPFR (using the --with-gmp directive) and am now
getting a new nastygram when make-ing gcc
No but building in the source directory is not recommended.
--
--- Comment #4 from johnkhord at gmail dot com 2010-05-13 17:15 ---
Never mind -- according to other bug entries, apparently gcc-4.4.3 (and
presumeably 4.4.4) requires glibc 2.6
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44105
--- Comment #5 from johnkhord at gmail dot com 2010-05-13 17:17 ---
(In reply to comment #3)
(In reply to comment #2)
I re-compiled both GMP and MPFR (using the --with-gmp directive) and am now
getting a new nastygram when make-ing gcc
No but building in the source directory is
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44092
--- Comment #9 from paolo dot carlini at oracle dot com 2010-05-13 17:28
---
Nope.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from kargl at gcc dot gnu dot org 2010-05-13 17:49 ---
(In reply to comment #4)
Never mind -- according to other bug entries, apparently gcc-4.4.3 (and
presumeably 4.4.4) requires glibc 2.6
glibc 2.6 is not required for gcc-4.4.3 or gcc-4.4.4.
--
--- Comment #7 from paolo dot carlini at oracle dot com 2010-05-13 17:54
---
Fixed for 4.6.0 by the patch which fixed PR34491.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #48 from tkoenig at gcc dot gnu dot org 2010-05-13 18:04
---
Any news on this?
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from jingyu at google dot com 2010-05-13 18:09 ---
Patch was committed to trunk (4.6) r158138.
Resolved.
--
jingyu at google dot com changed:
What|Removed |Added
m32 and m64:
FAIL: 27_io/basic_stringbuf/in_avail/char/1.cc (test for excess errors)
WARNING: 27_io/basic_stringbuf/in_avail/char/1.cc compilation failed to produce
executable
FAIL: 27_io/basic_stringbuf/in_avail/wchar_t/1.cc (test for excess errors)
WARNING:
--- Comment #1 from iains at gcc dot gnu dot org 2010-05-13 18:47 ---
also:
FAIL: 27_io/basic_stringbuf/in_avail/wchar_t/1.cc (test for excess errors)
Excess errors:
/GCC/gcc-live-trunk/libstdc++-v3/testsuite/27_io/basic_stringbuf/in_avail/wchar_t/1.cc:53:1:
error: Inline clone with
1 - 100 of 142 matches
Mail list logo
