Hi,
I am trying to find where IRA, is deleting trivial insn like:
(set r1 r1)
The problem I am facing is that I have managed to convince GCC to handle
moves that clobber RCC like:
(parallel [(set reg1 reg2) (clobber rcc)])
However, I am getting loads of insn like:
(parallel [(set r1 r2)
Hi!
This concerns multiple character integer constants, e.g.
'abcd'
as discussed in the C99 standard in subsection 6.4.4.4.
We'll call them multichars.
First: everybody agrees multichars are non-portable and therefore to
be avoided.
That said, there are real-life situations where they
The latest set of patches to update the Sparc platform has resulted in a
build failure in stage 1 of this mornings builds:
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic
GNU MPFR 3.1.0 (canard à l'orange) is now available for download
from the MPFR web site:
http://www.mpfr.org/mpfr-3.1.0/
and from INRIAGForge:
https://gforge.inria.fr/projects/mpfr/
It will be available on the GNU FTP site in a few hours.
Thanks very much to those who sent us bug reports
On 09/30/2011 01:36 PM, Andrew MacLeod wrote:
http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary
__atomic_store (size_t obj_size, T *mem, T val, enum memory_model model)
I don't like this. I really cannot imagine any situation for which the
compiler can't resolve SIZE to a compile-time constant.
On 10/03/2011 01:31 PM, Richard Henderson wrote:
On 09/30/2011 01:36 PM, Andrew MacLeod wrote:
http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary
__atomic_store (size_t obj_size, T *mem, T val, enum memory_model model)
I don't like this. I really cannot imagine any situation for which the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/11 22:43, Amker.Cheng wrote:
I believe, the optimization you may be referring to is value
range propagation which does predication of values based on
predicates of conditions. GCC definitely applies VRP at the
tree stage, I am not sure
On 10/03/2011 10:54 AM, Andrew MacLeod wrote:
its a library call for arbitrary sized objects... C++ can have any
class declared atomic, so it doesn't have to map to one of those
optimized lock-free routines.
Ah, I get it now. Ew.
r~
On Mon, 3 Oct 2011, Andrew MacLeod wrote:
On 10/03/2011 01:31 PM, Richard Henderson wrote:
On 09/30/2011 01:36 PM, Andrew MacLeod wrote:
http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary
__atomic_store (size_t obj_size, T *mem, T val, enum memory_model
model)
I don't like this. I
Ulf Magnusson ulfali...@gmail.com writes:
Is there some reason why GCC couldn't generate this code for the first
version of C::f()? Is this a failure of optimization, or am I missing
something in how __restricted works?
It's a failure of optimization.
Ian
pa...@matos-sorge.com (Paulo J. Matos) writes:
I am trying to find where IRA, is deleting trivial insn like:
(set r1 r1)
Search for Discard obvious no-ops in the function reload in the file
gcc/reload1.c.
Ian
Hello Everyone,
I contributed the Cilk Plus branch of GCC and I would like to create a
page in GCC Wiki (link: http://gcc.gnu.org/wiki/HomePage) with the information
about this branch and maybe some future work. Can someone please tell me how I
can get write access to the GCC wiki?
On 3 October 2011 21:55, Iyer, Balaji V wrote:
Hello Everyone,
I contributed the Cilk Plus branch of GCC and I would like to create a
page in GCC Wiki (link: http://gcc.gnu.org/wiki/HomePage) with the
information about this branch and maybe some future work. Can someone please
tell
On 10/03/2011 04:25 PM, Michael LIAO wrote:
Sorry, resend with plain text format.
Hi, Everyone
As x32 psABI (https://sites.google.com/site/x32abi/) is invented, do
we need a new triplet for system relies on triplet to figure out it's
targeted on x32 environment. The new triplet would look like
Hi,
Though conditional const information r684 - 0 is collected by
find_implicit_sets, the conditional information is recorded as local
information of bb 97, and it is not recorded in avout of bb 96, so not
in avin of bb 97 either.
To have the set in avout of bb 96 would be wrong because the
On Monday, October 03, 2011 18:25:46 Michael LIAO wrote:
As x32 psABI (https://sites.google.com/site/x32abi/) is invented, do
we need a new triplet for system relies on triplet to figure out it's
targeted on x32 environment. The new triplet would look like
'x86_64-unknown-linux-gnux32' for x32
Sorry, resend with plain text format.
Hi, Everyone
As x32 psABI (https://sites.google.com/site/x32abi/) is invented, do
we need a new triplet for system relies on triplet to figure out it's
targeted on x32 environment. The new triplet would look like
'x86_64-unknown-linux-gnux32' for x32 vs
Hi everybody!
It is necessary to implement a plug-in for GCC designed to collect the
information on types of translation unit, and generate static const
array of types rtti_ex _ on its base;
//
enum class type_ {
char_, uchar_, short_, ushort_, int_, uint_,
Hi everybody!
It is necessary to implement a plug-in for GCC designed to collect the
information on types of translation unit, and generate static const
array of types rtti_ex _ on its base;
//
enum class type_ {
char_, uchar_, short_, ushort_, int_, uint_,
Most examples would be related to tools generating code.
Suppose you have a software package with several hard-coded fully
optimized assembly file for different targets. Your build system need
to know the current target as well as target ABI to select the correct
assembly file to build it. It
On Monday, October 03, 2011 18:57:28 Michael LIAO wrote:
please don't top post
Most examples would be related to tools generating code.
Suppose you have a software package with several hard-coded fully
optimized assembly file for different targets. Your build system need
to know the
On Mon, Oct 3, 2011 at 3:57 PM, Michael LIAO michael.hl...@gmail.com wrote:
Most examples would be related to tools generating code.
Suppose you have a software package with several hard-coded fully
optimized assembly file for different targets. Your build system need
to know the current
On Mon, Oct 3, 2011 at 4:03 PM, Mike Frysinger vap...@gentoo.org wrote:
On Monday, October 03, 2011 18:57:28 Michael LIAO wrote:
please don't top post
sorry, it's my first post on mailing.
Most examples would be related to tools generating code.
Suppose you have a software package with
On Monday, October 03, 2011 19:47:57 Michael LIAO wrote:
On Mon, Oct 3, 2011 at 4:03 PM, Mike Frysinger wrote:
On Monday, October 03, 2011 18:57:28 Michael LIAO wrote:
Most examples would be related to tools generating code.
Suppose you have a software package with several hard-coded
On Mon, Oct 3, 2011 at 4:47 PM, Michael LIAO michael.hl...@gmail.com wrote:
On Mon, Oct 3, 2011 at 4:03 PM, Mike Frysinger vap...@gentoo.org wrote:
On Monday, October 03, 2011 18:57:28 Michael LIAO wrote:
please don't top post
sorry, it's my first post on mailing.
Most examples would be
On Mon, Oct 3, 2011 at 5:46 PM, Mike Frysinger vap...@gentoo.org wrote:
On Monday, October 03, 2011 19:47:57 Michael LIAO wrote:
On Mon, Oct 3, 2011 at 4:03 PM, Mike Frysinger wrote:
On Monday, October 03, 2011 18:57:28 Michael LIAO wrote:
Most examples would be related to tools generating
On Mon, Oct 3, 2011 at 5:53 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Mon, Oct 3, 2011 at 4:47 PM, Michael LIAO michael.hl...@gmail.com wrote:
On Mon, Oct 3, 2011 at 4:03 PM, Mike Frysinger vap...@gentoo.org wrote:
On Monday, October 03, 2011 18:57:28 Michael LIAO wrote:
please don't top post
On Monday, October 03, 2011 23:26:25 Michael LIAO wrote:
On Mon, Oct 3, 2011 at 5:46 PM, Mike Frysinger wrote:
in terms of asm code, it's still possible to use ifdef's to handle cases
where you truly need different code paths.
Yeah, we could have '#ifdef X32ABI in assembly file to select
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50587
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50596
Bug #: 50596
Summary: Problems in vectorization of condition expression
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50588
--- Comment #10 from Mikael Pettersson mikpe at it dot uu.se 2011-10-03
08:35:31 UTC ---
(In reply to comment #8)
(In reply to comment #6)
So which libc was this originally compiled against? Some things in
traceroute.i make me think it's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50596
--- Comment #1 from vincenzo Innocente vincenzo.innocente at cern dot ch
2011-10-03 08:40:53 UTC ---
manage to vectorize this
int j[1024];
void foo5() {
for (int i=0; i!=N; ++i)
j[i] = (a[i]b[i] ? -1 : 0) (c[i]d[i] ? -1 : 0);
}
which is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50587
--- Comment #3 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-10-03 08:44:09 UTC ---
(In reply to comment #2)
Created attachment 25402 [details]
gcc47-pr50587.patch
Does this patch fix it?
Yes it fixes both the LTO kernel and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50593
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=50587
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-03
09:06:43 UTC ---
Author: jakub
Date: Mon Oct 3 09:06:38 2011
New Revision: 179447
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179447
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50038
--- Comment #4 from Uros Bizjak ubizjak at gmail dot com 2011-10-03 09:19:16
UTC ---
(In reply to comment #3)
So assuming this approach (modify implicit-zee pass) is right, we'll have to
enable this pass at least on x86 (32 bit). Is it ok ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50597
Bug #: 50597
Summary: printf_fp.o: relocation R_X86_64_PC32 against
`hack_digit.6607' can not be used when making a shared
object; recompile with -fPIC
Classification:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50595
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-03
10:04:17 UTC ---
Without having looked at the code, ICC behaves exactly like GCC.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39681
--- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-10-03
10:07:49 UTC ---
(In reply to comment #2)
Manuel, can I have your opinion about this one?
Since you ask, my opinion is that first there should be only 1 error and not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50570
--- Comment #2 from msteghofer at cistib dot upf.edu 2011-10-03 10:15:09 UTC ---
Created attachment 25403
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25403
Code to reproduce the behaviour
Subroutine POINTER_INTENT_IN_BUG_FAILING contains
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50570
msteghofer at cistib dot upf.edu changed:
What|Removed |Added
CC||msteghofer at cistib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44854
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=39681
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-03
11:08:39 UTC ---
Ok, thanks. Frankly I hadn't noticed the *second* error. The first one seemed
good enough to me, and quite similar to what I saw elsewhere modulo type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39681
--- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-03
11:13:52 UTC ---
Like, sorry about my naivete, by adding a cp_parser_skip_to_end_of_statement or
something right after the error message?!?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50588
--- Comment #11 from Mikael Pettersson mikpe at it dot uu.se 2011-10-03
11:46:28 UTC ---
The failure seems to have disappeared on trunk starting with r179284:
http://gcc.gnu.org/ml/gcc-cvs/2011-09/msg00903.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50587
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50588
--- Comment #12 from Mikael Pettersson mikpe at it dot uu.se 2011-10-03
12:56:10 UTC ---
Backporting r179284 to 4.6.1 (trivial except for the third ifcvt.c hunk which
required manual application due to a context diff) fixed the test case there
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36819
nightstrike nightstrike at gmail dot com changed:
What|Removed |Added
CC||nightstrike at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43682
--- Comment #3 from nightstrike nightstrike at gmail dot com 2011-10-03
13:06:38 UTC ---
Who can update the in-tree boehm-gc?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42304
nightstrike nightstrike at gmail dot com changed:
What|Removed |Added
CC||nightstrike at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594
--- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-03
13:22:23 UTC ---
I have no idea how this can be made to work with -fwhole-program, but other
people know better.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2011-10-03
13:41:50 UTC ---
(In reply to comment #3)
Thank you for the replies. Is this behaviour standard-conforming?
The documentation for -fwhole-program says that all functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594
--- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2011-10-03
13:43:21 UTC ---
[basic.stc.dynamic.allocation] p1
a program is ill-formed if an allocation function is declared in a namespace
scope other than global scope or declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594
--- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-03
13:45:03 UTC ---
Oh, thanks Jon for testing that. Indeed, as far as I'm concerned, the issue is
resolved.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594
--- Comment #10 from Daniel Krügler daniel.kruegler at googlemail dot com
2011-10-03 13:49:01 UTC ---
(In reply to comment #8)
I agree that given the make static contract of -fwhole-program (which I was
not aware about) the compiler behaves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50598
Bug #: 50598
Summary: [4.7 Regression] Undefined symbols: ___emutls_v.*,
... on *-apple-darwin*
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50599
Bug #: 50599
Summary: -ftree-vectorize generating incorrect code
Classification: Unclassified
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594
--- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org 2011-10-03
15:02:37 UTC ---
we could add __attribute__((externally_visible)) on the declarations in new
I don't know what other side effects that would have
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594
--- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-03
15:12:53 UTC ---
Yes, yesterday, a bit sleepy, I also wondered that, but I'm not knowledgeable
enough of these mechanisms to say whether it would be otherwise safe.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33814
mercergeoinfo at yahoo dot co.uk changed:
What|Removed |Added
CC||mercergeoinfo at yahoo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50600
Bug #: 50600
Summary: Illegal instruction when using pragma Profile
(Restricted)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39164
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594
--- Comment #13 from Kerrek SB z0sh at sogetthis dot com 2011-10-03 16:12:28
UTC ---
Very interesting. I understand that making the function static makes the
program ill-formed, but it's still somewhat surprising that a compiler flag
should turn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50601
Bug #: 50601
Summary: [4.7 Regression] New LTO failures
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
Bug #: 50602
Summary: ICE in tree_nrv, at tree-nrv.c:155 during large LTO
build
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Version|unknown |4.7.0
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50601
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||hubicka at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50603
Bug #: 50603
Summary: [x32] Unnecessary lea
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49967
--- Comment #2 from Steve Ellcey sje at gcc dot gnu.org 2011-10-03 17:57:44
UTC ---
Author: sje
Date: Mon Oct 3 17:57:40 2011
New Revision: 179472
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179472
Log:
2011-10-03 Steve Ellcey
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50603
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
++,lto --enable-plugin --with-tune=generic
--enable-version-specific-runtime-libs
Thread model: posix
gcc version 4.7.0 20111003 (experimental) [trunk revision 179472] (GCC)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50604
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50588
--- Comment #13 from Mikael Pettersson mikpe at it dot uu.se 2011-10-03
19:27:21 UTC ---
Created attachment 25404
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25404
reduced preprocessed test case
With this reduced test case I'm seeing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50283
--- Comment #3 from John David Anglin danglin at gcc dot gnu.org 2011-10-03
19:43:40 UTC ---
Created attachment 25405
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25405
.final dump
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50357
--- Comment #1 from dcb dcb314 at hotmail dot com 2011-10-03 20:23:46 UTC ---
Seems fixed in gcc snapshot 20111001
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50357
dcb dcb314 at hotmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50605
Bug #: 50605
Summary: ice in ipa_get_jf_pass_through_result with -O3
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50606
Bug #: 50606
Summary: gcc fails to detect obvious use of NULL pointer
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50603
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|NEW |UNCONFIRMED
Ever
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50607
--- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-10-03
23:09:44 UTC ---
For cris-elf too (unsurprisingly as the error seems universal), plus I'm seeing
a:
FAIL: gcc.c-torture/execute/pr23135.c compilation, -O2 -flto (internal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50607
Bug #: 50607
Summary: [4.7 Regression] FAIL: gcc.dg/bconstp-3.c
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50607
--- Comment #2 from Artem Shinkarov artyom.shinkaroff at gmail dot com
2011-10-03 23:17:22 UTC ---
That seems to be the changes caused by the patch I have committed. However, may
be this is a test-case that needs adjustment.
I'll have to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50607
--- Comment #3 from Artem Shinkarov artyom.shinkaroff at gmail dot com
2011-10-03 23:32:47 UTC ---
(In reply to comment #1)
For cris-elf too (unsurprisingly as the error seems universal), plus I'm
seeing
a:
FAIL:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50608
Bug #: 50608
Summary: cannot apply 'offsetof' to a non constant address
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50608
Dan Berger dberger at oubliette dot org changed:
What|Removed |Added
See Also|
(GCC) version 4.7.0 20111003 (experimental) [trunk revision 179480]
(cris-elf)
compiled by GNU C version 4.4.3 20100127 (Red Hat 4.4.3-4), GMP version
4.3.0, MPFR version 2.4.1, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50607
--- Comment #4 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-10-04
00:04:54 UTC ---
(In reply to comment #3)
On x86 linux the testcase does not cause segfaults, so may be you could
investigate via gdb which function cause segfault on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50609
--- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-10-04
00:22:11 UTC ---
Last known working revision:first known failing 179447:179464, and 179462 is
the only related change in that range, so it's confirmed that's the revision
/testsuite/gcc/ -dumpbase
pr23135.x6 -auxbase-strip /tmp/ccJhtPAy.lto.o -O2 -w -version
-flto-partition=none -fresolution=pr23135.res pr23135.o -o pr23135.s
GNU GIMPLE (GCC) version 4.7.0 20111003 (experimental) [trunk revision 179480]
(cris-elf)
compiled by GNU C version 4.4.3 20100127 (Red Hat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50609
Hans-Peter Nilsson hp at gcc dot gnu.org changed:
What|Removed |Added
Target||cris-axis-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50610
Bug #: 50610
Summary: G++ 4.4.3: Incorrect code at -O2 (-fwrapv, SafeInt,
c++ templates, template class files)
Classification: Unclassified
Product: gcc
Version: 4.4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50610
--- Comment #1 from Jeffrey Walton noloader at gmail dot com 2011-10-04
04:07:17 UTC ---
My bad:
jeffrey@studio:~/Desktop/safeint-opt-test$ gcc --version
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
Copyright (C) 2009 Free Software Foundation, Inc.
This is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50610
--- Comment #2 from Jeffrey Walton noloader at gmail dot com 2011-10-04
05:24:20 UTC ---
For this problem, the work around was:
try
{
const T* base = ptr;
base += SafeIntsize_t(cnt);
}
catch(const SafeIntException)
{
From: Andi Kleen a...@linux.intel.com
Currently when reading in LTO sections from ld -r files they can
get randomly reordered based on hash tables and random IDs.
This causes reordering later when the final code is generated and
also makes crashes harder to reproduce.
This patch maintains
PING?
On Thu, Sep 22, 2011 at 2:28 PM, Ozkan Sezer seze...@gmail.com wrote:
Hi:
Unless I'm missing something, the mingw CPP_SPEC changes introduced in
r171833 have a typo: -D_REENTRANCE should read -D_REENTRANT . Patchlet
below. Please review, and apply if it's OK.
Richard Sandiford richard.sandif...@linaro.org writes:
Jan Hubicka hubi...@ucw.cz writes:
the problem is sign overflow in time computation. Time should be
capped by MAX_TIME and we compute MAX_TIME * INLINE_SIZE_SCALE *
2. This happens to be 2^31 2^32 so we overflow here because of use
of
Bernd Schmidt ber...@codesourcery.com writes:
On 09/14/11 11:03, Richard Sandiford wrote:
...I didn't see from an admittedly quick read of the patch how you
handle memory disambiguation between iterations. If a loop includes:
lb $3,($4)
sb $5,1($4)
then the two instructions
Just a suggestion, but...
Bernd Schmidt ber...@codesourcery.com writes:
Index: gcc/cfgcleanup.c
===
--- gcc/cfgcleanup.c (revision 178734)
+++ gcc/cfgcleanup.c (working copy)
@@ -1488,6 +1488,16 @@ outgoing_edges_match (int
1 - 100 of 179 matches
Mail list logo
