On Thu, Mar 15, 2012 at 01:52, Jerry DeLisle jvdeli...@charter.net wrote:
I like the idea behind this patch. I confess, I have not studied the two
test cases that you are modifying, but the changes seem to stick out with
too many digits there. Is this really correct?
When I get another
This patch implements the new attributes First_Valid and Last_Valid.
These apply to static discrete types with at least one valid value.
The static discrete type may have a static predicate (which is the
case where these attributes are useful). They return the lowest and
highest values for which
This patch corrects the previous messy and erroneous analysis of quantified
expression.
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-03-15 Vincent Pucci pu...@adacore.com
* exp_ch4.adb (Expand_N_Quantified_Expression): Expand the
original quantified expression node.
An object declaration of a class-wide object with a tag-indeterminate initial
value is rewritten as a renaming of a dereference. The renaming must preserve
the kind of the object (constant or variable). Previous to this patch, the
compiler failed to reject a call to a primitive operation with an
This patch corrects the code which detects whether an interface class-wide
object has been initialized by a controlled function call.
-- Source --
-- element.ads
with Ada.Containers.Indefinite_Doubly_Linked_Lists;
with Ada.Containers.Indefinite_Holders;
package
AI05-288 specifies that subtype conformance is required for actual types for
generic formal access-to-subprogram types, rather than just mode conformance.
This is a binding interpretation.
Compiling pack2.adb must yield:
pack2.adb:4:37: not subtype conformant with declaration at pack1.ads:2
Thanks, committed.
(And sorry for the truncated subject).
Tristan.
On Mar 14, 2012, at 6:50 PM, Jason Merrill wrote:
OK.
Jason
Thanks, committed.
Tristan.
On Mar 14, 2012, at 5:33 PM, Joseph S. Myers wrote:
On Wed, 14 Mar 2012, Tristan Gingold wrote:
Hi,
it happens that some system headers on VMS have #pragma between parameters.
This is spotted by building the Ada runtime.
This patch simply handles them.
A new pragma and aspect Contract_Case is defined, which allows defining
fine-grain specifications that can complement or replace the contract given
by a precondition and a postcondition. Additionally, the Contract_Case pragma
or aspect can be used by testing and formal verification tools. The
The warning option -gnatw.t already issued warnings on suspicious
postconditions. This extends it to contract cases, which is a GNAT
pragma/aspect allowing to express fine-grain contracts. GNAT now detects
these cases on the following code:
$ gcc -c -gnatc -gnatw.t -gnat12 p.ads
1. package
This patch adds the switch (-gnateinn, MAX_INSTANTIATIONS=nn in VMS)
to control the maximum number of instantiations. This may be used to
increase the limit from the default of 8000 in the very rare case
where a single unit legitimately has more than 8000 instantiations.
The following program:
The unit file name is needed when processing Alfa references from subunits,
in the formal verification backend of GNAT. Thus, add the unit file name
information for subunits in the line of the Alfa section that gives the
subunit file name.
Tested on x86_64-pc-linux-gnu, committed on trunk
When all function postconditions and contract-cases get a warning for only
referring to pre-state, there is no need to issue another warning for not
mentioning 'Result. This is in particular the case when there is a single
postcondition.
Tested on x86_64-pc-linux-gnu, committed on trunk
This patch makes the static elaboration model more conservative in the case of
indirect calls, by treating Subp'Access as a call for elaboration purposes.
The following test should print 3, even when compiled with the binder switch
-p, which enables pessimistic (worst-case) elaboration order.
On Wed, 14 Mar 2012, Tristan Gingold wrote:
On Mar 14, 2012, at 5:08 PM, Richard Guenther wrote:
On Wed, 14 Mar 2012, Tristan Gingold wrote:
Hi,
the code to call expand_main_function currently only checks DECL_NAME.
This leads
to a hack in ada/gcc-interface/utils.c to
A rather obvious patch: With proc-pointer dummies, one compared the
address of the pointer and not of the pointer target.
Build and regtested on x86-64-linux.
OK for the trunk? (What's the sentiment regarding backporting to 4.7.1?)
Tobias
PS: The patch looks larger than it is: I converted
On Tue, Mar 13, 2012 at 01:30:29PM -0700, Mike Stump wrote:
On Mar 13, 2012, at 9:38 AM, Bernhard Reutner-Fischer wrote:
Could some of the testsuite maintainers please eyeball?
I've eyed it, the only thing that stood out was:
-foreach testcase [lsort [glob -nocomplain $srcdir/$subdir/*.F]] {
-
On Mar 15, 2012, at 10:37 AM, Richard Guenther wrote:
On Wed, 14 Mar 2012, Tristan Gingold wrote:
On Mar 14, 2012, at 5:08 PM, Richard Guenther wrote:
On Wed, 14 Mar 2012, Tristan Gingold wrote:
Hi,
the code to call expand_main_function currently only checks DECL_NAME.
This
On Thu, 15 Mar 2012, Richard Guenther wrote:
This removes the use of TREE_LISTs for VECTOR_CSTs and instead employs
a similar way of storing elements as TREE_VECs. I copied the
macro interface bits of the CONSTRUCTOR accesses and did a 1:1 transform
at most places to not let refactoring
Hi!
If __builtin_ir{int,ound}{,f,l} expansion through optab fails,
we would end up generating a call to __builtin_ir{int,ound}{,f,l}
function (there is no ir{int,ound}{,f,l} in libm), which is wrong,
we should expand it as (int) lr{int,ound}{,f,l} in that case (similarly
to what we already do
Hi,
this is the second part of the patch for this problem. It adds some
basic simplifications for ==/!=
comparisons for eliminating redudant operands.
It adds the following patterns:
-X ==/!= Z - X - Z ==/!= 0.
~X ==/!= Z ^ X - Z ==/!= ~0
X ==/!= X - Y - Y == 0
X ==/!= X + Y - Y == 0
On Thu, Mar 15, 2012 at 2:06 PM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
If __builtin_ir{int,ound}{,f,l} expansion through optab fails,
we would end up generating a call to __builtin_ir{int,ound}{,f,l}
function (there is no ir{int,ound}{,f,l} in libm), which is wrong,
we should expand it
On Thu, Mar 15, 2012 at 2:08 PM, Kai Tietz ktiet...@googlemail.com wrote
Hi,
The solution for this PR is a mix out of different issues. First is
of course the type-hoisting, but also
it shows some lacks in simplifications on integer-values, and on equal
and none-equal
comparisons.
The
On Thu, Mar 15, 2012 at 2:09 PM, Kai Tietz ktiet...@googlemail.com wrote:
Hi,
this is the second part of the patch for this problem. It adds some
basic simplifications for ==/!=
comparisons for eliminating redudant operands.
It adds the following patterns:
-X ==/!= Z - X - Z ==/!= 0.
2012/3/15 Richard Guenther richard.guent...@gmail.com:
On Thu, Mar 15, 2012 at 2:09 PM, Kai Tietz ktiet...@googlemail.com wrote:
Hi,
this is the second part of the patch for this problem. It adds some
basic simplifications for ==/!=
comparisons for eliminating redudant operands.
It adds
2012/3/15 Richard Guenther richard.guent...@gmail.com:
On Thu, Mar 15, 2012 at 2:08 PM, Kai Tietz ktiet...@googlemail.com wrote
Hi,
The solution for this PR is a mix out of different issues. First is
of course the type-hoisting, but also
it shows some lacks in simplifications on
On Thu, Mar 15, 2012 at 02:53:10PM +0100, Kai Tietz wrote:
This looks like to match unbound pattern sizes and thus does not fit
into the forwprop machinery. Instead it was suggested elsewhere
that promoting / demoting registers should be done in a separate pass
where you can compute a
On Thu, Mar 15, 2012 at 3:00 PM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Mar 15, 2012 at 02:53:10PM +0100, Kai Tietz wrote:
This looks like to match unbound pattern sizes and thus does not fit
into the forwprop machinery. Instead it was suggested elsewhere
that promoting / demoting
On Thu, Mar 15, 2012 at 2:46 PM, Kai Tietz ktiet...@googlemail.com wrote:
2012/3/15 Richard Guenther richard.guent...@gmail.com:
On Thu, Mar 15, 2012 at 2:09 PM, Kai Tietz ktiet...@googlemail.com wrote:
Hi,
this is the second part of the patch for this problem. It adds some
basic
* config/sparc/sparc.c (sparc_handle_vis_mul8x16): Adjust interface
and implementation.
(sparc_fold_builtin): Adjust.
OK modulo:
/* Multiply the vector elements in ELTS0 to the elements in ELTS1 as
specified by FNCODE. All of the elements in ELTS0 and ELTS1 lists must
Ian Lance Taylor i...@google.com writes:
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
* I'm removing IRIX-specific parts of libgo. Given that libgo is
imported from upstream (and supposed to work or made work on the 4.7
branch), I don't know if this a good idea.
Yeah, it's not.
Ian Lance Taylor i...@google.com writes:
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
libgo:
* configure.ac (OSCFLAGS): Remove *-*-solaris2.8 handling.
(libgo_cv_lib_makecontext_stack_top): Remove
sparc*-*-solaris2.8* handling.
* configure: Regenerate.
As
2012/3/15 Richard Guenther richard.guent...@gmail.com:
On Thu, Mar 15, 2012 at 2:46 PM, Kai Tietz ktiet...@googlemail.com wrote:
2012/3/15 Richard Guenther richard.guent...@gmail.com:
On Thu, Mar 15, 2012 at 2:09 PM, Kai Tietz ktiet...@googlemail.com wrote:
Hi,
this is the second part of the
Hello!
SSE ABI entries for i?86 in glibc were rejected. ?I proposed them like
4-5 years ago to make -mfpmath=sse not suck.
With the new libm hopefully this can be revisited.
But there's the ABI and there's the internal implementation.
My point was just that relying on x87 fully again does
If we are, we'll never learn if this code is needed on anything beyond
Solaris 8 and keep this cruft around basically forever.
So what? This file is a big kludge and there is no value whatsoever in it
being elegant or particularly readable or even efficient.
I'll at least try a bootstrap
Hi!
On 26 Feb 2012 18:17:52 -, drep...@sourceware.org wrote:
http://sources.redhat.com/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=4efeffc1d583597e4f52985b9747269e47b754e2
commit 4efeffc1d583597e4f52985b9747269e47b754e2
Author: Ulrich Drepper drep...@gmail.com
Date: Sun Feb 26 13:17:27
I wasn't trying to be pompous! It's just our project name, but I
thought fission to be quite appropriate for what it does. How does
-gsplit or -gsplit-dwarf work for you?
Or -gsplit-debug?
-g is already supposed to convey the debug, so I think that -gsplit-dwarf is
the best proposal (and
PING! (At this point, obviously for trunk only)
On Mon, Feb 13, 2012 at 20:20, Janne Blomqvist
blomqvist.ja...@gmail.com wrote:
Hi,
the attached patch changes the low-level libgfortran IO dispatching
mechanism to use shared vtables for each stream type, instead of all
the function pointers
On Thu, Mar 15, 2012 at 11:05 AM, Thomas Schwinge
tho...@codesourcery.com wrote:
Hi!
On 26 Feb 2012 18:17:52 -, drep...@sourceware.org wrote:
http://sources.redhat.com/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=4efeffc1d583597e4f52985b9747269e47b754e2
commit
On Thu, Mar 15, 2012 at 1:39 PM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
On Tue, Mar 13, 2012 at 01:30:29PM -0700, Mike Stump wrote:
On Mar 13, 2012, at 9:38 AM, Bernhard Reutner-Fischer wrote:
Could some of the testsuite maintainers please eyeball?
I've eyed it, the only thing
Uros Bizjak ubiz...@gmail.com writes:
Hello!
SSE ABI entries for i?86 in glibc were rejected. ?I proposed them like
4-5 years ago to make -mfpmath=sse not suck.
With the new libm hopefully this can be revisited.
But there's the ABI and there's the internal implementation.
My point was
Gerald Pfeifer ger...@pfeifer.com writes:
On Mon, 12 Mar 2012, Rainer Orth wrote:
Tested with make doc/gccinstall.info doc/gccinstall.pdf, ok for mainline
and 4.7 branch?
+Sun does not ship a C compiler with Solaris 2 before Solaris 10, though
+you can download the Sun Studio compilers for
1. is easy, see patch below. 2. is much harder - we need to
compute the bit-offset relative to the bitfield group start,
thus in get_bit_range we do
/* Compute the adjustment to bitpos from the offset of the field
relative to the representative. */
offset = size_diffop
On Thu, Mar 15, 2012 at 8:57 AM, Carlos O'Donell
car...@systemhalted.org wrote:
On Thu, Mar 15, 2012 at 11:05 AM, Thomas Schwinge
tho...@codesourcery.com wrote:
Hi!
On 26 Feb 2012 18:17:52 -, drep...@sourceware.org wrote:
Hi,
On Thu, 15 Mar 2012, Richard Guenther wrote:
The type demotion is PR45397/PR47477 among other PRs. I'd just walk
from the narrowing integer conversion stmts recursively through the
def stmts, see if they can be narrowed, note it, and finally if
everything or significant portion of
Richard Guenther wrote:
On Thu, Mar 8, 2012 at 3:56 PM, Ulrich Weigand uweig...@de.ibm.com wrote:
Ira Rosen posted a couple of vectorizer patches intended for 4.8:
=A0 http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00191.html
=A0 http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00223.html
OK
Computing the offset in stor-layout.c and storing it in DECL_INITIAL?
Ugh. I just realized that the DECL_BIT_FIELD_REPRESENTATIVE is built during
layout... but is overloaded with DECL_QUALIFIER. That's probably the source
of the miscompilation I talked about earlier.
Can we delay it until
On Thu, 15 Mar 2012, Richard Guenther wrote:
c-family/
* c-pretty-print.c (pp_c_initializer_list): Adjust.
The c-family changes are OK.
--
Joseph S. Myers
jos...@codesourcery.com
On 03/14/2012 08:15 PM, Mike Stump wrote:
On Mar 14, 2012, at 10:21 AM, Doug Evans wrote:
The results of running the testsuite in parallel should match the
results when run serially. This patch adds KFAIL counts so that happens.
[There's still a nit that the order of the results don't
Sigh, libiberty is supposed to be a portability library, not a
kitchen-sink for common stuff. Should I give up that premise? Or
should we consider a common dwarf2 helper library, and move even more
of the dwarf2 code into it?
First, you'll notice that the first constant for a given enum is
DJ == DJ Delorie d...@redhat.com writes:
DJ Sigh, libiberty is supposed to be a portability library, not a
DJ kitchen-sink for common stuff. Should I give up that premise? Or
DJ should we consider a common dwarf2 helper library, and move even more
DJ of the dwarf2 code into it?
My reasoning
Iain,
I have posted at http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01799.html
the regtests on powerpc-apple-darwin9 with the patch. I still get the following
failures
FAIL: libffi.call/err_bad_abi.c -O0 -W -Wall execution test
FAIL: libffi.call/err_bad_abi.c -O2 execution test
FAIL:
Finally, there is already stuff in libiberty not related to
portability. E.g., hashtab or the demangler.
Yeah, I know, hence my Should I give up that premise?
I guess I can just put the whole DW_TAG_ prefix in there. That
isn't a big deal. Or if you have some other suggestion, I can
On 03/15/2012 06:48 PM, DJ Delorie wrote:
Finally, there is already stuff in libiberty not related to
portability. E.g., hashtab or the demangler.
Yeah, I know, hence my Should I give up that premise?
Wouldn't it make sense to eventually switch everything to gnulib
for portability instead?
On Mar 15, 2012, at 11:09 AM, Pedro Alves wrote:
Still, kfail is standard DejaGnu, not a GDB invention. It'd be nice not to
need to fork the script for this.
The change is fine for the gcc tree.
On Thu, Mar 15, 2012 at 12:41:54PM -0600, Tom Tromey wrote:
I guess I can just put the whole DW_TAG_ prefix in there.
That isn't a big deal. Or if you have some other suggestion, I can
implement it.
Yeah, I think the either the whole OP_TAG (DW_TAG_foobar, ...), or
OP_TAG (TAG_foobar, ...)
Hi,
since some time GCC has BUILT_IN_IROUND{F,,L}, similar to lround() and
llround() but the result is returned as an integer. As there is no
corresponding libc function, this builtin is expanded to lround{f,l}
except when -ffast-math is used, in which case it enables slightly
shorter and faster
DJ == DJ Delorie d...@redhat.com writes:
Tom Finally, there is already stuff in libiberty not related to
Tom portability. E.g., hashtab or the demangler.
DJ Yeah, I know, hence my Should I give up that premise?
Yeah.
I am not sure there will ever be enough shared code to warrant a new
Jakub == Jakub Jelinek ja...@redhat.com writes:
Jakub On Thu, Mar 15, 2012 at 12:41:54PM -0600, Tom Tromey wrote:
I guess I can just put the whole DW_TAG_ prefix in there.
That isn't a big deal. Or if you have some other suggestion, I can
implement it.
Jakub Yeah, I think the either the
Hi Dominique,
On 15 Mar 2012, at 18:46, Dominique Dhumieres wrote:
I have posted at http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01799.html
the regtests on powerpc-apple-darwin9 with the patch. I still get
the following
failures
thanks - I think the priority is to get this (unwind)
Currently, tree-ssa-loop-ivopts assumes that pointers and integers can
be used interchangeably. It prefers to compute everything in unsigned
integer types rather than pointer types.
On a new target that I'm working on, this assumption is problematic;
casting a pointer to an integer and doing
On Thu, Mar 15, 2012 at 05:56:32PM +0100, Bernhard Reutner-Fischer wrote:
On Thu, Mar 15, 2012 at 04:57:12PM +0100, Richard Guenther wrote:
On Thu, Mar 15, 2012 at 1:39 PM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
committed as r185430.
You forgot to add fortran-modules.exp
On Tue, Mar 13, 2012 at 4:01 PM, Ian Lance Taylor i...@google.com wrote:
The cooperative threading model used by Go works by calling entersyscall
whenever we are about to make a call to a C function that may block.
That was not being done for a call to getaddrinfo used when doing a DNS
lookup.
Hi!
This patch let's -mavx2 use vpermpd instead of vpermq for
V4DFmode __builtin_shuffle (e.g. {1, 2, 3, 0}).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2012-03-15 Jakub Jelinek ja...@redhat.com
PR target/52568
* config/i386/sse.md (UNSPEC_VPERMDF):
Hi!
As noted in the PR, we can vectorize e.g. V4DFmode
__builtin_shuffle (, {1, 2, 3, 0}) in 3 insns, some intra-lane
permutation, followed by swapping of the lanes (vperm2f128) and
finally vblend{pd,ps} that merges in the registers with non-swapped
and swapped lanes.
Bootstrapped/regtested on
Janne Blomqvist wrote:
since some time GCC has BUILT_IN_IROUND{F,,L}, similar to lround() and
llround() but the result is returned as an integer.
Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
OK. Thanks for the patch! Nit: Could you check mathbuiltins.def - at
least in the diff,
On Thu, Mar 15, 2012 at 22:14, Tobias Burnus bur...@net-b.de wrote:
Janne Blomqvist wrote:
since some time GCC has BUILT_IN_IROUND{F,,L}, similar to lround() and
llround() but the result is returned as an integer.
Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
OK. Thanks for the
Latest results for 4.6.x
-tgc
Testresults for 4.6.2:
hppa2.0w-hp-hpux11.11
i386-pc-solaris2.8
i686-pc-linux-gnu
powerpc-apple-darwin8.11.0
sparc-sun-solaris2.8 (2)
x86_64-apple-darwin10.8.0
x86_64-apple-darwin11.3.0
x86_64-unknown-linux-gnu
Testresults for 4.6.2:
jakub and richi analyzed this bug; normally we set DECL_EXTERNAL on all
functions with vague linkage, but we were failing to do so for the
synthesized destructor, which caused problems with devirtualization.
Fixed thus.
Jakub tested the patch. Applying to trunk; will apply to 4.7 branch
This patch mostly adds several test cases reduced from full-scale attempts to
use PPH.
c?anonymous* -- problems handling anonymous/tagless types
c?features* -- problems with benign macro redefinitions
x?tmpldfltparm* -- inappropriately merging default template arguments
It also add an
Hi,
Currently, tree-ssa-loop-ivopts assumes that pointers and integers can
be used interchangeably. It prefers to compute everything in unsigned
integer types rather than pointer types.
On a new target that I'm working on, this assumption is problematic;
casting a pointer to an integer and
On 03/15/2012 11:42 AM, Janne Blomqvist wrote:
PING! (At this point, obviously for trunk only)
Yes, OK for trunk.
On Mon, Feb 13, 2012 at 20:20, Janne Blomqvist
blomqvist.ja...@gmail.com wrote:
Hi,
the attached patch changes the low-level libgfortran IO dispatching
mechanism to use
On Thursday 15 March 2012 11:57:00 Carlos O'Donell wrote:
We should be rebuilding *all* of userspace when glibc changes. It
would be nice if we setup an OpenEmbedded system to rebuild as much of
x86-64 userspace as possible against a new glibc and check for
regressions.
emerge -e world
-mike
On 03/15/12 13:05, Jakub Jelinek wrote:
Hi!
This patch let's -mavx2 use vpermpd instead of vpermq for
V4DFmode __builtin_shuffle (e.g. {1, 2, 3, 0}).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2012-03-15 Jakub Jelinek ja...@redhat.com
PR target/52568
On 03/15/12 13:09, Jakub Jelinek wrote:
Hi!
As noted in the PR, we can vectorize e.g. V4DFmode
__builtin_shuffle (, {1, 2, 3, 0}) in 3 insns, some intra-lane
permutation, followed by swapping of the lanes (vperm2f128) and
finally vblend{pd,ps} that merges in the registers with non-swapped
On Fri, Mar 16, 2012 at 12:20:44AM +0100, Bernd Schmidt wrote:
On 03/16/2012 12:16 AM, Jakub Jelinek wrote:
On Fri, Mar 16, 2012 at 12:03:08AM +0100, Bernd Schmidt wrote:
On 03/15/2012 11:12 PM, Zdenek Dvorak wrote:
the reason unsigned integer types are prefered is that possible overflows
Hi,
Well, what are our rules for whether overflow on POINTER_PLUS_EXPR is
defined or not? A quick search through the headers and docs doesn't turn
up anything. Would there be a downside to defining it as wrapping?
Can you show an example where a POINTER_PLUS_EXPR produced by ivopts
On 03/16/2012 12:44 AM, Jakub Jelinek wrote:
For pointer arithmetics in the IL we assume the C
requirements, pointer arithmetics can be performed only within the same
object, so for
int a[10];
both of the following are invalid, even in the IL:
int *p = a - 1;
int *q = a + 11;
Ok, so what's
On Thu, Mar 15, 2012 at 5:09 PM, Bernd Schmidt ber...@codesourcery.com wrote:
On 03/16/2012 12:44 AM, Jakub Jelinek wrote:
For pointer arithmetics in the IL we assume the C
requirements, pointer arithmetics can be performed only within the same
object, so for
int a[10];
both of the following
On 15 March 2012 15:40, Richard Guenther wrote:
On Thu, Mar 15, 2012 at 4:22 PM, Kai Tietz ktiet...@googlemail.com wrote:
Richard,
ping. I think now could be a good time for applying the patch you
have for this issue as we are in stage 1.
It will still regress the two libstdc++ testcases
Hi there.
This patch backports my PCH on ARM EABI fix[1] for pch/PR45979 to the 4.6
branch. This
fixes PCH support on ARM and tidies up the random pch testsuite failures that
are seen
between runs.
OK for 4.6?
-- Michael
[1] http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00017.html
gcc/
For google/gcc-4_6 branch.
This patch fixes several problems with -gfission:
- Bad index for range list in the compile unit DIE.
- DW_AT_ranges attribute for compile unit in the wrong file.
- Incorrect size for skeleton type unit DIEs.
- Wrote location expression using DW_OP_addr to DWO file.
On Mar 9, 2012, Eric Botcazou ebotca...@adacore.com wrote:
It does that only in case the -g0 build would add the same locs to the
table. Only the DEBUG_INSN_P setting_insn locs are there just in -g builds
and not in -g0 ones.
If that's really supposed to work like so, then this is the bug,
83 matches
Mail list logo
