[Bug middle-end/57955] [4.8/4.9/5 Regression] Uniquization of constants reduces alignment of initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57955 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- I'll note that (not obvious from the comments) this PR talks about the r158838 change affecting the r201264 revision of the ppc-vector-memcpy.c test, r201265 changed the test again, so that it doesn't fail.
[Bug libstdc++/65114] char_traits::copy violates memcpy constraints, own postcondition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65114 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-19 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- PR65049 is another case where I wonder if char_traits members should be more consistent with the C memxxx() functions than currently specified, i.e. should have the same preconditions as the C functions.
[Bug libstdc++/65122] std::vector doesn't honor element alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122 --- Comment #3 from Benoit Jacob jacob.benoit.1 at gmail dot com --- I'd be interested in an explanation of why the default STL allocator can't just honor the alignment of the value_type ? (The document linked in comment 2 seemed to assume that that goes without saying?)
[Bug testsuite/65116] [4.9/5 Regression] additional_sources not defined anymore during dg-final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65116 --- Comment #8 from vries at gcc dot gnu.org --- (In reply to Maxim Kuvyrkov from comment #5) It was tested, but, obviously, not as well as it should. I'll revert the change for now. Hi Maxim, The change was reverted on 4-9 branch. Did you also plan to revert it on trunk? Thanks, - Tom
[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #54 from Jan Hubicka hubicka at ucw dot cz ---
diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 440ced4..3bf068a 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -1451,7 +1451,7 @@ propagate_alignment_accross_jump_function (struct
cgraph_edge *cs,
else
{
src_idx = ipa_get_jf_ancestor_formal_id (jfunc);
- offset = ipa_get_jf_ancestor_offset (jfunc);
+ offset = ipa_get_jf_ancestor_offset (jfunc) / BITS_PER_UNIT;
}
src_lats = ipa_get_parm_lattices (caller_info, src_idx);
Hehe, patch is OK
What about the lattice operations patch. If it looks fine to you, i will
regtest/bootstrap and commit.
Honza
[Bug testsuite/65116] [4.9/5 Regression] additional_sources not defined anymore during dg-final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65116 Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org --- Fixed by the above commit. Will re-apply the change with this fix on 4.9 branch in a week if everything looks OK.
[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #53 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Martin Jambor from comment #52)
So, as you might have guessed from the previous comment, this is the
fix. I should have left the office half an hour ago so I will
properly bootstrap and test and submit it tomorrow, but feel free to
do all of that yourself, if you do not want to wait.
diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 440ced4..3bf068a 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -1451,7 +1451,7 @@ propagate_alignment_accross_jump_function (struct
cgraph_edge *cs,
else
{
src_idx = ipa_get_jf_ancestor_formal_id (jfunc);
- offset = ipa_get_jf_ancestor_offset (jfunc);
+ offset = ipa_get_jf_ancestor_offset (jfunc) / BITS_PER_UNIT;
}
src_lats = ipa_get_parm_lattices (caller_info, src_idx);
I verified that it fixed 252.eon on x32. Thanks.
[Bug testsuite/65093] 26_numerics/random/binomial_distribution/operators/values.cc times out on slow targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65093 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Hans-Peter Nilsson hp at gcc dot gnu.org --- (In reply to Hans-Peter Nilsson from comment #1) (It's just odd that no FAIL has been observed before, as the test itself hasn't changed for quite some time, like 1.5 year since the last two camel-back-breaking subtests were added.) The test was enabled relatively recently for my autotesters, for the 4.9 branch as late as 2014-12-17 (c:a r218800) and for trunk about 2015-02-15 (c:a r220715). This happened automatically. The cause is most probably an update of newlib, to a version with the pieces missing for dg-require-cstdint or dg-require-cmath to be true. Automatic updates only happen when the branch is regression-free and only if the results after a tentative update would still be regression-free. There's no specific log event for tests that pass after an update.
[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #55 from H.J. Lu hjl.tools at gmail dot com ---
Another issue is propagate_constants_accross_call has
for (; (i args_count) (i parms_count); i++)
{
struct ipa_jump_func *jump_func = ipa_get_ith_jump_func (args, i);
struct ipcp_param_lattices *dest_plats;
dest_plats = ipa_get_parm_lattices (callee_info, i);
if (availability == AVAIL_INTERPOSABLE)
ret |= set_all_contains_variable (dest_plats);
else
{
ret |= propagate_scalar_accross_jump_function (cs, jump_func,
dest_plats-itself);
ret |= propagate_context_accross_jump_function (cs, jump_func, i,
dest_plats-ctxlat);
ret |= propagate_alignment_accross_jump_function (cs, jump_func,
dest_plats);
ret |= propagate_aggs_accross_jump_function (cs, jump_func,
dest_plats);
}
}
Even if availability == AVAIL_INTERPOSABLE, alignment from jump_func
is used if the function isn't preempted at run-time. Shouldn't it
call propagate_alignment_accross_jump_function unconditionally?
[Bug testsuite/65093] 26_numerics/random/binomial_distribution/operators/values.cc times out on slow targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65093 --- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org --- Author: hp Date: Thu Feb 19 19:30:03 2015 New Revision: 220821 URL: https://gcc.gnu.org/viewcvs?rev=220821root=gccview=rev Log: PR testsuite/65093 * testsuite/26_numerics/random/binomial_distribution/operators/values.cc (test01): Add explanatory comment. Keep only the bd1 sub-test and split out bd2, bd3, bd4, and bd5 sub-tests into... * testsuite/26_numerics/random/binomial_distribution/operators/values2.cc, testsuite/26_numerics/random/binomial_distribution/operators/values3.cc, testsuite/26_numerics/random/binomial_distribution/operators/values4.cc, testsuite/26_numerics/random/binomial_distribution/operators/values5.cc: New separate files with the old parts. Added: trunk/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values2.cc trunk/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values3.cc trunk/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values4.cc trunk/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values5.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc
[Bug fortran/65125] New: ISO_10646 characters and transfer statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65125
Bug ID: 65125
Summary: ISO_10646 characters and transfer statement
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: zbeekman at gmail dot com
Created attachment 34810
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34810action=edit
reproducer program
I am on OS X Yosemite, 10.10.2 with a 64bit Intel CPU.
Gfortran is version: NU Fortran (Homebrew gcc49 4.9.2_1 --enable-fortran) 4.9.2
I'm trying to make a portable json library that will behave gracefully when
encountering compilers whose ISO_10646 support is lacking. To achieve this, for
certain variables use the character kind defined as:
integer, parameter :: CK =
merge(tsource=selected_char_kind('ISO_10646'),fsource=selected_char_kind('DEFAULT'),mask=selected_char_kind('ISO_10646')
/= -1)
The error handling of the library needs a way to both DEFAULT and ISO_10646
characters, but overloading the error handling routine to have two interfaces
won't work because when ISO_10646 *isn't* supported the two specific routines
will have matching interfaces. As a work around, I would like to print the hex
representation of characters that are `kind=CK` that is possibly ISO_10646 or
DEFAULT. To accomplish this I have written a function `char_to_hex(c)` to try
to print the hex representation of the character. To do this, I am using
`transfer()` to puth the passed in single character into a sufficiently large
integer, and using the `z8.8` edit descriptor to convert to the function result
which is ALWAYS represented in `kind='DEFAULT'` characters (so that I can
safely pass it to the error handling routine).
The problem is that it appears the transfer statement is only writing 2 nibbles
(one byte) to the integer, or the z8.8 is only fetching two nibbles of the
int32 integer. Forexample, the output for a Unicode SNOWFLAKE is 0x00E2
when it should be: 0x00E29d84. I think the problem is the transfer statement,
since I observe some strange behavior if I modify the char_to_hex() function to
accept len=4 character strings, and adjust the inputs to be the character in
question followed by 4 spaces, and adjust the storage container to int64 and
edit descriptor to z18.18. Now SNOWFLAKE prints out as 0x0x009D00E2:
two most significant nibbles are on the right, then 6 zero nibbles to the left,
the 3rd and 4th most significant nibbles, then more zeroes.
Am I missing something? If not, I think this is a bug.
[Bug testsuite/65116] [4.9/5 Regression] additional_sources not defined anymore during dg-final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65116 --- Comment #9 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org --- Author: mkuvyrkov Date: Thu Feb 19 19:57:30 2015 New Revision: 220822 URL: https://gcc.gnu.org/viewcvs?rev=220822root=gccview=rev Log: Fix PR testsuite/65116 PR testsuite/65116 * lib/target-supports.exp (check_compile): Check whether additional_sources is defined before using it. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp
[Bug c++/62204] internal compiler error with -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62204 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed by r218729 I think.
[Bug libstdc++/58357] [5 Regression] In C++11 std::rotate(first, middle, last) now should return a forward iterator to first + (last - middle).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58357 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Done.
[Bug libstdc++/58357] [5 Regression] In C++11 std::rotate(first, middle, last) now should return a forward iterator to first + (last - middle).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58357 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Thu Feb 19 20:57:40 2015 New Revision: 220823 URL: https://gcc.gnu.org/viewcvs?rev=220823root=gccview=rev Log: PR libstdc++/58357 * include/bits/algorithmfwd.h (rotate): Move to inline namespace _V2. * include/bits/stl_algo.h (__rotate, rotate): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/algorithmfwd.h trunk/libstdc++-v3/include/bits/stl_algo.h
[Bug libstdc++/65122] std::vector doesn't honor element alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122 --- Comment #4 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Benoit Jacob from comment #3) I'd be interested in an explanation of why the default STL allocator can't just honor the alignment of the value_type ? [allocator.members] It is implementation-defined whether over-aligned types are supported so we don't really have to. the storage is obtained by calling ::operator new(std::size_t) so we can't use posix_memalign (providing a separate allocator that does could be a good idea though). We could, when the type is over-aligned, do the usual trick of requesting too much memory so we have enough margin to find a suitably aligned region inside, and write a marker before so we remember where the real allocation started. That might be what was tried in PR55727 (I didn't check), the maintainers might be ok with this if someone posts a patch. But calling new T would still be broken. It seems better in the long term to add the aligned versions of operator new and make both new and std::allocator use those (in the standard). Note that there would be ABI issues switching from the trick in the previous paragraph to this.
[Bug libstdc++/65122] std::vector doesn't honor element alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122 --- Comment #5 from Benoit Jacob jacob.benoit.1 at gmail dot com --- So while the standard says that over-aligned types dont have to be supported, it also says in 3.11/9 in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf that: If a request for a specific extended alignment in a specific context is not supported by an implementation, the program is ill-formed. Additionally, a request for runtime allocation of dynamic storage for which the requested alignment cannot be honored shall be treated as an allocation failure In my naive understanding, that sounds like if over-aligned allocation is not supported then it must be an allocation failure (i.e. not fail silently to honor alignment). That's relevant because failing all over-allocated allocations is probably not something that a compiler could do in the real world (that would break a lot of existing software) and so this 3.11/9 clause might then be de-facto forcing compilers to support over-allocated allocation. What do you think? How else would you interprete 3.11/9?
[Bug libstdc++/65122] std::vector doesn't honor element alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122 --- Comment #6 from Benoit Jacob jacob.benoit.1 at gmail dot com --- (In reply to Marc Glisse from comment #4) the storage is obtained by calling ::operator new(std::size_t) so we can't use posix_memalign Ouch. That's very unfortunate. I see. I would still be interested in how you understand 3.11/9 and how to reconcile it with that without breaking a lot of software.
[Bug testsuite/65116] additional_sources not defined anymore during dg-final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65116
--- Comment #1 from vries at gcc dot gnu.org ---
Presumably same thing happens for pr47218.C, which saves temps:
...
/* { dg-options -save-temps } */
...
And cleans them up:
...
// { dg-final { cleanup-saved-temps }
...
but also has additional sources:
...
/* { dg-additional-sources pr47218-1.C } */
...
Of which the temps are not cleaned up:
...
pr47218-1.o pr47218-1.ii pr47218-1.s
...
[Bug tree-optimization/62630] [5 regression] gcc.dg/graphite/vect-pr43423.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630 --- Comment #15 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Mircea Namolaru from comment #14) It seems to me that scalar evolution succeeds to determine the number of iterations for the case of signed longs. Looking in vectorization dump, first a symbolic expression for the number of iterations of a loop is found, and then vect_analyze_refs is entered. The problem is that the code expect an offset of a load to be an induction variable, but in our case an offset is only a cast of an induction variable, like below: _56 = (intD.6) graphite_IV.5_53; _55 = aD.1830[_56]; The offset is found not to be an affine expression, and vectorization don't succeed. But as the offset is a cast of an induction variable, it has the same behaviour as an induction variable even if formally is not one. This is not true - the cast of the induction variable is not an affine IV as the cast introduces wrapping if the IV exceeds the range of the casted-to type. number-of-iteration analysis can come to the rescue here but it has a very hard time, especially on the 2nd loop. It would be good to improve it anyway but we can hardly blame it solely for the problems ;) It seems to me that somehow extending the code to support casts of induction variables will solve our this problem.
[Bug rtl-optimization/44404] auto-inc-dec generates an invalid assembly instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44404 cbaylis at gcc dot gnu.org changed: What|Removed |Added CC||gilles.chanteperdrix@xenoma ||i.org --- Comment #9 from cbaylis at gcc dot gnu.org --- *** Bug 38674 has been marked as a duplicate of this bug. ***
[Bug middle-end/38674] When storing in a register the address of a value contained in the same register, gcc 4.3.2 on ARM clobbers the register before saving its content on the stack.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38674 cbaylis at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||cbaylis at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from cbaylis at gcc dot gnu.org --- This appears to have been fixed by r161920 2010-07-07 Bernd Schmidt ber...@codesourcery.com PR rtl-optimization/44404 * auto-inc-dec.c (find_inc): Avoid calling count_occurrences if possible, use reg_overlap_mentioned_p instead. *** This bug has been marked as a duplicate of bug 44404 ***
[Bug testsuite/65116] additional_sources not defined anymore during dg-final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65116 vries at gcc dot gnu.org changed: What|Removed |Added CC||mkuvyrkov at gcc dot gnu.org --- Comment #3 from vries at gcc dot gnu.org --- I suspect those errors are due to Maxim's recent checkin. Maybe missing exist test?
[Bug c/65117] New: xtensa: With -Os, invalid parameter c1 for reg_class_subset_p() to cause segment fault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65117
Bug ID: 65117
Summary: xtensa: With -Os, invalid parameter c1 for
reg_class_subset_p() to cause segment fault.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen.5i5j at gmail dot com
The related source file:
# cat r100.i
#pragma pack()
struct r100_cs_cube_info {
char a[17];
unsigned int width;
unsigned int height;
};
struct r100_cs_track_texture {
char a[96];
struct r100_cs_cube_info cube_info[5];
unsigned int tex_coord_type;
unsigned int txdepth;
char roundup_h;
};
struct r100_cs_track {
char a[89];
unsigned int num_cb;
unsigned int num_texture;
struct r100_cs_track_texture textures[2];
};
struct radeon_device;
void r100_cs_track_clear(int x, struct r100_cs_track *y)
{
int i, j;
for (i = 0; i y-num_texture; i++) {
if (x = 8)
y-textures[i].txdepth = 0;
else {
y-textures[i].txdepth = 9;
y-textures[i].tex_coord_type = 1;
}
y-textures[i].roundup_h = 0;
if (y-num_cb)
for (j= 0; j 5; j++) {
y-textures[i].cube_info[j].width = 2;
y-textures[i].cube_info[j].height = 2;
}
}
}
The related issue:
# /upstream/release-xtensa/libexec/gcc/xtensa-gchen-elf32/5.0.0/cc1 -Os r100.i
r100.i: In function 'r100_cs_track_clear':
r100.i:43:1: internal compiler error: Segmentation fault
}
^
0xa4427f crash_signal
../../gcc-xtensa/gcc/toplev.c:383
0x9c79c0 reg_class_subset_p(int, int)
../../gcc-xtensa/gcc/reginfo.c:1221
0x9d7a0c find_reloads(rtx_insn*, int, int, int, short*)
../../gcc-xtensa/gcc/reload.c:3678
0x9e2cbb reload_as_needed
../../gcc-xtensa/gcc/reload1.c:4688
0x9e8460 reload(rtx_insn*, int)
../../gcc-xtensa/gcc/reload1.c:1092
0x8cdb2d do_reload
../../gcc-xtensa/gcc/ira.c:5430
0x8cdb2d execute
../../gcc-xtensa/gcc/ira.c:5589
The related version:
# /upstream/release-xtensa/bin/xtensa-gchen-elf32-gcc -v
Using built-in specs.
COLLECT_GCC=/upstream/release-xtensa/bin/xtensa-gchen-elf32-gcc
COLLECT_LTO_WRAPPER=/upstream/release-xtensa/libexec/gcc/xtensa-gchen-elf32/5.0.0/lto-wrapper
Target: xtensa-gchen-elf32
Configured with: ../gcc-xtensa/configure --target=xtensa-gchen-elf32
--prefix=/upstream/release-xtensa --disable-nls --enable-languages=c
--disable-threads --disable-shared --enable-libssp --disable-libquadmath
--disable-libgomp --disable-libatomic
Thread model: single
gcc version 5.0.0 20150219 (experimental) (GCC)
# /upstream/release-xtensa/bin/xtensa-gchen-elf32-ld -v
GNU ld (GNU Binutils) 2.25.51.20150219
I shall try to fix it within this month, at present, the direct cause is: for
reg_class_subset_p(), the upper caller passes an incorrect parameter c1 which
value is -926186479, and this issue has only effect with -Os (no effect with
-O0, or -O2 ...).
[Bug testsuite/65116] New: additional_sources not defined anymore during dg-final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65116
Bug ID: 65116
Summary: additional_sources not defined anymore during dg-final
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
When running vect-simd-clone-10.c, a file vect-simd-clone-10a.c.126t.vect is
left in the test directory.
The testcase lists vect-simd-clone-10a.c as addditional source:
...
/* { dg-additional-sources vect-simd-clone-10a.c } */
...
Then the test-case cleans up the respective tree-dump:
...
/* { dg-final { cleanup-tree-dump vect } } */
...
The cleanup-tree-dump calls cleanup-dump, which intends to take
additional_sources into account.
However, the global additional_sources declaration is missing, so the exists
additional_sources will always return false.
And if we add the global additional_sources declaration, it still fails,
because additional_sources is empty. It has been reset by
dg-additional-files-options, which is called by gcc_target_compile, which is
called by gcc-dg-test-1, which is called by gcc-dg-test, which is called by
dg-test as ${tool}-dg-test.
dg-test does the the dg-final-code processing after the ${tool}-dg-test so at
that point additional_sources is empty.
[Bug libstdc++/65113] string::copy violates traits requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65113 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-19 Ever confirmed|0 |1
[Bug lto/65012] [5 Regression] systemd fails to build at least on ppc64el, powerpc, arm-inux-gnueabihf and aarch64 with -flto (ICE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65012 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Feb 19 11:56:00 2015 New Revision: 220810 URL: https://gcc.gnu.org/viewcvs?rev=220810root=gccview=rev Log: PR lto/65012 * varpool.c (varpool_node::get_constructor): Return early if this-lto_file_data is NULL. Modified: trunk/gcc/ChangeLog trunk/gcc/varpool.c
[Bug sanitizer/65112] [5 Regression] -fsanitized=thread Fortran program crashes at startup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65112 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug testsuite/65116] additional_sources not defined anymore during dg-final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65116
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
Is this related to these errors I'm seeing in the libstdc++ testsuite?
ERROR: 18_support/type_info/fundamental.cc: can't read additional_sources: no
such variable for dg-require-effective-target 2 dfp
ERROR: 17_intro/shared_with_static_deps.cc: can't read additional_sources: no
such variable for dg-require-effective-target 4 fpic
ERROR: 21_strings/c_strings/char/3_neg.cc: can't read additional_sources: no
such variable for dg-do 1 compile { target
correct_iso_cpp_string_wchar_protos }
ERROR: 21_strings/c_strings/wchar_t/3_neg.cc: can't read
et_cache(correct_iso_cpp_string_wchar_protos,value): no such element in array
for dg-do 1 compile { target correct_iso_cpp_string_wchar_protos }
ERROR: 22_locale/collate/compare/wchar_t/wrapped_env.cc: can't read
additional_sources: no such variable for dg-require-iconv 4 ISO8859-1
...
[Bug testsuite/65116] [4.9/5 Regression] additional_sources not defined anymore during dg-final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65116 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.9.3 Summary|additional_sources not |[4.9/5 Regression] |defined anymore during |additional_sources not |dg-final|defined anymore during ||dg-final Severity|trivial |blocker --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Also broken on the 4.9 branch. Was this ever tested?!
[Bug rtl-optimization/64317] [5 Regression] Ineffective allocation of PIC base register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64317
--- Comment #12 from Jeffrey A. Law law at redhat dot com ---
I'm very aware that the x86 backend doesn't support a fixed PIC register
anymore.
RA was going to have to spill something. THe PIC register is needed in three
different loops, L0, L1 and L2. L0 needs 9 general purpose registers, L8 needs
8 general purpose registers and L2 needs 9 general purpose registers. ie,
there's going to be spills, there's simply no way around it.
r107 (PIC pseudo) gets split into 3 allocnos. A1, A11 and A237, covering Loops
0, 2, 1 respectively. It's live throughout most of the resultant function by
way of explicit references and the need to have %ebx set up prior to external
calls.
For Loop 1 Loop 2, the respective allocnos (A237, A11) are not used/set
within the loop at all, ie, they are transparent within their respective loops.
IRA does exactly what we want here by keeping the PIC register in memory which
frees up a register within those loops for other objects that are used within
the loop. Of course, to do that we have to reload the value for the uses
outside the boundary of those loops.
Loop 0 (bbs 0, 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19) is the most
interesting and is the one where we have those annoying reloads.
One of the things I notice is that LRA is generating sequences like:
(insn 581 89 90 6 (set (reg:SI 3 bx [107])
(mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 28 [0x1c])) [4 %sfp+-4 S4 A32])) j.c:19 90
{*movsi_internal}
(nil))
(insn 90 581 91 6 (set (reg/f:SI 3 bx [orig:142 D.2145 ] [142])
(mem/f/c:SI (plus:SI (reg:SI 3 bx [107])
(const:SI (unspec:SI [
(symbol_ref:SI (out) [flags 0x2] var_decl
0x7670bc60 out)
] UNSPEC_GOTOFF))) [1 out+0 S4 A32])) j.c:19 90
{*movsi_internal}
(nil))
Note how we load %ebx from memory, then use/clobber it in the next insn. That
makes it impossible for the post-reload optimizers to help clean this up. How
hard would it be to generate code in LRA where those two insns set different
registers in those local snippets of code?
In this particular case, %ebp is locally available and there's no strong reason
why we have to use %ebx. By using different destinations for insns 581 and
90, the source MEM of insn 581 would be available after insn 90. And by making
the value available postreload-gcse would be able to commonize those loads.
[Bug c/65120] [5 Regression] Wlogical-not-parentheses should not warn about double exclamation !!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65120 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- And yes, the required if ((!!a) == b) is totally fugly.
[Bug testsuite/65116] [4.9/5 Regression] additional_sources not defined anymore during dg-final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65116 --- Comment #5 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org --- It was tested, but, obviously, not as well as it should. I'll revert the change for now.
[Bug c/65120] New: [gcc5] Wlogical-not-parentheses should not wanr about double exclamation !!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65120 Bug ID: 65120 Summary: [gcc5] Wlogical-not-parentheses should not wanr about double exclamation !! Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jirislaby at gmail dot com While warning about if (!a == b) is perfectly fine and I like it, I do not like warning about if (!!a = b) at all. It generates plenty of false positives (in the Linux kernel at least) and I doubt it can warn about an error at all. Better than papering over this as if ((!aa) = b) or by -Wno-logical-not-parentheses does not make much sense to me (opposing to the single ! case). Note: this is all about: logical not is only applied to the left hand side of comparison
[Bug c/65120] [5 Regression] Wlogical-not-parentheses should not warn about double exclamation !!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65120 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Oh, you can also workaround with if (b == !!a)
[Bug testsuite/65116] [4.9/5 Regression] additional_sources not defined anymore during dg-final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65116 --- Comment #6 from vries at gcc dot gnu.org --- I reproduced the issue in the description field with and without Maxim's patch, so AFAIU it's an orthogonal issue.
[Bug libstdc++/65118] New: Android target build is broken with guard.cc:36:22: fatal error: syscall.h: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65118 Bug ID: 65118 Summary: Android target build is broken with guard.cc:36:22: fatal error: syscall.h: No such file or directory Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: aivchenk at gmail dot com configured with: /users/aivchenk/toolchain_3/gcc/gcc-5.0/libstdc++-v3/configure - --enable-multilib --with-cross-host=x86_64-linux-gnu --disable-bootstrap --with-sysroot=/users/aivchenk/ndk/android-ndk-r10d/platforms/android-21/arch-x86_64/ --disable-shared --disable-libitm --disable-libsanitazer --enable-languages=c,c++,lto --program-transform-name=s^x86_64-linux-android- --disable-option-checking --with-target-subdir=x86_64-linux-android --build=x86_64-linux-gnu --host=x86_64-linux-android --target=x86_64-linux-android /users/aivchenk/toolchain_3//gcc/gcc-4.10/libstdc++-v3/libsupc++/guard.cc:36:22: fatal error: syscall.h: No such file or directory Should we guard that with __ANDROID__?
[Bug lto/65012] [5 Regression] systemd fails to build at least on ppc64el, powerpc, arm-inux-gnueabihf and aarch64 with -flto (ICE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65012 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug c++/65119] New: -fmessage-length= counts control characters when wrapping the caret line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65119
Bug ID: 65119
Summary: -fmessage-length= counts control characters when
wrapping the caret line
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
struct {
int y;
} x;
#define FOO
x*x
void foo()
{
FOO;
}
~/test1/220306M/build/gcc/cc1 test.c -fmessage-length=10
-fdiagnostics-color=always
foo
test.c: In
function
‘foo’
:
test.c:4:144: error: invalid
operands
to
binary
*
(have
‘struct
anonymous’
and
‘struct
anonymous’
)
x*x
^
test.c:7:3: note: in
expansion
of
macro
‘FOO’
FOO;
^
The reason is that pp_string()
https://github.com/gcc-mirror/gcc/blob/master/gcc/diagnostic.c#L384 counts
control characters (such as the color codes) when deciding whether to wrap
around, however those characters are not normally visible thus they produce a
strange effect. In general, the whole pretty-printer wrapping is oblivious to
the color codes, which is likely to produce excessive wrapping when using
-fmessage-length=.
[Bug c/65120] [gcc5] Wlogical-not-parentheses should not warn about double exclamation !!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65120 --- Comment #1 from Jiri Slaby jirislaby at gmail dot com --- (In reply to Jiri Slaby from comment #0) Better than papering over this as if ((!aa) = b) Pardon me, it should write: if ((!!aa) = b)
[Bug c/65120] [5 Regression] Wlogical-not-parentheses should not warn about double exclamation !!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65120
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-02-19
Known to work||4.9.2
Target Milestone|--- |5.0
Summary|[gcc5] |[5 Regression]
|Wlogical-not-parentheses|Wlogical-not-parentheses
|should not warn about |should not warn about
|double exclamation !! |double exclamation !!
Ever confirmed|0 |1
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
testcase you can compile and which warns with -Wall
int a, b;
int main()
{
if (!!a == b)
return 1;
return 0;
}
[Bug libstdc++/65118] Android target build is broken with guard.cc:36:22: fatal error: syscall.h: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65118 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- That's been there since 2008, why hasn't it caused a problem before now?
[Bug libstdc++/65122] New: std::vector doesn't honor element alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122 Bug ID: 65122 Summary: std::vector doesn't honor element alignment Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: jacob.benoit.1 at gmail dot com Created attachment 34807 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34807action=edit testcase Even in C++11 mode, even with the C++11 alignas keyword, element alignment isn't honored by std::vector. $ g++ vectoralign.cpp -o a --std=c++11 ./a ctor 0x2422010 ctor 0x2422050 Tested with a freshly built GCC 4.9.2 on Ubuntu x86-64. Attaching testcase. Note: this is morphing bug 53900.
[Bug c++/53900] [regression] Too optimistic on a alignment assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53900 Benoit Jacob jacob.benoit.1 at gmail dot com changed: What|Removed |Added CC||jacob.benoit.1 at gmail dot com --- Comment #9 from Benoit Jacob jacob.benoit.1 at gmail dot com --- (In reply to Andrew Pinski from comment #8) It is rather a bug in libstdc++ which should be reported separately though it needs an ABI change to work correctly. Filed bug 65122 for that.
[Bug c/64748] OpenACC: is not a variable error with deviceptr()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64748 Thomas Schwinge tschwinge at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jnorris at gcc dot gnu.org --- Comment #5 from Thomas Schwinge tschwinge at gcc dot gnu.org --- Patch posted by Jim, http://news.gmane.org/find-root.php?message_id=%3C54E23658.6060105%40codesourcery.com%3E.
[Bug middle-end/65074] [5 Regression] r220674 broke C++ PIEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65074 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Henderson rth at gcc dot gnu.org --- Fixed.
[Bug middle-end/65074] [5 Regression] r220674 broke C++ PIEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65074 --- Comment #6 from Richard Henderson rth at gcc dot gnu.org --- Author: rth Date: Thu Feb 19 15:14:24 2015 New Revision: 220816 URL: https://gcc.gnu.org/viewcvs?rev=220816root=gccview=rev Log: PR middle-end/65074 * varasm.c (default_binds_local_p_2): Don't test node-definition; test DECL_EXTERNAL independent of symtab_node. Modified: trunk/gcc/ChangeLog trunk/gcc/varasm.c
[Bug c/65106] C99 intialization of struct with const member through a non-const pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65106 --- Comment #2 from Andrey Riabushenko andrii.riabushenko at barclays dot com --- Thanks Joseph for pointing out relevant standard sections, hence standard does not allow for that. Given that implicit copies of structs with constant members are happening today (pass as argument by value and return value) and some compilers do support it, can we consider this as compiler extension?
[Bug tree-optimization/64365] [4.9 Regression] Predictive commoning after loop vectorization produces incorrect code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.9.3 Resolution|--- |FIXED Target Milestone|5.0 |4.9.3 --- Comment #16 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/64277] [4.9 Regression] Incorrect warning array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277 --- Comment #20 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Feb 19 14:13:16 2015 New Revision: 220815 URL: https://gcc.gnu.org/viewcvs?rev=220815root=gccview=rev Log: 2015-02-19 Richard Biener rguent...@suse.de Backport from mainline 2014-12-09 Richard Biener rguent...@suse.de PR middle-end/64199 * fold-const.c (fold_binary_loc): Use TREE_OVERFLOW_P. * gcc.dg/torture/pr64199.c: New testcase. 2015-01-14 Richard Biener rguent...@suse.de PR tree-optimization/64493 PR tree-optimization/64495 * tree-vect-loop.c (vect_finalize_reduction): For double-reductions assign the proper vectorized PHI to the inner loop exit PHIs. * gcc.dg/vect/pr64493.c: New testcase. * gcc.dg/vect/pr64495.c: Likewise. 2015-01-27 Richard Biener rguent...@suse.de PR tree-optimization/56273 PR tree-optimization/59124 PR tree-optimization/64277 * tree-vrp.c (vrp_finalize): Emit array-bound warnings only from the first VRP pass. * g++.dg/warn/Warray-bounds-6.C: New testcase. * gcc.dg/Warray-bounds-12.c: Likewise. * gcc.dg/Warray-bounds-13.c: Likewise. 2015-02-19 Richard Biener rguent...@suse.de Backport from mainline 2015-01-15 Richard Biener rguent...@suse.de PR middle-end/64365 * tree-data-ref.c (dr_analyze_indices): Make sure that accesses for MEM_REF access functions with the same base can never partially overlap. * gcc.dg/torture/pr64365.c: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/warn/Warray-bounds-6.C branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/Warray-bounds-12.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/Warray-bounds-13.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr64199.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr64365.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/pr64493.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/pr64495.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/fold-const.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-data-ref.c branches/gcc-4_9-branch/gcc/tree-vect-loop.c branches/gcc-4_9-branch/gcc/tree-vrp.c
[Bug tree-optimization/64277] [4.9 Regression] Incorrect warning array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.8.4, 4.9.3 Resolution|--- |FIXED Known to fail||4.9.2 --- Comment #21 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug target/62251] [5 Regression] FAIL: gfortran.dg/quad_2.f90 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62251 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug debug/64935] [5 Regression] compare debug failure during building of Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64935 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: mkuvyrkov Date: Thu Feb 19 08:31:14 2015 New Revision: 220808 URL: https://gcc.gnu.org/viewcvs?rev=220808root=gccview=rev Log: Fix PR64935 * haifa-sched.c (enum rfs_decision, rfs_str): Remove RFS_DEBUG. (rank_for_schedule_debug): Update. (ready_sort): Make static. Move sorting logic to ... (ready_sort_debug, ready_sort_real): New static functions. (schedule_block): Sort both debug insns and real insns in preparation for ready list trimming. Improve debug output. * sched-int.h (ready_sort): Remove global declaration. * gcc.dg/pr64935-1.c, gcc.dg/pr64935-2.c: New tests. Added: trunk/gcc/testsuite/gcc.dg/pr64935-1.c trunk/gcc/testsuite/gcc.dg/pr64935-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/haifa-sched.c trunk/gcc/sched-int.h trunk/gcc/testsuite/ChangeLog
[Bug c/65120] [5 Regression] Wlogical-not-parentheses should not warn about double exclamation !!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65120 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Looks reasonable, I'll take a look.
[Bug debug/46102] [4.8/4.9/5 Regression] ICE: SIGSEGV in dwarf2out_finish (dwarf2out.c:8490) with -feliminate-dwarf2-dups when using precompiled headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46102 --- Comment #10 from Aldy Hernandez aldyh at gcc dot gnu.org --- Created attachment 34806 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34806action=edit proposed patch Proposed patch. I will comment on the list shortly.
[Bug target/64876] Regressions in gcc-testresults for powerpc64 gccgo in 5.0 due to change for static chain for closures (219776)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64876 Peter Bergner bergner at gcc dot gnu.org changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #7 from Peter Bergner bergner at gcc dot gnu.org --- Lynn and Alan, can we mark this as fixed now?
[Bug target/65109] [5 Regression] r220674 causes FAIL: gcc.target/powerpc/ppc64-abi-1.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65109 --- Comment #4 from Martin Sebor msebor at gmail dot com --- There's the following comment in the test: /* Testcase could break on future gcc's, if parameter regs are changed before this asm. */ Moving the locals out of the function lets the test pass. The attached patch eliminates the local copy of the volatile reg_parms_t struct as well as the sp pointer and moves the remaining locals out of all the test functions to minimize the risk of the volatile registers getting clobbered before they are saved.
[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #52 from Martin Jambor jamborm at gcc dot gnu.org ---
So, as you might have guessed from the previous comment, this is the
fix. I should have left the office half an hour ago so I will
properly bootstrap and test and submit it tomorrow, but feel free to
do all of that yourself, if you do not want to wait.
diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 440ced4..3bf068a 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -1451,7 +1451,7 @@ propagate_alignment_accross_jump_function (struct
cgraph_edge *cs,
else
{
src_idx = ipa_get_jf_ancestor_formal_id (jfunc);
- offset = ipa_get_jf_ancestor_offset (jfunc);
+ offset = ipa_get_jf_ancestor_offset (jfunc) / BITS_PER_UNIT;
}
src_lats = ipa_get_parm_lattices (caller_info, src_idx);
[Bug libstdc++/65122] std::vector doesn't honor element alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122 --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org --- IMHO the only sensible solution is in this direction: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3396.htm I hope Clark is still working on this...
[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028 --- Comment #51 from Martin Jambor jamborm at gcc dot gnu.org --- So unless I made some mistake, we are looking a the following chain of calls and aliases main/48071 - _ZN18eonImageCalculatorC1Ev/50391 -alias- _ZN18eonImageCalculatorC2Ev/50390 - -_ZN12ggPhotometerC1ERK10ggSpectrumS2_S2_S2_S2_S2_S2_/49466 -alias-_ZN12ggPhotometerC2ERK10ggSpectrumS2_S2_S2_S2_S2_S2_/49465 - - _ZmlRK10ggSpectrumS1_/46520 with the following jump functions: callsite main/48071 - __comp_ctor /50391 : param 0: UNKNOWN Alignment: 16, misalignment: 0 callsite __base_ctor /50390 - __comp_ctor /49466 : param 0: UNKNOWN Alignment: 16, misalignment: 0 - param 1: ANCESTOR: 0, offset 192 Unknown alignment param 2: ANCESTOR: 0, offset 704 Unknown alignment param 3: ANCESTOR: 0, offset 448 Unknown alignment param 4: UNKNOWN Alignment: 16, misalignment: 0 param 5: UNKNOWN Alignment: 16, misalignment: 0 param 6: UNKNOWN Alignment: 16, misalignment: 0 param 7: UNKNOWN Alignment: 16, misalignment: 0 callsite __base_ctor /49465 - operator*/46520 : param 0: ANCESTOR: 0, offset 1088 Unknown alignment param 1: PASS THROUGH: 1 op nop_expr Unknown alignment from poking at things in the debugger, the offset that is marked down as 192 looks much more like 24 in reality and 24 times 8 is 192... oh boy...
[Bug libstdc++/65124] wstring_convert not recognised as a template class.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65124 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- #include locale
[Bug c++/62204] internal compiler error with -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62204 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-19 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.3 Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed for 4.9, but can't reproduce with 4.8. Trunks seems to be fine, let me see what fixed it...
[Bug testsuite/65116] [4.9/5 Regression] additional_sources not defined anymore during dg-final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65116 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-19 CC||dje at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from David Edelsohn dje at gcc dot gnu.org --- Confirmed on AIX.
[Bug target/65109] [5 Regression] r220674 causes FAIL: gcc.target/powerpc/ppc64-abi-1.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65109 --- Comment #5 from Martin Sebor msebor at gmail dot com --- Created attachment 34809 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34809action=edit Test patch to let it pass.
[Bug c++/62204] internal compiler error with -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62204 --- Comment #1 from David Koes koes at cmu dot edu --- Okay, I figured this out. It is a use after free error. Line numbers are for 4.8.4. The root cause was that I had these two lines in different header files: typedef long int128_t __attribute__((mode(TI))) __attribute__((aligned(8))); typedef long int128_t __attribute__((mode(TI))); The declaration with the alignment was processed by handle_aligned_attribute in c-common.c:7446 where the type was copied and the declartion was set to the type's name: tree tt = TREE_TYPE (decl); *type = build_variant_type_copy (*type); DECL_ORIGINAL_TYPE (decl) = tt; TYPE_NAME (*type) = decl; TREE_USED (*type) = TREE_USED (decl); TREE_TYPE (decl) = *type; Later, in duplicate_decls (decl.c) the aligned declaration is newdecl and the unaligned declaration is olddecl and newdecl is ultimately freed and clobbered, but the pointer set in handle_aligned_attribute is still around. The memory is eventually reallocated and the data overwritten. Later, when instantiating templates, this tree pointer (now pointing to something that isn't a tree) is accessed and the compiler crashes. It's easy enough for me to fix my code to prevent the crash, but I generally think that no code should make the compiler crash. I'm not sure what the standard says (especially since this involves __attribute__), but it seems like declaring the same type with different alignments should probably be an error. If this is not an error, then duplicate_decls either shouldn't merge these two types, or should correct the tree to not refer to the stale pointer.
[Bug libstdc++/65122] std::vector doesn't honor element alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122 --- Comment #8 from Benoit Jacob jacob.benoit.1 at gmail dot com --- If there is a defect in the standard, isn't it in the part that forces the compiler to not use the useful type information that it has, that is, the above-quoted the storage is obtained by calling ::operator new(std::size_t) ?
[Bug libstdc++/65122] std::vector doesn't honor element alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122 --- Comment #9 from Benoit Jacob jacob.benoit.1 at gmail dot com --- s/compiler/standard library
[Bug libstdc++/65122] std::vector doesn't honor element alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122 --- Comment #7 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Benoit Jacob from comment #6) I would still be interested in how you understand 3.11/9 I consider it a defect in the standard, so it needs fixing, not understanding...
[Bug c/65120] [5 Regression] Wlogical-not-parentheses should not warn about double exclamation !!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65120 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34811 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34811action=edit gcc5-pr65120.patch Untested fix.
[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added CC||aldyh at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org --- Comment #7 from Aldy Hernandez aldyh at gcc dot gnu.org --- I'm sure I'll regret it, but... I'll take a look.
[Bug libstdc++/65122] std::vector doesn't honor element alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Benoit Jacob from comment #6) (In reply to Marc Glisse from comment #4) the storage is obtained by calling ::operator new(std::size_t) so we can't use posix_memalign Ouch. That's very unfortunate. I see. I would still be interested in how you understand 3.11/9 and how to reconcile it with that without breaking a lot of software. But ::operator new(std::size_t) could always return memory aligned for the most over-aligned type? Thus our default new implementation could use posix_memalign (..., MIN (size, BIGGEST_ALIGNMENT), size)? If the user provides its own ::new then he is on its own, of course (and doing that and using posix_memalign in it would be a workaround for this issue?!).
[Bug lto/65130] New: ICE with LTO on valid code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65130
Bug ID: 65130
Summary: ICE with LTO on valid code on x86_64-linux-gnu
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk with
LTO on x86_64-linux-gnu in both 32-bit and 64-bit modes.
It is a regression from 4.9.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20150219 (experimental) [trunk revision 220822] (GCC)
$
$ gcc-4.9 -flto -O1 -c foo.c
$ gcc-4.9 -flto -O2 -c main.c
$ gcc-4.9 -flto -O1 foo.o main.o
$ ./a.out
$
$ gcc-trunk -flto -O1 -c foo.c
$ gcc-trunk -flto -O2 -c main.c
$ gcc-trunk -flto -O1 foo.o main.o
gcc-trunk: internal compiler error: Segmentation fault (program lto1)
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
lto-wrapper: fatal error: gcc-trunk returned 4 exit status
compilation terminated.
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
$
$ cat foo.c
extern void fn3 (void);
void fn2(void)
{
fn3();
}
void fn1(void)
{
fn2();
}
void fn4(void)
{
fn2();
}
$ cat main.c
extern void fn1(void);
extern void fn4 (void);
int a;
void fn3(void)
{
for (; a;)
fn4();
}
int main() {
fn1();
return 0;
}
$
[Bug tree-optimization/64530] [4.9 Regression] Incorrect calculation when assigning to array with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64530 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.9.3 Resolution|--- |FIXED --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug rtl-optimization/65123] [5 regression] lra remat places insn which breaks data flow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65123 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ra, wrong-code Priority|P3 |P1 Target Milestone|--- |5.0 Summary|[5.0 regression] lra remat |[5 regression] lra remat |places insn which breaks|places insn which breaks |data flow |data flow
[Bug testsuite/65126] [5 Regresion] additional_sources not defined anymore during dg-final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65126 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-20 Target Milestone|--- |5.0 Summary|additional_sources not |[5 Regresion] |defined anymore during |additional_sources not |dg-final|defined anymore during ||dg-final Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. This is also a regression I think.
[Bug libstdc++/65131] New: Integer overflow in .size() for std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65131
Bug ID: 65131
Summary: Integer overflow in .size() for std::vector
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: fayard at insideloop dot io
Hi,
The .size() method on the std::vectorT might overflow. In the case where:
- The system has a pointer size of 32 bits
- sizeof(T) == 1
- The vector has been created with a size n = 2^31
Then, as this-_M_impl._M_finish - this-_M_impl._M_start does not fit un a
std::ptrdiff_t, this difference has undefined behaviour.
// [23.2.4.2] capacity
/** Returns the number of elements in the %vector. */
size_type
size() const _GLIBCXX_NOEXCEPT
{ return size_type(this-_M_impl._M_finish - this-_M_impl._M_start); }
It turns out that max_size() does not prevent us from creating such an array.
/** Returns the size() of the largest possible %vector. */
size_type
max_size() const _GLIBCXX_NOEXCEPT
{ return _Alloc_traits::max_size(_M_get_Tp_allocator()); }
As I am quite new to C++ so I prefer not to supply a patch. This bug is not
present in libc++ and they solved it this way.
template class _Tp, class _Allocator
typename vector_Tp, _Allocator::size_type
vector_Tp, _Allocator::max_size() const _NOEXCEPT
{
return
_VSTD::minsize_type(__alloc_traits::max_size(this-__alloc()),
numeric_limitssize_type::max() / 2); // end() = begin(), always
}
Best regards,
Francois
[Bug testsuite/65126] [5 Regresion] additional_sources not defined anymore during dg-final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65126 --- Comment #3 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org --- Hi Tom, I can't reproduce this. I'm trying make check-gcc RUNTESTFLAGS=vect.exp on a native x86_64 bootstrap. What is required to trigger this? [FWIW, I see that code handling additional_source has different paths for remote vs local testing, so it might be triggered only with remote testing.]
[Bug debug/58123] [4.8/4.9/5 Regression] debug line not tracked for last autovariable dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58123 --- Comment #10 from asmwarrior asmwarrior at gmail dot com --- (In reply to Jan Kratochvil from comment #8) (In reply to Aldy Hernandez from comment #7) Putting this aside for a second, my question is, do we really want a debugging experience where we jump from back from the end of scope, back to the declaration of the class? I do not think so. I agree with Jan. Jump back to declaration of a variable may be OK for command line debugging, but it is very annoying especially you use an IDE, which means the whole view window get refreshed.
[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #57 from Jan Hubicka hubicka at ucw dot cz ---
Another issue is propagate_constants_accross_call has
for (; (i args_count) (i parms_count); i++)
{
struct ipa_jump_func *jump_func = ipa_get_ith_jump_func (args, i);
struct ipcp_param_lattices *dest_plats;
dest_plats = ipa_get_parm_lattices (callee_info, i);
if (availability == AVAIL_INTERPOSABLE)
ret |= set_all_contains_variable (dest_plats);
else
{
ret |= propagate_scalar_accross_jump_function (cs, jump_func,
dest_plats-itself);
ret |= propagate_context_accross_jump_function (cs, jump_func, i,
dest_plats-ctxlat);
ret |= propagate_alignment_accross_jump_function (cs, jump_func,
dest_plats);
ret |= propagate_aggs_accross_jump_function (cs, jump_func,
dest_plats);
}
}
Even if availability == AVAIL_INTERPOSABLE, alignment from jump_func
is used if the function isn't preempted at run-time. Shouldn't it
call propagate_alignment_accross_jump_function unconditionally?
Well, set_all_contains_variable will simply make every INTERPOSABLE function to
have
all parameters with unknown alignment. This is probably OK because the
function is
externally visible anyway and thus called from there.
I commented on this privately to Martin some time ago. While technically one
can find that the functions if not interposed are used one way or another, but
because we can't clone these functions (we would need to add runtime check
for interposition then), we don't have any use for that anyway.
Martin, I just tested firefox with -march=native -flto -O3 and it still
segfaults
for me at movaps, so it seems that there is still some issue with the code :(
(it happens with or withtout the propagation patch I posted)
Honza
[Bug lto/65130] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65130 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-20 CC||hubicka at gcc dot gnu.org Known to work||4.9.2 Target Milestone|--- |5.0 Summary|ICE with LTO on valid code |[5 Regression] ICE with LTO |on x86_64-linux-gnu |on valid code on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed - segfaults during WPA stage. Program received signal SIGSEGV, Segmentation fault. 0x00a4e987 in inline_edge_summary (edge=0x768d5270) at /space/rguenther/src/svn/trunk/gcc/ipa-inline.h:275 275 return inline_edge_summary_vec[edge-uid]; Missing separate debuginfos, use: zypper install libgmp10-debuginfo-6.0.0-71.1.x86_64 libisl13-debuginfo-0.14-25.2.x86_64 libmpc3-debuginfo-1.0.2-38.2.x86_64 (gdb) bt #0 0x00a4e987 in inline_edge_summary (edge=0x768d5270) at /space/rguenther/src/svn/trunk/gcc/ipa-inline.h:275 #1 0x00a57c4d in estimate_calls_size_and_time ( node=cgraph_node* 0x768dbab8 fn4, size=0x76ac726c, min_size=0x76ac7250, time=0x76ac7268, hints=0x0, possible_truths=4294967294, known_vals=..., known_contexts=..., known_aggs=...) at /space/rguenther/src/svn/trunk/gcc/ipa-inline-analysis.c:3115 ... #1234 0x00a57d62 in estimate_calls_size_and_time ( node=cgraph_node* 0x768dbab8 fn4, size=0x76ac726c, min_size=0x76ac7250, time=0x76ac7268, hints=0x0, possible_truths=4294967294, known_vals=..., known_contexts=..., known_aggs=...) at /space/rguenther/src/svn/trunk/gcc/ipa-inline-analysis.c:3141 (and more)
[Bug target/65128] remove linux and unix from preprocessor macros from cpp-5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65128 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||*-*-linux, *-*-unix, ||*-*-sun Component|preprocessor|target --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- They are indeed legacy defines. More affected systems: dragonfly.h: builtin_define_std (unix); \ freebsd-spec.h: builtin_define_std (unix); \ gnu.h: builtin_define_std (unix);\ kfreebsd-gnu.h: builtin_define_std (unix);\ knetbsd-gnu.h: builtin_define_std (unix);\ kopensolaris-gnu.h: builtin_define_std (unix);\ linux.h:builtin_define_std (linux); \ linux.h:builtin_define_std (unix);\ sol2.h: builtin_define_std (unix);\ sol2.h: builtin_define_std (sun); \
[Bug lto/64373] [4.9 regression] ICE with lto related to variably modified type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64373 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.9.3 Resolution|--- |FIXED Known to fail||4.9.2 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/65063] [4.8 Regression] gcc.dg/vect/vect-double-reduc-6.c FAILs with -O3 -fno-tree-loop-ivcanon -fno-tree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65063 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Feb 20 07:32:08 2015 New Revision: 220835 URL: https://gcc.gnu.org/viewcvs?rev=220835root=gccview=rev Log: 2015-02-20 Richard Biener rguent...@suse.de Backport from mainline 2015-01-12 Richard Biener rguent...@suse.de PR tree-optimization/64530 * tree-loop-distribution.c (pg_add_dependence_edges): Shuffle back dr1. * gfortran.dg/pr64530.f90: New testcase. 2015-02-13 Richard Biener rguent...@suse.de PR lto/64373 * lto-streamer-out.c (tree_is_indexable): Guard for NULL DECL_CONTEXT. * gcc.dg/lto/pr64373_0.c: New testcase. 2015-02-16 Richard Biener rguent...@suse.de PR tree-optimization/63593 * tree-predcom.c (execute_pred_commoning_chain): Delay removing stmts and releasing SSA names until... (execute_pred_commoning): ... after processing all chains. * gcc.dg/pr63593.c: New testcase. 2015-02-18 Richard Biener rguent...@suse.de PR tree-optimization/65063 * tree-predcom.c (determine_unroll_factor): Return 1 if we have replaced looparound PHIs. * gcc.dg/pr65063.c: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/lto/pr64373_0.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr63593.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr65063.c branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/pr64530.f90 Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/lto-streamer-out.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-loop-distribution.c branches/gcc-4_9-branch/gcc/tree-predcom.c
[Bug tree-optimization/63593] ICE: verify_gimple failed: incompatible types in PHI argument 0 with -O3 -fno-tree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63593 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Feb 20 07:32:08 2015 New Revision: 220835 URL: https://gcc.gnu.org/viewcvs?rev=220835root=gccview=rev Log: 2015-02-20 Richard Biener rguent...@suse.de Backport from mainline 2015-01-12 Richard Biener rguent...@suse.de PR tree-optimization/64530 * tree-loop-distribution.c (pg_add_dependence_edges): Shuffle back dr1. * gfortran.dg/pr64530.f90: New testcase. 2015-02-13 Richard Biener rguent...@suse.de PR lto/64373 * lto-streamer-out.c (tree_is_indexable): Guard for NULL DECL_CONTEXT. * gcc.dg/lto/pr64373_0.c: New testcase. 2015-02-16 Richard Biener rguent...@suse.de PR tree-optimization/63593 * tree-predcom.c (execute_pred_commoning_chain): Delay removing stmts and releasing SSA names until... (execute_pred_commoning): ... after processing all chains. * gcc.dg/pr63593.c: New testcase. 2015-02-18 Richard Biener rguent...@suse.de PR tree-optimization/65063 * tree-predcom.c (determine_unroll_factor): Return 1 if we have replaced looparound PHIs. * gcc.dg/pr65063.c: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/lto/pr64373_0.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr63593.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr65063.c branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/pr64530.f90 Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/lto-streamer-out.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-loop-distribution.c branches/gcc-4_9-branch/gcc/tree-predcom.c
[Bug lto/64373] [4.9 regression] ICE with lto related to variably modified type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64373 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Feb 20 07:32:08 2015 New Revision: 220835 URL: https://gcc.gnu.org/viewcvs?rev=220835root=gccview=rev Log: 2015-02-20 Richard Biener rguent...@suse.de Backport from mainline 2015-01-12 Richard Biener rguent...@suse.de PR tree-optimization/64530 * tree-loop-distribution.c (pg_add_dependence_edges): Shuffle back dr1. * gfortran.dg/pr64530.f90: New testcase. 2015-02-13 Richard Biener rguent...@suse.de PR lto/64373 * lto-streamer-out.c (tree_is_indexable): Guard for NULL DECL_CONTEXT. * gcc.dg/lto/pr64373_0.c: New testcase. 2015-02-16 Richard Biener rguent...@suse.de PR tree-optimization/63593 * tree-predcom.c (execute_pred_commoning_chain): Delay removing stmts and releasing SSA names until... (execute_pred_commoning): ... after processing all chains. * gcc.dg/pr63593.c: New testcase. 2015-02-18 Richard Biener rguent...@suse.de PR tree-optimization/65063 * tree-predcom.c (determine_unroll_factor): Return 1 if we have replaced looparound PHIs. * gcc.dg/pr65063.c: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/lto/pr64373_0.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr63593.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr65063.c branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/pr64530.f90 Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/lto-streamer-out.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-loop-distribution.c branches/gcc-4_9-branch/gcc/tree-predcom.c
[Bug tree-optimization/64530] [4.9 Regression] Incorrect calculation when assigning to array with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64530 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Feb 20 07:32:08 2015 New Revision: 220835 URL: https://gcc.gnu.org/viewcvs?rev=220835root=gccview=rev Log: 2015-02-20 Richard Biener rguent...@suse.de Backport from mainline 2015-01-12 Richard Biener rguent...@suse.de PR tree-optimization/64530 * tree-loop-distribution.c (pg_add_dependence_edges): Shuffle back dr1. * gfortran.dg/pr64530.f90: New testcase. 2015-02-13 Richard Biener rguent...@suse.de PR lto/64373 * lto-streamer-out.c (tree_is_indexable): Guard for NULL DECL_CONTEXT. * gcc.dg/lto/pr64373_0.c: New testcase. 2015-02-16 Richard Biener rguent...@suse.de PR tree-optimization/63593 * tree-predcom.c (execute_pred_commoning_chain): Delay removing stmts and releasing SSA names until... (execute_pred_commoning): ... after processing all chains. * gcc.dg/pr63593.c: New testcase. 2015-02-18 Richard Biener rguent...@suse.de PR tree-optimization/65063 * tree-predcom.c (determine_unroll_factor): Return 1 if we have replaced looparound PHIs. * gcc.dg/pr65063.c: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/lto/pr64373_0.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr63593.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr65063.c branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/pr64530.f90 Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/lto-streamer-out.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-loop-distribution.c branches/gcc-4_9-branch/gcc/tree-predcom.c
[Bug tree-optimization/62630] [5 regression] gcc.dg/graphite/vect-pr43423.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630 --- Comment #16 from Mircea Namolaru mircea.namolaru at inria dot fr --- Yes, but it seems to me that the cast (not in the original code) should not be generated at all if it could not be guaranteed that the casted-to type is larger enough to accommodate it. Otherwise you introduce a cast from a longer signed type to a shorter signed one whose behaviour is undefined by the C standard and was not in the original code. So the cast in the following code is problematic (when graphite_IV, a signed long is not in the range of a signed int). _56 = (intD.6) graphite_IV.5_53; _55 = aD.1830[_56]; The solution to fix this is to made Graphite not to generate casts like this. An alternative is to infer the range of graphite_IV like you do and remove the cast (but this seems more complicated and risky as the analysis may not succeed and the problematic cast is not removed).
[Bug c++/65127] New: internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'addr_expr' in parsing_nsdmi, at cp/parser.c:18311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65127
Bug ID: 65127
Summary: internal compiler error: tree check: expected tree
that contains 'decl minimal' structure, have
'addr_expr' in parsing_nsdmi, at cp/parser.c:18311
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lukeallardyce at gmail dot com
void make_item()
{
static int i{100};
struct
{
int id{i++};
} item;
}
int main()
{
make_item0();
}
--
g++ -std=c++11 bug.cpp -c
bug.cpp: In instantiation of 'void make_item() [with int sz = 0]':
bug.cpp:14:16: required from here
bug.cpp:9:5: internal compiler error: tree check: expected tree that contains
'decl minimal' structure, have 'addr_expr' in parsing_nsdmi, at
cp/parser.c:18311
} item;
^
bug.cpp:9:5: internal compiler error: Abort trap: 6
g++: internal compiler error: Abort trap: 6 (program cc1plus)
GCC built from trunk on 2/16
[Bug preprocessor/65128] New: remove linux and unix from preprocessor macros from cpp-5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65128 Bug ID: 65128 Summary: remove linux and unix from preprocessor macros from cpp-5 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: shawn at churchofgit dot com I just spent like a whole hour until I realized that cpp defines linux which gives this confusing error: src/systemctl/bootspec.h:40:15: error: expected identifier or ‘(’ before numeric constant char *linux; ^ We should remove these defines from gcc 5, and force programs to check __unix__ and __linux__
[Bug c++/65127] internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'addr_expr' in parsing_nsdmi, at cp/parser.c:18311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65127 --- Comment #1 from Luke Allardyce lukeallardyce at gmail dot com --- Sorry, make_item() should be templateint sz make_item()
[Bug target/65121] [5 regression] long_call attribute broken weak symbol arm*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65121 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Target|arm-none-eabi |arm* Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-19 CC||ramana at gcc dot gnu.org Component|regression |target Summary|long_call attribute broken |[5 regression] long_call |weak symbol arm_none_eabi |attribute broken weak ||symbol arm* Ever confirmed|0 |1 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- I'd expect this to fail on arm-none-linux-gnueabi(hf) too. Confirmed.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #25 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #24) (In reply to Harald Anlauf from comment #22) count_rate(8),count_max(1) =0 127 OK, but the last line looks strange: lacking documentation, I'd expect the rate to be 1, not 0. (Not that I'd use that in real code...). Yes, tha last one is wrong. I will look into it. I found the problem and have it fixed. I am traveling today so will not be able to upload a patch until tomorrow or the next day.
[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #50 from Martin Jambor jamborm at gcc dot gnu.org --- Finally, I have managed to reproduce the problem locally and am looking into it.
[Bug libstdc++/65122] std::vector doesn't honor element alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122 --- Comment #1 from Benoit Jacob jacob.benoit.1 at gmail dot com --- Homologous libc++ bug report: http://llvm.org/bugs/show_bug.cgi?id=22634
[Bug target/65109] [5 Regression] r220674 causes FAIL: gcc.target/powerpc/ppc64-abi-1.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65109 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-02-19 Assignee|unassigned at gcc dot gnu.org |rth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Henderson rth at gcc dot gnu.org --- Mine.
[Bug middle-end/65074] [5 Regression] r220674 broke C++ PIEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65074 --- Comment #7 from Richard Henderson rth at gcc dot gnu.org --- Author: rth Date: Thu Feb 19 15:48:50 2015 New Revision: 220817 URL: https://gcc.gnu.org/viewcvs?rev=220817root=gccview=rev Log: PR middle-end/65074 * g++.dg/opt/pr65074.C: New file. Added: trunk/gcc/testsuite/g++.dg/opt/pr65074.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/64317] [5 Regression] Ineffective allocation of PIC base register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64317
--- Comment #13 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
(In reply to Jeffrey A. Law from comment #12)
One of the things I notice is that LRA is generating sequences like:
(insn 581 89 90 6 (set (reg:SI 3 bx [107])
(mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 28 [0x1c])) [4 %sfp+-4 S4 A32])) j.c:19 90
{*movsi_internal}
(nil))
(insn 90 581 91 6 (set (reg/f:SI 3 bx [orig:142 D.2145 ] [142])
(mem/f/c:SI (plus:SI (reg:SI 3 bx [107])
(const:SI (unspec:SI [
(symbol_ref:SI (out) [flags 0x2] var_decl
0x7670bc60 out)
] UNSPEC_GOTOFF))) [1 out+0 S4 A32])) j.c:19 90
{*movsi_internal}
(nil))
Note how we load %ebx from memory, then use/clobber it in the next insn.
That makes it impossible for the post-reload optimizers to help clean this
up. How hard would it be to generate code in LRA where those two insns set
different registers in those local snippets of code?
In this particular case, %ebp is locally available and there's no strong
reason why we have to use %ebx. By using different destinations for insns
581 and 90, the source MEM of insn 581 would be available after insn 90.
And by making the value available postreload-gcse would be able to commonize
those loads.
Jeff, thanks for the analysis. PIC pseudo really can be in different regs.
There are a lot of places in RA in what reg the pic pseudo will be placed for
particular live range. Probably there is a place where the decision is done
for ebx without considering other alternatives. I'll investigate this problem.
[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028 --- Comment #49 from Markus Trippelsdorf trippels at gcc dot gnu.org --- The same issue also happen when I build Firefox on my amdfam10 testbox. With -flto -march=native Firefox crashes: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff9a5fe700 (LWP 4779)] 0x7567b5cb in js::gc::ArenaCellIterImpl::reset(js::gc::ArenaHeader*) () from /var/tmp/moz-build-dir/dist/bin/libxul.so (gdb) bt #0 0x7567b5cb in js::gc::ArenaCellIterImpl::reset(js::gc::ArenaHeader*) () from /var/tmp/moz-build-dir/dist/bin/libxul.so #1 0x75ae9eff in JS::Zone::discardJitCode(js::FreeOp*) [clone .part.593] [clone .lto_priv.66751] () from /var/tmp/moz-build-dir/dist/bin/libxul.so #2 0x75c2bb1d in js::gc::GCRuntime::updatePointersToRelocatedCells() () from /var/tmp/moz-build-dir/dist/bin/libxul.so #3 0x75c36a3b in js::gc::GCRuntime::incrementalCollectSlice(js::SliceBudget, JS::gcreason::Reason) () from /var/tmp/moz-build-dir/dist/bin/libxul.so #4 0x75c37bb6 in js::gc::GCRuntime::gcCycle(bool, js::SliceBudget, JS::gcreason::Reason) () from /var/tmp/moz-build-dir/dist/bin/libxul.so #5 0x75c381e6 in js::gc::GCRuntime::collect(bool, js::SliceBudget, JS::gcreason::Reason) () from /var/tmp/moz-build-dir/dist/bin/libxul.so #6 0x75258f60 in (anonymous namespace)::GarbageCollectRunnable::WorkerRun(JSContext*, mozilla::dom::workers::WorkerPrivate*) () from /var/tmp/moz-build-dir/dist/bin/libxul.so #7 0x752a4762 in mozilla::dom::workers::WorkerRunnable::Run() () from /var/tmp/moz-build-dir/dist/bin/libxul.so #8 0x75ead433 in mozilla::dom::workers::WorkerPrivate::ProcessAllControlRunnablesLocked() [clone .constprop.26404] () from /var/tmp/moz-build-dir/dist/bin/libxul.so #9 0x75137dfc in (anonymous namespace)::WorkerThreadPrimaryRunnable::Run() [clone .lto_priv.60874] () from /var/tmp/moz-build-dir/dist/bin/libxul.so #10 0x742f651a in nsThread::ProcessNextEvent(bool, bool*) () from /var/tmp/moz-build-dir/dist/bin/libxul.so #11 0x7642c0f9 in NS_ProcessNextEvent(nsIThread*, bool) [clone .constprop.47437] () from /var/tmp/moz-build-dir/dist/bin/libxul.so #12 0x743aeec5 in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) () from /var/tmp/moz-build-dir/dist/bin/libxul.so #13 0x74346798 in nsThread::ThreadFunc(void*) () from /var/tmp/moz-build-dir/dist/bin/libxul.so #14 0x73128b5c in _pt_root () from /usr/lib/libnspr4.so #15 0x77bc53e6 in start_thread () from /lib/libpthread.so.0 #16 0x774a06cd in clone () from /lib/libc.so.6 Using -flto -fno-ipa-cp-alignment -march=native fixes the problem.
[Bug libstdc++/65124] New: wstring_convert not recognised as a template class.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65124
Bug ID: 65124
Summary: wstring_convert not recognised as a template class.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
the following code snippet:
#include codecvt
namespace lldb_private {
class Editline
{
private:
std::wstring_convertstd::codecvt_utf8wchar_t m_utf8conv;
};
}
g++ -std=c++11 -S
gives:
wstring-convert.cpp:8:11: error: ‘wstring_convert’ in namespace ‘std’ does not
name a template type
std::wstring_convertstd::codecvt_utf8wchar_t m_utf8conv;
on both linux and darwin.
[Bug target/65109] [5 Regression] r220674 causes FAIL: gcc.target/powerpc/ppc64-abi-1.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65109 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Priority|P1 |P2 Status|ASSIGNED|NEW --- Comment #2 from Richard Henderson rth at gcc dot gnu.org --- The testcase is simply buggy. The beginning of fididisdsid contains a volatile asm (inside save_parms), which is assumed to be scheduled immediately after the prologue. Except that didn't happen, and there's nothing in the testcase to make sure that it must happen. .L.fididisdsid: mflr 0 std 31,-8(1) std 30,-16(1) std 0,16(1) stdu 1,-144(1) mr 31,1 std 9,112(31) -- s.dd spilled to stack ld 6,264(31) -- load t.a ld 9,256(31) -- load t.dd ori 2,2,0 lfd 0,112(31) #APP # 294 z.c 1-- Start of save_parms ld 11,gparms@got(2) I have no idea why the compiler should choose to spill s.dd in favor of t.dd, but certainly it is within it's rights to do so. In my opinion, this sort of testing can only be done via dedicated assembly entry points, and not asm within the function body. Not mine, and not P1 either.
