On Fri, 16 Mar 2012 19:41:56 + (UTC)
Joseph S. Myers jos...@codesourcery.com wrote:
On Fri, 16 Mar 2012, David Malcolm wrote:
Proposed outcome
[...]
Current architectural issues
[...]
Not many people commented on the architectural goals document Diego and I
posted at
On 3/18/2012 12:56 PM, Basile Starynkevitch wrote:
* you can name and count the modules of a software
Well in a hierarchical system this is not so clear, since modules may
exist at different levels of abstraction. For instance in a compiler,
at one level of abstraction, the front end is a
On Sun, 18 Mar 2012 13:11:05 -0400
Robert Dewar de...@adacore.com wrote:
On 3/18/2012 12:56 PM, Basile Starynkevitch wrote:
* you can name and count the modules of a software
Well in a hierarchical system this is not so clear, since modules may
exist at different levels of
On 18 March 2012 16:56, Basile Starynkevitch wrote:
* a garbage collector. Even a modular GCC need some memory management
policy (and
ref-counting à la GTK, or à la std::shared_ptr is not enough IMHO inside a
compiler
because a compiler has much more complex and circular data structures,
I'm sending the email again as my connection seems to be having strange issues
and it doesn't look like it got through the first time (hope it doesn't get
duplicated).
Hello everyone,
I'm thinking of applying for GSoC, and I've got three main ideas for gcc based
around my project.
I've been
On Sun, 18 Mar 2012 20:49:24 +
Jonathan Wakely jwakely@gmail.com wrote:
On 18 March 2012 16:56, Basile Starynkevitch wrote:
* a garbage collector. Even a modular GCC need some memory management
policy (and
ref-counting à la GTK, or à la std::shared_ptr is not enough IMHO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52610
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
CC||ebotcazou at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52610
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52609
--- Comment #2 from Pawel Sikora pluto at agmk dot net 2012-03-18 09:32:03
UTC ---
(In reply to comment #1)
accessing unsigned* via float* looks buggy
It does not have to be if the original argument was originally of type float.
Aliasing is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
Attachment #26909|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51002
Claus-Justus Heine hims...@claus-justus-heine.de changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
Thomas Koenig tkoenig at gcc dot gnu.org changed:
What|Removed |Added
CC||tkoenig at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52611
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52611
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
Known to work||4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52611
--- Comment #3 from Steven Bosscher steven at gcc dot gnu.org 2012-03-18
16:21:54 UTC ---
The problem happens very early on, during gimplification:
#1 0x009e7546 in verify_gimple_assign_unary (stmt=0x77fb5f00) at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41969
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52611
--- Comment #4 from Steven Bosscher steven at gcc dot gnu.org 2012-03-18
16:32:15 UTC ---
I don't think we should drop a cast that changes a machine mode:
--- tree-ssa.c.orig 2012-03-18 17:32:32.0 +0100
+++ tree-ssa.c 2012-03-18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
--- Comment #6 from Marc Glisse marc.glisse at normalesup dot org 2012-03-18
18:58:44 UTC ---
Created attachment 26912
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26912
generic shuffle of a single v8sf
An additional function (I should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51002
--- Comment #7 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-18
20:12:43 UTC ---
(In reply to comment #6)
Jut a comment: at least I was using -mtiny-stack on targets with 16-bit stack
to reduce the size of the prologue/epilogue of a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51002
--- Comment #8 from Claus-Justus Heine hims...@claus-justus-heine.de
2012-03-18 20:30:06 UTC ---
(In reply to comment #7)
(In reply to comment #6)
Jut a comment: at least I was using -mtiny-stack on targets with 16-bit
stack
to reduce the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51002
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
CC||dmixm at marine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51002
--- Comment #10 from Claus-Justus Heine hims...@claus-justus-heine.de
2012-03-18 21:56:35 UTC ---
(In reply to comment #9)
(In reply to comment #8)
(In reply to comment #7)
(In reply to comment #6)
Jut a comment: at least I was using
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43940
--- Comment #5 from Steven Bosscher steven at gcc dot gnu.org 2012-03-18
22:48:49 UTC ---
With trunk today (r185508), on x86_64-linux at -O2 -fno-tree-vrp:
The .072t.ifcombine dump:
main ()
{
void * p;
bb 2:
p_2 = __builtin_malloc (4);
if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42972
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
Target|arm-elf |arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52563
Jiangning Liu liujiangning at gcc dot gnu.org changed:
What|Removed |Added
CC|
Ok for google branches after updating the doc/invoke.texi file.
David
http://codereview.appspot.com/5825054/
Mike Stump mikest...@comcast.net writes:
We currently only support constant integer
widths = 2*HOST_BITS_PER_WIDE_INT, and the assert is correctly
triggering if we try to build a wider constant.
Can you give me a concrete example of what will fail with the constant
0 generated by:
On Thu, 8 Mar 2012, Jonathan Wakely wrote:
The manual claims a future version of G++ will support a hybrid
instantiation model, which I don't think is still planned, and
describes extern templates as an extension when they are in C++11.
* doc/extend.texi (Template Instantiation):
Hi,
That won't catch something like
int i;
static_castint(i);
which is also a useless cast, because i is already an int lvalue; not
all lvalues are derived from references. Note that something like
static_castint(42);
is not a useless cast, because it turns a prvalue into an xvalue.
On Sat, Mar 17, 2012 at 10:50 PM, H.J. Lu hjl.to...@gmail.com wrote:
Since we must use reg64 in %fs:(%reg) memory operand like
movq x@gottpoff(%rip),%reg64;
mov %fs:(%reg64),%reg
this patch optimizes x32 TLS IE load and store by wrapping
%reg64 inside of UNSPEC when Pmode == SImode. OK
On Mar 18, 2012, at 3:16 AM, Richard Sandiford wrote:
Mike Stump mikest...@comcast.net writes:
We currently only support constant integer
widths = 2*HOST_BITS_PER_WIDE_INT, and the assert is correctly
triggering if we try to build a wider constant.
Can you give me a concrete example of what
On Thu, 15 Mar 2012, Tom G. Christensen wrote:
Latest results for 4.6.x
-tgc
Testresults for 4.6.2:
hppa2.0w-hp-hpux11.11
i386-pc-solaris2.8
i686-pc-linux-gnu
powerpc-apple-darwin8.11.0
sparc-sun-solaris2.8 (2)
x86_64-apple-darwin10.8.0
x86_64-apple-darwin11.3.0
Dear All,
Please find attached a fix for PR41600 plus some. It is reasonably
straightforward but the following should be noted:
(i) gfc_get_vptr_from_expr exploits that seeming fact that tracing
back any class expression through TREE_OPERAND 0 eventually gets one
back to the class expression. I
On Sun, Mar 18, 2012 at 5:01 PM, Uros Bizjak ubiz...@gmail.com wrote:
I am testing this patch. OK for trunk if it passes all tests?
No, force_reg will generate a pseudo, so this conversion is valid only
for !can_create_pseudo ().
At least for *tls_initial_exec_x32_store, you will need a
On Fri, 9 Mar 2012, Sandra Loosemore wrote:
Per the DWARF web site
http://dwarfstd.org/Download.php
the correct names of the various versions of the DWARF standard appear
to be either DWARF Version N or DWARF N, rather than e.g. DWARF2,
DWARF-2, dwarf2, or whatever. This patch to
On Sun, Mar 18, 2012 at 6:12 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
Greetings,
Now that we're into stage 1 again, I'd like to submit the first round of
changes for dominator-based strength reduction, which will address
issues from PR22586, PR35308, PR46556, and perhaps
Updated doc/invoke.texi and submitted.
Thanks,
-Sri.
On Sat, Mar 17, 2012 at 11:58 PM, davi...@google.com wrote:
Ok for google branches after updating the doc/invoke.texi file.
David
http://codereview.appspot.com/5825054/
37 matches
Mail list logo
