--- Comment #3 from pzhao at gcc dot gnu dot org 2010-07-05 06:13 ---
Fixed for trunk.
--
pzhao at gcc dot gnu dot org changed:
What|Removed |Added
Hi all,
when I try to compile wine-1.2 on a RedHat Enterprise 5 server, i've got this
message:
registrar.c: In function âresource_registerâ:
registrar.c:468:1: internal compiler error: in insert_save, at
caller-save.c:1303
Please submit a full bug report,
with preprocessed source if appropriate.
gcc-4.6-20100703 fails during stage 2 of bootstrap on ARM:
/home/mikpe/gcc-4.6-20100703/gcc/config/arm/arm.c: In function
'arm_attr_length_move_neon':
/home/mikpe/gcc-4.6-20100703/gcc/config/arm/arm.c:12868:7: error: variable
'regno' set but not used [-Werror=unused-but-set-variable]
cc1: all
--- Comment #1 from mikpe at it dot uu dot se 2010-07-05 08:57 ---
Created an attachment (id=21089)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21089action=view)
delete unused ut set variable regno
This obvious patch gets me past this point in the bootstrap.
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-05 09:09 ---
Created an attachment (id=21090)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21090action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44813
--
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=44820
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-05 09:11 ---
Please provide preprocessed source for registrar.c and the output of invoking
the compile when appending -v to the command-line.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from jiez at gcc dot gnu dot org 2010-07-05 09:11 ---
Subject: Bug 44820
Author: jiez
Date: Mon Jul 5 09:11:39 2010
New Revision: 161822
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161822
Log:
2010-07-05 Mikael Pettersson mi...@it.uu.se
PR
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-05 09:13 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-05 09:14 ---
Confirmed btw.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jiez at gcc dot gnu dot org 2010-07-05 09:15 ---
Sorry for causing this. Thanks for your fix. I have committed it for you.
--
jiez at gcc dot gnu dot org changed:
What|Removed |Added
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22138
--- Comment #4 from mikpe at it dot uu dot se 2010-07-05 10:00 ---
Thank you Jie for the swift action.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44820
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-05 10:55 ---
I don't see anything odd on the value-expr (the variable res has been NRVed in
the FE to the RESULT_DECL) nor on the assignments from RESULT_DECL.
So, I think either we should guard this hunk in gimplify.c with
--- Comment #6 from nathan at codesourcery dot com 2010-07-05 10:56 ---
Subject: Re: Virtual inheritence with covariant return type
confuses GCC
Jason,
Reverting that patch fixes the problem and doesn't break any of the existing
covariant tests. Nathan, I couldn't figure out what
--- Comment #13 from dennis dot wassel at googlemail dot com 2010-07-05
11:02 ---
Works with 4.5.0
--
dennis dot wassel at googlemail dot com changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2010-07-05 11:04
---
On it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-05 11:04 ---
Created an attachment (id=21091)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21091action=view)
gcc46-pr44808.patch
Untested fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44808
--- Comment #2 from ubizjak at gmail dot com 2010-07-05 11:43 ---
The problem is with:
Breakpoint 1, fancy_abort (file=0xcd1f88 ../../gcc-svn/trunk/gcc/reload.c,
line=6327, function=0xcd2722 subst_reloads)
at ../../gcc-svn/trunk/gcc/diagnostic.c:878
878 {
(gdb) up
#1
--- Comment #4 from jakub at gcc dot gnu dot org 2010-07-05 12:18 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-05 12:20 ---
Subject: Bug 44784
Author: rguenth
Date: Mon Jul 5 12:20:00 2010
New Revision: 161829
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161829
Log:
2010-07-05 Richard Guenther rguent...@suse.de
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-07-05 12:21 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #11 from jakub at gcc dot gnu dot org 2010-07-05 12:21 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from ramana at gcc dot gnu dot org 2010-07-05 12:22 ---
Are you planning to backport this to all release branches since this affects
all of them ?
cheers
Ramana
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43703
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-07-05 12:32
---
field_type = build_pointer_type (field_type);
+ /* vtype fields can point to different types to the base type. */
+ if (c-ts.type == BT_DERIVED c-ts.u.derived-attr.vtype)
+
--- Comment #5 from jiez at gcc dot gnu dot org 2010-07-05 12:45 ---
Subject: Bug 44820
Author: jiez
Date: Mon Jul 5 12:45:19 2010
New Revision: 161833
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161833
Log:
2010-07-05 Mikael Pettersson mi...@it.uu.se
PR
$ uname -a
Linux oblomow 2.6.31.12-0.2-desktop #1 SMP PREEMPT 2010-03-16 21:25:39 +0100
x86_64 x86_64 x86_64 GNU/Linux
$ g++-4.5 -v
Using built-in specs.
COLLECT_GCC=g++-4.5
COLLECT_LTO_WRAPPER=/opt/gcc-4.5.0/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
--- Comment #13 from burnus at gcc dot gnu dot org 2010-07-05 13:14 ---
(In reply to comment #12)
You shouldn't change bits in (shared) types. Instead do
field_type = build_pointer_type_for_mode
(field_type, ptr_mode,
c-ts.type == BT_DERIVED
--- Comment #22 from ramana at gcc dot gnu dot org 2010-07-05 13:43 ---
With trunk as of a couple of days back - the testcase when compiled with
-mcpu=cortex-a9 -mfpu=neon -mfloat-abi=softfp for EABI generates the following
code for C++ but not for C.
Notice the removal of the check of
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-05 13:46 ---
recursive inlining is limited to a depth of 8.
While the testcase may be interesting, does it have any practical
relevance? Certainly nobody looked to optimize for these funny
callgraphs.
But yes, confirmed.
--
--- Comment #14 from paul dot richard dot thomas at gmail dot com
2010-07-05 13:52 ---
Subject: Re: [OOP] Dynamic dispatch uses broken types
On Mon, Jul 5, 2010 at 3:14 PM, burnus at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
Thanks for checking, Richard!
Indeed, seconded
--- Comment #2 from moonshine at kapsi dot fi 2010-07-05 14:01 ---
This issue seems to be fixed in latest trunk, although issue #44802 still
prevents xz build with -flto -fuse-linker-plugin. Reduced testcase compiles
fine however.
--
moonshine at kapsi dot fi changed:
--- Comment #15 from rguenther at suse dot de 2010-07-05 14:06 ---
Subject: Re: [OOP] Dynamic dispatch uses broken types
On Mon, 5 Jul 2010, paul dot richard dot thomas at gmail dot com wrote:
--- Comment #14 from paul dot richard dot thomas at gmail dot com
2010-07-05 13:52
--- Comment #3 from ubizjak at gmail dot com 2010-07-05 14:09 ---
So, what is the problem here?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44817
Testcase is reduced from ssa-ccp.c from gcc from specCPU2006.
reg...@john-home:~/volatile/bugs/tmp323$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/home/regehr/z/compiler-install/gcc-r161813-install/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target:
--- Comment #1 from regehr at cs dot utah dot edu 2010-07-05 14:40 ---
Created an attachment (id=21092)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21092action=view)
failure-inducing C
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44823
--- Comment #4 from jakub at gcc dot gnu dot org 2010-07-05 14:42 ---
Subject: Bug 44808
Author: jakub
Date: Mon Jul 5 14:42:20 2010
New Revision: 161838
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161838
Log:
PR c++/44808
* gimplify.c (gimplify_modify_expr):
--- Comment #2 from marco at technoboredom dot net 2010-07-05 14:46 ---
(In reply to comment #1)
recursive inlining is limited to a depth of 8.
While the testcase may be interesting, does it have any practical
relevance?
Probably. The test case shows that the compiler fails to
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-05 14:54 ---
It's quite different as tail-recursion optimization doesn't apply if the
functions are named differently. And the callgraph has an exponential
number of edges which we usually do not flatten down to the point where
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-07-05 15:26 ---
*** Bug 44823 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-05 15:26 ---
Mine is smaller ;)
*** This bug has been marked as a duplicate of 44784 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #32 from rguenth at gcc dot gnu dot org 2010-07-05 15:40
---
Re-confirmed for current 4.5 branch and trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from paul dot richard dot thomas at gmail dot com
2010-07-05 15:47 ---
Subject: Re: [OOP] Dynamic dispatch uses broken types
--- Comment #15 from rguenther at suse dot de 2010-07-05 14:06 ---
Now I take a look at build_pointer_type_for_mode and it's uses in
--- Comment #4 from hjl dot tools at gmail dot com 2010-07-05 15:57 ---
This may be a valgrind bug. I will investigate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44817
--- Comment #33 from rguenth at gcc dot gnu dot org 2010-07-05 16:03
---
Using valgrind there are randomly reported errors, so this is likely either
an invalid testcase or a miscompile that manifests itself as runtime
regression.
--
rguenth at gcc dot gnu dot org changed:
--disable-bootstrap --enable-shared --disable-sjlj-exceptions
Thread model: posix
gcc version 4.6.0 20100705 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-O2' '-I.' '-I.' '-I./common' '-I./config'
'-DLOCALEDIR=/usr/share/locale' '-DHAVE_CONFIG_H' '-I./../include/opcode'
'-I./../opcodes/..' '-I./../readline
--- Comment #1 from jojelino at gmail dot com 2010-07-05 16:07 ---
Created an attachment (id=21093)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21093action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44824
On Linux/ia32, revision 161840 gave:
../../src-trunk/gcc/java/class.c: In function 'make_class_data':
../../src-trunk/gcc/java/class.c:1923:3: error: comparison between signed and
unsigned integer expressions [-Werror=sign-compare]
../../src-trunk/gcc/java/class.c:1925:3: error: comparison
--- Comment #1 from hjl dot tools at gmail dot com 2010-07-05 16:13 ---
It may be caused by revision 161839:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00193.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
j...@evans:/abuild/jh/mozilla-central/build2/storage/src
/abuild/jh/trunk-install/bin/g++ mozStorageRow.ii -O2
../../../storage/src/mozStorageRow.cpp: In constructor
mozilla::storage::VariantDataType::Variant(typename
mozilla::storage::variant_storage_traitsDataType::ConstructorType) [with
--- Comment #1 from hubicka at gcc dot gnu dot org 2010-07-05 16:31 ---
Created an attachment (id=21094)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21094action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44826
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-07-05 16:45 ---
Actually it seems to be fallout of my local DECL_BY_REFERENCE change (so it
does not reproduce on clean mainline).
Apprently the result_slot_addr is something that is not allowed in mem_ref.
It goes away with:
@@
--- Comment #11 from sandra at gcc dot gnu dot org 2010-07-05 17:41 ---
Subject: Bug 42505
Author: sandra
Date: Mon Jul 5 17:40:57 2010
New Revision: 161844
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161844
Log:
2010-07-05 Sandra Loosemore san...@codesourcery.com
--- Comment #5 from reuter at physik dot uni-freiburg dot de 2010-07-05
17:41 ---
Created an attachment (id=21095)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21095action=view)
Code triggering the ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44742
--- Comment #6 from reuter at physik dot uni-freiburg dot de 2010-07-05
17:44 ---
I isolated the bug further and prepared a roughly 1 MB sniplet which triggers
the ICE. It seems that the definition of the more than 500 logical array and
packing them in one big array constructor is not
--- Comment #2 from froydnj at codesourcery dot com 2010-07-05 17:45
---
Subject: Re: [4.6 regression] Failed to bootstrap
I do not see this compilation failure on my x86-64 linux machine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44825
--- Comment #7 from janus at gcc dot gnu dot org 2010-07-05 17:49 ---
(In reply to comment #6)
The bug appears in 4.5.0 (release) as well as 4.6.0 trunk revision 161046.
4.4.5 I didn't test but as you have the code now its trivial for you to
verify.
I get the same ICE also with 4.3
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-05 18:00 ---
You need 32-bit HWI host to reproduce.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44825
--- Comment #4 from hjl dot tools at gmail dot com 2010-07-05 18:01 ---
(In reply to comment #2)
Subject: Re: [4.6 regression] Failed to bootstrap
I do not see this compilation failure on my x86-64 linux machine.
It is Linux/ia32 only. You can use
# CC=gcc -m32 CXX=g++ -m32
--- Comment #1 from baldrick at gcc dot gnu dot org 2010-07-05 18:43
---
It turns out that the problem is that when build_function_type_skip_args
creates
the new type, TYPE_POINTER_TO for the new type is still pointing to the old
type.
When gimple_call_set_fndecl is used to change the
--- Comment #8 from janus at gcc dot gnu dot org 2010-07-05 18:49 ---
(In reply to comment #6)
I isolated the bug further and prepared a roughly 1 MB sniplet which triggers
the ICE.
Here is a reduced test case:
module proc8
implicit none
private
integer, parameter :: n_cflow
--- Comment #2 from hubicka at ucw dot cz 2010-07-05 19:02 ---
Subject: Re: Type of ADDR_EXPR in CALL_EXPR
not rebuilt when function is cloned
It turns out that the problem is that when build_function_type_skip_args
creates
the new type, TYPE_POINTER_TO for the new type is
--- Comment #3 from baldrick at gcc dot gnu dot org 2010-07-05 19:14
---
Hi Honza, my original patch was silly, I'm trying this instead:
@@ -7216,7 +7216,7 @@
if (TREE_CODE (orig_type) != METHOD_TYPE
|| !bitmap_bit_p (args_to_skip, 0))
{
- new_type = copy_node
--- Comment #4 from hubicka at ucw dot cz 2010-07-05 19:18 ---
Subject: Re: Type of ADDR_EXPR in CALL_EXPR
not rebuilt when function is cloned
Hi Honza, my original patch was silly, I'm trying this instead:
This seems fine, thanks!
Honza
--
--- Comment #17 from pault at gcc dot gnu dot org 2010-07-05 19:26 ---
Subject: Bug 44596
Author: pault
Date: Mon Jul 5 19:26:12 2010
New Revision: 161848
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161848
Log:
2010-07-05 Paul Thomas pa...@gcc.gnu.org
PR
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #6 from amylaar at gcc dot gnu dot org 2010-07-05 20:14 ---
(In reply to comment #5)
Created an attachment (id=21088)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21088action=view) [edit]
patch which needs testing
I have not tested this fix but it should work and
--- Comment #9 from amylaar at gcc dot gnu dot org 2010-07-05 20:18 ---
Subject: Bug 44512
Author: amylaar
Date: Mon Jul 5 20:18:07 2010
New Revision: 161853
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161853
Log:
PR bootstrap/44512
* genenums.c (main): Output
--- Comment #4 from kargl at gcc dot gnu dot org 2010-07-05 20:24 ---
Closing as fix. The default behavior of gfortran is
to accept any logical kind supported by gfortran. If
either -std=f95 or -std=f2003 is given on the command
line, gfortran will issue an error.
Vittorio thanks for
--- Comment #9 from janus at gcc dot gnu dot org 2010-07-05 21:02 ---
Even shorter:
module proc8
implicit none
integer, parameter :: N = 256
logical, dimension(N**2), parameter :: A = .false.
logical, dimension(N,N), parameter :: B = reshape ( (/ A /), (/ N, N /) )
end module
--- Comment #5 from froydnj at gcc dot gnu dot org 2010-07-05 22:19 ---
Subject: Bug 44825
Author: froydnj
Date: Mon Jul 5 22:19:22 2010
New Revision: 161856
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161856
Log:
PR bootstrap/44825
* class.c
Hi, I get internal compiler error: Segmentation fault when compiling the
attached program. It compiles fine with version 3.4.4
--
Summary: g++4.3.4 segfaults when using boost::intrusive::list
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
--- Comment #1 from chtz at informatik dot uni-bremen dot de 2010-07-05
22:28 ---
Created an attachment (id=21096)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21096action=view)
generated by g++ -v -save-temps -c minimal.cc
--
--- Comment #7 from kkojima at gcc dot gnu dot org 2010-07-05 22:34 ---
Subject: Bug 44531
Author: kkojima
Date: Mon Jul 5 22:33:58 2010
New Revision: 161857
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161857
Log:
Backport from mainline:
PR target/44531
--- Comment #8 from kkojima at gcc dot gnu dot org 2010-07-05 22:39 ---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
reg...@john-home:~$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/home/regehr/z/compiler-install/gcc-r161813-install/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--- Comment #14 from steven at gcc dot gnu dot org 2010-07-05 22:55 ---
The word 'bubblestrap' doesn't appear anywhere anymore in wwwdocs, and only in
ChangeLogs in trunk/*. And the GCC 4.2 branch is now closed.
So this bug is no longer relevant = WONTFIX.
--
steven at gcc dot gnu
/user/inria/fsf/bld-20100705/./prev-gcc/xgcc
-B/user/inria/fsf/bld-20100705/./prev-gcc/
-B/user/inria/20100705/i686-pc-linux-gnu/bin/
-B/user/inria/20100705/i686-pc-linux-gnu/bin/
-B/user/inria/20100705/i686-pc-linux-gnu/lib/ -isystem
/user/inria/20100705/i686-pc-linux-gnu/include -isystem
/user
--- Comment #6 from amylaar at gcc dot gnu dot org 2010-07-05 23:15 ---
*** Bug 44829 has been marked as a duplicate of this bug. ***
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-07-05 23:15 ---
*** This bug has been marked as a duplicate of 44825 ***
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from redi at gcc dot gnu dot org 2010-07-05 23:26 ---
unpreprocessed source (because preprocessed boost source is so dependent on
compiler version it often won't compile with other versions)
#include boost/intrusive/list.hpp
struct A : public
--- Comment #3 from redi at gcc dot gnu dot org 2010-07-05 23:28 ---
ICE is always at the same place
b.cc: In member function void data_holder::remove(DX*) [with X = int]:
b.cc:45:15: instantiated from here
b.cc:35:3: internal compiler error: Segmentation fault
--
$ cat bug3.f90
module mod1
type my_type
integer i
end type my_type
end module mod1
module mod2
use mod1, only: mod1_type = my_type
interface
function my_func1()
import mod1_type
type(mod1_type) :: my_func1
end function my_func1
type(mod1_type) function
-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure : (reconfigured) ./configure : (reconfigured)
./configure
Thread model: posix
gcc version 4.6.0 20100705 (experimental) (GCC)
when compiling wine, it fails with:
aus...@midna:~/wine-git/dlls/netapi32$ make
gcc
--- Comment #1 from austinenglish at gmail dot com 2010-07-06 01:06 ---
Created an attachment (id=21097)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21097action=view)
output of gcc -v -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44831
--- Comment #2 from austinenglish at gmail dot com 2010-07-06 01:08 ---
Created an attachment (id=21098)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21098action=view)
preproccessed .i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44831
--- Comment #17 from pinskia at gcc dot gnu dot org 2010-07-06 01:49
---
*** Bug 44818 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-07-06 01:49 ---
*** This bug has been marked as a duplicate of 43662 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
r161856, bootstrapped with --enable-build-with-cxx, fails the bootstrap
comparison on i386.o.
By doing a binary search applying the first patch for PR44512
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01765.html
to older revisions, I found that the onset of these comparison failures
is between
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-07-06 05:25 ---
Adding -gtoggle to the options to compile the stage3 i386.o gives the same
assembly as stage2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
--- Comment #4 from ecyrbe at gmail dot com 2010-07-06 05:28 ---
(In reply to comment #3)
Subject: Re: Break in increment expression of for statement
inconsistent with g++
On Tue, 29 Jun 2010, pinskia at gmail dot com wrote:
What does a break with a statement expression do
--- Comment #10 from burnus at gcc dot gnu dot org 2010-07-06 05:33 ---
(In reply to comment #9)
Even shorter:
integer, parameter :: N = 256
Note: N=256 is the smallest number for which it fails.
Workaround: Use a sufficiently large -fmax-array-constructor=n, e.g.
95 matches
Mail list logo
