On Thu, 5 Jan 2012, Steven Bosscher wrote:
> On Thu, Jan 5, 2012 at 4:01 PM, Richard Guenther wrote:
> > Index: gcc/tree-streamer-out.c
> > ===
> > --- gcc/tree-streamer-out.c (revision 182908)
> > +++ gcc/tree-streamer-out.c
GCC's implementation of is not valid for C++11 because
[support.runtime] p8 says "The header and the header
shall not define macros named bool, true, or false."
This patch adds a libstdc++ test for that requirement and adjusts
stdbool.h to meet it. I've left _Bool defined in C++ as a GNU
extens
What is missing to get this ported back to the GCC 4.6 branch? Btw. what is
this ARM/embedded-4_6-branch for a branch? It seems to be more actively
maintained.
On 12/21/2011 09:10 AM, Sebastian Huber wrote:
Would someone mind committing this to the 4.6 branch. Thanks.
The test suite results
Hello,
Attached is the updated version of the patch.
Passed the bootstrap and gcc testsuite.
Thanks,
Dehao
Index: gcc/testsuite/gcc.dg/predict-3.c
===
--- gcc/testsuite/gcc.dg/predict-3.c(revision 0)
+++ gcc/testsuite/gcc.dg/pr
On 01/06/12 08:34:52, Tom Tromey wrote:
> The patch is ok with either that change or with those 2 lines removed.
Applied as svn version 183003.
Since GCC 4.4 applying the malloc attribute to realloc-like
functions does not work under the documented constraints because
the contents of the memory pointed to are not properly transfered
from the realloc argument (or treated as pointing to anything,
like 4.3 behaved).
The following adjusts do
Status
==
Stage 3 is now officially over, after a bit more than two months.
The GCC trunk is now in regression and documentation fixes only
state (so-called stage4). The trunk will remain in this state
until it is sufficiently stable for release. At this point we
will create the 4.7 branch
On Fri, Jan 6, 2012 at 6:05 PM, Aldy Hernandez wrote:
> On 01/05/12 09:36, Richard Guenther wrote:
>>
>> On Thu, Jan 5, 2012 at 3:48 PM, Aldy Hernandez wrote:
>>>
>>> As you suggested here:
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00232.html
>>>
>>> Bootregged on x86-64 Linux.
>>>
>>>
On Fri, Jan 6, 2012 at 7:17 PM, Eric Botcazou wrote:
>> > OK, I see. Then the only way out I can think of is to stop going up the
>> > chain of COMPONENT_REFs as soon as the offset becomes negative.
>>
>> Yeah, that sounds like a better solution.
>
> PR ada/51775 shows that this pessimizes though
> All EH-related tests fail with a recent upgrade on Solaris 10. Interestingly,
> the old implementation keeps working with the upgrade.
I've applied the attached patch to mainline and 4.6 branch. It reverts back to
the old pattern matching code in the Solaris 8+ multi-threaded case, which is
c
On Sun, Jan 8, 2012 at 12:38 AM, Jan Hubicka wrote:
> Hi,
> this patch fixes first half of the PR. The PR is about a function that is
> supposed
> to be inlined at -O2. The function contains two calls, one indirect and
> inlining
> the indirect call makes things a lot better. GCC however thing
I've just seen Richard's status email, so I guess this should wait for 4.8
On 9 January 2012 08:48, Jonathan Wakely wrote:
> GCC's implementation of is not valid for C++11 because
> [support.runtime] p8 says "The header and the header
> shall not define macros named bool, true, or false."
>
> T
Dear all,
this email contains a updated patch, which replaces the FIXME by an
implementation. See below.
Dear Dominique,
On 01/08/2012 11:13 PM, Dominique Dhumieres wrote:
Your patch passed my tests and in top of that fixes the ICE for pr51522.f90.
:-)
However I don't understand the erro
The issue was discovered when looking at the optional + elemental +
scalarizer issue (PR 50981, 4.4-4.7 regression). However, the example of
this PR never worked. Passing null() to denote an absent argument (for
nonallocatable/nonpointer dummies) is a Fortran 2008 / GCC 4.6 feature.
Build and
> Can you get me a testcase that I can compile? This should be fixed in FRE.
This is gnat.dg/pack9.ad[sb]. You need a bare cross-compiler to s390x-linux:
configure, build with make CFLAGS=-g, when the build fails, do gcc/ada then
make gnatlib. Go back to the build dir, copy gnat.dg/pack9.ad[s
On 17/12/2011 11:07, Eric Botcazou wrote:
>> I am happily using this patch and await this to be committed.
>
> Only after the import library issue is addressed. What do the other
> libraries
> bundled with GCC do here?
Sorry for the delay guys, I got rather busy over the holidays. I see we'
>
> That surely should be MAX_INLINE_INSNS_AUTO instead. At _least_.
> You are triggering very much more inlining during early inlining now -
> I don't see
> where we did this for -Os already as you claim. In fact it is totally
> against the spirit of early inlining now :(
This is IPA inlining,
On 01/09/2012 10:02 AM, Gary Funck wrote:
On 01/06/12 08:34:52, Tom Tromey wrote:
The patch is ok with either that change or with those 2 lines removed.
Applied as svn version 183003.
I get the build failure:
libcpp/macro.c:220:26: error: variable 'map' set but not used
[-Werror=unused-but
On 17/12/2011 10:06, Christian Joensson wrote:
> I can add that I also, manually, copy the
> lto-plugin/.libs/cyglto_plugin-0.dll into $bindir too.
Why? It deliberately installs into libexecsubdir rather than bindir because
it's only ever invoked by the gcc driver, which passes the full explic
On Mon, Jan 9, 2012 at 11:33 AM, Eric Botcazou wrote:
>> Can you get me a testcase that I can compile? This should be fixed in FRE.
>
> This is gnat.dg/pack9.ad[sb]. You need a bare cross-compiler to s390x-linux:
> configure, build with make CFLAGS=-g, when the build fails, do gcc/ada then
> mak
On Mon, Jan 9, 2012 at 12:07 PM, Jan Hubicka wrote:
>>
>> That surely should be MAX_INLINE_INSNS_AUTO instead. At _least_.
>> You are triggering very much more inlining during early inlining now -
>> I don't see
>> where we did this for -Os already as you claim. In fact it is totally
>> against
> Hmm, it seems to be because we do not value-number loads that
> satisfy stmt_could_throw_p (for whatever reason ...). Seems to date
> back to rev. 131610, the fix for PR34648. Looking at that bug it
> seems that we could at least allow stmts that only throw externally
> (but generally CSE shoul
On Mon, Jan 9, 2012 at 12:02, Tobias Burnus wrote:
> Dear all,
>
> this email contains a updated patch, which replaces the FIXME by an
> implementation. See below.
>
>
> Dear Dominique,
>
>
> On 01/08/2012 11:13 PM, Dominique Dhumieres wrote:
>>
>> Your patch passed my tests and in top of that fix
> Sorry for the delay guys, I got rather busy over the holidays. I see
> we're now discussing a patch for next stage 1.
No, not necessarily, the patch is specific to Ada on Windows so the risk is
quite low.
> It does however solve the problem of wanting the DLL to be in the /bin
> directory
The attached patch tunes the costs of conditional execution and branches
for Cortex-A15 to be the same as that for Cortex-A5.
This gives an average improvement of over 6% on a popular embedded
benchmark.
Note that the tuning parameter structure added for Cortex-A15 is only tuned
for branch costs,
> On Mon, Jan 9, 2012 at 12:07 PM, Jan Hubicka wrote:
> >>
> >> That surely should be MAX_INLINE_INSNS_AUTO instead. At _least_.
> >> You are triggering very much more inlining during early inlining now -
> >> I don't see
> >> where we did this for -Os already as you claim. In fact it is totally
On Mon, Jan 9, 2012 at 12:45 PM, Eric Botcazou wrote:
>> Hmm, it seems to be because we do not value-number loads that
>> satisfy stmt_could_throw_p (for whatever reason ...). Seems to date
>> back to rev. 131610, the fix for PR34648. Looking at that bug it
>> seems that we could at least allow
Hi,
On Sat, 7 Jan 2012, Peter Bergner wrote:
> While digging through ira-color.c tracking down an IRA shuffle copy
> issue, I noticed we only seem to do real copy coalescing for spilled
> pseudos. It seems we rely on coloring to try and assign the same hard
> reg to pseudos connected by a copy
On 12/23/2011 12:46 PM, Richard Sandiford wrote:
> In the end I tried an ad-hoc approach in an attempt to do something
> about (2), (3) and (4b). The idea was to construct a preliminary
> "model" schedule in which the only objective is to keep register
> pressure to a minimum. This schedule ignor
Ping
2012/1/5 Kai Tietz :
> Ping!
>
> 2012/1/2 Paolo Carlini :
>> Hi,
>>
>>> Hello,
>>>
>>> additionally to the suggested patch by Pawel Sikora, I added the
>>> adjustments for mt-allocator to it too.
>>>
>>> ChangeLog
>>>
>>> 2012-01-01 Kai Tietz
>>>
>>> PR libstc++/51673
>>> * con
> I get the build failure: ...
I got the same failure. The following patch
--- ../_clean/libcpp/macro.c2012-01-09 11:15:22.0 +0100
+++ ../work/libcpp/macro.c 2012-01-09 12:28:06.0 +0100
@@ -217,7 +217,7 @@ static const char * const monthnames[] =
const uchar *
_cpp_buil
On 09/01/12 12:01, Matthew Gretton-Dann wrote:
> The attached patch tunes the costs of conditional execution and branches
> for Cortex-A15 to be the same as that for Cortex-A5.
>
> This gives an average improvement of over 6% on a popular embedded
> benchmark.
>
> Note that the tuning parameter s
This fixes PR51775, we do not need to avoid value-numbering for
stmts that can throw. PRE already ensures to not enter anything
into the EXP/TMP_GEN sets for those so it won't ever end up
trying to insert throwing expressions.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richar
On 01/09/12 12:08:22, Tobias Burnus wrote:
> I get the build failure:
>
> libcpp/macro.c:220:26: error: variable 'map' set but not used
> [-Werror=unused-but-set-variable]
Tobias, thanks. Will fix.
- Gary
Committed as obvious.
Richard.
2012-01-09 Richard Guenther
libcpp/
* macro.c (_cpp_builtin_macro_text): Remove unused variable map.
Index: macro.c
===
--- macro.c (revision 183012)
+++ macro.c (working c
Sorry Tobias, I was about to post a patch about this when I saw your
message.
The issue is that the code handling NULL() doesn't consume the gfc_ss
struct created for it. Your fix, which advances to the next one anyway
would work just well, but I think it is slightly cleaner to not create
the
Ok for the trunk? (Build + "make pdf" tested)
Tobias
2012-01-09 Tobias Burnus
* gfortran.texi: Bump copyright year.
(Fortran 2003 Status): Update polymorphism item, add
item for generic interface with DT name.
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index aac2d9
On 01/09/12 06:04:28, Gary Funck wrote:
> On 01/09/12 12:08:22, Tobias Burnus wrote:
> > I get the build failure:
> >
> > libcpp/macro.c:220:26: error: variable 'map' set but not used
> > [-Werror=unused-but-set-variable]
Richard, thanks.
2012-01-09 Richard Guenther
libcpp/
*
On 01/09/2012 03:34 PM, Mikael Morin wrote:
The issue is that the code handling NULL() doesn't consume the gfc_ss
struct created for it. Your fix, which advances to the next one anyway
would work just well, but I think it is slightly cleaner to not create
the struct in the first place, as it is
On 12/30/2011 05:50 PM, Dmitry Melnik wrote:
> If one of branches has significantly greater probability than the other,
> then it may be better to rely on CPU's branch prediction and block
> reordering, than putting rarely executed instructions into the pipeline.
> In this patch we set 10% frequen
Ok with simply excluding SSA_NAMEs like
@@ -4411,16 +4411,27 @@ gimplify_modify_expr_rhs (tree *expr_p,
/* It's OK to use the target directly if it's being
initialized. */
use_target = true;
- else if (TREE_CODE (*to_p) != SSA_NAME
"make pdf" fails with:
libiberty/copying-lib.texi:481: This command can
appear only outside of any environment, not in environment @enumerate.
@badenverr ...temp , not @inenvironment @thisenv }
@checkenv ...@ifx @thisenv @temp @else @badenverr
@
On 12/04/2011 01:27 PM, Richard Sandiford wrote:
> OK, here it is. As well as switching to the backward scan and incremental
> liveness updates, I added a test for another case that I stumbled over:
>
> /* Reject targets of abnormal edges. This is needed for correctness
> on ports like A
Hi Georg.
I have found that conversion AVR port to using hard_frame_pointer have
resolved PR 50925 .
I have tested the patch without regressions, but I'm worry about it.
Can you test it with your testsuite for regressions ?
May be you have your own special difficult tests (special for addressing)
We have two Graphite related release blockers for 4.7. The
following patch fixes the first one.
The asserts in
static inline ppl_dimension_type
psct_dynamic_dim (poly_bb_p pbb, graphite_dim_t level)
{
graphite_dim_t result = 1 + 2 * level;
gcc_assert (result < pbb_nb_scattering_transform (
On Mon, Jan 09, 2012 at 03:38:21PM +0100, Tobias Burnus wrote:
> Ok for the trunk? (Build + "make pdf" tested)
>
> Tobias
The two "which" clauses in the 1st sentence seem awkward. How
about the following changes? OK, after considering the suggested
changes.
+@item Generic interface name which
This fixes the 2nd P1 ICE.
There is a disconnect on how we analyze data-references during SCOP
detection
(outermost_loop is the root of the loop tree) and during SESE-to-poly
where
outermost is determined by outermost_loop_in_sese_1 (). That influences
the SCEV result and thus we do not break
On Mon, Jan 9, 2012 at 3:57 PM, Aldy Hernandez wrote:
>
>> Ok with simply excluding SSA_NAMEs like
>>
>> @@ -4411,16 +4411,27 @@ gimplify_modify_expr_rhs (tree *expr_p,
>> /* It's OK to use the target directly if it's being
>> initialized. */
>> use_
Richard Henderson writes:
> On 01/04/2012 11:27 PM, Rainer Orth wrote:
>> [libgfortran, libitm] Link with -shared-libgcc
>> http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01382.html
>>
>> This will need a fortran resp. libitm maintainer.
>
> Does the following alleviate the need for -sha
The following patch has remained unreviewed for almost a month now,
despite two reminders:
[libffi] Build 64-bit multilib for i?86-linux
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01011.html
In the absence of a listed libffi maintainer (Anthony Green used to be
listed in MAINTAI
On 01/09/2012 04:09 PM, Rainer Orth wrote:
> In the absence of a listed libffi maintainer (Anthony Green used to be
> listed in MAINTAINERS, but isn't anymore despite still taking care of
> upstream libffi), it probably needs a global reviewer.
Sorry, I usually do it but missed this one. It's fin
While the combination of Sun as with GNU ld isn't a recommended
configuration on Solaris, it used to work half a year ago, but doesn't
right now: stage 1 libgomp fails to link:
/vol/gcc/bin/gld-2.22: .libs/team.o: unrecognized relocation (0xc) in section
`.text'
/vol/gcc/bin/gld-2.22: final link
On 01/09/2012 05:14 PM, Rainer Orth wrote:
While the combination of Sun as with GNU ld isn't a recommended
configuration on Solaris, it used to work half a year ago, but doesn't
right now: stage 1 libgomp fails to link:
/vol/gcc/bin/gld-2.22: .libs/team.o: unrecognized relocation (0xc) in sectio
On 01/02/2012 01:19 PM, Torvald Riegel wrote:
On Tue, 2011-12-20 at 01:13 +0100, Torvald Riegel wrote:
On Mon, 2011-12-19 at 15:17 -0800, Richard Henderson wrote:
On 12/19/2011 02:58 PM, Torvald Riegel wrote:
In the particular case (the validated loads technique used in
method-gl.cc, load(), s
On 9 January 2012 08:49, Sebastian Huber
wrote:
> What is missing to get this ported back to the GCC 4.6 branch?
I ran a sanity check again today and backported them to the 4.6
branch. Sorry about the delay. I prefer to do the same for the 4.4 and
4.5 branches. If you are happy to test them then
Denis Chertykov wrote:
> Hi Georg.
>
> I have found that conversion AVR port to using hard_frame_pointer have
> resolved PR 50925 .
> I have tested the patch without regressions, but I'm worry about it.
> Can you test it with your testsuite for regressions ?
> May be you have your own special diff
Hello
Even if I'm going to bore everyone.
Is it possible to get an answer from the ARM maintainers?
This is a serious question, and I hope there will be a serious answer.
Regards
Thomas Klein
reference:
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01774.html
Hello!
Attached patch fixes oversight with AND pattern and 0x
immediate. While ANDs with 0xff and 0x are converted to equivalent
zero_extend pattern, AND with 0x isn't. This problem leaves
important optimization that would substitute "movq%rdi, %rax; andl
$4294967295, %e
On the recent Solaris 10 version I have access to (s10_72), the kernel/libc
sometimes calls the call_user_handler routines with a null returned address.
This is responsible for the last ACATS failure (cb1010c). But, in most cases,
the address is the expected one, so it isn't clear if this is a b
> To get the ball rolling for other targets, and to let port maintainers see
> how easy it really is, here's a first cut at a port to ARM.
Do you plan to do something for the SPARC? I'm asking because you still are a
maintainer of this arch as well, so if we can avoid doing the work twice...
--
On 09.01.2012 15:45, Tobias Burnus wrote:
On 01/09/2012 03:34 PM, Mikael Morin wrote:
The issue is that the code handling NULL() doesn't consume the gfc_ss
struct created for it. Your fix, which advances to the next one anyway
would work just well, but I think it is slightly cleaner to not creat
Gerald Pfeifer writes:
> On Wed, 4 Jan 2012, Andrew Pinski wrote:
>> Woops, I had missed that. Here is the patch which adds both octeon+
>> and octeon2 to that list.
>>
>> I committed as obvious after a build.
>
> You may want to update the release notes as well
> (htdocs/gcc-4.7/changes.html).
Hello,
in GCC 4.6, gfortran printed before the backtrace, e.g.,
Program received signal 8 (SIGFPE): Floating-point exception.
to STDERR followed by the backtrace.
This was done by registering an error handler and - finishing with a
sys_exit(5). Since 4.7 with the patch for PR 48915 (comment 3
Is it ok to make this update to the web page? Someone has to approve
this change,
even though it is GUPC specific.
Nenad
? A
Index: htdocs/projects/gupc.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/gupc.html,v
retrieving revi
This very likely has no consequence in release mode, but you can get ICES with
tree checking enabled in some perculiar cases and on some platforms.
Tested on i586-suse-linux, applied on the mainline, 4.6 and 4.5 branches.
2012-01-09 Eric Botcazou
* gcc-interface/trans.c (addressable
Eric Botcazou writes:
> On the recent Solaris 10 version I have access to (s10_72), the kernel/libc
s10_72 is anything but recent: this is a Solaris 10 Express/Beta build
which even predates Solaris 10 FCS (s10_74L2a), so this is ancient
history by now. I suggest not caring about anything pre-
On Mon, Jan 09, 2012 at 08:21:31PM +0100, Tobias Burnus wrote:
>
> With the patch, one can get (cf. PR) an output to STDERR like:
>
> Program received signal 8 (SIGFPE): Floating-point exception.
>
> Backtrace for this error:
> #0 0x805891F in _gfortrani_show_backtrace at backtrace.c:261
> #1
Tom de Vries writes:
> 2012-01-08 Tom de Vries
> Andrew Pinski
>
> * reorg.c (fill_slots_from_thread): Don't speculate frame-related insns.
OK, thanks.
Richard
Dear All,
Committed as r183032.
Thanks
Paul
On Sun, Jan 8, 2012 at 10:32 PM, Tobias Burnus wrote:
> Dear Paul,
>
> Paul Richard Thomas:
>
>> A question for the standard aficianados: Are there other base object
>> expressions that are legal?
>
>
> I don't think so. (Ignoring RESHAPE, SPREAD etc
On Mon, Jan 9, 2012 at 21:21, Tobias Burnus wrote:
> Hello,
>
> in GCC 4.6, gfortran printed before the backtrace, e.g.,
> Program received signal 8 (SIGFPE): Floating-point exception.
> to STDERR followed by the backtrace.
>
> This was done by registering an error handler and - finishing with a
This patch extends the semantics of 24-bit __pgmx address space qualifier to
cover RAM and Flash.
RAM is represented by setting the high byte of 24-bit address to 0x80. The code
to read from 24-bit address space decides at runtime what instruction to use to
read by if-else decision depending on bi
This is a regression present on the mainline. It occurs only when the return
value is assigned to an array with fixed size (this is possible with subtypes
of the same unconstrained array type).
Tested on i586-suse-linux, applied on the mainline.
2012-01-09 Eric Botcazou
* gcc-inte
I was recently trying to turn on some of the debug options I put in when doing
the initial power7 work to track down some performance regressions. The
following patches fix problems that come up in telling the compiler to use the
traditional floating point insns for scalar mode on power7
(-mno-vsx
As requested by Jason, I've added -Wabi to the libstdc++ build flags.
The patch is trivial. The results are in line with what we expect.
After I did this part and verified the build went swimmingly, I ran the
testsuite with -Wabi as well. This part had some problems, I'm getting
some odd results
Certain source files will not produce a .debug_info section. This patch to
google/main adds a check for that case to output_pubnames, preventing a link
failure.
Tested:
By rebuild and bootstrap.
ChangeLog:
2012-01-09 Sterling Augustine
* gcc/dwarf2out.c (output_pubnames): Ad
Hi, all, it's been a long time, I've slightly modified my code -
TREE_ADDRESSABLE is only applied when TREE_CODE is VAR_DECL, and it's
combined with test for arrays/struct-union-contain-array, which makes
the code a little bit cleaner.
Comments, approvals? Thanks!
= Patch starts ==
diff -
On 01/09/2012 04:31 PM, Richard Guenther wrote:
We have two Graphite related release blockers for 4.7. The
following patch fixes the first one.
Hi Richard,
thanks a lot for working on this.
The asserts in
static inline ppl_dimension_type
psct_dynamic_dim (poly_bb_p pbb, graphite_dim_t lev
Dear Janne,
- The integer values for the signal numbers are not standardized,
hence printing them might give the user a false impression that these
numbers convey some information beyond whichever SIG* macro they map
to on that particular target.
- It doesn't test all the signals which are actu
Correct libstdc++ naming convention to be the same as used by the other
html tarballs, ie library-html.tar.bz2.
I just checked this in as I was fixing the recent gcc mailing list
report of broken links.
-benjamin2012-01-09 Benjamin Kosnik
* onlinedocs/index.html: Use same naming con
On 01/09/2012 04:34 PM, Richard Guenther wrote:
This fixes the 2nd P1 ICE.
There is a disconnect on how we analyze data-references during SCOP
detection
(outermost_loop is the root of the loop tree) and during SESE-to-poly
where
outermost is determined by outermost_loop_in_sese_1 (). That infl
> Certain source files will not produce a .debug_info section. This patch to
> google/main adds a check for that case to output_pubnames, preventing a link
> failure.
>
> Tested:
> By rebuild and bootstrap.
>
> ChangeLog:
>
> 2012-01-09 Sterling Augustine
>
> * gcc/dwarf2out.c (ou
On Mon, 9 Jan 2012, Nenad Vukicevic wrote:
> Is it ok to make this update to the web page? Someone has to approve
> this change, even though it is GUPC specific.
Yes, and no. ;-) This patch is okay, and I suggest you consider
yourself maintainer of this page and change it as you see fit (just
po
Dear all,
I have committed that attached test case as Rev. 183039.
The test case is the one of PR 46328, comment 2. The failure was solved
by Paul's patch for PR 51791.
Tobias
Index: gcc/testsuite/gfortran.dg/typebound_operator_11.f90
==
It looks non-ambiguous to me.
David
On Mon, Jan 9, 2012 at 1:05 AM, Richard Guenther wrote:
>
> Since GCC 4.4 applying the malloc attribute to realloc-like
> functions does not work under the documented constraints because
> the contents of the memory pointed to are not properly transfered
> fro
This is ok, but I realized that some of the newer CXXABI symbols were
missing, so I added them as well and then checked all of this in. See
attached patch.
best,
Benjamin
2012-01-09 Kai Tietz
PR libstc++/51673 part 2
* config/abi/pre/gnu-versioned-namespace.ver: Adjusted new/delete
operato
On Mon, Jan 9, 2012 at 4:30 PM, Michael Meissner
wrote:
> I was recently trying to turn on some of the debug options I put in when doing
> the initial power7 work to track down some performance regressions. The
> following patches fix problems that come up in telling the compiler to use the
> tra
On 01/10/2012 05:52 AM, Eric Botcazou wrote:
>> To get the ball rolling for other targets, and to let port maintainers see
>> how easy it really is, here's a first cut at a port to ARM.
>
> Do you plan to do something for the SPARC? I'm asking because you still are
> a
> maintainer of this arch
On 01/08/2012 11:50 PM, Tom de Vries wrote:
> * dwarf2cfi.c (scan_trace): Save and restore cur_row->reg_save when
> handling annulled branch.
Ok.
r~
On 01/10/2012 03:06 AM, Rainer Orth wrote:
> Richard Henderson writes:
>
>> On 01/04/2012 11:27 PM, Rainer Orth wrote:
>>> [libgfortran, libitm] Link with -shared-libgcc
>>> http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01382.html
>>>
>>> This will need a fortran resp. libitm maintainer.
>
On 01/09/2012 06:26 AM, Torvald Riegel wrote:
> libitm: Filter out undo writes that overlap with the libitm stack.
>
> libitm/
> * config/generic/tls.h (GTM::mask_stack_top,
> GTM::mask_stack_bottom): New.
> * local.cc (gtm_undolog::rollback): Filter out any updates
On 01/07/2012 05:47 AM, Aldy Hernandez wrote:
> Patrick Marlier
> PR middle-end/51516
> * trans-mem.c (get_cg_data): Traverse aliases if requested.
> (ipa_tm_scan_calls_block): Update parameters to get_cg_data.
> (ipa_tm_note_irrevocable): Same.
> (ipa_tm_s
Hi all,
that's a follow up to my review comment for
http://gcc.gnu.org/ml/fortran/2012-01/msg00077.html
As stated, I think "in intrinsic assignment" makes the error message
clearer and correcter.
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
PS: Other pending patches:
* ht
On Tue, Jan 10, 2012 at 00:33, Tobias Burnus wrote:
> Dear Janne,
>
>
>> - The integer values for the signal numbers are not standardized,
>> hence printing them might give the user a false impression that these
>> numbers convey some information beyond whichever SIG* macro they map
>> to on that
> I have no immediate plans. If you have time to knock something
> together for Sparc, that would be fantastic.
OK, will try, thanks.
--
Eric Botcazou
2012/1/10 Georg-Johann Lay :
> This patch extends the semantics of 24-bit __pgmx address space qualifier to
> cover RAM and Flash.
>
> RAM is represented by setting the high byte of 24-bit address to 0x80. The
> code
> to read from 24-bit address space decides at runtime what instruction to use
>
95 matches
Mail list logo
