--- Comment #5 from jon_y at users dot sourceforge dot net 2010-01-24
07:59 ---
Ping,
We need to get this fixed ASAP. Probably involving the libtool devs as well. I
propose the following naming scheme.
libw64stdc++-6.dll (64bit mingw-w64)
libw32stdc++-6.dll (32bit mingw-w64)
--- Comment #11 from burnus at gcc dot gnu dot org 2010-01-24 08:13 ---
Subject: Bug 39304
Author: burnus
Date: Sun Jan 24 08:10:47 2010
New Revision: 156195
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156195
Log:
2010-01-24 Tobias Burnus bur...@net-b.de
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-24 11:52 ---
*** This bug has been marked as a duplicate of 41464 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-24 11:52 ---
*** Bug 42846 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-01-24 12:08 ---
In the testcase from PR42846 one issue is that
base_address: p__3(D)
offset from base address: 0
constant offset from base address: 0
step: 4
aligned to: 128
--- Comment #5 from aanisimov at inbox dot ru 2010-01-24 12:11 ---
(In reply to comment #4)
This looks like a bug in gold rather then in GCC.
Try the latest development version of gold http://sourceware.org/binutils/.
If it still fails, please file a bug report with more details at
--- Comment #3 from aanisimov at inbox dot ru 2010-01-24 12:12 ---
No longer fails.
--
aanisimov at inbox dot ru changed:
What|Removed |Added
Status|WAITING
--- Comment #12 from burnus at gcc dot gnu dot org 2010-01-24 12:54 ---
(In reply to comment #10)
I think there are actually two issues - one is the SPAN/array descriptor
issue, which causes an ICE if one calls the specific function directly, cf.
PR 42851 for the ICE I get there.
I
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-24 13:16 ---
Works for me with GCC 4.3.4 and 4.4.2. GCC 4.2 is no longer maintained.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from bjg at gnu dot org 2010-01-24 13:47 ---
same error occurs with gcc-4.4.3
--
bjg at gnu dot org changed:
What|Removed |Added
CC|
--- Comment #7 from hubicka at ucw dot cz 2010-01-24 13:55 ---
Subject: Re: [4.5 Regression] another GCC 4.5 ICE on C++ templated code
I think it was an accident as this is a P1 bug anyways.
That was accident (i meant to update different PR). I tought I fixed that
already.
Honza
Since revision 155920 (see
http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg01286.html or
http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg02004.html ) there are the
following failures on *-apple-darwin*:
FAIL: gcc.dg/darwin-weakimport-1.c scan-assembler-not weak_[a-z \\t]*_b
FAIL:
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854
--- Comment #2 from danglin at gcc dot gnu dot org 2010-01-24 14:59 ---
The failure also occurs on hppa2.0w-hp-hpux11.11.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2010-01-24
15:00 ---
Subject: Re: [4.5 Regression] FAIL: g++.dg/abi/forced.C execution test
Probably related to PR42837.
The failure started before the failure of g++.dg/abi/packed1.C.
Dave
--
--- Comment #1 from mikpe at it dot uu dot se 2010-01-24 16:04 ---
I'm now seeing failures in StackTrace2 and Throw_3 on arm-linux-gnueabi with
gcc-4.3 branch which I didn't use to see. gcc-4.4 branch doesn't fail for me on
these two, but both 4.4 and 4.3 fail (as always) on Throw_2.
On powerpc*-*-* gcc.dg/tree-ssa/pr42585.c fails with:
FAIL: gcc.dg/tree-ssa/pr42585.c scan-tree-dump-times optimized struct _fat_ptr
_ans 0
FAIL: gcc.dg/tree-ssa/pr42585.c scan-tree-dump-times optimized struct _fat_ptr
_T2 0
(see http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg02116.html or
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-24 16:58 ---
It's a new test. Probably MOVE_RATIO is not defined for your target and thus
the default of 2 applies.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42855
--- Comment #5 from pault at gcc dot gnu dot org 2010-01-24 17:00 ---
Subject: Bug 41167
Author: pault
Date: Sun Jan 24 16:59:51 2010
New Revision: 156197
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156197
Log:
2010-01-24 Paul Thomas pa...@gcc.gnu.org
PR
--- Comment #11 from pault at gcc dot gnu dot org 2010-01-24 17:00 ---
Subject: Bug 41044
Author: pault
Date: Sun Jan 24 16:59:51 2010
New Revision: 156197
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156197
Log:
2010-01-24 Paul Thomas pa...@gcc.gnu.org
PR
Executing on host: /mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/
/mnt/
gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr41555.c -O0 -std=c99 -lm -o
./p
r41555.exe(timeout = 300)
/mnt/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr41555.c:4:20: error: stdint.h:
N
o such file or directory
--- Comment #2 from paolo dot carlini at oracle dot com 2010-01-24 18:42
---
Richard, I'm sorry, I realize now that I'm confused about an important point:
does your analysis of function::swap mean that we are *already* miscompiling
it? Or, are we going to commit patches which will lead
When ignoring the number of bytes available in a streambuf using
std::istream::ignore, ignore calls underflow. This should not happen. I feel
the easiest way to reproduce it is to look at strace output when ignoring bytes
from ifstream:
#include iostream
#include fstream
int main(int argc, char*
--- Comment #3 from rguenther at suse dot de 2010-01-24 20:50 ---
Subject: Re: Revisit std::function for aliasing
issues
On Sun, 24 Jan 2010, paolo dot carlini at oracle dot com wrote:
--- Comment #2 from paolo dot carlini at oracle dot com 2010-01-24 18:42
---
Richard,
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-24 21:20 ---
Needs /* { dg-require-effective-target stdint_types } */
HJ, you backported this?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-24 21:22 ---
Blocks improvement/regression fix for PR42617 (has patches attached to
reproduce
this bug).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
Between svn rev. 156083 and 156198 the following ICE started to
occur with the attached testcase:
f951: internal compiler error: Segmentation fault
Running gdb on the testcase:
(gdb) run gfcbug102.f90
Starting program: /opt/gfortran/4.5/libexec/gcc/i686-pc-linux-gnu/4.5.0/f951
gfcbug102.f90
--- Comment #1 from anlauf at gmx dot de 2010-01-24 22:36 ---
Created an attachment (id=19697)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19697action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42858
--- Comment #2 from dominiq at lps dot ens dot fr 2010-01-24 23:15 ---
Confirmed. I think this is due to revision 156195. I also see the same ICE for
the test in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42418#c1 (with the
comments removed). For both cases the backtrace is:
(gdb) run
--- Comment #13 from dominiq at lps dot ens dot fr 2010-01-24 23:31 ---
I think the patch in comment #11 caused pr42858. Also the tests in comment #1
and #4 give a segmentation fault:
(gdb) run pr39304_1.f90
The program being debugged has been started already.
Start it from the
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-cygwin/4.5.0/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: ./configure --prefix=/usr --disable-win32-registry
--enable-threads=posix --enable-languages=c,c++,java
--with-win32-nlsapi=unicode --enable-tls
--- Comment #1 from jojelino at gmail dot com 2010-01-25 00:11 ---
Created an attachment (id=19698)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19698action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42859
--- Comment #2 from jojelino at gmail dot com 2010-01-25 00:23 ---
Created an attachment (id=19699)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19699action=view)
testcase
other testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42859
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-01-25 01:18
---
This appears to fix this: regression tested on x86-64
Index: array.c
===
--- array.c (revision 156201)
+++ array.c (working copy)
@@
--- Comment #2 from hjl dot tools at gmail dot com 2010-01-25 03:11 ---
Created an attachment (id=19700)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19700action=view)
A patch
Please test this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42856
I've just upgraded to 4.4.3 and tried a fresh build of mesa's git/master. I
get an ICE as:
/usr/bin/gcc -I../../include -march=native -msse2 -mfpmath=sse -O3 -ffast-math
-funroll-loops -fomit-frame-pointer -floop-interchange -floop-strip-mine
-floop-block -Wall -Wmissing-prototypes -std=c99
--- Comment #5 from mmitchel at gcc dot gnu dot org 2010-01-25 03:14
---
Subject: Bug 42748
Author: mmitchel
Date: Mon Jan 25 03:14:25 2010
New Revision: 156202
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156202
Log:
PR c++/42748
* config/arm/arm.c
--- Comment #1 from ronis at ronispc dot chem dot mcgill dot ca 2010-01-25
03:15 ---
Created an attachment (id=19701)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19701action=view)
Preprocessed source file causing the ICE
This is the first source file that triggers the ICE;
--- Comment #6 from mmitchel at gcc dot gnu dot org 2010-01-25 03:16
---
Fixed.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c |middle-end
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2010-01-25 06:58
---
Jakub, what to do with this PR? It is still marked blocker although it seems
to have blocked nothing.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-01-25 07:35
---
3.x isn't supported anymore.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Priority|P1 |P3
--- Comment #12 from pault at gcc dot gnu dot org 2010-01-25 07:53 ---
I just posted the patch for this, so could take it with some advantage. Will
correct 4.4 in a few days.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from frank dot braun at rz dot uni-regensburg dot de
2010-01-25 07:57 ---
Today I am not able to reproduce the error. The compiler is working. Where
exactly does the file m.mod reside? In the user directory or in a compiler
directory?
Frank Braun
(In reply to comment
46 matches
Mail list logo
