Hi Andrew,
I can see that rs6000 port uses a flag
"cfun->machine->ra_needs_full_frame = 1".
But I need to check if this flag helps to generate frame for all the
functions in a compilation unit.
The requirement is that frame need to be preserved by any function
that calls our function which uses
Hi,
the attached patch fixes a problem with the movcc pattern on S/390.
I've committed the patch to mainline after a regression test.
Ok for GCC 4.8 branch?
Bye,
-Andreas-
2013-07-29 Dominik Vogt
* config/s390/s390.md ("movcc"): Swap load and store instructions.
---
gcc/config/s
Hi,
On 07/29/2013 02:06 AM, Tim Shen wrote:
On Mon, Jul 29, 2013 at 1:08 AM, Paolo Carlini wrote:
Oh well, thanks. But then I expect specific testcases to come with it, for
the various values of the parameter, both the default and the other other
values. Otherwise, the idea isn't really immedi
On Mon, Jul 29, 2013 at 4:26 PM, Paolo Carlini wrote:
> Minor nit: it's not clear to me why in the previous patch you added the
> includes of and .
I use them in regex_grep_matcher.h and regex_grep_matcher.tcc; Is
include/std/regex the right place where I include them?
--
Tim Shen
Dear Tobias,
I think that Janus's OK of the 27th was already enough :-)
The tweaks that you have made since make it look much cleaner. So,
once more - OK for trunk.
Thanks for the patch
Paul
On 27 July 2013 21:51, Tobias Burnus wrote:
> Tobias Burnus wrote:
>>
>> Giving up on the class.c ver
On 07/29/2013 10:37 AM, Tim Shen wrote:
On Mon, Jul 29, 2013 at 4:26 PM, Paolo Carlini wrote:
Minor nit: it's not clear to me why in the previous patch you added the
includes of and .
I use them in regex_grep_matcher.h and regex_grep_matcher.tcc; Is
include/std/regex the right place where I i
Hi!
We've got assignment form, finally.
I've add Changelog record and two testcases.
Please, review, is it ok to commit?
/*
With optimism,
Evgeny Gavrin
email : evgeny.gav...@hotmail.com
*/
> Date: Tue, 2 Jul 2013 13:54:14 -0700
> Subject: Re: [patch]
On Thu, Jul 25, 2013 at 10:50:14PM -0600, Jeff Law wrote:
> On 07/25/2013 04:40 PM, Joseph S. Myers wrote:
> >On Thu, 25 Jul 2013, Marek Polacek wrote:
> >
> >>So far it sanitizes division-by-zeros, shifts and
> >>__builtin_unreachable calls. This is of course far from being
> >>complete; I intend
Ramana Radhakrishnan writes:
> Hi,
>
> This fixes up the issues with PR target/19599 and the issues we've had
> around it.
...
> 2013-07-25 Ramana Radhakrishnan
>
> PR target/19599
> PR target/57731
> PR target/57748
Are you sure about the 57748 refe
On 26/07/13 16:04, David Malcolm wrote:
The following patch series eliminates the mutable global variables
representing GCC's passes, allowing for multiple compilation contexts in
one process, potentially with different combinations of passes
(e.g. JIT-compilation of JavaScript in one thread, JIT
On 28/07/13 23:03, Maxim Kuvyrkov wrote:
While verifying license compliance for GCC and its libraries I noticed that
several libgcc files that end up in the final library are licensed under
GPL-3.0+ instead of GPL-3.0-with-GCC-exception.
This is, obviously, was not the intention of developers
Ping?
Thanks,
Kyrill
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov
> Sent: 23 July 2013 10:09
> To: 'Richard Sandiford'
> Cc: gcc-patches; mi...@it.uu.se; 'Richard Biener'
> Subject: RE: [PATCH][4.8 backpor
Hello!
Attached patch (that is in fact a variant of HJ's patch) implements
clearing of SSE target register before cvt* instructions (the same
approach as ICC takes).
While there, there is also no need to check for SUBREGs in post-reload
splitters.
2013-07-29 Uros Bizjak
* config/i386/i38
> As a consensual first step toward addressing this issue, I suggest the
> following patch to the doc. I hope it is clear enough, but suggestions are
> obviously welcome. (I haven't even compiled the docs with it, as I'm on my
> laptop with little battery.)
Given that I received no feedback, I'
On 07/29/2013 02:06 PM, FX wrote:
> +build of a native compiler on @samp{x86_64-unknown-linux-gnu}, beware of
> +either:
> +
> +@itemize @bullet
> +@item having 32-bit libc developer package properly installed (the exact
> +name of the package depends on your distro); otherwise, you may encounter a
On Mon, 29 Jul 2013, Maxim Kuvyrkov wrote:
> Marcus, did you and ARM intend to license config/aarch64/sfp-machine.h
> and config/aarch64/sync-cache.c under GPL-3.0-with-GCC-exception?
In general I think it's appropriate for sfp-machine.h files to use the
soft-fp license (LGPLv2.1+ with exceptio
On Mon, Jul 29, 2013 at 6:22 AM, Andrew Haley wrote:
> There should be a better diagnostic.
If you remember, the start of this thread was:
> Why is it that configure worked but stubs-32.h was not found?
That is the correct thing to do. The reply, basically, was:
It's too hard.
OK, fine,
Hi all,
Now that combine emits the canonical form for (eq (neg x) (y)) instead of (eq
(x) (neg y)), this patch fixes up the corresponding pattern in aarch64 to
match that. This enables combine to properly generate the cmn instruction
where appropriate.
Tested aarch64-none-elf on model.
Ok for tr
On Mon, Jul 29, 2013 at 12:10:42PM +0100, Marcus Shawcroft wrote:
> On 28/07/13 23:03, Maxim Kuvyrkov wrote:
> >While verifying license compliance for GCC and its libraries I noticed that
> >several libgcc files that end up in the final library are licensed under
> >GPL-3.0+ instead of GPL-3.0-wi
On 07/29/2013 02:55 PM, Bruce Korb wrote:
> On Mon, Jul 29, 2013 at 6:22 AM, Andrew Haley wrote:
>
>> There should be a better diagnostic.
>
> If you remember, the start of this thread was:
>
>> Why is it that configure worked but stubs-32.h was not found?
>
> That is the correct thing to do.
On Sat, 27 Jul 2013, Richard Sandiford wrote:
> > gcc/
> > * config/mips/linux.h (GLIBC_DYNAMIC_LINKER): Handle `-mnan=2008'.
> > (UCLIBC_DYNAMIC_LINKER): New macro.
> > * config/mips/linux64.h (GLIBC_DYNAMIC_LINKER32): Handle
> > `-mnan=2008'.
> > (GLIBC_DYNAMIC_LINKER64,
> I think that Janus's OK of the 27th was already enough :-)
>
> The tweaks that you have made since make it look much cleaner. So,
> once more - OK for trunk.
Agreed. Sorry for the late reply,
Janus
> On 27 July 2013 21:51, Tobias Burnus wrote:
>> Tobias Burnus wrote:
>>>
>>> Giving up on t
On Mon, 2013-07-29 at 11:19 +0100, Richard Earnshaw wrote:
> On 26/07/13 16:04, David Malcolm wrote:
> > The following patch series eliminates the mutable global variables
> > representing GCC's passes, allowing for multiple compilation contexts in
> > one process, potentially with different combin
Looks good.
Jason
On Sun, 2013-07-28 at 10:37 +0200, Basile Starynkevitch wrote:
> On Fri, 2013-07-26 at 11:04 -0400, David Malcolm wrote:
> > This patch is the hand-written part of the conversion of passes from
> > C structs to C++ classes. It does not work without the subsequent
> > autogenerated part, which is h
On 07/28/2013 03:34 PM, Joseph S. Myers wrote:
On Fri, 26 Jul 2013, Andrew MacLeod wrote:
What it doesn't do:
* It doesn't implement the stdatomic.h header - do you intend that to be
provided by GCC or glibc?
(Substantive review of the full patch still to come.)
I figured gcc would provide
On Thu, 2013-07-18 at 07:56 -0700, Andrew Pinski wrote:
> On Thu, Jul 18, 2013 at 4:33 AM, David Malcolm wrote:
> > On Thu, 2013-07-18 at 00:08 -0700, Andrew Pinski wrote:
> >> On Wed, Jul 17, 2013 at 6:18 PM, David Malcolm wrote:
> >> > gcc/
> >> >
> >> > Explicitly number the instances
On Mon, 29 Jul 2013, Andrew MacLeod wrote:
> Blick. What were they smoking the night before... I guess we'll probably need
> to enhance the current atomic patterns in RTL...We should be able to
> figure out that its floating point and invoke the appropriate RTL pattern
> during expansion rathe
On 07/29/2013 10:59 AM, Andrew MacLeod wrote:
Blick. What were they smoking the night before... I guess we'll
probably need to enhance the current atomic patterns in RTL...We
should be able to figure out that its floating point and invoke the
appropriate RTL pattern during expansion rather
This changes the handling of SHLIB so that it is inlined into
DRIVER_DEFINES. This is ok because SHLIB is defined in a Makefile
fragment that is included by the generated Makefile.
The rationale for this is that it simplifies some .o targets, so that
we can share more code.
* Makefile.in
This is a refresh of my series to resurrect automatic dependency
tracking. v1 was posted here:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01218.html
Compared to v1:
* I ran the "hanging test" using GNU make 3.81 on each revision, as
detailed:
http://gcc.gnu.org/ml/gcc-patches/2013-
A few generated files were not mentioned in the generated_files
variable. This fixes the problem.
* Makefile.in (generated_files): Add options.h,
target-hooks-def.h, insn-opinit.h,
common/common-target-hooks-def.h.
---
gcc/Makefile.in | 4 +++-
1 file changed, 3 insertion
This converts the C++ front end.
This renames g++spec.o to cp/g++spec.o for uniformity.
This lets us remove an explicit rule.
This patch does not remove various *_H macros from cp/Make-lang.in.
These are still needed by ObjC++. They're removed by a later patch.
* Make-lang.in (g++spec.o
There is an order-only dependency in gcc/Makefile.in that tries to
build the generated files before compiling regular objects. However,
this appears too early, and so at the time it is seen by make,
GCOV_OBJS and GCOV_DUMP_OBJS have not yet been set.
This patch fixes the problem and prevents any
This converts the C front end.
Note that this fixes a latent bug in gcc/Makefile.in's definition of
C_TREE_H. This is needed to avoid breaking this build with this
patch.
* Makefile.in (C_TREE_H): Reference c/c-tree.h.
* Make-lang.in (c/gccspec.o): Remove.
(CFLAGS-c/gccs
This converts the ObjC front end.
Note that there is a latent possible bug in this code -- both ObjC and
ObjC++ define START_HDRS. Whichever is included last, wins; if they
are out of sync, then something could break. This possibility is
eliminated by this series.
* Make-lang.in (START_
This converts the ObjC++ front end.
Now we can finally remove the *_H macros from cp/Make-lang.in.
* Make-lang.in (CXX_TREE_H, CXX_PARSER_H, CXX_PRETTY_PRINT_H):
Remove.
* Make-lang.in (START_HDRS, cc1objplus-checksum.o)
(objcp/objcp-lang.o, objcp/objcp-decl.o
This converts the Java front end.
We also rename jvspec.o to java/jvspec.o, for uniformity; this lets us
remove an explicit rule.
* Make-lang.in (jvspec.o): Remove.
(CFLAGS-java/jvspec.o): New variable.
($(XGCJ)$(exeext), java_OBJS): Use java/jvspec.o
(java/jvspec.
This removes manual dependencies for the c-family .o files.
* Makefile.in (c-family/cppspec.o, c-family/c-common.o)
(c-family/c-cppbuiltin.o, c-family/c-dump.o, c-family/c-format.o)
(c-family/c-gimplify.o, c-family/c-lex.o, c-family/c-omp.o)
(c-family/c-opts.o, c-fa
This convert fortran.
It renames gfortranspec.o to fortran/gfortranspec.o, for uniformity
and to allow removing an explicit rule.
* Make-lang.in (fortran_OBJS): Use fortran/gfortranspec.o.
(gfortranspec.o): Remove.
(CFLAGS-fortran/gfortranspec.o): New variable.
(GF
There is a single definition of CROSS_FLOAT_H in the source.
As far as I can tell, this is never used anywhere.
So, this patch removes it.
* config/mcore/t-mcore (CROSS_FLOAT_H): Remove.
---
gcc/config/mcore/t-mcore | 3 ---
1 file changed, 3 deletions(-)
diff --git a/gcc/config/mcore/t-
This converts LTO.
This also fixes a latent buglet in lto/Make-lang.in. lto_OBJS should
hold all the objects for a language, but LTO never defined this.
* Make-lang.in (LTO_H, LINKER_PLUGIN_API_H, LTO_TREE_H)
(lto/lto-lang.o, lto/lto.o, lto/lto-partition.o)
(lto/lto-objec
This converts Go.
It renames gospec.o to go/gospec.o, for uniformity and so we can
remove an explicit rule.
It defines go_OBJS, to conform to the documented Make-lang.in
conventions, and to ensure that Go objects are given the correct
order-only dependencies on generated files.
* Make-la
I used this perl script to find unused _H macros in the Makefile. I
deleted the definitions it reported and re-ran the script, until there
was no more output.
The script also makes note of _H variables which are used but never
defined. That is how I found the TREE_GIMPLE_H use, fixed earlier in
There is a single reference to TREE_GIMPLE_H in the source tree.
Since it is not defined anywhere, we might as well remove the use.
* config/i386/t-i386 (i386.o): Don't use TREE_GIMPLE_H.
---
gcc/config/i386/t-i386 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/co
This is a small change to make out_object_file use automatic
dependencies.
* Makefile.in ($(out_object_file)): Use COMPILE and POSTCOMPILE.
---
gcc/Makefile.in | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 47ecaf8.
This adds the configury needed for automatic dependency tracking. It
also adds some bits to the Makefile so we can begin converting
(removing) explicit dependencies.
* Makefile.in (CCDEPMODE, DEPDIR, depcomp, COMPILE.base)
(COMPILE, POSTCOMPILE): New variables.
(.cc.o .c.o
On 07/29/2013 12:06 PM, Joseph S. Myers wrote:
On Mon, 29 Jul 2013, Andrew MacLeod wrote:
Blick. What were they smoking the night before... I guess we'll probably need
to enhance the current atomic patterns in RTL...We should be able to
figure out that its floating point and invoke the appr
On Jul 29, 2013, at 8:23 AM, David Malcolm wrote:
> How about "gcc::pass_manager"?
I like this name a whole lot better.
On Mon, Jul 29, 2013 at 11:23 AM, David Malcolm wrote:
> How about "gcc::pass_manager"?
Yes, please.
Diego.
On Jul 29, 2013, at 9:24 AM, Tom Tromey wrote:
> +objcp/objc-runtime-shared-support.o : objc/objc-runtime-shared-support.c
> +objcp/objc-gnu-runtime-abi-01.o: objc/objc-gnu-runtime-abi-01.c
> +objcp/objc-next-runtime-abi-01.o: objc/objc-next-runtime-abi-01.c
> +objcp/objc-next-runtime-abi-02.o:
On Jul 29, 2013, at 9:24 AM, Tom Tromey wrote:
> This converts the ObjC front end.
Thanks.
On Mon, 29 Jul 2013, Andrew MacLeod wrote:
> complex I hadn't thought about until just now, I'll have to look. I know we
> can deal with parts on complex sometimes. Hopefully at gimplification time
> we still have the whole complex reference and if we just take care of that
> with the atomic bu
> "Mike" == Mike Stump writes:
>> +objcp/objcp-act.o : objc/objc-act.c
>> +objcp/objc-encoding.o : objc/objc-encoding.c
>> +objcp/objc-map.o : objc/objc-map.c
Mike> Please, no space before :. Ok with that.
I'll make the change, but please note that this is how it was before my
patch. This
On Jul 29, 2013, at 9:24 AM, Tom Tromey wrote:
> This is a refresh of my series to resurrect automatic dependency
> tracking.
I've looked over the whole set and I like the direction. Thanks.
Hi,
this testcase triggers the gcc_assert in initialize_reference because
the conv returned by reference_binding has conv->kind == ck_ambig.
Before the crash, the diagnostic about ambiguous conversion is produced
by build_user_type_conversion_1, and it seems that in this case too we
can safe
Hi,
A shortcoming of older versions of GAS makes branch swapping not happen
if the instruction to be reordered into a branch delay slot immediately
follows a delay slot of another branch. This happens to hit some MIPS16
call stubs, e.g. (from libgcc.a):
<__mips16_call_stub_sf_0>:
On 07/29/2013 12:42 PM, Joseph S. Myers wrote:
On Mon, 29 Jul 2013, Andrew MacLeod wrote:
complex I hadn't thought about until just now, I'll have to look. I know we
can deal with parts on complex sometimes. Hopefully at gimplification time
we still have the whole complex reference and if we
On Thu, 2013-07-25 at 15:08 +0200, Martin Jambor wrote:
> Hi,
>
> I don't know why it's me again but again I do have a few comments.
Thanks for looking over the patch.
> One global remark first: If we are going to start using the gcc
> namespace (I understand it you need for isolation of symbols
This is the revised version of my patch #8 for power8 support. I have removed
all of the incidental changes, and only added the support for load fusion. I
have added support for fusion on 32-bit Linux. I have added a test to make
sure the fusion ops are being generated.
I have built a compiler
On 07/27/2013 06:51 PM, Bill Schmidt wrote:
PR57993 reports a scenario where a conditional candidate is incorrectly
replaced when its putative "hidden basis" (the basis hidden by one or
more PHI nodes) does not dominate all of the PHI nodes on which the
candidate depends.
This indicates that the
On Mon, 2013-07-29 at 14:20 -0400, David Malcolm wrote:
> >
> > The same here and at a few other places. It may be just me not being
> > used to references... nevertheless, if someone really wants to use
> > them like this, at least make them const and you will save a night of
> > frantic debuggi
On 07/23/2013 03:32 PM, pcha...@cs.wisc.edu wrote:
Hi,
The problem appears in revision 201034 in version 4.9. I attached a
one-line patch that fixes it. I also reported this problem
at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57800
Bootstrap and regression-tested on x86_64-linux.
In method
On 07/23/2013 03:39 PM, pcha...@cs.wisc.edu wrote:
Hi,
The problem appears in revision 201034 in version 4.9. I attached a
one-line patch that fixes it. I also reported this problem
at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57801
Bootstrap and regression-tested on x86_64-linux.
In method
On 07/23/2013 03:42 PM, pcha...@cs.wisc.edu wrote:
Hi,
The problem appears in revision 201034 in version 4.9. I attached a
one-line patch that fixes it. I also reported this problem
at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57791
Bootstrap and regression-tested on x86_64-linux.
In method
On 07/23/2013 03:49 PM, pcha...@cs.wisc.edu wrote:
Hi,
The problem appears in revision 201034 in version 4.9. I attached a
one-line patch that fixes it. I also reported this problem
at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57802
Bootstrap and regression-tested on x86_64-linux.
In method
On 07/23/2013 03:55 PM, pcha...@cs.wisc.edu wrote:
Hi,
The problem appears in revision 201034 in version 4.9. I attached a
one-line patch that fixes it. I also reported this problem
at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57804
Bootstrap and regression-tested on x86_64-linux.
In method
"Maciej W. Rozycki" writes:
> I believe the only legacy MIPS processors that implemented the MIPS16 ASE
> in its original variation (i.e. with no compact jumps, no SAVE/RESTORE,
> and no extend instructions) were the LSI's TinyRISC cores.
Ah, hadn't realised that the original version had no EX
OK.
Richard Sandiford writes:
> "Maciej W. Rozycki" writes:
>> I believe the only legacy MIPS processors that implemented the MIPS16 ASE
>> in its original variation (i.e. with no compact jumps, no SAVE/RESTORE,
>> and no extend instructions) were the LSI's TinyRISC cores.
>
> Ah, hadn't realised
On Thu, 2013-07-18 at 10:25 -0600, Jeff Law wrote:
> On 07/17/2013 07:18 PM, David Malcolm wrote:
> > gcc/
> >
> > Explicitly number the instances of passes within passes.def.
> >
> > This is needed by a subsequent patch so that we can create
> > fields within the pipeline class for eac
On 07/29/2013 10:37 AM, Jason Merrill wrote:
Yep, I'll deal.
Thus.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 1b76aeef615189d8b224201dac911f479900f0f5
Author: Jason Merrill
Date: Mon Jul 29 10:32:20 2013 -0400
* mangle.c (write_name): Check for null context.
(write_u
On 07/26/2013 09:04 AM, David Malcolm wrote:
gcc/
* Makefile.in (PIPELINE_H): New.
(lto-cgraph.o): Depend on CONTEXT_H and PIPELINE_H.
(passes.o): Likewise.
(statistics.o): Likewise.
(cgraphunit.o): Likewise.
(context.o): Depend on PIPELINE_H.
On 07/29/2013 01:32 PM, David Malcolm wrote:
On Thu, 2013-07-18 at 10:25 -0600, Jeff Law wrote:
On 07/17/2013 07:18 PM, David Malcolm wrote:
gcc/
Explicitly number the instances of passes within passes.def.
This is needed by a subsequent patch so that we can create
fie
On 07/26/2013 09:04 AM, David Malcolm wrote:
Introduce a new gen-pass-instances.awk script, and use it at build time
to make a pass-instances.def from passes.def.
An example of the result can be seen at:
http://dmalcolm.fedorapeople.org/gcc/2013-07-25/pass-instances.def
The generated pass-i
On 07/26/2013 09:04 AM, David Malcolm wrote:
With the conversion of passes to C++ classes, plugins that add custom
passes must create them by creating their own derived classes of the
relevant subclass of opt_pass. gcc itself is built with -fno-rtti,
hence there is no RTTI available for the opt_
The interesting case where we encounter a basic block head is when the
check of return_copy for BB_HEAD check succeeds with return_copy being
a label;
then last_insn is a NOTE_INSN_BASIC_BLOCK, and we must not try to split
off a part of the basic block before that note.
That can be properly tes
gcc.c-torture/execute/loop-2e.c was failing at -O3 for lack of an
ashlv2si3 operation, so I added that.
2013-07-29 Joern Rennecke
* config/epiphany/epiphany.md (*isub_i+2): New peephole.
(ashlv2si3): New expander.
(*ashlv2si3_i): New define_insn_and_split.
* pre
2013-07-29 Joern Rennecke
* gcc.dg/tree-ssa/pr44258.c: Disable scan test for Epiphany.
Index: gcc.dg/tree-ssa/pr44258.c
===
--- gcc.dg/tree-ssa/pr44258.c (revision 201313)
+++ gcc.dg/tree-ssa/pr44258.c (working copy)
Hi Tobias,
>> here is a fix for class pointer initialization.
>
> I think the patch looks reasonable.
well, it may appear so ...
> Additionally, the CLASS are wrongly initialized: You only set "_data"
> (indirectly as it is the first field/component of the class) but you do not
> set the _vptr
On Mon, 29 Jul 2013, Richard Sandiford wrote:
> > I believe the only legacy MIPS processors that implemented the MIPS16 ASE
> > in its original variation (i.e. with no compact jumps, no SAVE/RESTORE,
> > and no extend instructions) were the LSI's TinyRISC cores.
>
> Ah, hadn't realised that th
On 07/29/2013 02:24 PM, Joern Rennecke wrote:
The interesting case where we encounter a basic block head is when
the check of return_copy for BB_HEAD check succeeds with return_copy
being a label; then last_insn is a NOTE_INSN_BASIC_BLOCK, and we must
not try to split off a part of the basic bloc
On 07/26/2013 09:04 AM, David Malcolm wrote:
This patch is the hand-written part of the conversion of passes from
C structs to C++ classes. It does not work without the subsequent
autogenerated part, which is huge.
[ ... ]
With the changes from pipeline -> pass_manager this is fine. As is the
2013/7/29 Janus Weil :
> Hi Tobias,
>
>>> here is a fix for class pointer initialization.
>>
>> I think the patch looks reasonable.
>
> well, it may appear so ...
>
>
>> Additionally, the CLASS are wrongly initialized: You only set "_data"
>> (indirectly as it is the first field/component of the cl
On 07/29/2013 12:06 PM, Joseph S. Myers wrote:
On Mon, 29 Jul 2013, Andrew MacLeod wrote:
I planned to do the work in gimplification... let the atomic decls through,
and during gimplification, loads or stores of an atomic decl would be
converted to the appropriate load or store builtin, and at
>> The attached new version should do the right thing now. At least it
>> shows the correct dump for the original test case as well as yours. It
>> is currently being regtested.
>
> unfortunately it shows a couple of runtime problems with type-bound operators:
>
> FAIL: gfortran.dg/class_defined_op
> Is anyone still working on this?
>
> It would be very useful to include this option in gcc trunk, and have
> either -g1 or -gmlt emit line number information. This saves
> considerable space and time during compilation for large builds where
> full debug info is not needed, but line numbers in st
n 30/07/2013, at 2:06 AM, Ondřej Bílka wrote:
> On Mon, Jul 29, 2013 at 12:10:42PM +0100, Marcus Shawcroft wrote:
>> On 28/07/13 23:03, Maxim Kuvyrkov wrote:
>>> While verifying license compliance for GCC and its libraries I noticed that
>>> several libgcc files that end up in the final library a
88 matches
Mail list logo
