[Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60732 --- Comment #3 from Dominique d'Humieres --- > Dominique, what does the generated assembly look like in the (failing) Darwin > case? Without -fabi-version=0 (or with -fabi-version=1 to 3), I get the pre r203469 manglings: .globl __Z3fooU8__vectorh .globl __Z3fooU8__vectora .globl __Z3fooU8__vectorU6__boolc .globl __Z3fooU8__vectort .globl __Z3fooU8__vectors .globl __Z3fooU8__vectorU6__bools .globl __Z3fooU8__vectorj .globl __Z3fooU8__vectori .globl __Z3fooU8__vectorU6__booli .globl __Z3fooU8__vectorf .globl __Z3fooU8__vectoru7__pixel .globl __Z3fooi .globl __Z3fooj .globl __Z3foof With -fabi-version=0 or 4, I get the manglings expected by the test .globl __Z3fooDv16_h .globl __Z3fooDv16_a .globl __Z3fooDv16_U6__boolc .globl __Z3fooDv8_t .globl __Z3fooDv8_s .globl __Z3fooDv8_U6__bools .globl __Z3fooDv4_j .globl __Z3fooDv4_i .globl __Z3fooDv4_U6__booli .globl __Z3fooDv4_f .globl __Z3fooDv8_u7__pixel .globl __Z3fooi .globl __Z3fooj .globl __Z3foof
[Bug tree-optimization/59617] [vectorizer] ICE in vectorizable_mask_load_store with AVX-512F's gathers enabled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59617
--- Comment #4 from Uroš Bizjak ---
(In reply to Dominique d'Humieres from comment #3)
> The test gcc.target/i386/avx512f-gather-5.c fails on darwin
>
> FAIL: gcc.target/i386/avx512f-gather-5.c scan-assembler gather[^\\n]*zmm
>
> There is no 'gather' in the avx512f-gather-5.s file.
I have compiled the preprocessed file with a crosscompiler from
x86_64-pc-linux-gnu to x86_64-apple-darwin10.8.0 (gcc was configured with
--target=x86_64-apple-darwin10.8.0) without problems.
(preprocessed file was obtained from the native x86_64-pc-linux-gnu
compilation).
$ ~/gcc-build-xxx/gcc/cc1 -O3 -mavx512f -quiet avx512f-gather-5.i
$ grep gather avx512f-gather-5.s
vgatherdps (%rbx,%zmm0,4), %zmm2{%k2}
vgatherdps (%rdx,%zmm0,4), %zmm1{%k3}
[Bug bootstrap/60719] With --program-prefix=$target_alias --program-suffix=-$version install-driver breaks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60719 --- Comment #2 from Richard Biener --- Author: rguenth Date: Wed Apr 2 07:52:36 2014 New Revision: 209010 URL: http://gcc.gnu.org/viewcvs?rev=209010&root=gcc&view=rev Log: 2014-04-02 Richard Biener PR bootstrap/60719 * Makefile.in (install-driver): Guard extra installs with special names properly. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in
[Bug c++/60729] Compiler failure for combination of -ftrapv and -O3: compiler error: in prepare_cmp_insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60729 --- Comment #4 from Richard Biener --- Author: rguenth Date: Wed Apr 2 08:26:57 2014 New Revision: 209012 URL: http://gcc.gnu.org/viewcvs?rev=209012&root=gcc&view=rev Log: 2014-04-02 Richard Biener PR middle-end/60729 * optabs.c (expand_abs_nojump): Honor flag_trapv only for MODE_INTs. Properly use negv_optab. (expand_abs): Likewise. * g++.dg/vect/pr60729.cc: New testcase. Added: trunk/gcc/testsuite/g++.dg/vect/pr60729.cc Modified: trunk/gcc/ChangeLog trunk/gcc/optabs.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/60729] [4.8 Regression] Compiler failure for combination of -ftrapv and -O3: compiler error: in prepare_cmp_insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60729 Richard Biener changed: What|Removed |Added Component|c++ |middle-end Known to work||4.7.3, 4.9.0 Target Milestone|--- |4.8.3 Summary|Compiler failure for|[4.8 Regression] Compiler |combination of -ftrapv and |failure for combination of |-O3: compiler error: in |-ftrapv and -O3: compiler |prepare_cmp_insn|error: in prepare_cmp_insn --- Comment #5 from Richard Biener --- Fixed on trunk sofar.
[Bug bootstrap/60719] With --program-prefix=$target_alias --program-suffix=-$version install-driver breaks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60719 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed for 4.9.
[Bug target/43751] dsymutil is not called for fortran and, under some circumstances not for other FEs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43751 --- Comment #21 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Wed Apr 2 08:34:45 2014 New Revision: 209016 URL: http://gcc.gnu.org/viewcvs?rev=209016&root=gcc&view=rev Log: 2014-04-02 Dominique d'Humieres PR target/43751 * lib/prune.exp: Modify the regular express to prune the new warnings introduced by r205679 on darwin9. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/prune.exp
[Bug rtl-optimization/60738] A missing opportunity about process_single_reg_class_operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60738 Richard Biener changed: What|Removed |Added Keywords||missed-optimization, ra Severity|normal |enhancement
[Bug tree-optimization/50417] regression: memcpy with known alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417 Richard Biener changed: What|Removed |Added CC||anton at samba dot org --- Comment #5 from Richard Biener --- *** Bug 60737 has been marked as a duplicate of this bug. ***
[Bug middle-end/60737] rs6000 expand_block_clear uses word stores on double word pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60737 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Richard Biener --- there isn't any alignment info. *** This bug has been marked as a duplicate of bug 50417 ***
[Bug preprocessor/60736] Crash in preprocessor including stdc-predef.h when it does not exist on glibc-based systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-04-02 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Works for me on x86_64-linux. Please provide gcc -v output to properly specify target and build options. Btw, glibc 2.18 has stdc-predef.h, so what libc are you using?
[Bug tree-optimization/60733] [4.9 Regression] ICE due to SLSR on valid code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60733 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-04-02 Target Milestone|--- |4.9.0 Summary|ICE by LTO on valid code at |[4.9 Regression] ICE due to |-O3 on x86_64-linux-gnu |SLSR on valid code at -O3 ||on x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed. I'll have a look.
[Bug target/54407] FAIL: 30_threads/condition_variable/54185.cc execution test program timed out on powerpc-apple-darwin9 and x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54407 --- Comment #21 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Wed Apr 2 08:44:40 2014 New Revision: 209017 URL: http://gcc.gnu.org/viewcvs?rev=209017&root=gcc&view=rev Log: 2014-04-02 Dominique d'Humieres Jack Howarth PR target/54407 * testsuite/30_threads/condition_variable/54185.cc: Skip for darwin < 11. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/30_threads/condition_variable/54185.cc
[Bug target/54083] FAIL: gcc.dg/torture/pr53922.c on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54083 --- Comment #23 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Wed Apr 2 08:58:03 2014 New Revision: 209018 URL: http://gcc.gnu.org/viewcvs?rev=209018&root=gcc&view=rev Log: 2014-03-26 Dominique d'Humieres Iain Sandoe PR target/54083 * gcc.dg/attr-weakref-1.c: Allow the test on darwin with the additional options -Wl,-undefined,dynamic_lookup and -Wl,-flat_namespace. * gcc.dg/torture/pr53922.c: Additional option -Wl,-flat_namespace for darwin[89]. * gcc.dg/torture/pr60092.c: Additional options -Wl,-undefined,dynamic_lookup and -Wl,-flat_namespace for darwin[89]. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/attr-weakref-1.c trunk/gcc/testsuite/gcc.dg/torture/pr53922.c trunk/gcc/testsuite/gcc.dg/torture/pr60092.c
[Bug c++/60731] [4.7/4.8/4.9 Regression] dynamic library not getting reinitialized on multiple calls to dlopen()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60731 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-02 Known to work||4.4.7 Target Milestone|--- |4.7.4 Summary|dynamic library not getting |[4.7/4.8/4.9 Regression] |reinitialized on multiple |dynamic library not getting |calls to dlopen() |reinitialized on multiple ||calls to dlopen() Ever confirmed|0 |1 Known to fail||4.5.4, 4.8.2, 4.9.0 --- Comment #1 from Richard Biener --- Works up to GCC 4.4, fails since GCC 4.5. It's not clear what makes the difference here. Btw, with LD_DEBUG=all I see 10389: opening file=./static.so [0]; direct_opencount=2 10389: 10389: symbol=routine; lookup in file=./static.so [0] 10389: binding file ./static.so [0] to ./static.so [0]: normal symbol `routine' count:2 10389: opening file=./static.so [0]; direct_opencount=3 10389: 10389: symbol=routine; lookup in file=./static.so [0] 10389: binding file ./static.so [0] to ./static.so [0]: normal symbol `routine' count:3 so the dlclose call does nothing. While in the working case: 10438: 10438: file=./static.so [0]; dynamically loaded by ./test_static [0] 10438: file=./static.so [0]; generating link map 10438: dynamic: 0x76ffede0 base: 0x76dfd000 size: 0x002020a8 10438: entry: 0x76dfdb10 phdr: 0x76dfd040 phnum: 7 10438: calling init: ./static.so 10438: 10438: opening file=./static.so [0]; direct_opencount=1 10438: 10438: symbol=routine; lookup in file=./static.so [0] 10438: binding file ./static.so [0] to ./static.so [0]: normal symbol `routine' count:1 10438: 10438: calling fini: ./static.so [0] 10438: 10438: 10438: file=./static.so [0]; destroying link map
[Bug fortran/60739] New: Maybe uninitialized with deferred length character
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60739
Bug ID: 60739
Summary: Maybe uninitialized with deferred length character
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vladimir.fuka at gmail dot com
subroutine sub(str)
character(*) :: str
character(:), allocatable :: tmp
tmp = str
print *,allocated(tmp)
end
gfortran-4.9 uninit.f90 -c -Wall
uninit.f90: In function ‘sub’:
uninit.f90:5:0: warning: ‘.tmp’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
tmp = str
^
-fdump-tree-original:
character(kind=1)[1:.tmp] * tmp;
integer(kind=4) .tmp;
bitsizetype D.2326;
sizetype D.2327;
try
{
D.2326 = (bitsizetype) (sizetype) NON_LVALUE_EXPR <_str> * 8;
D.2327 = (sizetype) NON_LVALUE_EXPR <_str>;
tmp = 0B;
{
integer(kind=4) D.2321;
integer(kind=4) D.2320;
integer(kind=4) D.2319;
D.2319 = _str;
if (tmp != 0B) goto L.1;
tmp = (character(kind=1)[1:.tmp] *) __builtin_malloc (MAX_EXPR
<(sizetype) _str, 1>);
goto L.2;
L.1:;
if (.tmp == _str) goto L.2;
tmp = (character(kind=1)[1:.tmp] *) __builtin_realloc ((void *) tmp,
MAX_EXPR <(sizetype) _str, 1>);
L.2:;
.tmp = _str;
D.2320 = _str;
D.2321 = .tmp;
if (D.2321 != 0)
{
if ((unsigned long) D.2320 >= (unsigned long) D.2321)
{
__builtin_memmove ((void *) tmp, (void *) str, (unsigned long)
D.2321);
}
else
{
__builtin_memmove ((void *) tmp, (void *) str, (unsigned long)
D.2320);
__builtin_memset ((void *) tmp + (sizetype) D.2320, 32,
(unsigned long) D.2321 - (unsigned long) D.2320);
}
}
}
...
[Bug tree-optimization/60733] [4.9 Regression] ICE due to SLSR on valid code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60733 Richard Biener changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot gnu.org --- Comment #3 from Richard Biener --- Seems that nearest_common_dominator_for_cands doesn't consider uses. Bill, can you have a look please?
[Bug fortran/60739] Maybe uninitialized with deferred length character
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60739 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-02 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed on 4.6 up to trunk (4.9 r209002). The warning disappears with -O1 and above.
[Bug c++/57887] nested non-type template parameters not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57887 --- Comment #9 from Jonathan Wakely --- (In reply to Jaak Ristioja from comment #8) > also probably fixed by 204818. It was definitely fixed by r204818. I don't know what commit fixed the 4.7 ICE
[Bug c++/59361] cannot expand parenthesized pack expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59361 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-02 Ever confirmed|0 |1
[Bug c++/60731] [4.7/4.8/4.9 Regression] dynamic library not getting reinitialized on multiple calls to dlopen()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60731
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2 from Richard Biener ---
We hit
void
_dl_close (void *_map)
{
struct link_map *map = _map;
/* First see whether we can remove the object at all. */
if (__builtin_expect (map->l_flags_1 & DF_1_NODELETE, 0))
{
assert (map->l_init_called);
/* Nope. Do nothing. */
return;
the DF_1_NODELETE flag is set already after the first dlopen call which sets
it via do_lookup_x for the STB_GNU_UNIQUE symbol _ZGVZ16make_static_stayvE3smp
if (map->l_type == lt_loaded)
/* Make sure we don't unload this object by
setting the appropriate flag. */
((struct link_map *) map)->l_flags_1 |= DF_1_NODELETE;
so this either points to a "bad" design on the guard code for initializing
'smp' or to a weakness in the dynamic loader which doesn't handle unloading
of objects which define any(?) STB_GNU_UNIQUE symbol. Note the above is
guarded with
if ((type_class & ELF_RTYPE_CLASS_COPY) != 0)
enter (entries, size, new_hash, strtab + sym->st_name, ref,
undef_map);
else
{
enter (entries, size, new_hash, strtab + sym->st_name, sym,
map);
if (map->l_type == lt_loaded)
/* Make sure we don't unload this object by
setting the appropriate flag. */
((struct link_map *) map)->l_flags_1 |= DF_1_NODELETE;
}
thus if this were referenced via a copy relocation it would work.
Jason?
[Bug libstdc++/60734] Undefined behavior in g++-v4/bits/stl_tree.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-04-02 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- The analysis looks right. The static_cast is definitely undefined. You can't dereference the end() iterator so we don't need a valid pointer, so the reinterpret_cast is OK. I'd like to be able to reproduce it though, the toy examples I've tried don't get the ubsan error.
[Bug libstdc++/60734] Undefined behavior in g++-v4/bits/stl_tree.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Our ubsan does not yet detect the "downcast of address..." error. Maybe in next stage1.
[Bug libstdc++/60734] Undefined behavior in g++-v4/bits/stl_tree.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734 --- Comment #3 from Jonathan Wakely --- Thanks Marek, in that case this is less high priority IMHO
[Bug target/53090] suboptimal ivopt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53090 --- Comment #3 from Richard Biener --- I think the main observation is that use 1 address in statement _15 = *_14; at position *_14 type int * base perm_9(D) + (sizetype) ((long unsigned int) (k_4(D) + -1) * 4) step 18446744073709551612 base object (void *) perm_9(D) related candidates ((long unsigned int) (k_4(D) + -1) * 4) is a widening multiplication and the x86 addressing mode widens(?). Note that with the current specification of TARGET_MEM_REF: /* Low-level memory addressing. Operands are BASE (address of static or global variable or register), OFFSET (integer constant), INDEX (register), STEP (integer constant), INDEX2 (register), The corresponding address is BASE + STEP * INDEX + INDEX2 + OFFSET. Only variations and values valid on the target are allowed. The type of STEP, INDEX and INDEX2 is sizetype. this isn't allowed. One would need to a) extend the spec to allow step * index be a widening multiplication, b) extend the recog code in tree-ssa-address.c properly to see what the target does here, esp. whether it treats INDEX as signed or unsigned. Then IVOPTs could choose (unsigned) k_4 as IV and use it directly in the widening multiplication places. A way to test this would be to emit the widening multiplies from c-common.c:pointer_int_sum already. (but expect lots of fallout, there is a lot of code handling MULT_EXPR but not a lot handling WIDEN_MULT_EXPR)
[Bug tree-optimization/60740] New: ICE in extract_affine w/ -O2 -ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60740
Bug ID: 60740
Summary: ICE in extract_affine w/ -O2 -ftree-loop-linear
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
At least gcc 4.8.2 and and 4.9.0-alpha20140330 fail to compile the following
code snippet w/ -O2 -ftree-loop-linear on x86_64-pc-linux-gnu:
int **db6 = 0;
void
k26(void)
{
static int geb = 0;
int *a22 = &geb;
int **l30 = &a22;
int *c4b;
int ndf;
for (ndf = 0; ndf <= 1; ++ndf)
*c4b = (db6 == l30) && (*a22)--;
}
% gcc-4.9.0-alpha20140330 -c -O2 -ftree-loop-linear testcase.c
crash1.c: In function 'k26':
crash1.c:4:1: internal compiler error: in extract_affine, at
graphite-sese-to-poly.c:846
k26(void)
^
% gcc-4.8.2 -c -O2 -ftree-loop-linear testcase.c
crash1.c: In function 'k26':
crash1.c:4:1: internal compiler error: in extract_affine, at
graphite-sese-to-poly.c:827
k26(void)
^
% gcc-4.7.3 -c -O2 -ftree-loop-linear testcase.c
% echo $?
I failed to reduce the testcase any further.
[Bug tree-optimization/60740] [4.8/4.9 Regression] ICE in extract_affine w/ -O2 -ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60740 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-02 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|ICE in extract_affine w/|[4.8/4.9 Regression] ICE in |-O2 -ftree-loop-linear |extract_affine w/ -O2 ||-ftree-loop-linear Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed (-ftree-loop-linear is a graphite stuff).
[Bug target/53090] suboptimal ivopt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53090
--- Comment #4 from Richard Biener ---
Sth like
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 209018)
+++ gcc/c-family/c-common.c (working copy)
@@ -4415,19 +4415,21 @@ pointer_int_sum (location_t loc, enum tr
/* Convert the integer argument to a type the same size as sizetype
so the multiply won't overflow spuriously. */
+ enum tree_code code = MULT_EXPR;
if (TYPE_PRECISION (TREE_TYPE (intop)) != TYPE_PRECISION (sizetype)
|| TYPE_UNSIGNED (TREE_TYPE (intop)) != TYPE_UNSIGNED (sizetype))
-intop = convert (c_common_type_for_size (TYPE_PRECISION (sizetype),
-TYPE_UNSIGNED (sizetype)), intop);
+code = WIDEN_MULT_EXPR;
/* Replace the integer argument with a suitable product by the object size.
Do this multiplication as signed, then convert to the appropriate type
for the pointer operation and disregard an overflow that occurred only
because of the sign-extension change in the latter conversion. */
{
-tree t = build_binary_op (loc,
- MULT_EXPR, intop,
- convert (TREE_TYPE (intop), size_exp), 1);
+tree t = fold_build2_loc (loc, code,
+ c_common_type_for_size (TYPE_PRECISION
(sizetype),
+ TYPE_UNSIGNED
(sizetype)),
+ intop,
+ convert (TREE_TYPE (intop), size_exp));
intop = convert (sizetype, t);
if (TREE_OVERFLOW_P (intop) && !TREE_OVERFLOW (t))
intop = build_int_cst_wide (TREE_TYPE (intop), TREE_INT_CST_LOW (intop),
but then you notice that for example SCEV doesn't handle WIDEN_MULT_EXPR.
[Bug target/53090] suboptimal ivopt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53090
--- Comment #5 from Richard Biener ---
(In reply to Richard Biener from comment #4)
> Sth like
>
> Index: gcc/c-family/c-common.c
> ===
> --- gcc/c-family/c-common.c (revision 209018)
> +++ gcc/c-family/c-common.c (working copy)
> @@ -4415,19 +4415,21 @@ pointer_int_sum (location_t loc, enum tr
>
>/* Convert the integer argument to a type the same size as sizetype
> so the multiply won't overflow spuriously. */
> + enum tree_code code = MULT_EXPR;
>if (TYPE_PRECISION (TREE_TYPE (intop)) != TYPE_PRECISION (sizetype)
>|| TYPE_UNSIGNED (TREE_TYPE (intop)) != TYPE_UNSIGNED (sizetype))
> -intop = convert (c_common_type_for_size (TYPE_PRECISION (sizetype),
> -TYPE_UNSIGNED (sizetype)),
> intop);
> +code = WIDEN_MULT_EXPR;
>
>/* Replace the integer argument with a suitable product by the object
> size.
> Do this multiplication as signed, then convert to the appropriate type
> for the pointer operation and disregard an overflow that occurred only
> because of the sign-extension change in the latter conversion. */
>{
> -tree t = build_binary_op (loc,
> - MULT_EXPR, intop,
> - convert (TREE_TYPE (intop), size_exp), 1);
> +tree t = fold_build2_loc (loc, code,
> + c_common_type_for_size (TYPE_PRECISION
> (sizetype),
> + TYPE_UNSIGNED
> (sizetype)),
> + intop,
> + convert (TREE_TYPE (intop), size_exp));
> intop = convert (sizetype, t);
> if (TREE_OVERFLOW_P (intop) && !TREE_OVERFLOW (t))
>intop = build_int_cst_wide (TREE_TYPE (intop), TREE_INT_CST_LOW
> (intop),
>
>
> but then you notice that for example SCEV doesn't handle WIDEN_MULT_EXPR.
But for example SCEV could be teached to _create_ the WIDEN_MULT_EXPRs
in the first place ... thus analyze for example _14 instead of as
(set_scalar_evolution
instantiated_below = 4
(scalar = _14)
(scalar_evolution = {perm_9(D) + (sizetype) ((long unsigned int) j_5 * 4), +,
18446744073709551612}_1))
as
(set_scalar_evolution
instantiated_below = 4
(scalar = _14)
(scalar_evolution = {perm_9(D) + (sizetype) (j_5 w* 4), +,
18446744073709551612}_1))
[Bug tree-optimization/60733] [4.9 Regression] ICE due to SLSR on valid code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60733 --- Comment #4 from Bill Schmidt --- Ok, will have a look today.
[Bug preprocessor/60736] Crash in preprocessor including stdc-predef.h when it does not exist on glibc-based systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736 Ian Lance Taylor changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Ian Lance Taylor --- My system has Ubuntu EGLIBC 2.15-0ubuntu10.5 and does not have /usr/include/stdc-predef.h gcc -v output: > echo "#include " | gcc/xgcc -Bgcc/ -x c -v - Reading specs from gcc/specs COLLECT_GCC=gcc/xgcc COLLECT_LTO_WRAPPER=gcc/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../trunk/configure --prefix=/home/iant/gcc/go-install --with-ld=/home/iant/binutils/gold-dir/ld --with-arch-32=i686 --with-gold target_alias=x86_64-unknown-linux-gnu CFLAGS='-g -O2' LDFLAGS= CXXFLAGS='-g -O2' 'CC_FOR_TARGET= /home/iant/gcc/go-bootstrap/./gcc/xgcc -B/home/iant/gcc/go-bootstrap/./gcc/' 'GCJ_FOR_TARGET= ' 'GFORTRAN_FOR_TARGET= ' 'GOC_FOR_TARGET= /home/iant/gcc/go-bootstrap/./gcc/gccgo -B/home/iant/gcc/go-bootstrap/./gcc/' AR_FOR_TARGET=ar AS_FOR_TARGET=as DLLTOOL_FOR_TARGET=dlltool LD_FOR_TARGET=ld LIPO_FOR_TARGET=lipo NM_FOR_TARGET=nm OBJDUMP_FOR_TARGET=objdump RANLIB_FOR_TARGET=ranlib STRIP_FOR_TARGET=strip WINDRES_FOR_TARGET=windres WINDMC_FOR_TARGET=windmc --enable-languages=c,c++,go,lto --no-create --no-recursion : (reconfigured) ../trunk/configure --prefix=/home/iant/gcc/go-install --with-ld=/home/iant/binutils/gold-dir/ld --with-arch-32=i686 --with-gold target_alias=x86_64-unknown-linux-gnu CFLAGS='-g -O2' LDFLAGS= CXXFLAGS='-g -O2' 'CC_FOR_TARGET= /home/iant/gcc/go-bootstrap/./gcc/xgcc -B/home/iant/gcc/go-bootstrap/./gcc/' 'GCJ_FOR_TARGET= ' 'GFORTRAN_FOR_TARGET= ' 'GOC_FOR_TARGET= /home/iant/gcc/go-bootstrap/./gcc/gccgo -B/home/iant/gcc/go-bootstrap/./gcc/' AR_FOR_TARGET=ar AS_FOR_TARGET=as DLLTOOL_FOR_TARGET=dlltool LD_FOR_TARGET=ld LIPO_FOR_TARGET=lipo NM_FOR_TARGET=nm OBJDUMP_FOR_TARGET=objdump RANLIB_FOR_TARGET=ranlib STRIP_FOR_TARGET=strip WINDRES_FOR_TARGET=windres WINDMC_FOR_TARGET=windmc --enable-languages=c,c++,go,lto --no-create --no-recursion : (reconfigured) ../trunk/configure --prefix=/home/iant/gcc/go-install --with-ld=/home/iant/binutils/gold-dir/ld --with-arch-32=i686 --with-gold target_alias=x86_64-unknown-linux-gnu CFLAGS='-g -O2' LDFLAGS= CXXFLAGS='-g -O2' 'CC_FOR_TARGET= /home/iant/gcc/go-bootstrap/./gcc/xgcc -B/home/iant/gcc/go-bootstrap/./gcc/' 'GCJ_FOR_TARGET= ' 'GFORTRAN_FOR_TARGET= ' 'GOC_FOR_TARGET= /home/iant/gcc/go-bootstrap/./gcc/gccgo -B/home/iant/gcc/go-bootstrap/./gcc/' AR_FOR_TARGET=ar AS_FOR_TARGET=as DLLTOOL_FOR_TARGET=dlltool LD_FOR_TARGET=ld LIPO_FOR_TARGET=lipo NM_FOR_TARGET=nm OBJDUMP_FOR_TARGET=objdump RANLIB_FOR_TARGET=ranlib STRIP_FOR_TARGET=strip WINDRES_FOR_TARGET=windres WINDMC_FOR_TARGET=windmc --enable-languages=c,c++,go,lto --no-create --no-recursion : (reconfigured) ../trunk/configure --prefix=/home/iant/gcc/go-install --with-ld=/home/iant/binutils/gold-dir/ld --with-arch-32=i686 --with-gold target_alias=x86_64-unknown-linux-gnu CFLAGS='-g -O2' LDFLAGS= CXXFLAGS='-g -O2' 'CC_FOR_TARGET= /home/iant/gcc/go-bootstrap/./gcc/xgcc -B/home/iant/gcc/go-bootstrap/./gcc/' 'GCJ_FOR_TARGET= ' 'GFORTRAN_FOR_TARGET= ' 'GOC_FOR_TARGET= /home/iant/gcc/go-bootstrap/./gcc/gccgo -B/home/iant/gcc/go-bootstrap/./gcc/' AR_FOR_TARGET=ar AS_FOR_TARGET=as DLLTOOL_FOR_TARGET=dlltool LD_FOR_TARGET=ld LIPO_FOR_TARGET=lipo NM_FOR_TARGET=nm OBJDUMP_FOR_TARGET=objdump RANLIB_FOR_TARGET=ranlib STRIP_FOR_TARGET=strip WINDRES_FOR_TARGET=windres WINDMC_FOR_TARGET=windmc --enable-languages=c,c++,go,lto --no-create --no-recursion : (reconfigured) ../trunk/configure --prefix=/home/iant/gcc/go-install --with-ld=/home/iant/binutils/gold-dir/ld --with-arch-32=i686 --with-gold target_alias=x86_64-unknown-linux-gnu CFLAGS='-g -O2' LDFLAGS= CXXFLAGS='-g -O2' 'CC_FOR_TARGET= /home/iant/gcc/go-bootstrap/./gcc/xgcc -B/home/iant/gcc/go-bootstrap/./gcc/' 'GCJ_FOR_TARGET= ' 'GFORTRAN_FOR_TARGET= ' 'GOC_FOR_TARGET= /home/iant/gcc/go-bootstrap/./gcc/gccgo -B/home/iant/gcc/go-bootstrap/./gcc/' AR_FOR_TARGET=ar AS_FOR_TARGET=as DLLTOOL_FOR_TARGET=dlltool LD_FOR_TARGET=ld LIPO_FOR_TARGET=lipo NM_FOR_TARGET=nm OBJDUMP_FOR_TARGET=objdump RANLIB_FOR_TARGET=ranlib STRIP_FOR_TARGET=strip WINDRES_FOR_TARGET=windres WINDMC_FOR_TARGET=windmc --enable-languages=c,c++,go,lto --no-create --no-recursion : (reconfigured) ../trunk/configure --prefix=/home/iant/gcc/go-install --with-ld=/home/iant/binutils/gold-dir/ld --with-arch-32=i686 --with-gold target_alias=x86_64-unknown-linux-gnu CFLAGS='-g -O2' LDFLAGS= CXXFLAGS='-g -O2' 'CC_FOR_TARGET= /home/iant/gcc/go-bootstrap/./gcc/xgcc -B/home/iant/gcc/go-bootstrap/./gcc/' 'GCJ_FOR_TARGET= ' 'GFORTRAN_FOR_TARGET= ' 'GOC_FOR_TARGET= /home/iant/gcc/go-bootstrap/./gcc/gccgo -B/home/iant/gcc/go-bootstrap/./gcc/' AR_FOR_TARGET=ar AS_FOR_TARGET=as DLLTOOL_FOR_TARGET=dlltool LD_FOR_TARGET=ld LIPO_FOR_TARGET=lipo NM_FOR_TARGET=nm OBJDUMP_FOR_TARGET=objdump RANLIB_FOR_TARGET=ranlib
[Bug preprocessor/60736] Crash in preprocessor including stdc-predef.h when it does not exist on glibc-based systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #4 from Markus Trippelsdorf --- Maybe related to PR58893. Can you run it under valgrind please.
[Bug middle-end/60741] New: [-Wmaybe-uninitialized] false negative and confusing warning message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60741
Bug ID: 60741
Summary: [-Wmaybe-uninitialized] false negative and confusing
warning message
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: skvadrik at gmail dot com
Created attachment 32521
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32521&action=edit
wmaybe_uninitialized_strange_behavior.c
Given this code:
enum A { A1, A2 };
enum B { B1 };
static inline int fa (enum A a) {
int n;
switch (a) {
case A1: n = 1; break;
case A2: n = 2; break;
}
return n;
}
static inline int fb (enum B b) {
int n;
switch (b) {
case B1: n = 1; break;
}
return n;
}
int main (int argc, char **) {
return fa((A)argc) + fb((B)argc);
}
$ g++ -O1 -Wall wmaybe_uninitialized_strange_behavior.c
wmaybe_uninitialized_strange_behavior.c: In function ‘int main(int, char**)’:
wmaybe_uninitialized_strange_behavior.c:27:36: warning: ‘n’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
return fa((A)argc) + fb((B)argc);
^
1) gcc generates warning for 'fa' function, but not for 'fb' function.
2) The message points to the end of expression, that contains 'fa' call (not to
'fa' declaration, or at least to 'fa' call). The message mentions name of a
variable, that is used in 'fa' declaration. So we're lucky that the same name
doesn't appear in the calling function (main).
3) This all happens with -O1 or higher, with -O0 there's no warnings at all!
[Bug c++/59361] cannot expand parenthesized pack expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59361 Andrew Sutton changed: What|Removed |Added CC||andrew.n.sutton at gmail dot com --- Comment #2 from Andrew Sutton --- Created attachment 32522 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32522&action=edit Proposed solution The problem occurs in cp_parser_cast_expression. A term of having the form (T())... cannot be parsed as a cast expression since the the expansion is only applied to a part of the cast expression. If ... follows the closing paren, the expression must be parsed as unary expression.
[Bug middle-end/60741] [-Wmaybe-uninitialized] false negative and confusing warning message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60741 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez --- We don't warn for fb(), because PR18501. So the only original bug here is the location when warning. The problem is the locations that are propagated when transforming expressions. We reach: # n_4 = PHI : [test.cc : 20:32] # RANGE [-2147483648, 2147483647] NONZERO 0x7 _2 = n_4 + 1; When instead we should have a location for n_4 that is different than the location for '+'. In any case, pointing to the closing parenthesis is very confusing. At worst it should point to the '+'.
[Bug preprocessor/60736] Crash in preprocessor including stdc-predef.h when it does not exist on glibc-based systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736 --- Comment #5 from Ian Lance Taylor --- This is easy enough to recreate--do you really need valgrind output? In any case, here it is. > cat foo.c #include > valgrind gcc/cc1 foo.c ==25367== Memcheck, a memory error detector ==25367== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==25367== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==25367== Command: gcc/cc1 foo.c ==25367== vex amd64->IR: unhandled instruction bytes: 0xF3 0x48 0xF 0xBC 0xC3 0x48 0x98 0x48 ==25367== valgrind: Unrecognised instruction at address 0x608f90. ==25367==at 0x608F90: init_ggc() (hwint.h:260) ==25367==by 0x99DDEE: toplev_main(int, char**) (toplev.c:1157) ==25367==by 0x5A3176C: (below main) (libc-start.c:226) ==25367== Your program just tried to execute an instruction that Valgrind ==25367== did not recognise. There are two possible reasons for this. ==25367== 1. Your program has a bug and erroneously jumped to a non-code ==25367==location. If you are running Memcheck and you just saw a ==25367==warning about a bad jump, it's probably your program's fault. ==25367== 2. The instruction is legitimate but Valgrind doesn't handle it, ==25367==i.e. it's Valgrind's fault. If you think this is the case or ==25367==you are not sure, please let us know and we'll try to fix it. ==25367== Either way, Valgrind will now raise a SIGILL signal which will ==25367== probably kill your program. ==25367== Invalid read of size 4 ==25367==at 0xF1CC8D: linemap_location_from_macro_expansion_p(line_maps*, unsigned int) (line-map.c:948) ==25367==by 0xF1CE2E: linemap_lookup(line_maps*, unsigned int) (line-map.c:642) ==25367==by 0x9DC257: virt_loc_aware_diagnostic_finalizer(diagnostic_context*, diagnostic_info*) (tree-diagnostic.c:111) ==25367==by 0xF02837: diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) (diagnostic.c:801) ==25367==by 0xF0357F: internal_error(char const*, ...) (diagnostic.c:1136) ==25367==by 0x99C70F: crash_signal(int) (toplev.c:337) ==25367==by 0x5A4649F: ??? (in /lib/x86_64-linux-gnu/libc-2.15.so) ==25367==by 0x608F8F: init_ggc() (hwint.h:307) ==25367==by 0x99DDEE: toplev_main(int, char**) (toplev.c:1157) ==25367==by 0x5A3176C: (below main) (libc-start.c:226) ==25367== Address 0x24 is not stack'd, malloc'd or (recently) free'd ==25367== cc1: internal compiler error: Illegal instruction ==25367== ==25367== Process terminating with default action of signal 11 (SIGSEGV) ==25367== Access not within mapped region at address 0x24 ==25367==at 0xF1CC8D: linemap_location_from_macro_expansion_p(line_maps*, unsigned int) (line-map.c:948) ==25367==by 0xF1CE2E: linemap_lookup(line_maps*, unsigned int) (line-map.c:642) ==25367==by 0x9DC257: virt_loc_aware_diagnostic_finalizer(diagnostic_context*, diagnostic_info*) (tree-diagnostic.c:111) ==25367==by 0xF02837: diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) (diagnostic.c:801) ==25367==by 0xF0357F: internal_error(char const*, ...) (diagnostic.c:1136) ==25367==by 0x99C70F: crash_signal(int) (toplev.c:337) ==25367==by 0x5A4649F: ??? (in /lib/x86_64-linux-gnu/libc-2.15.so) ==25367==by 0xF1CC8C: linemap_location_from_macro_expansion_p(line_maps*, unsigned int) (line-map.c:948) ==25367==by 0xF1CE2E: linemap_lookup(line_maps*, unsigned int) (line-map.c:642) ==25367==by 0x9DC257: virt_loc_aware_diagnostic_finalizer(diagnostic_context*, diagnostic_info*) (tree-diagnostic.c:111) ==25367==by 0xF02837: diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) (diagnostic.c:801) ==25367==by 0xF0357F: internal_error(char const*, ...) (diagnostic.c:1136) ==25367== If you believe this happened as a result of a stack ==25367== overflow in your program's main thread (unlikely but ==25367== possible), you can try to increase the size of the ==25367== main thread stack using the --main-stacksize= flag. ==25367== The main thread stack size used in this run was 67108864. ==25367== ==25367== HEAP SUMMARY: ==25367== in use at exit: 22,246 bytes in 10 blocks ==25367== total heap usage: 266 allocs, 256 frees, 45,231 bytes allocated ==25367== ==25367== LEAK SUMMARY: ==25367==definitely lost: 31 bytes in 1 blocks ==25367==indirectly lost: 0 bytes in 0 blocks ==25367== possibly lost: 0 bytes in 0 blocks ==25367==still reachable: 22,215 bytes in 9 blocks ==25367== suppressed: 0 bytes in 0 blocks ==25367== Rerun with --leak-check=full to see details of leaked memory ==25367== ==25367== For counts of detected and suppressed errors, rerun with: -v ==25367== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 2 from 2) Segmentation fault (core dumped)
[Bug middle-end/60640] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60640 --- Comment #10 from Martin Jambor --- Created attachment 32523 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32523&action=edit Proposed patch for the 4.8 branch Independent of the trunk fix, I'm going to propose this simple patch which disables propagation through thunks for the 4.8 branch. It passes bootstrap and testsuite on x86_64-linux.
[Bug middle-end/60640] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60640 --- Comment #11 from Martin Jambor --- Created attachment 32524 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32524&action=edit Proposed patch for the 4.7 branch Independent of the trunk fix, I'm going to propose this simple patch which disables propagation through thunks for the 4.7 branch. It passes bootstrap and testsuite on x86_64-linux.
[Bug preprocessor/60736] Crash in preprocessor including stdc-predef.h when it does not exist on glibc-based systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736 --- Comment #6 from Markus Trippelsdorf --- Thanks. I get: ==15253== ==15253== Invalid read of size 1 ==15253==at 0xD2BEB7: cpp_errno(cpp_reader*, int, char const*) (errors.c:233) ==15253==by 0xD30DD2: _cpp_find_file (files.c:571) ==15253==by 0xD3139E: _cpp_stack_include (files.c:993) ==15253==by 0xD291E5: do_include_common(cpp_reader*, include_type) (directives.c:793) ==15253==by 0xD29D67: _cpp_handle_directive (directives.c:492) ==15253==by 0xD3658C: _cpp_lex_token (lex.c:2067) ==15253==by 0xD3ADCF: cpp_get_token_1(cpp_reader*, unsigned int*) (macro.c:2359) ==15253==by 0x594EA9: c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int) (c-lex.c:302) ==15253==by 0x54566F: c_lex_one_token(c_parser*, c_token*) (c-parser.c:234) ==15253==by 0x55F45D: c_parse_file() (c-parser.c:414) ==15253==by 0x599DC3: c_common_parse_file() (c-opts.c:1061) ==15253==by 0x8765C1: compile_file() (toplev.c:548) ==15253== Address 0x0 is not stack'd, malloc'd or (recently) free'd
[Bug preprocessor/60736] Crash in preprocessor including stdc-predef.h when it does not exist on glibc-based systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736
--- Comment #7 from Markus Trippelsdorf ---
diff --git a/libcpp/errors.c b/libcpp/errors.c
index d1ca7a12ff42..fa292214d677 100644
--- a/libcpp/errors.c
+++ b/libcpp/errors.c
@@ -230,7 +230,7 @@ cpp_warning_with_line_syshdr (cpp_reader *pfile, int
reason,
bool
cpp_errno (cpp_reader *pfile, int level, const char *msgid)
{
- if (msgid[0] == '\0')
+ if (msgid && msgid[0] == '\0')
msgid = _("stdout");
return cpp_error (pfile, level, "%s: %s", msgid, xstrerror (errno));
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #206 from Martin Liška --- Firefox (and chromium) memory reports with -flto=9 and -O2; archive contains also memory usage graph: https://docs.google.com/file/d/0B0pisUJ80pO1bnV5V0RtWXJkaVU/edit
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #207 from Martin Liška --- Created attachment 32525 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32525&action=edit Memory usage graphs for -flto=9, -flto=4, -flto=1 with -O2
[Bug lto/60449] Merging function DECLs discards leaf attribute which causes cfg verifier to fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60449 --- Comment #11 from Jan Hubicka --- > OTOH, why do we have to merge the decls/cgraph nodes at all? Can't we simply > make them aliases if tree merging decides the decls are not equal? If we do so, we would never merge external declaration from one unit with definition from other, so everything would go through aliases effectively doubling the symtab. Also aliases currently ar different symbols, not different tree representation of the same symbol, so one would need to rename the declaration and make it to bubble all the way into the assembler file. We can resort to not merging in selected cases, but I would prefer to do that only when we have very good reason why we want to do so.
[Bug preprocessor/60736] Crash in preprocessor including stdc-predef.h when it does not exist on glibc-based systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736 Markus Trippelsdorf changed: What|Removed |Added Known to work||4.7.3 Target Milestone|--- |4.8.4 Known to fail||4.8.3, 4.9.0
[Bug rtl-optimization/60651] Mode switching instructions are sometimes emitted in the wrong order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60651 --- Comment #2 from Jorn Wolfgang Rennecke --- Created attachment 32526 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32526&action=edit preprocessed libjava file With the latest proposed patch, we get an assertion failure building libjava during the i686-pc-linux-gnu bootstrap; this is the command line: ./cc1plus -fpreprocessed interpret.ii -quiet -dumpbase interpret.cc -mtune=generic -march=pentiumpro -auxbase-strip .libs/interpret.o -g -O2 -Wswitch-enum -Wextra -Wall -version -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -ffloat-store -fomit-frame-pointer -fwrapv -fPIC -o interpret.s The block in question looks like this: (code_label/s 9087 9590 9090 17 990 "" [1 uses]) (note 9090 9087 9088 17 [bb 17] NOTE_INSN_BASIC_BLOCK) where the BB_HEAD is the CODE_LABEL, and the BB_END is the NOTE_INSN_BASIC_BLOCK. The caller of new_seginfo is the abnormal-edge code that I've patched to handle non-empty blocks differently; this block is mistaken for a non-empty block. Now, interestingly, the pre-existing code already handles this incorrectly, by inserting instructions between the CODE_LABEL an the NOTE_INSN_BASIC_BLOCK.
[Bug c++/60691] Build fails in libstdc++ with --enable-sjlj-exceptions on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60691 --- Comment #4 from Fabian Vogt --- (In reply to Andrew Pinski from comment #3) > (In reply to Fabian Vogt from comment #2) > > It crashes and produces weird results if linked to bFLT. > > Yes because EABI is an elf only abi, if it does not have a place for the > unwind tables, then it is incompatible with the ABI :). Is it enough to put it (sorted/ordered) anywhere in the binary and point __exidx_start (IIRC) and __exidx_end to the correct positions? > >If SJLJ isn't supported for ARM, why does --enable-sjlj-exceptions still > >exist? > > Because it is supported for some other targets, mainly windows based ones. Hmm.. Windows RT? :P Anyway, I had also reported the bug on binutils' bugzilla and the gas internal error has been fixed. Nick even made a patch for gcc so it doesn't generate bad asm anymore :-) Bug report on gas: https://sourceware.org/bugzilla/show_bug.cgi?id=16765 Proposed patch: https://sourceware.org/bugzilla/attachment.cgi?id=7520
[Bug target/60735] GCC targeting E500 with SPE has errors with the _Decimal64 type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60735 --- Comment #2 from Michael Meissner --- Author: meissner Date: Wed Apr 2 17:03:49 2014 New Revision: 209025 URL: http://gcc.gnu.org/viewcvs?rev=209025&root=gcc&view=rev Log: 2014-04-02 Michael Meissner PR target/60735 * config/rs6000/rs6000.c (rs6000_hard_regno_mode_ok): If we have software floating point or no floating point registers, do not allow any type in the FPRs. Eliminate a test for SPE SIMD types in GPRs that occurs after we tested for GPRs that would never be true. * config/rs6000/rs6000.md (mov_softfloat32, FMOVE64): Rewrite tests to use TARGET_DOUBLE_FLOAT and TARGET_E500_DOUBLE, since the FMOVE64 type is DFmode/DDmode. If TARGET_E500_DOUBLE, specifically allow DDmode, since that does not use the SPE SIMD instructions. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.md
[Bug target/60735] GCC targeting E500 with SPE has errors with the _Decimal64 type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60735 Michael Meissner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Michael Meissner --- Fixed in subversion id 209025.
[Bug target/60735] GCC targeting E500 with SPE has errors with the _Decimal64 type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60735 --- Comment #4 from Michael Meissner --- Author: meissner Date: Wed Apr 2 17:16:33 2014 New Revision: 209026 URL: http://gcc.gnu.org/viewcvs?rev=209026&root=gcc&view=rev Log: 2014-04-02 Michael Meissner Back port mainline subversion id 209025. 2014-04-02 Michael Meissner PR target/60735 * config/rs6000/rs6000.c (rs6000_hard_regno_mode_ok): If we have software floating point or no floating point registers, do not allow any type in the FPRs. Eliminate a test for SPE SIMD types in GPRs that occurs after we tested for GPRs that would never be true. * config/rs6000/rs6000.md (mov_softfloat32, FMOVE64): Rewrite tests to use TARGET_DOUBLE_FLOAT and TARGET_E500_DOUBLE, since the FMOVE64 type is DFmode/DDmode. If TARGET_E500_DOUBLE, specifically allow DDmode, since that does not use the SPE SIMD instructions. Modified: branches/ibm/gcc-4_8-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.c branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.md
[Bug preprocessor/60736] Crash in preprocessor including stdc-predef.h when it does not exist on glibc-based systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736 --- Comment #8 from Ian Lance Taylor --- I don't think that's the right patch, unless there is a good reason for msgid to be NULL. Note that two lines down we are printing msgid, so that would need to be fixed as well. But it would be best if msgid were not NULL.
[Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60732 --- Comment #4 from Brooks Moses --- Interesting. As noted, with -fabi-version=[1 to 3] on Linux, I was getting both sets. Mike, what do you think is the best solution here? We could use Dominique's patch with a comment to the effect that "New-ABI symbols are always emitted on Linux, but only with -fabi-version=4 or later on Darwin." We could revert my change and hardcode -fabi-version=2 for all targets. Or we could take the suggestion from your original review email and duplicate the test into new-ABI and old-ABI versions, and do both of those. (If we duplicate the test, is altivec-7a.C a reasonable name for the duplicate-with-different-ABI, or does it need to be altivec-18.C or whatever the next available number is?)
[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657 --- Comment #7 from Jeffrey A. Law --- Actually, it occurs to me, why don't we fix the predicates. That seems like a better solution than rejecting problematical constants in the insn's condition.
[Bug c++/60731] [4.7/4.8/4.9 Regression] dynamic library not getting reinitialized on multiple calls to dlopen()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60731 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #3 from Jason Merrill --- Right, it was a deliberate choice in ld.so to suppress dlclose of DSOs that use STB_GNU_UNIQUE, which causes problems with some code that relies on reinitialization with dlclose/dlopen. As Ian says in http://gcc.gnu.org/ml/gcc-help/2011-05/msg00450.html this seems excessive; you only need to avoid unloading files that are satisfying symbol references in another DSO. But I guess checking for that was deemed too slow. If you're using the gold linker, you can link with --no-gnu-unique to avoid the use of STB_GNU_UNIQUE. I suppose I should add a compiler flag to turn it off, too...
[Bug preprocessor/60736] Crash in preprocessor including stdc-predef.h when it does not exist on glibc-based systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736 --- Comment #9 from Markus Trippelsdorf --- (In reply to Ian Lance Taylor from comment #8) > I don't think that's the right patch, unless there is a good reason for > msgid to be NULL. Note that two lines down we are printing msgid, so that > would need to be fixed as well. But it would be best if msgid were not NULL. Yes, you're right. So what about this untested patch: diff --git a/libcpp/files.c b/libcpp/files.c index 7e8877854445..30707cf7050b 100644 --- a/libcpp/files.c +++ b/libcpp/files.c @@ -1044,7 +1044,7 @@ open_file_failed (cpp_reader *pfile, _cpp_file *file, int angle_brackets) if (CPP_OPTION (pfile, deps.style) == DEPS_NONE || print_dep || CPP_OPTION (pfile, deps.need_preprocessor_output)) - cpp_errno (pfile, CPP_DL_FATAL, file->path); + cpp_errno (pfile, CPP_DL_FATAL, file->name); else cpp_errno (pfile, CPP_DL_WARNING, file->path); }
[Bug tree-optimization/60733] [4.9 Regression] ICE due to SLSR on valid code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60733 --- Comment #5 from Bill Schmidt --- The logic for placement of initializers for PHI candidates is a bit wrong. They should be placed at the end of the feeding block for the PHI. Currently they can end up being placed too early, as in this case. I'm testing a patch.
[Bug c++/60742] New: ill-formed declarator (array) in selection statement not caught appropriately
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60742
Bug ID: 60742
Summary: ill-formed declarator (array) in selection statement
not caught appropriately
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: filip.roseen at gmail dot com
Created attachment 32527
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32527&action=edit
testcase.cpp
int main () {
if (int a[3] = {1,2,3}) {
(void)a;
}
}
-
[stmt.select]p2:
> The rules for conditions apply both to selction-statements and to
> the for and while statements (6.5) __The declarator shall not
> specify a function or an array.__ If the auto type-specifier appears
> in the decl-specifier-seq, the type of the identifier being
> declared is deduced from the initializer as described in 7.1.6.4.
-
H20:/tmp% g++ -std=c++11 -pedantic-errors testcase.cpp;
H20:/tmp% g++ -std=c++11 -pedantic-errors -Waddress testcase.cpp;
testcase.cpp: In function ‘int main()’:
testcase.cpp:2:25: warning: the address of ‘a’ will always evaluate as ‘true’
[-Waddress]
if (int a[3] = {1,2,3}) {
-
As seen above a diagnostic is only issued if we do `-Waddress` (or some warning
flag that includes the mentioned one).
The problem isn't actually with the address of `a` always evaluting to `true`,
the major problem is that this kind of code is ill-formed; gcc should therefore
reject it.
[ Note: `clang` and `icc` both handles this correctly (ie. rejects it) ]
[Bug rtl-optimization/60650] [ARM] LRA ICE in assign_by_spills
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60650 --- Comment #12 from Vladimir Makarov --- Author: vmakarov Date: Wed Apr 2 20:55:02 2014 New Revision: 209038 URL: http://gcc.gnu.org/viewcvs?rev=209038&root=gcc&view=rev Log: 2014-04-02 Vladimir Makarov PR rtl-optimization/60650 * lra-constraints.c (process_alt_operands): Decrease reject for earlyclobber matching. 2014-04-02 Vladimir Makarov PR rtl-optimization/60650 * gcc.target/arm/pr60650-2.c: New. Added: trunk/gcc/testsuite/gcc.target/arm/pr60650-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/60733] [4.9 Regression] ICE due to SLSR on valid code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60733 --- Comment #6 from Bill Schmidt --- Author: wschmidt Date: Wed Apr 2 22:07:30 2014 New Revision: 209040 URL: http://gcc.gnu.org/viewcvs?rev=209040&root=gcc&view=rev Log: [gcc] 2014-04-02 Bill Schmidt PR tree-optimization/60733 * gimple-ssa-strength-reduction.c (ncd_with_phi): Change required insertion point for PHI candidates to be the end of the feeding block for the PHI argument. [gcc/testsuite] 2014-04-02 Bill Schmidt PR tree-optimization/60733 * gcc.dg/torture/pr60733.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr60733.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-strength-reduction.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/60733] [4.9 Regression] ICE due to SLSR on valid code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60733 Bill Schmidt changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Bill Schmidt --- Fixed. Bug was introduced in 4.9 so no backports are needed.
[Bug tree-optimization/60733] [4.9 Regression] ICE due to SLSR on valid code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60733 --- Comment #8 from Zhendong Su --- (In reply to Bill Schmidt from comment #7) > Fixed. Bug was introduced in 4.9 so no backports are needed. That's very quick; thanks Bill!
[Bug bootstrap/60743] New: build/genautomata uses 700 MB memory for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60743 Bug ID: 60743 Summary: build/genautomata uses 700 MB memory for ARM Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de build/genautomata ../../gcc-4.9-trunk/gcc/config/arm/arm.md \ insn-conditions.md > tmp-automata.c => uses way too much memory/takes too long to complete. this was observed, when building a cross compiler for arm-linux-gnueabi on a i686-pc-linux-gnu system. This build-step used significantly less memory in the past.
[Bug c++/60702] thread_local initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60702 arturomdn at gmail dot com changed: What|Removed |Added CC||arturomdn at gmail dot com --- Comment #4 from arturomdn at gmail dot com --- Created attachment 32528 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32528&action=edit Smaller testcase that reproduces the problem clang had the same problem, this smaller test was submitted to the clang team and they identified it as a duplicate of a recently fixed bug: http://llvm.org/bugs/show_bug.cgi?id=19254 Which was fixed as follows http://llvm.org/viewvc/llvm-project?view=revision&revision=204869 With the following comment: PR19254: If a thread_local data member of a class is accessed via member access syntax, don't forget to run its initializer.
[Bug tree-optimization/59967] [4.8/4.9 Regression] Performance regression from 4.7.x to 4.8.x (loop not unrolled)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59967
--- Comment #2 from Jan Hubicka ---
> 193246hubicka /* If there is call on a hot path through the loop,
> then
> 193246hubickathere is most probably not much to optimize. */
> 193246hubicka else if (size.num_non_pure_calls_on_hot_path)
> 138522rguenth {
> 138522rguenth if (dump_file && (dump_flags & TDF_DETAILS))
> 193246hubicka fprintf (dump_file, "Not unrolling loop %d: "
> 193246hubicka"contains call and code would grow.\n",
> 138522rguenthloop->num);
> 138522rguenth return false;
> 138522rguenth }
>
> so we conclude
>
> size: 59-8, last_iteration: 52-5
> Loop size: 59
> Estimated size after unrolling: 269
> Not unrolling loop 2: contains call and code would grow.
>
> so it was disabled on purpose. Not sure if it's worth special-casing
> self-recursive calls the same as pure/const ones.
Not by the logic above, because self recursion is not really better understood
by optimizers than normal function calls. I am surprised the unroling makes
10-15% difference in this case then. Is there something that makes the unrolled
loop to optimize better?
Honza
[Bug libfortran/60706] FAIL: gfortran.dg/size_kind_2.f90 -O scan-tree-dump original "var2 = 42949673 00;"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60706 --- Comment #3 from dave.anglin at bell dot net --- On 31-Mar-14, at 4:53 AM, rguenth at gcc dot gnu.org wrote: > Like this. If that works for you it's pre-approved. Only > implements the > special-case (the gmp path would probably have a lot of testsuite > fallout?). > I don't have a suitable target to test this on where the path isn't > optimized > away. Fails on hppa64-hp-hpux11.11: In file included from ../../gcc/gcc/tree-pretty-print.h:25:0, from ../../gcc/gcc/tree-pretty-print.c:28: ../../gcc/gcc/tree-pretty-print.c: In function 'void pp_double_int(pretty_printe r*, double_int, bool)': ../../gcc/gcc/hwint.h:16:52: error: left shift count >= width of type [-Werror] #define HOST_BITS_PER_LONG (CHAR_BIT * SIZEOF_LONG) ^ ../../gcc/gcc/pretty-print.h:257:54: note: in definition of macro 'pp_scalar' sprintf (pp_buffer (PP)->digit_buffer, FORMAT, SCALAR); \ ^ ../../gcc/gcc/hwint.h:60:35: note: in expansion of macro 'HOST_BITS_PER_LONG' # define HOST_BITS_PER_WIDE_INT HOST_BITS_PER_LONG ^ ../../gcc/gcc/tree-pretty-print.c:3472:43: note: in expansion of macro 'HOST_BIT S_PER_WIDE_INT' (((unsigned HOST_WIDEST_INT) d.high << HOST_BITS_PER_WIDE_INT) ^ -- John David Anglindave.ang...@bell.net
[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657 --- Comment #8 from Jeffrey A. Law --- Patch is spinning which introduced new predicates which only allow suitable constants.
[Bug ipa/60659] [4.9 Regression] ICE in get_polymorphic_call_info, at ipa-devirt.c:1292
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60659 --- Comment #6 from Jan Hubicka --- Author: hubicka Date: Thu Apr 3 03:55:59 2014 New Revision: 209048 URL: http://gcc.gnu.org/viewcvs?rev=209048&root=gcc&view=rev Log: PR ipa/60659 * ipa-devirt.c (get_polymorphic_call_info): Do not ICE on type inconsistent code and instead mark the context inconsistent. (possible_polymorphic_call_targets): For inconsistent contexts return empty complete list. * testsuite/g++.dg/torture/pr60659.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr60659.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-devirt.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/60659] [4.9 Regression] ICE in get_polymorphic_call_info, at ipa-devirt.c:1292
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60659 Markus Trippelsdorf changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Markus Trippelsdorf --- Fixed.
[Bug tree-optimization/59967] [4.8/4.9 Regression] Performance regression from 4.7.x to 4.8.x (loop not unrolled)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59967 --- Comment #3 from Christoph Breitkopf --- It's this conditional in the inner loop. The expression becomes constant only if both loops are unrolled (i and j are the loop counters): if (1<
[Bug bootstrap/60743] build/genautomata uses 700 MB memory for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60743 --- Comment #1 from Bernd Edlinger --- current snapshot gcc-4.9-20140330, trunk revision 208948 uses 773 MB peak memory. last week's snapshot gcc-4.9-20140323, trunk revision 208775 used only 417 MB peak memory, which did not cause problems.
