Perhaps instead of passing array of { void *hostaddr; size_t length; char
kind; }
and length we could pass 3 arrays and length (the same for all of them).
I can see 2 advantages of doing that:
1) the sizes are often constant and the kinds are always constant, so
we could often allocate
On Thu, 2013-08-29 01:18:32 +, paul_kon...@dell.com paul_kon...@dell.com
wrote:
On Aug 28, 2013, at 8:52 PM, Samuel Mi samuel.mi...@gmail.com wrote:
On Thu, Aug 29, 2013 at 2:54 AM, Jan-Benedict Glaw jbg...@lug-owl.de
wrote:
On Thu, 2013-08-29 02:43:54 +0800, Samuel Mi
Jan-Benedict Glaw jbg...@lug-owl.de writes:
On Wed, 2013-08-28 23:26:29 +0800, Samuel Mi samuel.mi...@gmail.com wrote:
Looks like you for now have been trying to find out a solution
suitable for you to automatically build GCC from source combined with
certain continuous systems like Jenkins.
On Thu, 2013-08-29 10:34:40 +0200, Rainer Orth r...@cebitec.uni-bielefeld.de
wrote:
Jan-Benedict Glaw jbg...@lug-owl.de writes:
On Wed, 2013-08-28 23:26:29 +0800, Samuel Mi samuel.mi...@gmail.com wrote:
Looks like you for now have been trying to find out a solution
suitable for you to
On Wed, Aug 28, 2013 at 7:15 PM, Mike Stump mikest...@comcast.net wrote:
On Aug 28, 2013, at 2:40 AM, Richard Biener richard.guent...@gmail.com
wrote:
Digging shows I at one point removed all this code - but people objected and
I
had to revert it :/
[ oh,, sorry to hear ] I got rid of it
On Wed, Aug 28, 2013 at 1:37 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Aug 28, 2013 at 01:21:53PM +0200, Richard Biener wrote:
My thought was that we need to have control over scheduling and thus have
a single runtime to be able to execute the following in parallel on the
accelerator
Hi,
I would like to hear how other architectures organize their builtin/intrinsic
headers.
Until recently we had a header that would look like:
/* Types */
typedef char V8B __attribute__ ((vector_size (8)));
...
/* Prototypes */
extern V8B __vec_put_v8b (V8B B, char C, unsigned char
On Thu, Aug 29, 2013 at 6:02 AM, Jan-Benedict Glaw jbg...@lug-owl.de wrote:
On Thu, 2013-08-29 10:34:40 +0200, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
I honestly wouldn't worry about such legacy systems: their respective
maintainers take care of testing them, and it would be hard
On Thu, 2013-08-29 07:21:28 -0400, Diego Novillo dnovi...@google.com wrote:
On Thu, Aug 29, 2013 at 6:02 AM, Jan-Benedict Glaw jbg...@lug-owl.de wrote:
On Thu, 2013-08-29 10:34:40 +0200, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
I honestly wouldn't worry about such legacy systems:
Hi,
function_value_regno_p hook implementation for i386 target
(ix86_function_value_regno_p) always returns false for DX register.
But DX register is used to return 128 bit values an AX:DX. Is it
intentional or a bug?
I'm asking because it causes problem with mode switching which fails
if see
On Thu, Aug 29, 2013 at 7:33 AM, Ilya Enkovich enkovich@gmail.com wrote:
Hi,
function_value_regno_p hook implementation for i386 target
(ix86_function_value_regno_p) always returns false for DX register.
But DX register is used to return 128 bit values an AX:DX. Is it
intentional or a
I have implemented this gcc mips16 floating point scheme in llvm/clang
and ran into one interesting issue.
In gcc mips16, for all the hard float routines, i.e. __mips16_xxx, gcc
emits a .globl for them.
It does not do this for other routines like strcmp for example or puts.
If don't remit
I forgot to mention that this only happens with Im linking as C++
On 08/29/2013 02:07 PM, Reed Kotler wrote:
I have implemented this gcc mips16 floating point scheme in llvm/clang
and ran into one interesting issue.
In gcc mips16, for all the hard float routines, i.e. __mips16_xxx, gcc
emits a
Snapshot gcc-4.8-20130829 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20130829/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #6 from Kostya Serebryany kcc at gcc dot gnu.org ---
Would a fallback implementation of BlockingMutex::{Lock,Unlock}() that uses
pthread_mutex_*() be sensible here?
That would be non-trivial. We intercept the pthread_ functions so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56933
--- Comment #8 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #7)
Created attachment 30712 [details]
fixed test case
Looking deeper into the matter it seems like this an example
where
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57685
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Thu Aug 29 07:45:59 2013
New Revision: 202068
URL: http://gcc.gnu.org/viewcvs?rev=202068root=gccview=rev
Log:
2013-08-29 Richard Biener rguent...@suse.de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57685
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Known to work||4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58268
Bug ID: 58268
Summary: umm registers not used for -march=bdver1
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287
--- Comment #17 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to davidxl from comment #16)
(In reply to Richard Biener from comment #15)
Confirmed. David, can you have a look here? I had a hard time following
what
exactly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269
Bug ID: 58269
Summary: [4.9 Regression] ICE when building libobjc on
x86_64-apple-darwin10 after revision 201915
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49821
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48173
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50275
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50913
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58268
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393
--- Comment #29 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Joost VandeVondele from comment #28)
OK, with only the patch mentioned above applied all testcases now pass. I
think this patch should be posted to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56864
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57511
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
It looks like
Index: gcc/tree-scalar-evolution.c
===
--- gcc/tree-scalar-evolution.c (revision 202068)
+++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58260
--- Comment #8 from anand.karanam at tcs dot com ---
Hi,
I have tried the build of gmp,mpfr and mpc with the option of --disable-shared
and using them.
However now when I use the following configuration for cross compiler build (
Solaris to Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58260
--- Comment #9 from anand.karanam at tcs dot com ---
Hi,
I have tried the build of gmp,mpfr and mpc with the option of --disable-shared
and using them.
However now when I use the following configuration for cross compiler build (
Solaris to Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58260
--- Comment #10 from anand.karanam at tcs dot com ---
Created attachment 30716
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30716action=edit
libgomp configuration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58246
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
Bug ID: 58270
Summary: Wrong code accessing array elements
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
--- Comment #1 from Florian Weimer fweimer at redhat dot com ---
The compiler is free to assume that both i1 and i2 are zero and the first store
is dead (because this is the only valid array index). So if the buggy()
function stores a value of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58246
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
We decide to stop because we think that we reached a killing definition when
looking for possible defs of
_8 = t[a.0_6];
and reach, over the loop backedge
t[a.0_6] = 0;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58228
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
--- Comment #2 from Krzysztof Strasburger strasbur at chkw386 dot
ch.pwr.wroc.pl ---
OK, I'm not and expert, but mem is a global structure and it can be of
different size in other object file. The linker should assume the biggest of
all, correct?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269
Iain Sandoe iains at gcc dot gnu.org changed:
What|Removed |Added
Target|x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287
--- Comment #18 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Thu Aug 29 11:20:16 2013
New Revision: 202069
URL: http://gcc.gnu.org/viewcvs?rev=202069root=gccview=rev
Log:
2013-08-29 Richard Biener rguent...@suse.de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58260
--- Comment #11 from Mikael Pettersson mikpe at it dot uu.se ---
(In reply to anand.karanam from comment #9)
Do we need to have a copy of the Linux host includes and libraries to
prepare the cross compiler?
Or can we avoid this with newlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
--- Comment #3 from Krzysztof Strasburger strasbur at chkw386 dot
ch.pwr.wroc.pl ---
The compiler option -fno-tree-dse does the job for me. Florian - thank you for
using the term dead store ;). I'm not sure whether it should be enabled by
default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58252
--- Comment #2 from Martin Jambor jamborm at gcc dot gnu.org ---
Created attachment 30718
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30718action=edit
Delta reduced testcase
A fair bit smaller multidelta-delta reduced testcase.
Requires
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52243
--- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org ---
Author: tkoenig
Date: Thu Aug 29 11:44:41 2013
New Revision: 202070
URL: http://gcc.gnu.org/viewcvs?rev=202070root=gccview=rev
Log:
2013-08-29 Thomas Koenig tkoe...@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52243
--- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org ---
Fixed on trunk, closing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52243
Thomas Koenig tkoenig at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58223
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
--- Comment #4 from Krzysztof Strasburger strasbur at chkw386 dot
ch.pwr.wroc.pl ---
Unfortunately, this is not the end of story. I'm going to attach a little more
complicated example, for which even using -fno-dse -fno-tree-dse does not help.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
--- Comment #5 from Krzysztof Strasburger strasbur at chkw386 dot
ch.pwr.wroc.pl ---
Created attachment 30719
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30719action=edit
Second example, not working also with -fno-tree-dse -fno-dse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
--- Comment #6 from Krzysztof Strasburger strasbur at chkw386 dot
ch.pwr.wroc.pl ---
Created attachment 30720
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30720action=edit
File containing main() for the second example
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56519
Thomas Koenig tkoenig at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
--- Comment #7 from Mikael Pettersson mikpe at it dot uu.se ---
Your examples are invalid C. In one module you present the compiler with a
specific declaration, and complain when it utilizes constraints derived from
that declaration. Then in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58010
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51424
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58246
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Thu Aug 29 13:04:19 2013
New Revision: 202071
URL: http://gcc.gnu.org/viewcvs?rev=202071root=gccview=rev
Log:
2013-08-29 Richard Biener rguent...@suse.de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58010
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org ---
In the loop in question we have a dead scalar cycle for which we do not
insert loop-closed PHI nodes. Hm.
The correct fix looks easy though - simply remove the assert. We'll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57396
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Thu Aug 29 13:11:01 2013
New Revision: 202073
URL: http://gcc.gnu.org/viewcvs?rev=202073root=gccview=rev
Log:
Backported from mainline
2013-05-27 Richard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57343
--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Thu Aug 29 13:09:26 2013
New Revision: 202072
URL: http://gcc.gnu.org/viewcvs?rev=202072root=gccview=rev
Log:
Backported from mainline
2013-05-27 Richard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641
--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Thu Aug 29 13:14:59 2013
New Revision: 202074
URL: http://gcc.gnu.org/viewcvs?rev=202074root=gccview=rev
Log:
Backported from mainline
2013-07-22
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57381
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Thu Aug 29 13:14:59 2013
New Revision: 202074
URL: http://gcc.gnu.org/viewcvs?rev=202074root=gccview=rev
Log:
Backported from mainline
2013-07-22
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57417
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Thu Aug 29 13:14:59 2013
New Revision: 202074
URL: http://gcc.gnu.org/viewcvs?rev=202074root=gccview=rev
Log:
Backported from mainline
2013-07-22
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58084
--- Comment #8 from Richard Biener rguenth at gcc dot gnu.org ---
If a type is refered to by two functions it is by definition not local. But
as it references a local entity it is local.
Note that you seem to have put the type local for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57396
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57343
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57381
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57417
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=58270
--- Comment #8 from Krzysztof Strasburger strasbur at chkw386 dot
ch.pwr.wroc.pl ---
Mikael,
I cannot agree. Do not look at main.c, as the compiler doesn't know anything
about it while compiling buggy.c (this is the reason for which I keep main()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Last reconfirmed|2012-03-24 00:00:00
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58271
Bug ID: 58271
Summary: ICE in gcc for a MIPS target during compilation with
-mpaired-single -ftree-vectorize
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58252
--- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org ---
We are getting an integer instead of an expected ADDR_EXPR to a
FUNCTIONN_DECL. Token is 3, known_binfo which is a binfo pertaining to
(gdb) pge known_binfo-typed.type
struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58272
Bug ID: 58272
Summary: unnecessary vtables emission for pure abstract classes
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
--- Comment #10 from Krzysztof Strasburger strasbur at chkw386 dot
ch.pwr.wroc.pl ---
Jakub,
I do not care about C++ (never understood it), but commons are just commons. I
see them from linker's perspective. How does the compiler treat variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287
--- Comment #20 from meadori at gcc dot gnu.org ---
Confirmed fix.
I can also now build GDB trunk with GCC trunk (both from today).
Thanks Richard!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58273
Bug ID: 58273
Summary: ICE: Segmentation fault with C++11
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #7 from Daniel Richard G. skunk at iskunk dot org ---
Created attachment 30723
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30723action=edit
Trivial configure-time check
(In reply to Kostya Serebryany from comment #6)
That
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58273
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12081
--- Comment #31 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Thu Aug 29 18:37:46 2013
New Revision: 202083
URL: http://gcc.gnu.org/viewcvs?rev=202083root=gccview=rev
Log:
Backport from mainline
2013-08-05 Oleg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12081
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58273
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=58273
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.7.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58274
Bug ID: 58274
Summary: libiberty/stack-limit.c: bootstrap failure due to
missing FreeBSD header
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58275
Bug ID: 58275
Summary: __builtin_constant_p( expr ) returns true if expr is
eliminated by CSE
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58275
--- Comment #1 from Marc Glisse glisse at gcc dot gnu.org ---
Where do you see a bug? The test argc!=23 is always true in this branch, so it
*is* a compile-time constant. It is very much on purpose that
__builtin_constant_p returns true.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58275
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #191 from Markus Trippelsdorf markus at trippelsdorf dot de ---
First of all many thanks for your work on reducing memory usage.
Peak memory usage is now lower (~3GB) than clang's (~4GB).
However, with -enable-optimize=-O3 on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58275
--- Comment #3 from Tijl Coosemans tijl at coosemans dot org ---
Eh, of course.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #21 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Richard, I have one question:
does this code at expr.c line 4717 look right?
I mean does the code in the if block use the offset at all?
misalignp = true;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #192 from Markus Trippelsdorf markus at trippelsdorf dot de ---
It turned out that -enable-optimize=-O3 is the cause.
Rev202079 with -Os links fine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58276
Bug ID: 58276
Summary: make install-host gfortran is not functional
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
model: posix
gcc version 4.9.0 20130829 (experimental) [trunk revision 202067] (GCC)
$ gcc-trunk -m32 -O2 small.c
$ a.out
0
$ gcc-4.6 -m32 -O3 small.c
$ a.out
0
$ gcc-trunk -m32 -O3 small.c
$ a.out
0
Aborted (core dumped)
$ gcc-4.7 -m32 -O3 small.c
$ a.out
0
Aborted (core dumped)
$ gcc-4.8 -m32 -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58276
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58277
--- Comment #1 from Zhendong Su su at cs dot ucdavis.edu ---
Created attachment 30725
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30725action=edit
testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58277
--- Comment #2 from Zhendong Su su at cs dot ucdavis.edu ---
I'm also attaching a related testcase (small2.c) for both 32-bit and 64-bit
modes.
$ gcc-trunk -m64 -O2 small2.c
$ a.out
$ gcc-4.6 -m64 -O3 small2.c
$ a.out
$ gcc-4.7 -m64 -O3 small2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58277
--- Comment #3 from Zhendong Su su at cs dot ucdavis.edu ---
Created attachment 30726
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30726action=edit
another testcase for both 32-bit and 64-bit modes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58276
--- Comment #2 from Larry Baker baker at usgs dot gov ---
Andrew,
On 29 Aug 2013, at 4:31 PM, pinskia at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58276
Andrew Pinski pinskia at gcc dot gnu.org changed:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58276
--- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Larry Baker from comment #2)
Yes, this is exactly what I described in my post. The question I have is,
what is the intended behavior of a GCC make install-host with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58276
--- Comment #4 from Larry Baker baker at usgs dot gov ---
I suppose a different way of asking whether this should be considered a bug is
to ask what should gfortran's behavior be when libgfortran.spec is missing? Is
the correct behavior to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58276
--- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Larry Baker from comment #4)
I suppose a different way of asking whether this should be considered a bug
is to ask what should gfortran's behavior be when
1 - 100 of 182 matches
Mail list logo
