On Thu, 19 Dec 2013, DJ Delorie wrote:
Where is the right place to set the array of this __intN mode is
enabled flags? I initially set it in tree.c where __int128 is set
up, but that happens *after* c_parse_init() needs the flag to set up
the RID_* keywords for them.
Maybe immediately after
Status
==
The trunk remains in Stage 3 until the end of January at which
point we enter regression-and-doc-fixes-only mode.
Quality is improving slowly as we are still getting a lot of
new regressions, both due to increased testing and still merging
a lot of code (please slow down and
Stop banning this sender. Since we want to clean up spam in GCC mailing list.
If you want to restore your Mozilla Bugzilla account (seotaewong40),
you want to contact Mozilla Bugzilla.
You want to add posting permissions to wine-devel mailing list for
seotaewong40 gmail com mail address.
Hey all, this thread started on the libstdc++ list where I asked a
couple of questions about patching std::string for C++11 compliance. I
have figured how to do that and it yields a library that only works in
the C++11 mode. This is not an issue here as we deploy a versioned
runtime into a
==
GNU Tools Cauldron 2014
http://gcc.gnu.org/wiki/cauldron2014
Call for Abstracts and Participation
18-20 July 2014
Cambridge, England
This seems mostly plausible, though I don't see anything to ensure that
__intN does not exist at all if the size matches one of the standard C
types, or if the mode fails targetm.scalar_mode_supported_p.
What do we check against for this? Is there some table of standard
types we can read
On Fri, 20 Dec 2013, DJ Delorie wrote:
This seems mostly plausible, though I don't see anything to ensure that
__intN does not exist at all if the size matches one of the standard C
types, or if the mode fails targetm.scalar_mode_supported_p.
What do we check against for this? Is
I think using the macros for type sizes is fine, and float / vector /
complex types are completely irrelevant to this (so standard_type_bitsize
should maybe be standard_integer_type_bitsize).
Whew. Am I missing any in the previous code snippet (char, short,
int, long, long long) ? Those
On Fri, 20 Dec 2013, DJ Delorie wrote:
I think using the macros for type sizes is fine, and float / vector /
complex types are completely irrelevant to this (so standard_type_bitsize
should maybe be standard_integer_type_bitsize).
Whew. Am I missing any in the previous code snippet
Ok, so I've got it checking for existing types and checking the target
for supported modes. Any other features, or is it time for a second
patch? Should I cut out the __int128 parts yet, or do you just want
to see the new code still?
To-Do: C++ parser, C++ mangling. Still no idea what to do
On Fri, 20 Dec 2013, DJ Delorie wrote:
Ok, so I've got it checking for existing types and checking the target
for supported modes. Any other features, or is it time for a second
patch? Should I cut out the __int128 parts yet, or do you just want
to see the new code still?
I think a patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904
--- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #11)
With the patch in comment 9, gfortran.dg/class_48.f90 no longer fails and I
don't see any regression. The warning for the test in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59545
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Markus Trippelsdorf from comment #5)
Thanks Jakub, it looks much better now. What is left are mostly left shifts
of negative values:
gcc/combine.c:11865:14: runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56811
--- Comment #9 from __vic d.v.a at ngs dot ru ---
Is there any progress and/or solid plan? The last available version of G++ for
HP-UX is 4.7.1 (here
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59541
--- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Note that on x86_64-apple-darwin10 the test
gcc.dg/tree-prof/cold_partition_label.c has started to fail (compilation,
-fprofile-use -D_PROFILE_USE) between r204856 (OK) and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59545
--- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #6)
(In reply to Markus Trippelsdorf from comment #5)
gcc/cselib.c:1121:43: runtime error: signed integer overflow: 4224 +
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59510
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59520
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904
--- Comment #13 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Jakub Jelinek from comment #12)
But you can always create testcases (in C/C++ etc.) that will hit this
warning, so while the FE change is possible, we need to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59566
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59565
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #5 from bin.cheng amker.cheng at gmail dot com ---
For the offending loop:
bb 5:
bb 6:
# b.4_30 = PHI b.4_12(5), 1(12)
# prephitmp_28 = PHI c.1_9(5), c.1_21(12)
# b_lsm.11_13 = PHI b.4_12(5), 1(12)
# ivtmp_46 = PHI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59564
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59545
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=59541
--- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr ---
could someone please point me at the original post for this patch?
I have the same question.
I have finally found the answer: final patch at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59413
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
Weird, I still get exactly the same code (except for gcc version string)
between pre-r205884 and post-r205884. So, what exact differences are you
seeing on the testcase, and with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59566
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59567
Bug ID: 59567
Summary: Incorrect error 'was not declared in this scope'
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59567
Jascha Wetzel jascha at jawset dot com changed:
What|Removed |Added
Attachment #31486|0 |1
is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59567
Jascha Wetzel jascha at jawset dot com changed:
What|Removed |Added
Attachment #31488|compile simply with g++|reproducer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59413
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=59413
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org ---
Ah, my fault then, terribly sorry, I've simplified the testcase a little bit
(removed the typedef and used unsigned int instead). Apparently for the
reproduction it is important that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59520
--- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Fri, 20 Dec 2013, su at cs dot ucdavis.edu wrote:
In particular, are the following well-defined according the standard or they
have undefined behavior?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59413
--- Comment #9 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to H.J. Lu from comment #5)
It is fixed by r205884. We can add the testcase and close it.
FWIW, it is also introduced by r204516.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59413
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Fri Dec 20 13:07:10 2013
New Revision: 206147
URL: http://gcc.gnu.org/viewcvs?rev=206147root=gccview=rev
Log:
PR tree-optimization/59413
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59413
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59494
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
True, I guess adding -mtune=generic doesn't hurt though, it will be still
broken with --target_board=unix/-mtune=core2 or similar testing, but at least
it will FAIL less often. For
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59544
--- Comment #1 from meibf at gcc dot gnu.org ---
Author: meibf
Date: Fri Dec 20 13:46:01 2013
New Revision: 206148
URL: http://gcc.gnu.org/viewcvs?rev=206148root=gccview=rev
Log:
2013-12-20 Bingfeng Mei b...@broadcom.com
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59315
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Target|*-*-solaris2.* |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59471
--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org ---
Testing
Index: gimplify.c
===
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59520
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59494
--- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr ---
I believe that is the only reason for the different number of vector
additions.
I don't think the number of packed double operations is changed, only the
number of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59566
--- Comment #3 from gdlxn at us dot ibm.com ---
Richard and Jakub - Thanks for the quick response and explanation. I was able
to use the -nostdinc option to suppress the automatic inclusion of
stdc-predef.h, which eliminates the unwanted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59567
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59255
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Fri Dec 20 16:32:21 2013
New Revision: 206152
URL: http://gcc.gnu.org/viewcvs?rev=206152root=gccview=rev
Log:
PR c++/59255
* g++.dg/tree-prof/pr59255.C:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59255
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Fri Dec 20 16:34:21 2013
New Revision: 206153
URL: http://gcc.gnu.org/viewcvs?rev=206153root=gccview=rev
Log:
PR c++/59255
Backported from mainline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59255
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54114
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
CC||law at redhat dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59561
--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #1)
Isn't that effectively a duplicate of the P1 regression PR57904?
Might well be, I'm not sure. However, the patch posted in PR 57904 comment 9
does not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009
--- Comment #40 from dave.anglin at bell dot net ---
On 12/19/2013 5:53 PM, John David Anglin wrote:
Rechecking status on the arm box.
Problem is still there:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904
--- Comment #14 from Jeffrey A. Law law at redhat dot com ---
So a quick prototype which reuses the infrastructure from the
phi-only-propagator cleans things up quite nicely.
Given this block after substitute_and_fold does its thing:
bb 2:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56069
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
CC||law at redhat dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904
--- Comment #15 from Dominique d'Humieres dominiq at lps dot ens.fr ---
*** Bug 58746 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58746
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=59568
Bug ID: 59568
Summary: complex type operator does not set eofbit for input
streams.
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904
--- Comment #16 from Dominique d'Humieres dominiq at lps dot ens.fr ---
For the FE change, I guess most important are benchmark results,
doesn't it slow down important benchmarks?
AFAICT the answer is not at least for the gfortran test suite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59568
--- Comment #1 from Physeterm at yahoo dot com ---
Created attachment 31490
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31490action=edit
test program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59568
--- Comment #2 from Physeterm at yahoo dot com ---
Created attachment 31491
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31491action=edit
input test file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59568
--- Comment #3 from Physeterm at yahoo dot com ---
Created attachment 31492
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31492action=edit
output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59568
--- Comment #4 from Physeterm at yahoo dot com ---
Created attachment 31493
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31493action=edit
make command
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59561
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59561
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
CC||jakub at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904
--- Comment #17 from Jeffrey A. Law law at redhat dot com ---
Dominique, thanks for verifying that 58746 is a duplicate. I was wondering
about that.
Richi, we've known for a long time (since the early 90s) that running CSE soon
after loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904
--- Comment #18 from Jeffrey A. Law law at redhat dot com ---
Whoops, message for Richi was meant for a different BZ.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59541
--- Comment #9 from Martin Liška marxin.liska at gmail dot com ---
Hello,
thank you for the hotfix that repaired switch/case missing return value.
Actually I was told by Jan to reproduce the functionality from varasm.c that I
was able to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56069
--- Comment #6 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
(In reply to Jeffrey A. Law from comment #5)
Maybe I'm missing something here. We have this immediately prior to IRA:
ISTM that we want (reg 86) to prefer di and (reg 87)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
--- Comment #27 from janus at gcc dot gnu.org ---
From http://gcc.gnu.org/ml/fortran/2013-12/msg00104.html ...
Currently missing are:
a) Finalization of the LHS during intrinsic assignment:
b) Finalization of functions results after their use
c)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45424
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59541
--- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Hello,
thank you for the hotfix that repaired switch/case missing return value.
Nothing has been committed yet to fix darwin bootstrap!-(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59569
Bug ID: 59569
Summary: [4.9 Regression] r206148 causes internal compiler
error: in vect_create_destination_var, at
tree-vect-data-refs.c:4294
Product: gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59569
--- Comment #1 from H.J. Lu hjl.tools at gmail dot com ---
Created attachment 31494
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31494action=edit
A testcase
[hjl@gnu-mic-2 0001]$
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59569
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59570
Bug ID: 59570
Summary: Warning for semicolon trailing closing curly brackets
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59569
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com ---
254.gap in SPEC CPU 2K is also failed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59571
Bug ID: 59571
Summary: [C++11] ICE when casting inside static member
constexpr brace initializer
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity:
Hello!
index 000..5375b61
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr53623.c
@@ -0,0 +1,25 @@
+/* { dg-do compile { target { x86_64-*-* } } } */
+/* { dg-options -O2 -fdump-rtl-ree } */
Please use:
/* { dg-do compile { target { ! ia32 } } } */
Uros.
On Thu, Dec 19, 2013 at 09:57:36PM -0700, Jeff Law wrote:
* ree.c (combine_set_extension): Handle case where source
and destination registers in an extension insn are different.
(combine_reaching_defs): Allow source and destination
registers in extension to be different
On Thu, Dec 19, 2013 at 10:22:38PM -0700, Jeff Law wrote:
+ *gsi = create_cond_insert_point (gsi, /*before_p=*/true,
+ /*then_more_likely_p=*/false,
+ /*create_then_fallthru_edge=*/true,
+ then_bb,
OK to commit?
Thanks,
Bingfeng
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On
Behalf Of Bingfeng Mei
Sent: 18 December 2013 16:25
To: Jakub Jelinek
Cc: Richard Biener; gcc-patches@gcc.gnu.org
Subject: RE: [PATCH] Vectorization for store
On 11/26/2013 07:45 AM, Chung-Lin Tang wrote:
+(define_insn movhi_internal
+ [(set (match_operand:HI 0 nonimmediate_operand =m, r,r, r,r)
+(match_operand:HI 1 general_operand rM,m,rM,I,J))]
Didn't you say you'd removed the J alternative?
+error (only register based stack
Hello,
there's updated version of the patch.
Tested on x86_64 with enable bootstrap.
Martin
This caused pr59541.
TIA
Dominique
On Thu, Oct 31, 2013 at 09:39:11AM +0100, Jakub Jelinek wrote:
On Thu, Oct 31, 2013 at 09:34:41AM +0100, Bernhard Reutner-Fischer wrote:
The cleanup routine would currently run 7 regexes on the incoming
compiler-flags which is supposedly pretty fast.
But yes, we could as well key off
Date: Fri, 20 Dec 2013 07:57:02 +1030
From: amo...@gmail.com
To: bernd.edlin...@hotmail.de
CC: gcc-patches@gcc.gnu.org; ja...@redhat.com; d...@redhat.com;
ebotca...@adacore.com
Subject: Re: Two build != host fixes
On Thu, Dec 19, 2013 at 11:50:02AM
Ultimately, mklog ought to write the ChangeLog itself.
We get rid of that headache, at least.
How about this then? Updated mklog now adds 'New file'/'New
test'/'Remove' when necessary.
I did some tests with unified/context-diffed SVN and git and it worked
as expected. I can do more testing
On 8 November 2013 17:28, Bruce Korb bk...@gnu.org wrote:
Sure. Looks good to me. Thanks
pushed as r206146
thanks,
On Fri, Nov 8, 2013 at 2:57 AM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
On 4 April 2013 22:20, Bruce Korb bk...@gnu.org wrote:
Except as noted below, fine by
On 13 November 2013 18:56, Jonathan Wakely jwakely@gmail.com wrote:
On 13 November 2013 09:22, Bernhard Reutner-Fischer wrote:
On 11 November 2013 12:30, Jonathan Wakely jwakely@gmail.com wrote:
How does __UCLIBC_SUSV4_LEGACY__ get defined? We'd have a problem if
users defined that at
Hi Martin,
Thanks for working on this!
--- However you have introduced some problems including a bootstrap fail on
darwin.
On 16 Dec 2013, at 10:13, Jan Hubicka wrote:
Hello,
there's updated version of the patch.
Tested on x86_64 with enable bootstrap.
Martin
On 16 December 2013
Ian Lance Taylor wrote:
On Wed, Nov 13, 2013 at 7:30 AM, Gary Benson gben...@redhat.com wrote:
Richard Biener wrote:
On Tue, Nov 12, 2013 at 8:55 PM, Ian Lance Taylor i...@google.com wrote:
On Tue, Nov 12, 2013 at 11:24 AM, Uros Bizjak ubiz...@gmail.com wrote:
This was
Hi!
The bug in this PR has been introduced by my r204516 change and fixed
by r205884 (PR59417) fix.
I've committed the testcase as obvious so that we can close the PR.
2013-12-20 Jakub Jelinek ja...@redhat.com
PR tree-optimization/59413
* gcc.c-torture/execute/pr59413.c: New
On Fri, Dec 20, 2013 at 12:18 AM, Trevor Saunders
trev.saund...@gmail.com wrote:
As discussed in http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02808.html
bootstrap + same regression tests as previous rev, ok?
Ok.
Thanks,
Richard.
2013-12-19 Trevor saunders tsaund...@mozilla.com
gcc/
Hi, all,
There is a problem in nds32.h to determine available register number
for passing BLKmode argument. The original checking only refers to
NDS32_NEED_N_REGS_FOR_ARG macro but that is not sufficient to make
decision of using odd or even register number. It is supposed to
further check the
On Fri, Dec 20, 2013 at 11:09 AM, Bingfeng Mei b...@broadcom.com wrote:
OK to commit?
Ok.
Thanks,
Richard.
Thanks,
Bingfeng
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On
Behalf Of Bingfeng Mei
Sent: 18 December 2013 16:25
To:
On 19/12/13 17:40, Charles Baylis wrote:
On 19 December 2013 16:13, Richard Earnshaw rearn...@arm.com wrote:
OK with that change.
Thanks.
The bugzilla entry is targeted at 4.8, but it is a latent problem
which affects 4.7 too.
Is it ok for 4.8, and should it be considered for 4.7?
On 19/12/13 17:58, Kyrill Tkachov wrote:
On 18/12/13 15:32, Ramana Radhakrishnan wrote:
On Tue, Dec 3, 2013 at 1:46 PM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Ping?
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02351.html
Thanks,
Kyrill
Ok if no objections in 24 hours.
Thanks Ramana,
On Tue, Dec 17, 2013 at 7:48 AM, Teresa Johnson tejohn...@google.com wrote:
On Mon, Dec 16, 2013 at 2:48 PM, Xinliang David Li davi...@google.com wrote:
Ok -- gcov_write_counter and gcov_write_tag_length are qualified as
low level primitives for basic gcov format and probably should be kept
in
We ICEd on invalid testcases with auto, because lookup_conversions
got template_type_parm as a parameter and the TYPE_BINFO didn't like
it. Fixed by checking for RECORD_OR_UNION_TYPE_P first.
Regtested/bootstrapped on x86_64-linux, ok for trunk?
2013-12-20 Marek Polacek pola...@redhat.com
On Fri, Dec 20, 2013 at 5:00 AM, Gary Benson gben...@redhat.com wrote:
--- a/libiberty/ChangeLog
+++ b/libiberty/ChangeLog
@@ -1,3 +1,20 @@
+2013-12-20 Gary Benson gben...@redhat.com
+
+ * cp-demangle.c (struct d_print_info): New fields
+ next_saved_scope, copy_templates,
On 12/17/2013 12:42 PM, Michael V. Zolotukhin wrote:
Hi everybody,
Here is a patch 3/3: Add invocation of target compiler.
+ /* Run objcopy on TARGET_IMAGE_FILE_NAME. */
+ buf1 = (char*) xmalloc (strlen (.data=.)
+ + strlen (OFFLOAD_IMAGE_SECTION_NAME) + 1);
+ if
On 20/12/2013, 07:08 , Yury Gribov wrote:
Ultimately, mklog ought to write the ChangeLog itself.
We get rid of that headache, at least.
How about this then? Updated mklog now adds 'New file'/'New
test'/'Remove' when necessary.
I did some tests with unified/context-diffed SVN and git and it
Hi!
Honza recently changed the i?86 backend, so that it often doesn't
do -maccumulate-outgoing-args by default on x86_64.
Unfortunately, on some of the here included testcases this regressed
quite a bit the generated code. As AVX vectors are used, the dynamic
realignment code needs to assume
1 - 100 of 124 matches
Mail list logo
