[Bug fortran/78976] [7 Regression] FAIL: gfortran.dg/dependency_49.f90 and gfortran.dg/transfer_intrinsic_1.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78976 --- Comment #3 from Janne Blomqvist --- Ugh, yeah. I had to revert the big patch, https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00110.html, which also reverted the testcase fixes. I'll commit them separately.
[Bug bootstrap/77569] [7 Regression] self tests fail when not using C locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77569 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Wed Jan 4 07:53:30 2017 New Revision: 244047 URL: https://gcc.gnu.org/viewcvs?rev=244047&root=gcc&view=rev Log: PR bootstrap/77569 * input.c (ebcdic_execution_charset::on_error): Don't use strstr for a substring of the message, but strcmp with the whole message. Ifdef ENABLE_NLS, translate the message first using dgettext. Modified: trunk/gcc/ChangeLog trunk/gcc/input.c
[Bug fortran/78983] New: ICE with CAF-DT with allocatable member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78983
Bug ID: 78983
Summary: ICE with CAF-DT with allocatable member
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: stefano.zaghi at cnr dot it
Target Milestone: ---
Created attachment 40450
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40450&action=edit
MCVE of CAF-DT with allocatable member
My current "env" is
+ GNU Fortran (GCC) 7.0.0 20161206 (experimental)
+ MPICH 3.2.0 built with GCC 7.0.0
+ OpenCoarrays built 1.7.5 with GCC 7.0.0 and MPICH 3.2.0
+ Linux 4.8.8-2-ARCH #1 SMP PREEMPT Thu Nov 17 14:51:03 CET 2016 x86_64
GNU/Linux
The MCVE raising the ICE is attached as "MCVE of CAF-DT with allocatable
member". Essentially, there is a "base" DT (named "node") with an allocatable
member, a second DT (named "caf") that has a coarray member of "type(node)".
The last concrete instance of "type(caf)" is a scalar, static variable thus the
code should be valid (while I still think that the other is invalid).
Compiling this code with the above env generates the following ICE
stefano@zaghi(09:38 AM Mon Dec 12) desk {opencoarrays-1.7.5-gnu-7.0.0 -
OpenCoarrays 1.7.5 with gcc 7.0.0 environment}
~/fortran/compilers_bug/gfortran_sigsegv_caf_dt_allocatable_member 5 files,
84Kb
→ caf -fcoarray=lib sigsegv_caf_dt.f90
sigsegv_caf_dt.f90:77:0:
end module caf_module
internal compiler error: Segmentation fault
0xc0db4f crash_signal
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/toplev.c:333
0xeb1764 recompute_tree_invariant_for_addr_expr(tree_node*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/tree.c:4317
0xeb1d7c build1_stat(tree_code, tree_node*, tree_node*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/tree.c:4414
0x92c76c build1_stat_loc
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/tree.h:3903
0x92c76c fold_build1_stat_loc(unsigned int, tree_code, tree_node*, tree_node*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fold-const.c:12139
0x6f204f gfc_build_addr_expr(tree_node*, tree_node*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:298
0x70532b structure_alloc_comps
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-array.c:8329
0x7827b3 gfc_trans_deallocate(gfc_code*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:6477
0x6f1bf7 trans_code
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:1942
0x7742f3 gfc_trans_if_1
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:1303
0x77c39a gfc_trans_if(gfc_code*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:1334
0x6f1ce7 trans_code
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:1878
0x7742f3 gfc_trans_if_1
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:1303
0x77c39a gfc_trans_if(gfc_code*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:1334
0x6f1ce7 trans_code
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:1878
0x77e271 gfc_trans_simple_do
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:1924
0x77e271 gfc_trans_do(gfc_code*, tree_node*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-stmt.c:2057
0x6f1cba trans_code
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:1890
0x723038 gfc_generate_function_code(gfc_namespace*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans-decl.c:6271
0x6f6949 gfc_generate_module_code(gfc_namespace*)
/opt/arch/gcc/opencoarrays/prerequisites/downloads/trunk/gcc/fortran/trans.c:2164
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
My best regards.
[Bug libgcc/58120] libgcc.a and libgcc_eh.a have incorrect symbol visibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58120 Yuri Gribov changed: What|Removed |Added CC||tetra2005 at gmail dot com --- Comment #1 from Yuri Gribov --- Does not reproduce with arm-linux-gnueabi-gcc 5.4.0, all symbols in libgcc.a are hidden.
[Bug target/78972] [5/6/7 Regression] poor x86 simd instruction scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972 --- Comment #7 from Andrew Pinski --- One thing to try is -fno-tree-ter.
[Bug tree-optimization/78856] [6 Regression] wrong code at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78856 Jeffrey A. Law changed: What|Removed |Added Summary|[6/7 Regression] wrong code |[6 Regression] wrong code |at -O3 on x86_64-linux-gnu |at -O3 on x86_64-linux-gnu |(in both 32-bit and 64-bit |(in both 32-bit and 64-bit |modes) |modes) --- Comment #7 from Jeffrey A. Law --- Fixed on trunk so far.
[Bug tree-optimization/78856] [6 Regression] wrong code at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78856 Jeffrey A. Law changed: What|Removed |Added Summary|[6/7 Regression] wrong code |[6 Regression] wrong code |at -O3 on x86_64-linux-gnu |at -O3 on x86_64-linux-gnu |(in both 32-bit and 64-bit |(in both 32-bit and 64-bit |modes) |modes) --- Comment #6 from Jeffrey A. Law --- Author: law Date: Wed Jan 4 05:31:23 2017 New Revision: 244045 URL: https://gcc.gnu.org/viewcvs?rev=244045&root=gcc&view=rev Log: PR tree-optimizatin/78856 * tree-ssa-threadupdate.c: Include tree-vectorizer.h. (mark_threaded_blocks): Remove code to truncate thread paths that cross multiple loop headers. Instead invalidate the cached loop iteration information and handle case of a thread path walking into an irreducible region. PR tree-optimization/78856 * gcc.c-torture/execute/pr78856.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr78856.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-threadupdate.c --- Comment #7 from Jeffrey A. Law --- Fixed on trunk so far.
[Bug tree-optimization/78856] [6/7 Regression] wrong code at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78856 --- Comment #6 from Jeffrey A. Law --- Author: law Date: Wed Jan 4 05:31:23 2017 New Revision: 244045 URL: https://gcc.gnu.org/viewcvs?rev=244045&root=gcc&view=rev Log: PR tree-optimizatin/78856 * tree-ssa-threadupdate.c: Include tree-vectorizer.h. (mark_threaded_blocks): Remove code to truncate thread paths that cross multiple loop headers. Instead invalidate the cached loop iteration information and handle case of a thread path walking into an irreducible region. PR tree-optimization/78856 * gcc.c-torture/execute/pr78856.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr78856.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-threadupdate.c
[Bug tree-optimization/66826] Unused result from dlsym in constructor results in a segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66826 Rich Felker changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #5 from Rich Felker --- I think the issue is more complicated. Even if glibc were fixed not to crash, code like the following: return dlsym(RTLD_NEXT, "whatever"); would return the wrong result under tco when the caller's caller is in a different dso. GCC probably needs a "notailcall" attribute to fix this, but maybe there are workarounds glibc could do to prevent tco without needing a new attribute...
[Bug target/78953] Errors in compiling Spec 2006 for power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78953 --- Comment #3 from Michael Meissner --- Author: meissner Date: Wed Jan 4 04:32:48 2017 New Revision: 244044 URL: https://gcc.gnu.org/viewcvs?rev=244044&root=gcc&view=rev Log: [gcc] 2016-12-30 Michael Meissner PR target/78900 * config/rs6000/rs6000.c (rs6000_split_signbit): Change some assertions. Add support for doing the signbit if the IEEE 128-bit floating point value is in a GPR. * config/rs6000/rs6000.md (Fsignbit): Delete. (signbit2_dm): Delete using and just use "wa". Update the length attribute if the value is in a GPR. (signbit2_dm_ext): Add combiner pattern to eliminate the sign or zero extension instruction, since the value is always 0/1. (signbit2_dm2): Delete using . 2017-01-03 Michael Meissner PR target/78953 * config/rs6000/vsx.md (vsx_extract__store_p9): If we are extracting SImode to a GPR register so that we can generate a store, limit the vector to be in a traditional Altivec register for the vextuwrx instruction. [gcc/testsuite] 2017-01-03 Michael Meissner PR target/78953 * gcc.target/powerpc/pr78953.c: New test. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr78953.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.md trunk/gcc/config/rs6000/vsx.md trunk/gcc/testsuite/ChangeLog
[Bug target/78900] ICE in gcc.target/powerpc/signbit-3.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78900 --- Comment #2 from Michael Meissner --- Author: meissner Date: Wed Jan 4 04:32:48 2017 New Revision: 244044 URL: https://gcc.gnu.org/viewcvs?rev=244044&root=gcc&view=rev Log: [gcc] 2016-12-30 Michael Meissner PR target/78900 * config/rs6000/rs6000.c (rs6000_split_signbit): Change some assertions. Add support for doing the signbit if the IEEE 128-bit floating point value is in a GPR. * config/rs6000/rs6000.md (Fsignbit): Delete. (signbit2_dm): Delete using and just use "wa". Update the length attribute if the value is in a GPR. (signbit2_dm_ext): Add combiner pattern to eliminate the sign or zero extension instruction, since the value is always 0/1. (signbit2_dm2): Delete using . 2017-01-03 Michael Meissner PR target/78953 * config/rs6000/vsx.md (vsx_extract__store_p9): If we are extracting SImode to a GPR register so that we can generate a store, limit the vector to be in a traditional Altivec register for the vextuwrx instruction. [gcc/testsuite] 2017-01-03 Michael Meissner PR target/78953 * gcc.target/powerpc/pr78953.c: New test. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr78953.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.md trunk/gcc/config/rs6000/vsx.md trunk/gcc/testsuite/ChangeLog
[Bug target/78982] __builtin_lrintf() not an cvtss2si/vcvtss2si but cvttss2si/vcvttss2si since GCC 6.xx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78982 --- Comment #2 from Andrew Pinski --- Please attach the preprocessed source for each version of GCC you are using? I suspect there is some glibc changes that you are seeing :).
[Bug regression/78982] __builtin_lrintf() not an cvtss2si/vcvtss2si but cvttss2si/vcvttss2si since GCC 6.xx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78982 --- Comment #1 from Waldemar Friedrich --- additional info changing code to float someFloat = 10*argc; someFloat+=0.1f; long someInt = lrintf (someFloat); does produce cvtss2si/vcvtss2si but float someFloat = 10*argc; someFloat+=2.0f; long someInt = lrintf (someFloat); don't so it looks when it is assumed value is whole integer in nature it is cvttss2si (truncation) otherwise cvtss2si (rounding)
[Bug regression/78982] New: __builtin_lrintf() not an cvtss2si/vcvtss2si but cvttss2si/vcvttss2si since GCC 6.xx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78982
Bug ID: 78982
Summary: __builtin_lrintf() not an cvtss2si/vcvtss2si but
cvttss2si/vcvttss2si since GCC 6.xx
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: anty_order at tlen dot pl
Target Milestone: ---
It looks starting from GCC 6 bug reported and fixed earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48139
reappeared.
Solution given in mentioned bug (adding -fno-math-errno or -ffast-math) works
as expected in all GCC versions below 6.x (tested with 4.8.x, 4.9.x, 5.x).
example code:
#include
#include
int main(int argc, char **argv)
{
float someFloat = 10*argc;
long someInt = lrintf (someFloat);
std::cout << someInt << std::endl;
}
compile options:
-O2 -msse -ffast-math
same for -O3 and -mavx
up to GCC 5.4
lea eax, [rdi+rdi*4]
pxorxmm0, xmm0
sub rsp, 8
mov edi, OFFSET FLAT:std::cout
add eax, eax
cvtsi2ssxmm0, eax
cvtss2sirsi, xmm0
since GCC 6 (6.1-6.3 and 7)
lea eax, [rdi+rdi*4]
pxorxmm0, xmm0
sub rsp, 8
mov edi, OFFSET FLAT:std::cout
add eax, eax
cvtsi2ssxmm0, eax
cvttss2si rsi, xmm0
[Bug c/44677] Warn for variables incremented but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44677 Martin Sebor changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #4 from Martin Sebor --- *** Bug 78964 has been marked as a duplicate of this bug. ***
[Bug c++/78964] gcc fails to detect pointless increment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78964
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
CC||msebor at gcc dot gnu.org
Resolution|WONTFIX |DUPLICATE
Severity|normal |enhancement
--- Comment #10 from Martin Sebor ---
Variables that aren't used after they have been assigned to are a indicator of
poor code quality (see CWE-563: Assignment to Variable without Use ('Unused
Variable')). Issuing a warning for such variables would be not only helpful,
but in my view also consistent with -Wunused-but-set-variable whose documented
purpose is to "Warn whenever a local variable is assigned to, but otherwise
unused (aside from its declaration)."
The semantics of ++m are not the same as m = m + 1 but rather those of m += 1,
with the important (but IMO not relevant to this report) difference of course
being that the left operand is evaluated just once. Either way, since both of
the latter expressions are forms of assignment (simple vs compound) it's fair
to say that the variable is "assigned to and otherwise unused." Explaining
this in the documentation shouldn't be difficult, but since these are the
standard semantics that most C and C++ programmers are familiar with, it
doesn't seem that it should be necessary.
I think it's worthwhile to keep this report open, if not as a bug in
-Wunused-but-set-variable then as a enhancement request.
[I was about to reopen it when I noticed Joseph's update so I'm resolving it as
a duplicate instead.]
*** This bug has been marked as a duplicate of bug 44677 ***
[Bug c++/78656] Fix-it suggestion for std::alocator doesn't include std::allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78656 --- Comment #2 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00143.html
[Bug c++/78964] gcc fails to detect pointless increment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78964 --- Comment #9 from joseph at codesourcery dot com --- See bug 44677.
[Bug target/78818] msp430 persistent attribute is not applied correctly in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78818 --- Comment #1 from Andrew Wygle --- Compiling with -mdata-region=either also causes this problem, with variables ending up in either .either.data or .either.bss.
[Bug c++/69517] [7 regression] SEGV on a VLA with excess initializer elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69517
--- Comment #15 from Martin Sebor ---
The test case from comment #0 doesn't crash for me either but one that
initializes the VLA with more than 6 elements, say like so, does:
int a[n] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 };
With both test cases the tree dump shows that GCC writes past the end of the
array.
[Bug tree-optimization/78913] Probably misleading error reported by -Wformat-length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78913 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=77708 --- Comment #9 from Martin Sebor --- See also bug 77708 for a similar (though not exactly the same) change/feature request.
[Bug tree-optimization/78913] Probably misleading error reported by -Wformat-length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78913 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #8 from Martin Sebor --- The following patch has been posted for review. It doesn't remove the warning for the submitted test case but it does make it possible to avoid it either by using the return value of the function, or by compiling with -Wno-format-truncation. https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00140.html
[Bug middle-end/77708] -Wformat-length %s warns for snprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77708 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Martin Sebor --- The following patch suppresses the warning for the test case (the warning is only issued when the return value is unused, or with -Wformat-truncation=2): https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00140.html
[Bug middle-end/78977] [7 Regression] g++7 snprintf() of double produces wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78977 --- Comment #5 from Martin Sebor --- (In reply to Hannes Hauswedell from comment #3) > > Great, let me know if it's merged, then I will try a newer snapshot! The patch has been committed (r244037). Please give it a try and let us know how it goes.
[Bug tree-optimization/78696] [7 Regression] -fprintf-return-value misoptimizes %.Ng where N is greater than 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78696 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #19 from Martin Sebor --- Patch committed in r244037.
[Bug tree-optimization/78696] [7 Regression] -fprintf-return-value misoptimizes %.Ng where N is greater than 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78696 --- Comment #18 from Martin Sebor --- Author: msebor Date: Tue Jan 3 23:14:44 2017 New Revision: 244037 URL: https://gcc.gnu.org/viewcvs?rev=244037&root=gcc&view=rev Log: PR tree-optimization/78696 - [7 Regression] -fprintf-return-value misoptimizes %.Ng where N is greater than 10 gcc/ChangeLog: PR tree-optimization/78696 * gimple-ssa-sprintf.c (format_floating): Correct handling of precision. Use MPFR for %f for greater fidelity. Correct handling of %g. (pass_sprintf_length::compute_format_length): Set width and precision specified by asrerisk to void_node for vararg functions. (try_substitute_return_value): Adjust dump output. gcc/testsuite/ChangeLog: PR tree-optimization/78696 * gcc.dg/tree-ssa/builtin-sprintf-5.c: Remove incorrect test cases. * gcc.dg/tree-ssa/builtin-sprintf-warn-7.c: Correct off-by-1 errors. * gcc.dg/tree-ssa/builtin-sprintf-warn-9.c: New test. * gcc.dg/tree-ssa/builtin-sprintf.c: Add test cases. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-sprintf.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-5.c trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-7.c trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c
[Bug c++/70834] Incorrect warning for placement new when conditionally used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70834
--- Comment #5 from Martin Sebor ---
As a workaround until the warning is made smarter, partial specialization can
be used to avoid the compile-time conditional, for example like so:
struct Test {
char buf[4];
template
struct Ctor {
static T *construct(void*) {
return new T; // else make it on the heap
}
};
template T* construct () {
return Ctor::construct (buf);
}
};
template
struct Test::Ctor {
static T* construct (void *p) {
return new (p) T;
}
};
[Bug c++/78964] gcc fails to detect pointless increment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78964 --- Comment #8 from Markus Trippelsdorf --- (In reply to David Binderman from comment #7) > (In reply to Markus Trippelsdorf from comment #4) > > And the Linux kernel would not see these warnings anyway: > > > > Makefile: > > 707 # These warnings generated too much noise in a regular build. > > 708 # Use make W=1 to enable them (see scripts/Makefile.build) > > 709 KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable) > > 710 KBUILD_CFLAGS += $(call cc-disable-warning, unused-const-variable) > > Linux kernel just an example. There are over 100 similar bugs in llvm. > about 20 in netBSD kernel, about a dozen in gcc itself etc. > > Unless you are claiming that every source code that uses gcc switches > off -Wunused-but-set-variable, then I can see some value in this new warning. > > From a user perspective, this new warning isn't a lot different to > -Wunused-but-set-variable and that got implemented, why not this ? Why are you calling these slight style issues bugs? What harm is there in a superfluous variable that the compiler optimizes away? Why should people spend time "fixing" these issues?
[Bug c++/70834] Incorrect warning for placement new when conditionally used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70834 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #4 from Martin Sebor --- I'm hoping to move -Wplacement-new to the middle end in GCC 8 and have it make use of object size checking similarly to -Wstringop-overflow.
[Bug c++/78964] gcc fails to detect pointless increment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78964 --- Comment #7 from David Binderman --- (In reply to Markus Trippelsdorf from comment #4) > And the Linux kernel would not see these warnings anyway: > > Makefile: > 707 # These warnings generated too much noise in a regular build. > 708 # Use make W=1 to enable them (see scripts/Makefile.build) > 709 KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable) > 710 KBUILD_CFLAGS += $(call cc-disable-warning, unused-const-variable) Linux kernel just an example. There are over 100 similar bugs in llvm. about 20 in netBSD kernel, about a dozen in gcc itself etc. Unless you are claiming that every source code that uses gcc switches off -Wunused-but-set-variable, then I can see some value in this new warning. From a user perspective, this new warning isn't a lot different to -Wunused-but-set-variable and that got implemented, why not this ?
[Bug fortran/78976] [7 Regression] FAIL: gfortran.dg/dependency_49.f90 and gfortran.dg/transfer_intrinsic_1.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78976 Andrew Pinski changed: What|Removed |Added Status|WAITING |NEW Target Milestone|--- |7.0 --- Comment #2 from Andrew Pinski --- This still fails as of r244027 (git commit 6dc2e74): https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg00277.html
[Bug other/77421] Bugs found in GCC with the help of PVS-Studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77421 Manuel López-Ibáñez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Manuel López-Ibáñez --- I think everything here got fixed or has its own specific PR, so let's close this.
[Bug c++/78964] gcc fails to detect pointless increment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78964
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #6 from Manuel López-Ibáñez ---
(In reply to Jakub Jelinek from comment #3)
> ++m is no different from m = m + 1;, both read the variable content before
> writing it again, and with the current infrastructure it would be terribly
> hard to figure out that the var is read solely to write its value again.
> Even trying to explain this in the documentation would be hard.
Well, we could just say that uses that are assigned to itself are not
considered uses for the purposes of Wunused-but-set. This would include not
only ++m but also m += 2 and m = m + x, so we would warn about:
void f( int n)
{
int m = 0;
m = m + n;
}
I thought there was an open PR about this and another about the simpler "m = m"
case, but I cannot find them.
[Bug middle-end/77721] -Wformat-length not uses arg range for converted vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77721 --- Comment #4 from Martin Sebor --- As it turns out, the patch for bug 78622 only masked the true root cause of the problem which is bug 78969. An unrelated patch I'm testing makes the false positives come back. There may be a way to work around the underlying problem but I'm mot sure I'll have the time to do it in GCC 7.
[Bug c++/70834] Incorrect warning for placement new when conditionally used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70834 Manuel López-Ibáñez changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-03 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Manuel López-Ibáñez --- The warning comes from the FE, which knows nothing about control-flow. We have many open PRs regarding this (see PR23577) but it is not something that will change in the near future. It may work if you use ?: since that is optimised very early (but perhaps not before this warning, I don't know).
[Bug c/39589] make -Wmissing-field-initializers=2 work with "designated initializers" ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39589 --- Comment #10 from Manuel López-Ibáñez --- (In reply to Georg from comment #8) > If it helps implementing this legitimate distinction between > use cases, i.e. default initialisation vs. software maintenance, > I'd be happy having to attach a type attribute. For example, This seems more complicated than extending -Wm-f-i or adding a new option. I think the current behavior is historical and does not make sense nowadays. If the patch reviewers complain that the behavior of -Wm-f-i should not change, then just add a new option or a numeric level to -Wm-f-i, whatever reviewers prefer (see point 10 in https://gcc.gnu.org/wiki/Community). The reason this has not been implemented in 8 years is not any a priori rejection, but simply nobody has had the time or the motivation to submit a patch: https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps
[Bug target/78953] Errors in compiling Spec 2006 for power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78953 --- Comment #2 from Michael Meissner --- Created attachment 40449 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40449&action=edit Proposed patch to fix the problem
[Bug go/78789] Error: no such instruction: `aesenc %xmm0,%xmm2' when compiling libgo/runtime/aeshash.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78789 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Ian Lance Taylor --- Fixed.
[Bug middle-end/78977] [7 Regression] g++7 snprintf() of double produces wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78977 --- Comment #4 from Jakub Jelinek --- (In reply to Hannes Hauswedell from comment #3) > > if it does, then we really need self-contained small test. > > Like I said, it doesn't happen on all the time and I have had difficulties > extracting it. I could make something smaller than our whole repo, but it > would likely still be quite a lot of code. Or is there some way I can make > GCC dump an intermediate version of all the code that it actually uses for > building the binary? We can reduce it ourselves, if you provide preprocessed source for the compilation unit in which it happens, plus g++ command line options. But without access to FreeBSD we also need to know what the double argument is (unless it is a compile time constant) and what FreeBSD snprintf prints (unless it is the "0.3\000\377\177\000\000" you mentioned earlier).
[Bug go/78789] Error: no such instruction: `aesenc %xmm0,%xmm2' when compiling libgo/runtime/aeshash.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78789 --- Comment #2 from ian at gcc dot gnu.org --- Author: ian Date: Tue Jan 3 20:41:54 2017 New Revision: 244031 URL: https://gcc.gnu.org/viewcvs?rev=244031&root=gcc&view=rev Log: PR go/78789 runtime: don't build aeshash.c if the assembler doesn't support it This is for CentOS 5, whose assembler does not know the aesinc instruction. Fixes GCC PR 78789. Patch by Uros Bizjak. Reviewed-on: https://go-review.googlesource.com/34796 Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/config.h.in trunk/libgo/configure trunk/libgo/configure.ac trunk/libgo/go/runtime/alg.go trunk/libgo/go/runtime/runtime2.go trunk/libgo/go/runtime/stubs.go trunk/libgo/runtime/aeshash.c trunk/libgo/runtime/runtime.h trunk/libgo/runtime/runtime_c.c
[Bug demangler/78944] null pointer in demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78944 --- Comment #2 from Ivan Sorokin --- Another very rare crash discovered by my fuzzer: _Z1fAqu4SmFG1n3_a.
[Bug rtl-optimization/65618] [5/6 Regression] gnat bootstrap comparison failure on mips{,el}-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65618
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
Summary|[5/6/7 Regression] gnat |[5/6 Regression] gnat
|bootstrap comparison|bootstrap comparison
|failure on |failure on
|mips{,el}-linux-gnu |mips{,el}-linux-gnu
--- Comment #12 from Jeffrey A. Law ---
Fixed on the trunk.
[Bug rtl-optimization/65618] [5/6/7 Regression] gnat bootstrap comparison failure on mips{,el}-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65618 --- Comment #11 from Jeffrey A. Law --- Author: law Date: Tue Jan 3 18:41:05 2017 New Revision: 244029 URL: https://gcc.gnu.org/viewcvs?rev=244029&root=gcc&view=rev Log: PR rtl-optimization/65618 * emit-rtl.c (try_split): Move initialization of "before" and "after" to just before the call to emit_insn_after_setloc. Modified: trunk/gcc/ChangeLog trunk/gcc/emit-rtl.c
[Bug go/78789] Error: no such instruction: `aesenc %xmm0,%xmm2' when compiling libgo/runtime/aeshash.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78789 --- Comment #1 from Uroš Bizjak --- Proposed patch at [1]. [1] https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00117.html
[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534 --- Comment #16 from Janne Blomqvist --- Author: jb Date: Tue Jan 3 18:01:30 2017 New Revision: 244027 URL: https://gcc.gnu.org/viewcvs?rev=244027&root=gcc&view=rev Log: PR 78534 Revert r244011 r244011 caused regressions on 32-bit hosts. Removed: trunk/gcc/testsuite/gfortran.dg/repeat_7.f90 trunk/gcc/testsuite/gfortran.dg/string_1_lp64.f90 trunk/gcc/testsuite/gfortran.dg/string_3_lp64.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/match.c trunk/gcc/fortran/misc.c trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/target-memory.c trunk/gcc/fortran/target-memory.h trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-const.c trunk/gcc/fortran/trans-const.h trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-io.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans-types.c trunk/gcc/fortran/trans-types.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/dependency_49.f90 trunk/gcc/testsuite/gfortran.dg/repeat_4.f90 trunk/gcc/testsuite/gfortran.dg/scan_2.f90 trunk/gcc/testsuite/gfortran.dg/string_1.f90 trunk/gcc/testsuite/gfortran.dg/string_3.f90 trunk/gcc/testsuite/gfortran.dg/transfer_intrinsic_1.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/args.c trunk/libgfortran/intrinsics/chmod.c trunk/libgfortran/intrinsics/env.c trunk/libgfortran/intrinsics/extends_type_of.c trunk/libgfortran/intrinsics/gerror.c trunk/libgfortran/intrinsics/getlog.c trunk/libgfortran/intrinsics/hostnm.c trunk/libgfortran/intrinsics/string_intrinsics_inc.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unit.c trunk/libgfortran/io/write.c trunk/libgfortran/libgfortran.h
[Bug go/78978] [7 regression] runtime/pprof FAILs on Solaris 2/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78978 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 CC||law at redhat dot com
[Bug c++/69517] [7 regression] SEGV on a VLA with excess initializer elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69517 --- Comment #14 from Marek Polacek --- I don't see the segv anymore with current trunk.
[Bug c/78981] Sign extension bug when stdlib is not explicitly included while using getenv on amd64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78981 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andreas Schwab --- Since getenv is undeclared it is implicitly declared returning int. Use -Werror=implicit-function-declaration.
[Bug libstdc++/78975] uniform_real_distribution should not check RealType with is_floating_point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78975 --- Comment #2 from Charles Karney --- Gag... I see that the standard indeed restricts the implementation to float, double, and long double. Was this really the intention? Everything carries over beautifully for arbitrary types that "behave" as floating point. (The same goes for multiprecision integer types.)
[Bug c/78981] Sign extension bug when stdlib is not explicitly included while using getenv on amd64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78981 --- Comment #1 from Andrew Pinski --- You should be getting an implicit function declared warning with -Wextra -Wall .
[Bug middle-end/78977] [7 Regression] g++7 snprintf() of double produces wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78977 --- Comment #3 from h2+bugs at fsfe dot org --- (In reply to Jakub Jelinek from comment #1) > You haven't provided a self-contained test, so it is hard to know exactly, > but I bet it is the -fprintf-return-value optimization. Try > -fno-printf-return-value if it helps, Yes, that "fixes" it. > if it does, then we really need self-contained small test. Like I said, it doesn't happen on all the time and I have had difficulties extracting it. I could make something smaller than our whole repo, but it would likely still be quite a lot of code. Or is there some way I can make GCC dump an intermediate version of all the code that it actually uses for building the binary? > Perhaps FreeBSD libc snprintf prints %g differently from what GCC expects, > rounds it differently etc. Hm, could be. Note that FreeBSD still has some brokenness in the lib that mandates using -D_GLIBCXX_USE_C99=1 if you want C99 (which is required for c++11). But I thought this was only related to lacking precision in the math library. (In reply to Martin Sebor from comment #2) > It's possible that this bug will be fixed by my patch for bug 78696. The > patch was approved just before the holidays but I am yet to commit it. Let > me retest it and check it in today. Great, let me know if it's merged, then I will try a newer snapshot!
[Bug c/78981] New: Sign extension bug when stdlib is not explicitly included while using getenv on amd64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78981
Bug ID: 78981
Summary: Sign extension bug when stdlib is not explicitly
included while using getenv on amd64.
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rwincey at securifera dot com
Target Milestone: ---
When compiling the following program using
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
#include
#include
//#include
#include
int main( int argc, const char **argv, const char **envp ){
char *src;
close(0);
src = getenv("QUERY_STRING");
if( !src )
exit(1);
puts("Content-Type: text/html\r\n\r");
puts("");
printf("Input %s", src);
return 0;
}
The compiler adds an unnecessary sign extension instruction after the call to
getenv (cdqe), which in my case was changing the address from 0x7fffef3b to
0xef3b.
After some troubleshooting it was discovered that this was due to stdlib.h not
explicitly being defined as an include.
This bug has the potential to cause significant security implications depending
on what operations follow the sign extension. It is suggested that the compiler
either errors out completed during compilation if stdlib is not included, or
properly includes the correct library which will not cause the sign extension
assembly instruction to be added.
[Bug c/78973] warning: ‘memcpy’: specified size between 18446744071562067968 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78973 Markus Trippelsdorf changed: What|Removed |Added Status|WAITING |NEW Summary|[7 Regression] warning: |warning: ‘memcpy’: |‘memcpy’: specified size|specified size between |between |18446744071562067968 and |18446744071562067968 and|18446744073709551615 |18446744073709551615|exceeds maximum object size |exceeds maximum object size |9223372036854775807 |9223372036854775807 |[-Wstringop-overflow=] |[-Wstringop-overflow=] | Severity|normal |enhancement --- Comment #2 from Markus Trippelsdorf --- (In reply to Martin Sebor from comment #1) > That said, unless this particular instance of the warning is a false > positive, I would view this report as an enhancement request rather than a > regression. Can you explain why you marked it as such? No. It was just on oversight. Sorry. I noticed this particular warning while building the Linux kernel. I'm not sure if it makes sense in this context, but haven't looked deeper yet.
[Bug middle-end/78977] [7 Regression] g++7 snprintf() of double produces wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78977 --- Comment #2 from Martin Sebor --- It's possible that this bug will be fixed by my patch for bug 78696. The patch was approved just before the holidays but I am yet to commit it. Let me retest it and check it in today.
[Bug c/78973] [7 Regression] warning: ‘memcpy’: specified size between 18446744071562067968 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78973 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-01-03 Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- I agree that huge decimal numbers can be hard to read (not just in this message but in all others that print them). I have been thinking about an enhancement to the pretty printer that would make it possible to use symbolic constants like INT_MAX or use simple expressions involving them like CHAR_MAX + 2. Using hexadecimal for very large numbers might be worth considering as well. That said, unless this particular instance of the warning is a false positive, I would view this report as an enhancement request rather than a regression. Can you explain why you marked it as such?
[Bug tree-optimization/78899] [7 Regression] Vestorized loop with optmized mask stores motion is completely deleted after r242520.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78899
--- Comment #4 from Jakub Jelinek ---
Somewhat more simplified:
/* PR c++/71077 */
/* { dg-do compile } */
/* { dg-options "-O3" } */
/* { dg-additional-options "-mavx2" { target { i?86-*-* x86_64-*-* } } } */
void
foo (int *a, int n)
{
int b, c;
for (b = 0; b < n; b++)
for (c = 0; c < 32; c++)
if ((b & 1U) << c)
a[b + c] = 0;
}
Apparently we with the patch manage to vectorize both the outer loop and in the
version with non-vectorizable outer loop the inner loop and something is wrong
with rewriting into loop closed ssa.
I guess best would be to arrange for the outer loops to be vectorized before
the inner one, vectorizing the inner one then is likely not beneficial anyway
(it will be only in the scalar loop).
[Bug libstdc++/78968] conflict between gnu's __cxa_thread_atexit and LLVM's/FreeBSD's implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968 --- Comment #11 from Kostik Belousov --- (In reply to Jonathan Wakely from comment #10) > (In reply to Kostik Belousov from comment #9) > > Would older gcc releases fine if FreeBSD exports __cxa_thread_atexit_impl as > > an alias for __cxa_thread_atexit ? > > I think there would still be a duplicate definition of __cxa_thread_atexit > in that case. Yes, but the definitions will be runtime-identical. I mean that the benefit would be that not patched gcc configure will detect presence of __cxa_thread_atexit_impl and libsupc++ only provide trivial wrapper. This means that both implementations use compatible runtime. I am still somewhat puzzled by the 'duplicate definitions' linker diagnostic. It should be satisfied by whatever implementation it finds first. In the op case, somehow a whole static library is linked in, and we do not even know is it libc or libstdc++. > > > Note that there were no FreeBSD release > > which provided __cxa_thread_atexit, although the symbol is already present > > on the stable/11 branch and cannot be removed due ABI compat guarantees. It > > is used by libc++ already, I believe. > > Is that a local change in FreeBSD's copy of libc++? Because there's no > reference to it in the upstream libc++ repo. No, there is no change in libc++. Compiler generated references to __cxa_thread_atexit() are satisfied by libc directly. This was what asked for by the LLVM dev. > > > Request for __cxa_thread_atexit came directly from one of the LLVM > > developers, at least this is how I see the history. > > I understand the desire to have __cxa_thread_atexit available. The point is > that it belongs in the C++ runtime, and that at least two implementations of > the C++ runtime (libsupc++ and libcxxabi) already do the same thing, > defining __cxa_thread_atexit unconditionally, but making use of > __cxa_thread_atexit_impl if libc provides that. BTW, it was not unnatural to provide __cxa_thread_atexit() from libc, given the precedent of __cxa_atexit(3).
[Bug tree-optimization/78899] [7 Regression] Vestorized loop with optmized mask stores motion is completely deleted after r242520.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78899
--- Comment #3 from Jakub Jelinek ---
The original ICE is with -flto, but modified testcase:
/* PR c++/71077 */
/* { dg-do compile { target { i?86-*-* x86_64-*-* } } } */
/* { dg-options "-O3 -march=core-avx2" } */
int *a;
static int b, c, d, e;
static inline int sched_analyze(void) {
for (; b; b++) {
c = 0;
for (; c < 32; c++)
if (b & 1 << c)
a[b + c] = d;
}
return 0;
}
static inline void schedule_insns(void) { e = sched_analyze(); }
int main(void) { schedule_insns(); }
ICEs with the last patch even without -flto.
[Bug libstdc++/78979] 27_io/headers/cstdio/functions_neg.cc FAILs on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78979 --- Comment #2 from Jonathan Wakely --- The Solaris header would be more correct if it did: #if __STDC_VERSION__ < 201112L && __cplusplus < 201402L extern char *gets(char *) __ATTR_DEPRECATED; #endif That would suppress the declaration for C++14, as the C++14 standard requires. You could use fixincludes to do that. I'm not sure how important it is, or if we should just XFAIL the test.
[Bug libstdc++/78979] 27_io/headers/cstdio/functions_neg.cc FAILs on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78979
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-01-03
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
(In reply to Rainer Orth from comment #0)
> The 27_io/headers/cstdio/functions_neg.cc testcase started to FAIL on Solaris
> between between 20160930 and 20161003:
>
> FAIL: 27_io/headers/cstdio/functions_neg.cc (test for errors, line 24)
>
> This is
>
> using std::gets; // { dg-error "has not been declared" }
>
> obviously caused by
>
> 2016-09-30 Jonathan Wakely
>
> PR libstdc++/77795
> * acinclude.m4 (GLIBCXX_CHECK_STDIO_PROTO): Use -std=gnu++11 to check
> for gets.
> * config.h.in: Regenerate.
> * configure: Regenerate.
> * include/c_global/cstdio [!_GLIBCXX_HAVE_GETS] (gets): Only declare
> for C++98 and C++11.
> * include/c_std/cstdio [!_GLIBCXX_HAVE_GETS] (gets): Likewise.
> * testsuite/27_io/headers/cstdio/functions_neg.cc: New test.
>
> Ultimately, this happens because config/sol2.h (TARGET_OS_CPP_BUILTINS)
> always
> has
>
> if (c_dialect_cxx ()) \
> { \
> builtin_define ("__STDC_VERSION__=199901L");\
That should be fine for C++11 and C++14, because they use the C99 standard
library. For C++17 that should define 201112L instead.
> so enabling the gets decl in , which is
>
> #if __STDC_VERSION__ < 201112L
> extern char *gets(char *) __ATTR_DEPRECATED;
> #endif
>
> even for C++11 mode.
Oh, and the Solaris header also puts it in namespace std, right?
I think we should just XFAIL the test for Solaris. We can't prevent the Solaris
header from declaring std::gets, so we shouldn't expect the test to pass.
[Bug libstdc++/78968] conflict between gnu's __cxa_thread_atexit and LLVM's/FreeBSD's implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968 --- Comment #10 from Jonathan Wakely --- (In reply to Kostik Belousov from comment #9) > Would older gcc releases fine if FreeBSD exports __cxa_thread_atexit_impl as > an alias for __cxa_thread_atexit ? I think there would still be a duplicate definition of __cxa_thread_atexit in that case. > Note that there were no FreeBSD release > which provided __cxa_thread_atexit, although the symbol is already present > on the stable/11 branch and cannot be removed due ABI compat guarantees. It > is used by libc++ already, I believe. Is that a local change in FreeBSD's copy of libc++? Because there's no reference to it in the upstream libc++ repo. > Request for __cxa_thread_atexit came directly from one of the LLVM > developers, at least this is how I see the history. I understand the desire to have __cxa_thread_atexit available. The point is that it belongs in the C++ runtime, and that at least two implementations of the C++ runtime (libsupc++ and libcxxabi) already do the same thing, defining __cxa_thread_atexit unconditionally, but making use of __cxa_thread_atexit_impl if libc provides that.
[Bug target/78972] [5/6/7 Regression] poor x86 simd instruction scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972 Thomas Koenig changed: What|Removed |Added Target Milestone|--- |7.0 --- Comment #6 from Thomas Koenig --- (In reply to Andrew Pinski from comment #5) > What happens if you add -fschedule-insns? -fschedule-insns makes the stack use slightly higher. With current trunk: ig25@linux-fd1f:~/Krempel/SMID> gcc -O1 -S example.c && grep subq example.s subq$2416, %rsp ig25@linux-fd1f:~/Krempel/SMID> gcc -O1 -fschedule-insns -S example.c && grep subq example.s subq$2432, %rsp By comparison, gcc 4.8 uses _far_ less stack: ig25@linux-fd1f:~/Krempel/SMID> /usr/bin/gcc -O1 -S example.c && grep subq example.s subq$272, %rsp ig25@linux-fd1f:~/Krempel/SMID> /usr/bin/gcc -O1 -fschedule-insns -S example.c && grep subq example.s subq$416, %rsp -O2 and -O3 do not help either.
[Bug go/78980] runtime/internal/atomic FAILs on 32-bit SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78980 Rainer Orth changed: What|Removed |Added Target Milestone|--- |7.0
[Bug go/78980] New: runtime/internal/atomic FAILs on 32-bit SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78980
Bug ID: 78980
Summary: runtime/internal/atomic FAILs on 32-bit SPARC
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: ro at gcc dot gnu.org
CC: cmang at google dot com
Target Milestone: ---
Host: sparc*-sun-solaris2.*
Target: sparc*-sun-solaris2.*
Build: sparc*-sun-solaris2.*
Between 20160909 and 20160912, there occured a new libgo testsuite failure on
32-bit (only) Solaris/SPARC:
FAIL: runtime/internal/atomic
--- FAIL: TestXadduintptrOnUint64 (0.01s)
atomic_test.go:65: xadduintptr should increase lower-order bits, want
100, got 429496729600
FAIL
FAIL: runtime/internal/atomic
go/runtime/internal/atomic/atomic_test.go has
// Tests that xadduintptr correctly updates 64-bit values. The place where
// we actually do so is mstats.go, functions mSysStat{Inc,Dec}.
func TestXadduintptrOnUint64(t *testing.T) {
/* if runtime.BigEndian != 0 {
// On big endian architectures, we never use xadduintptr to
update
// 64-bit values and hence we skip the test. (Note that
functions
// mSysStat{Inc,Dec} in mstats.go have explicit checks for
// big-endianness.)
return
}*/
but it's commented (and obviously isn't an issue on 64-bit SPARC).
Rainer
[Bug libstdc++/78968] conflict between gnu's __cxa_thread_atexit and LLVM's/FreeBSD's implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968 Kostik Belousov changed: What|Removed |Added CC||kostikbel at ukr dot net --- Comment #9 from Kostik Belousov --- Would older gcc releases fine if FreeBSD exports __cxa_thread_atexit_impl as an alias for __cxa_thread_atexit ? Note that there were no FreeBSD release which provided __cxa_thread_atexit, although the symbol is already present on the stable/11 branch and cannot be removed due ABI compat guarantees. It is used by libc++ already, I believe. Request for __cxa_thread_atexit came directly from one of the LLVM developers, at least this is how I see the history.
[Bug go/78978] [7 regression] runtime/pprof FAILs on Solaris 2/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78978 --- Comment #1 from Ian Lance Taylor --- If the libstdc++ approach works and is acceptable, it seems to me we should do the same for libgo.
[Bug target/67321] [ARM] Exploit Wide Add operations when appropriate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67321 --- Comment #5 from Christophe Lyon --- I think this was fixed by Michael's commit r235402.
[Bug rtl-optimization/78116] [7 regression] Performance drop after r241173 on avx512 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78116 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Any progress on this?
[Bug middle-end/78977] [7 Regression] g++7 snprintf() of double produces wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78977 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org, ||msebor at gcc dot gnu.org Component|c++ |middle-end Target Milestone|--- |7.0 Summary|g++7 snprintf() of double |[7 Regression] g++7 |produces wrong code with|snprintf() of double |-O3 |produces wrong code with ||-O3 --- Comment #1 from Jakub Jelinek --- You haven't provided a self-contained test, so it is hard to know exactly, but I bet it is the -fprintf-return-value optimization. Try -fno-printf-return-value if it helps, if it does, then we really need self-contained small test. Perhaps FreeBSD libc snprintf prints %g differently from what GCC expects, rounds it differently etc.
[Bug testsuite/77734] FAIL: gcc.dg/plugin/must-tail-call-1.c -fplugin=./must_tail_call_plugin.so (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77734 Rainer Orth changed: What|Removed |Added Target|hppa-unknown-linux-gnu |hppa-unknown-linux-gnu, ||sparc-sun-solaris2.* CC||ro at gcc dot gnu.org Host|hppa-unknown-linux-gnu |hppa-unknown-linux-gnu, ||sparc-sun-solaris2.* Build|hppa-unknown-linux-gnu |hppa-unknown-linux-gnu, ||sparc-sun-solaris2.* --- Comment #1 from Rainer Orth --- Also on Solaris/SPARC.
[Bug c++/70834] Incorrect warning for placement new when conditionally used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70834 --- Comment #2 from Matt Godbolt --- if constexpr is of course the right solution here, for certain. I appreciate the compiler determining which if() branch to take in the non-constexpr case is tricky.
[Bug libstdc++/78979] 27_io/headers/cstdio/functions_neg.cc FAILs on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78979 Rainer Orth changed: What|Removed |Added Target Milestone|--- |7.0
[Bug libstdc++/78979] New: 27_io/headers/cstdio/functions_neg.cc FAILs on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78979
Bug ID: 78979
Summary: 27_io/headers/cstdio/functions_neg.cc FAILs on Solaris
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: redi at gcc dot gnu.org
Target Milestone: ---
Host: *-*-solaris2.*
Target: *-*-solaris2.*
Build: *-*-solaris2.*
The 27_io/headers/cstdio/functions_neg.cc testcase started to FAIL on Solaris
between between 20160930 and 20161003:
FAIL: 27_io/headers/cstdio/functions_neg.cc (test for errors, line 24)
This is
using std::gets; // { dg-error "has not been declared" }
obviously caused by
2016-09-30 Jonathan Wakely
PR libstdc++/77795
* acinclude.m4 (GLIBCXX_CHECK_STDIO_PROTO): Use -std=gnu++11 to check
for gets.
* config.h.in: Regenerate.
* configure: Regenerate.
* include/c_global/cstdio [!_GLIBCXX_HAVE_GETS] (gets): Only declare
for C++98 and C++11.
* include/c_std/cstdio [!_GLIBCXX_HAVE_GETS] (gets): Likewise.
* testsuite/27_io/headers/cstdio/functions_neg.cc: New test.
Ultimately, this happens because config/sol2.h (TARGET_OS_CPP_BUILTINS) always
has
if (c_dialect_cxx ()) \
{ \
builtin_define ("__STDC_VERSION__=199901L");\
so enabling the gets decl in , which is
#if __STDC_VERSION__ < 201112L
extern char *gets(char *) __ATTR_DEPRECATED;
#endif
even for C++11 mode. The gcc-5 and gcc-6 branches are also affected. I'm
uncertain how best to proceed. Conditionalizing the __STDC_VERSION__ define
based on cxx_dialect
might be an option...
Rainer
[Bug libstdc++/78956] std::thread doesn't fully meet LWG 2097 requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78956 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-03 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- Fixed on trunk so far.
[Bug go/78978] New: [7 regression] runtime/pprof FAILs on Solaris 2/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78978 Bug ID: 78978 Summary: [7 regression] runtime/pprof FAILs on Solaris 2/x86 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ro at gcc dot gnu.org CC: cmang at google dot com Target Milestone: --- Host: i386-pc-solaris2.* Target: i386-pc-solaris2.* Build: i386-pc-solaris2.* Some time ago, runtime/pprof started to FAIL on Solaris/x86 with as and ld: ld.so.1: a.out: fatal: a.out: hardware capability (CA_SUNW_HW_1) unsupported: 0x440 [ AES SSSE3 ] FAIL: runtime/pprof The same issue has been fixed before for libgo.so by linking it with -mclear-hwcap, but that change isn't effective here since the runtime/pprofl/check a.out is linked with # At least for now, we need -static-libgo for this test, because # otherwise we can't get the line numbers. # Also use -fno-inline to get better results from the memory profiler. runtime_pprof_check_GOCFLAGS = -static-libgo -fno-inline Adding $(HWCAP_LDCAPS) here fixes the immediate failure, but leaves the general issue of libgo.a in the presence of hwcaps. I see two options: * Build either all of libgo or at least aeshash.la with -Wa,-nH (as is done in libstdc++) to avoid generating hwcaps in the first place, or * Make -static-libgo imply -mclear-hwcap. Rainer
[Bug libstdc++/78968] conflict between gnu's __cxa_thread_atexit and LLVM's/FreeBSD's implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968 --- Comment #8 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #7) > Right. This can be worked around for any GCC releases except 5.5, 6.4 and > 7.1, but anything older can't be fixed. Sorry, I edited that sentence half way through writing it. I meant: Right. This can be worked around for the future GCC releases 5.5, 6.4 and 7.1, but anything older can't be fixed.
[Bug libstdc++/78968] conflict between gnu's __cxa_thread_atexit and LLVM's/FreeBSD's implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968 --- Comment #7 from Jonathan Wakely --- Right. This can be worked around for any GCC releases except 5.5, 6.4 and 7.1, but anything older can't be fixed.
[Bug go/78978] [7 regression] runtime/pprof FAILs on Solaris 2/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78978 Rainer Orth changed: What|Removed |Added Target Milestone|--- |7.0
[Bug libstdc++/78968] conflict between gnu's __cxa_thread_atexit and LLVM's/FreeBSD's implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968 --- Comment #6 from h2+bugs at fsfe dot org --- Thanks for your quick response! To be honest, I only have a very basic understanding of the matter. The original discussion of the implementation in FreeBSD can found here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192320 https://reviews.freebsd.org/rS303795 If you feel that this should be solved differently on FreeBSD's end, I will re-open discussion there. If that doesn't lead anywhere a workaround in GCC would be great, but since this actually affects all currently released GCCs on FreeBSD11, I would prefer an OS solution as gcc patches would likely only land in the most recent GCC-branch(es), right?
[Bug fortran/78976] [7 Regression] FAIL: gfortran.dg/dependency_49.f90 and gfortran.dg/transfer_intrinsic_1.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78976 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-01-03 Ever confirmed|0 |1 --- Comment #1 from Janne Blomqvist --- Yes, it was part of the patch for PR 78534 (of which there is a tediously long thread) which was split out in order to bisect potential performance regressions easier. Unfortunately I forgot to commit the part which fixed the scan-tree-dump-times patterns as well together with that. But they are part of the big patch which was committed as r244011. Does it work as of r244011?
[Bug c++/70834] Incorrect warning for placement new when conditionally used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70834 --- Comment #1 from Roel Standaert --- I guess you can't really expect the compiler to correctly infer the value of the if statement at compile time? If std::enable_if is used instead of an if statement, GCC won't generate a warning: https://godbolt.org/g/GO7Ao7 Also, if you use C++17's "if constexpr", it's fine: https://godbolt.org/g/H58gBI
[Bug c++/78977] New: g++7 snprintf() of double produces wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78977
Bug ID: 78977
Summary: g++7 snprintf() of double produces wrong code with -O3
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
We have current snapshots of g++ in our nightly build matrix and are seeing two
tests fail at run-time for strange reasons.
% g++7 --version
g++7 (FreeBSD Ports Collection) 7.0.0 20161225 (experimental)
% uname -a
FreeBSD celegans.imp.fu-berlin.de 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0
r306420: Thu Sep 29 01:43:23 UTC 2016
r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
Both tests involve the following function (although other passing tests use
this code, too):
template
inline typename Size::Type
appendNumber(TTarget & target, double source)
{
char buffer[32];
size_t len = snprintf(buffer, sizeof(buffer), "%g", source);
write(target, (char *)buffer, len);
return len;
}
An example of test_random in our build matrix is here:
http://cdash.seqan.de/testSummary.php?project=1&name=test_test_random&date=2017-01-03
test_random_beta_write fails with:
/home/mi/h4nn3s/nightly-builds/testroot/checkout-develop/FreeBSD-11.0-RELEASE-p1_g++7_64/tests/random/test_random_beta.h:130
Assertion failed : CharString("~Beta(0.5,0.3)") == os.str() was: ~Beta(0.5,0.3)
!= ~Beta(0.5,0.3
[NON-XML-CHAR-0x8]
)
Or sometimes just:
CharString("~Beta(0.5,0.3)") == os.str() was: ~Beta(0.5,0.3) != ~Beta(0.5,0.3
From the debugger the string looks like:
1 = "~Beta(0.5,0.3\000\377\177\000\000)"
So apparently some bogus content from behind the double is included in the
string.
The issue only appears with -O3 , not with any lower optimization levels. This
makes it really hard for me to debug, because all the relevant code is
optimized out.
Can you help me with this? What do you need for further analysis? Unfortunately
I have not yet been able to extract a minimal working example outside our test
matrix, a regular call to snprintf seems to work. And I know that more than the
two failing tests use the code in question so it's definitely not something
always fails (although it is reproducible on exactly these two tests).
Thank you for your help!
[Bug fortran/78976] New: [7 Regression] FAIL: gfortran.dg/dependency_49.f90 and gfortran.dg/transfer_intrinsic_1.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78976 Bug ID: 78976 Summary: [7 Regression] FAIL: gfortran.dg/dependency_49.f90 and gfortran.dg/transfer_intrinsic_1.f90 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org CC: jb at gcc dot gnu.org Target Milestone: --- Target: aarch64 arm Hi, Since commit r244003, I've noticed that 2 fortran tests now fail on arm and aarch64 targets: gfortran.dg/dependency_49.f90 -O scan-tree-dump-times original "__var_1" 4 gfortran.dg/transfer_intrinsic_1.f90 -O scan-tree-dump-times original "MIN_EXPR" 1 I couldn't find the patch on gcc-patches, so I'm filing this bug report instead of replying to the thread. The commit message says: PR 78534 Modify string copy to avoid -Wstringop-overflow warning When the character length is changed from int to size_t the existing algorithm causes a -Wstringop-overflow warning with -O1 on the gfortran.dg/allocate_deferred_char_scalar_1.f03 testcase. This change is committed separately from the character length size change in order to make bisecting potential performance issues easier. 2017-01-02 Janne Blomqvist PR fortran/78534 * trans-expr.c (gfc_trans_string_copy): Rework string copy algorithm to avoid -Wstringop-overflow warning.
[Bug tree-optimization/76957] [7 regression] FAIL: gcc.dg/graphite/scop-dsyr2k.c scan-tree-dump-times graphite "number of SCoPs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76957 Rainer Orth changed: What|Removed |Added Target|arm-none-eabi |arm-none-eabi |hppa-unknown-linux-gnu |hppa-unknown-linux-gnu ||i386-pc-solaris2, ||sparc-sun-solaris2, ||i686-pc-linux-gnu, ||x86_64-pc-linux-gnu CC||ro at gcc dot gnu.org Summary|FAIL: |[7 regression] FAIL: |gcc.dg/graphite/scop-dsyr2k |gcc.dg/graphite/scop-dsyr2k |.c scan-tree-dump-times |.c scan-tree-dump-times |graphite "number of SCoPs |graphite "number of SCoPs --- Comment #5 from Rainer Orth --- This is a regression on trunk, actually, present on many more (all?) systems.
[Bug libstdc++/78956] std::thread doesn't fully meet LWG 2097 requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78956 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Tue Jan 3 13:31:26 2017 New Revision: 244022 URL: https://gcc.gnu.org/viewcvs?rev=244022&root=gcc&view=rev Log: Add deleted std::thread(const thread&&) constructor PR libstdc++/78956 * include/std/thread (thread(const thread&&)): Add deleted constructor. * testsuite/30_threads/thread/cons/lwg2097.cc: New test. Added: trunk/libstdc++-v3/testsuite/30_threads/thread/cons/lwg2097.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/thread
[Bug libstdc++/78975] uniform_real_distribution should not check RealType with is_floating_point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78975 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-03 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Jonathan Wakely --- The standard explicitly says using boost::multiprecision::float128 as a RealType is undefined, but we could accept it as a conforming extension. The suggestion seems like the best way to do that.
[Bug libstdc++/78968] conflict between gnu's __cxa_thread_atexit and LLVM's/FreeBSD's implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968 --- Comment #5 from Jonathan Wakely --- It seems entirely wrong for libc to be providing any __cxa entry point called by the compiler, such as __cxa_thread_atexit. It should come from the C++ runtime, such as libsupc++, or libcxxabi, or FreeBSD's libcxxrt. We can work around it, but it's still wrong.
[Bug libstdc++/78975] New: uniform_real_distribution should not check RealType with is_floating_point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78975 Bug ID: 78975 Summary: uniform_real_distribution should not check RealType with is_floating_point Product: gcc Version: 6.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: charles at karney dot com Target Milestone: --- random's uniform_real_distribution checks the its template argument with is_floating_point. This means it can't be used with high-precision types such as boost::multiprecision::float128. See https://svn.boost.org/trac/boost/ticket/12720 John Maddock (the maintainer of the boost multiprecision libraries) says that, because float128 qualifies as is_class it's not possible for it also to be is_float_point. On the other hand, numeric_limits can (and is) specialized for float128. So I'd like to request that the tests in uniform_real_distribution and other real distributions be changed from static_assert(std::is_floating_point<_RealType>::value, "template argument not a floating point type"); to something like static_assert(std::numeric_limits<_RealType>::is_specialised && !std::numeric_limits<_RealType>::is_integer, "template argument not a floating point type"); Thanks!
[Bug libstdc++/78968] conflict between gnu's __cxa_thread_atexit and LLVM's/FreeBSD's implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968 --- Comment #4 from Jonathan Wakely --- I wonder why FreeBSD chose to do it that way, instead of providing the _impl function, which would also work with LLVM's libcxxabi.
[Bug c/78974] New: STM32L4 CPU read burst access equal to or more than 9 registers to FMC returns corrupted data starting from the 9th read word
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78974
Bug ID: 78974
Summary: STM32L4 CPU read burst access equal to or more than 9
registers to FMC returns corrupted data starting from
the 9th read word
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: abdullah_khalil at mentor dot com
Target Milestone: ---
I have been working on STM32L486ZG board. There is an issue with the board when
connected to external SRAM using FSMC (Flexible static Memory Controller) as
written in the Errata as follow:
“CPU read burst access equal to or more than 9 registers to FMC returns
corrupted data starting from the 9th read word. These bursts can only be
generated by Cortex®-M4 CPU and not by the other masters (i.e not by DMA).
This issue occurs when the stack is remapped on the external memory on the FMC
and POP operations are performed with 9 or more registers.
This also occurs when LDM/VLDM operations are used with 9 or more registers.”
So we can’t use LDM instructions in this case when executing from external SRAM
in regular cases. For example following instruction will cause an error:
ldmia sp!, {r4,r5,r6,r7,r8,r9,r0,r11,pc}
the value of pc is not restored correctly thus causing an error in the flow.
Is there an optimization present in gcc or some flag present to capture this
issue and limit the number of registers used in one instruction.
[Bug libstdc++/78968] conflict between gnu's __cxa_thread_atexit and LLVM's/FreeBSD's implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968 --- Comment #3 from Jonathan Wakely --- (In reply to h2+bugs from comment #0) > This is a bug in gcc. The libsupc++ configuration assumes that there are > exactly two possibilities: either libc is glibc and implements > __cxa_thread_atexit() using __cxa_thread_atexit_impl(), or libsupc++ must > provide an implementation on its own. Although this isn't quite right, there's no assumption of glibc. The two possibilities are that only __cxa_thread_atexit_impl exists, or that neither __cxa_thread_atexit_impl nor __cxa_thread_atexit exists. There's no assumption about the provenance of __cxa_thread_atexit_impl.
[Bug libstdc++/78968] conflict between gnu's __cxa_thread_atexit and LLVM's/FreeBSD's implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-03 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- I agree.
[Bug libstdc++/78968] conflict between gnu's __cxa_thread_atexit and LLVM's/FreeBSD's implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968 --- Comment #2 from Jonathan Wakely --- Created attachment 40448 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40448&action=edit Check for __cxa_thread_atexit in libc Does this fix it?
[Bug bootstrap/77569] [7 Regression] self tests fail when not using C locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77569 Jakub Jelinek changed: What|Removed |Added Attachment #40446|0 |1 is obsolete|| Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Created attachment 40447 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40447&action=edit gcc7-pr77569.patch Actually, the cb.error callback receives the message translated, without further modifications like expansion of %s etc., so if we just don't strstr for a substring, but instead strcmp with the whole message (after translation), I think it should work both in C/locales without translation for this message as well as locales that have it translated. As my iconv handles ebcdic correctly, I can't test though...
[Bug bootstrap/77569] [7 Regression] self tests fail when not using C locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77569 --- Comment #5 from Jakub Jelinek --- Created attachment 40446 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40446&action=edit gcc7-pr77569.patch Untested fix that implements the verification - if that message has been translated, the self-test will still work, but will not catch ebcdic handling bugs the same as when it is not translated.
[Bug bootstrap/77569] [7 Regression] self tests fail when not using C locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77569
--- Comment #4 from Jakub Jelinek ---
I still can't reproduce on x86_64-linux, but looking at the above mentioned
line (in input.c from that date), there is:
/* Detect and record errors emitted by libcpp/charset.c:init_iconv_desc
when the local iconv build doesn't support the conversion. */
if (strstr (msgid, "not supported by iconv"))
{
s_singleton->m_num_iconv_errors++;
return true;
}
/* Otherwise, we have an unexpected error. */
abort ();
The problem is that msgid the on_error callback receives is if ENABLE_NLS
already transformed on the libcpp side through
# define _(msgid) dgettext (PACKAGE, msgid)
and thus for de_DE.UTF-8 we'd need to search either for
"wird von iconv nicht unterstützt" or "not supported by iconv" depending on if
dgettext succeeded in translating it or not.
So, either we need to nuke this strstr and just never abort, nuke the test,
always force LC_ALL, LANGUAGE etc. env vars for self tests, or check if it has
been translated.
[Bug target/78631] [Intel MPX] libmpxwrappers shared library leads to a non-bounds-preserving memcpy()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78631 --- Comment #13 from Ilya Enkovich --- (In reply to Alexander Ivchenko from comment #12) > Fixed with r243942 It should be backported to GCC6.
[Bug driver/78863] error on -fsanitize suggests invalid -fsanitize=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78863 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Summary|[6 Regression] error on |error on -fsanitize |-fsanitize suggests invalid |suggests invalid |-fsanitize=all |-fsanitize=all --- Comment #7 from Martin Liška --- Fixed on 6 branch.
[Bug driver/78863] [6 Regression] error on -fsanitize suggests invalid -fsanitize=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78863 --- Comment #6 from Martin Liška --- Author: marxin Date: Tue Jan 3 12:15:32 2017 New Revision: 244021 URL: https://gcc.gnu.org/viewcvs?rev=244021&root=gcc&view=rev Log: Do not suggest -fsanitize=all (PR driver/78863). 2017-01-03 Martin Liska Backport from mainline 2016-12-21 Jakub Jelinek Martin Liska PR driver/78863 * gcc.c (driver::build_option_suggestions): Do not add -fsanitize=all as a suggestion candidate. 2017-01-03 Martin Liska Backport from mainline 2016-12-21 Martin Liska PR driver/78863 * gcc.dg/spellcheck-options-13.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.dg/spellcheck-options-13.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/gcc.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/78886] Segmentation fault malloc and volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78886 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Summary|[5/6 Regression]|Segmentation fault malloc |Segmentation fault malloc |and volatile |and volatile| --- Comment #12 from Martin Liška --- Fixed on all active branches.
