1. Dataflow framework to propagate bitwise register properties.
(Integrated with the current dataflow framework.)
2. Forward bitwise dataflow analysis: constant bit propagation.
3. Backward bitwise dataflow analysis: dead bit propagation.
4. Target applications: improve dce and see.
Silvius,
If you want to persue this, you should go back and look at my patches
for subreg level dataflow and start hacking from there. It is not a
big step to start from that and modify it for bits. If you start
from that, it is most likely not much more than a few days work for
the analysis
Hi,
I find this mails here
http://gcc.gnu.org/ml/gcc/2006-11/msg6.html
But i find no answer how i can do same as extern inline and get no problems
in C99 mode and other modes
I use for longer functions this code
extern __inline long func()
{
}
but when a makefile set -std=c99 then get
On Fri, 6 Mar 2009, Ian Lance Taylor wrote:
I'm happy to report that the gcc-in-cxx branch can now bootstrap. That
is, the code in gcc proper can now be compiled with a C++ compiler.
Great work, thanks!
I'm curious whether there are any detectable differences in the resulting
compiler when
Bernd Roesch wrote:
Hi,
I find this mails here
http://gcc.gnu.org/ml/gcc/2006-11/msg6.html
But i find no answer how i can do same as extern inline and get no problems
in C99 mode and other modes
http://gcc.gnu.org/ml/gcc/2007-03/msg01093.html
cheers,
DaveK
On Fri, 2009-03-06 at 18:44 -0800, Ian Lance Taylor wrote:
I'm happy to report that the gcc-in-cxx branch can now bootstrap. That
is, the code in gcc proper can now be compiled with a C++ compiler.
Hi, did you test with Ada enabled? There are some C files in the
Ada compiler and RTS.
Laurent
Hello
Is -mfpmath=both for i386 and x86-64 still experimental in gcc 4.3, as
the in the online manual page ?
`sse,387'`sse+387'`both'Attempt to utilize both instruction sets at
once. This effectively double the amount of available registers and on
chips with separate execution units for 387 and
On Fri, Mar 6, 2009 at 8:44 PM, Ian Lance Taylor i...@google.com wrote:
I'm happy to report that the gcc-in-cxx branch can now bootstrap. That
is, the code in gcc proper can now be compiled with a C++ compiler.
My plan going forward is as follows (when we are back in stage 1):
* For each
On Wed, Mar 4, 2009 at 9:37 AM, Joseph S. Myers jos...@codesourcery.com wrote:
On Wed, 4 Mar 2009, Piotr Wyderski wrote:
Hello,
Is it possible to allow C++ constant expressions (currently static const,
and C++0x constexpr in the future) to be used as __attribute__ parameters
in the
On Sat, 7 Mar 2009, Gabriel Dos Reis wrote:
(Not that I am impressed with the incompatibilities of C++0x attributes
with existing practice or their ignoring all the hard issues with
attributes that have actually come up in GCC implementation experience -
along with the proposals having
May I forward your message to the CCC++ CWG?
-- Gaby
On Sat, 7 Mar 2009, Gabriel Dos Reis wrote:
May I forward your message to the CCC++ CWG?
Certainly, it is a public message, as are all the previous discussions it
references. I have not tried to engage with the C++ committee directly
since I am not a C++ expert and keeping up with C
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
--- 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
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu dot
|
--- 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
--- 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 on
--- 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=17413action=view)
gcc -E output ( gcc 4.4.0 svn 20090307 )
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
--- 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=17414action=view)
the output object of thread.o
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
--- 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
gcc-bugzi...@gcc.gnu.org wrote:
Using -L/lib for -lcloog looks deeply suspicious
--- 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=gccview=revrev=144694
Log:
2009-03-07 Paul Thomas pa...@gcc.gnu.org
PR
--- 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=gccview=revrev=144695
Log:
2009-03-07 Paul Thomas pa...@gcc.gnu.org
PR
--- 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 #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 #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=gccview=revrev=144696
Log:
PR middle-end/38028
* function.c
--- 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=gccview=revrev=144697
Log:
PR c++/39367
* init.c (build_new_1): Don't use a
--- 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 #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=gccview=revrev=144701
Log:
gcc/
2009-03-07 H.J. Lu hongjiu...@intel.com
PR c/39323
--
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
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
--- 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
--- 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=17415action=view)
gzipped. preprocessed source code of the acffected C++ source file.
Output of
x86_64-pc-mingw32-g++ -E -O2
--- 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 #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.
--
--- 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 #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 #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
--- 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
bb 3:
D.1204 = ax;
retval =
--- 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.
--
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
--- 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=17416action=view)
libiberty pid_t patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39397
--- 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 #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
produce
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
--- 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=17417action=view)
Source file to compile
This is the file used on the command line
--
--- 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=17418action=view)
File referenced in the error output
This is the other file referenced in the error output
--
--- 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
47 matches
Mail list logo
