On Mar 9, 2012, Eric Botcazou 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, because the
>
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.
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/
2012
On 15 March 2012 15:40, Richard Guenther wrote:
> On Thu, Mar 15, 2012 at 4:22 PM, Kai Tietz 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 (well, I guess
On Thu, Mar 15, 2012 at 5:09 PM, Bernd Schmidt 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 are invalid,
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
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 i
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 possib
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-swap
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
>
> PR target/52568
> *
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
-mi
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
>>> during the computation have defined semantics. With poi
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
> > during the computation have defined semantics. With pointer types, the
> > intermediate steps of the co
On 03/15/2012 11:12 PM, Zdenek Dvorak wrote:
> the reason unsigned integer types are prefered is that possible overflows
> during the computation have defined semantics. With pointer types, the
> intermediate steps of the computations could have undefined behavior, possibly
> confusing further op
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
wrote:
Hi,
the attached patch changes the low-level libgfortran IO dispatching
mechanism to use shared vtables for each stream
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 a
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 optio
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
afte
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:
powerpc-ibm-ai
On Thu, Mar 15, 2012 at 22:14, Tobias Burnus 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 patch
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, "iroun
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 x8
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
PR target/52568
* config/i386/sse.md (UNSPEC_VPERMDF): Remove.
(a
On Tue, Mar 13, 2012 at 4:01 PM, Ian Lance Taylor 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. This patch
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
> > wrote:
>
> >> committed as r185430.
> >
> >You forgot to add fortran-modules.exp :(
>
> co
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 arithm
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) patc
> "Jakub" == Jakub Jelinek 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 whole
> "DJ" == DJ Delorie 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
library, p
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 c
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, ...)
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 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 in
> 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
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: libffi.c
> "DJ" == DJ Delorie 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 was:
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
>
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
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
> 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 a
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
> wrote:
>> committed as r185430.
>
>You forgot to add fortran-modules.exp :(
committed as r185439.
I am very sorry for that..
>
>That breaks final testing result it seems
Richard Guenter wrote:
> On Thu, Mar 8, 2012 at 3:29 PM, Ulrich Weigand wrote:
> > I'm wondering where to go from there:
> >
> > - Why are those special re-association cases handled only in forwprop,
> > and not in fold-cost? I would have expected forwprop to just propagate
> > subexpressions
Richard Guenther wrote:
> On Thu, Mar 8, 2012 at 3:56 PM, Ulrich Weigand 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 to commi
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 por
On Thu, Mar 15, 2012 at 8:57 AM, Carlos O'Donell
wrote:
> On Thu, Mar 15, 2012 at 11:05 AM, Thomas Schwinge
> 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=4efeffc1d583597e4f52985b9747269e47
> 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 (DEC
Gerald Pfeifer 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 free. In S
Uros Bizjak 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 p
On Thu, Mar 15, 2012 at 1:39 PM, Bernhard Reutner-Fischer
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 that stood out
On Thu, Mar 15, 2012 at 11:05 AM, Thomas Schwinge
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 4efeffc1d583597e4f52985b9747269e47b754e2
>> A
PING! (At this point, obviously for trunk only)
On Mon, Feb 13, 2012 at 20:20, Janne Blomqvist
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 being replicated for e
On Thu, Mar 15, 2012 at 4:22 PM, Kai Tietz 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 (well, I guess so at least).
Jonathan - you didn't answer my reply to
On Thu, 15 Mar 2012, Richard Guenther wrote:
> On Thu, 15 Mar 2012, Eric Botcazou wrote:
>
> > > Ok, I applied a fix for PR52134 and am preparing a fix for PR52578.
> > > It seems we might not be able to rely on
> > >
> > > tree maxsize = size_diffop (TYPE_SIZE_UNIT (DECL_CONTEXT (field)),
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.
Regards,
Kai
> > 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 bes
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
> Date: Sun Feb 26 13:17:27 2012 -0500
>
On Thu, 15 Mar 2012, Eric Botcazou wrote:
> > Ok, I applied a fix for PR52134 and am preparing a fix for PR52578.
> > It seems we might not be able to rely on
> >
> > tree maxsize = size_diffop (TYPE_SIZE_UNIT (DECL_CONTEXT (field)),
> > DECL_FIELD_OFFSET (r
> 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
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
2012/3/15 Richard Guenther :
> On Thu, Mar 15, 2012 at 2:46 PM, Kai Tietz wrote:
>> 2012/3/15 Richard Guenther :
>>> On Thu, Mar 15, 2012 at 2:09 PM, Kai Tietz wrote:
Hi,
this is the second part of the patch for this problem. It adds some
basic simplifications for ==/!=
> Ok, I applied a fix for PR52134 and am preparing a fix for PR52578.
> It seems we might not be able to rely on
>
> tree maxsize = size_diffop (TYPE_SIZE_UNIT (DECL_CONTEXT (field)),
> DECL_FIELD_OFFSET (repr));
> gcc_assert (host_integerp (maxsize, 1)
Eric Botcazou writes:
>> * Although libgcc/config/sparc/sol2-unwind.h could be simplified quite a
>> bit, perhaps we could go further: I wonder if the remaining nframes = 2
>> case really applies to Solaris 9. If not, one could massivly simplify
>> this code.
>
> Please no, let's keep bein
2012/3/15 Richard Guenther :
> On Thu, Mar 15, 2012 at 3:00 PM, Jakub Jelinek 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
>>> >
Ian Lance Taylor writes:
> Rainer Orth writes:
>
>> libgo:
>> * configure.ac (OSCFLAGS): Remove *-*-solaris2.8 handling.
>> (libgo_cv_lib_makecontext_stack_top): Remove
>> sparc*-*-solaris2.8* handling.
>> * configure: Regenerate.
>
> As with the Irix 5 changes, just sen
Ian Lance Taylor writes:
> Rainer Orth 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. Just send me the mainline patches t
> * 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 mu
On Thu, Mar 15, 2012 at 2:46 PM, Kai Tietz wrote:
> 2012/3/15 Richard Guenther :
>> On Thu, Mar 15, 2012 at 2:09 PM, Kai Tietz wrote:
>>> Hi,
>>>
>>> this is the second part of the patch for this problem. It adds some
>>> basic simplifications for ==/!=
>>> comparisons for eliminating redudant o
On Thu, Mar 15, 2012 at 3:00 PM, Jakub Jelinek 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 register
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 comput
2012/3/15 Richard Guenther :
> On Thu, Mar 15, 2012 at 2:08 PM, Kai Tietz 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
>>
2012/3/15 Richard Guenther :
> On Thu, Mar 15, 2012 at 2:09 PM, Kai Tietz 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 ==/!=
On Thu, Mar 15, 2012 at 2:09 PM, Kai Tietz 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.
> ~X ==/!= Z ^ X
On Thu, Mar 15, 2012 at 2:08 PM, Kai Tietz 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 first patch adds to
On Thu, Mar 15, 2012 at 2:06 PM, Jakub Jelinek 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 as (int) lr{
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
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 first patch adds to forward-propagation the ability to do type-hoisting
for some con
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 with
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 refactorin
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 chec
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]
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 some
On 14 March 2012 15:52, Paolo Bonzini wrote:
> Il 14/03/2012 16:37, Ramana Radhakrishnan ha scritto:
>> Empirically I spotted this odd behaviour with
>> gcc_GAS_CHECK_FEATURE and comments - Attached are the 2 alternate
>> patches that I tried and the difference in the configure scripts
>> themsel
On 03/15/2012 02:55 AM, Janne Blomqvist wrote:
On Thu, Mar 15, 2012 at 01:52, Jerry DeLisle 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?
Currently we bail out early when the subscript dependence tester
runs into an unanalyzable dimension. That's overly pessimistic
in case further dimensions reveal non-conflicting access functions
which now happens more times as we introduce artificial dimensions
for COMPONENT_REFs.
Bootstrapped a
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-inter
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.
gna
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
2012-03-1
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
2012-03
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 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 P
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 compi
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 ha
Thanks, committed.
(And sorry for the truncated subject).
Tristan.
On Mar 14, 2012, at 6:50 PM, Jason Merrill wrote:
> OK.
>
> Jason
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
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 Elemen
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 in
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
* exp_ch4.adb (Expand_N_Quantified_Expression): Expand the
original quantified expression node.
* sem_ch4.
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 va
98 matches
Mail list logo
