[Bug jit/69490] jit testsuite failures (segmentation fault) on x86_64-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69490 --- Comment #3 from Rainer Emrich --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am 26.01.2016 um 16:08 schrieb Rainer Emrich: > Am 26.01.2016 um 15:50 schrieb dmalcolm at gcc dot gnu.org: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69490 > >> --- Comment #1 from David Malcolm >> --- Thanks for reporting this. > >> Which exact version are you testing with? This looks a lot like >> PR 68446, which was fixed in r232567. > > Ok, I'm a little bit behind, that's rev. 232504. I will retest > with current trunk! I confirm, revision 232832 doesn't have the issue. I mark this as duplicate of pr68446. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWqHx/AAoJEB3HOsWs+KJbmqYH/3fNkJQuBeALQtmMNXKkM8EM 5FAOgykAFDQQhmodoXt2kE+MdzlOdWefoKTySEsxy+qfHK3kXpxgmw8RN3Ir19++ KMXGZAla6836UU7UEZYxwd0Xt7pxukQ7HqGxOBzxrivh6ntT6BwLV2qZRR3emkmm PM+l17UlgJfB9x2LfTxq8C7nzAnoBm8vV3KHdpNeiWS7kwm6xB63M2MOlfK/PW/q 4SlzzPjrUNKwNGbp4bkVkVhz13XD13lSQvYNnvb20vadWCu89Q5Zko5cwmhdwhFB ZYYs/uyL58cW7omrRCo6eEH5/leX9xvwcUJ6ar2f19UgTcd5AgLH0gvq5U9ZWOw= =qbY3 -END PGP SIGNATURE-
[Bug jit/69490] jit testsuite failures (segmentation fault) on x86_64-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69490 Rainer Emrich changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Rainer Emrich --- Marked as duplicate of PR68446, which is solved in r232567. *** This bug has been marked as a duplicate of bug 68446 ***
[Bug jit/68446] [6 Regression] jit testsuite failures seen inside dwarf2out.c:gen_producer_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68446 Rainer Emrich changed: What|Removed |Added CC||rai...@emrich-ebersheim.de --- Comment #9 from Rainer Emrich --- *** Bug 69490 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/69466] [6 Regression] ICE: Invalid PHI argument after vectorization (on -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69466 --- Comment #5 from Alexandre Oliva --- Created attachment 37486 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37486&action=edit Patch I'm testing to fix the problem The problem occurs because we call set_current_def for phi nodes after duplicating some blocks, but it isn't always the case that the blocks passed to slpeel_duplicate_current_defs_from_edges were copied from one another. In the given testcase, the exit blocks passed to this function don't seem to be related at all, so taking information from corresponding phi nodes to call set_current_def is most certainly incorrect. Indeed, it's calling set_current_def for a virtual operand from a "corresponding" non-virtual operand that causes slpeel_duplicate_current_defs_from_edges's use of get_current_def to set up an incorrect, non-virtual value for the virtual-operand phi node. With this patch, we refrain from setting current defs when blocks don't have analogous phi nodes, and this is enough to address the problem. It would be nice, however, if someone more familiar with the loop vectorizer would check whether our calling this function with mismatched blocks indicates another latent problem, or whether we could check for the mismatch and bypass the call more efficiently at the caller. For this testcase, the mismatching call is the single_exit (scalar_loop) one in slpeel_tree_duplicate_loop_to_edge_cfg.
[Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654 --- Comment #22 from rguenther at suse dot de --- On Tue, 26 Jan 2016, afomin.mailbox at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654 > > --- Comment #21 from Alexander Fomin --- > (In reply to Richard Biener from comment #18) > > Heh. What about testcases? > We don't have a reproducer yet, but I can provide any RTL dumps immediately > (of > course). Can you simply attach preprocessed source of the relevant file?
[Bug tree-optimization/69336] Constant value not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69336 --- Comment #11 from Richard Biener --- Should be fixed with 2016-01-25 Richard Biener PR testsuite/69380 * g++.dg/tree-ssa/pr69336.C: Restrict to x86_64 and i?86.
[Bug rtl-optimization/69482] Writing through pointers to volatile not always preserved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69482
--- Comment #5 from rguenther at suse dot de ---
On Wed, 27 Jan 2016, wipedout at yandex dot ru wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69482
>
> --- Comment #4 from wipedout at yandex dot ru ---
> Okay, suppose we have the following scenario. There's a third party library
> with an encryption function like this:
>
> void encrypt( void* data, void* key );
>
> That function is compiled into as a static library and we cannot recompile it.
> We know that the function copies the key onto the stack and fails to overwrite
> it.
>
> So we want to overwrite the stack after that function. Here's what we
> could do:
>
>
> void overwrite()
> {
> char array[SIZE];
> memset_s( array, SIZE );
> }
>
> void usefulFunction()
> {
> encrypt( something, key );
> overwrite();
> }
>
> This would work the following way: first, `encrypt()` runs and leaves data on
> the stack. Then `overwrite()` runs, allocates an array which very likely
> overlaps with the area where `encrypt()` left the data and overwrites that
> array.
>
> This "array is not used" optimization heuristic equally applies to the array
> in
> overwrite() and a later version of gcc may decide that no matter how the array
> is allocated it's not used and therefore no need to overwrite it.
>
> Yes, I know that the trick relies on undefined behavior in the first place.
well, it doesn't rely on undefined behavior. It relies on the compiler
not performing valid optimizations on it ;)
All it takes to make it work is declare 'array' itself volatile and
prevent the compiler from inlining 'overwrite' (otherwise the
stack-overwriting wouldn't work).
#include
#include
static void __attribute__((noinline))
overwrite (size_t n)
{
volatile char array[n];
unsigned i;
for (i = 0; i < n; ++i)
array[i] = 0;
}
extern void foo ();
void test()
{
foo ();
overwrite (1024);
}
works for me. It may not be very fast (volatile char stores) though.
[Bug tree-optimization/69466] [6 Regression] ICE: Invalid PHI argument after vectorization (on -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69466 --- Comment #6 from Richard Biener --- I'll have a look as well.
[Bug sanitizer/69508] Undefined Behavior Sanitizer __ubsan_handle_load_invalid_value reports invalid load with wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69508 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-01-27 Ever confirmed|0 |1
[Bug bootstrap/69506] [6 Regression] check-in 232454 seems to cause problems with cygwin builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69506 Richard Biener changed: What|Removed |Added Priority|P3 |P1 CC||nickc at gcc dot gnu.org Target Milestone|--- |6.0 Summary|check-in 232454 seems to|[6 Regression] check-in |cause problems with cygwin |232454 seems to cause |builds |problems with cygwin builds
[Bug lto/69408] LD crashes with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69408 --- Comment #14 from night_ghost at ykoctpa dot ru --- Created attachment 37487 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37487&action=edit script to build GCC-avr and other tools use this script to build GCC
[Bug sanitizer/69508] Undefined Behavior Sanitizer __ubsan_handle_load_invalid_value reports invalid load with wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69508 --- Comment #2 from Jakub Jelinek --- Note that passing the _Bool to varargs function might very well zero extend it (i.e. mask with 1). As kernel is built with -fno-strict-aliasing, I bet trying to print *(char *)&tid_agg_rx->removed instead might give you more accurate answers.
[Bug c/69504] XMM register variable ICE with vector extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69504
Richard Biener changed:
What|Removed |Added
Keywords||accepts-invalid,
||ice-on-invalid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-01-27
Component|tree-optimization |c
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
This is because you use the vector extension of indexing a vector with [] but
with variable indexes the FE represents this in a way that takes the address
of the vector variable which isn't possible in this case - it's a register.
printf ((const char * restrict) "%d\n", (int) *((unsigned char *) &u8x16 +
(sizetype) i));
so I fear the solution here is to reject the code with an error or force
the frontend to special-case register vars by going through a temporary,
that is, use ({ u8x16_t tem = u8x16; tem[i]; })
Frontend issue. If you do sth like
void foo (u8x16_t *);
int main(void) {
register u8x16_t u8x16 asm ("xmm0");
foo (&u8x16);
}
the FEs will reject it with
error: address of register variable ‘u8x16’ requested
so I think rejecting this code is a reasonable thing. Using intrinsics if you
use processor specific registers is a reasonable thing to expect from you here.
[Bug c++/69494] Optimizer eliminates assignment to volatile subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69494 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-27 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Similar to another bug 'dev' is allocated to a register during RTL expansion and thus the volatility is lost. IIRC the language standards do not have a concept of "volatile subobjects" so the testcase is questionable.
[Bug c/69504] XMM register variable ICE with vector extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69504
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #2 from Marek Polacek ---
gcc34 / 44 / 45:
v.c: In function `main':
v.c:8: error: subscripted value is neither array nor pointer
gcc4.6+ ICE.
g++ 4.6 and 4.7 give
v.c: In function ‘int main()’:
v.c:8:50: error: invalid types ‘u8x16_t {aka __vector(16) unsigned char}[int]’
for array subscript
And g++ 4.8 and newer ICE.
So looks like a regression and it seems we want to do what the FEs were
aleready doing in the past.
[Bug lto/69491] [6 Regression] [CHKP] gcc.dg/lto/chkp-wrap-asm-name ICEs with -fno-use-linker-plugin (verify_cgraph_node failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69491 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug c/69504] XMM register variable ICE with vector extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69504 --- Comment #3 from Richard Biener --- I think at some point the FEs created array-refs here. I think I suggested that elsewhere during last stage1 but nobody implemented that ... (now it's already again quite late). Thus for vector[i] create ARRAY_REF (vector), i> avoiding the need to take the address of vector. Thus instead of bool non_lvalue = convert_vector_to_pointer_for_subscript (loc, &array, index); convert the vector to an array type via a VIEW_CONVERT. That should work for both r and lvalues. Of course it may trigger interesting new paths should this survive until RTL expansion ;) The other option is in convert_vector_to_pointer_for_subscript, force the !lvalue_p path for DECL_HARD_REGISTER *vecp.
[Bug tree-optimization/69196] [5/6 Regression] code size regression with jump threading at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196 --- Comment #12 from Sebastian Huber --- New numbers for SPARC and PowerPC (rtems4.12-gcc 6.0.0 20160127): sparc-rtems4.11-gcc -c -O2 -o vprintk.4.11.o vprintk.i sparc-rtems4.12-gcc -c -O2 -o vprintk.4.12.o vprintk.i size vprintk.4.11.o textdata bss dec hex filename 688 0 0 688 2b0 vprintk.4.11.o size vprintk.4.12.o textdata bss dec hex filename 1252 0 01252 4e4 vprintk.4.12.o powerpc-rtems4.11-gcc -c -O2 -o vprintk.4.11.o vprintk.i powerpc-rtems4.12-gcc -c -O2 -o vprintk.4.12.o vprintk.i size vprintk.4.11.o textdata bss dec hex filename 797 0 0 797 31d vprintk.4.11.o size vprintk.4.12.o textdata bss dec hex filename 1005 0 01005 3ed vprintk.4.12.o
[Bug c/69504] XMM register variable ICE with vector extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69504 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |7.0 --- Comment #4 from Marek Polacek --- Ok, I'll try that out, but as you say, in the next stage1.
[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655 --- Comment #33 from Nick Clifton --- The patch did receive approval in the end: https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02074.html phew! As for 68601 - I guess that we can leave it as RESOLVED for now, and see if the problem resurfaces at a later date. (Fingers crossed - this will not happen).
[Bug rtl-optimization/69447] [5/6 Regression] wrong code with -O2 -fno-schedule-insns and mixed 8/16/32/64bit arithmetics @ armv7a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69447 --- Comment #10 from ktkachov at gcc dot gnu.org --- (In reply to Richard Henderson from comment #9) > Created attachment 37484 [details] > proposed patch > > Fixes the test case, in that it prevents the remat. > > Starting overnight bootstraps for armv7hf, i686, and x86_64... This patch also seems to fix the wrong code in PR 69124
[Bug go/69511] New: G.gcstack_size uses uintptr instead of size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69511 Bug ID: 69511 Summary: G.gcstack_size uses uintptr instead of size_t Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: vogt at linux dot vnet.ibm.com CC: cmang at google dot com, krebbel at gcc dot gnu.org Target Milestone: --- Target: s390 s390x Created attachment 37488 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37488&action=edit Proposed fix. The field gcstack_size in the G structure in libgo/runtime/runtime.h has "uintptr" as its type, but &G.gcstack_size is passed to a function expecting "size_t *". On S/390 this results in a warning and hence a bootstrap failure with the split stack patches we're working on: error: passing argument 3 of ‘__splitstack_find’ from incompatible pointer type [-Werror=incompatible-pointer-types] g->gcstack = __splitstack_find(nil, nil, &g->gcstack_size, I believe it's safe to change the type to size_t which it should have been in the first place. But theoretically it's possible that size_t and unitptr are of different bit size. What do you think about the attached patch?
[Bug tree-optimization/69336] Constant value not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69336 --- Comment #12 from Dominik Vogt --- The test works now on s390x. Thanks.
[Bug rtl-optimization/69447] [5/6 Regression] wrong code with -O2 -fno-schedule-insns and mixed 8/16/32/64bit arithmetics @ armv7a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69447 --- Comment #11 from Jakub Jelinek --- Without knowing the lra-remat code at all, I just wonder if subreg_regs needs to be one per the whole function, rather than say per extended basic block or basic block, with the patch any uses in multi-reg subregs anywhere in the function will affect remat of all other spots where it is used.
[Bug lto/69408] LD crashes with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69408 --- Comment #15 from night_ghost at ykoctpa dot ru --- steps to repeat: Arduino recent version should be installed GCC created by the above script should be in PATH and in Arduino's /usr/share/arduino/hardware/tools/avr un-tar testcase, cd to it. in mk/board_avr.mk one should set path to liblto_plugin.so then cd ArduCopter make after lots of compilation you'll get %% ArduCopter.elf collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped compilation terminated. make: *** [/tmp/ArduCopter.build/ArduCopter.elf] Ошибка 1 make: *** Удаляется файл `/tmp/ArduCopter.build/ArduCopter.elf' PS. I can't upload testcase because of size limit 1mb. Is there another way to send it?
[Bug c++/69462] FLT_EVAL_METHOD and DECIMAL_DIG missing in float.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69462 --- Comment #3 from Dominik Vogt --- Is this change fit to be posted on gcc-patches? (I have a patch for that anyway and can post it for you if you like.)
[Bug tree-optimization/69466] [6 Regression] ICE: Invalid PHI argument after vectorization (on -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69466 --- Comment #7 from Richard Biener --- I think the fix is wrong, slpeel_duplicate_current_defs_from_edges assumes from->dest and to->dest are the same (or the same kind of) block. Your patch merely papers over the issue that one of the exits leads to an unexpected forwarder block. Note that the whole slpeel infrastructure is quite fragile and should be ditched - certainly it shouldn't "abuse" set/get_current_def. But well... It seems this bug has been introduced with adding versioning to if-conversion and using the non-if-converted body for scalar iterations. And the "bug" is likely introduced by running a CFG cleanup requring an exit edge split in vect_analyze_loop_form_1. Removing that edge splitting "fixes" this testcase. I'm going to see why we needed that there.
[Bug target/69512] New: ICE when using avx with i586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69512
Bug ID: 69512
Summary: ICE when using avx with i586
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: chrbr at gcc dot gnu.org
Target Milestone: ---
a reduced case from gcc.target/i386/avx-vcmppd-1.c that fails instead of being
unsupported for testing with -march=i586
attached test compiled with
runs withs -O2 -mavx -march=i586 -m32
ICES with unrecognizable insn
extern double s1[];
extern double s2[];
extern long long e[];
void
avx_test ()
{
int i;
for (i = 0; i < 2; i++)
e[i] = !__builtin_isunordered(s1[i], s2[i]) && s1[i] != s2[i] ? -1 : 0;
}
I suppose that avx is not available for this combination ?, so maybe just
missing an arch incompatible option check ?
[Bug target/69512] ICE when using avx with i586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69512 chrbr at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic, ice-checking Target||i596 Priority|P3 |P1 Known to fail||6.0
[Bug sanitizer/69508] Undefined Behavior Sanitizer __ubsan_handle_load_invalid_value reports invalid load with wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69508 Chris Bainbridge changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Chris Bainbridge --- Thanks for the hints. Jakub was right - after casting with "*(char *)&" the value is indeed 2. Marking this bug report as invalid.
[Bug target/69512] ICE when using avx with i586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69512 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-27 Ever confirmed|0 |1 --- Comment #1 from Uroš Bizjak --- STV pass is generating: (insn 50 19 51 2 (set (reg:SI 2 cx [113]) (zero_extend:SI (reg:QI 2 cx [112]))) pr69512.c:11 -1 (nil)) which is not supported on TARGET_ZERO_EXTEND_WITH_AND targets
[Bug testsuite/69488] tests in gnat/sso give a lot of spurious failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69488 --- Comment #2 from Rainer Emrich --- Created attachment 37489 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37489&action=edit proposed patch * gnat.dg/sso/*.adb: Robustify dg-output directives.
[Bug testsuite/69488] tests in gnat/sso give a lot of spurious failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69488 --- Comment #3 from Rainer Emrich --- I'm testing the proposed patch on x86_64-w64-mingw32 and x86_64-unknown-linux-gnu.
[Bug fortran/69485] oddity with -Wtabs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69485 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-27 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (6.0) for fixed-form. After converting the include file to free-form I get pr69485.inc:1:1: character*76 dsf_file,ntup_file,stat_file 1 Warning: Nonconforming tab character at (1) [-Wtabs] ... pr69485.inc:23:1: common/options/ndiv_sam,read_scaler,proj_bends, & 1 Warning: Nonconforming tab character at (1) [-Wtabs]
[Bug c++/65656] __builtin_constant_p should always be constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65656
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
I don't think this change works properly though.
Consider say -O2 -std=c++11 testcase from tree-ssa-ccp.c:
template class generic_wide_int;
template struct fixed_wide_int_storage;
typedef generic_wide_int >
widest_int;
namespace wi {
enum precision_type { FLEXIBLE_PRECISION, VAR_PRECISION, CONST_PRECISION };
template struct int_traits;
template unsigned int get_precision (const T &);
template ::precision_type, enum precision_type P2 = int_traits ::precision_type>
struct binary_traits;
template struct unary_traits : public binary_traits {};
template struct binary_traits {
typedef generic_wide_int ::precision> > result_type;
};
template bool geu_p (const T1 &, const T2);
template typename wi::unary_traits
::result_type lrshift (const T1 &, const T2 &);
struct storage_ref {
storage_ref (const long *, unsigned int, unsigned int);
const long *val;
unsigned int len;
unsigned int precision;
unsigned int get_len () const;
unsigned int get_precision () const;
const long *get_val () const;
};
inline::wi::storage_ref::storage_ref (const long *val_in, unsigned int
len_in, unsigned int precision_in) : val (val_in), len (len_in), precision
(precision_in) {}
inline unsigned int wi::storage_ref::get_len () const { return len; }
inline unsigned int wi::storage_ref::get_precision () const { return
precision; }
inline const long * wi::storage_ref::get_val () const { return val; }
}
template class generic_wide_int : public storage {
public:
generic_wide_int ();
template generic_wide_int (const T &);
unsigned long to_uhwi () const;
};
template template inline generic_wide_int
::generic_wide_int (const T &x) : storage (x) {}
namespace wi {
template struct int_traits > :
public wi::int_traits {
static unsigned int get_precision (const generic_wide_int &);
static wi::storage_ref decompose (long *, unsigned int, const
generic_wide_int &);
};
template inline wi::storage_ref wi::int_traits
>::decompose (long *, unsigned int precision, const
generic_wide_int &x) {
return wi::storage_ref (x.get_val (), x.get_len (), precision);
}
}
template struct wide_int_ref_storage : public wi::storage_ref {
long scratch[2];
template wide_int_ref_storage (const T &);
};
template template inline wide_int_ref_storage
::wide_int_ref_storage (const T &x) : storage_ref (wi::int_traits
::decompose (scratch, wi::get_precision (x), x)) {}
template struct fixed_wide_int_storage {
long val[(N + 64 + 1) / 64];
unsigned int len;
unsigned int get_precision () const;
const long *get_val () const;
unsigned int get_len () const;
};
template inline unsigned int fixed_wide_int_storage ::get_precision
() const { return N; }
template inline const long * fixed_wide_int_storage ::get_val ()
const { return val; }
template inline unsigned int fixed_wide_int_storage ::get_len ()
const { return len; }
template inline unsigned int wi::int_traits
>::get_precision (const generic_wide_int
& x) { return x.get_precision (); }
namespace wi {
template struct int_traits > {
static const enum precision_type precision_type = CONST_PRECISION;
static const bool is_sign_extended = true;
static const unsigned int precision = N;
};
}
template inline unsigned int wi::get_precision (const T &x) {
return wi::int_traits ::get_precision (x); }
void bar ();
template inline typename wi::unary_traits
::result_type wi::lrshift (const T1 &x, const T2 &y) {
generic_wide_int ::is_sign_extended> > xi (x);
generic_wide_int ::is_sign_extended> > yi (y);
if (geu_p (yi, xi.precision)) {
unsigned int shift = yi.to_uhwi ();
if ((__builtin_constant_p (xi.precision > 64) && (xi.precision > 64)) ?
(shift < 64 && xi.len == 1 && xi.val[0] >= 0) : xi.precision <= 64) {
bar ();
}
}
}
void foo (widest_int *a, widest_int &b, widest_int &c) {
*a = wi::lrshift (b, c);
}
It doesn't seem that anything is used in constexpr context, and when compiled
with g++ 5.x we end up after all inlining with conditional call
if (shift < 64 && xi.len == 1 && xi.val[0] >= 0) bar ();
But with trunk, __builtin_constant_p (xi.precision > 64) seems to be folded to
0 prematurely and thus we end up with if (xi.precision <= 64) that is soon
folded into if (0) because after early inlining xi.precision is known to be
192.
I see fold_builtin_constant_p being called first during cp_fold, which ensures
that it is not optimized into 0, and then from fold_non_dependent_expr (when
tsubst* instantiates the condition), which uses constexpr.c stuff and folds it
to 0, despite not being in constexpr function nor e.g. resolved in constexpr
context.
[Bug c++/69462] FLT_EVAL_METHOD and DECIMAL_DIG missing in float.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69462 --- Comment #4 from Jonathan Wakely --- Yes, but I can't approve changes to that part of GCC and it should probably wait for stage 1.
[Bug tree-optimization/69466] [6 Regression] ICE: Invalid PHI argument after vectorization (on -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69466
--- Comment #8 from Richard Biener ---
Ok, it doesn't fix it, it somehow just makes -fno-vect-cost-model necessary.
We still split the edge, but later in vect_loop_versioning then, so the reason
for the bug is still the same - we're looking at forwarder edge PHIs.
OTOH the values there should be ok to use. We're ICEing with the 2nd peeling
now.
So the reason for the mismatch is that when split-edge comes along splitting
:
...
:
# prephitmp_112 = PHI
# e_lsm.38_108 = PHI <1(14)>
# e_lsm.37_100 = PHI
then slpeel_update_phi_nodes_for_guard2 fails to "copy" the PHI with constant
argument (which wasn't needed in the first place):
for (gsi = gsi_start_phis (update_bb); !gsi_end_p (gsi); gsi_next (&gsi))
{
tree new_res;
update_phi = gsi.phi ();
orig_phi = update_phi;
orig_def = PHI_ARG_DEF_FROM_EDGE (orig_phi, e);
/* This loop-closed-phi actually doesn't represent a use
out of the loop - the phi arg is a constant. */
if (TREE_CODE (orig_def) != SSA_NAME)
continue;
this later confuses the current-def-setting code. This means the circumstances
are somewhat "controlled" and thus the following fix "works". Of course it
makes the whole thing even more awkward ;)
Index: tree-vect-loop-manip.c
===
--- tree-vect-loop-manip.c (revision 232867)
+++ tree-vect-loop-manip.c (working copy)
@@ -727,17 +727,26 @@ slpeel_duplicate_current_defs_from_edges
for (gsi_from = gsi_start_phis (from->dest),
gsi_to = gsi_start_phis (to->dest);
- !gsi_end_p (gsi_from) && !gsi_end_p (gsi_to);
- gsi_next (&gsi_from), gsi_next (&gsi_to))
+ !gsi_end_p (gsi_from) && !gsi_end_p (gsi_to);)
{
gimple *from_phi = gsi_stmt (gsi_from);
gimple *to_phi = gsi_stmt (gsi_to);
tree from_arg = PHI_ARG_DEF_FROM_EDGE (from_phi, from);
+ if (TREE_CODE (from_arg) != SSA_NAME)
+ {
+ gsi_next (&gsi_from);
+ continue;
+ }
tree to_arg = PHI_ARG_DEF_FROM_EDGE (to_phi, to);
- if (TREE_CODE (from_arg) == SSA_NAME
- && TREE_CODE (to_arg) == SSA_NAME
- && get_current_def (to_arg) == NULL_TREE)
+ if (TREE_CODE (to_arg) != SSA_NAME)
+ {
+ gsi_next (&gsi_to);
+ continue;
+ }
+ if (get_current_def (to_arg) == NULL_TREE)
set_current_def (to_arg, get_current_def (from_arg));
+ gsi_next (&gsi_from);
+ gsi_next (&gsi_to);
}
}
[Bug target/69512] ICE when using avx with i586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69512 Uroš Bizjak changed: What|Removed |Added Keywords|diagnostic, ice-checking| Target|i596|i586 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Target Milestone|--- |6.0 --- Comment #2 from Uroš Bizjak --- I have a patch.
[Bug fortran/69498] ICE on disjunct cases with displaced or incomplete embedded statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69498 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-27 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (6.0) for the first test in comment 0. Submodules are not supported before gcc 6.0 and the other tests give errors without ICE before 6.0.
[Bug testsuite/69488] tests in gnat/sso give a lot of spurious failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69488 --- Comment #4 from Eric Botcazou --- > I'm testing the proposed patch on x86_64-w64-mingw32 and > x86_64-unknown-linux-gnu. Thanks. The patch is OK for mainline if the above testing is successful.
[Bug target/69512] [6 Regression] ICE when using avx with i586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69512 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|ICE when using avx with |[6 Regression] ICE when |i586|using avx with i586 --- Comment #3 from Jakub Jelinek --- Surprisingly, the ICE started with r228668, perhaps it has been latent before.
[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #26 from Ilya Enkovich ---
(In reply to H.J. Lu from comment #25)
> Please add -mpreferred-stack-boundary=2 to your tests. Otherwise,
> you just remove a nop.
Here is a test which crashes LRA with the path you proposed. Crash happens
because LRA requests a stack slot aligned by 8 and stack is aligned by 4. So
Jakub's patch looks the safest option for now, but probably use 64 requirement
instead of 128.
>cat test.i
long long a, b;
fn1() {
long long c = a;
a = b ^ a;
fn2();
a = c;
}
>gcc test.i -O2 -m32 -mpreferred-stack-boundary=2
test.i: In function 'fn1':
test.i:5:3: warning: implicit declaration of function 'fn2'
[-Wimplicit-function-declaration]
fn2();
^~~
test.i:7:1: internal compiler error: in assign_stack_local_1, at function.c:409
[Bug c++/67364] [5/6 Regression] "accessing uninitialized member" error in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67364 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Started with commit 7321fbd5edb3905d2fcf75c8f5c6e0b9734d0145 Author: jason Date: Tue Nov 18 17:07:24 2014 + PR c++/63934 * constexpr.c (cxx_eval_call_expression): Check DECL_CONSTRUCTOR_P rather than VOID_TYPE_P. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@217729 138bc75d-0d04-0410-961f-82ee72b054a4 I'll look into this, but no promises.
[Bug bootstrap/69513] New: LTO bootstrap fails with bootstrap-profiled during linking gnat1 in stagefeedback
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69513 Bug ID: 69513 Summary: LTO bootstrap fails with bootstrap-profiled during linking gnat1 in stagefeedback Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: rai...@emrich-ebersheim.de Target Milestone: --- trunk revison 232867 binutils-2.26 /opt/devel/SCRATCH/tmp.kZaQUWUv9N/gcc-6.0.0-test/gcc-6.0.0-test/./prev-gcc/xg++ -B/opt/devel/SCRATCH/tmp.kZaQUWUv9N/gcc-6.0.0-test/gcc-6.0.0-test/./prev-gcc/ -B/opt/devel/gnu/gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_13.2/gcc-6.0.0-test/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/opt/devel/SCRATCH/tmp.kZaQUWUv9N/gcc-6.0.0-test/gcc-6.0.0-test/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/opt/devel/SCRATCH/tmp.kZaQUWUv9N/gcc-6.0.0-test/gcc-6.0.0-test/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/opt/devel/SCRATCH/tmp.kZaQUWUv9N/gcc-6.0.0-test/gcc-6.0.0-test/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/opt/devel/SCRATCH/tmp.kZaQUWUv9N/gcc-6.0.0-test/gcc-6.0.0-test/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/opt/devel/gnu/src/gcc/gcc-6.0.0-test/libstdc++-v3/libsupc++ -L/opt/devel/SCRATCH/tmp.kZaQUWUv9N/gcc-6.0.0-test/gcc-6.0.0-test/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/opt/devel/SCRATCH/tmp.kZaQUWUv9N/gcc-6.0.0-test/gcc-6.0.0-test/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -no-pie -g -O2 -flto=jobserver -frandom-seed=1 -fprofile-use -DIN_GCC -fPIC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o gnat1 ada/adadecode.o ada/adaint.o ada/argv.o ada/cio.o ada/cstreams.o ada/env.o ada/init.o ada/initialize.o ada/raise.o ada/seh_init.o ada/targext.o ada/cuintp.o ada/decl.o ada/rtfinal.o ada/rtinit.o ada/misc.o ada/utils.o ada/utils2.o ada/trans.o ada/targtyps.o ada/a-charac.o ada/a-chlat1.o ada/a-elchha.o ada/a-except.o ada/a-ioexce.o ada/ada.o ada/spark_xrefs.o ada/ali.o ada/alloc.o ada/aspects.o ada/atree.o ada/butil.o ada/casing.o ada/checks.o ada/comperr.o ada/contracts.o ada/csets.o ada/cstand.o ada/debug.o ada/debug_a.o ada/einfo.o ada/elists.o ada/err_vars.o ada/errout.o ada/erroutc.o ada/eval_fat.o ada/exp_aggr.o ada/exp_spark.o ada/exp_atag.o ada/exp_attr.o ada/exp_cg.o ada/exp_ch11.o ada/exp_ch12.o ada/exp_ch13.o ada/exp_ch2.o ada/exp_ch3.o ada/exp_ch4.o ada/exp_ch5.o ada/exp_ch6.o ada/exp_ch7.o ada/exp_ch8.o ada/exp_ch9.o ada/exp_code.o ada/exp_dbug.o ada/exp_disp.o ada/exp_dist.o ada/exp_fixd.o ada/exp_imgv.o ada/exp_intr.o ada/exp_pakd.o ada/exp_prag.o ada/exp_sel.o ada/exp_smem.o ada/exp_strm.o ada/exp_tss.o ada/exp_unst.o ada/exp_util.o ada/expander.o ada/fmap.o ada/fname-uf.o ada/fname.o ada/freeze.o ada/frontend.o ada/g-byorma.o ada/g-hesora.o ada/g-htable.o ada/g-spchge.o ada/g-speche.o ada/g-u3spch.o ada/get_spark_xrefs.o ada/get_targ.o ada/ghost.o ada/gnat.o ada/gnatvsn.o ada/hostparm.o ada/impunit.o ada/inline.o ada/interfac.o ada/itypes.o ada/krunch.o ada/layout.o ada/lib-load.o ada/lib-util.o ada/lib-writ.o ada/lib-xref.o ada/lib.o ada/live.o ada/namet-sp.o ada/namet.o ada/nlists.o ada/nmake.o ada/opt.o ada/osint-c.o ada/osint.o ada/output.o ada/par.o ada/par_sco.o ada/prep.o ada/prepcomp.o ada/put_spark_xrefs.o ada/put_scos.o ada/repinfo.o ada/restrict.o ada/rident.o ada/rtsfind.o ada/s-addope.o ada/s-assert.o ada/s-bitops.o ada/s-carun8.o ada/s-casuti.o ada/s-conca2.o ada/s-conca3.o ada/s-conca4.o ada/s-conca5.o ada/s-conca6.o ada/s-conca7.o ada/s-conca8.o ada/s-conca9.o ada/s-crc32.o ada/s-crtl.o ada/s-excdeb.o ada/s-except.o ada/s-exctab.o ada/s-htable.o ada/s-imenne.o ada/s-imgenu.o ada/s-mastop.o ada/s-memory.o ada/s-os_lib.o ada/s-parame.o ada/s-purexc.o ada/s-restri.o ada/s-secsta.o ada/s-soflin.o ada/s-sopco3.o ada/s-sopco4.o ada/s-sopco5.o ada/s-stache.o ada/s-stalib.o ada/s-stoele.o ada/s-strcom.o ada/s-strhas.o ada/s-string.o ada/s-strops.o ada/s-traent.o ada/s-unstyp.o ada/s-utf_32.o ada/s-valint.o ada/s-valuns.o ada/s-valuti.o ada/s-wchcnv.o ada/s-wchcon.o ada/s-wchjis.o ada/scans.o ada/scil_ll.o ada/scn.o ada/scng.o ada/scos.o ada/sdefault.o ada/sem.o ada/sem_aggr.o ada/sem_attr.o ada/sem_aux.o ada/sem_case.o ada/sem_cat.o ada/sem_ch10.o ada/sem_ch11.o ada/sem_ch12.o ada/sem_ch13.o ada/sem_ch2.o ada/sem_ch3.o ada/sem_ch4.o ada/sem_ch5.o ada/sem_ch6.o ada/sem_ch7.o ada/sem_ch8.o ada/sem_ch9.o ada/sem_dim.o ada/sem_disp.o ada/sem_dist.o ada/sem_elab.o ada/sem_elim.o ada/sem_eval.o ada/sem_intr.o ada/sem_mech.o ada/sem_prag.o ada/sem_res.o ada/sem_scil.o ada/sem_smem.o ada/sem_type.o ada/sem_util.o ada/sem_warn.o ada/set_targ.o ada/sinfo-cn.o
[Bug tree-optimization/69399] [5/6 Regression] wrong code with -O and int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69399 --- Comment #12 from Jakub Jelinek --- Author: jakub Date: Wed Jan 27 11:40:04 2016 New Revision: 232869 URL: https://gcc.gnu.org/viewcvs?rev=232869&root=gcc&view=rev Log: PR tree-optimization/69399 * wide-int.h (wi::lrshift): For larger precisions, only use fast path if shift is known to be < HOST_BITS_PER_WIDE_INT. * gcc.dg/torture/pr69399.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr69399.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/wide-int.h
[Bug bootstrap/69513] LTO bootstrap fails with bootstrap-profiled during linking gnat1 in stagefeedback
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69513
--- Comment #1 from Richard Biener ---
This means the DIE in question was created too late or figured unreachable.
case dw_val_class_die_ref:
if (AT_ref_external (a))
...
else
{
gcc_assert (AT_ref (a)->die_offset);
dw2_asm_output_data (DWARF_OFFSET_SIZE, AT_ref (a)->die_offset,
"%s", name);
both 'die' and AT_ref (a) would be interesting to look at.
[Bug c++/68782] [6 regression] bad reference member formed with constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68782 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug rtl-optimization/69052] [6 Regression] Performance regression after r229402.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69052 --- Comment #8 from Ilya Enkovich --- (In reply to amker from comment #7) > According to discussion at https://gcc.gnu.org/ml/gcc/2016-01/msg00190.html, > hook is probably not wanted in this case. > Bernd gave another proposal by moving combine before loop transforms is also > interesting, but it can be for GCC6. > So a backend fix would be nice. Unfortunately my patch causes significant regressions in some SPEC benchmarks. Looks like address operands order matters in some other places.
[Bug rtl-optimization/69052] [6 Regression] Performance regression after r229402.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69052 --- Comment #9 from amker at gcc dot gnu.org --- (In reply to Ilya Enkovich from comment #8) > (In reply to amker from comment #7) > > According to discussion at https://gcc.gnu.org/ml/gcc/2016-01/msg00190.html, > > hook is probably not wanted in this case. > > Bernd gave another proposal by moving combine before loop transforms is also > > interesting, but it can be for GCC6. > > So a backend fix would be nice. > > Unfortunately my patch causes significant regressions in some SPEC > benchmarks. Looks like address operands order matters in some other places. I know little about x86, is it because of generation of non-canonical rtl expression after this change? Another question for this case is: Is it because operand ordering that inv_can_prop_to_addr_use failed to verify the result insn as a valid one? If so, is it because of non-canonical rtl expressions? I will check how combine merges these two instructions. Thanks.
[Bug rtl-optimization/69052] [6 Regression] Performance regression after r229402.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69052 --- Comment #10 from Ilya Enkovich --- (In reply to amker from comment #9) > I know little about x86, is it because of generation of non-canonical rtl > expression after this change? > > Another question for this case is: Is it because operand ordering that > inv_can_prop_to_addr_use failed to verify the result insn as a valid one? > If so, is it because of non-canonical rtl expressions? In i386 address expression only the first operand of PLUS may be another PLUS. Thus (r1 + r2) + CONST is a valid address but r1 + (r2 + CONST) is not. Thus when you propagate a register you may need to reorder operands.
[Bug rtl-optimization/68730] [6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68730 --- Comment #14 from Bernd Schmidt --- It does look like an issue with lra-remat...
[Bug rtl-optimization/69052] [6 Regression] Performance regression after r229402.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69052 --- Comment #11 from amker at gcc dot gnu.org --- (In reply to Ilya Enkovich from comment #10) > (In reply to amker from comment #9) > > I know little about x86, is it because of generation of non-canonical rtl > > expression after this change? > > > > Another question for this case is: Is it because operand ordering that > > inv_can_prop_to_addr_use failed to verify the result insn as a valid one? > > If so, is it because of non-canonical rtl expressions? > > In i386 address expression only the first operand of PLUS may be another > PLUS. Thus (r1 + r2) + CONST is a valid address but r1 + (r2 + CONST) is > not. Thus when you propagate a register you may need to reorder operands. I see, I will check what combine does here. Maybe it's just an overlook in inv_can_prop_to_addr_use, which reminds me if other targets like AArch64 are also affected. Thanks.
[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #27 from H.J. Lu ---
(In reply to Ilya Enkovich from comment #26)
> (In reply to H.J. Lu from comment #25)
> > Please add -mpreferred-stack-boundary=2 to your tests. Otherwise,
> > you just remove a nop.
>
> Here is a test which crashes LRA with the path you proposed. Crash happens
> because LRA requests a stack slot aligned by 8 and stack is aligned by 4.
> So Jakub's patch looks the safest option for now, but probably use 64
> requirement instead of 128.
>
> >cat test.i
> long long a, b;
> fn1() {
> long long c = a;
> a = b ^ a;
> fn2();
> a = c;
> }
> >gcc test.i -O2 -m32 -mpreferred-stack-boundary=2
> test.i: In function 'fn1':
> test.i:5:3: warning: implicit declaration of function 'fn2'
> [-Wimplicit-function-declaration]
>fn2();
>^~~
>
> test.i:7:1: internal compiler error: in assign_stack_local_1, at
> function.c:409
The last place to update stack alignment is ix86_update_stack_boundary.
Try
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index a03a515..10a00f8 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3588,16 +3588,6 @@ convert_scalars_to_vector ()
bitmap_obstack_release (NULL);
df_process_deferred_rescans ();
- /* Conversion means we may have 128bit register spills/fills
- which require aligned stack. */
- if (converted_insns)
-{
- if (crtl->stack_alignment_needed < 128)
- crtl->stack_alignment_needed = 128;
- if (crtl->stack_alignment_estimated < 128)
- crtl->stack_alignment_estimated = 128;
-}
-
return 0;
}
@@ -12041,6 +12031,13 @@ ix86_update_stack_boundary (void)
if (crtl->stack_alignment_needed < 128)
crtl->stack_alignment_needed = 128;
}
+
+ /* The STV pass needs 64-bit stack alignment. */
+ if (!TARGET_64BIT
+ && TARGET_STV
+ && TARGET_SSE2 && optimize > 1
+ && crtl->stack_alignment_estimated < 64)
+crtl->stack_alignment_estimated = 64;
}
/* Handle the TARGET_GET_DRAP_RTX hook. Return NULL if no DRAP is
[Bug c++/69494] Optimizer eliminates assignment to volatile subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69494 --- Comment #2 from Lukas --- I was wrong about what part of the standard defines the behavior for volatile access. Paragraph 8 of [intro.execution] specifies that access to volatile objects is observable behavior. Access is defined in [defns.access] as reading or modifying the value of an object. Paragraph one of [intro.object] says that "an object is a region of storage." Paragraph two says that objects can contain other objects and calls the latter subobjects. Paragraph eight of [basic.types] defines 'object type' to contain cv-qualified versions of types that are not function types, references, or void. According to these passages dev.tcc is both an object and a subobject. The standard makes no explicit mention of volatile subobjects because whether or not an object is a subobject does not matter, at least when talking about volatile.
[Bug lto/68881] [6 Regression] UNRESOLVED/FAIL: gcc.dg/lto/attr-weakref-1 -O2 -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68881 --- Comment #13 from Jakub Jelinek --- While GCC can do that, what if weakref is used in the source and the definition is provided by user in inline asm?
[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #28 from Jakub Jelinek ---
(In reply to H.J. Lu from comment #27)
> (In reply to Ilya Enkovich from comment #26)
> > (In reply to H.J. Lu from comment #25)
> > > Please add -mpreferred-stack-boundary=2 to your tests. Otherwise,
> > > you just remove a nop.
> >
> > Here is a test which crashes LRA with the path you proposed. Crash happens
> > because LRA requests a stack slot aligned by 8 and stack is aligned by 4.
> > So Jakub's patch looks the safest option for now, but probably use 64
> > requirement instead of 128.
> >
> > >cat test.i
> > long long a, b;
> > fn1() {
> > long long c = a;
> > a = b ^ a;
> > fn2();
> > a = c;
> > }
> > >gcc test.i -O2 -m32 -mpreferred-stack-boundary=2
> > test.i: In function 'fn1':
> > test.i:5:3: warning: implicit declaration of function 'fn2'
> > [-Wimplicit-function-declaration]
> >fn2();
> >^~~
> >
> > test.i:7:1: internal compiler error: in assign_stack_local_1, at
> > function.c:409
>
> The last place to update stack alignment is ix86_update_stack_boundary.
> Try
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index a03a515..10a00f8 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -3588,16 +3588,6 @@ convert_scalars_to_vector ()
>bitmap_obstack_release (NULL);
>df_process_deferred_rescans ();
>
> - /* Conversion means we may have 128bit register spills/fills
> - which require aligned stack. */
> - if (converted_insns)
> -{
> - if (crtl->stack_alignment_needed < 128)
> - crtl->stack_alignment_needed = 128;
> - if (crtl->stack_alignment_estimated < 128)
> - crtl->stack_alignment_estimated = 128;
> -}
> -
>return 0;
> }
>
> @@ -12041,6 +12031,13 @@ ix86_update_stack_boundary (void)
>if (crtl->stack_alignment_needed < 128)
> crtl->stack_alignment_needed = 128;
> }
> +
> + /* The STV pass needs 64-bit stack alignment. */
> + if (!TARGET_64BIT
> + && TARGET_STV
> + && TARGET_SSE2 && optimize > 1
> + && crtl->stack_alignment_estimated < 64)
> +crtl->stack_alignment_estimated = 64;
> }
>
> /* Handle the TARGET_GET_DRAP_RTX hook. Return NULL if no DRAP is
Which will likely penalize even code where the stv pass wouldn't do anything.
Isn't it better to just disable the stv pass if the stack isn't aligned enough
(like in the #c4 or #c5 patches)?
[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454 --- Comment #29 from H.J. Lu --- (In reply to Jakub Jelinek from comment #28) > > Which will likely penalize even code where the stv pass wouldn't do anything. In normal case it is a nop since the incoming stack is 128-bit aligned. > Isn't it better to just disable the stv pass if the stack isn't aligned > enough > (like in the #c4 or #c5 patches)? Ilya, please run your tests with -mpreferred-stack-boundary=2 to see which approach is preferred.
[Bug target/69245] [6 Regression] ICE in extract_insn, at recog.c:2286 on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69245 --- Comment #14 from chrbr at gcc dot gnu.org --- Author: chrbr Date: Wed Jan 27 13:03:45 2016 New Revision: 232872 URL: https://gcc.gnu.org/viewcvs?rev=232872&root=gcc&view=rev Log: 2016-01-20 Christian Bruel PR target/69245 * config/arm/arm-c.c (arm_pragma_target_parse): Add comments. Move arm_reset_previous_fndecl and set_target_option_current_node in the conditional part. Call save_restore_target_globals. * config/arm/arm.c (arm_set_current_function): Refactor to better support #pragma target and attribute mix. Call save_restore_target_globals. * config/arm/arm-protos.h (save_restore_target_globals): New function. Added: trunk/gcc/testsuite/gcc.target/arm/pr69245.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm-c.c trunk/gcc/config/arm/arm-protos.h trunk/gcc/config/arm/arm.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #30 from H.J. Lu ---
Try this one:
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index a03a515..c82883e 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3588,16 +3588,6 @@ convert_scalars_to_vector ()
bitmap_obstack_release (NULL);
df_process_deferred_rescans ();
- /* Conversion means we may have 128bit register spills/fills
- which require aligned stack. */
- if (converted_insns)
-{
- if (crtl->stack_alignment_needed < 128)
- crtl->stack_alignment_needed = 128;
- if (crtl->stack_alignment_estimated < 128)
- crtl->stack_alignment_estimated = 128;
-}
-
return 0;
}
@@ -29300,8 +29290,10 @@ ix86_minimum_alignment (tree exp, machine_mode mode,
return align;
/* Don't do dynamic stack realignment for long long objects with
- -mpreferred-stack-boundary=2. */
- if ((mode == DImode || (type && TYPE_MODE (type) == DImode))
+ -mpreferred-stack-boundary=2. The STV pass needs 64-bit alignment
+ for DImode. */
+ if (!(TARGET_STV && TARGET_SSE2 && optimize > 1)
+ && (mode == DImode || (type && TYPE_MODE (type) == DImode))
&& (!type || !TYPE_USER_ALIGN (type))
&& (!decl || !DECL_USER_ALIGN (decl)))
return 32;
[Bug c/69429] gcc create sparse exec/libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69429 --- Comment #4 from joakim.tjernlund at transmode dot se --- (In reply to Jakub Jelinek from comment #3) > Because most of the powerpc distros now use 64KB page size instead of 4KB, > so having only 4KB common page size means security protection of relro area > usually does not work or covers smaller amount of data. > You can probably use -z common-page-size=4096 if you are sure you are never > going to run your binaries on a kernel with 64KB pages. Even for ppc32? It would be good with a configure option for ppc32 to have 4KB pages by default as it can be cumbersome to pass -z common-page-size=4096 for all apps/libs built for ppc32
[Bug fortran/69514] New: ICE with nested array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69514 Bug ID: 69514 Summary: ICE with nested array constructor Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mrestelli at gmail dot com Target Milestone: --- The attached code produces an internal compiler error. Notice that the problem disappears removing the multiplication 3.0_wp* . program p implicit none integer, parameter :: wp = selected_real_kind(12,307) real(wp), parameter :: w(2) = & (/ real(wp) :: 0 , 3.0_wp*(/ real(wp) :: 2 /) /) !real(wp), parameter :: w(2) = & ! this is fine ! (/ real(wp) :: 0 , (/ real(wp) :: 2 /) /) write(*,*) w end program p $ gfortran test.f90 -o test f951: internal compiler error: Speicherzugriffsfehler 0xa683cf crash_signal gcc/toplev.c:335 0x5c114c gfc_arith_times gcc/fortran/arith.c:696 0x5bf798 reduce_binary_ca gcc/fortran/arith.c:1329 0x5bf9a4 reduce_binary gcc/fortran/arith.c:1414 0x5c029b eval_intrinsic gcc/fortran/arith.c:1592 0x5c04ce eval_intrinsic_f3 gcc/fortran/arith.c:1725 0x61d334 match_add_operand gcc/fortran/matchexp.c:392 0x61d51c match_level_2 gcc/fortran/matchexp.c:480 0x61d672 match_level_3 gcc/fortran/matchexp.c:551 0x61d784 match_level_4 gcc/fortran/matchexp.c:599 0x61d784 match_and_operand gcc/fortran/matchexp.c:693 0x61d942 match_or_operand gcc/fortran/matchexp.c:722 0x61da32 match_equiv_operand gcc/fortran/matchexp.c:765 0x61db22 match_level_5 gcc/fortran/matchexp.c:811 0x61ce91 gfc_match_expr(gfc_expr**) gcc/fortran/matchexp.c:870 0x5c3a1a match_array_cons_element gcc/fortran/array.c:1051 0x5c4cc9 gfc_match_array_constructor(gfc_expr**) gcc/fortran/array.c:1146 0x61d029 match_primary gcc/fortran/matchexp.c:153 0x61d029 match_level_1 gcc/fortran/matchexp.c:211 0x61d029 match_mult_operand gcc/fortran/matchexp.c:267 $ gfortran --version GNU Fortran (GCC) 6.0.0 20160127 (experimental)
[Bug target/69245] [6 Regression] ICE in extract_insn, at recog.c:2286 on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69245 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Jakub Jelinek --- Assuming fixed.
[Bug c/69429] gcc create sparse exec/libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69429 --- Comment #5 from Jakub Jelinek --- Of course even for ppc32. The ppc64 kernel supports ppc32 binaries.
[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454 --- Comment #31 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #28) > Which will likely penalize even code where the stv pass wouldn't do anything. > Isn't it better to just disable the stv pass if the stack isn't aligned > enough Maybe we can use HJ's patch from Comment #27 and communicate converted_insns flag from convert_scalars_to_vector to ix86_finalize_stack_realign_flags? The i_f_s_r function is able to cancel the realignment just before prologue generation, when realignment is not needed.
[Bug c++/69462] FLT_EVAL_METHOD and DECIMAL_DIG missing in float.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69462 Dominik Vogt changed: What|Removed |Added Summary|stack overflow detected |FLT_EVAL_METHOD and ||DECIMAL_DIG missing in ||float.h --- Comment #5 from Dominik Vogt --- (Sorry, acidentally typed a search string into the wrong field.)
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 --- Comment #45 from H.J. Lu --- I opened a clang bug: https://llvm.org/bugs/show_bug.cgi?id=26337 I propose the following definitions: i. An empty record is: 1. A class without member. Or 2. An array of empty records. Or 3. A class with empty records. ii. An empty record type for parameter passing is POD for the purpose of layout and 1. A class without member. Or 2. A class with empty records.
[Bug libstdc++/69295] [6 Regression] New special math function failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69295 --- Comment #9 from Jonathan Wakely --- On big-endian ppc64 ext/special_functions/hyperg/check_value.cc these tests fail: data167, toler167 on line 11579 max_abs_frac = 4.82864e-13 data171, toler171 on line 11579 max_abs_frac = 5.15741e-12 data172, toler172 on line 11579 max_abs_frac = 3.10473e-11 data173, toler173 on line 11579 max_abs_frac = 1.09304e-12 data197, toler197 on line 11579 max_abs_frac = 4.82864e-13 data201, toler201 on line 11579 max_abs_frac = 1.86001e-12 data202, toler202 on line 11579 max_abs_frac = 3.21576e-12 data203, toler203 on line 11579 max_abs_frac = 2.58658e-12 data204, toler204 on line 11579 max_abs_frac = 6.15743e-13 data206, toler206 on line 11579 max_abs_frac = 1.87073e-10 data207, toler207 on line 11579 max_abs_frac = 7.72796e-10 data208, toler208 on line 11579 max_abs_frac = 5.19491e-09 data209, toler209 on line 11579 max_abs_frac = 2.15517e-10 data231, toler231 on line 11579 max_abs_frac = 5.15741e-12 data232, toler232 on line 11579 max_abs_frac = 3.10473e-11 data233, toler233 on line 11579 max_abs_frac = 1.09304e-12 data236, toler236 on line 11579 max_abs_frac = 1.87073e-10 data237, toler237 on line 11579 max_abs_frac = 7.72796e-10 data238, toler238 on line 11579 max_abs_frac = 5.19491e-09 data239, toler239 on line 11579 max_abs_frac = 2.15517e-10 data241, toler241 on line 11579 max_abs_frac = 1.68813e-09 data242, toler242 on line 11579 max_abs_frac = 2.64594e-08 data243, toler243 on line 11579 max_abs_frac = 3.02697e-07 data244, toler244 on line 11579 max_abs_frac = 4.34529e-07 data245, toler245 on line 11579 max_abs_frac = 2.36511e-07 for special_functions/02_assoc_legendre/check_value.cc only one fails: data033, toler033 on line 1901 max_abs_frac = 2.75283e-13 Ed, we need to do something about this. Jakub asked: > Increase tolerance on the problematic subtests, or only do that conditionally > on excess precision, or avoid testing altogether for excess precision, or > force flags like -ffloat-store to avoid excess precision? I'm leaning towards adding -ffloat-store so we don't use any excess precision (since that causes the results to match the values Ed generated using GSL, presumably on x86_64).
[Bug target/68662] [6 regression] FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68662
--- Comment #7 from Jakub Jelinek ---
Seems like powerpc* has lots of other issues related to mixing pic and non-pic
code. E.g.
int x;
int
foo (void)
{
return x;
}
__attribute__((optimize ("PIC"))) int
bar (void)
{
return x;
}
seems to ICE due to endless recursion with -O2 -m32 (every force_reg causes
another force_reg, at least in x86_64-linux -> powerpc64-linux cross).
[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454 --- Comment #32 from Ilya Enkovich --- (In reply to Uroš Bizjak from comment #31) > Maybe we can use HJ's patch from Comment #27 and communicate converted_insns > flag from convert_scalars_to_vector to ix86_finalize_stack_realign_flags? > The i_f_s_r function is able to cancel the realignment just before prologue > generation, when realignment is not needed. I don't see how it resolves DRAP register problem. Patch will indicate we need to realign but won't provide a DRAP for it. And as I mentioned before it might be unsafe to allocate DRAP after STV due to tail calls.
[Bug lto/68881] [6 Regression] UNRESOLVED/FAIL: gcc.dg/lto/attr-weakref-1 -O2 -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68881 --- Comment #14 from H.J. Lu --- (In reply to Jakub Jelinek from comment #13) > While GCC can do that, what if weakref is used in the source and the > definition is provided by user in inline asm? The assembly manual says: 7.102 '.weakref ALIAS, TARGET' == This directive creates an alias to the target symbol that enables the symbol to be referenced with weak-symbol semantics, but without actually making it weak. If direct references or definitions of the symbol are present, then the symbol will not be weak, but if all references to it are through weak references, the symbol will be marked as weak in the symbol table. The effect is equivalent to moving all references to the alias to a separate assembly source file, renaming the alias to the symbol in it, declaring the symbol as weak there, and running a reloadable link to merge the object files resulting from the assembly of the new source file and the old source file that had the references to the alias removed. The alias itself never makes to the symbol table, and is entirely handled within the assembler. It is unclear to me if TARGET could be a definition or not.
[Bug c++/69515] New: partial specialization of variable templates is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515
Bug ID: 69515
Summary: partial specialization of variable templates is broken
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
Reduced from http://stackoverflow.com/q/35027853/2756719:
struct A { A(int = 0); };
template class meow;
template A foo;
template A foo> = 1;
auto&& a = foo>;
auto&& b = foo>;
Output:
/tmp/ccpeDea7.s: Assembler messages:
/tmp/ccpeDea7.s:24: Error: symbol `foo' is already defined
Additionally, attempting to explicitly instantiate 'foo' using the partial
specialization causes a bogus error:
template A foo; // OK
template A foo>; // Error
prog.cc:11:12: error: 'foo' is not a static data member of a class template
template A foo>;
^~
[Bug libstdc++/69295] [6 Regression] New special math function failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69295 --- Comment #10 from Jakub Jelinek --- Does -ffloat-store help on ppc64 though? I believe that target doesn't have excess precision... Perhaps fma is used somewhere (can you objdump -dr check_value.exe | grep madd ?)? No idea if it is possible to disable fma on powerpc though.
[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454 --- Comment #33 from H.J. Lu --- (In reply to Ilya Enkovich from comment #32) > (In reply to Uroš Bizjak from comment #31) > > Maybe we can use HJ's patch from Comment #27 and communicate converted_insns > > flag from convert_scalars_to_vector to ix86_finalize_stack_realign_flags? > > The i_f_s_r function is able to cancel the realignment just before prologue > > generation, when realignment is not needed. > > I don't see how it resolves DRAP register problem. Patch will indicate we > need to realign but won't provide a DRAP for it. And as I mentioned before > it might be unsafe to allocate DRAP after STV due to tail calls. Please try my patch in comment 30.
[Bug libstdc++/69295] [6 Regression] New special math function failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69295 --- Comment #11 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #10) > Does -ffloat-store help on ppc64 though? I believe that target doesn't have > excess precision... Perhaps fma is used somewhere (can you objdump -dr > check_value.exe | grep madd ?)? No idea if it is possible to disable fma on > powerpc though. You're right, it doesn't help on ppc64, and objdump shows fmadd instructions.
[Bug c++/67364] [5/6 Regression] "accessing uninitialized member" error in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67364
--- Comment #4 from Marek Polacek ---
Is there any practical difference between brace-init-list:
constexpr closure() : member{} { }
and expression-list:
constexpr closure() : member() { }
?
[Bug c++/69496] [5/6 Regression] [C++ 14] ICE on VLA in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69496 --- Comment #6 from Marek Polacek --- Author: mpolacek Date: Wed Jan 27 14:26:38 2016 New Revision: 232875 URL: https://gcc.gnu.org/viewcvs?rev=232875&root=gcc&view=rev Log: PR c++/69496 * constexpr.c (cxx_eval_array_reference): Evaluate the number of elements of the array. * g++.dg/ext/constexpr-vla1.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/constexpr-vla1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/testsuite/ChangeLog
[Bug c++/69496] [5/6 Regression] [C++ 14] ICE on VLA in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69496 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- Fixed on trunk.
[Bug target/68273] [5/6 Regression] Wrong code on mips/mipsel due to (invalid?) peeking at alignments in function_arg.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273 Bernd Schmidt changed: What|Removed |Added CC||bernds at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #12 from Bernd Schmidt --- (In reply to Jeffrey A. Law from comment #10) > /* Advance to an even register if the argument is doubleword-aligned. */ > if (doubleword_aligned_p) > info->reg_offset += info->reg_offset & 1; > > Which can be tracked back to this commit: > commit 26bcab5a0015a5304899649081fd676996b8 > Author: rsandifo > Date: Sat Sep 25 07:42:43 2004 + > > * config/mips/mips.h (struct mips_args): Clarify comments. > * config/mips/mips.c (struct mips_arg_info): Likewise. > (mips_arg_info): Don't allow fpr_p to affect the register or > stack alignment. Remove o64 silliness. > (function_arg): Deal with the o32 float,float case specially. > Cc'ing Richard in case he has input.
[Bug libstdc++/69450] [6 Regression] libstdc++-v3/include/math.h:66:1 2: error: 'constexpr bool std::isnan(double)' conflicts with a previous declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69450 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P4
[Bug rtl-optimization/69032] [5/6 Regression] ICE: in cfg_preds_1, at sel-sched-ir.c:4809 with -fsched-pressure -fsel-sched-pipelining -fselective-scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69032 --- Comment #2 from Andrey Belevantsev --- Created attachment 37490 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37490&action=edit proposed patch We fail to find the proper seqno for the fresh bookkeeping copy here. The problem is that in get_seqno_by_preds we are iterating over bb from the given insn backwards up to the first bb insn. We skip the initial insn when iterating over bb, yet we should take seqno from it. The code in question originally didn't include bb head when iterating, and was patched to do so in 2011. The patch was wrong and instead of including bb head managed to exclude the original insn itself. By reading the original and patched code I've convinced myself that the right fix will be to do what the patch intended and include both the initial insn and the bb head in the iteration. The patch fixes the reported testcase but I will have to test it more thoroughly before submitting.
[Bug fortran/69268] [5 Regression] Sourced allocation calls function twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69268 --- Comment #4 from vehre at gcc dot gnu.org --- Author: vehre Date: Wed Jan 27 14:48:04 2016 New Revision: 232876 URL: https://gcc.gnu.org/viewcvs?rev=232876&root=gcc&view=rev Log: gcc/testsuite/ChangeLog: 2016-01-27 Andre Vehreschild PR fortran/69268 * gfortran.dg/allocatable_scalar_13.f90: Fixing counts of malloc/ free to fit the actual number of calls. * gfortran.dg/allocate_with_source_16.f90: New test. gcc/fortran/ChangeLog: 2016-01-27 Andre Vehreschild PR fortran/69268 * trans-stmt.c (gfc_trans_allocate): Make sure the source= expression is evaluated once only. Use gfc_trans_assignment () instead of explicitly calling gfc_trans_string_copy () to reduce the code complexity in trans_allocate. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_16.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/trans-stmt.c branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocatable_scalar_13.f90
[Bug tree-optimization/69355] [5 Regression] Wrong results with -O1 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69355 --- Comment #21 from Martin Jambor --- Author: jamborm Date: Wed Jan 27 14:51:17 2016 New Revision: 232877 URL: https://gcc.gnu.org/viewcvs?rev=232877&root=gcc&view=rev Log: [PR 69355] Correct hole detection when total_scalarization fails 2016-01-27 Martin Jambor PR tree-optimization/69355 * tree-sra.c (analyze_access_subtree): Correct hole detection when total_scalarization fails. testsuite/ * gcc.dg/tree-ssa/pr69355.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr69355.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c
[Bug tree-optimization/69166] [4.9/5/6 Regression] ICE in get_initial_def_for_reduction, at tree-vect-loop.c:4188
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69166 --- Comment #8 from Richard Biener --- Author: rguenth Date: Wed Jan 27 14:54:03 2016 New Revision: 232878 URL: https://gcc.gnu.org/viewcvs?rev=232878&root=gcc&view=rev Log: 2016-01-27 Richard Biener PR tree-optimization/69166 * tree-vect-loop.c (vect_is_simple_reduction): Always check reduction code for commutativity / associativity. * gcc.dg/torture/pr69166.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr69166.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/69166] [4.9/5 Regression] ICE in get_initial_def_for_reduction, at tree-vect-loop.c:4188
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69166 Richard Biener changed: What|Removed |Added Known to work||6.0 Summary|[4.9/5/6 Regression] ICE in |[4.9/5 Regression] ICE in |get_initial_def_for_reducti |get_initial_def_for_reducti |on, at |on, at |tree-vect-loop.c:4188 |tree-vect-loop.c:4188 Known to fail|6.0 | --- Comment #9 from Richard Biener --- Fixed on trunk sofar.
[Bug target/68662] [6 regression] FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68662 --- Comment #8 from Peter Bergner --- (In reply to Jakub Jelinek from comment #7) > seems to ICE due to endless recursion with -O2 -m32 (every force_reg causes > another force_reg, at least in x86_64-linux -> powerpc64-linux cross). I see a similar failure on a native compile too.
[Bug fortran/69268] [5 Regression] Sourced allocation calls function twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69268 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING
[Bug fortran/69495] unused-label warning does not tell which flag triggered it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #2) > I think there must be a lot more cases of this: Yes, those should be taken care of as well. I'll try to do that. I guess practically all occurrences of "gfc_warning (0, ..." need to be transformed, or are there cases where the zero is legitimate?
[Bug fortran/69495] unused-label warning does not tell which flag triggered it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495 --- Comment #4 from janus at gcc dot gnu.org --- Btw, I noticed another loosely related issue concerning misspellings of the warning flags: $ gfortran -Wunused-labels test.f90 gfortran: error: unrecognized command line option ‘-Wunused-labels’ $ gfortran -Wno-unused-labels test.f90 (no error!) $ gfortran -Wall -Wno-unused-labels test.f90 f951: Warning: unrecognized command line option ‘-Wno-unused-labels’ This seems very inconsistent: All three calls involve an invalid flag, but the diagnostics is very different for each of them (it's particularly bad that the second case does not give any kind of feedback). Is there a reason for this behavior?
[Bug libstdc++/69295] [6 Regression] New special math function failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69295 --- Comment #12 from Jonathan Wakely --- Author: redi Date: Wed Jan 27 15:09:38 2016 New Revision: 232879 URL: https://gcc.gnu.org/viewcvs?rev=232879&root=gcc&view=rev Log: Set FP options for failing special functions tests PR libstdc++/69295 * testsuite/ext/special_functions/hyperg/check_value.cc: Use -ffp-contract=off, and -ffloat-store to disable excess precision. * testsuite/special_functions/02_assoc_legendre/check_value.cc: Use -ffp-contract=off. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/ext/special_functions/hyperg/check_value.cc trunk/libstdc++-v3/testsuite/special_functions/02_assoc_legendre/check_value.cc
[Bug libstdc++/69295] [6 Regression] New special math function failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69295 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Jonathan Wakely --- Should be ok now.
[Bug fortran/69495] unused-label warning does not tell which flag triggered it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495 --- Comment #5 from Manuel López-Ibáñez --- (In reply to janus from comment #4) > This seems very inconsistent: All three calls involve an invalid flag, but > the diagnostics is very different for each of them (it's particularly bad > that the second case does not give any kind of feedback). Is there a reason > for this behavior? https://gcc.gnu.org/wiki/FAQ#wnowarning But the third call should have given some other warning; otherwise there is a bug.
[Bug fortran/69485] oddity with -Wtabs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69485 --- Comment #5 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #4) > Confirmed from 4.8 up to trunk (6.0) for fixed-form. > > After converting the include file to free-form I get So you're saying the problem only exists for fixed form? I guess whether an include file is interpreted as fixed or free form is actually determined by the file it's included from (.f or .f90), right?
[Bug fortran/69495] unused-label warning does not tell which flag triggered it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495 --- Comment #6 from Manuel López-Ibáñez --- (In reply to janus from comment #3) > I guess practically all occurrences of "gfc_warning (0, ..." need to be > transformed, or are there cases where the zero is legitimate? Most warnings don't have a command-line option associated to them, they are enabled by default and cannot be disabled. I'm not sure whether they should, this is up to the gfortran maintainers. The consensus in C/C++ so far has been that adding options for all warnings would add too many options that nobody uses. Clang does associate an option to every warning. Other warnings that can be enabled/disabled by an option must use the corresponding OPT_ in the warning call.
[Bug tree-optimization/69466] [6 Regression] ICE: Invalid PHI argument after vectorization (on -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69466 --- Comment #9 from Richard Biener --- I am testing that patch now.
[Bug fortran/69495] unused-label warning does not tell which flag triggered it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495 --- Comment #7 from janus at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #5) > (In reply to janus from comment #4) > > Is there a reason for this behavior? > > https://gcc.gnu.org/wiki/FAQ#wnowarning I see. So this is intended and not a bug. Thanks for the pointer. > But the third call should have given some other warning; otherwise there is > a bug. Right, there was a warning. I just omitted it because I did not expect that it makes a difference.
[Bug fortran/69484] [5/6 Regression] documentation issue: -Wtabs and -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69484 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug c++/68514] [6 Regression] ICE in tr1/5_numerical_facilities libstdc++ test cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68514 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Jakub Jelinek --- .
[Bug target/65931] [5/6 regression] dsymutil assertion failure building libgnat-5.dylib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65931 Jakub Jelinek changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #11 from Jakub Jelinek --- .
[Bug c++/66487] [6 Regression] Firefox segfault with LTO enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66487 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #14 from Jakub Jelinek --- (In reply to Jason Merrill from comment #4) > Actually, I guess checking for this is more of a fit for an uninitialized > read detector such as MemorySanitizer or Valgrind memcheck. Well, AddressSanitizer should be able to do that too with some extra work, what we need is know not just when the lifetime of a variable ends, but also when it starts, and instrument those two, plus disable reusing variable stack slots when instrumenting. In the function prologue we'd then mark the variables as unavailable, not just their padding, and then when they get into scope (that is the first clobber these days), we'd mark them enabled and when they get out of scope (second clobber) mark them unavailable again. GCC7 material.
[Bug c++/69317] [6 regression] wrong ABI version in -Wabi warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69317 --- Comment #3 from Martin Sebor --- Author: msebor Date: Wed Jan 27 15:44:07 2016 New Revision: 232881 URL: https://gcc.gnu.org/viewcvs?rev=232881&root=gcc&view=rev Log: PR c++/69317 - [6 regression] wrong ABI version in -Wabi warnings gcc/cp/ChangeLog: 2016-01-27 Martin Sebor PR c++/69317 * mangle.c (mangle_decl): Reference the correct (saved) version of the ABI in -Wabi diagnostics. gcc/testsuite/ChangeLog: 2016-01-27 Martin Sebor PR c++/69317 * g++.dg/abi/Wabi-2-2.C: New test. * g++.dg/abi/Wabi-2-3.C: New test. * g++.dg/abi/Wabi-3-2.C: New test. * g++.dg/abi/Wabi-3-3.C: New test. Added: trunk/gcc/testsuite/g++.dg/abi/Wabi-2-2.C trunk/gcc/testsuite/g++.dg/abi/Wabi-2-3.C trunk/gcc/testsuite/g++.dg/abi/Wabi-3-2.C trunk/gcc/testsuite/g++.dg/abi/Wabi-3-3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/testsuite/ChangeLog
