On 01/08/2015 10:10 PM, Jeff Law wrote:
On 01/08/15 15:08, Sandra Loosemore wrote:
This patch cleans up the documentation of -fvtable-verify, -fvtv-debug,
and -fvtv-counts. The substantive change is to correct the location of
the debug log files per discussion here:
https://gcc.gnu.org/ml/gcc
I've checked in this patch to fix some over-full hboxes (text
overflowing the right margin) in the PDF version of the GCC manual.
More boring tech-writer stuff. :-)
-Sandra
2015-01-10 Sandra Loosemore
gcc/
* doc/invoke.texi (Option Summary): Break long
encourage doing so in an example). After checking the
implementation to see what the option actually does, I decided it would
be better not to name any particular function here.
Checked in under the obvious fix rule.
-Sandra
2015-01-12 Sandra Loosemore
gcc/
* doc/invoke.te
The GNU coding standards say:
"Please do not write ‘()’ after a function name just to indicate it is a
function."
I've checked in this patch to fix some instances of that in the GCC manual.
-Sandra
2015-01-12 Sandra Loosemore
gcc/
* doc/invoke.texi ([-Wsu
t, just grammar.
-Sandra
2012-11-10 Sandra Loosemore
gcc/
* doc/extend.texi: Copy-edit to fix incorrect uses of "which"
and "that" throughout the file.
Index: gcc/doc/extend.texi
===
---
tely
precedes a noun and should be hyphenated. On the other hand, "64 bits"
is a noun phrase and shouldn't be hyphenated. Similar rules apply to
"floating-point" (adjective) versus "floating point" (noun), etc.
-Sandra
2012-11-10 Sandra Loosemore
I've checked in this patch to consistently use "bit-field" in
extend.texi instead of "bitfield" or "bit field". "Bit-field" is listed
in the GCC Coding Conventions as the preferred terminology, for
consistency with the C and C++ standa
Per the GCC Coding Conventions, "builtin" is not a word, and the
preferred terminology already used in most places is "built-in
function". I've checked in this patch to tidy up a bunch of incorrect
uses of "builtin" in extend.texi.
-Sandra
2012-11-
few of the listed markup issues that I
could easily check for with search-and-replace.
-Sandra
2012-11-16 Sandra Loosemore
gcc/
* doc/extend.texi: Various copy-edits to comply with GCC coding
standards for spelling, terminology, and markup, including use of
This patch is another installment in my series of copy-edits to the GCC user
documentation. Here I've cleaned up several Texinfo markup issues relating to
example environments. Checked in under the free-for-all write access policy.
-Sandra
2012-11-18 Sandra Loosemore
of the material and I may attempt to do some
rearrangement to e.g. better group all the attribute discussion together.
-Sandra
2012-12-02 Sandra Loosemore
gcc/
* doc/extend.texi: Various corrections to punctuation and grammar
throughout the file. Use consistent terminology and proper
the
top-level noconfigdirs.
Jeff Johnston has already approved this patch for newlib. OK for gcc, too?
-Sandra
2013-05-06 Sandra Loosemore
* configure.ac (noconfigdirs [nios2-*-*]): Add target-libgloss.
* configure: Regenerated.
I
of tests that were failing because there was nothing left for those
passes to do any more.
I regression-tested this on powerpc-none-eabi. OK to commit?
-Sandra
2013-05-20 Sandra Loosemore
Pat Wellander
gcc/
* config/rs6000/rs6000-protos.h (rs6000_data_alignment):
On 05/20/2013 04:14 PM, Jakub Jelinek wrote:
Isn't this ABI incompatible change? See http://gcc.gnu.org/PR56564
for more info (yeah, different target, but looks exactly the same issue).
If what this new DATA_ALIGNMENT value is optimization rather than an ABI
requirement, then you'll hit the sam
On 05/20/2013 03:20 PM, David Edelsohn wrote:
This seems like a reasonable change and *should* improve performance,
but what is the actual effect on performance, especially recent POWER
processors? We have had some recent cases where increased alignment
hurt performance because of secondary effe
On 05/21/2013 04:04 PM, David Edelsohn wrote:
There are three issues here:
1) Someone in the LTC toolchain team needs to benchmark this patch on POWER7.
That would be great if somebody else could help with that.
2) We need to clarify how the patch affects the ABI because it cannot
break the
On 05/22/2013 02:01 AM, Richard Biener wrote:
On Wed, May 22, 2013 at 3:57 AM, David Edelsohn wrote:
Increasing the alignment of arrays within structs and unions would be
nice, but that probably will change the ABI. I think that they best we
may be able to do is increase the alignment if the a
On 05/23/2013 06:29 AM, Bill Schmidt wrote:
Sandra and David,
The array-alignment patch is performance-neutral with respect to
CPU2006. All variations were in the noise range.
Well, that settles it; I don't see any reason to pursue the patch any
further if it's not a performance win after a
configure option and
build=i686-pc-linux-gnu, host=target=powerpc-linux-gnu, and verifying
that the output of running the resulting gcc with --version --verbose
looked sane.
OK to commit?
-Sandra
2013-05-23 Nathan Sidwell
Sandra Loosemore
gcc/
* config.gcc
bit-field code required, in addition to the
functional changes, can they be done as followup patches or do I need to
work out the entire series of patches in advance?
-Sandra
2013-06-12 Sandra Loosemore
PR middle-end/23623
PR middle-end/48784
PR middle-end/56341
PR middle-
On 06/14/2013 06:31 AM, Richard Biener wrote:
I think we can split the patch up, so let me do piecewise approval of changes.
The changes that remove the packedp flag passing around and remove
the warning code are ok. The store_bit_field_1 change is ok, as is
the similar extract_bit_field_1 cha
ecifying "dg-do run" unconditionally instead of allowing the
dg-require-effective-target mechanism to decide whether the target can
run code compiled with the vectorization options added by vect.exp.
This patch fixes the bad tests. OK to check in?
-Sandra
2014-09-25 Sandra Loosemore
On 09/25/2014 02:04 PM, Sandra Loosemore wrote:
While doing some arm-none-eabi testing, I noticed that a bunch of
gcc.dg/vect tests were causing the target to hang from trying to execute
code compiled with "-mfpu=neon -mfloat-abi=softfp", on a target that
doesn't support those ins
06-16 Sandra Loosemore
gcc/
* expr.h (extract_bit_field): Remove packedp parameter.
* expmed.c (extract_fixed_bit_field): Remove packedp parameter
from forward declaration.
(store_split_bit_field): Remove packedp arg from calls to
extract_fixed_bit_field.
(extract_bit_field_1): Remove pa
The following series of 5 patches is intended to be identical in terms
of code changes to the version I posted last week:
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00750.html
I have just split it up into pieces to make it easier to review:
1 remove -fstrict-volatile-bitfields warnings and
w volatile-bitfields-3.c test pass on some
targets (specifically, x86_64).
This part of the patch series has already been approved, but since it's
probably not useful without the other pieces, I'm deferring checking it
in for now.
-Sandra
2013-06-16 Sandra Loosemore
-volatile-bitfield handling.
This patch is intended to be applied on top of part 1 (they both touch
some of the same code).
-Sandra
2013-06-16 Sandra Loosemore
PR middle-end/48784
PR middle-end/56341
PR middle-end/56997
gcc/
* expmed.c (store_fixed_bit_field): Adjust
laces where the bit range information is being
used.
-Sandra
2013-06-16 Sandra Loosemore
PR middle-end/23623
gcc/
* expr.c (get_bit_range): Handle flag_strict_volatile_bitfields.
Index: gcc/expr.c
===
--- gcc/expr.c (rev
Here are the test cases for the bugs fixed by this patch series. See my
original posting of this patch set
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00750.html
for discussion of which test cases were previously failing on what targets.
-Sandra
2013-06-16 Sandra Loosemore
PR middle
On 06/17/2013 08:41 AM, Joseph S. Myers wrote:
On Mon, 17 Jun 2013, Julian Brown wrote:
IIUC, the incompatibility between the specified
-fstrict-volatile-bitfields behaviour and the C++ memory model is a
recognised deficiency in the ARM EABI. It might be an unpopular
suggestion, but how about d
Ping? I think these are the most recent versions of the unreviewed
patches in the series:
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00287.html
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00760.html
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01085.html
There are also these two parts that
Earlier today I wrote:
On 06/17/2013 08:41 AM, Joseph S. Myers wrote:
On Mon, 17 Jun 2013, Julian Brown wrote:
IIUC, the incompatibility between the specified
-fstrict-volatile-bitfields behaviour and the C++ memory model is a
recognised deficiency in the ARM EABI. It might be an unpopular
su
On 06/17/2013 06:02 PM, Sandra Loosemore wrote:
I had another thought: perhaps -fstrict-volatile-bitfields could remain
the default on targets where it currently is, but it can be overridden
by an appropriate -std= option. Perhaps also GCC could give an error if
-fstrict-volatile-bitfields is
On 06/19/2013 05:10 PM, Joseph S. Myers wrote:
I don't think it's right to depend on the standard version like this. The
existing semantics for GNU C and C++ follow the memory model for all
standard versions, and that's the sort of thing that shouldn't depend on
the target architecture. In the
On 06/16/2013 01:08 PM, Sandra Loosemore wrote:
This part of the patch series fixes problems with bad code being emitted
for unaligned bitfield accesses, as reported in PRs 48784, 56341, and
56997. A secondary goal of this patch was making the bitfield store and
extract code follow similar
On 06/24/2013 06:31 AM, Richard Biener wrote:
On Sun, Jun 23, 2013 at 6:17 PM, Sandra Loosemore
wrote:
On 06/16/2013 01:08 PM, Sandra Loosemore wrote:
This part of the patch series fixes problems with bad code being emitted
for unaligned bitfield accesses, as reported in PRs 48784, 56341
Here is my third attempt at cleaning up -fstrict-volatile-bitfields.
Part 1 removes the warnings and packedp flag. It is the same as in the
last version, and has already been approved. I'll skip reposting it
since the patch is here already:
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00908
might be that some tests for other
targets need similar changes as well.
OK to commit in conjunction with the other patches in this series?
-Sandra
2013-06-30 Sandra Loosemore
gcc/
* config/aarch64/aarch64.c (aarch64_override_options): Don't
override flag_strict_volatile_bitf
n of due to overriding the new memory
model, programmers at least will be less likely to be taken by surprise
when it does something weird with packed structures.
Is this version OK to commit, or at least getting closer? I'd like to
wind this project up soon, somehow or another.
-Sandra
On 06/30/2013 09:32 PM, DJ Delorie wrote:
Given how much trouble I went through to make it the default, I'd
rather not revert all that work... especially since the flag is
*required* for proper operation of the hardware on many of these
targets.
This patch will, or course, silently and obscure
On 06/30/2013 09:24 PM, Sandra Loosemore wrote:
Here is my third attempt at cleaning up -fstrict-volatile-bitfields.
Ping?
Part 1 removes the warnings and packedp flag. It is the same as in the
last version, and has already been approved. I'll skip reposting it
since the patch is
On 07/09/2013 10:23 AM, Sandra Loosemore wrote:
On 06/30/2013 09:24 PM, Sandra Loosemore wrote:
Here is my third attempt at cleaning up -fstrict-volatile-bitfields.
Ping?
...and ping again.
Part 1 removes the warnings and packedp flag. It is the same as in the
last version, and has
On 07/20/2013 01:12 PM, Sandra Loosemore wrote:
On 07/09/2013 10:23 AM, Sandra Loosemore wrote:
On 06/30/2013 09:24 PM, Sandra Loosemore wrote:
Here is my third attempt at cleaning up -fstrict-volatile-bitfields.
Ping?
...and ping again.
...and again. Hmmm.
struct patch_status
improvement over the current docs. ;-)
-Sandra
2013-03-03 Sandra Loosemore
gcc/
* target.def (TARGET_OPTION_VALID_ATTRIBUTE_P): Update comments;
the attribute is now called "target" instead of "option".
(TARGET_OPTION_PRAGMA_PARSE): Likewise, for the pragma.
* doc/t
tch, although target-specific, needs to be
approved by a global reviewer and then propagated to the sourceware.org
binutils-gdb and newlib repositories as well. So, OK to commit?
-Sandra
2014-04-24 Sandra Loosemore
* configure.ac (target_makefile_frag): Set for nios2-*-elf*.
* co
Ping!
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01618.html
-Sandra
t;, which allows the configure test to pass.
OK to commit?
-Sandra
2014-05-12 Catherine Moore
Sandra Loosemore
gcc/
* configure.ac: Fix assembly for explicit JALR relocation check.
* configure: Regenerate.
Ind
The test case gcc.target/mips/loongson-simd.c fails when the multilib
options include -mmicromips. This patch fixes it analogously to how
this test case already ignores MIPS16ness.
OK to commit?
-Sandra
2014-05-12 Nathan Sidwell
Sandra Loosemore
gcc/testsuite
On 05/05/2014 02:32 PM, Sandra Loosemore wrote:
Ping!
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01618.html
And ping again
-Sandra
ven building. So I ended up
testing this patch on a more stable 4.9.0 checkout modified to support
Mentor's extended set of mips-sde-elf multilibs instead.
OK to commit?
-Sandra
2014-05-13 Sandra Loosemore
gcc/
* config/mips/mips.h (enum reg_class): Add JALR_REGS.
t?
-Sandra
2014-05-13 Catherine Moore
Sandra Loosemore
gcc/
* config/mips/mips.c (mips_order_regs_for_local_alloc): Delete.
* config/mips/mips.h (ADJUST_REG_ALLOC_ORDER): Delete.
* config/mips/mips-protos.h (mips_order_regs_for_local_alloc): Delete.
On 05/13/2014 03:41 PM, Richard Sandiford wrote:
Sandra Loosemore writes:
When I was trying to benchmark another patch (which I'll be sending
along shortly) with CSiBE for -mabi=64, I ran into an assembler error
like this:
/tmp/ccJv2faG.s: Assembler messages:
/tmp/ccJv2faG.s:1605: Err
On 05/14/2014 12:49 PM, Richard Sandiford wrote:
Jeff Law writes:
On 05/13/14 14:11, Sandra Loosemore wrote:
2014-05-13 Catherine Moore
Sandra Loosemore
gcc/
* config/mips/mips.c (mips_order_regs_for_local_alloc): Delete.
* config/mips/mips.h
g that was not there before; previously the failure mode
was to quietly generate long conditional branches everywhere instead of
an ICE.
-Sandra
2014-05-14 Sandra Loosemore
gcc/
* config/nios2/nios2.md (nios2_cbranch): Fix paste-o in
length attribute computation.
to $baseline_subdir_switch
after the check for missing bits instead of before. OK to commit?
-Sandra
2014-05-16 Iain Sandoe
Sandra Loosemore
libstdc++-v3/
* testsuite/libstdc++-abi/abi.exp: Defer setting of baseline_subdir
until after checking that t
It appears that this patch from last fall never got reviewed.
https://gcc.gnu.org/ml/gcc-patches/2013-10/msg02340.html
Can someone take a look? I'll commit the patch on Cesar's behalf if
it's approved.
-Sandra
On 05/16/2014 11:25 AM, Jan Hubicka wrote:
Hi,
this patch adds code to remove write only static variables. While analyzing
effectivity of LTO on firefox, I noticed that surprisingly large part of
binary's data segment is occupied by these. Fixed thus.
(this is quite trivial transformation, I ju
On 05/18/2014 02:59 PM, Jan Hubicka wrote:
Sandra,
This patch seems quite similar in purpose to the
remove_local_statics optimization that Mentor has proposed, although
the implementation is quite different. Here is the last version of
our patch, prepared by Bernd Schmidt last year:
https://gc
ps-sde-elf
using Mentor's usual assortment of multilibs, specifically including one
for microMIPS.
-Sandra
2014-05-19 Iain Sandoe
Catherine Moore
Sandra Loosemore
gcc/
* config/mips/mips.c (mips_set_current_function): Choose
function ali
On 05/17/2014 04:07 AM, Jonathan Wakely wrote:
On 17 May 2014 10:50, Jonathan Wakely wrote:
On 17 May 2014 01:16, Sandra Loosemore wrote:
It appears that this patch from last fall never got reviewed.
https://gcc.gnu.org/ml/gcc-patches/2013-10/msg02340.html
Can someone take a look? I&#x
On 05/18/2014 08:45 PM, Sandra Loosemore wrote:
On 05/18/2014 02:59 PM, Jan Hubicka wrote:
For cases like local-statics-7 your approach can be "saved" by adding
simple IPA analysis
to look for static vars that are used only by one function and keeping
your DSE code active
for them,
this OK, or is there a better way to do it?
-Sandra
2014-05-20 Cesar Philippidis
Sandra Loosemore
gcc/testsuite/
* lib/scanasm.exp (scan-lto-assembler): New procedure.
* gcc.target/nios2/custom-fp-lto.c: New test.
Index: gcc/testsuite/lib/scanas
On 05/21/2014 03:12 AM, Richard Biener wrote:
On Wed, May 21, 2014 at 3:51 AM, Sandra Loosemore
wrote:
One of the consequences of the (now-fixed) bug in PR60179 is that Nios II
code using target pragmas to specify custom instructions failed to generate
those instructions with -flto. We came
On 05/19/2014 01:38 PM, Sandra Loosemore wrote:
2014-05-19 Iain Sandoe
Catherine Moore
Sandra Loosemore
gcc/
* config/mips/mips.c (mips_set_current_function): Choose
function alignment once the current mode is known.
gcc/testsuite
results in BE8 code rather than BE32.) It seems
simplest just to remove the specific -mcpu option and rely on the
multilib options to supply appropriate test flags for the execution
environment.
OK to commit?
-Sandra
2014-05-30 Julian Brown
Sandra Loosemore
gcc
On 05/28/2014 01:09 PM, Richard Sandiford wrote:
Sandra Loosemore writes:
On 05/19/2014 01:38 PM, Sandra Loosemore wrote:
2014-05-19 Iain Sandoe
Catherine Moore
Sandra Loosemore
gcc/
* config/mips/mips.c (mips_set_current_function): Choose
with
old versions of the linker, but we'd rather have the first official
release of GCC for Nios II implement this correctly.
-Sandra
2014-02-02 Sandra Loosemore
gcc/
* config/nios2/nios2.md (load_got_register): Initialize GOT
pointer from _gp_got instead of _GLOBAL_OFFSET_TABLE_.
On 02/19/2014 02:43 AM, Andrew Haley wrote:
On 02/19/2014 09:34 AM, Richard Biener wrote:
Sandras patch was supposed to introduce support
for --enable-version-specific-runtime-libs in libgcj (but obviously
it failed, given the result above).
Sandra? You're very quiet. What say you?
I don't
milar restrictions
requiring -ffinite-math-only, etc., so that part was also just following
current practice and building on existing framework, just adding a new flag.
I've checked this in.
-Sandra
2014-04-22 Sandra Loosemore
gcc/
* config/nios2/nios2.md (UNSPEC_ROUND): New.
(l
On 12/18/2012 10:42 PM, Gerald Pfeifer wrote:
Hi Sandra,
On Sat, 10 Nov 2012, Sandra Loosemore wrote:
2012-11-10 Sandra Loosemore
gcc/
* doc/extend.texi: Copy-edit to fix incorrect hyphenation phrases
involving "bit", "byte", "word&quo
This patch fixes a group of bugs that were causing link errors on
hard-float MIPS16 code built with a mips-linux-gnu toolchain. This is
Mark Mitchell's analysis of the original problem:
The MIPS16
instruction set cannot directly access hard-float registers, so helper
functions in libgcc are u
On 08/08/2012 03:07 AM, Richard Sandiford wrote:
It looks like this patch might have been written before:
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00756.html
which added:
/* If we're calling a locally-defined MIPS16 function, we know that
it will return values in both the "sof
On 08/04/2012 07:55 AM, Richard Sandiford wrote:
> Sandra Loosemore writes:
>> This is another patch that has been present in our local source base for some
>> years now. It originally came from MIPS; I've verified that we have legal
>> permission to contribute it to
This patch adds a peephole optimization to use a clever trick to
zero-initialize the two halves of an accumulator register with one
instruction instead of a mtlo/mthi pair. OK to check in?
-Sandra
2012-08-16 Sandra Loosemore
Julian Brown
MIPS Technologies, Inc
On 08/16/2012 01:27 PM, Richard Sandiford wrote:
Sandra Loosemore writes:
@@ -569,7 +569,7 @@
UNSPEC_DPAU_H_QBL))]
"ISA_HAS_DSP&& !TARGET_64BIT"
"dpau.h.qbl\t%q0,%2,%3"
- [(set_attr "type" "imadd")
+ [(set_
an alternative if this
doesn't meet with your approval. Is the rest of the patch OK to check in?
-Sandra
2012-08-20 Julian Brown
Sandra Loosemore
gcc/
* config/mips/mips.md (MIPS16_T_REGNUM): New constant.
(tablejump): D
012-08-21 Paul Brook
Joseph Myers
Sandra Loosemore
gcc/
* expr.h (store_bit_field): Add packedp parameter to prototype.
* expmed.c (store_bit_field, store_bit_field_1): Add packedp
parameter. Adjust all callers.
(warn_misaligned
That would also allow us to use it for plain HI and LO. It wasn't
obvious from the patch why it was restricted to the DSP extension
registers.
Please also add a scan-assembler test.
How is this version of the fix?
-Sandra
2012-08-22 Sandra Loosemore
gcc/
ch that addresses the other problems you pointed
out. Is this part OK, at least? It passes regression testing.
-Sandra
2012-08-22 Julian Brown
Sandra Loosemore
gcc/
* config/mips/mips.md
(UNSPEC_CASESI_DISPATCH): New.
(MIPS16_T_REGNUM): New c
On 08/22/2012 03:27 PM, Eric Botcazou wrote:
+ bool packedp = false;
+
+ if (TREE_CODE(to) == COMPONENT_REF
+&& (TYPE_PACKED (TREE_TYPE (TREE_OPERAND (to, 0)))
+ || (TREE_CODE (TREE_OPERAND (to, 1)) == FIELD_DECL
+&& DECL_PACKED (TREE_OPERAND (to, 1))
On 08/23/2012 03:08 AM, Richard Guenther wrote:
In fact, you should probably implement code-generation constraints from
within the frontends by, for strict volatile bitfields, emitting loads/stores
using DECL_BIT_FIELD_REPRESENTATIVE (doing read-modify-write
explicitely). Or maybe you can elabo
On 08/24/2012 11:46 PM, Richard Sandiford wrote:
Andrew Pinski writes:
On Fri, Aug 24, 2012 at 10:08 PM, Andrew Pinski wrote:
On Wed, Aug 22, 2012 at 7:15 PM, Sandra Loosemore
wrote:
On 08/21/2012 02:23 PM, Richard Sandiford wrote:
Would be nice to add a compile test for -mabi=64 just
While I was grovelling around trying to swap in more state on the
bitfield store/extract code for the patch rewrite being discussed here:
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01546.html
I found a reference to PR23623 and found that it is broken again, but in
a different way. On ARM EA
ct.
This fixes the previously-failing test case and regression tests OK on
arm-none-eabi, but I haven't tried it on any other target yet. Is this
a reasonable way to resolve this conflict, or should something farther
up the call chain take care of it?
-Sandra
2012-08-26 Sandra Loos
On 08/23/2012 03:51 AM, Chung-Lin Tang wrote:
WRT only the code expansion aspects in store_fixed_bit_field(), would a
test of "STRICT_ALIGNMENT&& MEM_ALIGN(op0)< GET_MODE_ALIGNMENT(mode)"
be sufficient to detect instead of a packedp parameter?
As an experiment, I tried putting in an assertio
anual.
-Sandra
2012-09-14 Sandra Loosemore
gcc/
* doc/tm.texi.in (Stack Arguments): Update obsolete references
to current_function_outgoing_args_size.
(Function Entry): Likewise for current_function_pops_args,
current_function_pretend_args
On 08/27/2012 10:36 AM, Richard Sandiford wrote:
Sandra Loosemore writes:
On 08/19/2012 11:22 AM, Richard Sandiford wrote:
Not sure whether a peephole is the right choice here. In practice,
I'd imagine these opportunities would only come from a DImode move of
$0 into a doubleword reg
Re:
I think tree-ssa-loop-ivopts is simply
asking for the wrong thing, and needs to be changed. As I say,
Sandra had some fixes in this area.
This patch:
http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00319.html
Sadly, that patch has fallen off the bottom of my priority list (some
legal wran
On 06/06/2012 02:29 AM, Richard Guenther wrote:
Pre-computing and caching things is to avoid creating RTXen over and over.
As you have discarded this completely did you try to measure the cost
of doing so in terms of produced garbage and compile-time cost? Did you
consider changing the target i
On 06/05/2012 10:34 AM, Sandra Loosemore wrote:
2012-06-05 Sandra Loosemore
gcc/
* tree-ssa-loop-ivopts.c (comp_cost): Make complexity field signed.
Update comments to indicate this is for addressing mode complexity.
(new_cost): Make signedness of parameters
obvious that I've gone ahead and checked it in on
mainline as well.
-Sandra
2012-07-04 Sandra Loosemore
libgomp/
* libgomp.texi (Library Index): Renamed from "Index" to prevent
conflict wi
We've had this patch to add missing whitespace to the assembler spec
string in the SH back end in our local tree for a couple of years. I
think it's obvious enough that I've gone ahead and checked it in on
mainline too.
-Sandra
2012-07-14 Andrew Stubbs
S
I've checked in this patch, which was conditionally approved 3+ years ago:
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00688.html
I did look at general usage for m68k and adding -mcpu is consistent with
other existing tests; there aren't enough of them that are
conditionalized in this way to
Like the subject line says; this is consistent with the existing test to
bail out for MIPS bare-metal. OK for mainline?
-Sandra
2012-07-17 Julian Brown
Sandra Loosemore
gcc/testsuite/
* gcc.c-torture/execute/20101011-1.c: Skip on bare-metal m68k.
Index: gcc
isting hack for this problem in that backend. Nick, you're listed as mcore
port maintainer; can you help?
-Sandra
2012-07-23 Sandra Loosemore
Paul Brook
PR target/53633
gcc/
* target.def (warn_func_return): New hook.
* doc/tm.texi.in (TARGET_WA
I was looking to see what needs to be done to un-stick this previously
submitted patch:
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01419.html
Paolo's suggestion was to re-write this to use a "tortoise-and-hare"
algorithm to detect the circularity, rather than Andrew's solution of
using a po
t way the mcore port would be
> tested as well as the ARM port.
Something like this? The code part of the patch is unchanged from the last
version I posted. OK to check in?
-Sandra
2012-07-24 Sandra Loosemore
Paul Brook
PR target/53633
gcc/
* target.
On 07/25/2012 09:57 AM, Richard Henderson wrote:
>
> I'll echo Nick's comments about arm asm in a common test.
> There's no need to have anything but __asm__(""); there.
>
> Ok with that change.
Thanks! Here's the version I committed.
-Sandra
20
On 07/17/2012 05:22 AM, Richard Guenther wrote:
On Wed, Jul 4, 2012 at 6:35 PM, Sandra Loosemore
wrote:
Ping? Original post with patch is here:
http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00319.html
Can you update the patch and numbers based on what Bill did for
straight-line strength
ull bootstrap and regression-test
on x86_64. OK to check in?
-Sandra
2012-07-25 Andrew Jenner
Sandra Loosemore
gcc/
* cse.c (find_comparison_args): Check for cycles of any length.
gcc/testsuite/
* gcc.c-torture/compile/pr50380.c: Add code to cau
1001 - 1100 of 1326 matches
Mail list logo
