--- Comment #10 from irar at il dot ibm dot com 2009-03-08 07:25 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from terminatorul at gmail dot com 2009-03-08 03:58 ---
Created an attachment (id=17418)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17418&action=view)
File referenced in the error output
This is the other file referenced in the error output
--
http://gcc.gnu
--- Comment #1 from terminatorul at gmail dot com 2009-03-08 03:56 ---
Created an attachment (id=17417)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17417&action=view)
Source file to compile
This is the file used on the command line
--
http://gcc.gnu.org/bugzilla/show_bug.cg
Here is the command line and the output:
adr...@darkstar:~/packages/gcc-4.3.3-obj/gcc$
/home/adrian/packages/gcc-4.3.3-obj/./prev-gcc/xgcc
-B/home/adrian/packages/gcc-4.3.3-obj/./prev-gcc/ -B/usr/i686-pc-linux-gnu/bin/
-c -g -O2 -fomit-frame-pointer -fprofile-generate -gnatpg -gnata -g -O1
-f
--- Comment #7 from manu at gcc dot gnu dot org 2009-03-08 03:54 ---
(In reply to comment #5)
> BTW, my comment was about the C++ frontend. IE:
> .../gcc44/bin/g++ -c -Wall -W -Wconversion test.cpp
The code of Wconversion is shared between C and C++ front-ends, so they should
produc
--- Comment #3 from manu at gcc dot gnu dot org 2009-03-08 03:30 ---
> The old behavior was just fine!
You absolutely did not understand what the old -Wconversion did.
http://gcc.gnu.org/wiki/NewWconversion
But if you still want the old behaviour, just use -Wtraditional-conversion.
--- Comment #1 from sezeroz at gmail dot com 2009-03-08 01:51 ---
Created an attachment (id=17416)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17416&action=view)
libiberty pid_t patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39397
pex-* stuff of libiberty is inconsistent in storing pid values: at some
places it uses 'pid_t' but at some places it uses 'long'. using long is
wrong for win64: pex-win32.c deals with HANDLE values and they must be
stored as pid_t, which mingw-w64 headers properly define as int64.
the attached pat
--- Comment #9 from fang at csl dot cornell dot edu 2009-03-07 20:25
---
I usually set the environment variable POSIXLY_CORRECT when I want to catch
portability issues. The GNU versions of the utils are usually good about
disabling extensions and griping about violations.
--
fang
--- Comment #16 from jason at gcc dot gnu dot org 2009-03-07 20:16 ---
So here's what happens:
1) The front end chooses 'x' as the NRV for f4 and rewrites the assignments.
2) inlining creates a temporary variable for the return value of f1. So we
have
:
D.1204 = ax;
= D.1204;
g
--- Comment #3 from fang at csl dot cornell dot edu 2009-03-07 20:02
---
If class C inherits from A and B, would we conservatively consider possible
cross-casts from A* to B* through C*, when trying to statically analyze the
dynamic_cast? (And would it matter if class C wasn't even vis
--- Comment #7 from hjl dot tools at gmail dot com 2009-03-07 19:44 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00432.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #6 from fang at csl dot cornell dot edu 2009-03-07 19:36
---
Manuel has resolved/fixed several -Wconversion issues since 4.3, perhaps he can
comment?
--
fang at csl dot cornell dot edu changed:
What|Removed |Added
-
--- Comment #3 from wolfgang dot glas at ev-i dot at 2009-03-07 17:48
---
Jakub, I will try this again with the next snapshot of mingw-w64 and will come
back to this report in a few days. Most likely, this is really a duplicate of
PR39367 and we may then close this issue.
--
http:/
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-07 17:07 ---
Likely dup of PR39367. Please retry with latest SVN.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39396
--- Comment #1 from wolfgang dot glas at ev-i dot at 2009-03-07 16:54
---
Created an attachment (id=17415)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17415&action=view)
gzipped. preprocessed source code of the acffected C++ source file.
Output of
x86_64-pc-mingw32-g++ -E -O2
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2009-03-07
16:52 ---
Subject: Re: [4.4 Regression] ICE at dwarf2out.c:10353 in
loc_descriptor_from_tree_1
> Can you reproduce it with stage1 cc1plus (or non-bootstrapped cc1plus) built
> by
> some older gcc, or only with sta
I encountered the following ICE when compining omniORB 4.1.3 with mingw-w64
20090305 snapshot:
/home/wglas/download/omniorb/omniORB-4.1.3/src/lib/omniORB/orbcore > make
export
x86_64-pc-mingw32-g++ -c -O2 -D_WINSTATIC -mthreads -I.. -I./..
-I../../../../include/omniORB4/internal -DUSE_omniORB_lo
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #3 from hjl at gcc dot gnu dot org 2009-03-07 16:32 ---
Subject: Bug 39323
Author: hjl
Date: Sat Mar 7 16:32:34 2009
New Revision: 144701
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144701
Log:
gcc/
2009-03-07 H.J. Lu
PR c/39323
* c-common.c
--- Comment #12 from jason at gcc dot gnu dot org 2009-03-07 16:22 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #11 from jason at gcc dot gnu dot org 2009-03-07 16:21 ---
Subject: Bug 39367
Author: jason
Date: Sat Mar 7 16:21:05 2009
New Revision: 144697
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144697
Log:
PR c++/39367
* init.c (build_new_1): Don't use a
--- Comment #1 from uweigand at gcc dot gnu dot org 2009-03-07 16:02
---
Subject: Bug 38028
Author: uweigand
Date: Sat Mar 7 16:02:30 2009
New Revision: 144696
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144696
Log:
PR middle-end/38028
* function.c (assign_p
--- Comment #5 from pault at gcc dot gnu dot org 2009-03-07 16:00 ---
Fixed on trunk and 4.3.
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #11 from pault at gcc dot gnu dot org 2009-03-07 15:59 ---
Fixed on trunk and 4.3.
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pault at gcc dot gnu dot org 2009-03-07 15:59 ---
Subject: Bug 39295
Author: pault
Date: Sat Mar 7 15:58:49 2009
New Revision: 144695
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144695
Log:
2009-03-07 Paul Thomas
PR fortran/39295
* int
--- Comment #10 from pault at gcc dot gnu dot org 2009-03-07 15:56 ---
Subject: Bug 39292
Author: pault
Date: Sat Mar 7 15:56:37 2009
New Revision: 144694
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144694
Log:
2009-03-07 Paul Thomas
PR fortran/39292
* tr
--- Comment #1 from spop at gcc dot gnu dot org 2009-03-07 15:29 ---
Subject: Re: New: cloog link failure with non-gcc
bootstrap compiler
On Sat, Mar 7, 2009 at 02:28, dcb314 at hotmail dot com
wrote:
> Using -L/lib for -lcloog looks deeply suspicious to me.
> Even more so, -
--- Comment #11 from drangon dot mail at gmail dot com 2009-03-07 15:10
---
Created an attachment (id=17414)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17414&action=view)
the output object of thread.o
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
--- Comment #10 from drangon dot mail at gmail dot com 2009-03-07 15:02
---
Created an attachment (id=17413)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17413&action=view)
gcc -E output ( gcc 4.4.0 svn 20090307 )
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
--- Comment #9 from drangon dot mail at gmail dot com 2009-03-07 14:52
---
(In reply to comment #8)
> I can't test your precompiled code, because c++ has changed in an incompatible
> way. Could you attach a current precompiled version using gcc4.4 of it?
> Is the problem still present o
--- Comment #18 from galtgendo at o2 dot pl 2009-03-07 14:06 ---
Well, I've got bad news for you anyway:
it seems that the problem affects gcc-4.3.2 too:
it seems it's reproducible in another app,
however one potentially much harder to debug.
Please read http://bugs.winehq.org/show_bug.c
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu dot
|
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-03-07 10:46 ---
(In reply to comment #3)
> Well, the issues in driver seems to be related to pexecute in protoize.c. On a
> first glance, I noticed that here for pid's an 'int' type is used (btw in
> libiberty a 'long' is used for ke
I usually bootstrap the weekly snapshot of gcc 4.4
with the Intel C compiler.
This usually works, but this week snapshot 20090306 didn't.
There seem to be some fun & games with linking together to
make cc1-dummy.
icc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prot
ot
35 matches
Mail list logo
