[Bug c++/106166] Improve diagnostic for explicit constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106166 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-07-02 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Yes I've been bothered by this for a while. I think this diagnostic is mentioned in another PR too, contrasting it to the way we display errors for non-explicit ctors.
[Bug analyzer/106000] RFE: -fanalyzer should complain about memory accesses that are definitely out-of-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106000
--- Comment #4 from David Malcolm ---
For example, the "classic test" referred to in section 1.2 of
https://open-std.org/JTC1/SC22/WG14/www/docs/n3005.pdf
has:
#include
#include
int y=2, x=1;
int main() {
int *p = &x + 1;
int *q = &y;
printf("Addresses: p=%p q=%p\n" ,(void*)p,(void*)q);
if (memcmp(&p, &q, sizeof(p)) == 0) {
*p = 11; // does this have undefined behaviour?
printf("x=%d y=%d *p=%d *q=%d\n",x,y,*p,*q);
}
}
where N3005 notes that "the mere formation of the &x+1 one-past pointer is
explicitly permitted by the ISO standard".
I think -fanalyzer ought to complain with an definite-out-of-bounds warning at
the *p dereference: assuming sizeof(int) == 4, we'd have a decl_region of size
4, where only bytes 0 to 3 are validly accessible, whereas here the code
attempts to accessing bytes 4-7 of the decl_region for x, which is
out-of-bounds.
(I think the memcpy result would be a conjured_svalue, and hence we would
consider both true and false out-edges after the test; if the user is relying
on the two vars to be next to each other in memory we ought to be warning them
about that)
[Bug target/106167] New: Missed optimization (memory vs register read)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106167
Bug ID: 106167
Summary: Missed optimization (memory vs register read)
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vluchits at gmail dot com
Target Milestone: ---
Target: sh
Created attachment 53238
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53238&action=edit
Test case
Hello,
in the provided example, this piece of C code:
if (newclipbounds)
{
int newfloorclipx = floorclipx;
int newceilingclipx = ceilingclipx;
uint16_t newclip;
// rewrite clipbounds
if (actionbits & AC_NEWFLOOR)
newfloorclipx = low;
if (actionbits & AC_NEWCEILING)
newceilingclipx = high;
newclip = (newceilingclipx << 8) + newfloorclipx;
clipbounds[x] = newclip;
newclipbounds[x] = newclip;
}
is compiled to the following assembler code:
if (newclipbounds)
16c: 54 f7 mov.l @(28,r15),r4
16e: 24 48 tst r4,r4
170: 8d 10 bt.s194 <_R_SegLoop+0x194>
172: e0 54 mov #84,r0
if (actionbits & AC_NEWFLOOR)
174: 05 fe mov.l @(r0,r15),r5
176: 25 58 tst r5,r5
178: 8f 01 bf.s17e <_R_SegLoop+0x17e>
17a: e0 58 mov #88,r0
floorclipx = ceilingclipx & 0x00ff;
17c: 67 a3 mov r10,r7
if (actionbits & AC_NEWCEILING)
17e: 00 fe mov.l @(r0,r15),r0
180: 20 08 tst r0,r0
182: 8f 01 bf.s188 <_R_SegLoop+0x188>
184: 50 fb mov.l @(44,r15),r0
int newceilingclipx = ceilingclipx;
186: 66 93 mov r9,r6
newclip = (newceilingclipx << 8) + newfloorclipx;
188: 46 18 shll8 r6
18a: 37 6c add r6,r7
18c: 67 7d extu.w r7,r7
clipbounds[x] = newclip;
18e: 08 75 mov.w r7,@(r0,r8)
newclipbounds[x] = newclip;
The following lines are of particular interest:
if (newclipbounds)
16c: 54 f7 mov.l @(28,r15),r4
16e: 24 48 tst r4,r4
...
newclipbounds[x] = newclip;
190: 50 f7 mov.l @(28,r15),r0
192: 08 75 mov.w r7,@(r0,r8)
The compiler fails to notice that it's already holding the value of @(28,r15)
in r4 and re-reads the value from stack instead of doing the mov r4,r0.
CFLAGS: -c -std=c11 -g -m2 -mb -Os -fomit-frame-pointer -Wall -Wextra -pedantic
-Wno-unused-parameter -Wimplicit-fallthrough=0 -Wno-missing-field-initializers
-Wnonnull
This may or may not be relevant to bug #106161
[Bug ada/106168] New: Errors with empty array aggregate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106168 Bug ID: 106168 Summary: Errors with empty array aggregate. Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: p.p11 at orange dot fr Target Milestone: --- Created attachment 53239 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53239&action=edit Full source code Following the example section of RM Ada 2022 § 4.3.3 Array Aggregate, the empty aggregate is line 8: 3.type Real is digits 8; 4.type Matrix is array (Integer range <>, Integer range <>) of Real; 5. 6.-- AARM (Draft 22) Section_4_3_3_Paragraph_47 7. 8.Empty_Matrix : constant Matrix := []; -- A matrix without elements GNAT 12.1.0 issues the following errors: % gcc -c -gnat2022 2022/test_20220702_array_agg.adb test_20220702_array_agg.adb:8:38: error: value not in range of type "Standard.Integer" test_20220702_array_agg.adb:8:38: error: static expression fails Constraint_Check
[Bug ada/106169] New: Error with iterated element association in aggregate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106169 Bug ID: 106169 Summary: Error with iterated element association in aggregate. Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: p.p11 at orange dot fr Target Milestone: --- Created attachment 53240 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53240&action=edit Full source code Following the example section of RM Ada 2022 § 4.3.5 Container Aggregate, the iterated element association aggregate is line 32: 32.M := [for P of Table use P.Key => P.Value.all]; GNAT 12.1.0 issues the following error: % gcc -c -gnatX 2022/test_20220702_iter_agg.adb test_20220702_iter_agg.adb:32:39: error: invalid prefix in selected component "Value"
[Bug c++/106102] gcc/cp/mapper-resolver.cc fails to build against musl: musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use poisoned "calloc"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106102 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Sergei Trofimovich : https://gcc.gnu.org/g:de6f402a54f7e6a3f8a79d723a25724e6274cc3e commit r12-8539-gde6f402a54f7e6a3f8a79d723a25724e6274cc3e Author: Sergei Trofimovich Date: Mon Jun 27 13:27:24 2022 +0100 c++: avoid poisoning on musl [PR106102] On musl uses calloc() (via ). includes it indirectly and exposes use of poisoned calloc() when module code is built: /build/build/./prev-gcc/xg++ ... ../../gcc-13-20220626/gcc/cp/mapper-resolver.cc In file included from /<>/musl-1.2.3-dev/include/pthread.h:30, from /build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/include/x86_64-unknown-linux-musl/bits/gthr-default.h:35, from /build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/include/memory:77, from ../../gcc-13-20220626/gcc/../libcody/cody.hh:24, from ../../gcc-13-20220626/gcc/cp/../../c++tools/resolver.h:25, from ../../gcc-13-20220626/gcc/cp/../../c++tools/resolver.cc:23, from ../../gcc-13-20220626/gcc/cp/mapper-resolver.cc:32: /<>/musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use poisoned "calloc" 84 | void *calloc(size_t, size_t); | ^ /<>/musl-1.2.3-dev/include/sched.h:124:36: error: attempt to use poisoned "calloc" 124 | #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n))) |^ gcc/cp/ PR c++/106102 * mapper-client.cc: Include via "system.h". * mapper-resolver.cc: Ditto. * module.cc: Ditto. libcc1/ PR c++/106102 * libcc1plugin.cc: Include via "system.h". * libcp1plugin.cc: Ditto. (cherry picked from commit 3b21c21f3f5726823e19728fdd1571a14aae0fb3)
[Bug c++/106102] gcc/cp/mapper-resolver.cc fails to build against musl: musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use poisoned "calloc"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106102 --- Comment #9 from CVS Commits --- The releases/gcc-12 branch has been updated by Sergei Trofimovich : https://gcc.gnu.org/g:ad5d760b815b3d491bdb5d97f6e053d60d6991b9 commit r12-8540-gad5d760b815b3d491bdb5d97f6e053d60d6991b9 Author: Sergei Trofimovich Date: Mon Jun 27 23:42:44 2022 +0100 jit: avoid calloc() poisoning on musl [PR106102] On musl uses calloc() (via ). jit/ includes it directly and exposes use of poisoned calloc(): /build/build/./prev-gcc/xg++ ... ../../gcc-13-20220626/gcc/jit/jit-playback.cc make[3]: *** [Makefile:1143: jit/libgccjit.o] Error 1 make[3]: *** Waiting for unfinished jobs In file included from /<>/musl-1.2.3-dev/include/pthread.h:30, from ../../gcc-13-20220626/gcc/jit/jit-playback.cc:44: /<>/musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use poisoned "calloc" 84 | void *calloc(size_t, size_t); | ^ /<>/musl-1.2.3-dev/include/sched.h:124:36: error: attempt to use poisoned "calloc" 124 | #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n))) |^ The change moves inclusion to "system.h" under new INCLUDE_PTHREAD_H guard and uses this mechanism in libgccjit. gcc/ PR c++/106102 * system.h: Introduce INCLUDE_PTHREAD_H macros to include . gcc/jit/ PR c++/106102 * jit-playback.cc: Include via "system.h" to avoid calloc() poisoning. * jit-recording.cc: Ditto. * libgccjit.cc: Ditto. (cherry picked from commit 49d508065bdd36fb1a9b6aad9666b1edb5e06474)
[Bug c++/106102] gcc/cp/mapper-resolver.cc fails to build against musl: musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use poisoned "calloc"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106102 Sergei Trofimovich changed: What|Removed |Added Target Milestone|--- |12.2 Status|UNCONFIRMED |RESOLVED Assignee|unassigned at gcc dot gnu.org |slyfox at gcc dot gnu.org Resolution|--- |FIXED --- Comment #10 from Sergei Trofimovich --- Pulled fixes as is to gcc-12. Not going to pull it in to gcc-11 and lower as it depends on larger headers reshuffle like commit b8f7ff76d6f0b7fdffc314a19425423606b5e296.
[Bug libcc1/104799] Header issue with x86_64-linux-musl based cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104799 Sergei Trofimovich changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |12.2 Status|UNCONFIRMED |RESOLVED --- Comment #4 from Sergei Trofimovich --- > libcc1/libcc1plugin.cc (In reply to Mosè Giordano from comment #2) > Created attachment 52568 [details] > Patch for poisoned calloc on Musl systems > > Following the example of > https://git.alpinelinux.org/aports/tree/main/gcc/0042-Fix-attempt-to-use- > poisoned-calloc-error-in-libgccji.patch, reported in > https://bugs.gentoo.org/828580, I wrote the attached patch for libcc1, which > seems to solve the issue for me. I think the change looks reasonable. Should be fixed by "c++: avoid poisoning on musl [PR106102]" patch from PR106102 in master and gcc-12 branches. Can you give it a try?
[Bug ada/106037] ICE with Aggregate aspect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106037 Pascal Pignard changed: What|Removed |Added CC||p.p11 at orange dot fr --- Comment #2 from Pascal Pignard --- Same error with iterated element association in aggregate: 597. declare 598. Keys : constant array (Positive range <>) of Integer := [2, 3, 5, 7, 11]; 599. begin 600. 601. -- A map aggregate where the values produced by the 602. -- iterated_element_association are of the same type as the key 603. -- (eliminating the need for a separate key_expression): 604. 605.M := [for Key1 of Keys => Integer'Image (Key1)]; +===GNAT BUG DETECTED==+ | 12.1.0 (x86_64-apple-darwin19.6.0) Program_Error sem_type.adb:837 explicit raise| | Error detected at aarm_202x_ch04.adb:605:21
[Bug analyzer/106003] RFE: -fanalyzer could complain about misuse of file-descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003 --- Comment #2 from CVS Commits --- The master branch has been updated by Immad Mir : https://gcc.gnu.org/g:97baacba963c06e3d0e33cde04e7e687671e60e7 commit r13-1404-g97baacba963c06e3d0e33cde04e7e687671e60e7 Author: Immad Mir Date: Sat Jul 2 22:09:37 2022 +0530 analyzer: implement five new warnings for misuse of POSIX file descriptor APIs [PR106003]. This patch adds a new state machine to the analyzer for checking usage of POSIX file descriptor APIs with five new warnings. It adds: - check for FD leaks (CWE 775). - check for double "close" of a FD (CWE-1341). - check for read/write of a closed file descriptor. - check whether a file descriptor was used without being checked for validity. - check for read/write of a descriptor opened for just writing/reading. gcc/ChangeLog: PR analyzer/106003 * Makefile.in (ANALYZER_OBJS): Add sm-fd.o. * doc/invoke.texi: Add -Wanalyzer-fd-double-close, -Wanalyzer-fd-leak, -Wanalyzer-fd-access-mode-mismatch, -Wanalyzer-fd-use-without-check, -Wanalyzer-fd-use-after-close. gcc/analyzer/ChangeLog: PR analyzer/106003 * analyzer.opt (Wanalyzer-fd-leak): New option. (Wanalyzer-fd-access-mode-mismatch): New option. (Wanalyzer-fd-use-without-check): New option. (Wanalyzer-fd-double-close): New option. (Wanalyzer-fd-use-after-close): New option. * sm.h (make_fd_state_machine): New decl. * sm.cc (make_checkers): Call make_fd_state_machine. * sm-fd.cc: New file. gcc/testsuite/ChangeLog: PR analyzer/106003 * gcc.dg/analyzer/fd-1.c: New test. * gcc.dg/analyzer/fd-2.c: New test. * gcc.dg/analyzer/fd-3.c: New test. * gcc.dg/analyzer/fd-4.c: New test.
[Bug analyzer/105900] RFE: -fanalyzer could check malloc sizes when casting the result to a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105900 --- Comment #4 from CVS Commits --- The master branch has been updated by Tim Lange : https://gcc.gnu.org/g:e6c3bb379f515b27268d08e62b4b3e5d7200b437 commit r13-1405-ge6c3bb379f515b27268d08e62b4b3e5d7200b437 Author: Tim Lange Date: Fri Jul 1 00:02:17 2022 +0200 analyzer: add allocation size checker [PR105900] This patch adds an checker that warns about code paths in which a buffer is assigned to a incompatible type, i.e. when the allocated buffer size is not a multiple of the pointee's size. Regression-tested on x86_64 Linux. Also compiled coreutils, curl, openssh and httpd with the patch enabled. 2022-07-01 Tim Lange gcc/analyzer/ChangeLog: PR analyzer/105900 * analyzer.opt: Added Wanalyzer-allocation-size. * checker-path.cc (region_creation_event::get_desc): Added call to new virtual function pending_diagnostic::describe_region_creation_event. * checker-path.h: Added region_creation_event::get_desc. * diagnostic-manager.cc (diagnostic_manager::add_event_on_final_node): New function. * diagnostic-manager.h: Added diagnostic_manager::add_event_on_final_node. * pending-diagnostic.h (struct region_creation): New event_desc struct. (pending_diagnostic::describe_region_creation_event): Added virtual function to overwrite description of a region creation. * region-model.cc (class dubious_allocation_size): New class. (capacity_compatible_with_type): New helper function. (class size_visitor): New class. (struct_or_union_with_inheritance_p): New helper function. (is_any_cast_p): New helper function. (region_model::check_region_size): New function. (region_model::set_value): Added call to region_model::check_region_size. * region-model.h (class region_model): New function check_region_size. * svalue.cc (region_svalue::accept): Changed to post-order traversal. (initial_svalue::accept): Likewise. (unaryop_svalue::accept): Likewise. (binop_svalue::accept): Likewise. (sub_svalue::accept): Likewise. (repeated_svalue::accept): Likewise. (bits_within_svalue::accept): Likewise. (widening_svalue::accept): Likewise. (unmergeable_svalue::accept): Likewise. (compound_svalue::accept): Likewise. (conjured_svalue::accept): Likewise. (asm_output_svalue::accept): Likewise. (const_fn_result_svalue::accept): Likewise. gcc/ChangeLog: PR analyzer/105900 * doc/invoke.texi: Added Wanalyzer-allocation-size. gcc/testsuite/ChangeLog: PR analyzer/105900 * gcc.dg/analyzer/pr96639.c: Changed buffer size to omit warning. * gcc.dg/analyzer/allocation-size-1.c: New test. * gcc.dg/analyzer/allocation-size-2.c: New test. * gcc.dg/analyzer/allocation-size-3.c: New test. * gcc.dg/analyzer/allocation-size-4.c: New test. * gcc.dg/analyzer/allocation-size-5.c: New test. Signed-off-by: Tim Lange
[Bug analyzer/105887] [meta-bug] clang analyzer warnings that GCC's -fanalyzer could implement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105887 Bug 105887 depends on bug 105900, which changed state. Bug 105900 Summary: RFE: -fanalyzer could check malloc sizes when casting the result to a pointer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105900 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug analyzer/105900] RFE: -fanalyzer could check malloc sizes when casting the result to a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105900 Tim Lange changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Tim Lange --- Committed my patch to master.
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 Jerry DeLisle changed: What|Removed |Added Attachment #52981|0 |1 is obsolete|| --- Comment #24 from Jerry DeLisle --- Created attachment 53241 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53241&action=edit Revised patch that may be as good as it gets. I have not had time to commit this, but this would be it. If you can test it and point out any issues it is appreciated.
[Bug fortran/106065] Crash when reading extended derived type array in namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106065 --- Comment #2 from Jerry DeLisle --- I was a bit curious to see what flang would do with the test case. It gives the exact same error message as gfortran, word for word.
[Bug fortran/106089] false positives with -Wuninitialized for allocation on assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106089
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC||kargl at gcc dot gnu.org
Last reconfirmed||2022-07-02
Ever confirmed|0 |1
Priority|P3 |P4
Keywords|diagnostic |
--- Comment #3 from kargl at gcc dot gnu.org ---
Removed 'diagnostic' keyword. This is much worse than just a bad diagnostic.
Consider a much shorter testcase.
program foo
integer, allocatable :: i(:)
i = [1,1]
if (any(i /= 1)) stop
end program foo
% gfortran11 -Wall -c a.f90 |& grep -i warn
Warning: 'i.offset' is used uninitialized [-Wuninitialized]
Warning: 'i.dim[0].lbound' is used uninitialized [-Wuninitialized]
Warning: 'i.dim[0].ubound' is used uninitialized [-Wuninitialized]
Warning: 'i.dim[0].lbound' may be used uninitialized [-Wmaybe-uninitialized]
Warning: 'i.dim[0].ubound' may be used uninitialized [-Wmaybe-uninitialized]
Warning: 'i.dim[0].ubound' may be used uninitialized [-Wmaybe-uninitialized]
Warning: 'i.dim[0].lbound' may be used uninitialized [-Wmaybe-uninitialized]
With the patch that follows, I get
% gfcx -Wall -c a.f90 |& grep -i warn
Warning: 'i.offset' is used uninitialized [-Wuninitialized]
Warning: 'i.dim[0].lbound' is used uninitialized [-Wuninitialized]
Warning: 'i.dim[0].ubound' is used uninitialized [-Wuninitialized]
so 4 of the rogue warnings are no longer issued.
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 05134952db4..793e6a21e6d 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -10734,27 +10734,27 @@ gfc_alloc_allocatable_for_assignment (gfc_loopinfo
*loop,
/* If the lhs shape is not the same as the rhs jump to setting the
bounds and doing the reallocation... */
- for (n = 0; n < expr1->rank; n++)
+ if (expr1->shape)
{
- /* Check the shape. */
- lbound = gfc_conv_descriptor_lbound_get (desc, gfc_rank_cst[n]);
- ubound = gfc_conv_descriptor_ubound_get (desc, gfc_rank_cst[n]);
- tmp = fold_build2_loc (input_location, MINUS_EXPR,
-gfc_array_index_type,
-loop->to[n], loop->from[n]);
- tmp = fold_build2_loc (input_location, PLUS_EXPR,
-gfc_array_index_type,
-tmp, lbound);
- tmp = fold_build2_loc (input_location, MINUS_EXPR,
-gfc_array_index_type,
-tmp, ubound);
- cond = fold_build2_loc (input_location, NE_EXPR,
- logical_type_node,
- tmp, gfc_index_zero_node);
- tmp = build3_v (COND_EXPR, cond,
- build1_v (GOTO_EXPR, jump_label1),
- build_empty_stmt (input_location));
- gfc_add_expr_to_block (&fblock, tmp);
+ for (n = 0; n < expr1->rank; n++)
+ {
+ /* Check the shape. */
+ lbound = gfc_conv_descriptor_lbound_get (desc, gfc_rank_cst[n]);
+ ubound = gfc_conv_descriptor_ubound_get (desc, gfc_rank_cst[n]);
+ tmp = fold_build2_loc (input_location, MINUS_EXPR,
+gfc_array_index_type,
+loop->to[n], loop->from[n]);
+ tmp = fold_build2_loc (input_location, PLUS_EXPR,
+gfc_array_index_type, tmp, lbound);
+ tmp = fold_build2_loc (input_location, MINUS_EXPR,
+gfc_array_index_type, tmp, ubound);
+ cond = fold_build2_loc (input_location, NE_EXPR,
+ logical_type_node, tmp, gfc_index_zero_node);
+ tmp = build3_v (COND_EXPR, cond,
+ build1_v (GOTO_EXPR, jump_label1),
+ build_empty_stmt (input_location));
+ gfc_add_expr_to_block (&fblock, tmp);
+ }
}
/* ...else if the element lengths are not the same also go to
So, what's the problem. The scalarizer is broken, which was
originally written before (re)allocation of the LHS was introduced
to Fortran. The above is not valid Fortran 95. The LHS and RHS
of the assignment must be conformable. This means that, if an
error had not been emitted, then the LHS and RHS have the same
array descriptor. This leads to two problems. The first is
the scalarizer appears to write the descriptors into the intermediate
representation (IR).
% gfortran11 -Wall -c a.f90 -fdump-tree-original
% more a.f90.005t.original (NOte inline annotations)
void foo ()
{
struct array01_integer(kind=4) i;
i.data = 0B;
i.dtype = {.elem_len=4, .rank=1, .type=1};
{
*** This is the descriptor for the RHS
integer(kind=4
[Bug analyzer/105898] RFE: -fanalyzer should complain about overlapping args to memcpy and mempcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105898 Tim Lange changed: What|Removed |Added CC||tlange at gcc dot gnu.org --- Comment #2 from Tim Lange --- (In reply to Eric Gallager from comment #1) > Doesn't -Wrestrict already kinda do this? Partly. -Wrestrict only warns when you actually use the same variable, e.g. memcpy (buf, buf, 4). Doing that in the analyzer could also warn on cases like: - memcpy (buf, alias_to_buf, 4) - memcpy (buf, buf + 2, 4)
[Bug gcov-profile/106090] [GCOV] Wrong coverage for loop statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106090
--- Comment #2 from Yang Wang ---
(In reply to Martin Liška from comment #1)
> No, it's correct as it only contains do_it() call that is triggered the same
> number times as line 20 minus one.
(In reply to Martin Liška from comment #1)
> No, it's correct as it only contains do_it() call that is triggered the same
> number times as line 20 minus one.
-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:1:volatile int cnt = 0;
-:2:
-:3:__attribute__((noinline, noclone)) static int
5:4:last (void)
-:5:{
5:6: return ++cnt % 5 == 0;
-:7:}
-:8:
-:9:__attribute__((noinline, noclone)) static void
6: 10:do_it (void)
-: 11:{
6: 12: asm volatile ("" : : "r" (&cnt) : "memory");
6: 13:}
-: 14:
1: 15:static void f1 (void)
-: 16:{
1: 17: do_it();
4: 18: for (; 0<1; do_it())
-: 19:{
5: 20: if (last ())
1: 21:break;
-: 22:}
1: 23: do_it ();
1: 24:}
-: 25:
-: 26:int
1: 27:main ()
-: 28:{
1: 29: f1 ();
-: 30:}
do_it() is indeed called 4 times,but I wonder how the coverage statistiscs of
the for-statement is calculated. It doesn't become 5 untill the for-stamentment
is completed.
-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:1:volatile int cnt = 0;
-:2:
-:3:__attribute__((noinline, noclone)) static int
5:4:last (void)
-:5:{
5:6: return ++cnt % 5 == 0;
-:7:}
-:8:
-:9:__attribute__((noinline, noclone)) static void
6: 10:do_it (void)
-: 11:{
6: 12: asm volatile ("" : : "r" (&cnt) : "memory");
6: 13:}
-: 14:
1: 15:static void f1 (void)
-: 16:{
1: 17: do_it();
5: 18: for (int a=0;0<1;do_it())
-: 19:{
5: 20: if (last ())
1: 21:break;
-: 22:}
1: 23: do_it ();
1: 24:}
-: 25:
-: 26:int
1: 27:main ()
-: 28:{
1: 29: f1 ();
-: 30:}
[Bug gcov-profile/106090] [GCOV] Wrong coverage for loop statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106090
--- Comment #3 from Yang Wang ---
(In reply to Yang Wang from comment #2)
> (In reply to Martin Liška from comment #1)
> > No, it's correct as it only contains do_it() call that is triggered the same
> > number times as line 20 minus one.
>
> (In reply to Martin Liška from comment #1)
> > No, it's correct as it only contains do_it() call that is triggered the same
> > number times as line 20 minus one.
>
> -:0:Source:test.c
> -:0:Graph:test.gcno
> -:0:Data:test.gcda
> -:0:Runs:1
> -:1:volatile int cnt = 0;
> -:2:
> -:3:__attribute__((noinline, noclone)) static int
> 5:4:last (void)
> -:5:{
> 5:6: return ++cnt % 5 == 0;
> -:7:}
> -:8:
> -:9:__attribute__((noinline, noclone)) static void
> 6: 10:do_it (void)
> -: 11:{
> 6: 12: asm volatile ("" : : "r" (&cnt) : "memory");
> 6: 13:}
> -: 14:
> 1: 15:static void f1 (void)
> -: 16:{
> 1: 17: do_it();
> 4: 18: for (; 0<1; do_it())
> -: 19:{
> 5: 20: if (last ())
> 1: 21: break;
> -: 22:}
> 1: 23: do_it ();
> 1: 24:}
> -: 25:
> -: 26:int
> 1: 27:main ()
> -: 28:{
> 1: 29: f1 ();
> -: 30:}
>
> do_it() is indeed called 4 times,but I wonder how the coverage statistiscs
> of the for-statement is calculated. It doesn't become 5 untill the
> for-stamentment is completed.
> -:0:Source:test.c
> -:0:Graph:test.gcno
> -:0:Data:test.gcda
> -:0:Runs:1
> -:1:volatile int cnt = 0;
> -:2:
> -:3:__attribute__((noinline, noclone)) static int
> 5:4:last (void)
> -:5:{
> 5:6: return ++cnt % 5 == 0;
> -:7:}
> -:8:
> -:9:__attribute__((noinline, noclone)) static void
> 6: 10:do_it (void)
> -: 11:{
> 6: 12: asm volatile ("" : : "r" (&cnt) : "memory");
> 6: 13:}
> -: 14:
> 1: 15:static void f1 (void)
> -: 16:{
> 1: 17: do_it();
> 5: 18: for (int a=0;0<1;do_it())
> -: 19:{
> 5: 20: if (last ())
> 1: 21: break;
> -: 22:}
> 1: 23: do_it ();
> 1: 24:}
> -: 25:
> -: 26:int
> 1: 27:main ()
> -: 28:{
> 1: 29: f1 ();
> -: 30:}
Besides, GCov doesn't seem to provide voerage statistics for "for(;;)" .
-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:1:volatile int cnt = 0;
-:2:
-:3:__attribute__((noinline, noclone)) static int
5:4:last (void)
-:5:{
5:6: return ++cnt % 5 == 0;
-:7:}
-:8:
-:9:__attribute__((noinline, noclone)) static void
6: 10:do_it (void)
-: 11:{
6: 12: asm volatile ("" : : "r" (&cnt) : "memory");
6: 13:}
-: 14:
1: 15:static void f1 (void)
-: 16:{
1: 17: do_it();
-: 18: for (; ; )
-: 19:{
5: 20: if (last ())
1: 21:break;
4: 22: do_it();
-: 23:}
1: 24: do_it ();
1: 25:}
-: 26:
-: 27:int
1: 28:main ()
-: 29:{
1: 30: f1 ();
-: 31:}
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #25 from harper at msor dot vuw.ac.nz --- I received your patch but I have no idea how to install it - I have been using Fortran off and on since 1963 but I am not a systems programmer. My version of gfortran is gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1) On Sat, 2 Jul 2022, jvdelisle at gcc dot gnu.org wrote: > Date: Sat, 2 Jul 2022 17:14:05 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug fortran/105473] semicolon allowed when list-directed read > integer with decimal='point' > Resent-Date: Sun, 3 Jul 2022 05:14:17 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 > > Jerry DeLisle changed: > > What|Removed |Added > > Attachment #52981|0 |1 >is obsolete|| > > --- Comment #24 from Jerry DeLisle --- > Created attachment 53241 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53241&action=edit > Revised patch that may be as good as it gets. > > I have not had time to commit this, but this would be it. If you can test it > and point out any issues it is appreciated. > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276
[Bug lto/106170] New: win32 thread model does not pthread.h. lto-plugin fails with canadian compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106170 Bug ID: 106170 Summary: win32 thread model does not pthread.h. lto-plugin fails with canadian compilation Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com CC: marxin at gcc dot gnu.org Target Milestone: --- make[4]: Entering directory '/home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/x86_64-w64-mingw32/gcc/gmp/demos' Making all in calc ../../../../../gcc/lto-plugin/lto-plugin.c:62:10: fatal error: pthread.h: No such file or directory 62 | #include | ^~~ win32 thread model's gcc does not have pthread.h
[Bug lto/106170] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106170 --- Comment #1 from cqwrteur --- windows does not provide those things. You can use EnterCriticalSection/ LeaveCriticalSection instead. I can write a patch to fix it for windows.
[Bug lto/106118] lto-plugin/lto-plugin.c: -pthread not passed to AM_LDFLAGS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106118 cqwrteur changed: What|Removed |Added CC||unlvsur at live dot com --- Comment #4 from cqwrteur --- (In reply to Martin Liška from comment #3) > Should be fixed now. This patch is just wrong. Since windows simply does not provide libpthread.a you have win32, posix, and mcf 3 kinds of threads. Plus a lot of single-thread targets. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106170
[Bug lto/106170] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106170 cqwrteur changed: What|Removed |Added CC||unlvsur at live dot com --- Comment #2 from cqwrteur --- Created attachment 53242 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53242&action=edit This patch just fixed the compilation part for windows. -pthread flag is a huge issue I do not know how to fix that.
[Bug lto/106170] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106170 cqwrteur changed: What|Removed |Added Attachment #53242|0 |1 is obsolete|| --- Comment #3 from cqwrteur --- Created attachment 53243 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53243&action=edit Update patch
[Bug lto/106170] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106170 cqwrteur changed: What|Removed |Added Attachment #53243|0 |1 is obsolete|| --- Comment #4 from cqwrteur --- Created attachment 53244 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53244&action=edit My patch without autoreconf. Please run autoreconf by yourself I have just fixed them, but need to run autoreconf by yourself. BTW. -lpthread -pthread lpthreads whatever i remember they all exist. Plus win32 does not need -lpthread anymore since it uses win32 CriticalSection api.
