[Bug tree-optimization/64853] [5 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64853 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-29 CC||jakub at gcc dot gnu.org Target Milestone|--- |5.0 Summary|wrong code at -Os and above |[5 Regression] wrong code |on x86_64-linux-gnu |at -Os and above on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- This started with r217560, the first difference is during VRP2: Visiting statement: _13 = (signed char) g_68; +Match-and-simplified (signed char) g_68 to -56(OVF) Found new range for _13: [-56, -56] and various others, leading to -_10: ~[1, 254] +_10: [255, +INF] .MEM_11: VARYING -g_12: [0, 255] -_13: VARYING +g_12: [255, 255] +_13: [-56, -1] etc. Haven't checked if the changes are correct or not.
[Bug tree-optimization/64853] [5 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64853 --- Comment #2 from Jakub Jelinek --- I think the problem is that: Visiting statement: _15 = _56 & 1; Applying pattern match.pd:312, gimple-match.c:13772 Applying pattern match.pd:235, gimple-match.c:13525 Match-and-simplified _56 & 1 to 0 Intersecting [0, 0] and [0, 1] to [0, 0] Found new range for _15: [0, 0] might be reasonable during iteration, when not yet considering the backedge as executable, but we actually never visit this statement again, perhaps due to match-and-simplify looking at earlier statements. Richard, can you please have a look?
[Bug jit/64810] jit not working on armv7hl ("ld: error: /tmp/libgccjit-ZGemdr/fake.so uses VFP register arguments, /tmp/ccJFCBsE.o does not")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64810
--- Comment #18 from ramana.radhakrishnan at arm dot com ---
On 28/01/15 17:58, dmalcolm at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64810
>
> --- Comment #9 from David Malcolm ---
> Thanks Ramana.
>
> I attempted a build of the jit with the configuration you suggested,
> specifically:
>
>$ ../src/configure \
>--enable-host-shared \
>--enable-languages=jit,c++ \
>--disable-bootstrap \
>--enable-checking=release \
>--prefix=/home/dmalcolm/gcc-git-jit/install-jit \
>--with-arch=armv7-a \
>--with-float=hard \
>--with-fpu=vfpv3-d16
>
> Unfortunately, I see the same failures.
>
> Hacking in a "-v" into the driver invocation in jit-playback.c...
>
> diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c
> index d2549a0..5f570a7 100644
> --- a/gcc/jit/jit-playback.c
> +++ b/gcc/jit/jit-playback.c
> @@ -2271,6 +2271,8 @@ invoke_driver (const char *ctxt_progname,
>time. */
> ADD_ARG ("-fno-use-linker-plugin");
>
> + ADD_ARG ("-v");
> +
> /* pex argv arrays are NULL-terminated. */
> ADD_ARG (NULL);
>
> ...I see that libgccjit attempts to invoke the driver to convert the .s
> to a .so, but it fails like so:
>
> Target: armv7l-unknown-linux-gnueabihf
> Configured with: ../src/configure --enable-host-shared
> --enable-languages=jit,c++ --disable-bootstrap --enable-checking=release
> --prefix=/home/dmalcolm/gcc-git-jit/install-jit --with-arch=armv7-a
> --with-float=hard --with-fpu=vfpv3-d16
> Thread model: posix
> gcc version 5.0.0 20150126 (experimental) (GCC)
> COLLECT_GCC_OPTIONS='-shared' '-o' '/tmp/libgccjit-VxeXM1/fake.so'
> '-fno-use-linker-plugin' '-v' '-march=armv7-a' '-mfloat-abi=hard'
> '-mfpu=vfpv3-d16' '-mtls-dialect=gnu'
> as -v -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -meabi=5 -o
> /tmp/ccCY7c5L.o /tmp/libgccjit-VxeXM1/fake.s
> GNU assembler version 2.24 (armv7hl-redhat-linux-gnueabi) using BFD version
> version 2.24
> COMPILER_PATH=
> LIBRARY_PATH=/home/dmalcolm/gcc-git-jit/build-jit-comment8/gcc/:/lib/:/usr/lib/
> COLLECT_GCC_OPTIONS='-shared' '-o' '/tmp/libgccjit-VxeXM1/fake.so'
> '-fno-use-linker-plugin' '-v' '-march=armv7-a' '-mfloat-abi=hard'
> '-mfpu=vfpv3-d16' '-mtls-dialect=gnu'
> ld --eh-frame-hdr -shared -dynamic-linker /lib/ld-linux-armhf.so.3 -X -m
> armelf_linux_eabi -o /tmp/libgccjit-VxeXM1/fake.so /lib/crti.o
> /home/dmalcolm/gcc-git-jit/build-jit-comment8/gcc/crtbeginS.o
> -L/home/dmalcolm/gcc-git-jit/build-jit-comment8/gcc /tmp/ccCY7c5L.o -lgcc
> --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
> --no-as-needed
> /home/dmalcolm/gcc-git-jit/build-jit-comment8/gcc/crtendS.o /lib/crtn.o
> ld: error: /tmp/libgccjit-VxeXM1/fake.so uses VFP register arguments,
> /tmp/ccCY7c5L.o does not
> ld: failed to merge target specific data of file /tmp/ccCY7c5L.o
>
> That said, with the "test-empty.c" testcase, the generated
> "fake.s" looks like this:
>
> .cpu arm10tdmi
> .fpu softvfp
> .eabi_attribute 20, 1
> .eabi_attribute 21, 1
> .eabi_attribute 23, 3
> .eabi_attribute 24, 1
> .eabi_attribute 25, 1
> .eabi_attribute 26, 2
> .eabi_attribute 30, 2
> .eabi_attribute 34, 0
> .arm
> .syntax divided
> .file "fake.c"
> .text
> .Ltext0:
> .cfi_sections .debug_frame
> .Letext0:
> .section.debug_line,"",%progbits
> .Ldebug_line0:
> .section.debug_str,"MS",%progbits,1
> .LASF0:
> .ascii "/tmp/libgccjit-La3Yzk/fake.c\000"
> .LASF1:
> .ascii "libgccjit 5.0.0 20150126 (experimental) -fPIC -O3 -"
> .ascii "g --param ggc-min-expand=0 --param ggc-min-heapsize"
> .ascii "=0\000"
> .ident "GCC: (GNU) 5.0.0 20150126 (experimental)"
> .section.note.GNU-stack,"",%progbits
>
> In particular, I'm guessing that the line:
> .fpu softvfp
> is at fault here.
>
> This appears to come from arm.c:arm_file_start:
> 25689 if (TARGET_SOFT_FLOAT)
> 25690 {
> 25691 fpu_name = "softvfp";
> 25692 }
> 25693 else
> and on debugging:
> (gdb) p global_options.x_arm_float_abi
> $1 = ARM_FLOAT_ABI_SOFT
>
> Is this value bogus, given the configure-time options?
Sorry about the slow response, I was unable to check email last evening.
Yes this value is bogus as are the other .cpu values - the assembler
output suggests to me that the configure time options aren't being
passed at all from the driver down when used as a jit. Given the
configure options I would expect
.arch armv7-a
.fpu vfpv3-d16
and an EABI attribute tag to indicate the PCS.
I think you've worked this out reading down-thread.
Ramana
>
> (if so, I'm guessing this is a jit-specific state-management issue)
>
[Bug tree-optimization/64853] [5 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64853 --- Comment #3 from Jakub Jelinek --- Simulating block 2 Simulating block 2 Simulating block 25 Simulating block 15 Simulating block 4 Simulating block 3 Simulating block 5 Simulating block 6 Simulating block 4 Simulating block 12 Simulating block 13 Simulating block 26 Simulating block 14 Simulating block 8 Simulating block 7 Simulating block 15 Simulating block 16 Simulating block 17 Simulating block 10 Simulating block 8 Simulating block 9 Simulating block 18 Simulating block 19 Simulating block 23 Simulating block 11 Simulating block 21 Simulating block 10 Simulating block 20 Simulating block 22 Simulating block 11 So, we indeed simulate block 5 only the first time after simulating block 15 (i.e. when edge 25 -> 15 is executable and 14 -> 15 is not), and never again (block 15 itself is simulated again with both incoming edges executable). Wonder if for match-and-simplify during the VRP folding that looks at other statements we shouldn't somehow note at which statements we've actually looked when making the decision (but how?) and mark the statement for resimulation.
[Bug libgomp/64719] omp_get_num_procs should not account for cpu affinity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64719 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek --- This is very much intentional. If you confine the process to certain subset of cores/HW threads, then normally all threads that it creates are confined that way. So as far as OpenMP is concerned, the other cores/HW threads are not online for this process.
[Bug target/64844] [5 Regression] Vectorization inhibited in gcc5 when loop starts with elem[1], aarch64 perf regression from 4.9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64844 --- Comment #3 from Richard Biener --- (In reply to Andrew Pinski from comment #2) > t.c:8:5: note: === vect_update_slp_costs_according_to_vf === > t.c:8:5: note: cost model: the vector iteration cost = 26 divided by the > scalar iteration cost = 10 is greater or equal to the vectorization factor = > 2. > t.c:8:5: note: not vectorized: vectorization not profitable. > t.c:8:5: note: not vectorized: vector version will never be profitable. > t.c:8:5: note: bad operation or unsupported loop bound. > > > A cost model issue with cortex-a57. The cost model changed in GCC 5 for > cortex-a57. I think this is due to unaligned loads. But we (should) have known misalignment here and thus peeling for alignment should be able to arrange for aligned vectors. Iff aarch64 can align the stack properly. If not then the first loop should behave the same as the 2nd... Right: t.c:7:5: note: vect_model_load_cost: aligned. t.c:7:5: note: vect_get_data_access_cost: inside_cost = 5, outside_cost = 0. t.c:7:5: note: vect_model_load_cost: aligned. t.c:7:5: note: vect_get_data_access_cost: inside_cost = 10, outside_cost = 0. t.c:7:5: note: Try peeling by 1 t.c:7:5: note: Alignment of access forced using peeling. t.c:7:5: note: Peeling for alignment will be applied. but the costs are odd. For the first (aligned loop we get) t.c:7:5: note: Cost model analysis: Vector inside of loop cost: 16 Vector prologue cost: 8 Vector epilogue cost: 11 Scalar iteration cost: 10 Scalar outside cost: 0 Vector outside cost: 19 prologue iterations: 0 epilogue iterations: 0 Calculated minimum iters for profitability: 10 while for the 2nd: t.c:7:5: note: Cost model analysis: Vector inside of loop cost: 26 Vector prologue cost: 18 Vector epilogue cost: 21 Scalar iteration cost: 10 Scalar outside cost: 0 Vector outside cost: 39 prologue iterations: 1 epilogue iterations: 1 while the vector inside of loop cost should be the same. The issue is that both vect_enhance_data_refs_alignment at analysis time and vectorizable_load at transform time account for the cost via the add_stmt_cost hook. With that fixed we get t.c:7:5: note: Cost model analysis: Vector inside of loop cost: 16 Vector prologue cost: 18 Vector epilogue cost: 21 Scalar iteration cost: 10 Scalar outside cost: 0 Vector outside cost: 39 prologue iterations: 1 epilogue iterations: 1 Calculated minimum iters for profitability: 12 which is more reasonable and vectorizes both loops as expected.
[Bug libgomp/61798] OpenMP exit code 155, profiling related?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61798 --- Comment #1 from Jakub Jelinek --- Exit code 155 is indeed that the process has been killed by SIGPROF signal. Without a testcase there is hard to say anything more on this, libgomp certainly doesn't install a signal handler for this signal, nor generate it, nor do anything else with it, so I bet you'd get exactly the same situation if you just used pthread_create yourself instead of OpenMP.
[Bug libgomp/61798] OpenMP exit code 155, profiling related?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61798 --- Comment #2 from Andrew Pinski --- What target is this on?
[Bug target/64844] [5 Regression] Vectorization inhibited in gcc5 when loop starts with elem[1], aarch64 perf regression from 4.9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64844 --- Comment #4 from Richard Biener --- Created attachment 34613 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34613&action=edit patch Patch I am testing.
[Bug tree-optimization/64853] [5 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64853
--- Comment #4 from Jakub Jelinek ---
--- gcc/tree-vrp.c.jj2015-01-28 08:39:51.0 +0100
+++ gcc/tree-vrp.c2015-01-29 10:44:37.395688127 +0100
@@ -7093,14 +7093,14 @@ vrp_valueize_1 (tree name)
if (TREE_CODE (name) == SSA_NAME)
{
value_range_t *vr = get_value_range (name);
- if (range_int_cst_singleton_p (vr))
-return vr->min;
/* If the definition may be simulated again we cannot follow
this SSA edge as the SSA propagator does not necessarily
re-visit the use. */
gimple def_stmt = SSA_NAME_DEF_STMT (name);
if (prop_simulate_again_p (def_stmt))
return NULL_TREE;
+ if (range_int_cst_singleton_p (vr))
+return vr->min;
}
return name;
}
fixes this, even when a VR is singleton, it might be singleton just because it
is singleton only in the first iteration and not afterwards.
That said, I'd worry that this patch might degrade VRP folding too much.
[Bug tree-optimization/64853] [5 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64853
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from Richard Biener ---
Mine. I thought I had handled this correctly with vrp_valueize_1 doing
/* Return the singleton value-range for NAME if that is a constant
but signal to not follow SSA edges. */
static inline tree
vrp_valueize_1 (tree name)
{
if (TREE_CODE (name) == SSA_NAME)
{
value_range_t *vr = get_value_range (name);
if (range_int_cst_singleton_p (vr))
return vr->min;
/* If the definition may be simulated again we cannot follow
this SSA edge as the SSA propagator does not necessarily
re-visit the use. */
gimple def_stmt = SSA_NAME_DEF_STMT (name);
if (prop_simulate_again_p (def_stmt))
^^^
return NULL_TREE;
but I guess the singleton handling needs to be guarded with the same.
[Bug tree-optimization/64853] [5 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64853 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #6 from Richard Biener --- I have a patch (CCP is also affected).
[Bug fortran/64854] New: No bound check for explicit-shape arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64854 Bug ID: 64854 Summary: No bound check for explicit-shape arrays Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: bugs at stellardeath dot org I assumed that the following would be catched by -fcheck=bounds, array "a" is passed as an explicit-shape array to subroutine "testsub" with the invalid bounds "n1", "n2": program test use m1 implicit none integer :: n1, n2 real :: a(1:10) ! Setup invalid indices: n1 = 1024*1024 n2 = 1024*1024*2 call testsub(a, n1, n2) contains subroutine testsub(a, n1, n2) integer :: n1, n2 real :: a(n1:n2) integer :: i do i = n1, n2 a(i) = 0 end do end subroutine end program But this happily produces a segfault. My gfortran version: #> gfortran-4.9 --version GNU Fortran (SUSE Linux) 4.9.0 Copyright (C) 2014 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING Kind regards, Lorenz
[Bug c/64803] [5 Regression] __LINE__ inside macro is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64803 --- Comment #3 from Dodji Seketeli --- Created attachment 34614 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34614&action=edit Candidate fix This is the patch that I am currently testing. It seems to fix the issue for me. Please let me know if it works for you.
[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60322 --- Comment #7 from vehre at gcc dot gnu.org --- I just want to report some progress. I have a patch that fixes the issues in comment #1 and #3. The tree-dump shows, that a class array is handled the same for a class array as for a "type array" as described in comment #2. Currently I am in a battle with the code in comment #5. Somehow the routine taking care about the association of the temporary real array needed for the type is (double precision) does not get the array descriptors, neither the one for the original array ar nor the one for the temporary real-array.
[Bug tree-optimization/64853] [5 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64853
--- Comment #7 from Richard Biener ---
Sth like
Index: gcc/tree-ssa-propagate.c
===
--- gcc/tree-ssa-propagate.c(revision 220235)
+++ gcc/tree-ssa-propagate.c(working copy)
@@ -364,6 +364,7 @@ simulate_stmt (gimple stmt)
FOR_EACH_EDGE (e, ei, bb->succs)
add_control_edge (e);
}
+ return;
}
else if (val == SSA_PROP_INTERESTING)
{
@@ -377,6 +378,45 @@ simulate_stmt (gimple stmt)
if (taken_edge)
add_control_edge (taken_edge);
}
+
+ /* If there are no SSA uses on the stmt whose defs are simulated
+ again then this stmt will be never visited again. */
+ bool has_simulate_again_uses = false;
+ use_operand_p use_p;
+ ssa_op_iter iter;
+ if (gimple_code (stmt) == GIMPLE_PHI)
+{
+ edge_iterator ei;
+ edge e;
+ tree arg;
+ FOR_EACH_EDGE (e, ei, gimple_bb (stmt)->preds)
+ if (!(e->flags & EDGE_EXECUTABLE)
+ || ((arg = PHI_ARG_DEF_FROM_EDGE (stmt, e))
+ && TREE_CODE (arg) == SSA_NAME
+ && !SSA_NAME_IS_DEFAULT_DEF (arg)
+ && prop_simulate_again_p (SSA_NAME_DEF_STMT (arg
+ {
+ has_simulate_again_uses = true;
+ break;
+ }
+}
+ else
+FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, SSA_OP_USE)
+ {
+ gimple def_stmt = SSA_NAME_DEF_STMT (USE_FROM_PTR (use_p));
+ if (!gimple_nop_p (def_stmt)
+ && prop_simulate_again_p (def_stmt))
+ {
+ has_simulate_again_uses = true;
+ break;
+ }
+ }
+ if (!has_simulate_again_uses)
+{
+ if (dump_file && (dump_flags & TDF_DETAILS))
+ fprintf (dump_file, "marking stmt to be not simulated again\n");
+ prop_set_simulate_again (stmt, false);
+}
}
/* Process an SSA edge worklist. WORKLIST is the SSA edge worklist to
for what we discussed on IRC. Probably makes sense to omit PHI handling
first as that's definitely "interesting". I'll bootstrap that separately
on the fix for this PR (without handling PHIs).
[Bug libffi/64855] New: FAIL: libffi.call/* -W -Wall -Wno-psabi -O0 -DABI_NUM=* -DABI_ATTR=* execution test on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64855 Bug ID: 64855 Summary: FAIL: libffi.call/* -W -Wall -Wno-psabi -O0 -DABI_NUM=* -DABI_ATTR=* execution test on x86_64-apple-darwin* Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libffi Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: doko at gcc dot gnu.org, howarth at bromo dot med.uc.edu, iains at gcc dot gnu.org, rth at gcc dot gnu.org Host: x86_64-apple-darwin* Target: x86_64-apple-darwin* Build: x86_64-apple-darwin* After r220158 all the lib tests of the kind 'libffi.call/* -W -Wall -Wno-psabi -O0 -DABI_NUM=* -DABI_ATTR=*' fail on x86_64-apple-darwin*: see https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg03329.html. While these failures are exposed by r220158, they were for new tests introduced by r219477. Note that trying to run struct5.exe compiled with /opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/ /opt/gcc/work/libffi/testsuite/libffi.call/struct5.c -W -Wall -Wno-psabi -O2 -DABI_NUM=FFI_STDCALL -DABI_ATTR=__STDCALL__ -I/opt/gcc/build_w/x86_64-apple-darwin14.1.0/i386/libffi/include -I/opt/gcc/work/libffi/include -I/opt/gcc/build_w/x86_64-apple-darwin14.1.0/i386/libffi/ -L/opt/gcc/build_w/x86_64-apple-darwin14.1.0/i386/libffi/.libs -L/opt/gcc/build_w/x86_64-apple-darwin14.1.0/i386/libstdc++-v3/src/.libs -Wl,-allow_stack_execute -shared-libgcc -lffi -lm -m32 -o ./struct5.exe gives dyld: Library not loaded: /opt/gcc/gcc4.10w/lib/i386/libffi.4.dylib Referenced from: /Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/struct5.exe Reason: image not found Trace/BPT trap First I don't understand why /opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/ refers to my install directory. Second, I don't find any libffi library in my install directories under x86_64-apple-darwin14 (4.8 to 5.0), while I found them for x86_64-apple-darwin10 and 4.8 (r209181). Is this intended?
[Bug libffi/64855] FAIL: libffi.call/* -W -Wall -Wno-psabi -O0 -DABI_NUM=* -DABI_ATTR=* execution test on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64855 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-29 CC||fxcoudert at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed.
[Bug target/64047] [5 Regression] ICE: Segmentation fault when compiling gcc.dg/torture/pr52429.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64047 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Perhaps the ppc backend needs to catch up all the recent i386 backend target attribute / target pragma related handling changes.
[Bug target/64783] -march=armv8.1-a should be supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64783 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-29 Ever confirmed|0 |1 --- Comment #1 from Richard Earnshaw --- Agreed, but for GCC-5, I would expect the best we could do would be to pass the appropriate flags through to the assembler, to permit inline assembly to use the new instructions.
[Bug fortran/64854] No bound check for explicit-shape arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64854 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-01-29 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Well, you give wrong information to the compiler. How do expect it to handle your mistake: in testsub -fcheck=bounds checks that n1<=i<=n2 which is the case. What you ask for is a check that a(n1:n2) is inside a(1:10), AFAIK such check is not implemented and I don't have any idea about how difficult it is to implement it. I am inclined to close tis PR as INVALID or WONTFIX.
[Bug ada/64349] [5 Regression] Bootstrapping Ada fails on darwin(9|10).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64349
--- Comment #11 from Dominique d'Humieres ---
I have bootstrapped x86_64-apple-darwin10 with the patch. Any plan to commit it
soon?
Thanks,
Dominique
> Le 27 janv. 2015 à 04:00, demoonlit at panathenaia dot halfmoon.jp
> a écrit :
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64349
>
> yuta tomino changed:
>
> What|Removed |Added
>
> CC||demoonlit at panathenaia dot
> halfm
> ||oon.jp
>
> --- Comment #10 from yuta tomino
> ---
> Please move #ifdef in the correct order.
>
> --- a/gcc/ada/env.c
> +++ b/gcc/ada/env.c
> @@ -44,12 +44,6 @@
> #include
> #endif
>
> -#if defined (__APPLE__) && !defined (__arm__)
> -/* On Darwin, _NSGetEnviron must be used for shared libraries; but it is not
> - available on iOS. */
> -#include
> -#endif
> -
> #if defined (__vxworks)
> #if defined (__RTP__)
> /* On VxWorks 6 Real-Time process mode, environ is defined in unistd.h.
> */
> @@ -78,6 +72,12 @@
> #include "system.h"
> #endif /* IN_RTS */
>
> +#if defined (__APPLE__) && !defined (__arm__)
> +/* On Darwin, _NSGetEnviron must be used for shared libraries; but it is not
> + available on iOS. */
> +#include
> +#endif
> +
> #ifdef __cplusplus
> extern "C" {
> #endif
> @@ -215,11 +215,11 @@ __gnat_environ (void)
> #elif defined (sun)
> extern char **_environ;
> return _environ;
> +#elif defined (__APPLE__) && !defined (__arm__)
> + return *_NSGetEnviron ();
> #elif ! (defined (__vxworks))
> extern char **environ;
> return environ;
> -#elif defined (__APPLE__) && !defined (__arm__)
> - return *_NSGetEnviron ();
> #else
> return environ;
> #endif
>
> --
> You are receiving this mail because:
> You reported the bug.
[Bug middle-end/64805] Specific use of __attribute ((always_inline)) breaks MPX functionality with -fcheck-pointer-bounds -mmpx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64805 --- Comment #4 from ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Thu Jan 29 11:03:02 2015 New Revision: 220240 URL: https://gcc.gnu.org/viewcvs?rev=220240&root=gcc&view=rev Log: gcc/ PR middle-end/64805 * ipa-inline.c (early_inliner): Rebuild IPA_REF_CHKP reference to avoid error in cgraph node verification. gcc/testsuite/ PR middle-end/64805 * gcc.target/i386/pr64805.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/pr64805.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c trunk/gcc/testsuite/ChangeLog
[Bug target/64477] [4.9 Regression] x86 sse unnecessary GPR spill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64477 Jakub Jelinek changed: What|Removed |Added Summary|[4.9/5 Regression] x86 sse |[4.9 Regression] x86 sse |unnecessary GPR spill |unnecessary GPR spill --- Comment #10 from Jakub Jelinek --- Assuming fixed on the trunk then.
[Bug fortran/64854] No bound check for explicit-shape arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64854 --- Comment #2 from Lorenz Hüdepohl --- (Please remove the line "use m1" from my example, its a leftover from a previous version) I'm not denying that there is a mistake in the example program. I just hoped that -fcheck=bounds would save me from this kind of mistake. Please consider this not a bug report then, but a feature request :) It really would help tremendously if this kind of misbehaviour could be checked at run-time via -fcheck-bounds.
[Bug c/64856] New: Initializing struct not accepted in gnu99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64856
Bug ID: 64856
Summary: Initializing struct not accepted in gnu99
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
struct A {
unsigned long b;
};
struct B {
struct A c[2];
};
struct B d = { .c = { [0 ... 1] = (struct A){ .b = -1UL } } };
$ ./cc1 -quiet j.c -std=gnu90
$ ./cc1 -quiet j.c -std=gnu99
j.c:9:35: error: initializer element is not constant
struct B d = { .c = { [0 ... 1] = (struct A){ .b = -1UL } } };
^
j.c:9:35: note: (near initialization for ‘d.c[0]’)
j.c:9:35: error: initializer element is not constant
j.c:9:35: note: (near initialization for ‘d.c[1]’)
This is bad with gnu11 as a default.
[Bug c/64856] Initializing struct not accepted in gnu99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64856 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-01-29 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Mine.
[Bug preprocessor/64803] [5 Regression] __LINE__ inside macro is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64803 --- Comment #4 from Alexander Klimov --- Thanks! Your patch works for llvm.
[Bug libstdc++/64857] New: Headers missing from and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64857 Bug ID: 64857 Summary: Headers missing from and Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org In C++11 mode doesn't include any of the standard headers: #if __cplusplus < 201103L #include #endif and doesn't include or . I'll fix this in stage 1.
[Bug libstdc++/64857] Headers missing from and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64857 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-01-29 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug preprocessor/64803] [5 Regression] __LINE__ inside macro is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64803 --- Comment #5 from Jakub Jelinek --- Note, instead of doing such ugly hacks with __LINE__, IMHO gtest should use __COUNTER__ instead, that doesn't care if it is on one line or multiple, and doesn't get upset if you put more such macros on the same line.
[Bug middle-end/64809] [5 Regression] ICE at -O3 with -g enabled on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64809 --- Comment #10 from ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Thu Jan 29 12:20:55 2015 New Revision: 220241 URL: https://gcc.gnu.org/viewcvs?rev=220241&root=gcc&view=rev Log: gcc/testsuite/ PR middle-end/64809 * gcc.dg/pr64809.c: Delete. Removed: trunk/gcc/testsuite/gcc.dg/pr64809.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/64844] [5 Regression] Vectorization inhibited in gcc5 when loop starts with elem[1], aarch64 perf regression from 4.9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64844 --- Comment #5 from Richard Biener --- Author: rguenth Date: Thu Jan 29 12:53:39 2015 New Revision: 220244 URL: https://gcc.gnu.org/viewcvs?rev=220244&root=gcc&view=rev Log: 2015-01-29 Richard Biener PR tree-optimization/64844 * tree-vect-loop.c (vect_estimate_min_profitable_iters): Always dump cost model analysis. * tree-vect-data-refs.c (vect_enhance_data_refs_alignment): Do not register adjusted load/store costs here. * gcc.dg/vect/pr64844.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/pr64844.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-loop.c
[Bug target/64844] [5 Regression] Vectorization inhibited in gcc5 when loop starts with elem[1], aarch64 perf regression from 4.9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64844 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug tree-optimization/64853] [5 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64853 Richard Biener changed: What|Removed |Added Keywords||wrong-code Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener --- Fixed.
[Bug tree-optimization/64853] [5 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64853 --- Comment #9 from Richard Biener --- Author: rguenth Date: Thu Jan 29 13:50:37 2015 New Revision: 220247 URL: https://gcc.gnu.org/viewcvs?rev=220247&root=gcc&view=rev Log: 2015-01-29 Richard Biener PR tree-optimization/64853 * tree-vrp.c (vrp_valueize_1): Do not return anything if the stmt will get simulated again. * tree-ssa-ccp.c (valueize_op_1): Likewise. * gcc.dg/torture/pr64853.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr64853.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c trunk/gcc/tree-vrp.c
[Bug tree-optimization/64746] Loop with nested load/stores is not vectorized using aggressive if-conversion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64746 --- Comment #3 from ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Thu Jan 29 13:52:28 2015 New Revision: 220248 URL: https://gcc.gnu.org/viewcvs?rev=220248&root=gcc&view=rev Log: gcc/ PR tree-optimization/64746 * tree-if-conv.c (mask_exists): New function. (predicate_mem_writes): Save created mask with given size for further use. (stmt_is_root_of_bool_pattern): Remove argument VAR and store to it. (ifcvt_repair_bool_pattern): Collect all statements that are root of bool pattern and use iterative algorithm to remove multiple uses of predicates, display number of required iterations. gcc/testsuite/ PR tree-optimization/64746 * gcc.target/i386/avx2-vect-aggressive-1.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/avx2-vect-aggressive-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c
[Bug ipa/64858] New: [5 Regression] Libreoffice build failure caused by ICF crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64858
Bug ID: 64858
Summary: [5 Regression] Libreoffice build failure caused by ICF
crash
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
trippels@gcc2-power8 ~ % cat xpathobject.ii
template class A
{
reference_type *m_pBody;
public:
A (const A &) { m_pBody->acquire (); }
};
class B;
class C
{
protected:
B *_pInterface;
};
template class I : C
{
public:
I (interface_type *);
};
class B
{
public:
virtual void acquire ();
};
class D
{
protected:
void acquire ();
};
template class J : D, public Ifc1
{
void
acquire ()
{
D::acquire ();
}
};
class K : B
{
};
class L;
class F
{
A m_pDocument;
F (A const &, int &&);
};
class XUnoTunnel;
class XEventTarget;
template class WeakImplHelper3 : D, B
{
void
acquire ()
{
D::acquire ();
}
};
template class G
{
public:
void
acquire ()
{
WeakImplHelper3 ();
}
};
struct H
{
H ()
: mxAttribList (new J), mxCurrentHandler (0), mxDocHandler (0),
mxTokenHandler (0)
{
}
I > mxAttribList;
I mxCurrentHandler;
I mxDocHandler;
I mxTokenHandler;
};
class L : public G
{
};
class M : public J
{
public:
M ();
};
template I::I (interface_type *p1)
{
B *a = static_cast (static_cast (p1));
_pInterface = a;
_pInterface->acquire ();
}
F::F (A const &p1, int &&) : m_pDocument (p1) { I (new M); }
trippels@gcc2-power8 ~ % g++ -O2 -std=gnu++11 -c xpathobject.ii
xpathobject.ii:90:66: internal compiler error: Segmentation fault
F::F (A const &p1, int &&) : m_pDocument (p1) { I (new M); }
^
0x10a141eb crash_signal
../../gcc/gcc/toplev.c:383
0x11070c88 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:2845
0x11070c88 ipa_icf::sem_function::init()
../../gcc/gcc/ipa-icf.c:786
0x11074923 ipa_icf::sem_item_optimizer::parse_nonsingleton_classes()
../../gcc/gcc/ipa-icf.c:1865
0x1107c353 ipa_icf::sem_item_optimizer::execute()
../../gcc/gcc/ipa-icf.c:1721
0x1107d173 ipa_icf_driver
../../gcc/gcc/ipa-icf.c:2461
0x1107d173 ipa_icf::pass_ipa_icf::execute(function*)
../../gcc/gcc/ipa-icf.c:2509
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug other/51153] OpenACC implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51153 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus --- The basic implementation is now (= GCC 5) in: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01258.html See also https://gcc.gnu.org/wiki/OpenACC Even though, it is not fully working, yet. I think this PR can now be closed and instead one could concentrate on the remaining issues elsewhere (PRs with 'openacc' keyword, pending patches).
[Bug target/15184] [4.8/4.9/5 Regression] Direct access to byte inside word not working with -march=pentiumpro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184 --- Comment #32 from Jeffrey A. Law --- Author: law Date: Thu Jan 29 14:30:45 2015 New Revision: 220249 URL: https://gcc.gnu.org/viewcvs?rev=220249&root=gcc&view=rev Log: PR target/15184 * combine.c (try_combine): If I0 is a memory load and I3 a store to a related address, increase the "goodness" of doing a 4-insn combination with I0-I3. (make_field_assignment): Handle SUBREGs in the ior+and case. PR target/15184 * gcc.target/i386/pr15184-1.c: New test. * gcc.target/i386/pr15184-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr15184-1.c trunk/gcc/testsuite/gcc.target/i386/pr15184-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog
[Bug target/15184] [4.8/4.9 Regression] Direct access to byte inside word not working with -march=pentiumpro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|4.8.5 |5.0 Summary|[4.8/4.9/5 Regression] |[4.8/4.9 Regression] Direct |Direct access to byte |access to byte inside word |inside word not working |not working with |with -march=pentiumpro |-march=pentiumpro --- Comment #33 from Jeffrey A. Law --- Fixed on trunk. Not planning to backport to release branches (requires 4 insn combine code).
[Bug target/60925] [4.9/5 Regression] hppa: can't find a register in class 'R1_REGS' while reloading 'asm'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #12 from Jeffrey A. Law --- See c#11.
[Bug libgomp/61798] OpenMP exit code 155, profiling related?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61798 --- Comment #3 from Manuel Kessler --- Thank you both for trying to help. @Andrew: This is on x86_64, running kernel 3.1.0 on an (admittedly old) openSUSE 11.4. @Jakub: You are probably right, but the question remains, how a SIGPROF (probably from the profiling machinery added with -pg) can escape up to the user level instead of being catched by said machinery - and what to do against it, of course. Ciao, Manuel
[Bug sanitizer/64839] libsanitizer shouldn't require
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64839 --- Comment #1 from Harald van Dijk --- FWIW, libsanitizer builds just fine if the rpc references are forcibly removed, like so: --- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc +++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc @@ -131,7 +131,6 @@ #include #include #include -#include #include #include #include @@ -1148,19 +1147,6 @@ CHECK_SIZE_AND_OFFSET(group, gr_gid); CHECK_SIZE_AND_OFFSET(group, gr_mem); #if SANITIZER_LINUX && !SANITIZER_ANDROID -CHECK_TYPE_SIZE(XDR); -CHECK_SIZE_AND_OFFSET(XDR, x_op); -CHECK_SIZE_AND_OFFSET(XDR, x_ops); -CHECK_SIZE_AND_OFFSET(XDR, x_public); -CHECK_SIZE_AND_OFFSET(XDR, x_private); -CHECK_SIZE_AND_OFFSET(XDR, x_base); -CHECK_SIZE_AND_OFFSET(XDR, x_handy); -COMPILER_CHECK(__sanitizer_XDR_ENCODE == XDR_ENCODE); -COMPILER_CHECK(__sanitizer_XDR_DECODE == XDR_DECODE); -COMPILER_CHECK(__sanitizer_XDR_FREE == XDR_FREE); -#endif - -#if SANITIZER_LINUX && !SANITIZER_ANDROID COMPILER_CHECK(sizeof(__sanitizer_FILE) <= sizeof(FILE)); CHECK_SIZE_AND_OFFSET(FILE, _flags); CHECK_SIZE_AND_OFFSET(FILE, _IO_read_ptr); But that's clearly not acceptable :)
[Bug ipa/64858] [5 Regression] Libreoffice build failure caused by ICF crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64858 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.0
[Bug c++/64859] New: -Wabi-tag is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64859 Bug ID: 64859 Summary: -Wabi-tag is not documented Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org The -Wabi-tag warning is not documented, it only shows up in gcc --help=warnings -Wabi-tag Warn if a subobject has an abi_tag attribute that the complete object type does not have
[Bug c++/49508] Bogus "control reaches end of non-void function" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49508
Jonathan Wakely changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #6 from Jonathan Wakely ---
I'm seeing this frequently too, I was about to create a new PR as follows:
struct Y { };
struct X {
X(short*);
};
X f() { int i; return &i; }
w.cc: In function ‘X f()’:
w.cc:5:24: error: could not convert ‘& i’ from ‘int*’ to ‘X’
X f() { int i; return &i; }
^
w.cc:5:27: warning: control reaches end of non-void function [-Wreturn-type]
X f() { int i; return &i; }
^
The warning is useless, because as soon as the error is fixed the warning will
go away, so it adds nothing but noise to the output.
And it's also confusing because there's a return statement *right* *there*! I
can see it and GCC even printed it out! :-) It only reaches the end because GCC
decides to ignore the return statement that fails in order to continue
compiling the rest of the function.
This doesn't happen in all cases where the return statement has an error, e.g.
if the example above does return i; instead of return &i; there's no warning.
[Bug sanitizer/64717] -fsanitize=vptr leads to warning: ‘’ may be used uninitialized in this function [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64717 Gert-jan Los changed: What|Removed |Added CC||gerrit.los at gmail dot com --- Comment #1 from Gert-jan Los --- Created attachment 34615 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34615&action=edit test case with virtual destructor version: gcc version 5.0.0 20150128 (experimental) (GCC) options: -O -fsanitize=vptr -Werror=uninitialized PostScript_Back_End.C.i: In function ‘void fn1()’: PostScript_Back_End.C.i:8:34: error: ‘’ is used uninitialized in this function [-Werror=uninitialized]
[Bug sanitizer/64717] -fsanitize=vptr leads to warning: ‘’ may be used uninitialized in this function [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64717 --- Comment #2 from Gert-jan Los --- Created attachment 34616 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34616&action=edit test case with virtual base class version: gcc version 5.0.0 20150128 (experimental) (GCC) options: -O -fsanitize=vptr -Werror=uninitialized gap_widths.C.i: In function ‘void fn1()’: gap_widths.C.i:13:41: error: ‘’ is used uninitialized in this function [-Werror=uninitialized]
[Bug lto/64860] New: multiple definition of typeinfo in 5.0 (4.9.2 works)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860 Bug ID: 64860 Summary: multiple definition of typeinfo in 5.0 (4.9.2 works) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: sirl at gcc dot gnu.org Created attachment 34617 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34617&action=edit Simple testcase. Use "make" to reproduce. While trying to construct a testcase for a 4.8 to 4.9 change of LTO linking behaviour, I stumbled over this (just re-tested with r220248): g++-5 -flto -fuse-linker-plugin -O2 -Wall -Wextra -c file1.cpp g++-5 -flto -fuse-linker-plugin -O2 -Wall -Wextra -c file2.cpp gcc-5 -flto -fuse-linker-plugin -Wl,-r -nostdlib -o lib1.lib file1.o gcc-5 -flto -fuse-linker-plugin -Wl,-r -nostdlib -o lib2.lib file2.o g++-5 -flto -fuse-linker-plugin -O2 -o testexe lib1.lib lib2.lib lib2.lib:(.rodata+0x0): multiple definition of `typeinfo name for CDialogBase' lib1.lib:(.rodata+0x0): first defined here collect2: error: ld returned 1 exit status # g++-5 -v Using built-in specs. COLLECT_GCC=g++-5 COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/5/lto-wrapper Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,fortran --with-gxx-include-dir=/usr/include/c++/5 --enable-ssp --disable-libssp --disable-libvtv --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --with-default-libstdcxx-abi=c++98 --enable-version-specific-runtime-libs --enable-linker-build-id --enable-linux-futex --program-suffix=-5 --without-system-libunwind --enable-multilib --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux Thread model: posix gcc version 5.0.0 20150129 (experimental) (SUSE Linux) gcc-4.8.3 and 4.9.2 compile and link the same code just fine.
[Bug lto/64860] multiple definition of typeinfo in 5.0 (4.9.2 works)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Richard Biener --- Honza?
[Bug lto/64860] [5 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860 Richard Biener changed: What|Removed |Added Keywords||lto, wrong-code Known to work||4.9.2 Target Milestone|--- |5.0 Summary|multiple definition of |[5 Regression] multiple |typeinfo in 5.0 (4.9.2 |definition of typeinfo in |works) |5.0 (4.9.2 works)
[Bug c++/49508] [4.8/4.9/5 regression] Bogus "control reaches end of non-void function" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49508 Jason Merrill changed: What|Removed |Added Status|REOPENED|ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Summary|Bogus "control reaches end |[4.8/4.9/5 regression] |of non-void function" |Bogus "control reaches end |warning |of non-void function" ||warning --- Comment #7 from Jason Merrill --- 4.4 didn't warn, so it seems reasonable to call it a regression.
[Bug middle-end/64394] ICE: in build_linearized_memory_access, at graphite-interchange.c:121 (isl_constraint.c:558: expecting integer value) with -floop-interchange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64394 Jana Saout changed: What|Removed |Added CC||jana at saout dot de --- Comment #1 from Jana Saout --- I'm presumably seeing this bug being hit when trying to build gcc 5 with lto-bootstrapping. My backtrace is garbled, but the "isl_constraint.cc": "expecting integer value" is also at the core of the ICE.
[Bug sanitizer/64670] -fsanitize=vptr leads to "undefined reference to `typeinfo for class'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64670 --- Comment #4 from Jason Merrill --- This seems like a bug in the user's code, not the compiler. If the class is defined in a header with #pragma interface, there needs to be a matching #pragma implementation somewhere to cause the typeinfo and such to be emitted. clang doesn't run into this because it just ignores #pragma interface.
[Bug jit/64810] jit not working on armv7hl ("ld: error: /tmp/libgccjit-ZGemdr/fake.so uses VFP register arguments, /tmp/ccJFCBsE.o does not")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64810 --- Comment #19 from David Malcolm --- (In reply to ramana.radhakrish...@arm.com from comment #18) [...snip...] > Yes this value is bogus as are the other .cpu values - the assembler > output suggests to me that the configure time options aren't being > passed at all from the driver down when used as a jit. Given the > configure options I would expect > > .arch armv7-a > .fpu vfpv3-d16 > > and an EABI attribute tag to indicate the PCS. > > I think you've worked this out reading down-thread. Thanks for the confirmation. I'm testing a patch for this now.
[Bug c++/64521] [4.9/5 Regression] ICE with -frepo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64521 --- Comment #3 from Jason Merrill --- Author: jason Date: Thu Jan 29 16:09:56 2015 New Revision: 220251 URL: https://gcc.gnu.org/viewcvs?rev=220251&root=gcc&view=rev Log: PR c++/64521 * repo.c (repo_emit_p): It's OK for a clone to be extern at this point. Added: trunk/gcc/testsuite/g++.dg/template/repo11.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/repo.c
[Bug c++/49508] [4.8/4.9/5 regression] Bogus "control reaches end of non-void function" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49508 --- Comment #8 from Jason Merrill --- Author: jason Date: Thu Jan 29 16:10:08 2015 New Revision: 220252 URL: https://gcc.gnu.org/viewcvs?rev=220252&root=gcc&view=rev Log: PR c++/49508 * semantics.c (finish_return_stmt): Suppress -Wreturn-type on erroneous return statement. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/g++.old-deja/g++.jason/report.C
[Bug c++/49508] [4.8/4.9/5 regression] Bogus "control reaches end of non-void function" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49508 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #9 from Jason Merrill --- Fixed for GCC 5.
[Bug fortran/64861] New: Possible wrong code with BIND(C) and PRIVATE + slightly bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64861
Bug ID: 64861
Summary: Possible wrong code with BIND(C) and PRIVATE +
slightly bogus warning
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: diagnostic, wrong-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Blocks: 49111
This PR is partially identical to PR49111 / See also
https://groups.google.com/forum/#!topic/comp.lang.fortran/RedeUCqh12c ("Private
interfaces with iso_c_binding")
In modules, gfortran warns for module procedures - and for interface procedures
with BIND(C) attribute, which are marked as PRIVATE:
Warning: Symbol 'my_c_routine' at (1) is marked PRIVATE but has been given
the binding label 'my_c_routine'
This warning seems to be on by default (not checked) and is slightly bogus.
There are two meanings of PRIVATE: (a) avoid cluttering the name space when
USE-ing a module. (b) To hide a symbol from the rest of the world.
Fortran's meaning is (a), although some users think of (b) - seemingly also the
warning writer.
Additionally, there might be a wrong-code issue: gfortran marks PRIVATE module
procedures (and variables) which are not otherwise used as being only used in
that file - based on the knowledge that it cannot be used (without knowledge of
the name mangling of gfortran).
I think it currently misses the check for BIND(C). (BTW: A BIND(C) function
without a name (i.e. name="" or an internal procedure) can continue to be
marked as static.)
THUS:
* Check whether the TREE_PUBLIC handling is correctly done for BIND(C)+PRIVATE
(honoring additionally whether it has a binding name or not.)
The following items are the same/similar to PR49111
* Check whether the warning message makes really sense - and if so, improve the
wording and consider not to enable it by default.
* If continuing to warn: Consider not to warn at all for INTERFACE and only for
module procedures.
[Bug jit/64780] toplevel configure should reject jit as a language if --enable-host-shared is not supplied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64780 --- Comment #3 from David Malcolm --- Author: dmalcolm Date: Thu Jan 29 16:25:14 2015 New Revision: 220253 URL: https://gcc.gnu.org/viewcvs?rev=220253&root=gcc&view=rev Log: PR jit/64780: configure: --enable-host-shared and the jit ChangeLog: PR jit/64780 * configure.ac: Require the user to explicitly specify --enable-host-shared if the jit is enabled. * configure: Regenerate. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac
[Bug libffi/64855] FAIL: libffi.call/* -W -Wall -Wno-psabi -O0 -DABI_NUM=* -DABI_ATTR=* execution test on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64855 --- Comment #2 from Richard Henderson --- I apologize for my mis-diagnosis earlier. These tests are not expected to pass on Darwin at present. Disabling them in the testsuite is the best thing to do for now. Long term, someone needs to figure out the problems with Darwin in the upstream libffi respository, so we can move Darwin onto the shared code base with the rest of the x86 ports.
[Bug libffi/64855] FAIL: libffi.call/* -W -Wall -Wno-psabi -O0 -DABI_NUM=* -DABI_ATTR=* execution test on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64855 --- Comment #3 from howarth at bromo dot med.uc.edu --- FYI, I reported struct5.exe execution failures upstream earlier in the thread... https://sourceware.org/ml/libffi-discuss/2015/msg00019.html https://sourceware.org/ml/libffi-discuss/2015/msg00020.html https://sourceware.org/ml/libffi-discuss/2015/msg00021.html
[Bug c/47781] warnings from custom printf format specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781 Tom Tromey changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #11 from Tom Tromey --- (In reply to jos...@codesourcery.com from comment #4) > For the general issue, my inclination is that we should add plugin hooks > into the format checking machinery that allow plugins to define formats > with the full flexibility of all the format checking datastructures in > GCC. I agree this makes sense for the general case, but I wanted to point out that requiring a plugin for the simple cases is significantly harder for users than some in-source extension mechanism. E.g., firefox has a logging printf that accepts "%hs" to print char16_t* strings. This extension means that printf checking can't be used here. Requiring a plugin to deal with this situation would also be difficult. However letting one write __attribute__((printf, 1, 2, "hs", char16_t*)) would solve this nicely. I suppose I think that a format-for-a-specific-type is the most common kind of extension and so may deserve special treatment.
[Bug c++/64521] [4.9/5 Regression] ICE with -frepo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64521 --- Comment #5 from Jason Merrill --- Author: jason Date: Thu Jan 29 16:47:32 2015 New Revision: 220255 URL: https://gcc.gnu.org/viewcvs?rev=220255&root=gcc&view=rev Log: PR c++/64521 * repo.c (repo_emit_p): It's OK for a clone to be extern at this point. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/template/repo11.C Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/repo.c
[Bug c/64862] New: printf attribute should accept other string types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862
Bug ID: 64862
Summary: printf attribute should accept other string types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Consider this source:
#include
#include
extern void p (const char16_t *fmt, ...)
__attribute__((__printf__ (1, 2)));
void f()
{
p(u"%d\n", 23);
}
Currently gcc rejects this attribute:
pokyo. gcc --syntax-only -std=c11 -Wall r.c
r.c:5:3: warning: ‘__printf__’ attribute directive ignored [-Wattributes]
__attribute__((__printf__ (1, 2)));
^
I don't see why it should, though.
It seems to me that it could accept wchar_t, char16_t, or char32_t
strings as the format argument.
[Bug c++/64863] New: error for use of members of a forward declared enum is poor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64863
Bug ID: 64863
Summary: error for use of members of a forward declared enum is
poor
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tbsaunde at gcc dot gnu.org
consider this test case
enum class foo;
int bar();
int main()
{
if (bar() < foo::baz)
return 0;
return 1;
}
produces
test.cpp: In function ‘int main()’:
test.cpp:7:14: error: ‘baz’ is not a member of ‘foo’
if (bar() < foo::baz)
^
which while true isn't terrible helpful. I'd think it would be better to say
only a forward declaration of foo has been seen, and to use members you need
the full definition.
[Bug target/64844] [5 Regression] Vectorization inhibited in gcc5 when loop starts with elem[1], aarch64 perf regression from 4.9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64844 --- Comment #7 from Chris Jones --- Confirmed fixed at TOT. Thank you!
[Bug c++/64521] [4.9/5 Regression] ICE with -frepo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64521 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #4 from Jason Merrill --- Fixed.
[Bug libffi/64855] FAIL: libffi.call/* -W -Wall -Wno-psabi -O0 -DABI_NUM=* -DABI_ATTR=* execution test on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64855 --- Comment #4 from Iain Sandoe --- (In reply to Richard Henderson from comment #2) > I apologize for my mis-diagnosis earlier. These tests are not > expected to pass on Darwin at present. Disabling them in the > testsuite is the best thing to do for now. adding: && ![istarget "*-*-darwin*"] should be enough - the targetabis list is initialised to "" before that test.
[Bug preprocessor/64864] New: [5 Regression] preprocessor linemarkers break configure checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64864 Bug ID: 64864 Summary: [5 Regression] preprocessor linemarkers break configure checks Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: dodji at gcc dot gnu.org For example (this happens for many projects that check for the boost version): ... checking for working strtod... yes checking for gettimeofday... yes checking for Boost headers version >= 1.36.0... yes checking for Boost's header version... configure: error: invalid value: boost_major_version= markus@x4 core % cat test.cpp #include boost-lib-version = BOOST_LIB_VERSION markus@x4 core % g++ -E test.cpp # 1 "test.cpp" # 1 "" # 1 "" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 1 "" 2 # 1 "test.cpp" # 1 "/usr/include/boost/version.hpp" 1 3 4 # 2 "test.cpp" 2 boost-lib-version = # 2 "test.cpp" 3 4 "1_56" markus@x4 core % /usr/x86_64-pc-linux-gnu/gcc-bin/4.9.2/g++ -E test.cpp # 1 "test.cpp" # 1 "" # 1 "" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 1 "" 2 # 1 "test.cpp" # 1 "/usr/include/boost/version.hpp" 1 3 4 # 2 "test.cpp" 2 boost-lib-version = "1_56" I know that these linemarkers are valid. But is it really necessary that they appear in the middle of statements? Using -P is a workaround, that apparently nobody uses in configure scripts. See also PR64604.
[Bug preprocessor/64864] [5 Regression] preprocessor linemarkers break configure checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64864 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- But they should. Though, it is true that it affects quite a lot of packages, e.g. cclive emacs ember gnote ksh libcmis libgpg-error libixion liborcus ncurses openldap to name a few. As before, the change was introduced with PR60723.
[Bug preprocessor/64864] [5 Regression] preprocessor linemarkers break configure checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64864 --- Comment #2 from Jakub Jelinek --- I really think this is porting_to.html material, rather than a bug report.
[Bug libstdc++/64865] New: std::allocator::construct/destroy not called for specialization of std::allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64865
Bug ID: 64865
Summary: std::allocator::construct/destroy not called for
specialization of std::allocator
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Per N4296 [container.requirements.general]/3:
For the components affected by this subclause that declare an allocator_type,
objects stored in these components shall be constructed using the
allocator_traits::construct function and destroyed using the
allocator_traits::destroy function (20.7.8.2).
libstdc++ optimizes out calls to `construct` and `destroy` for types with
trivial construction/destruction when the allocator type is a specialization of
std::allocator: see implementation of __uninitialized_copy_a(InputIterator,
InputIterator, ForwardIterator, allocator<>&) in bits/stl_uninitialized.h, and
_Destroy(ForwardIterator, ForwardIterator, allocator<>&) in
bits/stl_construct.h. However, not every instance of std::allocator necessarily
has side-effect free implementation of construct/destruct, since
[namespace.std]/1 allows users to specialize templates in the standard
namespace if the declaration depends on a user-defined type. For example, this
program:
#include
#include
#include
struct mytype {
int value;
mytype(int v) : value{v} {}
operator int() const { return value; }
};
int constructions = 0, destructions = 0;
namespace std {
template <>
struct allocator<::mytype> {
using value_type = mytype;
allocator() = default;
template
allocator(const allocator&) {}
mytype* allocate(std::size_t n) {
return static_cast(::operator new(n * sizeof(mytype)));
}
void deallocate(mytype* ptr, std::size_t) noexcept {
::operator delete(ptr);
}
template
void construct(U* ptr, Args&&...args) {
::new ((void*)ptr) U(std::forward(args)...);
++::constructions;
}
template
void destroy(U* ptr) noexcept {
++::destructions;
ptr->~U();
}
friend constexpr bool operator == (const allocator&, const allocator&)
noexcept {
return true;
}
friend constexpr bool operator != (const allocator&, const allocator&)
noexcept {
return false;
}
};
} // namespace std
int main() {
{
std::vector{1,2,3};
// assert(constructions == 3); // assert would fire
}
// assert(destructions == 3); // assert would fire
return constructions != 3 || destructions != 3;
}
always returns non-zero, and either of the asserts will fire if uncommented.
Some possible solutions:
* Change all such optimizations in the library to presume that specializations
of std::allocator are the "default allocator" only if they are derived from
__allocator_base. This is the case for the base template definition as
implemented in bits/allocator.h.
* Remove all such optimizations from the library, and let the compiler optimize
away trivial construction and destruction. This has the unfortunate side effect
of slowing down debug builds of user programs.
* Close this bug report as WONTFIX since it is horrible design to specialize
std::allocator instead of declaring a new allocator type; given that container
implementations are free to rebind to a different specialization, there is no
guarantee that functionality added to a user-defined specialization will even
be used.
[Bug ada/64866] New: Lost visibility of package Interfaces after task or PO declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64866 Bug ID: 64866 Summary: Lost visibility of package Interfaces after task or PO declaration Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Created attachment 34618 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34618&action=edit Demonstrator While developing an Ada RTS, I found that code like with Interfaces; package body Foo is task T is end T; U : Interfaces.Unsigned_32 := 0; task body T is begin null; end T; end Foo; would fail with foo.adb:7:08: "Interfaces" is not visible (more references follow) foo.adb:7:08: non-visible declaration at interfac.ads:38 (and similar problems with a PO). I’m fairly confident that this is caused by having System.Tasking ‘with’ an unexpected package, in this case package FreeRTOS (it wasn’t just the name, I changed it to package Whatever, same result). I also tried making the child packages of FreeRTOS into nested packages, and then making that a child of System (in s-freert.ads); no joy. In the attachment, I’ve included the relevant RTS specs, which are all that is needed to show the problem when unpacked into the same directory as foo.ad?. The same problem occurs if the RTS code is in a proper RTS’s adainclude/.
[Bug preprocessor/64864] [5 Regression] preprocessor linemarkers break configure checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64864 --- Comment #3 from Markus Trippelsdorf --- (In reply to Jakub Jelinek from comment #2) > I really think this is porting_to.html material, rather than a bug report. I agree that the issue is borderline. Feel free to close this bug. What is gained by these new linemarkers?
[Bug sanitizer/64717] -fsanitize=vptr leads to warning: ‘’ may be used uninitialized in this function [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64717 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-01-29 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jakub Jelinek --- Created attachment 34619 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34619&action=edit gcc5-pr64717.patch Untested fix. The SAVE_EXPR in there was needed in earlier versions of =vptr support, where it emitted the __ubsan_* calls early, but right now it is used just once, and the SAVE_EXPR causes problems when the same dtor call is used shared in multiple locations (finally and cleanup). There is still a possible SAVE_EXPR if the address of the object has side-effects, but I hope dtors are never called that way if they'd could appear in cleanups.
[Bug preprocessor/64864] [5 Regression] preprocessor linemarkers break configure checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64864 --- Comment #4 from Jakub Jelinek --- The line markers allows the compiler to properly distinguish between what tokens come from where, e.g. system headers vs. normal headers (should we warn about issues in there if -Wsystem-headers is not used and it is some warning not enabled by default in system headers), or e.g. for #pragma GCC diagnostics tracking.
[Bug c++/64867] New: warning for passing non-POD to varargs function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867 Bug ID: 64867 Summary: warning for passing non-POD to varargs function Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Currently gcc does not warn if I pass a non-POD to a varargs function. It would have been useful recently if there was an option to make gcc warn about this.
[Bug preprocessor/64864] [5 Regression] preprocessor linemarkers break configure checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64864 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #5 from Marek Polacek --- More info here https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60723#c13 I'm going to prepare the porting_to bit, then I think we should close this bug.
[Bug c/64862] printf attribute should accept other string types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862 --- Comment #1 from Andreas Schwab --- glibc has this in : extern int wprintf (const wchar_t *__restrict __format, ...) /* __attribute__ ((__format__ (__wprintf__, 1, 2))) */;
[Bug c/64862] printf attribute should accept other string types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862
--- Comment #2 from Tom Tromey ---
Naturally my example was wrong.
Sorry about that. But gcc still doesn't handle it:
#include
#include
extern void p (const char16_t *fmt, ...)
__attribute__((format (__printf__, 1, 2)));
void f()
{
p (u"%s %d", 23, "hi");
}
... with gcc saying:
r.cc:5:44: error: format string argument is not a string type
__attribute__((format (__printf__, 1, 2)));
^
[Bug c/64862] printf attribute should accept other string types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862 Andrew Pinski changed: What|Removed |Added Depends on||38308 --- Comment #3 from Andrew Pinski --- wchar_t part was filed as bug 38308 a long time ago.
[Bug c++/64867] warning for passing non-POD to varargs function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867 --- Comment #1 from Andrew Pinski --- >From https://gcc.gnu.org/gcc-4.5/changes.html: Diagnostics that used to complain about passing non-POD types to ... or jumping past the declaration of a non-POD variable now check for triviality rather than PODness, as per C++0x. See PR 37907. And having an example would be useful too. Because of the change between C++98 and C++11.
[Bug c++/64867] warning for passing non-POD to varargs function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867 --- Comment #2 from Jonathan Wakely --- Jason informs me it's now a warning enabled by -Wconditionally-supported
[Bug c++/64867] warning for passing non-POD to varargs function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867 --- Comment #3 from Jason Merrill --- Passing a non-POD to a varargs function is conditionally-supported, with implementation-defined semantics. In GCC 5 it's supported and treated like normal pass-by-value. You can get a diagnostic about it with -Wconditionally-supported.
[Bug target/64159] [5 Regression] FAIL: gcc.dg/tree-ssa/ssa-dom-cse-2.c scan-tree-dump optimized "return 28;"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64159 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-29 CC||dje at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from David Edelsohn --- This is confirmed. Do we have agreement to XFAIL the testcase on powerpc and sparc?
[Bug target/64047] [5 Regression] ICE: Segmentation fault when compiling gcc.dg/torture/pr52429.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64047 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-29 CC||dje at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from David Edelsohn --- Confirmed.
[Bug tree-optimization/64365] [4.9 Regression] Predictive commoning after loop vectorization produces incorrect code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365 --- Comment #12 from Brooks Moses --- Thanks, Richard! It looks like I'll need to backport this to our google/gcc-4_9 branch before that happens; any chance you already have a version of this patch that works with 4.9? The wide_int pieces don't exist in 4.9 AFAICT.
[Bug fortran/64854] No bound check for explicit-shape arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64854 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #3 from Harald Anlauf --- (In reply to Dominique d'Humieres from comment #1) > Well, you give wrong information to the compiler. How do expect it to handle > your mistake: in testsub -fcheck=bounds checks that n1<=i<=n2 which is the > case. What you ask for is a check that a(n1:n2) is inside a(1:10), AFAIK > such check is not implemented and I don't have any idea about how difficult > it is to implement it. valgrind detects this issue. I was expected that the address sanitizer is able to handle it, but I am getting linking errors on my system. > I am inclined to close tis PR as INVALID or WONTFIX. The right way to fix the problem is to fix the program by using an appropriate programming style. Writing real:: a(n1:) ! not: real :: a(n1:n2) one gets the expected check: At line 22 of file pr64854.f90 Fortran runtime error: Index '1048586' of dimension 1 of array 'a' above upper bound of 1048585 Backtrace for this error: + function testsub.3321 (0x80486A4) from file pr64854.f90 + in the main program from file pr64854.f90 + /lib/libc.so.6(__libc_start_main+0xf3) [0xb7424003] I also suggest to close the PR.
[Bug c/64868] New: C front-end rejects valid syntax.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64868 Bug ID: 64868 Summary: C front-end rejects valid syntax. Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: u17263 at att dot net Created attachment 34620 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34620&action=edit test case gcc version: 5.0.0 / svn: r220249 gcc -Wall -fopenmp -c bug-9.c bug-9.c: In function ‘foo’: bug-9.c:12:22: error: invalid form of ‘#pragma omp atomic’ before ‘;’ token fgot = 1.0 / fgot;
[Bug sanitizer/64717] -fsanitize=vptr leads to warning: ‘’ may be used uninitialized in this function [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64717 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Thu Jan 29 20:40:07 2015 New Revision: 220262 URL: https://gcc.gnu.org/viewcvs?rev=220262&root=gcc&view=rev Log: PR c++/64717 * cp-ubsan.c (cp_ubsan_instrument_vptr): Don't wrap vptr into SAVE_EXPR. * g++.dg/ubsan/pr64717-1.C: New test. * g++.dg/ubsan/pr64717-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/ubsan/pr64717-1.C trunk/gcc/testsuite/g++.dg/ubsan/pr64717-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-ubsan.c trunk/gcc/testsuite/ChangeLog
[Bug c++/64867] warning for passing non-POD to varargs function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #4 from Tom Tromey ---
Thanks, I'll give it a try.
Here's my test case FWIW and a short demo showing what clang does:
pokyo. cat q.cc
#include
class ConstUTF8CharsZ
{
const char *mData;
public:
ConstUTF8CharsZ() : mData(0)
{
}
explicit ConstUTF8CharsZ(const char *aBytes)
: mData(aBytes)
{
}
const void *get() const { return mData; }
const char *c_str() const { return mData; }
operator bool() const { return mData != 0; }
};
void zzz(const char *x, ...) {
}
void m(const char *m) {
ConstUTF8CharsZ cu(m);
zzz(m, cu);
}
pokyo. clang++ q.cc
q.cc:30:10: error: cannot pass object of non-POD type 'ConstUTF8CharsZ' through
variadic function; call will abort at runtime [-Wnon-pod-varargs]
zzz(m, cu);
^
1 error generated.
[Bug fortran/64854] No bound check for explicit-shape arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64854 --- Comment #4 from Lorenz Hüdepohl --- > The right way to fix the problem is to fix the program > by using an appropriate programming style. Writing > > real:: a(n1:) ! not: real :: a(n1:n2) > > one gets the expected check I realize that, and when I write my own code I would never use such a construction. However, sometimes one is burdened with existing code in which small treasures such as this kind of bug are hidden. I was hoping that with -fcheck=bounds I could find this. If the code was correct already there would be no need for any kind of runtime checks, right?
[Bug libstdc++/64351] std::uniform_real_distribution(0, 1) returns 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64351 emsr at gcc dot gnu.org changed: What|Removed |Added CC||emsr at gcc dot gnu.org --- Comment #1 from emsr at gcc dot gnu.org --- Created attachment 34621 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34621&action=edit Just keep trying in generate_canonical... I'm going to test this... Just keep looping until you get less that one in generate_canonical.
[Bug c/64709] [5 Regression] Bogus -Wmissing-field-initializers warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64709 --- Comment #6 from Marek Polacek --- Author: mpolacek Date: Thu Jan 29 21:02:21 2015 New Revision: 220263 URL: https://gcc.gnu.org/viewcvs?rev=220263&root=gcc&view=rev Log: PR c/64709 * c-typeck.c (pop_init_level): If constructor_elements has exactly one element with integer_zerop value, set constructor_zeroinit to 1. Remove braces around warning_init call. * gcc.dg/pr64709.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr64709.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/64709] [5 Regression] Bogus -Wmissing-field-initializers warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64709 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- Fixed.
[Bug sanitizer/64717] -fsanitize=vptr leads to warning: ‘’ may be used uninitialized in this function [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64717 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug libstdc++/64814] std::copy_n advances InputIterator one *less* time than necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64814
--- Comment #9 from Anquietas ---
(In reply to Jonathan Wakely from comment #8)
> N.B. libc++ changed its copy_n with
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20110221/039404.
> html and then libstdc++ did the same in PR 50119
I linked that bug report in the OP, but as it happens the behaviour is quite
interesting with std::istream_iterator using an adaptation of the code I
pasted in OP:
int main() {
std::istringstream ss("1 2 3 4 5 6 7 8 9 0 1 2 ");
std::vector output;
auto readIter = std::istream_iterator(ss);
for (int i = 0; i < 3; ++i) {
output.clear();
auto inserter = std::back_inserter(output);
// Doesn't work - outputs 123415671890
std::copy_n(readIter, 4, inserter);
for (auto n : output)
std::cout << n;
}
}
However, in this case moving readIter's declaration inside the loop fixes it.
If we go back to the code in OP and do the same, it *doesn't* fix it and still
produces the same output in either case. At the very least, the current
implementation of copy_n appears to be inconsistent, depending on the type of
iterator used. The implementation I provided for copy_n in OP doesn't work for
the istream_iterator case though, and neither does the direct for loop
approach.
[Bug libffi/64855] FAIL: libffi.call/* -W -Wall -Wno-psabi -O0 -DABI_NUM=* -DABI_ATTR=* execution test on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64855
--- Comment #5 from howarth at bromo dot med.uc.edu ---
Confirmed on x86_64-apple-darwin14 that...
Index: libffi/testsuite/lib/libffi.exp
===
--- libffi/testsuite/lib/libffi.exp(revision 220263)
+++ libffi/testsuite/lib/libffi.exp(working copy)
@@ -310,7 +310,7 @@ proc run-many-tests { testcases extra_fl
set targetabis { "" }
if [string match $compiler_vendor "gnu"] {
if { ([istarget "i?86-*-*"] || [istarget "x86_64-*-*"])
- && [is-effective-target ia32] } {
+ && [is-effective-target ia32] && ![istarget "*-*-darwin*"] } {
set targetabis {
""
"-DABI_NUM=FFI_STDCALL -DABI_ATTR=__STDCALL__"
eliminates all regressions in the libffi test suite.
=== libffi Summary ===
# of expected passes3828
# of unsupported tests60
