http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-24
17:26:48 UTC ---
--- gimplify.c.jj2013-01-11 09:02:55.0 +0100
+++ gimplify.c2013-01-24 18:15:54.246157569 +0100
@@ -8600,6 +8600,7 @@
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55856
--- Comment #6 from simonb at gcc dot gnu.org 2013-01-24 18:10:44 UTC ---
Author: simonb
Date: Thu Jan 24 18:10:26 2013
New Revision: 195435
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195435
Log:
svn merge -c 194864
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
--- Comment #36 from ian at gcc dot gnu.org ian at gcc dot gnu.org 2013-01-24
18:12:41 UTC ---
Author: ian
Date: Thu Jan 24 18:12:23 2013
New Revision: 195436
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195436
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56098
Bug #: 56098
Summary: conditional write through volatile pointer produces
unintended read
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094
--- Comment #8 from rguenther at suse dot de rguenther at suse dot de
2013-01-24 18:37:30 UTC ---
jakub at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094
--- Comment #6 from Jakub
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094
--- Comment #9 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-01-24
18:39:18 UTC ---
During original gimplification, I can understand the OR_HERE (aka
input_location) part there, or in passes that maintain input_location.
I thought
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099
Bug #: 56099
Summary: Empty static noinline functions aren't called from
optimized code
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55041
--- Comment #16 from Tom Tromey tromey at gcc dot gnu.org 2013-01-24 18:50:58
UTC ---
(In reply to comment #12)
In my case the issue seems to be weird debuginfo emitted by gcc;
look at what the breakpoint reports:
Breakpoint 1,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55951
--- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com 2013-01-24
18:54:47 UTC ---
Re-confirmed with: g++ (GCC) 4.8.0 20130124 (experimental)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55041
Benjamin Kosnik bkoz at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099
--- Comment #2 from Yuri yuri at tsoft dot com 2013-01-24 19:06:12 UTC ---
Created attachment 29267
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29267
asm of the testcase showing there is still no noinline function
I am trying
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54793
Alexandre Oliva aoliva at gcc dot gnu.org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099
--- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-24
19:11:33 UTC ---
(In reply to comment #2)
Created attachment 29267 [details]
asm of the testcase showing there is still no noinline function
You need the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099
--- Comment #4 from Yuri yuri at tsoft dot com 2013-01-24 19:16:10 UTC ---
You are saying I also need to place some __asm__ into this noinline function?
Doesn't this look like working around some bugs in gcc? User doesn't need to
know how
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55887
Tilo Schwarz t...@tilo-schwarz.de changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099
--- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-24
19:22:43 UTC ---
(In reply to comment #4)
You are saying I also need to place some __asm__ into this noinline function?
Doesn't this look like working around some
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099
--- Comment #6 from Yuri yuri at tsoft dot com 2013-01-24 19:24:43 UTC ---
I think 'noinline' flag should be factored into the removal decision.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099
--- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-24
19:28:59 UTC ---
(In reply to comment #6)
I think 'noinline' flag should be factored into the removal decision.
No because this is not about inlining. This is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094
--- Comment #10 from rguenther at suse dot de rguenther at suse dot de
2013-01-24 19:30:54 UTC ---
manu at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094
--- Comment #9 from Manuel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56066
--- Comment #1 from Solomon Gibbs solomon.gibbs.lists at gmail dot com
2013-01-24 19:42:15 UTC ---
I'm looking at the objdump -x output for the c++ object and I note that there's
a separate section for the inlined function. It appears to be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
--- Comment #37 from ian at gcc dot gnu.org ian at gcc dot gnu.org 2013-01-24
19:44:31 UTC ---
Author: ian
Date: Thu Jan 24 19:44:23 2013
New Revision: 195438
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195438
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927
--- Comment #1 from Tom Tromey tromey at gcc dot gnu.org 2013-01-24 20:24:18
UTC ---
It seems that I read the wrong frame info in my original report.
However, the bug still exists. Here is a new and hopefully more
correct example showing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094
--- Comment #11 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-01-24
20:49:33 UTC ---
(In reply to comment #10)
Input_location should only be used from parsing. Other places reuse the
variable and those happen to eventually pick up
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56100
Bug #: 56100
Summary: spurious -Wshadow warning with local variable in
template class
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56100
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-24
21:14:51 UTC ---
I think this is an artifact of warning during instantiation rather than at
definition time.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56100
--- Comment #2 from Frank Heckenbach f.heckenb...@fh-soft.de 2013-01-24
21:25:09 UTC ---
I guess many warnings can only be given correctly during instantiation because
they depend on the actual arguments.
But shadowing is not one of them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56073
--- Comment #2 from Alan Modra amodra at gcc dot gnu.org 2013-01-24 21:52:04
UTC ---
Author: amodra
Date: Thu Jan 24 21:51:58 2013
New Revision: 195444
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195444
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51376
--- Comment #5 from Alan Modra amodra at gcc dot gnu.org 2013-01-24 21:52:03
UTC ---
Author: amodra
Date: Thu Jan 24 21:51:58 2013
New Revision: 195444
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195444
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56101
Bug #: 56101
Summary: pthread program abort
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: major
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56081
--- Comment #10 from janus at gcc dot gnu.org 2013-01-24 23:58:18 UTC ---
Author: janus
Date: Thu Jan 24 23:58:12 2013
New Revision: 195447
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195447
Log:
2013-01-24 Janus Weil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56081
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55994
--- Comment #6 from Janis Johnson janis at gcc dot gnu.org 2013-01-25
00:26:43 UTC ---
Author: janis
Date: Fri Jan 25 00:26:34 2013
New Revision: 195458
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195458
Log:
Backport from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56102
Bug #: 56102
Summary: Wrong rtx cost calculated for Thumb1
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56102
--- Comment #1 from bin.cheng amker.cheng at gmail dot com 2013-01-25
03:46:59 UTC ---
I have investigated this issue.
GCC uses function init_lower_subreg to initialize costs of MOVE insn with
different mode, then uses this information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56102
--- Comment #2 from bin.cheng amker.cheng at gmail dot com 2013-01-25
07:25:34 UTC ---
Created attachment 29270
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29270
correct test case
The previous test case is not appropriate,
Eric Botcazou ebotca...@adacore.com writes:
ERROR: gcc.dg/vect/vect-multitypes-12.c: error executing dg-final: bad index
18-1: must be integer or end?-integer?
Does that help? Perhaps the M-N feature isn't supported by your version
of tcl.
* lib/target-supports-dg.exp
On 01/23/13 20:55, David Edelsohn wrote:
This patch looks okay, although it needs a ChangeLog entry.
Ok, inside the patch file now rather than at the end of the mail text.
I'm still unsure if the patch should contain a real ChangeLog diff or
a simple comment, as I doubt the ChangeLog diff
On Sat, 2013-01-12 at 13:03 -0800, Andi Kleen wrote:
From: Andi Kleen a...@linux.intel.com
The libitm TSX hardware transaction fast path currently does quite a bit of
unnecessary work (saving registers etc.) before even trying to start
a hardware transaction. This patch moves the initial
On Wed, Jan 23, 2013 at 7:43 PM, Vladimir Makarov wrote:
The error occurs because a pseudo in asm insn is not changed into hard
register as the pseudo info is incorrect after info updating.
You should just use lra_update_insn_regno_info. The patch (and the patch is
ok to commit) should look
Hi,
PR 55927 is about failing scan dumps in g++.dg/ipa/devirt-10.C on
ia64. The problem turned out to be that early inliner was a bit more
active on ia64 and left nothing for IPA to figure out and so the
strings were not there in the dumps. Fixed below by running the test
with early inliner
On Thu, Jan 24, 2013 at 1:23 AM, Paul Pluzhnikov ppluzhni...@google.com wrote:
This patch allows us to catch use of destructed strings.
Google ref: b/5430313
Ok for google/gcc-4_7 and google/integration?
OK.
Diego.
Hi,
tested x86_64-linux, committed mainline and 4_7-branch.
Thanks,
Paolo.
///
2013-01-24 Paolo Carlini paolo.carl...@oracle.com
PR libstdc++/56085
* include/std/complex (pow(const complex, int)): Avoid __n
signed overflow.
Index:
On Wed, Jan 23, 2013 at 8:08 PM, Uros Bizjak ubiz...@gmail.com wrote:
All things equal, we would like to avoid x87 registers to move DFmode
immediates to a memory.
Attached patch is much better fix for the above problem. The patch
conditionally disables x87 register preferences when
Committed the following change:
http://gcc.gnu.org/r195424
* config/avr/avr.c (avr_out_fract): Make register numbers that
might be outside of source operand signed.
The problem occurs with fixed-point conversions to a wider mode and where the
input operand is in a small regno
Hi!
As discussed in the PR, while most of c-typeck.c handles
constructor_max_index == NULL the same as when
tree_int_cst_lt (constructor_max_index, some_index)
returns false, i.e. some_index is within bounds, there is one spot
that handles this incorrectly and one which doesn't consider NULL
Hi,
the testcase reproduce ICE in a very corner case of inlining. What happens is
1) early inlining is tricked to produce very complex self recursive callgraph
graph
by somewhat bogus inlining of self recursive cycles
2) late inliner decide to continue in the recursive inlining
3)
On 01/23/2013 08:24 PM, David Holsgrove wrote:
Hi Michael,
On 24 January 2013 00:58, Michael Eager ea...@eagercon.com wrote:
On 01/20/2013 09:42 PM, David Holsgrove wrote:
gcc/Changelog
2013-01-21 Edgar E. Iglesias edgar.igles...@gmail.com
* config.gcc (microblaze*-*-elf): Add
This patch adds the absolute value functions to stdfix.h.
DEF_BUILTIN gets one more argument LIBNAME that sets the library name. If no
folding is found, for some builtins it's more convenient to call libgcc support
directly instead of expanding to an insn.
gcc's folding is not very good, thus
// See gtm_thread::begin_transaction.
-uint32_t GTM::htm_fastpath = 0;
+extern C
+{
+ uint32_t __gtm_htm_fastpath = 0;
Please keep this as-is and rather use the same approach as for
gtm_thread::begin_transaction.
What approach?
I don't want to hardcode C++ mangling in the
On Thu, 24 Jan 2013, Jakub Jelinek wrote:
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk? The 20030305-1.c testcase is now rejected with hard
errors instead of resulting just in warnings and ignored initializers,
but I believe the error is right,
Hello,
I just created a new branch, based on GCC 4.7, for migrating the
vtable verification work to GCC. 4.7. I've announced the new branch
on the gcc mailing list. This patch updates the web patch docs to
mention the new branch.
-- Caroline Tice
cmt...@google.com
wwwdocs.patch
Description:
On Thu, Jan 24, 2013 at 11:52 AM, Caroline Tice cmt...@google.com wrote:
Hello,
I just created a new branch, based on GCC 4.7, for migrating the
vtable verification work to GCC. 4.7. I've announced the new branch
on the gcc mailing list. This patch updates the web patch docs to
mention the
On Mon, 2012-12-17 at 13:52 +0400, Dmitry Vyukov wrote:
resend in plain text
On Mon, Dec 17, 2012 at 1:50 PM, Dmitry Vyukov dvyu...@google.com wrote:
On Fri, Dec 14, 2012 at 5:43 PM, Torvald Riegel trie...@redhat.com wrote:
On Thu, 2012-12-13 at 10:02 +0100, Jakub Jelinek wrote:
On
On Thu, Jan 24, 2013 at 9:29 PM, Torvald Riegel trie...@redhat.com wrote:
On Mon, 2012-12-17 at 13:52 +0400, Dmitry Vyukov wrote:
resend in plain text
On Mon, Dec 17, 2012 at 1:50 PM, Dmitry Vyukov dvyu...@google.com wrote:
On Fri, Dec 14, 2012 at 5:43 PM, Torvald Riegel trie...@redhat.com
On Thu, Jan 24, 2013 at 4:18 AM, Michael Haubenwallner
michael.haubenwall...@salomon.at wrote:
Ok, inside the patch file now rather than at the end of the mail text.
I'm still unsure if the patch should contain a real ChangeLog diff or
a simple comment, as I doubt the ChangeLog diff would
Like LWU, MIPS16 LBU and LHU only allow offset(base) addresses,
so they should use W rather than o as the memory constraint.
This fixes g++.dg/torture/vshuf-v8hi.C on mips64el-linux-gnu,
where the constraints matched a PC-relative address instead.
Tested on mips64el-linux-gnu and applied.
On 01/24/2013 08:45 AM, Andi Kleen wrote:
Please keep this as-is and rather use the same approach as for
gtm_thread::begin_transaction.
What approach?
Using __asm__ to set the assembler name.
r~
Steven,
On 19/07/12 16:43, Steven Bosscher wrote:
On Thu, Jul 19, 2012 at 3:43 PM, Tom de Vries tom_devr...@mentor.com wrote:
I think you should compare your method to the one described in the
paper, and at least reference the paper if it's somehow similar --
Interesting, thanks. Will do.
I've committed this patch from minux to libgo to fix some typos in code
that is only used on non-GNU/Linux systems:
https://codereview.appspot.com/7158043
Bootstrapped on x86_64-unknown-gnu-linux, although that proves little.
Committed to mainline.
Ian
diff -r cbf555d07453 libgo/Makefile.am
FYI.
$ svn merge -c 194864
svn+ssh://sim...@gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch
...test, passes dejagnu
$ svn commit gcc/testsuite/g++.dg/cpp0x/constexpr-ctor11.C
gcc/cp/ChangeLog gcc/cp/semantics.c
Sendinggcc/cp/ChangeLog
Sendinggcc/cp/semantics.c
Adding
On Thu, 2013-01-24 at 21:44 +0400, Dmitry Vyukov wrote:
On Thu, Jan 24, 2013 at 9:29 PM, Torvald Riegel trie...@redhat.com wrote:
On Mon, 2012-12-17 at 13:52 +0400, Dmitry Vyukov wrote:
I think the simplest way to solve it for now, it to use... well, single
global lock.
I.e. replace
On Wed, 23 Jan 2013, Paul Pluzhnikov wrote:
This patch allows us to catch use of destructed strings.
Hello,
while a number of the google debug patches are just cheaper versions (that
don't break the ABI) of what libstdc++'s debug mode provides, this
overwriting of classes on destruction is
Hurugalawadi, Naveen wrote:
Hi,
Please consider this as a reminder to review the patch posted at
following link:-
http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00765.html
What is this good for?
Why are you changing the semantics of an existing, global constraint?
This patch from minux changes libgo to use __USER_LABEL_PREFIX__ for all
asm symbols. This is a necessary step for Darwin support. Bootstrapped
and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to
mainline.
https://codereview.appspot.com/7086062/
Ian
diff -r 246ddf77db61
I intend to look at this once we're back in development stage 1 (for GCC
4.9).
--
Joseph S. Myers
jos...@codesourcery.com
Hello Joseph,
I have other patches that are also part of Cilk Plus. Can I send them
out now also?
Thanks,
Balaji V. Iyer.
-Original Message-
From: Joseph Myers [mailto:jos...@codesourcery.com]
Sent: Thursday, January 24, 2013 3:22 PM
To: Iyer, Balaji V
Cc:
On Thu, 24 Jan 2013, Iyer, Balaji V wrote:
I have other patches that are also part of Cilk Plus. Can I send
them out now also?
You can send them, but I don't propose to review them outside stage 1
(clearly such major new features are only suitable for mainline commit in
stage 1), and
octeon-pipe-1.c is a sched2 test, so make sure we generate some code.
Tested on mips64el-linux-gnu and applied. This fixes the UNRESOLVEDs
in the test_summary output.
Richard
gcc/testsuite/
* gcc.target/mips/octeon-pipe-1.c: Add -ffat-lto-objects
Index:
gfortran.dg/bind_c_array_params_2.f90 fails for some mips*-linux-gnu
combinations because we output the linker hint:
.reloc 1f,R_MIPS_JALR,myBindC
as well as the call itself.
Fixed by passing the option that disables this feature. Tested on
mips64el-linux-gnu and applied.
Richard
Ok, inside the patch file now rather than at the end of the mail text.
I'm still unsure if the patch should contain a real ChangeLog diff or
a simple comment, as I doubt the ChangeLog diff would apply smoothly.
The general approach is insert the ChangeLog, as text, in the body of
the email
On 24 January 2013 19:03, Marc Glisse wrote:
On Wed, 23 Jan 2013, Paul Pluzhnikov wrote:
This patch allows us to catch use of destructed strings.
Hello,
while a number of the google debug patches are just cheaper versions (that
don't break the ABI) of what libstdc++'s debug mode provides,
On 25 January 2013 01:38, Michael Eager ea...@eagercon.com wrote:
On 01/23/2013 08:24 PM, David Holsgrove wrote:
Hi Michael,
On 24 January 2013 00:58, Michael Eager ea...@eagercon.com wrote:
On 01/20/2013 09:42 PM, David Holsgrove wrote:
gcc/Changelog
2013-01-21 Edgar E. Iglesias
Hi Michael,
Please find attached updated patch for MicroBlaze Little Endian
support to reflect removal of microblaze*-*-* target.
Changelog updated as follows.
thanks,
David
gcc/Changelog
2013-01-25 Edgar E. Iglesias edgar.igles...@gmail.com
* gcc/config.gcc (microblaze*-linux*): Add
From: Andi Kleen a...@linux.intel.com
The libitm TSX hardware transaction fast path currently does quite a bit of
unnecessary work (saving registers etc.) before even trying to start
a hardware transaction. This patch moves the initial attempt at a
transaction early into the assembler stub.
I've updated my email address. KugelWorks is open for business.
--
Maxim Kuvyrkov
KugelWorks
0001-MAINTAINERS-Update-my-email.patch
Description: Binary data
Hi,
Please find attached the patch that fixes following warning in aarch64:-
warning: TARGET_FIXED_CONDITION_CODE_REGS redefined
Thanks,
Naveen.H.S
2013-01-25 Naveen H.S naveen.hurugalaw...@caviumnetworks.com
* config/aarch64/aarch64.c (TARGET_FIXED_CONDITION_CODE_REGS):
2013/1/24 Georg-Johann Lay a...@gjlay.de:
This patch adds the absolute value functions to stdfix.h.
DEF_BUILTIN gets one more argument LIBNAME that sets the library name. If no
folding is found, for some builtins it's more convenient to call libgcc
support
directly instead of expanding to
101 - 179 of 179 matches
Mail list logo
