I am starting a review of the changes I made on the mem-ref2 branch
in preparation for a merge to trunk. This is a request for testing.
I have personally bootstrapped and tested on x86_64-unknown-linux
and powerpc64-linux (both with 32bit multilibs included and for
all languages). I also
Hi,
In my port I get to gen_reload to the lines
/* If IN is a simple operand, use gen_move_insn. */
else if (OBJECT_P (in) || GET_CODE (in) == SUBREG)
{
static int xxx;
xxx = OBJECT_P (in);
tem = emit_insn (gen_move_insn (out, in));
/* IN may contain a
Hi,
In the context of bug 31230, I have a question about the if_marked
construct.
[DOC http://gcc.gnu.org/onlinedocs/gccint/GTY-Options.html]
if_marked (expression)
Suppose you want some kinds of object to be unique, and so you
put them in a hash table. If garbage collection marks the
On Tue, Jun 08, 2010 at 10:27:03PM +0930, Alan Modra wrote:
PowerPC64 gcc support for a larger TOC via -mcmodel option.
[snip]
I'm having second thoughts about the optimization I added to PowerPC64
gcc with the patch hunk below. Its effect is to use a more efficient
TOC/GOT pointer relative
roy rosen roy.1ro...@gmail.com writes:
In my port I get to gen_reload to the lines
/* If IN is a simple operand, use gen_move_insn. */
else if (OBJECT_P (in) || GET_CODE (in) == SUBREG)
{
static int xxx;
xxx = OBJECT_P (in);
tem = emit_insn (gen_move_insn
roy rosen roy.1ro...@gmail.com writes:
In my port I get to gen_reload to the lines
/* If IN is a simple operand, use gen_move_insn. */
else if (OBJECT_P (in) || GET_CODE (in) == SUBREG)
{
static int xxx;
xxx = OBJECT_P (in);
tem = emit_insn (gen_move_insn
Tom de Vries tjvr...@xs4all.nl writes:
static int prop(const_tree type)
{
return type == A;
}
static int type_hash_marked_p (const void *p) {
const_tree const type = ((const struct type_hash *) p)-type;
return ggc_marked_p (type) || prop (type);
}
I would like to question your
Can we similarly promise or say something for accesses of the
containing struct as a whole?
I hadn't considered those cases (when would you want to copy a
*peripheral* ?) Should be the same as before, I would think.
On Jun 23, 2010, at 16:49, Ian Lance Taylor wrote:
Tom de Vries tjvr...@xs4all.nl writes:
static int prop(const_tree type)
{
return type == A;
}
static int type_hash_marked_p (const void *p) {
const_tree const type = ((const struct type_hash *) p)-type;
return ggc_marked_p (type) || prop
On Wed, Jun 23, 2010 at 11:34:04AM -0400, DJ Delorie wrote:
Can we similarly promise or say something for accesses of the
containing struct as a whole?
I hadn't considered those cases (when would you want to copy a
*peripheral* ?) Should be the same as before, I would think.
Not the
Tom de Vries tjvr...@xs4all.nl writes:
What I am really trying to do, is a bootstrap debug build of 4.3.5.
However, I ran into bug 31230. I minimized the testcase, did an
analysis, created a naive patch to test my hypothesis, tested the
patch and put it in the bug report. Now I'm looking for
On Wed, 2010-06-23 at 08:56 -0700, Ian Lance Taylor wrote:
Tom de Vries tjvr...@xs4all.nl writes:
What I am really trying to do, is a bootstrap debug build of 4.3.5.
However, I ran into bug 31230. I minimized the testcase, did an
analysis, created a naive patch to test my hypothesis,
Hi,
My port supports hardware loops generated by the following (do_end) pattern:
(set (pc) (if_then_else (ne (match_operand:HI 0 general_register_operand d)
(const_int 0))
(label_ref (match_operand 1 ))
(pc)))
(set
On 06/23/10 11:22, Alex Turjan wrote:
Hi,
My port supports hardware loops generated by the following (do_end) pattern:
(set (pc) (if_then_else (ne (match_operand:HI 0 general_register_operand d)
(const_int 0))
(label_ref (match_operand 1 ))
Basile Starynkevitch bas...@starynkevitch.net writes:
On Wed, 2010-06-23 at 08:56 -0700, Ian Lance Taylor wrote:
Tom de Vries tjvr...@xs4all.nl writes:
What I am really trying to do, is a bootstrap debug build of 4.3.5.
However, I ran into bug 31230. I minimized the testcase, did an
insns which branch are not allowed to have output
reloads. You must
support any kind of register as well as memory operands in
your insn for
the loop counter.
Thanks for answer but what do you suggest to do, as my architecture done not
support HW loops with memory operands?
Alex
On 06/23/10 12:29, Alex Turjan wrote:
insns which branch are not allowed to have output
reloads. You must
support any kind of register as well as memory operands in
your insn for
the loop counter.
Thanks for answer but what do you suggest to do, as my architecture done not
support
On 06/23/2010 06:03 AM, Alan Modra wrote:
On Tue, Jun 08, 2010 at 10:27:03PM +0930, Alan Modra wrote:
PowerPC64 gcc support for a larger TOC via -mcmodel option.
[snip]
I'm having second thoughts about the optimization I added to PowerPC64
gcc with the patch hunk below. Its effect is to
Date: Wed, 23 Jun 2010 11:53:31 -0400
From: Daniel Jacobowitz d...@codesourcery.com
On Wed, Jun 23, 2010 at 11:34:04AM -0400, DJ Delorie wrote:
Can we similarly promise or say something for accesses of the
containing struct as a whole?
I hadn't considered those cases (when would you
On Jun 23, 2010, at 19:40, Ian Lance Taylor wrote:
Basile Starynkevitch bas...@starynkevitch.net writes:
On Wed, 2010-06-23 at 08:56 -0700, Ian Lance Taylor wrote:
Tom de Vries tjvr...@xs4all.nl writes:
What I am really trying to do, is a bootstrap debug build of 4.3.5.
However, I ran into
There are some target-specific types that are embedded in otherwise
target-independent types, namely struct machine_function and
CUMULATIVE_ARGS (which is the type of the info member of struct
incoming_args).
For the multi-target configurations as per PR44566 to work, these types
have to be
Quoting Alex Turjan atur...@yahoo.com:
When Im compiling a loop with high register pressure the register
allocator does not allocate a register for the loop counter (i.e.,
operand 0) as it has a long life range. Thus operand 0 has to be
reloaded but then I get a failure in the reload:
Hi everyone,
I'm starting to dig a little bit in what gcc does to protect the stack
from overflows and attacks of that kind. I've found some docs and
patches, but they aren't really up to date. I thought I could get some
diffs for the parts that manage these features, to see exactly what
they do
On Jun 23, 2010, at 22:53, Tomás Touceda wrote:
I'm starting to dig a little bit in what gcc does to protect the stack
from overflows and attacks of that kind. I've found some docs and
patches, but they aren't really up to date. I thought I could get some
diffs for the parts that manage
Joern Rennecke amyl...@spamcop.net writes:
Would patches to introduce these accessor macros be considered separately,
or should I only submit them as part of the big patch for PR44566?
Would patches for this be considered separately?
I would always prefer to see smaller patches. I can't
Tomás Touceda chi...@gmail.com writes:
I'm starting to dig a little bit in what gcc does to protect the stack
from overflows and attacks of that kind. I've found some docs and
patches, but they aren't really up to date.
See the -fstack-protector and -fstack-check options.
Ian
--- Comment #5 from aoliva at gcc dot gnu dot org 2010-06-23 07:00 ---
I've just run into this very problem building i-c.adb on ia64-linux-gnu, using
gcc-3.4.6 as the bootstrap compiler to build today's trunk daily bump, r161240.
I think I hadn't had Ada enabled on this platform
--- Comment #6 from charlet at gcc dot gnu dot org 2010-06-23 07:09 ---
Subject: Bug 0
Author: charlet
Date: Wed Jun 23 07:08:46 2010
New Revision: 161255
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161255
Log:
PR 0
* doc/install.texi: Update
--- Comment #7 from charlet at gcc dot gnu dot org 2010-06-23 07:11 ---
Doc updated.
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from charlet at gcc dot gnu dot org 2010-06-23 07:48 ---
Subject: Bug 0
Author: charlet
Date: Wed Jun 23 07:47:57 2010
New Revision: 161256
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161256
Log:
Replace PR 0 by PR ada/0.
Modified:
When cc1 is build using --enable-build-with-cxx, it is nigh impossible to
debug because the variables insn_data and df share their name with the
struct tags of the element / pointed-to data.
I believe the struct tags should be renamed, e.g. insn_data_d and df_d.
--
Summary: type/data
--- Comment #2 from amylaar at gcc dot gnu dot org 2010-06-23 08:58 ---
Should I add PR44644 to the list of PRs blocking this one? Although you
can bootstrap gcc without fixing that PR, it causes considerable problems
when debugging gcc, and it could be easily fixed.
--
--- Comment #2 from charlet at gcc dot gnu dot org 2010-06-23 09:15 ---
Subject: Bug 44633
Author: charlet
Date: Wed Jun 23 09:14:55 2010
New Revision: 161264
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161264
Log:
2010-06-23 Thomas Quinot qui...@adacore.com
*
--- Comment #3 from charlet at gcc dot gnu dot org 2010-06-23 09:15 ---
Fixed on trunk.
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pini_os at yahoo dot fr 2010-06-23 09:53 ---
(In reply to comment #3)
Fixed on trunk.
Thanks for the fix and the reactivity.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44633
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-06-23 10:08 ---
Created an attachment (id=20985)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20985action=view)
patch from multi-target-20100613-branch
This is the patch that I have just unbundled from
this breaks debugging of std::map and other tree-based containers in the
library, see http://gcc.gnu.org/ml/libstdc++/2010-06/msg00159.html for more
info
$ cat debug2.cc
struct S
{
typedef S* ptr;
ptr p;
};
int main()
{
S s = { };
return !s.p;
}
$ $GCC45/bin/g++ -g
--- Comment #3 from jsm28 at gcc dot gnu dot org 2010-06-23 11:07 ---
This is a bug in the AVR back end; if it marks a decl readonly it must also
adjust the type of the decl. The problem code is probably in
avr_insert_attributes.
--
jsm28 at gcc dot gnu dot org changed:
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org
|dot org
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-23
12:07 ---
Subject: Re: -pthreads option with -shared does not cause libpthread.so to
be linked in.
I've found that the Sun Studio compiler behaves the same with its -mt
option and asked the maintainers about it:
--- Comment #4 from mikpe at it dot uu dot se 2010-06-23 12:12 ---
Created an attachment (id=20986)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20986action=view)
test long long to double runtime conversions
Making the constant signed rather than unsigned makes no difference.
I
--- Comment #21 from sfilippone at uniroma2 dot it 2010-06-23 12:20 ---
(In reply to comment #20)
(In reply to comment #14)
The attached variation of generic_23 still does not work.
... and the dump shows why:
The specific PPCs of 'foo2' point to the right procedures, but
--- Comment #3 from amylaar at gcc dot gnu dot org 2010-06-23 13:19 ---
spu patches have been committed to trunk, the remaining issue is PR44512.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44640
--- Comment #2 from amylaar at gcc dot gnu dot org 2010-06-23 13:41 ---
A patch is here:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02330.html
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-06-23 13:48
---
The relevance of that behavior has gone with the unified process model
in Solaris 10, and it's causing me trouble when implementing TLS support
for Solaris 8 and 9, so I'm going to fix this for 4.6.0, together
DO [,] CONCURRENT forall-header
is a special loop variant with some extra constraints; in particular, it allows
the compiler to run through the loop in any index order.
That's somewhat similar to FORALL (or at least to how FORALL is perceived) but
avoids (a) temporaries (which FORALL often
--- Comment #3 from burnus at gcc dot gnu dot org 2010-06-23 14:13 ---
[Cf. also Corrigenda 1 to 5 (informal collection of these 5 documents)
ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1823.pdf (F2008 should incorporate
those changes)] Current (on-going) interpretation requests:
--- Comment #4 from burnus at gcc dot gnu dot org 2010-06-23 14:21 ---
Add another J3 meeting #192 link, which is only a discussion item, but give
some idea: http://j3-fortran.org/doc/meeting/192/10-164.txt
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
--- Comment #3 from amylaar at gcc dot gnu dot org 2010-06-23 14:25 ---
Subject: Bug 44644
Author: amylaar
Date: Wed Jun 23 14:25:33 2010
New Revision: 161281
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161281
Log:
PR other/44644
* df-core.c (struct df): Rename
The definitions of std::nothrow, __new_handler and std::bad_alloc are in the
same file. This is bad since the std::bad_alloc definition pulls in the
exception support. The std::bad_alloc definitions should be placed into a
separate file.
--
Summary: std::nothrow and std::bad_alloc
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-23 14:57 ---
(In reply to comment #0)
The std::bad_alloc definitions should be placed into a
separate file.
IIUC that wouldn't work, new is required to declare bad_alloc, so if
bad_alloc was moved to a separate file, the parts
--- Comment #2 from sebastian dot huber at embedded-brains dot de
2010-06-23 15:02 ---
(In reply to comment #1)
(In reply to comment #0)
The std::bad_alloc definitions should be placed into a
separate file.
IIUC that wouldn't work, new is required to declare bad_alloc, so if
--- Comment #3 from redi at gcc dot gnu dot org 2010-06-23 15:14 ---
OK, now I understand what you're suggesting.
Confirmed as a valid enhancement request.
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from sebastian dot huber at embedded-brains dot de
2010-06-23 15:20 ---
Created an attachment (id=20987)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20987action=view)
Moves std::bad_alloc implementation into new file bad_alloc.cc
I don't know how to regenerate
--- Comment #5 from redi at gcc dot gnu dot org 2010-06-23 15:24 ---
leave it to me (apart from not including the re-generated autoconf file, your
patch doesn't update the Copyright dates)
--
redi at gcc dot gnu dot org changed:
What|Removed
gcc warns about the unused variable on line 3 below but not for the one on line
8. I would expect to see a warning in both cases.
$ cat -n z.cpp g++ -O2 -Wunused z.cpp
1 int main()
2 {
3 if (bool b = 1)
4 return 0;
5 else
6 return 1;
Cf. F2008:
13.7.160 STORAGE SIZE (A [, KIND])
Description. Storage size in bits.
Class. Inquiry function.
Arguments.
A shall be a scalar or array of any type. If it is polymorphic it shall
not be an undefined pointer. If it has any deferred type parameters it
--- Comment #4 from weasel at cs dot stanford dot edu 2010-06-23 15:59
---
thanks for the hint about avr_insert_attribute. there's a comment there
mumbling:
/* ??? This seems sketchy. Why can't the user declare the
thing const in the first place? */
when it sets the
Opensuse 10.2
-
gcc -v:
ma...@pc-31c:~ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/marco/local/gcc-4.5.0/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-threads=posix
--- Comment #1 from morandini at aero dot polimi dot it 2010-06-23 16:02
---
Created an attachment (id=20988)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20988action=view)
preprocessed file triggering the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44650
--- Comment #5 from jsm28 at gcc dot gnu dot org 2010-06-23 16:35 ---
An assertion failure is always a bug. Yes, an error if the object
isn't already const would be one valid fix.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2010-06-23 16:45 ---
Cf. PR 40569 for two other module procedures of ISO_C_BINDING
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40568
--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-23 16:46 ---
Cf. PR 40568 for C_SIZEOF, a F2008 module procedure of ISO_C_BINDING
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40569
--- Comment #4 from paul dot richard dot thomas at gmail dot com
2010-06-23 17:36 ---
Subject: Re: [OOP] Dynamic dispatch uses broken types
Tobias,
On Tue, Jun 22, 2010 at 5:00 PM, burnus at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #2 from burnus at gcc
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-06-23 19:39 ---
This works for me and many other people.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2010-06-23 20:20
---
Can you try reducing the reproducer to something more manageable? Here you can
find some tips: http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44650
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu dot
|
--- Comment #4 from amylaar at gcc dot gnu dot org 2010-06-23 23:32 ---
Subject: Bug 44640
Author: amylaar
Date: Wed Jun 23 23:32:38 2010
New Revision: 161299
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161299
Log:
PR target/44640
* config/spu/spu-protos.h
--- Comment #4 from amylaar at gcc dot gnu dot org 2010-06-23 23:35 ---
Subject: Bug 44644
Author: amylaar
Date: Wed Jun 23 23:35:04 2010
New Revision: 161300
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161300
Log:
PR other/44644
* df-core.c (struct df): Rename
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-06-23 23:51 ---
Subject: Bug 44637
Author: amylaar
Date: Wed Jun 23 23:51:11 2010
New Revision: 161301
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161301
Log:
PR bootstrap/44637
* config/rs6000/rs6000.c
The new testcases...
r161063 | ktietz | 2010-06-21 03:27:19 -0400 (Mon, 21 Jun 2010) | 6 lines
2010-06-21 Kai Tietz kai.ti...@onevision.com
* gcc.target/x86_64/abi/callabi/leaf-1.c: New.
* gcc.target/x86_64/abi/callabi/leaf-2.c: New.
fail on x86_64-apple-darwin10 as
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-06-24
00:59 ---
Created an attachment (id=20989)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20989action=view)
leaf-1.s from x86_64-apple-darwin10
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44651
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-06-24
00:59 ---
Created an attachment (id=20990)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20990action=view)
leaf-2.s from x86_64-apple-darwin10
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44651
-4.6-20100623/gcc/testsuite/gcc.target/x86_64/abi/callabi/leaf-1.c
-O2 -mabi=sysv -S -o leaf-1.s
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100623/gcc/testsuite/gcc.target/x86_64/abi
--- Comment #10 from aoliva at gcc dot gnu dot org 2010-06-24 03:34 ---
I can only duplicate this problem, even on 4.5 branch, using an old version of
GDB, on ia64-linux-gnu. With GDB 7.1, it gets the variables as expected.
--
aoliva at gcc dot gnu dot org changed:
What
--- Comment #30 from aoliva at gcc dot gnu dot org 2010-06-24 04:01 ---
Patch installed on 2009-10-01, assuming fixed.
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
76 matches
Mail list logo
