[Bug target/57952] AVX/AVX2 no ymm registers used in a trivial reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57952
--- Comment #1 from vincenzo Innocente ---
I modified a bit the benchmark adding timing
and the new version now vectorize YMM with avx2, still not with old avx
if I remove the call to rdtsc(); it does not use YMM anymore
-fno-tree-pre does not help
cat polyAVX.cpp
//template
typedef float T;
inline T polyHorner(T y) {
return T(0x2.p0) + y * (T(0x2.p0) + y * (T(0x1.p0) + y * (T(0x5.55523p-4) +
y * (T(0x1.5554dcp-4) + y * (T(0x4.48f41p-8) + y * T(0xb.6ad4p-12)) ;
}
#include
#include
volatile unsigned long long rdtsc() {
unsigned int taux=0;
return __rdtscp(&taux);
}
int main() {
long long t=0;
bool ret=true;
float s =0;
for (int k=0; k!=100; ++k) {
float c = 1.f/1000.f;
t -=rdtsc();
for (int i=1; i<1001; ++i) s+= polyHorner((float(i)+float(k))*c);
t+=rdtsc();
}
ret &= s!=0;
std::cout << t <
[Bug fortran/57959] New: ICE with structure constructor with scalar allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57959 Bug ID: 57959 Summary: ICE with structure constructor with scalar allocatable components Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Based on the array example in PR57957, which compiles. The following: type :: type1 real, allocatable :: anum end type type1 ... = type1(5.0) fails with: 0x7b3b5d fold_convert_loc(unsigned int, tree_node*, tree_node*) ../../gcc/fold-const.c:1952 0x5fb036 gfc_trans_scalar_assign(gfc_se*, gfc_se*, gfc_typespec, bool, bool, bool) ../../gcc/fortran/trans-expr.c:6899 Full example: program main implicit none type :: type1 real, allocatable :: anum end type type1 type :: type2 type(type1) :: temp end type type2 block type(type1) :: uKnot type(type2) :: a uKnot = type1(5.0) a = type2(uKnot) end block end
[Bug fortran/57957] Double free with allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57957 Tobias Burnus changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-23 CC||burnus at gcc dot gnu.org Summary|Double free or corruption |Double free with |(fasttop) |allocatable components Ever confirmed|0 |1 Known to fail||4.5.3, 4.8.1, 4.9.0 --- Comment #1 from Tobias Burnus --- Confirmed. For GCC 4.9, one needs to wrap the code in the main program in BLOCK/END BLOCK as otherwise the end-of-scope deallocation does not trigger, which causes the failure. PR57959 prevents testing whether the problem is related to the array constructor or not.
[Bug target/51244] [SH] Inefficient conditional branch and code around T bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #61 from Laurent Aflonsi ---
Yes that's the point. L3 can be reached by another block (L2):
tstr2,r2
mov#-1,r2
negcr2,r2
.L3:
tstr2,r2
bt/s.L11
[...]
.L2:
mov.l@r4,r2
tstr2,r2
bra.L3
movtr2
The movt(L2) and the tst(L3) are both removed, and that's coherent for that run
path, because it is preceded by the tst r2,r2.
But that makes the first path incoherent because L3 can be reached by the very
first block. I have written a first fix, too restrictive ("pr25869-19.c
scan-assembler-not movt" is failing) :
--- ./gcc/gcc/config/sh/sh.md.orig
+++ ./gcc/gcc/config/sh/sh.md
@@ -8523,7 +8523,8 @@
T bit. Notice that some T bit stores such as negc also modify
the T bit. */
if (modified_between_p (get_t_reg_rtx (), s1.insn, testing_insn)
- || modified_in_p (get_t_reg_rtx (), s1.insn))
+ || modified_in_p (get_t_reg_rtx (), s1.insn)
+ || !no_labels_between_p(s1.insn, testing_insn))
operands[2] = NULL_RTX;
break;
The idea would be to check if "s1.insn block dominates testing_insn block",
but I don't know how to write it at this stage.
More generally, I'm surprised to see that optimization at mapping level, isn't
this a generic problematic that should be handled at rtl dead code elimination
stage on the T bit register ?
Thanks,
Laurent
[Bug rtl-optimization/57960] New: LRA ICE building glibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57960
Bug ID: 57960
Summary: LRA ICE building glibc
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Testcase extracted from Glibc e_acosl.c:
typedef union
{
long double value;
struct
{
unsigned int w0, w1, w2, w3;
}
parts32;
}
ieee854_long_double_shape_type;
static const long double one = 1.0L;
long double
__ieee754_acosl (long double x)
{
long double z, w;
int ix;
ieee854_long_double_shape_type u;
z = (one - u.value) * 0.5;
u.parts32.w2 = 0;
u.parts32.w3 = 0;
w = z - u.value * u.value;
return 2.0 * w;
}
builds fine with: cc1 -fpreprocessed -quiet -O1 -mno-lra
but with: cc1 -fpreprocessed -quiet -O1
t.c: In function ‘__ieee754_acosl’:
t.c:25:1: error: unable to generate reloads for:
}
^
(insn 14 13 16 2 (set (strict_low_part (subreg:SI (reg/v:TI 51 [ u ]) 12))
(const_int 0 [0])) t.c:21 77 {movstrictsi}
(nil))
t.c:25:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:2954
0x8051ecb5 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/andreas/patched/gcc-head/gcc/rtl-error.c:109
0x8046895b curr_insn_transform
/home/andreas/patched/gcc-head/gcc/lra-constraints.c:2954
0x804692e1 lra_constraints(bool)
/home/andreas/patched/gcc-head/gcc/lra-constraints.c:3810
0x804577a9 lra(_IO_FILE*)
/home/andreas/patched/gcc-head/gcc/lra.c:2319
0x8040c22b do_reload
/home/andreas/patched/gcc-head/gcc/ira.c:4689
0x8040c22b rest_of_handle_reload
/home/andreas/patched/gcc-head/gcc/ira.c:4801
[Bug fortran/57959] ICE with structure constructor with scalar allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57959 --- Comment #1 from Tobias Burnus --- gfc_trans_subcomponent_assign lacks handling of allocatable scalars. It simply does: type1.0.anum = 5.0 instead of: (re)allocate of "type1.0.anum" *type1.0.anum = 5.0 For arrays, it is handled via gfc_trans_alloc_subarray_assign, which is called via gfc_trans_structure_assign -> gfc_trans_subcomponent_assign. TODO: Also check whether coarrays are properly handled. "= TYPE(CAF=5.0)" should be valid, but the LHS shan't be (re)allocated.
[Bug c/57961] New: Excessive memory use with -O0 ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57961 Bug ID: 57961 Summary: Excessive memory use with -O0 ? Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Created attachment 30540 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30540&action=edit C source code I just tried to compile the attached code with -O0. Over 4 Gig of RAM seemed to be required to compile it with gcc trunk from 20130721, but gcc 481 seems to compile it ok in 1 Gig. [dcb@localhost foundBugs]$ (ulimit -v 400; /home/dcb/gcc/results/bin/gcc -O0 -c bug115.c) bug115.c: In function ‘VLparse’: bug115.c:18324:9: warning: passing argument 1 of ‘VLerror’ discards ‘const’ qualifier from pointer target type [enabled by default] VLerror (yymsgp); ^ bug115.c:4726:13: note: expected ‘char *’ but argument is of type ‘const char *’ extern void VLerror( char* msg ); ^ virtual memory exhausted: Cannot allocate memory [dcb@localhost foundBugs]$ /home/dcb/gcc/results/bin/gcc -v Using built-in specs. COLLECT_GCC=/home/dcb/gcc/results/bin/gcc COLLECT_LTO_WRAPPER=/home/dcb/gcc/results/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../src/trunk/configure --prefix=/home/dcb/gcc/results --enable-checking=yes --enable-languages=c,c++,fortran Thread model: posix gcc version 4.9.0 20130721 (experimental) [trunk revision 193500] (GCC) [dcb@localhost foundBugs]$ (ulimit -v 100; /usr/bin/gcc -O0 -c bug115.c) bug115.c: In function ‘VLparse’: bug115.c:18324:9: warning: passing argument 1 of ‘VLerror’ discards ‘const’ qualifier from pointer target type [enabled by default] VLerror (yymsgp); ^ bug115.c:4726:13: note: expected ‘char *’ but argument is of type ‘const char *’ extern void VLerror( char* msg ); ^ [dcb@localhost foundBugs]$ /usr/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.1/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-isl=/builddir/build/BUILD/gcc-4.8.1-20130603/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.1-20130603/obj-x86_64-redhat-linux/cloog-install --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.1 20130603 (Red Hat 4.8.1-1) (GCC) [dcb@localhost foundBugs]$ Suggest code rework.
[Bug tree-optimization/57962] New: Missed Optimization for Superword Level Parallelism
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57962 Bug ID: 57962 Summary: Missed Optimization for Superword Level Parallelism Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: freddie at witherden dot org Created attachment 30541 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30541&action=edit Sample code. GCC 4.7.3 and 4.8.1 both miss an optimization when compiling the attached test case using: gcc -Ofast -march=corei7-avx test.c -S By loading the components of ul and fl into the bottom half of an xmm register and ur and fr into the corresponding top half it is possible to compute disf_inv_impl(ul, fl) and disf_inv_impl(ur, fr) in a single hit. Horizontal instructions can then be used to add the various fl and fr components together.
[Bug c/57821] 'array is too large' error is missing when sizetype overflows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57821 John David Anglin changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #3 from John David Anglin --- On 32-bit hppa-unknown-linux-gnu: Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdi r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/large-size-array-6.c -fno-di agnostics-show-caret -fdiagnostics-color=never -O2 -S -o large-size-array-6.s(timeout = 300) spawn /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/gcc/ /home/ dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/large-size-array-6.c -fno-diagnostics-show -caret -fdiagnostics-color=never -O2 -S -o large-size-array-6.s /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/large-size-array-6.c:6:3: internal c ompiler error: in tree_low_cst, at tree.c:6805 0x7b8eab tree_low_cst(tree_node const*, int) ../../gcc/gcc/tree.c:6805 0x134c73 process_init_element(c_expr, bool, obstack*) ../../gcc/gcc/c/c-typeck.c:8351 0x1537b7 c_parser_initval ../../gcc/gcc/c/c-parser.c:4023 0x15306f c_parser_initelt ../../gcc/gcc/c/c-parser.c:3997 0x15306f c_parser_braced_init ../../gcc/gcc/c/c-parser.c:3779 0x158343 c_parser_initializer ../../gcc/gcc/c/c-parser.c:3737 0x158343 c_parser_declaration_or_fndef ../../gcc/gcc/c/c-parser.c:1651 0x15d883 c_parser_external_declaration ../../gcc/gcc/c/c-parser.c:1363 0x15e58b c_parser_translation_unit ../../gcc/gcc/c/c-parser.c:1251 0x15e58b c_parse_file() ../../gcc/gcc/c/c-parser.c:11000 0x1ae0ff c_common_parse_file() ../../gcc/gcc/c-family/c-opts.c:1046
[Bug rtl-optimization/57963] New: LRA S/390: esa mode failure memcpy-chk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57963
Bug ID: 57963
Summary: LRA S/390: esa mode failure memcpy-chk
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
memcpy-chk with -O2 fails if compiled with lra enabled.
It succeeds with -mno-lra.
With lra an insn storing into the literal pool is being emitted:
ira:
(insn 126 127 129 11 (parallel [
(set (reg/f:SI 60 [ D.1911 ])
(plus:SI (reg/v/f:SI 126 [ buf3 ])
(const_int 14 [0xe])))
(clobber (reg:CC 33 %cc))
])
/build/gcc-head/gcc/testsuite/gcc.c-torture/execute/builtins/memcpy-chk.c:131
297 {*addsi3}
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(expr_list:REG_EQUIV (const:SI (plus:SI (symbol_ref:SI ("buf1") [flags
0x400] )
(const_int 14 [0xe])))
(nil
(insn 129 126 135 11 (set (reg/f:SI 261)
(mem/u/c:SI (symbol_ref/u:SI ("*.LC69") [flags 0x2]) [3 S4 A32]))
/build/gcc-head/gcc/testsuite/gcc.c-torture/execute/builtins/memcpy-chk.c:131
68 {*movsi_esa}
(expr_list:REG_EQUIV (const:SI (plus:SI (symbol_ref:SI ("buf1") [flags
0x400] )
(const_int 14 [0xe])))
(nil)))
reload:
126: {r406:SI=r406:SI+0xe;clobber %cc:CC;}
REG_UNUSED %cc:CC
REG_EQUIV const(`buf1'+0xe)
Inserting insn reload before:
829: r406:SI=r126:SI
Inserting insn reload after:
830: r60:SI=r406:SI
alt=1,overall=1,losers=0,rld_nregs=0
Choosing alt 1 in insn 830: (0) d (1) d {*movsi_esa}
alt=1,overall=1,losers=0,rld_nregs=0
Choosing alt 1 in insn 829: (0) d (1) d {*movsi_esa}
Removing equiv init insn 129 (freq=9944)
129: r261:SI=[`*.LC69']
REG_EQUIV const(`buf1'+0xe)
deleting insn with uid = 129.
Changing pseudo 60 in operand 0 of insn 830 on equiv [`*.LC69']
alt=1,overall=609,losers=1,rld_nregs=1
alt=2,overall=17,losers=2,rld_nregs=1
alt=3,overall=0,losers=0,rld_nregs=0
Choosing alt 3 in insn 830: (0) R (1) d {*movsi_esa}
(insn 829 828 126 11 (set (reg/f:SI 7 %r7 [orig:60 D.1911 ] [60])
(reg/v/f:SI 2 %r2 [orig:126 buf3 ] [126]))
/build/gcc-head/gcc/testsuite/gcc.c-torture/execute/
builtins/memcpy-chk.c:131 68 {*movsi_esa}
(nil))
(insn 126 829 830 11 (parallel [
(set (reg/f:SI 7 %r7 [orig:60 D.1911 ] [60])
(plus:SI (reg/f:SI 7 %r7 [orig:60 D.1911 ] [60])
(const_int 14 [0xe])))
(clobber (reg:CC 33 %cc))
])
/build/gcc-head/gcc/testsuite/gcc.c-torture/execute/builtins/memcpy-chk.c:131
297 {*addsi3}
(expr_list:REG_EQUIV (const:SI (plus:SI (symbol_ref:SI ("buf1") [flags
0x400] )
(const_int 14 [0xe])))
(nil)))
(insn 830 126 129 11 (set (mem/u/c:SI (symbol_ref/u:SI ("*.LC69") [flags 0x2])
[3 S4 A32])
(reg/f:SI 7 %r7 [orig:60 D.1911 ] [60]))
/build/gcc-head/gcc/testsuite/gcc.c-torture/execute/builtins/memcpy-chk.c:131
68 {*movsi_esa}
(expr_list:REG_DEAD (reg/f:SI 7 %r7 [orig:60 D.1911 ] [60])
(nil)))
insn 830 writes to a literal pool slot. The testcase fails with a segfault due
to this.
[Bug middle-end/57811] Wasted work in find_reloads()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57811 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #5 from Jeffrey A. Law --- Fixed in mainline.
[Bug middle-end/57782] Wasted work in remove_path()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57782 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #2 from Jeffrey A. Law --- Installed onto mainline.
[Bug target/57787] Wasted work in ix86_valid_target_attribute_inner_p() and ix86_pad_returns()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57787 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- Second patch installed on mainline.
[Bug target/57907] warning: switch -mcpu=cortex-a15 conflicts with -march=armv7-a switch [enabled by default]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57907 --- Comment #1 from Richard Earnshaw --- You get the warning because Cortex-A15 implements a superset of ARM-v7a, due to the addition of the HW division instructions. This means that -march=armv7-a and -mcpu=cortex-a15 leads to an ambiguity as to what architectural features you want and hence the warning. It's not currently possible to specify the exact architecture variant that A15 supports in the command line; we're looking at fixing that in future.
[Bug target/57847] Compile ARM linux kernel with configuration of SLUB allocator, kernel failed to boot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57847 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-07-23 Ever confirmed|0 |1 --- Comment #4 from Richard Earnshaw --- Sorry, we cannot debug your program for you. We don't have the board that you have or the full code. To take this any further you're going to have to work out where and why the code generated by the compiler is wrong and provide us with a test-case that we can work on. Also, you're using a Linaro build of the tools, so your first port of call should be with the linaro developers who provided your distribution.
[Bug target/57911] alignment of arrays allocated stack on ARM : 4 bytes ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57911 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-07-23 Ever confirmed|0 |1 --- Comment #1 from Richard Earnshaw --- The ABI specifies *minimum* alignment constraints. It can never specify a maximum. Compilers are entitled to place objects on whatever boundaries they wish if they think it will lead to better results (better does not necessarily mean faster). Even when optimizing for size it can be the case that padding some objects up to word boundaries will lead to smaller code (-Os is primarily aimed at generating smaller code segments, not necessarily about minimizing stack usage). For example, it might allow LDM operations to be used to read multiple words from the object at once. If you have more details, then please supply pre-processed test case that we can look at.
[Bug target/57949] [powerpc64] Structure parameter alignment issue with vector extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57949 --- Comment #4 from Bill Schmidt --- Enabling the code used for MachO/Darwin64 when targeting ABI_AIX/linux produces much better code: li 9,144 addis 8,2,.LC1@toc@ha lvx 0,1,9 ld 10,.LC1@toc@l(8) addis 8,2,.LC2@toc@ha ld 9,.LC2@toc@l(8) ld 8,128(1) stvx 0,0,9 std 8,0(10) blr A properly aligned vector load is used from the parameter save area without a copy through the local variable area. David/Peter, two questions: (1) Would it be reasonable to make this the new default behavior, but add a target-specific flag (-munaligned-vect-struct-parms or something) to allow compatibility with the existing behavior? I doubt this comes up often, but it probably occurs somewhere in an existing library interface. (2) If we make a change, should it be just for Linux, or should we change code for AIX as well?
[Bug target/56864] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vect "vectorized 1 loops" 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56864 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-23 CC||dje at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #13 from David Edelsohn --- confirmed.
[Bug tree-optimization/56787] [4.8 Regression] Vectorization fails because of CLOBBER statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56787 David Edelsohn changed: What|Removed |Added CC||dje at gcc dot gnu.org Known to work|4.9.0 | --- Comment #6 from David Edelsohn --- The patch fixed x86_64 but the new testcase fails on PPC64.
[Bug c++/3] Nested types sometimes not visible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #8 from Robert Lougher ---
A couple of things:
On 22 July 2013 16:40, Ondřej Bílka wrote:
> These patches were generated by running command
>
> stylepp_spell_patch
>
> This is third part where human intervention is needed.
>
> I first generate list of likely typos (stylepp_spellcheck script)
>
> Then I check that list with aspell and correct candidates.
>
> From these candidates I create dictionary and use stylepp_fix_spell to
> apply it.
>
> Dictionary, stripped patch and patch are below.
>
> accomodates accommodates
> accross across
> advantagous advantageous
> algebric algebraic
> aplications applications
> approriate appropriate
> astheticsaesthetics
> compability compatibility
> compatibiliy compatibility
> composited composed
> curent current
> desribed described
> dissappears disappears
> existant existent
> extendsions extensions
> featues features
> flattenning flattening
> fuction function
> hundredsof hundreds_of
> implemenetation implementation
> ineqalityinequality
> initialisation initialization
The 's' spelling is OK in British English.
> instace instance
> interesing interesting
> interpeter interpreter
> logrithm logarithm
> matchers marchers
> muliple multiple
> obtaines obtains
> occured occurred
> occurrs occurs
> ouputoutput
> overridding overriding
> paramter parameter
> parantheses parentheses
> probabilyprobability
> procesorsprocessors
> realiablereliable
> recommanded recommended
> relase release
> remebers remembers
> represenationrepresentation
> representaiton representation
> resettable resetable
> retore restore
> satelittesatellite
> sendign sending
> seperatorseparator
> sigificance significance
> simpliestsimplest
> specfied specified
> specialised specialized
See above
> specifyedspecified
> thounsands thousands
> ulessunless
> utilised utilized
See above
> y {@link DynAnyFactory}. The factory is obtaines by
> y {@link DynAnyFactory}. The factory is obtains by
> ^^
This is wrong. It should be "obtained".
> -DynAny's are created by {@link DynAnyFactory}. The factory is obtaines by
> +DynAny's are created by {@link DynAnyFactory}. The factory is obtains by
See above.
[Bug c++/57926] Atomic functions broken with C++ but not C?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926 --- Comment #8 from Jason Merrill --- I don't know how exactly these builtins interact with overload resolution, but it should be calling decay_conversion to turn arrays into pointers.
[Bug c++/57926] Atomic functions broken with C++ but not C?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926 Andrew Macleod changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #9 from Andrew Macleod --- I don't know either.. that parameter checking stuff is all inherited from the original __sync code. resolve_overloaded_builtin() is called avery early and it takes care of everything, telling the call handling code to not do anything else. In C it would have to call array_to_pointer_conversion() for arrays, and decay_conversion for c++.. ugg. that means it needs to be done *before* the overloaded resolution. Thats pretty ugly. Im going to copy rth since he wrote this code originally. Maybe he knows the easy shortcut :-) Andrew
[Bug fortran/57904] Bogus(?) "invokes undefined behavior" warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904 Martin Jambor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-23 CC||jakub at gcc dot gnu.org, ||jamborm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Jambor --- I'm not really sure what the warning is about. The warning is emitted in the cunrolli (note the i at the end) pass when it also dumps the following to the dump: Statement _16 = idx_15 + -1; is executed at most 2147483647 (bounded by 2147483647) + 1 times in loop 3. which looks suspicious. However, the whole loop is guarded by cndition (ubound.0_3 > 0) which IPA-CP tells us is false, so the code is never executed. Indeed the whole loop disappears in the very next pass dump ccp2 and scheduling an extra ccp before cunrolli makes the warning go away. Having said that, I'm not sure how to proceed at the moment and have to leave my office pretty much immediately :-) Parhaps Jakub, who introduced the warning, might have an idea?
[Bug target/57949] [powerpc64] Structure parameter alignment issue with vector extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57949 Bill Schmidt changed: What|Removed |Added CC||joseph at codesourcery dot com --- Comment #5 from Bill Schmidt --- Joseph, adding you for any comments you might have relative to Freescale impacts. Summarizing some offline discussion: * This would apply to long double, __int128, and (probably) _Decimal128 as well. The fix is the same in all cases. * There may be some oddities for _Decimal128, as the need to be in even/odd register pairs may conflict with alignment in storage. The 64-bit ABI does not currently specify the alignment for _Decimal128 so we'll need to check the code to see what's the case in practice.
[Bug target/57949] [powerpc64] Structure parameter alignment issue with vector extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57949 --- Comment #6 from joseph at codesourcery dot com --- I'm not expert on the 64-bit ABI; the Power.org ABI TSC never really got onto doing anything with the 64-bit ABI, although nominally it's in scope. The only Freescale peculiarity I know of for 64-bit processors is that some don't have fsqrt, but that's nothing to do with the ABI.
[Bug fortran/57800] Wasted work in gfc_match_call()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57800 --- Comment #2 from Po-Chun Chang --- Patch sent to gcc-patch@ and fortran@ http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01054.html http://gcc.gnu.org/ml/fortran/2013-07/msg00068.html
[Bug c++/57958] Incorrect code generation in lambda with argument of type reference to template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57958 Paolo Carlini changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-23 Blocks||54367 Ever confirmed|0 |1
[Bug middle-end/57955] Uniquization of constants breaks constant alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57955 --- Comment #4 from Eric Botcazou --- > I don't understand the comment "questionable optimization patterns". I don't see much value in optimizing a memcpy to initialize a variable, it's unlikely to be in a hot spot. I'd suggest adding 'const' to the testcase. > Optimizing for size should be controlled by -Os. It's just classical constant pool technique though and constant pools are not conditionalized on -Os in the compiler.
[Bug fortran/57791] Wasted work in gfc_check_pointer_assign()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57791 --- Comment #2 from Po-Chun Chang --- Patch sent to gcc-patches@ and fortran@ http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01056.html http://gcc.gnu.org/ml/fortran/2013-07/msg00070.html
[Bug fortran/57801] Wasted work in resolve_variable()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57801 --- Comment #2 from Po-Chun Chang --- Patch sent to gcc-patches@ and fortran@ http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01055.html http://gcc.gnu.org/ml/fortran/2013-07/msg00069.html
[Bug fortran/57802] Wasted work in set_loop_bounds()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57802 --- Comment #2 from Po-Chun Chang --- Patch sent to gcc-patches@ and fortran@ http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01057.html http://gcc.gnu.org/ml/fortran/2013-07/msg00071.html
[Bug fortran/57804] Waste work in gfc_trans_transfer()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57804 --- Comment #2 from Po-Chun Chang --- Patch sent to gcc-patches@ and fortran@ http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01058.html http://gcc.gnu.org/ml/fortran/2013-07/msg00072.html
[Bug rtl-optimization/57921] Alias change causes perl from SPEC 2006 to abort on MIPS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57921 Steve Ellcey changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Steve Ellcey --- Given the SPEC comments about perl not obeying aliasing rules and the fact that I can compile this correctly with -fno-strict-aliasing I am going to close this out as 'invalid' I.e. it is not a GCC bug.
[Bug ada/57964] New: Bug box with ambiguity combined with expression if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57964 Bug ID: 57964 Summary: Bug box with ambiguity combined with expression if Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: prosfilaes at gmail dot com with Problem; use Problem; package Linear_Programming is procedure Linear_Init; end Linear_Programming; with Ada.Containers.Vectors; package Problem is package Natural_Vector_Package is new Ada.Containers.Vectors (Positive, Natural); -- We may need to stuff depots in there use Natural_Vector_Package; Num_Customers : Positive; Demand : Natural_Vector_Package.Vector; end Problem; with Ada.Containers.Vectors; with Ada.Containers; use Ada.Containers; with Interfaces.C; use Interfaces.C; package body Linear_Programming is package Double_Vector is new Ada.Containers.Vectors (Positive, Double); procedure Linear_Init is AR : Double_Vector.Vector; V: Integer := 1; begin for I in 0 .. Num_Customers - 1 loop for J in I + 1 .. Num_Customers loop if (I = 0 and then J >= V) or else I >= V then AR.Append (Interfaces.C.Double ((if I > 0 then Demand (I) else 0) + Demand (J)) / 2.0); end if; end loop; end loop; end Linear_Init; end Linear_Programming; gets me | 4.8.0 (x86_64-unknown-linux-gnu) Storage_Error stack overflow or erroneous memory access| | Error detected at linear_programming.adb:15:21 | compiled with gcc -c linear_programming.adb . (-gnat2012 gets rid of an error about if expression being an Ada 2012 expression, but it's the same bug box either way.)
[Bug ada/49524] container loop error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49524 David Starner changed: What|Removed |Added CC||prosfilaes at gmail dot com --- Comment #1 from David Starner --- Code works fine with gcc 4.8.0 on x86_64-unknown-linux-gnu.
[Bug middle-end/57955] [4.6/4.7/4.8/4.9 Regression] Uniquization of constants reduces alignment of initializers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57955 David Edelsohn changed: What|Removed |Added Summary|Uniquization of constants |[4.6/4.7/4.8/4.9 |breaks constant alignment |Regression] Uniquization of ||constants reduces alignment ||of initializers --- Comment #5 from David Edelsohn --- It was an undocumented change in GCC behavior. I infer from the name that the testcase was trying to test that a block move of appropriate alignment used VMX instructions. I will see if I can construct a testcase with memcpy directly.
[Bug c/57956] missing 'msgstr' section errors when building
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57956 --- Comment #1 from Rich Townsend --- Temporary workaround: add --disable-nls to ./configure args.
