On 07/26/2013 01:00 AM, David Starner wrote:
On Thu, Jul 25, 2013 at 1:17 AM, Andrew Haley a...@redhat.com wrote:
On 07/24/2013 11:51 PM, David Starner wrote:
On Wed, Jul 24, 2013 at 8:50 AM, Andrew Haley a...@redhat.com wrote:
Not at all: we're just disagreeing about what a real system with
On 07/25/2013 06:21 PM, Joseph S. Myers wrote:
I was interested to watch the video of the DejaGnu BOF at the Cauldron. A
few issues with DejaGnu for toolchain testing that I've noted but I don't
think were covered there include:
Thanks for the thoughtful comments, they're useful as I start
On Fri, 26 Jul 2013, Rob Savoye wrote:
* DejaGnu has a lot of hardcoded logic to try to find various files in a
toolchain build directory. A lot of it is actually for very old toolchain
versions (using GCC version 2 or older, for example). The first issue
with this is that it doesn't
On 07/26/2013 10:37 AM, Joseph S. Myers wrote:
Anything in the core needs to avoid obstructing toolchain changes. People
typically test with the installed DejaGnu from their OS, and the OS itself
may well be a few years old (e.g. Ubuntu 10.04), so it's undesirable for
an enhancement to the
On Fri, 26 Jul 2013, Rob Savoye wrote:
I'd agree there is lots of crufty support for things like the old
Cygnus trees that could be removed. Ideally I'd prefer to explore
people's ideas on what would be useful for testing toolchains 5-10 years
from now. Me, I want something not dependent
Forwarding this to the mailing list as I have forgotten to reply-all.
Should anybody search for the same issue, my solution was to get the
right gawk version. gawk generates a optionslist and options.h file.
The GCC documentation states that gawk 3.1.5 is known to work. My
version was broken.
I am looking at how to best integrate building a cross compiler in our
source tree, which is a little bit old-baken and easy to break.
Nevertheless, I'd like to to it like you're supposed to do with new
GCC's. I am using 4.8.1 now. Rather than describing my specific
problem, let me ask very
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57837
--- Comment #2 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Ramana Radhakrishnan from comment #1)
mine.
fixed with revision 201240 ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57324
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||glisse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57324
--- Comment #2 from Markus Trippelsdorf markus at trippelsdorf dot de ---
Created attachment 30557
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30557action=edit
output
unwrapped output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57699
--- Comment #5 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Well, if a portable O/S like eCos would need such special treatment,
the NO_IMPLICIT_EXTERN_C should not be bound to the target architecture,
it would be far more appropriate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57990
Bug ID: 57990
Summary: cross compilation fails to build zlib
(git-1b179ea9d4020d)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57699
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #5)
Well, if a portable O/S like eCos would need such special treatment,
eCos doesn't need it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57837
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57990
--- Comment #1 from dominik.vogt at gmx dot de ---
Version is commit id 1b179ea9d4020d from git (i.e. current HEAD).
Cross compilation from BUILD=i686-pc-linux-gnu, HOST=i686-pc-linux-gnu to
TARGET=s390-ibm-linux-gnu fails to built zlib.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57731
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57699
--- Comment #7 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Jonathan Wakely from comment #6)
(In reply to Bernd Edlinger from comment #5)
Well, if a portable O/S like eCos would need such special treatment,
eCos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57991
Bug ID: 57991
Summary: Enhance Same actual argument associated warning
(-Waliasing)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57101
--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com ---
This is fixed in mainline. I'm adding the testcase and keeping the bug open
with only the [4.8 Regression] marker.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57101
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Summary|[4.8/4.9 Regression]|[4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57992
Bug ID: 57992
Summary: Pointless packing of contiguous arrays for simply
contiguous functions results as actual arguments
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: antoine.balestrat at gmail dot com
Hello !
I'm using GCC 4.9.0 as of 20130726 :
$ cat dom.c
int a, b, c, d;
char e;
unsigned g;
void f(void)
{
int h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974
--- Comment #14 from Henner Sudek henner.sudek at gmail dot com ---
First i want to thank you all for the quick response and solving my problem. I
just want to point out that std::pow(std::complexlong double(0,0),1.) still
returns nan. Maybe there
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974
--- Comment #15 from Paolo Carlini paolo.carlini at oracle dot com ---
However, there is *nothing* new about that. I still do believe there is a
middle-end issue here, if only because clang and icc are fine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57987
--- Comment #1 from Martin Jambor jamborm at gcc dot gnu.org ---
Created attachment 30558
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30558action=edit
An unsuccessful attempt to fix this
I attempted to fix this with the attached patch but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57916
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com ---
Alexey I sent you the questionnaire on July, 21st. Did you get it?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57987
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org ---
Comment on attachment 30558
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30558
An unsuccessful attempt to fix this
+ if (!has_coarray_vars || gfc_option.coarray ==
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974
--- Comment #16 from Paolo Carlini paolo.carlini at oracle dot com ---
Also, in practice, I think it's *very* hard to explain to the users why long
double is so special, why the middle-end can't handle it in complete analogy
with float and double.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56429
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54812
--- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org ---
*** Bug 56429 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54812
--- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Paolo Carlini from comment #3)
Of course it should be fixed, it *must* be fixed, actually! And it's really
annoying that this bug affecting private defaulted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54812
--- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com ---
Jason call if we want this to be a P2. Well, maybe some wrong code bugs I
recently bumped to P2 should be P1 ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57993
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974
--- Comment #17 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Henner Sudek from comment #14)
First i want to thank you all for the quick response and solving my problem.
I just want to point out that std::pow(std::complexlong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57993
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
CC||wschmidt at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974
--- Comment #18 from Paolo Carlini paolo.carlini at oracle dot com ---
Couple of clarifications: this doesn't go through cpow at all, the second
argument isn't complex; this isn't -ffast-math, and in general in my experience
whatever you throw at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974
Marc Glisse glisse at gcc dot gnu.org changed:
What|Removed |Added
CC||glisse at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974
Marc Glisse glisse at gcc dot gnu.org changed:
What|Removed |Added
CC|glisse at gcc dot gnu.org |
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
Bug ID: 57994
Summary: Constant folding of infinity
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com ---
Thanks Marc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57995
Bug ID: 57995
Summary: [4.72, C++11] Lambda [] wrongly states catch(...)
must be the last handler when variable by-reference
capture occurs within catch(...) scope
Product:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57995
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56388
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57993
--- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org ---
Thanks. I'd guess that something in slsr_process_phi causes this, but so far I
don't know much more.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org ---
So I only got to this and I definitely won't be able to finish it
today or even this week but here is what I have figured out so far.
We ICE when expanding statement
MEM[(struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57413
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57993
Bill Schmidt wschmidt at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57993
--- Comment #5 from Bill Schmidt wschmidt at gcc dot gnu.org ---
Looks like the casting is confusing us into replacing PHIs not dominated by the
prospective basis. Shouldn't be too hard to fix.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57993
--- Comment #6 from Bill Schmidt wschmidt at gcc dot gnu.org ---
Here's the patch I'm currently testing, which corrects the problem for this
test case. We'll see how it does on regressions.
Index: gcc/gimple-ssa-strength-reduction.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
The following patch seems to fix it ...
... but unfortunately ICEs on a number of tests, e.g. class_{13,18,33,34} and
others.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||hjl.tools at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57996
Bug ID: 57996
Summary: Fold more standard complex functions
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #4 from janus at gcc dot gnu.org ---
Here is an enhanced patch which regtests cleanly:
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954
--- Comment #3 from Evgeniy Dushistov dushistov at mail dot ru ---
Great, I tested the patch, at now pi calculation as fast as in icc, and two
times faster then in clang 3.3.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Attachment #30560|0 |1
is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42955
Brooks Moses brooks at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed|2010-04-22 20:17:36 |2013-07-26
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
There are no errno issues - this is an exact zero result, not underflow.
But I'm not confident that MPFR follows all the Annex F special cases for
infinities
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997
Bug ID: 57997
Summary: Segmentation fault after returning valarray expression
from an auto function
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC||gdr at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997
--- Comment #2 from Gabriel Dos Reis gdr at gcc dot gnu.org ---
(In reply to Paolo Carlini from comment #1)
Gaby, can you help me with this?
I think this is typical confusion about what valarray expressions are.
f1() has some complicated return
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997
--- Comment #3 from Gabriel Dos Reis gdr at gcc dot gnu.org ---
Also, there might be some interactions with move semantics; I don't know.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57998
Bug ID: 57998
Summary: Unhelpful error message when a class has no move
constructor
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: enhancement
On Thu, 25 Jul 2013, Joseph S. Myers wrote:
On Thu, 25 Jul 2013, Marek Polacek wrote:
So far it sanitizes division-by-zeros, shifts and
__builtin_unreachable calls. This is of course far from being
complete; I intend to write more features during this 4.9 stage.
Such as everything needed
Hello!
The (static arg) generator functions are casted to a var arg
function pointer, making the assumption that the ABI for passing
the arguments will be the same as for static arguments.
This isn't a valid assumption on all architectures, var args might for
example be passed on the stack,
On Fri, Jul 26, 2013 at 10:08 AM, Stefan Kristiansson
stefan.kristians...@saunalahti.fi wrote:
On Fri, Jul 26, 2013 at 08:51:41AM +0200, Uros Bizjak wrote:
Stefan, can you resubmit an updated patch (with proposed update from [1])?
I would really like to see this patch in the mainline.
On 23 July 2013 13:35, Ian Bolton ian.bol...@arm.com wrote:
2013-07-23 Ian Bolton ian.bol...@arm.com
gcc/
* config/aarch64/aarch64-simd.md (negmode2): Offer alternative
that uses vector r
Cheers,
Ian
OK
/Marcus
Hi,
I'm adding the testcase and keeping the PR open (the issue seems still
present in 4_8-branch).
Thanks,
Paolo.
//
2013-07-26 Paolo Carlini paolo.carl...@oracle.com
PR c++/57101
* g++.dg/cpp0x/pr57101.C: New.
Index: g++.dg/cpp0x/pr57101.C
Hi,
This patch changes to skip gcc.dg/lower-subreg-1.c for aarch64*-*-*.
The word mode in aarch64 is 64-bit so the lower-subreg pass won't happen
in this test case. The test is currently skipped on aarch64 with lp64
due to the directive of dg-require-effective-target ilp32, but fails
when
Fixed and committed, but I have a small follow-up related to parameter
packs in requires clauses. The checking for unexpanded parameter packs
treats the parameter declarations like regular PARM_DECL references
and gives errors that they are unexpanded packs.
2013-07-26 Andrew Sutton
On Thu, Jul 25, 2013 at 10:33:46PM -0700, Andrew Pinski wrote:
What does it mean by unsigned-integer-overflow? Unsigned integers
never overflow.
Or maybe I misread the documentation here.
Well, clang can sanitize even when unsigned int wraps. But this
feature seems doubtful, I don't think I
This patch implements a new trait __is_same_as. This is foundational
for future work on concepts in that it provides a mechanism for
reasoning about type equivalences.
It also provides the correct preconditions for __is_convertible_to as
required in meta.rel.
2013-07-26 Andrew Sutton
Hi,
On 07/26/2013 02:11 PM, Andrew Sutton wrote:
This patch implements a new trait __is_same_as. This is foundational
for future work on concepts in that it provides a mechanism for
reasoning about type equivalences.
Isn't the name a little misleading? I immediately wondered what was
wrong
Maxim, thank you for your input! That's for sure a better solution.
__BIONIC__ is not defined in features.h so I had to change the include
to ctype.h. (__BIONIC__ is defined in sys/ctypes.h, but it's not safe
to include that directly..)
tested on x86_64_unknow_linux and on android device.
Is it
Isn't the name a little misleading? I immediately wondered what was wrong
with std::is_same. IMHO something a little longer/technical clarifying that
the trait isn't just about comparing types is in order...
Sure.
First, it means we don't have to instantiate any class templates in
order to
Hi,
On 07/26/2013 03:23 PM, Andrew Sutton wrote:
Isn't the name a little misleading? I immediately wondered what was wrong
with std::is_same. IMHO something a little longer/technical clarifying that
the trait isn't just about comparing types is in order...
Sure.
First, it means we don't have
Joseph == Joseph S Myers jos...@codesourcery.com writes:
Joseph We have a reliable reproducer for the bug, at least in the form
Joseph in which it appeared with the old patch:
Joseph http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01663.html - even
Joseph though it was never clear exactly what the
Thanks a lot. Now I'm afraid that some of these nice clarifications,
delicate technical details included, may get lost. Do you think they exist
already in some of your design documents, papers, etc. Then a reference in
the code would do. Otherwise, please consider adding some of the above to
Hi all,
The minmaxsi_minus.c test in gcc.target/arm/ was added to confirm that we
generate two conditional subtractions instead of two conditional moves and an
unconditional subtraction. It tests that by scanning for two conditional rsb
instructions. But now, the arm backend generates sub
On 26/07/13 15:44, Kyrylo Tkachov wrote:
Hi all,
The minmaxsi_minus.c test in gcc.target/arm/ was added to confirm that we
generate two conditional subtractions instead of two conditional moves and an
unconditional subtraction. It tests that by scanning for two conditional rsb
instructions. But
The following patch series eliminates the mutable global variables
representing GCC's passes, allowing for multiple compilation contexts in
one process, potentially with different combinations of passes
(e.g. JIT-compilation of JavaScript in one thread, JIT-compilation
of OpenGL shader programs in
This is the automated part of the conversion of passes from C structs to
C++ classes.
It is generated by the refactor_passes.py script in
https://github.com/davidmalcolm/gcc-refactoring-scripts
The script has its own test suite: test_refactor_passes.py, and you can
get an idea of the behavior of
This patch introduces a gcc::pipeline class and moves various non-GTY
globals relating to pass management into it. The gcc::context gains its
first field: a pointer to the gcc::pipeline instance.
It was previously sent as:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01090.html
as part of:
With the conversion of passes to C++ classes, plugins that add custom
passes must create them by creating their own derived classes of the
relevant subclass of opt_pass. gcc itself is built with -fno-rtti,
hence there is no RTTI available for the opt_pass class hierarchy.
Hence plugins that
This patch is the hand-written part of the conversion of passes from
C structs to C++ classes. It does not work without the subsequent
autogenerated part, which is huge.
Given that the autogenerated part of the conversion is very large
(500k), for the sake of human comprehension I have kept the
gcc/
Rewrite how instances of passes are cloned to remove assumptions
about their sizes (thus allowing pass subclasses to have
additional data fields, albeit non-GC-managed ones at this point).
* passes.c (make_pass_instance): Now that passes have clone
This is an example of converting the gate and execute functions of
a pass into C++ virtual functions, so that in the next patch we can move
a variable into member data of the opt_pass subclass.
gcc/testsuite/
* gcc.dg/plugin/one_time_plugin.c: (one_pass_gate): convert
to member
gcc/testsuite/
Example of converting global state to per-pass state.
* gcc.dg/plugin/one_time_plugin.c (one_pass::execute): Convert
global state static int counter to...
(one_pass::counter): ...this instance data.
---
gcc/testsuite/gcc.dg/plugin/one_time_plugin.c
This patch makes gcc::context instances be allocated within the GC-heap,
and adds traversal hooks for GC/PCH so that a gcc::context can own refs
to other GC-allocated objects.
gcc/
* Makefile.in (GTFILES): Add context.h.
* context.c (gcc::context::operator new): New.
This patch adds enough special-casing to gengtype to allow it to cope
with types that are within the gcc namespace.
gcc/
* gengtype.c (type_for_name): Add special-case support for
locating types within the gcc:: namespace.
(open_base_files): Emit a using namespace gcc
This patch makes gcc::pipeline and opt_pass instances be allocated
within the GC-heap, and adds traversal hooks for GC/PCH, so that passes
can own refs to other GC-allocated objects.
gcc/
Make opt_pass and gcc::pipeline be GC-managed, so that pass
instances can own GC refs.
Introduce a new gen-pass-instances.awk script, and use it at build time
to make a pass-instances.def from passes.def.
An example of the result can be seen at:
http://dmalcolm.fedorapeople.org/gcc/2013-07-25/pass-instances.def
The generated pass-instances.def contains similar content to
Introduce a new gen-pass-instances.awk script, and use it at build time
to make a pass-instances.def from passes.def.
An example of the result can be seen at:
http://dmalcolm.fedorapeople.org/gcc/2013-07-25/pass-instances.def
The generated pass-instances.def contains similar content to
Quoting Richard Guenther richard.guent...@gmail.com:
On Sun, Sep 25, 2011 at 2:36 PM, Joern Rennecke amyl...@spamcop.net wrote:
This patch has not been reviewed for eight weeks.
- Forwarded message from amyl...@spamcop.net -
Date: Mon, 01 Aug 2011 01:01:13 -0400
From: Joern
Tom Good idea. I'll dig up make 3.81 and give it a try soon, if not
Tom tomorrow, then early next week.
I did this today.
I downloaded and built GNU make 3.81 and put it in my PATH.
Then I did make -j2 builds in the gcc directory of each revision.
I also ran touch Makefile.in and then make -j2
This patch is for the google/gcc-4_8 branch. I will also submit this
to trunk separately.
This fixes a problem with -fdebug-types-section where some types that
have contain nested type templates or member function templates are
given different type signatures in different compilation units,
Ok for google branches. Many changes in coverage.c (such as
get_coverage_counts) and value-prof.c need to be in trunk too.
David
On Thu, Jul 25, 2013 at 10:02 AM, Teresa Johnson tejohn...@google.com wrote:
This patch ports the remaining -fopt-info messages that had been added
to google/gcc-4_7
Thanks. I'll work on a trunk patch to send next week. Teresa
On Fri, Jul 26, 2013 at 10:05 AM, Xinliang David Li davi...@google.com wrote:
Ok for google branches. Many changes in coverage.c (such as
get_coverage_counts) and value-prof.c need to be in trunk too.
David
On Thu, Jul 25, 2013 at
1 - 100 of 133 matches
Mail list logo
