[Bug libgcc/68082] issue on 64 bit shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68082 --- Comment #7 from angelo --- Hi Andrew, it is passed some time, i solved mainly the issue with a workaround. Yes i tested several binutils even last, but is more a matter of compiling the m68k/coldfire toolchain properly. Mainly, building if i build the toolchain for m68k with default flags, only m68000 default code is added in gcc multilibs (and it is used later when i buil m68k apps with 64 bit shift). While, if i try to to build with flags for coldfire (--with-arch=cf) this breaks the compilation, i should have reported some other error about here in bugtracking. My workaround was to copy libgcc.a and coldfire subfolder from another older working toolchain. Regards angelo
[Bug target/71776] relocation truncated to fit: R_ARM_THM_JUMP11 against symbol `__gnu_h2f_internal'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71776 malithyapa at gmail dot com changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug target/71776] relocation truncated to fit: R_ARM_THM_JUMP11 against symbol `__gnu_h2f_internal'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71776 malithyapa at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from malithyapa at gmail dot com --- The problem was in fact with linking both libm and libgcc with --whole-archive and --allow-multiple-definitions options. Which makes the linker link to a duplicate function in the other library than the one its linking from since it'll link to the first one it finds. In thumb mode the offset to the other library would be two large for the instruction. Even though it'll be nice if gcc links to the closest symbol rather than the first one, this is documented behavior and it's not a bug.
[Bug tree-optimization/77550] [6/7 Regression] std::deque with -O3 has infinite std::distance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550 --- Comment #14 from Markus Trippelsdorf --- The reduced testcase needs libstdc++.so from trunk. Otherwise you'll get undefined reference errors to _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_ .
[Bug tree-optimization/77550] [6/7 Regression] std::deque with -O3 has infinite std::distance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550 --- Comment #13 from Markus Trippelsdorf --- Created attachment 39606 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39606&action=edit somewhat reduced testcase
[Bug libstdc++/77528] std::queue default constructor unnecessarily creates temporary of underlying Container
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77528 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #2 from TC --- This makes the default constructor implicit, though that's probably how it should be anyway.
[Bug libstdc++/60348] -static-libstdc++ broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 Andrew Pinski changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #18 from Andrew Pinski --- Invalid as the gcc you just compiled is that version of glibc and that version of glibc support unique objects.
[Bug rtl-optimization/67856] callee-saved register saves should be shrink-wrapped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67856 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization CC||pinskia at gcc dot gnu.org Severity|normal |enhancement
[Bug target/67750] undefined local label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67750 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #5 from Andrew Pinski --- 4.9.x is no longer supported so closing as fixed.
[Bug libgcc/64598] var-tracking.c has internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64598 Andrew Pinski changed: What|Removed |Added Target||i586-scc-linux-gnu Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #11 from Andrew Pinski --- Not enough information on how to reproduce this bug even when asked so closing as invalid.
[Bug rtl-optimization/59857] 4.8.2 loop optimization is worse than 4.5.1 under ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59857 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- volatile performance is known to be not as good otherwise. Basically volatile is a huge hammer to GCC and this won't be fixed any time soon.
[Bug sanitizer/61314] Building GCC 4.9.0 breaks in libbacktrace on Ubuntu Lucid and Precise using libfaketime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61314 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Andrew Pinski --- Works in later versions of Ubuntu for sure. Sounds like timestamps are not working correctly for make :).
[Bug other/59862] Code does not compile with 4.8.1 tarball release but compiles with 4.8.1 SVN release
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59862 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #8 from Andrew Pinski --- Works for many other people so closing.
[Bug target/45102] mm/page-writeback.c:820: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45102 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #9 from Andrew Pinski --- No feedback in over 6 months (really 6 years). So closing.
[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #15 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to Eric Gallager from comment #6)
> > This should probably depend on the -fstrict-enums flag, as that controls
> > whether enums can have any value or just those values that are enumerated.
>
> No, that's not what it does.
>
> It tells the compiler the enum will only be one of the values of the
> enumeration, which is not the same as the values corresponding to
> enumerators.
>
That's a confusing distinction; they sound like the same thing at first to
someone like me who doesn't speak standards-ese...
>
> As I said in comment 3, the OP's type has the values of int, because it has
> an underlying type of int.
>
> Given enum E { E1 = 1, E3 = 3 } the values of the type are 0, 1, 2 and 3 and
> -fstrict-enums tells the compiler it will never have a value outside that
> range. It does **not** tell it that the type will never have the value 0 or
> 2.
Thanks, that example helps clear things up. Could it be added to the
documentation for -fstrict-enums?
[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479 --- Comment #14 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #9) > In summary, neither adding 'default' or 'return' are recommended to silence > this warning if you think the warning is wrong. If you think the warning > will always be wrong, use __builtin_unreachable(). If you think it is wrong > now, but you would like to notice if it stops being wrong, then use > assert(false). This is probably an issue for a separate bug, but speaking of __builtin_unreachable(), now that GCC is going to start recognizing the lint-style comment of: /* FALLTHROUGH */ for the benefit of -Wimplicit-fallthrough, could it also start recognizing the lint-style comment of: /* NOTREACHED */ as a synonym for __builtin_unreachable()? I've seen comments like that in a lot of code, actually, and it'd be a more portable solution than __builtin_unreachable().
[Bug libstdc++/67807] [5/6/7 Regression] call to public member function catalog failed on Linux -std=c++03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67807 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |5.5
[Bug tree-optimization/77550] [6/7 Regression] std::deque with -O3 has infinite std::distance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |6.3
[Bug middle-end/77546] [6/7 regression] C++ software renderer performance drop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77546 Andrew Pinski changed: What|Removed |Added Status|WAITING |UNCONFIRMED Target Milestone|--- |6.3 Summary|[6 regression] C++ software |[6/7 regression] C++ |renderer performance drop |software renderer ||performance drop Ever confirmed|1 |0
[Bug middle-end/77558] [6/7 regression] c-c++-common/va-arg-va-list-type.c fails for arm/aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77558 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.3
[Bug rtl-optimization/77541] [7 Regression] wrong code with 512bit vectors of int128 @ -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77541 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |7.0
[Bug c++/77545] [7 Regression] ICE on valid C++11 code: in potential_constant_expression_1, at cp/constexpr.c:5480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77545 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |7.0
[Bug target/77527] [7 Regression] ICE: in make_decl_rtl, at varasm.c:1311 with -mstringop-strategy=libcall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77527 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |7.0
[Bug fortran/77518] [5/6/7 Regression] ICE in gfc_advance_chain, at fortran/trans.c:58
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77518 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |5.5
[Bug target/77526] [7 Regression] ICE: in verify_dominators, at dominance.c:1039 with -mstringop-strategy=byte_loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77526 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |7.0
[Bug tree-optimization/77514] [6/7 Regression] ICE in VN_INFO_GET, at tree-ssa-sccvn.c:406 w/ -O2 (and above)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77514 Andrew Pinski changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code --- Comment #3 from Andrew Pinski --- (In reply to Markus Trippelsdorf from comment #2) > On the other hand: l0 += (*rs ^ (l0 &= 1)); > looks like undefined behavior. undefined code at runtime is still "valid" code.
[Bug tree-optimization/77514] [6/7 Regression] ICE in VN_INFO_GET, at tree-ssa-sccvn.c:406 w/ -O2 (and above)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77514 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.3
[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |6.3 Summary|Static branch predictor |[6/7 Regression] Static |causes ~6-8% regression of |branch predictor causes |SPEC2000 GAP|~6-8% regression of ||SPEC2000 GAP
[Bug fortran/77371] [6/7 Regression] ICE in force_constant_size, at gimplify.c:671 (... and others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77371 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.3
[Bug fortran/72832] [6/7 Regression] [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72832 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.3
[Bug lto/69188] [5/6/7 Regression] ICE when linking objects at different optimization levels with LTO and profile generation enabled. (Works with 4.9.3.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69188 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |5.5 Summary|[Regression 5/6/7] ICE when |[5/6/7 Regression] ICE when |linking objects at |linking objects at |different optimization |different optimization |levels with LTO and profile |levels with LTO and profile |generation enabled. (Works |generation enabled. (Works |with 4.9.3.)|with 4.9.3.)
[Bug target/72717] [5/6/7 Regression] ICE: in emit_move_insn, at expr.c:3693 with vector shift @ powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72717 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |5.5
[Bug c++/71912] [6/7 regression] flexible array in struct in union rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71912 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.3
[Bug c++/77562] large amount of memory usage when allocating big arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77562 --- Comment #6 from programmerjake at gmail dot com --- (In reply to Andrew Pinski from comment #5) > Note I suspect this is due to "long a = 1;" being treated as a constexpr > something like that now. it is. In the original code I had, S has a constexpr default constructor.
[Bug bootstrap/60633] When boostrapping 4.8.2 cc1 crashes with memory allocation problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60633 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Andrew Pinski --- 4.2.3 is no longer supported. You should get a new binary build of GCC and try building a newer version from that.
[Bug tree-optimization/67242] Missing optimization with float IV in SCEV-CCP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67242 --- Comment #4 from Andrew Pinski --- There might be a dup of this one already.
[Bug tree-optimization/67731] Combine of OR'ed bitfields should use bit-test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67731 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Component|rtl-optimization|tree-optimization Severity|normal |enhancement
[Bug target/67751] redundant zero extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67751 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug tree-optimization/77550] [6/7 Regression] std::deque with -O3 has infinite std::distance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550
--- Comment #12 from Bernd Edlinger ---
(In reply to Markus Trippelsdorf from comment #11)
> (In reply to Bernd Edlinger from comment #9)
> > I'm unable to reduce the test case...
>
> Creduce is running and hopefully I will have a small testcase tomorrow
> morning.
>
>
good luck.
here is a hacky patch, test case passes, but I don't know
if it is going design-wise in the right direction:
--- tree-vect-stmts.c 2016-09-11 19:53:01.841182370 +0200
+++ tree-vect-stmts.c 2016-09-11 19:34:15.691171637 +0200
@@ -5482,6 +5483,7 @@
gimple *new_stmt;
int vf;
vec_load_store_type vls_type;
+ bool alias_p = false;
if (!STMT_VINFO_RELEVANT_P (stmt_info) && !bb_vinfo)
return false;
@@ -5740,6 +5742,16 @@
first_stmt = GROUP_FIRST_ELEMENT (stmt_info);
first_dr = STMT_VINFO_DATA_REF (vinfo_for_stmt (first_stmt));
group_size = GROUP_SIZE (vinfo_for_stmt (first_stmt));
+ next_stmt = GROUP_NEXT_ELEMENT (vinfo_for_stmt (first_stmt));
+ for (i = 1; i < group_size; i++)
+ {
+ struct data_reference *next_dr
+ = STMT_VINFO_DATA_REF (vinfo_for_stmt (next_stmt));
+ if (get_alias_set (DR_REF (first_dr))
+ != get_alias_set (DR_REF (next_dr)))
+ alias_p = true;
+ next_stmt = GROUP_NEXT_ELEMENT (vinfo_for_stmt (next_stmt));
+ }
GROUP_STORE_COUNT (vinfo_for_stmt (first_stmt))++;
@@ -6174,8 +6188,10 @@
dataref_ptr,
dataref_offset
? dataref_offset
- : build_int_cst (reference_alias_ptr_type
- (DR_REF (first_dr)),
0));
+ : build_int_cst (alias_p
+ ? ptr_type_node
+ :
reference_alias_ptr_type
+(DR_REF (first_dr)),
0));
align = TYPE_ALIGN_UNIT (vectype);
if (aligned_access_p (first_dr))
misalign = 0;
[Bug tree-optimization/77550] [6/7 Regression] std::deque with -O3 has infinite std::distance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550 --- Comment #11 from Markus Trippelsdorf --- (In reply to Bernd Edlinger from comment #9) > I'm unable to reduce the test case... Creduce is running and hopefully I will have a small testcase tomorrow morning. trippels@gcc2-power8 ~ % cat check.sh #!/bin/sh ulimit -t 2 clang++ -Wall -Werror -std=c++14 -O3 -fsanitize=undefined test.ii if ! test $? = 0; then exit 1 fi ./a.out 2>&1 | grep "runtime error" if test $? = 0; then exit 1 fi ./a.out if ! test $? = 0; then exit 1 fi ~/gcc_5/usr/local/bin/g++ -std=c++14 -O3 test.ii -w -Wfatal-errors if ! test $? = 0; then exit 1 fi ./a.out if ! test $? = 0; then exit 1 fi g++ -O2 test.ii -w -Wfatal-errors if ! test $? = 0; then exir 1 fi valgrind -q --error-exitcode=1 ./a.out if ! test $? = 0; then exit 1 fi g++ -O3 test.ii -w -Wfatal-errors if ! test $? = 0; then exit 1 fi ./a.out if ! test $? = 137; then exit 1 fi
[Bug c++/77562] large amount of memory usage when allocating big arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77562 --- Comment #5 from Andrew Pinski --- Note I suspect this is due to "long a = 1;" being treated as a constexpr something like that now.
[Bug c++/68203] Аbout infinite compilation time on struct with nested array of pairs with -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68203 Andrew Pinski changed: What|Removed |Added CC||programmerjake at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 77562 has been marked as a duplicate of this bug. ***
[Bug c++/77562] large amount of memory usage when allocating big arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77562 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- (In reply to programmerjake from comment #3) > I would think that unrolling loops would be best left till after > gimplification. I agree, but it is a dup of bug 68203 and maybe more ... *** This bug has been marked as a duplicate of bug 68203 ***
[Bug target/77468] [7 Regression] C-ray regression on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77468 --- Comment #7 from PeteVine --- $ gcc $CFLAGS -o c-ray-mt c-ray-mt.c -lm -lpthread && ./c-ray-mt -t 32 -s 160x120 -r 8 -i sphfract -o output.ppm -mcpu=cortex-a53 : Rendering took: 2 seconds (1958 milliseconds) -mcpu=cortex-a73 : Rendering took: 2 seconds (1867 milliseconds) Reproducing the difference and restoring the optimal performance. But we're not targeting a Cortex A73.
[Bug tree-optimization/24021] VRP does not work with floating points
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #2 from Manuel López-Ibáñez --- Could this be a summer of code project? Numerically intensive programs should benefit tremendously, shouldn't they?
[Bug c++/77562] large amount of memory usage when allocating big arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77562 --- Comment #3 from programmerjake at gmail dot com --- I would think that unrolling loops would be best left till after gimplification.
[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479 --- Comment #13 from Manuel López-Ibáñez --- (In reply to DB from comment #10) > Yeah, I've since thought of using abort(), which as you say, silences the > warning - and indicates with sufficient strength that this shouldn't happen. > assert() isn't much use since the warning would return as soon I compile in > release mode... been there, tried that. :) You can write your own "verify()" function that works like assert() but it will still be there in release mode. I think gnulib has something like that. The important bit is that it is declared noreturn. > I don't see why it gives "even more licence" to optimise, though, since it'd > be conditional per enum, rather than -fstrict-enums, which applies > globally... so if anyone inadvertently invokes UB, they've got much more > chance of being caught out if they're using the existing global option, than > if there was a per-enum attribute for whether or not the value must be a > named enumerator. For example, if you add a check that the enum is inside its range, the compiler with -fstrict-enums has every right to delete it, even if the enum is actually outside its range (due to a bug). And the compiler may not warn because it may not be able to prove that it is used outside its range at the point it gives the warning. Things only become more complex and unpredictable if each enum can be behave differently.
[Bug c++/77562] large amount of memory usage when allocating big arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77562 Andrew Pinski changed: What|Removed |Added Keywords||memory-hog --- Comment #2 from Andrew Pinski --- I have seen this bug even in 4.7 and before so I don't think it is new.
[Bug c++/77562] large amount of memory usage when allocating big arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77562 --- Comment #1 from Andrew Pinski --- There is a dup of this bug somewhere already. Basically the front-end decides it is going to "unroll" the loop for the constructors.
[Bug middle-end/67739] name clash between builtin functions and local variables when optimization is on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67739 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic, wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-09-11 Component|c++ |middle-end Ever confirmed|0 |1 Severity|major |normal --- Comment #5 from Andrew Pinski --- (In reply to Milan Durovic from comment #4) > But the core problem is still there: the compiler generates a call to a > method whose name clashes with a local variable and no indication of this > happening is given at all. Cgraph could figure this out slightly and rename sincosf variable to sincosf.0 but this would need to happen after each time an optimization that would optimize into a new function. But it might do the incorrect thing in some cases
[Bug c++/77562] New: large amount of memory usage when allocating big arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77562
Bug ID: 77562
Summary: large amount of memory usage when allocating big
arrays
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: programmerjake at gmail dot com
Target Milestone: ---
when using gcc 5+, compiling the following code uses a huge amount of memory
creating a read-only template object. On gcc 4.9 and before, it does the
expected thing, filling the array in a loop without a source object that it's
copying from.
code:
struct S
{
long a = 1;
};
template
struct A
{
T value[N];
};
void *fn()
{
return new A, 400>, 400>;
}
[Bug bootstrap/68048] Unable to compile ./host-x86_64-pc-linux-gnu/gcc/version.c! Can't pass preprocessor strings!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68048 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- No feedback in more than 9 months so closing.
[Bug rtl-optimization/68086] Expression explicitly defined outside the loop is moved inside the loop by the optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68086 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement --- Comment #2 from Andrew Pinski --- This is most likely IV opts messing up. This might already be fixed for 6.2.0, I don't have a x86_64 build of a newer gcc right now.
[Bug libgcc/68082] issue on 64 bit shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68082 Andrew Pinski changed: What|Removed |Added Target|m68k|m68k-linux --- Comment #6 from Andrew Pinski --- What binutils version are you using? Have you tried a newer version of binutils first?
[Bug tree-optimization/68097] We should track ranges for floating-point values too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097 Andrew Pinski changed: What|Removed |Added Depends on||24021 --- Comment #5 from Andrew Pinski --- Bug 24021 really. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021 [Bug 24021] VRP does not work with floating points
[Bug tree-optimization/77550] [6/7 Regression] std::deque with -O3 has infinite std::distance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550 Andrew Pinski changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #10 from Andrew Pinski --- (In reply to Bernd Edlinger from comment #9) > I'm unable to reduce the test case... > > > The deque_iterator has these members: > > _Elt_pointer _M_cur; > _Elt_pointer _M_first; > _Elt_pointer _M_last; > _Map_pointer _M_node; > > the first 3 elements have alias set 12 > while _M_node has alias set 13. > > when all 4 elements are assigned that becomes > 2 vector statements, but all use alias set 12. The vector stores should have become the aliasing set of the struct instead as suggested on the store widening patch.
[Bug tree-optimization/77550] [6/7 Regression] std::deque with -O3 has infinite std::distance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550 Bernd Edlinger changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #9 from Bernd Edlinger --- I'm unable to reduce the test case... The deque_iterator has these members: _Elt_pointer _M_cur; _Elt_pointer _M_first; _Elt_pointer _M_last; _Map_pointer _M_node; the first 3 elements have alias set 12 while _M_node has alias set 13. when all 4 elements are assigned that becomes 2 vector statements, but all use alias set 12. but _M_node is read back in the loop using alias set 13. and thus it seems _M_node is constant. It can be seen first in expand. _M_node is read without non-vectorized: (insn 290 289 291 44 (set (reg/f:DI 117 [ prephitmp_166 ]) (mem/f/c:DI (plus:DI (reg/f:DI 82 virtual-stack-vars) (const_int -176 [0xff50])) [12 MEM[(struct _Deque_iterator *)&D.66017]._M_last+0 S8 A128])) -1 (nil)) (insn 291 290 292 44 (set (reg/f:DI 149 [ _215 ]) (mem/f/c:DI (plus:DI (reg/f:DI 82 virtual-stack-vars) (const_int -168 [0xff58])) [13 MEM[(struct _Deque_iterator *)&D.66017]._M_node+0 S8 A64])) /var/tmp/gcc_test/usr/local/include/c++/7.0.0/bits/stl_deque.h:173 -1 (nil)) _M_node is written using _M_last's alias set in insn 307: (insn 305 304 306 46 (set (mem/c:V2DI (plus:DI (reg/f:DI 82 virtual-stack-vars) (const_int -192 [0xff40])) [12 MEM[(struct Foo * *)&D.66017]+0 S16 A128]) (reg:V2DI 237)) /var/tmp/gcc_test/usr/local/include/c++/7.0.0/bits/stl_deque.h:174 -1 (nil)) (insn 306 305 307 46 (set (reg:V2DI 238) (vec_concat:V2DI (reg/f:DI 117 [ prephitmp_166 ]) (reg:DI 90 [ _25 ]))) /var/tmp/gcc_test/usr/local/include/c++/7.0.0/bits/stl_deque.h:258 -1 (nil)) (insn 307 306 308 46 (set (mem/c:V2DI (plus:DI (reg/f:DI 82 virtual-stack-vars) (const_int -176 [0xff50])) [12 MEM[(struct Foo * *)&D.66017 + 16B]+0 S16 A128]) (reg:V2DI 238)) /var/tmp/gcc_test/usr/local/include/c++/7.0.0/bits/stl_deque.h:174 -1 (nil))
[Bug target/77530] optimization prevents excess precision from being removed with x86/amd64 long double and rounding to 53 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77530 --- Comment #4 from Vincent Lefèvre --- Note that the current behavior should be correct on NetBSD 7. But it isn't on NetBSD 5.1 and 6.
[Bug middle-end/77546] [6 regression] C++ software renderer performance drop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77546 --- Comment #5 from PeteVine --- ARMv7 for example is not affected, on the contrary, GCC6 posts a very small improvement (29.2 vs 29.0). Back on aarch64, however, GCC7 is able to get some of the lost performance back @ 37 avg. A clue?
[Bug lto/77511] internal compiler error: in get_ptr_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77511 Andrew Pinski changed: What|Removed |Added Target||x86_64-w64-mingw32 Status|UNCONFIRMED |WAITING Last reconfirmed||2016-09-11 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- .
[Bug lto/77511] internal compiler error: in get_ptr_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77511 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Component|c |lto Summary|libbacktrace could not find |internal compiler error: in |executable to open |get_ptr_info --- Comment #1 from Andrew Pinski --- Can you attach the preprocessed source? Please read https://gcc.gnu.org/bugs/ for more information on what we need from you here really.
[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #12 from DB ---
(In reply to Jonathan Wakely from comment #11)
> Given enum E { E1 = 1, E3 = 3 } the values of the type are 0, 1, 2 and 3 and
> -fstrict-enums tells the compiler it will never have a value outside that
> range. It does **not** tell it that the type will never have the value 0 or
> 2.
Huh. So allows non-named values and only enforces min/max, so doesn't account
for folk doing bitwise ORing? Seems a little like the worst of both worlds. ;)
Thanks for the info anyway.
[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #11 from Jonathan Wakely ---
(In reply to Eric Gallager from comment #6)
> This should probably depend on the -fstrict-enums flag, as that controls
> whether enums can have any value or just those values that are enumerated.
No, that's not what it does.
It tells the compiler the enum will only be one of the values of the
enumeration, which is not the same as the values corresponding to enumerators.
As I said in comment 3, the OP's type has the values of int, because it has an
underlying type of int.
Given enum E { E1 = 1, E3 = 3 } the values of the type are 0, 1, 2 and 3 and
-fstrict-enums tells the compiler it will never have a value outside that
range. It does **not** tell it that the type will never have the value 0 or 2.
[Bug c++/77561] Unclear diagnostic for invalid declaration of partial specialization as friend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77561 --- Comment #1 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #0) > The user is not trying to declare a specialization, they're trying to define > a friend. The error should tell them that is allowed, Oops, should tell them that is **not** allowed.
[Bug c/71199] Support overloadable attribute in GNU C front-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71199 --- Comment #8 from Yu Xuanchi --- I have test extern "C" in clang. Look like clang dose not actually mangled it to "C format". I think because clang C front-end actually not have any mangle logic. So it just mangled it like CPP front-end does.
[Bug c++/77557] gcc doesn't warn about code (clang does), __PRETTY_FUNCTION__ used in struct in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77557
--- Comment #4 from Martin ---
(In reply to Jonathan Wakely from comment #3)
> N.B. for clang 3.9 the program prints "top level" not the constructor name.
And for __func_ clang 3.9 has has an empty string. Which makes me think clang
3.9 moves the struct to the outside of the function. Which might be good or
bad. __func__ is in the standard, what does the standard say about the proper
scope of __func__ in getter():s(__func__){}.
gcc behaves as if getter was rewritten to
getter() {
s=__func__;
static const char __func__[] = "...";
}
clang 3.8 behaves as if
getter() {
static const char __func__[] = "...";
s=__func__;
}
and clang 3.9 as if the getter inherited __func__ and ___PRETTY_FUNCTION__ from
a different scope.
getter() {
s=__func__;
static const char __func__[] = "...";
}
So, clang 3.9 is doing something like gcc about the order, with something weird
about the scope.
> __PRETTY_FUNCTION__ is a non-standard extension so the standard says nothing
> about how it works. The similar function-local predefined variable __func__
> is standard, and is usable in ctor-init-lists, e.g. this should get the name
> of the constructor:
> I don't see anything in the standard saying the predefined variable __func__
> is not usable in nested classes defined in the block scope where the
> variable is defined.
Yes, it's non-standard, you're right, slipped my mind, but __func__ is
standard, and the two customarily behave alike. And my tests show that they do
behave alike. So the bug could just as well be about __func__. Both behave
differently between compilers. If the standard really doesn't specify, IMHO my
previous comments apply, this is not right, the program should give the same
result regardless of clang, gcc, msvc, or whatever.
[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479 --- Comment #10 from DB --- (In reply to Manuel López-Ibáñez from comment #8) Thanks for the thoughts! > Those "artificial kludges" not only silence the warning, but also make the > code more readable and help the optimizer. A call to abort() or to any > noreturn function, for example, assert(), will also silence the warning and > it is safer than adding a new option to silence it. Yeah, I've since thought of using abort(), which as you say, silences the warning - and indicates with sufficient strength that this shouldn't happen. assert() isn't much use since the warning would return as soon I compile in release mode... been there, tried that. :) > You can use #pragma GCC diagnostic to disable the warning for this > particular function. If that seems even more of kludge than adding assert(), > you are right. But then, adding a #pragma around your whole codebase (which > is what a new option amounts to) sounds even worse, no?(In reply to DB from > comment #7) Thanks for the hint, and yeah, that would probably produce even messier code ;-) Good to know it exists though. > Perhaps there are uses for an __attribute__((strict_enum)) that can be > attached to particular enums (it would be a more fine-grained version of > -fstrict-enums). However, the effort to implement such a thing and keep it > working seems huge for and the potential fallout for handling it wrong (or > users misusing the attribute). Such an attribute is basically giving even > more license to the compiler to optimize based on undefined behavior, and > users often find UB incomprehensible. Compare that with the effort of > asking users to add __builtin_unreachable() (if they are sure their code > will never be wrong) or add an assert(false) (if they are not completely > sure). Yeah, I think this would be best as a Standard thing, rather than adding another custom attribute to any given compiler. I don't see why it gives "even more licence" to optimise, though, since it'd be conditional per enum, rather than -fstrict-enums, which applies globally... so if anyone inadvertently invokes UB, they've got much more chance of being caught out if they're using the existing global option, than if there was a per-enum attribute for whether or not the value must be a named enumerator. > Perhaps I should add an entry to the FAQ summarizing the above (anyone feel > free to beat me to it...) Couldn't hurt. :) There are some great explanations collected around the net (including some on IRC, but I'm sure you know those ;) but it's hard to find a pre-emptive summary of why this isn't already done. Thanks!
[Bug c/71199] Support overloadable attribute in GNU C front-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71199 --- Comment #7 from Yu Xuanchi --- And there is another option. Because clang documentation say: "However, when an overloadable function occurs within an extern "C" linkage specification, it’s name will be mangled in the same way as it would in C." So should we think nested function as implicit extern "C" and mangled it in C way like "test.", "test.0001"?
[Bug c/71199] Support overloadable attribute in GNU C front-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71199 --- Comment #6 from Yu Xuanchi --- So I think in short term. We just reject those code. Because our aim is to support this feature like clang. If there is no any problem. I'll go impl it.
[Bug c++/77561] New: Unclear diagnostic for invalid declaration of partial specialization as friend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77561
Bug ID: 77561
Summary: Unclear diagnostic for invalid declaration of partial
specialization as friend
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
template class A { };
template
class B {
template friend class A;
};
G++ says:
ps.cc:5:38: error: specialization of ‘template class A’ must
appear at namespace scope
template friend class A;
^~~
The user is not trying to declare a specialization, they're trying to define a
friend. The error should tell them that is allowed, instead of telling them
they're doing it in the wrong place.
Clang says:
ps.cc:5:32: error: partial specialization cannot be declared as a friend
template friend class A;
^ ~~
EDG says:
"ps.cc", line 5: error: a friend declaration may not declare a partial
specialization
template friend class A;
^
[Bug libstdc++/24693] Deque improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24693 --- Comment #5 from Jonathan Wakely --- See also PR 77524
[Bug c++/63263] friend declaration of function template specialization gets confused when specialization was forward declared.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63263
Jonathan Wakely changed:
What|Removed |Added
Keywords||ice-on-valid-code
Last reconfirmed|2014-12-13 00:00:00 |2016-9-11
Known to fail|5.0 |5.4.0, 6.2.0, 7.0
--- Comment #4 from Jonathan Wakely ---
Trunk ICEs again.
ps.cc: In instantiation of ‘void f(T&) [with T = B]’:
ps.cc:5:20: required from here
ps.cc:1:35: error: no matching function for call to ‘B::B(int)’
template void f(T&) { T(1); }
^~~~
ps.cc:4:8: note: candidate: constexpr B::B()
struct B { friend void f(B&); };
^
ps.cc:4:8: note: candidate expects 0 arguments, 1 provided
ps.cc:4:8: note: candidate: constexpr B::B(const B&)
ps.cc:4:8: note: no known conversion for argument 1 from ‘int’ to ‘const B&’
ps.cc:4:8: note: candidate: constexpr B::B(B&&)
ps.cc:4:8: note: no known conversion for argument 1 from ‘int’ to ‘B&&’
ps.cc:1:39: internal compiler error: in add_stmt, at cp/semantics.c:385
template void f(T&) { T(1); }
^
0x7eafdf add_stmt(tree_node*)
/home/jwakely/src/gcc/gcc/gcc/cp/semantics.c:385
0x6b51fa tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:15424
0x6f4f90 instantiate_decl(tree_node*, int, bool)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:22158
0x6fbe69 instantiate_pending_templates(int)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:22277
0x740d63 c_parse_final_cleanups()
/home/jwakely/src/gcc/gcc/gcc/cp/decl2.c:4617
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug c/71199] Support overloadable attribute in GNU C front-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71199
--- Comment #5 from Yu Xuanchi ---
So there is a problem clang does not support nested function. Like:
-
void foo() {
void foo1() {
// Bar
}
}
-
And cpp also not supported. But gcc support it as an extensions. So how we deal
with code like this:
-
void __attribute__((overloadable)) test(long bar) {}
void foo1() {
void __attribute__((overloadable)) test(int bar) {}
void __attribute__((overloadable)) test(float bar) {}
}
void foo2() {
void __attribute__((overloadable)) test(int bar) {}
void __attribute__((overloadable)) test(float bar) {}
}
-
So extern scope "test" function should be mangled to "_Z4testl" right? But how
about others? Should we reject compile code like this? Or just allow it and
mangle it in some way? The origin gcc mangle nested function linke "test.".
the is some number only gcc what it mean. So should we mangle name like
"Z4testi."? or "Z9test.i"?
[Bug regression/71231] [7 Regression]: 300% runtime increase for rnflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71231 --- Comment #17 from Dominique d'Humieres --- > This problem seems fixed. The runtimes are back to normal. AFAICT the output does not seem right with r240076 and "-fprotect-parens -Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer -fwhole-program -flto": ... 173 , 181194373 195269 0.45979 173 , 189 78369 78688 0.40996 173 , 197 19089 19224 0.69988 173 , 205 30633176 3.5594 181 , 197 29924 30167 0.81002 189 , 197 32866 32970 0.31993 189 , 205 12258 12376 0.94988 197 , 205 10923 10808 1.0495 0: 0:21.328 -> Completed program execution compared to the output of an executable from Aug 16 2013: ... 173 , 181194373 193363 0.51981 173 , 189 78369 78008 0.45979 173 , 197 19089 18777 1.6300 181 , 189 81645 81532 0.14001 181 , 197 29924 29571 1.1795 189 , 197 32866 33059 0.57983 189 , 205 12258 12352 0.75990 197 , 205 10923 10786 1.2500 205 , 213 32783208 2.1387 0: 0:14.916 -> Completed program execution or of gfortran 6.2.0 ... 173 , 181194373 193363 0.51981 173 , 189 78369 78008 0.45979 173 , 197 19089 18777 1.6300 181 , 189 81645 81532 0.14001 181 , 197 29924 29571 1.1795 189 , 197 32866 33059 0.57983 189 , 205 12258 12352 0.75990 197 , 205 10923 10786 1.2500 205 , 213 32783208 2.1387 0: 0:13.175 -> Completed program execution
[Bug c++/77553] [6/7 Regression] wrong code with post-increment operator in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77553 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 39605 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39605&action=edit gcc7-pr77553.patch Untested fix.
[Bug fortran/32834] [Meta-bug] 'Fortran 95'-only failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32834 Bug 32834 depends on bug 77560, which changed state. Bug 77560 Summary: Redefinition of lower bound in explicit-shape dummy argument https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77560 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID
[Bug fortran/77560] Redefinition of lower bound in explicit-shape dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77560 Thomas Koenig changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Thomas Koenig --- Dominique, you're right, this is invalid.
[Bug fortran/77560] Redefinition of lower bound in explicit-shape dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77560 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-09-11 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- I think the code is invalid: "from = from + 1" tries to write on the constant 1. The following test works subroutine foo(a,from,to) integer :: from, to real, dimension(from:to) :: a from = from + 1 print *,a end subroutine foo program main integer :: ione = 1 real, dimension(3) :: a a = reshape([(i,i=1,3)],shape(a)) print *,a call foo(a,ione,3) end program main
[Bug fortran/77560] New: Redefinition of lower bound in explicit-shape dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77560 Bug ID: 77560 Summary: Redefinition of lower bound in explicit-shape dummy argument Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- The following program segfaults: subroutine foo(a,from,to) integer :: from, to real, dimension(from:to) :: a from = from + 1 print *,a end subroutine foo program main real, dimension(3) :: a a = reshape([(i,i=1,3)],shape(a)) print *,a call foo(a,1,3) end program main ig25@linux-fd1f:~/Krempel/Full> gfortran full.f90 ig25@linux-fd1f:~/Krempel/Full> ./a.out 1. 2. 3. Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7f5d3ec6d087 in ??? #1 0x7f5d3ec6df35 in ??? #2 0x7f5d3e18511f in ??? #3 0x400879 in ??? #4 0x400a2a in ??? #5 0x400a61 in ??? #6 0x7f5d3e171b04 in ??? #7 0x400718 in ??? at ../sysdeps/x86_64/start.S:122 #8 0x in ??? Speicherzugriffsfehler Although bad style, this is legal. 5.1.2.5.1 of J3/04-007 says If an explicit-shape array has bounds that are not initialization expressions, the bounds, and hence shape, are determined at entry to the procedure by evaluating the bounds expressions. The bounds of such an array are unaffected by the redefinition or undefinition of any variable during execution of the procedure.
[Bug other/70268] add option -ffile-prefix-map to map one directory name (old) to another (new) in __FILE__, __BASE_FILE__and __builtin_FILE()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268 --- Comment #7 from Sascha Steinbiss --- Is there any progress on this? Actually such a functionality as provided by -ffile-prefix-map would also be highly desirable in the context of the Reproducible Builds effort [1]. Build-specific source paths included via __FILE__ in gcc-built artefacts are quite common and -- at least from my experience -- a problematic source of binary variation. Cheers Sascha [1] https://reproducible-builds.org
[Bug middle-end/77558] [6/7 regression] c-c++-common/va-arg-va-list-type.c fails for arm/aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77558 --- Comment #4 from Christophe Lyon --- (In reply to Tom de Vries from comment #2) > Fails for arm as well (as mentioned here: > > The failure is different, but the root cause is the same. Also the ICE > already appears before the patch introducing the test-case was committed. > > Applying the patch from comment 1 fixes this as well. Indeed the same patch fixes the ICE on arm. Thanks.
[Bug c++/77557] gcc doesn't warn about code (clang does), __PRETTY_FUNCTION__ used in struct in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77557
--- Comment #3 from Jonathan Wakely ---
N.B. for clang 3.9 the program prints "top level" not the constructor name.
__PRETTY_FUNCTION__ is a non-standard extension so the standard says nothing
about how it works. The similar function-local predefined variable __func__ is
standard, and is usable in ctor-init-lists, e.g. this should get the name of
the constructor:
struct getter {
getter() : s(__func__) { }
const char* s;
};
However, the predefined variable is only in scope in the function body, and a
default member initializer is not part of the constructor's function body, so I
think G++ is right to find the variable from the enclosing scope (as in
Andrew's example).
And so I think Clang is wrong to warn. Likewise, EDG is wrong to give an error:
"dmi2.cc", line 4: error: the reserved identifier "__PRETTY_FUNCTION__" may
only be used inside a function
const char * fn = __PRETTY_FUNCTION__;
^
I don't see anything in the standard saying the predefined variable __func__ is
not usable in nested classes defined in the block scope where the variable is
defined.
[Bug tree-optimization/71915] A missed opportunity for SLSR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71915 Martin Liška changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #2 from Martin Liška --- *** Bug 77552 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/77552] FAIL: gcc.dg/tree-ssa/slsr-8.c scan-tree-dump-times optimized " w?\\* " 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77552 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Martin Liška --- Duplicate. *** This bug has been marked as a duplicate of bug 71915 ***
[Bug c++/77556] [6/7 Regression] ICE on invalid C++ code with non-constant non-type template argument: in convert_nontype_argument, at cp/pt.c:6416
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77556 Martin Liška changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-09-11 CC||marxin at gcc dot gnu.org Target Milestone|--- |6.3 Summary|ICE on invalid C++ code |[6/7 Regression] ICE on |with non-constant non-type |invalid C++ code with |template argument: in |non-constant non-type |convert_nontype_argument, |template argument: in |at cp/pt.c:6416 |convert_nontype_argument, ||at cp/pt.c:6416 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with a graphite patch in r228215.
[Bug lto/71089] [7 Regression] Failed to build 483.xalancbmk in SPEC CPU 2006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71089 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jan Hubicka --- Fixed a while ago
[Bug lto/50147] LTO: Segmentation fault in infinite_empty_loop_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50147 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-09-11 CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Jan Hubicka --- Works for me with current mainline and it is not obvious to me what went wrong in 4.6 Does it still wreproduce on any of maintained branches?
[Bug web/77551] Please disable the "Importance:" field for normal users of bugzilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77551 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-09-11 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- c.f. https://gcc.gnu.org/ml/gcc/2015-12/msg00069.html The distinction between bug and "enhancement" is useful, and maybe "trivial" is useful, but the other severities (blocker, critical, minor etc) are useless. We should either remove the severity field entirely, or remove most of the options. Alternatively, don't let normal users set it, only people with edit privs.
[Bug lto/57726] LTO verify_flow_info: error: control flow in the middle of basic block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57726 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-09-11 CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jan Hubicka --- Seems the testcase is not complete. Does it still reproduce?
[Bug c++/77554] ICE on valid C++11 code with variadic template function: tree check: expected class ‘expression’, have ‘type’ (integer_type) in tree_operand_check, at tree.h:3524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77554 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-09-11 CC||marxin at gcc dot gnu.org Target Milestone|--- |5.5 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed.
[Bug ipa/61159] __builtin_constant_p gives incorrect results with aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61159 --- Comment #4 from Jan Hubicka --- Author: hubicka Date: Sun Sep 11 12:15:02 2016 New Revision: 240082 URL: https://gcc.gnu.org/viewcvs?rev=240082&root=gcc&view=rev Log: PR ipa/61159 * compile/pr61159.c: New testcase Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr61159.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug ipa/61159] __builtin_constant_p gives incorrect results with aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61159 --- Comment #3 from Jan Hubicka --- Fixed.
[Bug middle-end/77558] c-c++-common/va-arg-va-list-type.c fails for arm/aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77558
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #3 from Christophe Lyon ---
(In reply to Tom de Vries from comment #1)
> This patch seems to fix the problem:
> ...
> diff --git a/gcc/builtins.c b/gcc/builtins.c
> index e779c71..93a5f3b 100644
> --- a/gcc/builtins.c
> +++ b/gcc/builtins.c
> @@ -4089,10 +4089,7 @@ std_canonical_va_list_type (tree type)
>
>wtype = va_list_type_node;
>htype = type;
> - /* Treat structure va_list types. */
> - if (TREE_CODE (wtype) == RECORD_TYPE && POINTER_TYPE_P (htype))
> -htype = TREE_TYPE (htype);
> - else if (TREE_CODE (wtype) == ARRAY_TYPE)
> + if (TREE_CODE (wtype) == ARRAY_TYPE)
> {
>/* If va_list is an array type, the argument may have decayed
>to a pointer type, e.g. by being passed to another function.
> ...
>
> Should get some testing on aarch64.
This patch does make the test pass on aarch64, thanks.
[Bug rtl-optimization/64316] [5 Regression] ICE in simplify_const_unary_operation after r218503
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64316 --- Comment #5 from Jan Hubicka --- Author: hubicka Date: Sun Sep 11 12:08:28 2016 New Revision: 240081 URL: https://gcc.gnu.org/viewcvs?rev=240081&root=gcc&view=rev Log: PR ipa/64316 * gcc.dg/ipa/pr63416.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/ipa/pr63416.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug ipa/63416] Three calls to empty functions via pointers get folded, but not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63416 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Severity|normal |enhancement --- Comment #5 from Jan Hubicka --- It looks like this used to be bug in ipa-prop that was fixed in gcc.5.
[Bug middle-end/77558] c-c++-common/va-arg-va-list-type.c fails for arm/aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77558 Tom de Vries changed: What|Removed |Added Summary|c-c++-common/va-arg-va-list |c-c++-common/va-arg-va-list |-type.c fails for aarch64 |-type.c fails for ||arm/aarch64 --- Comment #2 from Tom de Vries --- Fails for arm as well (as mentioned here: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00597.html ): ... FAIL: c-c++-common/va-arg-va-list-type.c -std=c++11 (test for errors, line 8) FAIL: c-c++-common/va-arg-va-list-type.c -std=c++11 (internal compiler error) FAIL: c-c++-common/va-arg-va-list-type.c -std=c++11 (test for excess errors) FAIL: c-c++-common/va-arg-va-list-type.c -std=c++14 (test for errors, line 8) FAIL: c-c++-common/va-arg-va-list-type.c -std=c++14 (internal compiler error) FAIL: c-c++-common/va-arg-va-list-type.c -std=c++14 (test for excess errors) FAIL: c-c++-common/va-arg-va-list-type.c -std=c++98 (test for errors, line 8) FAIL: c-c++-common/va-arg-va-list-type.c -std=c++98 (internal compiler error) FAIL: c-c++-common/va-arg-va-list-type.c -std=c++98 (test for excess errors) FAIL: c-c++-common/va-arg-va-list-type.c -Wc++-compat (test for errors, line 8) FAIL: c-c++-common/va-arg-va-list-type.c -Wc++-compat (internal compiler error) FAIL: c-c++-common/va-arg-va-list-type.c -Wc++-compat (test for excess errors) ... The failure is different, but the root cause is the same. Also the ICE already appears before the patch introducing the test-case was committed. Applying the patch from comment 1 fixes this as well.
[Bug c++/77559] Implicit conversion from pointer to reference fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77559 --- Comment #2 from Markus Trippelsdorf --- It works with -std=c++98.
[Bug c++/77559] Implicit conversion from pointer to reference fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77559 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Markus Trippelsdorf --- All other compilers (icc,clang) reject this also. Not a compiler bug.
[Bug fortran/48298] [F03] User-Defined Derived-Type IO (DTIO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #20 from Paul Thomas --- (In reply to Paul Thomas from comment #19) > Author: pault > Date: Wed Sep 7 21:21:16 2016 > New Revision: 240032 > > URL: https://gcc.gnu.org/viewcvs?rev=240032&root=gcc&view=rev > Log: > 2016-09-07 Dominique Dhumieres > > PR fortran/48298 > * gfortran.dg/assumed_rank_12.f90: Correct tree scan. > * gfortran.dg/assumed_type_2.f90: Correct tree scans. > * gfortran.dg/coarray_lib_comm_1.f90: Likewise. > * gfortran.dg/coarray_lib_this_image_2.f90: Likewise. > * gfortran.dg/coarray_lock_7.f90: Likewise. > * gfortran.dg/coarray_stat_function.f90: Likewise. > * gfortran.dg/no_arg_check_2.f90: Likewise. > * gfortran.dg/pr32921.f: Likewise. > > Modified: > branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev > branches/fortran-dev/gcc/testsuite/gfortran.dg/assumed_rank_12.f90 > branches/fortran-dev/gcc/testsuite/gfortran.dg/assumed_type_2.f90 > branches/fortran-dev/gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90 > > branches/fortran-dev/gcc/testsuite/gfortran.dg/coarray_lib_this_image_2.f90 > branches/fortran-dev/gcc/testsuite/gfortran.dg/coarray_lock_7.f90 > branches/fortran-dev/gcc/testsuite/gfortran.dg/coarray_stat_function.f90 > branches/fortran-dev/gcc/testsuite/gfortran.dg/no_arg_check_2.f90 > branches/fortran-dev/gcc/testsuite/gfortran.dg/pr32921.f Sorry for the noise. I did a copy and paste for ChangeLog formatting and forgot to remove the PR number. The above patch is concerned with fixing the fallout from merging fortran-dev and 7-branch. Fortran-dev is focussed on array descriptor reform. Paul
[Bug fortran/77532] ICE in check_dtio_interface1, at fortran/interface.c:4622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77532 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Paul Thomas --- This PR and PRs77533/4 fixed by the patch committed in comment #3. Thanks for the report. Paul and Jerry.
