[Bug gcov-profile/94029] [9 Regression] gcc crash in coverage.c:655 since r9-4216-g390e529e2b98983d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94029 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #15 from sandra at gcc dot gnu.org --- Seen on nios2-elf: FAIL: gcc.misc-tests/gcov-pr94029.c gcov failed: gcov-pr94029.c.gcov does not exist
[Bug tree-optimization/93946] Bogus redundant store removal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
--- Comment #9 from sandra at gcc dot gnu.org ---
Both the new test cases are failing on nios2 at -Os, -O2, and -O3. I've done
some analysis, but I'm not sure exactly where the problem lies, and whether
this is a problem in the nios2 back end or somewhere else.
long __attribute__((noipa))
foo (struct bb *bv, void *ptr)
{
struct aa *a = ptr;
struct bb *b = ptr;
bv->b.u.f = 1;
a->a.u.i = 0;
b->b.u.f = 0;
return bv->b.u.f;
}
is compiling to
foo:
movir2, 1
stw r2, 0(r4)
ldw r2, 0(r4)
stw zero, 0(r5)
stw zero, 4(r5)
ret
What's going on here is that load instructions have 3-cycle latency on nios2,
so the sched2 pass is moving the "ldw r2, 0(r4)" to load the return value 2
instructions earlier ahead of the store instruction to the same location
via the aliased pointer. :-(
I'm not an expert on the instruction scheduler, and it seems like the target
hooks and machine description syntax are all focused on modelling pipeline
costs in order to minimize stalls, not telling the scheduler that certain
instructions cannot be correctly reordered at all. Should some other pass be
inserting optimization barriers, or something like that? I feel like I'm
missing some big-picture expertise of where this needs to be fixed, so any
suggestions to point me in the right direction would be appreciated.
[Bug gcov-profile/94029] [9 Regression] gcc crash in coverage.c:655 since r9-4216-g390e529e2b98983d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94029
--- Comment #18 from sandra at gcc dot gnu.org ---
I'm seeing the missing gcov file on nios2-linux-gnu as well. Git revision
6e00d8dcf32ace6588a1a4843dfcc0e8b9f9d00f.
I took another look at the testcase. I haven't used gcov for about a gazillion
years, but...
It says "{ dg-do compile }". Don't you have to run the testcase to collect the
data to run with gcov? And copy the .gcda file from the target to the host?
Then, it is trying to run "gcov gcov-pr94029.c" instead of e.g. "nios2-elf-gcov
gcov-pr94029.c", and it's picking up some random gcov program installed on the
host system instead of the one for the target.
Maybe this testcase should just be restricted to native targets?
[Bug tree-optimization/93946] Bogus redundant store removal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946 --- Comment #11 from sandra at gcc dot gnu.org --- RTL before sched2 does look sane and similar to that generated for x86 with -m32. I've been trying to step through sched2. I think that where things get interesting is the call to true_dependence at sched-deps.c:2663. Breakpoint 6, true_dependence (mem=0x7742c9a8, mem_mode=E_VOIDmode, x=0x7742cac8) at /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/alias.c:3056 3056 return true_dependence_1 (mem, mem_mode, NULL_RTX, (gdb) print debug_rtx(mem) (mem/j:SI (reg/v/f:SI 5 r5 [orig:48 ptr ] [48]) [1 MEM[(struct aa *)ptr_1(D)].a.u.i+0 S4 A32]) $19 = void (gdb) print debug_rtx(x) (mem/j:SI (reg/v/f:SI 4 r4 [orig:47 bv ] [47]) [1 bv_3(D)->b.u.f+0 S4 A32]) $20 = void This is making it all the way to the end of true_dependence_1, into rtx_refs_may_alias_p, and into refs_may_alias_p_1, which is returning false, which gets propagated back up as the result of true_dependence. IIUC, this is what is allowing sched2 to move the read from "x" ahead of the write to "mem". Before I spend more time on this, am I on the right track here? And is this pointing at the problem being in refs_may_alias_p_1 rather than somewhere along the way e.g. in true_dependence_1?
[Bug tree-optimization/93946] Bogus redundant store removal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946
--- Comment #13 from sandra at gcc dot gnu.org ---
Well, no. The problem is that the scheduler is moving
ldw r2, 0(r4)
ahead of
stw zero, 0(r5)
which is incorrect because the pointers in r4 and r5 are aliases.
So at the point of call to true_dependence, I see:
(gdb) frame 1
#1 0x01d1a108 in sched_analyze_2 (deps=0x7fffdd50,
x=0x7742cac8, insn=0x77315600)
at /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/sched-deps.c:2663
2663if (true_dependence (pending_mem->element (), VOIDmode,
t)
(gdb) print debug_rtx(insn)
(insn 17 10 18 2 (set (reg/i:SI 2 r2)
(mem/j:SI (reg/v/f:SI 4 r4 [orig:47 bv ] [47]) [1 bv_3(D)->b.u.f+0 S4
A32]))
"/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/testsuite/gcc.dg/torture/pr93946-1.c":18:1
5 {movsi_internal}
(expr_list:REG_DEAD (reg/v/f:SI 4 r4 [orig:47 bv ] [47])
(nil)))
$3 = void
(gdb) print debug_rtx(pending->insn())
(insn 9 8 10 2 (set (mem/j:SI (reg/v/f:SI 5 r5 [orig:48 ptr ] [48]) [1
MEM[(struct aa *)ptr_1(D)].a.u.i+0 S4 A32])
(const_int 0 [0]))
"/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/testsuite/gcc.dg/torture/pr93946-1.c":15:12
5 {movsi_internal}
(nil))
$4 = void
[Bug tree-optimization/93946] Bogus redundant store removal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946 --- Comment #15 from sandra at gcc dot gnu.org --- Hmmm. I've gone over this code 2 or 3 times now, and I'm still convinced the problem is in the alias analysis, not the scheduler. I've stepped deeper into the code in the debugger, and here is the backtrace from where I see things going wrong: #0 indirect_refs_may_alias_p (ref1=0x774196f0, base1=0x773fec08, offset1=..., max_size1=..., size1=..., ref1_alias_set=1, base1_alias_set=4, ref2=0x774195d0, base2=0x773febb8, offset2=..., max_size2=..., size2=..., ref2_alias_set=1, base2_alias_set=6, tbaa_p=true) at /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/tree-ssa-alias.c:2122 #1 0x013f8266 in refs_may_alias_p_2 (ref1=0x7fffd7d0, ref2=0x7fffd790, tbaa_p=true) at /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/tree-ssa-alias.c:2320 #2 0x013f82bb in refs_may_alias_p_1 (ref1=0x7fffd7d0, ref2=0x7fffd790, tbaa_p=true) at /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/tree-ssa-alias.c:2339 #3 0x00b90b06 in rtx_refs_may_alias_p (x=0x7742cac8, mem=0x7742c9a8, tbaa_p=true) at /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/alias.c:365 #4 0x00b981de in true_dependence_1 (mem=0x7742c9a8, mem_mode=E_SImode, mem_addr=0x7742c7e0, x=0x7742cac8, x_addr=0x7742c798, mem_canonicalized=false) at /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/alias.c:3048 The code here says /* Do type-based disambiguation. */ if (base1_alias_set != base2_alias_set && !alias_sets_conflict_p (base1_alias_set, base2_alias_set)) return false; and the "false" return status gets propagated all the way back up to true_dependence. It seems to me that what is going wrong is that it is failing to consider that two pointer parameters can be aliased no matter what their declared type is, and no matter what types they are cast to -- e.g. because they point to members of the same union. Should ao_ref_base_alias_set be putting everything based on pointer parameters without restrict semantics into the same alias set, maybe? Or should there be some code in indirect_refs_may_alias_p to look for this situation before it reaches the point of type-based disambiguation where it is currently failing to DTRT?
[Bug tree-optimization/93946] Bogus redundant store removal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946
--- Comment #18 from sandra at gcc dot gnu.org ---
Hmmm, it looks to me like things are going wrong in the tree fre1 pass too. I
commented out the redundant zero store in the test case to see what would
happen, like
long __attribute__((noipa))
foo (struct bb *bv, void *ptr)
{
struct aa *a = ptr;
struct bb *b = ptr;
bv->b.u.f = 1;
a->a.u.i = 0;
/* b->b.u.f = 0; */
return bv->b.u.f;
}
fre1 gets this as input:
__attribute__((noipa, noinline, noclone, no_icf))
foo (struct bb * bv, void * ptr)
{
struct bb * b;
struct aa * a;
long int _8;
:
bv_5(D)->b.u.f = 1;
MEM[(struct aa *)ptr_1(D)].a.u.i = 0;
_8 = bv_5(D)->b.u.f;
return _8;
}
and produces this output:
__attribute__((noipa, noinline, noclone, no_icf))
foo (struct bb * bv, void * ptr)
{
struct bb * b;
struct aa * a;
:
bv_5(D)->b.u.f = 1;
MEM[(struct aa *)ptr_1(D)].a.u.i = 0;
return 1;
}
This is with -O2.
Again, it seems like something is not realizing that pointer parameters can be
aliased no matter what their types are. Or perhaps that is just a symptom of
some other underlying bug. :-S
[Bug tree-optimization/93946] Bogus redundant store removal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946 --- Comment #22 from sandra at gcc dot gnu.org --- My nios2-elf test results look good now with this patch. Thanks!
[Bug target/93847] Nios II ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93847 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- Your "test cases" are not useful. Please provide something self-contained (e.g., preprocessed source code for the file that GCC ICEs on), that does not depend on all of some version of buildroot. Also please provide the complete set of command-line options used for building that file.
[Bug analyzer/96395] New: gcc.dg/analyzer/explode-2.c fails when compiled as C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96395 Bug ID: 96395 Summary: gcc.dg/analyzer/explode-2.c fails when compiled as C++ Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- gcc.dg/analyzer/explode-2.c triggers a -Wanalyzer-too-complex diagnostic when compiled as C++, but not as C: $ x86_64-linux-gnu-g++ /path/to/gcc/testsuite/gcc.dg/analyzer/explode-2.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -fanalyzer -fdiagnostics-path-format=separate-events -Wanalyzer-too-complex -fanalyzer-call-summaries --param analyzer-max-enodes-per-program-point=200 --param analyzer-bb-explosion-factor=50 -S cc1plus: warning: analysis bailed out early (701 'after-snode' enodes; 2762 enodes) [-Wanalyzer-too-complex] ... Increasing both of the params specified in the test case by a factor of 5 didn't seem to help. I ran into this problem in connection with my patches to unify loop representations in the C and C++ front ends https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541954.html but it can be reproduced separately without those patches just by compiling with g++ instead of gcc.
[Bug analyzer/96395] gcc.dg/analyzer/explode-2.c fails when compiled as C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96395 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- Once my C/C++ loop unification changes are in, this test case will fail when compiled as C, too. Recording that it fails as C++ already gives you a way to duplicate the bug meanwhile, independently of my patches, and also gives me an issue to track the future C testsuite regression introduced by my patches. It seems like it would be a good idea generally to run analyzer unit tests as both C and C++, though. This is a pretty simple test case, and yet the analyzer completely falls over on it, which doesn't fill me with confidence on how well it would work on any real C++ program, even one that doesn't use templates or exceptions.
[Bug tree-optimization/96487] New: cddce1 optimizer depends on order of basic blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96487 Bug ID: 96487 Summary: cddce1 optimizer depends on order of basic blocks Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- Created attachment 49007 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49007&action=edit c and c++ dump files If the test case gcc.dg/tree-ssa/ssa-dce-3.c is compiled as C++ code instead of as C, it fails to reduce to an empty loop as expected. It seems to be triggered by a slight difference in the input coming into the cddce1 pass. The C front end canonicalizes the test to the end of the loop so the latch (bb 5) falls through to the header (bb 6). The C++ front end orders the latch (bb 6) last with a goto to the header (bb 3). I did some additional tracing of the flow through the pass beyond the dump file output. Because the latch in the C input does not end with a control statement, it is ignored by mark_last_stmt_necessary, via the call to mark_control_dependent_edges_necessary at the end of find_obviously_necessary_stmts. So in the C case, nothing gets added to the work list, while for C++ it does process the latch block, follow the control flow out of it, and ends up marking the loop end test etc as necessary. I am wondering if this is a bug in the way the C output is handled and it is incorrectly optimizing away the loop body. It seems like it should not matter if the control transfer between blocks is done via explicit goto or via fallthrough, anyway; either it ought to handle the fallthrough case like the explicit goto case, or vice versa. I originally noticed this problem in conjunction with these patches to unify the loop handling in the C and C++ front ends: https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534142.html But it can be reproduced with unmodified sources just by compiling with g++ instead of gcc. The commands used to produce the attached dump files were x86_64-linux-gnu-gcc /path/to/gcc/testsuite/gcc.dg/tree-ssa/ssa-dce-3.c -O2 -fdump-tree-dse1 -fdump-tree-cddce1-details -S x86_64-linux-gnu-g++ /path/to/gcc/testsuite/gcc.dg/tree-ssa/ssa-dce-3.c -O2 -fdump-tree-dse1 -fdump-tree-cddce1-details -S
[Bug c/97125] [11 Regression] new problem with -Wduplicated-branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97125 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #4 from sandra at gcc dot gnu.org --- Hmmm, maybe it needs to know about the other structured control flow tree nodes I moved from cp/ to c-family/, as well as SWITCH_STMT?
[Bug c/97125] [11 Regression] new problem with -Wduplicated-branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97125 --- Comment #6 from sandra at gcc dot gnu.org --- Yeah, that looks like an easy fix. Thanks for tracking it down.
[Bug other/92435] New: % format codes for diagnostics are not documented in the GCC internals manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92435 Bug ID: 92435 Summary: % format codes for diagnostics are not documented in the GCC internals manual Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- There's a little bit of high-level guidance about compiler diagnostics in the "User Experience Guidelines" chapter of the internals manual that mentions quoting mechanisms in diagnostics, but AFAICT there is no reference documentation that lists all the %-directives and modifiers and what they mean. This makes it hard to understand what existing diagnostics are trying to do, as well as hard to write new ones.
[Bug target/92499] nios2 backend needs to consider allocated object size, not C object size for gprel optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92499 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |sandra at gcc dot gnu.org --- Comment #1 from sandra at gcc dot gnu.org --- I'll take care of this. Glibc will have a workaround to disable -mgpopt when using buggy compiler versions, but the fix ought to be backported to all active GCC versions anyway.
[Bug target/92499] nios2 backend needs to consider allocated object size, not C object size for gprel optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92499 --- Comment #2 from sandra at gcc dot gnu.org --- As I suspected, MIPS has exactly the same bug. It generates GP-relative addressing in get_flexible and get_flexible_nonzero, and puts flexible_nonzero in .sdata instead of .data. This isn't terribly surprising since they both use int_size_in_bytes (TREE_TYPE (exp)) to get compute the object size in the TARGET_IN_SMALL_DATA_P hook, and SYMBOL_REF_SMALL_P (which uses that hook) to determine whether to use GP-relative addressing. I checked all the targets that define TARGET_IN_SMALL_DATA_P if they use int_size_in_bytes: alpha: Y arc: Y c6x: N (looks like it rejects objects of aggregate type instead) frv: Y ia64: Y lm32: Y m32r: Y microblaze: Y mips: Y nios2: Y riscv: Y rs6000: Y rx: Y Looks like we need a new function in common code that returns 0 for types with flexible array members and int_size_in_bytes otherwise, and use it in all of these backends.
[Bug target/92499] nios2 backend needs to consider allocated object size, not C object size for gprel optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92499 --- Comment #3 from sandra at gcc dot gnu.org --- Created attachment 47233 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47233&action=edit buggy MIPS output for test case
[Bug target/92499] nios2 backend needs to consider allocated object size, not C object size for gprel optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92499 --- Comment #4 from sandra at gcc dot gnu.org --- Hmmm, the plot thickens. The comment on int_size_in_bytes in tree.c says: /* Return the size of TYPE (in bytes) as a wide integer or return -1 if the size can vary or is larger than an integer. */ but apparently it is failing to return -1 in this case.
[Bug rtl-optimization/951] Documentation of compiler passes and sources very out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=951 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #11 from sandra at gcc dot gnu.org --- I think that to confirm this is fixed, somebody would have to go through passes.def and compare it to the docs. It would really be nice if we could make this self-documenting, though -- include a short pass description in the code where the pass is declared which we could extract via a script that also massages passes.def into a table to insert into the manual, etc.
[Bug target/92499] nios2 backend needs to consider allocated object size, not C object size for gprel optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92499 --- Comment #5 from sandra at gcc dot gnu.org --- Richard Sandiford complained that my patch to not put objects containing flexible arrays in small data was an ABI change for references across compilation units, so I've been taking another look at this to see if I can find a different solution. The thing that triggered the link error reported in GLIBC is that the nios2 back end generates uses gp-relative addressing for a locally declared object of such a type, but was inconsistently placing the (zero-initialized) object in .bss instead of .sbss. I spent some time in the debugger on this one -- the problem is that get_variable_section returns lcomm_section in this instance, without checking whether the object is "small", or deferring to the backend to choose a section. Eventually in the nios2 back end the ASM_OUTPUT_ALIGNED_LOCAL hook looks at the size to decide whether to emit the local in .sbss or .bss, but the size it has at that point is the size of the initializer, not the declared size of the type. Local objects with nonzero initializers are placed in .sdata and objects with external linkage are also placed in .sdata/.sbss consistently with the use of gp-relative addressing. The MIPS back end has the same issue; it puts the zero-initialized local object in .comm, while the other cases end up in .sdata/.sbss. I also observed that the MIPS backend is emitting an incorrect .size directive (using the size of the non-flexible part of the object instead of the size of the initializer) for the cases it does put in .sdata/.sbss. I don't know if that is actually used by the assembler in a way that is harmful, though. So I think we could fix this without changing the ABI by fixing get_variable_section not to short-circuit the criteria the rest of the compiler uses to decide whether an object belongs in a small data section. That could optionally be combined with target-specific changes not to consider flexibly-sized objects with internal linkage not to be "small" for the purposes of either section placement or gp-relative addressing.
[Bug target/92499] nios2 backend needs to consider allocated object size, not C object size for gprel optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92499 --- Comment #6 from sandra at gcc dot gnu.org --- Created attachment 47346 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47346&action=edit improved test case with global/external cases as well as local
[Bug target/92499] nios2 backend needs to consider allocated object size, not C object size for gprel optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92499 --- Comment #7 from sandra at gcc dot gnu.org --- Created attachment 47347 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47347&action=edit nios2 output for improved test case, -O2 -mgpopt=global
[Bug target/92499] nios2 backend needs to consider allocated object size, not C object size for gprel optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92499 --- Comment #8 from sandra at gcc dot gnu.org --- Created attachment 47348 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47348&action=edit mips output for improved test case, -O2
[Bug testsuite/92622] FAIL: gcc.dg/Warray-bounds-22.c on ILP32: missing warnings for VLA on lines 67 and 69
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92622 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- I've been seeing this random failure on nios2-elf and nios2-linux-gnu, too.
[Bug target/92499] nios2 backend needs to consider allocated object size, not C object size for gprel optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92499 --- Comment #9 from sandra at gcc dot gnu.org --- Author: sandra Date: Mon Dec 2 03:52:15 2019 New Revision: 278891 URL: https://gcc.gnu.org/viewcvs?rev=278891&root=gcc&view=rev Log: 2019-12-01 Sandra Loosemore Fix bugs relating to flexibly-sized objects in nios2 backend. PR target/92499 gcc/c/ * c-decl.c (flexible_array_type_p): Move to common code. gcc/ * config/nios2/nios2.c (nios2_in_small_data_p): Do not consider objects of flexible types to be small if they have internal linkage or are declared extern. * config/nios2/nios2.h (ASM_OUTPUT_ALIGNED_LOCAL): Replace with... (ASM_OUTPUT_ALIGNED_DECL_LOCAL): ...this. Use targetm.in_small_data_p instead of the size of the object initializer. * tree.c (flexible_array_type_p): Move from C front end, and generalize to handle fields in non-C structures. * tree.h (flexible_array_type_p): Declare. gcc/testsuite/ * gcc.target/nios2/pr92499-1.c: New. * gcc.target/nios2/pr92499-2.c: New. * gcc.target/nios2/pr92499-3.c: New. Added: trunk/gcc/testsuite/gcc.target/nios2/pr92499-1.c trunk/gcc/testsuite/gcc.target/nios2/pr92499-2.c trunk/gcc/testsuite/gcc.target/nios2/pr92499-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/config/nios2/nios2.c trunk/gcc/config/nios2/nios2.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c trunk/gcc/tree.h
[Bug target/92499] nios2 backend needs to consider allocated object size, not C object size for gprel optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92499 --- Comment #10 from sandra at gcc dot gnu.org --- Author: sandra Date: Tue Dec 3 02:44:41 2019 New Revision: 278919 URL: https://gcc.gnu.org/viewcvs?rev=278919&root=gcc&view=rev Log: 2019-12-02 Sandra Loosemore Fix bugs relating to flexibly-sized objects in nios2 backend. PR target/92499 gcc/c/ * c-decl.c (flexible_array_type_p): Move to common code. gcc/ * config/nios2/nios2.c (nios2_in_small_data_p): Do not consider objects of flexible types to be small if they have internal linkage or are declared extern. * config/nios2/nios2.h (ASM_OUTPUT_ALIGNED_LOCAL): Replace with... (ASM_OUTPUT_ALIGNED_DECL_LOCAL): ...this. Use targetm.in_small_data_p instead of the size of the object initializer. * tree.c (flexible_array_type_p): Move from C front end, and generalize to handle fields in non-C structures. * tree.h (flexible_array_type_p): Declare. gcc/testsuite/ * gcc.target/nios2/pr92499-1.c: New. * gcc.target/nios2/pr92499-2.c: New. * gcc.target/nios2/pr92499-3.c: New. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/c/ChangeLog branches/gcc-9-branch/gcc/c/c-decl.c branches/gcc-9-branch/gcc/config/nios2/nios2.c branches/gcc-9-branch/gcc/config/nios2/nios2.h branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/tree.c branches/gcc-9-branch/gcc/tree.h
[Bug target/92499] nios2 backend needs to consider allocated object size, not C object size for gprel optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92499
--- Comment #11 from sandra at gcc dot gnu.org ---
I've committed a patch to fix this for nios2 only to mainline and the GCC 9
branch.
I did consider an alternate 1-line fix to target-independent code:
Index: gcc/varasm.c
===
--- gcc/varasm.c(revision 278907)
+++ gcc/varasm.c(working copy)
@@ -1201,6 +1201,7 @@ get_variable_section (tree decl, bool pr
if (ADDR_SPACE_GENERIC_P (as)
&& !DECL_THREAD_LOCAL_P (decl)
+ && !targetm.in_small_data_p (decl)
&& !(prefer_noswitch_p && targetm.have_switchable_bss_sections)
&& bss_initializer_p (decl))
{
but I am not 100% sure this will DTRT on other affected targets. On anything
that uses default_elf_select_section this will put zero-initialized data in
.sbss if targetm.in_small_data_p is true, but is that actually where it's
supposed to go? E.g., are the linker scripts set up to cope with .sbss instead
of whatever lcomm_section maps to? I think I have to defer to the other target
maintainers for what is right for their respective back ends. :-S
[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93316 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #1 from sandra at gcc dot gnu.org --- I'm seeing most of these on nios2-elf as well. Including doesn't fix the malloc-callbacks.c failures on this and other newlib targets; newlib's version of that header file defines alloca as a function-like macro instead of a function. Also observed on nios2-elf: FAIL: gcc.dg/analyzer/pattern-test-2.c == 0 (test for warnings, line 21) FAIL: gcc.dg/analyzer/pattern-test-2.c != 0 (test for warnings, line 21) FAIL: gcc.dg/analyzer/pattern-test-2.c (test for excess errors) Excess errors: /path/to/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:21:6: warning: pattern match on 'p == 0' /path/to/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:21:17: warning: pattern match on 'q == 0'
[Bug libstdc++/88999] [9/10 Regression] testcases using in_avail() fail on nios2-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88999 --- Comment #4 from sandra at gcc dot gnu.org --- I've been taking another look at this issue. It looks like the trouble is that the "checking for S_ISREG or S_IFREG" test in the configure script is failing because it tries to link the test program without specifying an appropriate linker script. Newlib with GDB semihosting ought to support S_IFREG, and indeed the program makes it through the compilation step without complaint only to fail because the default linker script isn't pulling in the semihosting library. I imagine this problem might affect other bare-metal targets that have to be linked explicitly with a BSP, too. Anyway, std::__basic_file::showmanyc returns 0 when neither _GLIBCXX_HAVE_S_ISREG nor _GLIBCXX_HAVE_S_IFREG is defined, which causes in_avail() to return 0 as well. I've also found a bug in the nios2 libgloss implementation of lseek (it doesn't encode negative offsets correctly), but lseek is never even getting called here.
[Bug libstdc++/88999] [9/10 Regression] testcases using in_avail() fail on nios2-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88999 --- Comment #5 from sandra at gcc dot gnu.org --- This may be the same as PR 79193. I'll check and see whether the patch attached to that issue fixes it.
[Bug libstdc++/88999] [9/10 Regression] testcases using in_avail() fail on nios2-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88999 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from sandra at gcc dot gnu.org --- Yes, confirmed: this is a misconfiguration error, same as PR 79193. *** This bug has been marked as a duplicate of bug 79193 ***
[Bug libstdc++/79193] libstdc++ configure incorrectly decides linking works for cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79193 --- Comment #5 from sandra at gcc dot gnu.org --- *** Bug 88999 has been marked as a duplicate of this bug. ***
[Bug target/88284] nios2: pessimistic ldw-to-stwio scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88284 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #1 from sandra at gcc dot gnu.org --- The current behavior is intentional. GCC treats I/O peripheral memory as volatile, so accesses are not re-ordered with respect to other instructions.
[Bug c/90690] Undocumented -Werror-implicit-function-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90690 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- I think this has been fixed? In a recent-ish trunk build, I see gcc -Q --help-warning prints -Werror-implicit-function-declaration -Werror=implicit-function-declaration whereas in GCC 9 it just printed -Werror-implicit-function-declaration
[Bug c++/90467] Documentation: many warning options that are enabled by default are documented in the -Woption form, not -Wno-option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90467 sandra at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from sandra at gcc dot gnu.org --- I've made a pass through all the warning options to try to fix this, plus fixing alphabetization of the option summary sections, making sure the options are documented in the section corresponding to where they are listed in the option summary, all the C++ warnings are grouped together, etc. This section of the manual is still a mess, though -- I'll try to do some more work on it as I have time.
[Bug target/53633] __attribute__((naked)) should disable -Wreturn-type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53633 --- Comment #3 from sandra at gcc dot gnu.org 2012-07-25 18:08:11 UTC --- Author: sandra Date: Wed Jul 25 18:08:06 2012 New Revision: 189860 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189860 Log: 2012-07-25 Sandra Loosemore Paul Brook PR target/53633 gcc/ * target.def (warn_func_return): New hook. * doc/tm.texi.in (TARGET_WARN_FUNC_RETURN): New hook. * doc/tm.texi: Regenerate. * doc/sourcebuild.texi (Effective-Target Keywords): Document naked_functions. * ipa-pure-const.c (warn_function_noreturn): Check targetm.warn_func_return. * tree-cfg.c (execute_warn_function_return): Likewise. * config/spu/spu.c (spu_warn_func_return): New. (TARGET_WARN_FUNC_RETURN): Define. * config/rx/rx.c (rx_warn_func_return): New. (TARGET_WARN_FUNC_RETURN): Define. * config/avr/avr.c (avr_warn_func_return): New. (TARGET_WARN_FUNC_RETURN): Define. * config/arm/arm.c (arm_warn_func_return): New. (TARGET_WARN_FUNC_RETURN): Define. * config/mcore/mcore.c (mcore_warn_func_return): New. (TARGET_WARN_FUNC_RETURN): Define. (saved_warn_return_type, saved_warn_return_type_count): Remove. (mcore_reorg, mcore_handle_naked_attribute): Remove warn_return hack. gcc/cp/ * decl.c (finish_function): Check targetm.warn_func_return. gcc/testsuite/ * lib/target-suports.exp (check_effective_target_naked_functions): New. * c-c++-common/pr53633.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr53633.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/avr/avr.c trunk/gcc/config/mcore/mcore.c trunk/gcc/config/rx/rx.c trunk/gcc/config/spu/spu.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/doc/sourcebuild.texi trunk/gcc/doc/tm.texi trunk/gcc/doc/tm.texi.in trunk/gcc/ipa-pure-const.c trunk/gcc/target.def trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp trunk/gcc/tree-cfg.c
[Bug rtl-optimization/50380] cc1 hangs eating 100% CPU
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50380 --- Comment #5 from sandra at gcc dot gnu.org 2011-12-19 20:29:27 UTC --- Author: sandra Date: Mon Dec 19 20:29:21 2011 New Revision: 182498 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182498 Log: 2011-12-19 Sandra Loosemore Tom de Vries PR rtl-opt/50380 gcc/ * cse.c (find_comparison_args): Detect fixed point and bail early. gcc/testsuite/ * gcc.c-torture/compile/pr50380.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr50380.c Modified: trunk/gcc/ChangeLog trunk/gcc/cse.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/59447] --with-dwarf2 should be documented as meaning "DWARF 2 or later" instead of just "DWARF 2"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #5 from sandra at gcc dot gnu.org --- Actually, this issue is already on my radar, but there are definitely more documentation bugs out there than I have time to fix this release cycle. Of course there's nothing stopping other people from fixing some of these things too. :-)
[Bug other/16615] throughout gcc docu and code numerous "can not"'s appear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16615 --- Comment #10 from sandra at gcc dot gnu.org --- Patch was posted here. I'd like some review on methodology for the mechanically-generated parts before checking in the whole mess. https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01732.html
[Bug other/16615] throughout gcc docu and code numerous "can not"'s appear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16615 --- Comment #11 from sandra at gcc dot gnu.org --- Author: sandra Date: Wed Jan 9 21:37:45 2019 New Revision: 267783 URL: https://gcc.gnu.org/viewcvs?rev=267783&root=gcc&view=rev Log: 2019-01-09 Sandra Loosemore PR other/16615 [1/5] contrib/ * mklog: Mechanically replace "can not" with "cannot". gcc/ * Makefile.in: Mechanically replace "can not" with "cannot". * alias.c: Likewise. * builtins.c: Likewise. * calls.c: Likewise. * cgraph.c: Likewise. * cgraph.h: Likewise. * cgraphclones.c: Likewise. * cgraphunit.c: Likewise. * combine-stack-adj.c: Likewise. * combine.c: Likewise. * common/config/i386/i386-common.c: Likewise. * config/aarch64/aarch64.c: Likewise. * config/alpha/sync.md: Likewise. * config/arc/arc.c: Likewise. * config/arc/predicates.md: Likewise. * config/arm/arm-c.c: Likewise. * config/arm/arm.c: Likewise. * config/arm/arm.h: Likewise. * config/arm/arm.md: Likewise. * config/arm/cortex-r4f.md: Likewise. * config/csky/csky.c: Likewise. * config/csky/csky.h: Likewise. * config/darwin-f.c: Likewise. * config/epiphany/epiphany.md: Likewise. * config/i386/i386.c: Likewise. * config/i386/sol2.h: Likewise. * config/m68k/m68k.c: Likewise. * config/mcore/mcore.h: Likewise. * config/microblaze/microblaze.md: Likewise. * config/mips/20kc.md: Likewise. * config/mips/sb1.md: Likewise. * config/nds32/nds32.c: Likewise. * config/nds32/predicates.md: Likewise. * config/pa/pa.c: Likewise. * config/rs6000/e300c2c3.md: Likewise. * config/rs6000/rs6000.c: Likewise. * config/s390/s390.h: Likewise. * config/sh/sh.c: Likewise. * config/sh/sh.md: Likewise. * config/spu/vmx2spu.h: Likewise. * cprop.c: Likewise. * dbxout.c: Likewise. * df-scan.c: Likewise. * doc/cfg.texi: Likewise. * doc/extend.texi: Likewise. * doc/fragments.texi: Likewise. * doc/gty.texi: Likewise. * doc/invoke.texi: Likewise. * doc/lto.texi: Likewise. * doc/md.texi: Likewise. * doc/objc.texi: Likewise. * doc/rtl.texi: Likewise. * doc/tm.texi: Likewise. * dse.c: Likewise. * emit-rtl.c: Likewise. * emit-rtl.h: Likewise. * except.c: Likewise. * expmed.c: Likewise. * expr.c: Likewise. * fold-const.c: Likewise. * genautomata.c: Likewise. * gimple-fold.c: Likewise. * hard-reg-set.h: Likewise. * ifcvt.c: Likewise. * ipa-comdats.c: Likewise. * ipa-cp.c: Likewise. * ipa-devirt.c: Likewise. * ipa-fnsummary.c: Likewise. * ipa-icf.c: Likewise. * ipa-inline-transform.c: Likewise. * ipa-inline.c: Likewise. * ipa-polymorphic-call.c: Likewise. * ipa-profile.c: Likewise. * ipa-prop.c: Likewise. * ipa-pure-const.c: Likewise. * ipa-reference.c: Likewise. * ipa-split.c: Likewise. * ipa-visibility.c: Likewise. * ipa.c: Likewise. * ira-build.c: Likewise. * ira-color.c: Likewise. * ira-conflicts.c: Likewise. * ira-costs.c: Likewise. * ira-int.h: Likewise. * ira-lives.c: Likewise. * ira.c: Likewise. * ira.h: Likewise. * loop-invariant.c: Likewise. * loop-unroll.c: Likewise. * lower-subreg.c: Likewise. * lra-assigns.c: Likewise. * lra-constraints.c: Likewise. * lra-eliminations.c: Likewise. * lra-lives.c: Likewise. * lra-remat.c: Likewise. * lra-spills.c: Likewise. * lra.c: Likewise. * lto-cgraph.c: Likewise. * lto-streamer-out.c: Likewise. * postreload-gcse.c: Likewise. * predict.c: Likewise. * profile-count.h: Likewise. * profile.c: Likewise. * recog.c: Likewise. * ree.c: Likewise. * reload.c: Likewise. * reload1.c: Likewise. * reorg.c: Likewise. * resource.c: Likewise. * rtl.def: Likewise. * rtl.h: Likewise. * rtlanal.c: Likewise. * sched-deps.c: Likewise. * sched-ebb.c: Likewise. * sched-rgn.c: Likewise. * sel-sched-ir.c: Likewise. * sel-sched.c: Likewise. * shrink-wrap.c: Likewise. * simplify-rtx.c: Likewise. * symtab.c: Likewise. * target.def: Likewise. * toplev.c: Likewise. * tree-call-cdce.c: Likewise. * tree-cfg.c: Likewise. * tree-complex.c: Likewise. * tree-core.h: Likewise. * tree-eh.c: Likewise. * tree-inline.c: Likewi
[Bug other/16615] throughout gcc docu and code numerous "can not"'s appear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16615 --- Comment #12 from sandra at gcc dot gnu.org --- Author: sandra Date: Wed Jan 9 21:39:49 2019 New Revision: 267784 URL: https://gcc.gnu.org/viewcvs?rev=267784&root=gcc&view=rev Log: 2019-01-09 Sandra Loosemore PR other/16615 [2/5] include/ * libiberty.h: Mechanically replace "can not" with "cannot". * plugin-api.h: Likewise. libiberty/ * cp-demangle.c: Mechanically replace "can not" with "cannot". * floatformat.c: Likewise. * strerror.c: Likewise. Modified: trunk/include/ChangeLog trunk/include/libiberty.h trunk/include/plugin-api.h trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c trunk/libiberty/floatformat.c trunk/libiberty/strerror.c
[Bug other/16615] throughout gcc docu and code numerous "can not"'s appear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16615 --- Comment #13 from sandra at gcc dot gnu.org --- Author: sandra Date: Wed Jan 9 21:41:36 2019 New Revision: 267785 URL: https://gcc.gnu.org/viewcvs?rev=267785&root=gcc&view=rev Log: 2019-01-09 Sandra Loosemore PR other/16615 [3/5] gcc/testsuite/ * g++.dg/lto/odr-1_1.C: Update diagnostic message patterns to replace "can not" with "cannot". * gfortran.dg/common_15.f90: Likewise. * gfortran.dg/derived_result_2.f90: Likewise. * gfortran.dg/do_check_6.f90: Likewise. * gfortran.dg/namelist_args.f90: Likewise. * gfortran.dg/negative_unit_check.f90: Likewise. * gfortran.dg/pure_formal_3.f90: Likewise. * obj-c++.dg/attributes/method-attribute-2.mm: Likewise. * obj-c++.dg/exceptions-3.mm: Likewise. * obj-c++.dg/exceptions-4.mm: Likewise. * obj-c++.dg/exceptions-5.mm: Likewise. * obj-c++.dg/property/at-property-23.mm: Likewise. * obj-c++.dg/property/dotsyntax-17.mm: Likewise. * obj-c++.dg/property/property-neg-7.mm: Likewise. * objc.dg/attributes/method-attribute-2.m: Likewise. * objc.dg/exceptions-3.m: Likewise. * objc.dg/exceptions-4.m: Likewise. * objc.dg/exceptions-5.m: Likewise. * objc.dg/param-1.m: Likewise. * objc.dg/property/at-property-23.m: Likewise. * objc.dg/property/dotsyntax-17.m: Likewise. * objc.dg/property/property-neg-7.m: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/lto/odr-1_1.C trunk/gcc/testsuite/gfortran.dg/common_15.f90 trunk/gcc/testsuite/gfortran.dg/derived_result_2.f90 trunk/gcc/testsuite/gfortran.dg/do_check_6.f90 trunk/gcc/testsuite/gfortran.dg/namelist_args.f90 trunk/gcc/testsuite/gfortran.dg/negative_unit_check.f90 trunk/gcc/testsuite/gfortran.dg/pure_formal_3.f90 trunk/gcc/testsuite/obj-c++.dg/attributes/method-attribute-2.mm trunk/gcc/testsuite/obj-c++.dg/exceptions-3.mm trunk/gcc/testsuite/obj-c++.dg/exceptions-4.mm trunk/gcc/testsuite/obj-c++.dg/exceptions-5.mm trunk/gcc/testsuite/obj-c++.dg/property/at-property-23.mm trunk/gcc/testsuite/obj-c++.dg/property/dotsyntax-17.mm trunk/gcc/testsuite/obj-c++.dg/property/property-neg-7.mm trunk/gcc/testsuite/objc.dg/attributes/method-attribute-2.m trunk/gcc/testsuite/objc.dg/exceptions-3.m trunk/gcc/testsuite/objc.dg/exceptions-4.m trunk/gcc/testsuite/objc.dg/exceptions-5.m trunk/gcc/testsuite/objc.dg/param-1.m trunk/gcc/testsuite/objc.dg/property/at-property-23.m trunk/gcc/testsuite/objc.dg/property/dotsyntax-17.m trunk/gcc/testsuite/objc.dg/property/property-neg-7.m
[Bug other/16615] throughout gcc docu and code numerous "can not"'s appear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16615 --- Comment #14 from sandra at gcc dot gnu.org --- Author: sandra Date: Wed Jan 9 21:44:56 2019 New Revision: 267786 URL: https://gcc.gnu.org/viewcvs?rev=267786&root=gcc&view=rev Log: 2019-01-09 Sandra Loosemore PR other/16615 [4/5] gcc/ * config/pa/pa.c: Change "can not" to "cannot". * gimple-ssa-evrp-analyze.c: Likewise. * ipa-icf.c: Likewise. * ipa-polymorphic-call.c: Likewise. * ipa-pure-const.c: Likewise. * lra-constraints.c: Likewise. * lra-remat.c: Likewise. * reload1.c: Likewise. * reorg.c: Likewise. * tree-ssa-uninit.c: Likewise. gcc/ada/ * exp_ch11.adb: Change "can not" to "cannot". * sem_ch4.adb: Likewise. gcc/fortran/ * expr.c: Change "can not" to "cannot". libobjc/ * objc/runtime.h: Change "can not" to "cannot". Modified: trunk/gcc/ChangeLog trunk/gcc/ada/ChangeLog trunk/gcc/ada/exp_ch11.adb trunk/gcc/ada/sem_ch4.adb trunk/gcc/config/pa/pa.c trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/gimple-ssa-evrp-analyze.c trunk/gcc/ipa-icf.c trunk/gcc/ipa-polymorphic-call.c trunk/gcc/ipa-pure-const.c trunk/gcc/lra-constraints.c trunk/gcc/lra-remat.c trunk/gcc/reload1.c trunk/gcc/reorg.c trunk/gcc/tree-ssa-uninit.c trunk/libobjc/ChangeLog trunk/libobjc/objc/runtime.h
[Bug other/16615] throughout gcc docu and code numerous "can not"'s appear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16615 --- Comment #15 from sandra at gcc dot gnu.org --- Author: sandra Date: Wed Jan 9 21:46:45 2019 New Revision: 267787 URL: https://gcc.gnu.org/viewcvs?rev=267787&root=gcc&view=rev Log: 2019-01-09 Sandra Loosemore PR other/16615 [5/5] gcc/po/ * gcc.pot: Regenerate. Modified: trunk/gcc/po/ChangeLog trunk/gcc/po/gcc.pot
[Bug other/16615] throughout gcc docu and code numerous "can not"'s appear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16615 sandra at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from sandra at gcc dot gnu.org --- I'm marking this issue as fixed, although there are still instances of "can not" in files maintained outside the normal GCC process. See the mailing list discussion for details. Also, I copied the changes to libiberty/ and include/ to the binutils-gdb copy of those directories.
[Bug libstdc++/86756] Don't define __cpp_lib_filesystem unless --enable-libstdcxx-filesystem-ts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86756 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #6 from sandra at gcc dot gnu.org --- The patch for this issue seems to have caused several test regressions and new failures on nios2-elf, a newlib-based target with semihosted i/o. It's getting link-time errors about references to undefined symbols chdir, mkdir, etc. It's not clear how I'm supposed to fix that. Am I missing some configure option, or should I be adding dg-skip-if (or whatever) to the failing tests?
[Bug libstdc++/88999] New: [9 Regression] testcases using in_avail() fail on nios2-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88999 Bug ID: 88999 Summary: [9 Regression] testcases using in_avail() fail on nios2-elf Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- I'm seeing some libstdc++ test regressions on nios2-elf testing on mainline. The symptoms are assertion failures about the results of calls to in_avail(). # Assertion 'strmsz_1 > strmsz_2' failed. FAIL: 27_io/basic_filebuf/sgetn/char/1-in.cc execution test FAIL: 27_io/basic_filebuf/sgetn/char/1-io.cc execution test FAIL: 27_io/basic_filebuf/sgetn/char/2-in.cc execution test FAIL: 27_io/basic_filebuf/sgetn/char/2-io.cc execution test # Assertion 'i != 0' failed. FAIL: 27_io/basic_istream/readsome/char/6746-2.cc execution test FAIL: 27_io/basic_istream/readsome/wchar_t/6746-2.cc execution test I see that these tests are xfailed for bare-metal ARM targets with a note that ARM semihosting doesn't support the underlying fstat call, but that is not true of nios2. These tests all passed on nios2-elf with GCC 8. I realize it is hard for other people to test this target, but I'd be happy to test a patch or do some debugging to try to track it down given some clues about where to look. (Maybe this failure rings a bell with someone already familiar with the code?)
[Bug libstdc++/89023] New: libstdc++ test failure; can't find omp.h with --disable-libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89023 Bug ID: 89023 Summary: libstdc++ test failure; can't find omp.h with --disable-libgomp Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- On nios2-elf, I'm seeing FAIL: 28_regex/headers/regex/parallel_mode.cc (test for excess errors) Specifically: In file included from /path/to/nios2-elf/include/c++/9.0.0/parallel/algobase.h:40, from /path/to/nios2-elf/include/c++/9.0.0/bits/stl_algobase.h:1459, from /path/to/nios2-elf/include/c++/9.0.0/algorithm:61, from /path/to/nios2-elf/include/c++/9.0.0/regex:38, from /path/to/src/gcc/libstdc++-v3/testsuite/28_regex/headers/regex/parallel_mode.cc:22: /path/to/nios2-elf/include/c++/9.0.0/parallel/base.h:37: fatal error: omp.h: No such file or directory I'm building for this bare-metal target with --disable-libgomp so of course there is no omp.h being installed, and this test cannot work. Is there some reason this test is conditionalized differently than, say, 28_regex/headers/regex/parallel_mode.cc ?? That one is properly recognized as unsupported on this target. Also, the underlying failure seems related to pr35887. Why is libstdc++ even installing headers that depend on omp.h with --disable-libgomp?
[Bug middle-end/83889] [8 regression] new failures on some arm targets after r256644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83889 --- Comment #4 from sandra at gcc dot gnu.org --- Author: sandra Date: Wed Sep 11 20:53:46 2019 New Revision: 275667 URL: https://gcc.gnu.org/viewcvs?rev=275667&root=gcc&view=rev Log: 2019-09-11 Sandra Loosemore PR testsuite/83889 gcc/testsuite/ * gcc.dg/vect/pr81740-2.c: Remove explicit dg-do run. * gcc.dg/vect/pr88598-1.c: Likewise. * gcc.dg/vect/pr88598-2.c: Likewise. * gcc.dg/vect/pr88598-3.c: Likewise. * gcc.dg/vect/pr88598-4.c: Likewise. * gcc.dg/vect/pr88598-5.c: Likewise. * gcc.dg/vect/pr88598-6.c: Likewise. * gcc.dg/vect/pr89440.c: Likewise. * gcc.dg/vect/pr90018.c: Likewise. * gcc.dg/vect/pr91293-1.c: Likewise. * gcc.dg/vect/pr91293-2.c: Likewise. * gcc.dg/vect/pr91293-3.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr81740-1.c trunk/gcc/testsuite/gcc.dg/vect/pr81740-2.c trunk/gcc/testsuite/gcc.dg/vect/pr88598-1.c trunk/gcc/testsuite/gcc.dg/vect/pr88598-2.c trunk/gcc/testsuite/gcc.dg/vect/pr88598-3.c trunk/gcc/testsuite/gcc.dg/vect/pr88598-4.c trunk/gcc/testsuite/gcc.dg/vect/pr88598-5.c trunk/gcc/testsuite/gcc.dg/vect/pr88598-6.c trunk/gcc/testsuite/gcc.dg/vect/pr89440.c trunk/gcc/testsuite/gcc.dg/vect/pr90018.c trunk/gcc/testsuite/gcc.dg/vect/pr91293-1.c trunk/gcc/testsuite/gcc.dg/vect/pr91293-2.c trunk/gcc/testsuite/gcc.dg/vect/pr91293-3.c
[Bug middle-end/83889] [8 regression] new failures on some arm targets after r256644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83889 --- Comment #5 from sandra at gcc dot gnu.org --- Author: sandra Date: Sat Sep 14 19:00:15 2019 New Revision: 275718 URL: https://gcc.gnu.org/viewcvs?rev=275718&root=gcc&view=rev Log: 2019-09-14 Sandra Loosemore PR testsuite/83889 gcc/testsuite/ * g++.dg/vect/pr87914.cc: Remove explicit dg-do run. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/vect/pr87914.cc
[Bug middle-end/26241] [7/8/9/10 Regression] None of the IPA passes are documented in passes.texi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26241 --- Comment #20 from sandra at gcc dot gnu.org --- Author: sandra Date: Thu Oct 10 19:44:26 2019 New Revision: 276851 URL: https://gcc.gnu.org/viewcvs?rev=276851&root=gcc&view=rev Log: 2019-10-10 Xiong Hu Luo Sandra Loosemore gcc/ PR middle-end/26241 * doc/lto.texi (IPA): Reference to the IPA passes. * doc/passes.texi (Pass manager): Add node IPA passes and description for each IPA pass. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/lto.texi trunk/gcc/doc/passes.texi
[Bug c/80409] Document that va_arg(ap, void*) can be used to consume any pointer argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80409 --- Comment #5 from sandra at gcc dot gnu.org --- Author: sandra Date: Tue Feb 26 02:33:26 2019 New Revision: 269203 URL: https://gcc.gnu.org/viewcvs?rev=269203&root=gcc&view=rev Log: 2019-02-25 Sandra Loosemore PR c/80409 gcc/ * doc/extend.texi (Variadic Pointer Args): New section. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi
[Bug c/80409] Document that va_arg(ap, void*) can be used to consume any pointer argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80409 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from sandra at gcc dot gnu.org --- Fixed on trunk.
[Bug demangler/79111] demangle_template tries to allocate 18446744070799748648 bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79111 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- Am I correct in thinking this bug has been rendered moot by commit 267363, which deleted most of the code in cplus-dem.c?
[Bug other/89817] New: remove references to type modes from user docs for vector extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89817 Bug ID: 89817 Summary: remove references to type modes from user docs for vector extensions Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- The existing user documentation for vector extensions (including the type and variable attributes and not just the Vector Extensions section) is full of references to type modes. This is an internal GCC implementation detail and probably only confuses ordinary users. We need to rewrite this documentation to remove the references and explain the concepts in some other way.
[Bug middle-end/82063] issues with arguments enabled by -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82063 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #15 from sandra at gcc dot gnu.org --- It appears that last group of patches checked in on Jul 20 caused regressions. I've seen these on arm-none-eabi and other targets: FAIL: gcc.dg/attr-alloc_size-3.c (test for warnings, line 403) FAIL: gcc.dg/attr-alloc_size-3.c (test for warnings, line 404) FAIL: gcc.dg/attr-alloc_size-3.c (test for warnings, line 406) FAIL: gcc.dg/attr-alloc_size-3.c (test for warnings, line 407) FAIL: gcc.dg/attr-alloc_size-3.c (test for warnings, line 408) FAIL: gcc.dg/attr-alloc_size-3.c (test for warnings, line 409) FAIL: gcc.dg/attr-alloc_size-3.c (test for warnings, line 410) FAIL: gcc.dg/attr-alloc_size-3.c (test for warnings, line 413) FAIL: gcc.dg/attr-alloc_size-3.c (test for warnings, line 414) FAIL: gcc.dg/attr-alloc_size-3.c (test for warnings, line 416) FAIL: gcc.dg/attr-alloc_size-3.c (test for warnings, line 438) FAIL: gcc.dg/attr-alloc_size-3.c (test for warnings, line 449) FAIL: gcc.dg/attr-alloc_size-3.c (test for warnings, line 453) FAIL: gcc.dg/attr-alloc_size-3.c (test for warnings, line 454) FAIL: gcc.dg/attr-alloc_size-3.c (test for warnings, line 455) FAIL: gcc.dg/attr-alloc_size-3.c (test for excess errors) FAIL: gcc.dg/attr-alloc_size-3.c argument 2 (test for warnings, line 410) FAIL: gcc.dg/attr-alloc_size-3.c argument 2 (test for warnings, line 455) FAIL: gcc.dg/Wvla-larger-than-3.c (test for warnings, line 66) FAIL: gcc.dg/pr42611.c (test for warnings, line 17)
[Bug libstdc++/78179] FAIL: 26_numerics/headers/cmath/hypot.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78179 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #1 from sandra at gcc dot gnu.org --- This test also fails on nios2 (both nios2-elf and nios2-linux-gnu).
[Bug target/61024] nios2-rtems4.11 build of 4.9.0 fails on FreeBSD 10 c++ (clang).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61024 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #3 from sandra at gcc dot gnu.org --- I believe this issue should be closed, as RTEMS support for Nios II was committed back in July 2014. https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02124.html That patch provided the missing definition for TARGET_LINUX_ABI, among other things.
[Bug other/85716] No easy way for end-user to tell what GCC is doing when compilation is slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85716 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #9 from sandra at gcc dot gnu.org --- Just to clarify, I didn't have anything to do with proposing a "progress bar"; I just needed to know whether the split1 pass had run yet. And I ended up solving that problem by using a property instead of a dynamic pass numbering thing.
[Bug target/59784] Nios2: Wrong code generation for fextsd custom instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59784 sandra at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from sandra at gcc dot gnu.org --- Closing this issue as it was fixed in 2014.
[Bug rtl-optimization/62130] ld.exe: nios2_work.elf: Not enough room for program headers, try linking with -N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62130 sandra at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #2 from sandra at gcc dot gnu.org --- Closing this issue since no test case was ever provided to demonstrate it's a gcc bug instead of a linker or BSP issue.
[Bug target/80024] nios2: unclear wording "numeric digits" in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80024 --- Comment #1 from sandra at gcc dot gnu.org --- Author: sandra Date: Sat Oct 27 21:34:43 2018 New Revision: 265561 URL: https://gcc.gnu.org/viewcvs?rev=265561&root=gcc&view=rev Log: 2018-10-27 Sandra Loosemore PR target/80024 gcc/ * config/nios2/nios2.c (nios2_valid_target_attribute_rec): Fix error message. Modified: trunk/gcc/ChangeLog trunk/gcc/config/nios2/nios2.c
[Bug target/80024] nios2: unclear wording "numeric digits" in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80024 sandra at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from sandra at gcc dot gnu.org --- Fixed on mainline now.
[Bug target/85035] nios2: adding -fdelete-null-pointer-checks with -O2 enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85035
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
--- Comment #3 from sandra at gcc dot gnu.org ---
I've looked at this on mainline trunk and I'm not convinced there's a bug here,
or at least not a nios2 backend bug.
The -fdelete-null-pointer-checks option is badly named. What it really does is
allow attempts to dereference a null pointer to be combined and/or replaced
with some other code sequence that also causes a trap. So in the isolate-paths
tree pass, we're getting
if (t_4(D) != 0B)
goto ; [100.00%]
else
goto ; [0.00%]
[count: 0]:
# iftmp.0_8 = PHI <0B(2)>
_9 ={v} iftmp.0_8->m_LL;
__builtin_trap ();
The long long read is tagged as volatile to prevent it from getting optimized
away from later passes, and -mno-cache-volatile says to use the io instructions
for volatile memory reads and writes.
[Bug target/85035] nios2: adding -fdelete-null-pointer-checks with -O2 enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85035 --- Comment #4 from sandra at gcc dot gnu.org --- Created attachment 44912 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44912&action=edit assembly language output
[Bug tree-optimization/86965] nios2 optimizer forgets about known upper bits of register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86965
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
Component|target |tree-optimization
--- Comment #1 from sandra at gcc dot gnu.org ---
I'm not sure what command-line options you were using, but with -O2 the bad2
case now generates the expected code.
Looking at the bad1 case, this is what's coming out of the tree optimizers, and
what the back end has to deal with for RTL expansion:
bad1 (const signed char * str, int * res)
{
int c;
signed char _1;
int _2;
int _11;
signed char _12;
_Bool _13;
[local count: 1073741824]:
_1 = *str_6(D);
c_8 = (int) _1;
_2 = c_8 + -48;
*res_9(D) = _2;
_12 = _1 & -33;
_13 = _12 == 69;
_11 = (int) _13;
return _11;
}
The code coming out of RTL expand is a mess too; there's no QImode "and"
instruction, it can't use the SImode "andi" instruction because that it only
accepts small unsigned constants (not -33), and then it has to sign-extend the
QImode result it computed because the comparison instructions need SImode too.
FWIW I think the real bug here is in the tree reassoc1 pass: it shouldn't
attempt this optimization if there is no optab support for bitwise AND in the
appropriate mode. So I'm reclassifying this as a tree-optimization bug rather
than a target bug; if the maintainers dispute that, feel free to switch it back
and I will take another look see if I can do something in the backend to
recombine the insns.
[Bug target/86975] wrong peephole optimization applied on nios2 and mips targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86975 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #1 from sandra at gcc dot gnu.org --- Given that this code is originating in the tree reassoc1 pass, wouldn't it be better to just make that pass prefer to generate a code sequence with an unsigned constant on all targets? It should work just as well as the current negative-constant expansion does on targets that support unsigned constants, right?
[Bug tree-optimization/86965] nios2 optimizer forgets about known upper bits of register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86965 --- Comment #2 from sandra at gcc dot gnu.org --- Also see PR86975, which is specifically about that negative constant operand to the AND expression being generated by the range optimizer.
[Bug target/85035] nios2: adding -fdelete-null-pointer-checks with -O2 enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85035 sandra at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from sandra at gcc dot gnu.org --- I'm marking this issue as resolved since it seems to be fixed on trunk now.
[Bug target/87079] nios2 optimization for size - case of regression relatively to 5.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87079 sandra at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-02 CC||sandra at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |sandra at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from sandra at gcc dot gnu.org --- This looks like a problem with the nios2 instruction costs. Things are going wrong in expand_widening_mult (in expmed.c); compiling with -O2 takes the expand_binop path at the end to use the provided umulsidi3 expander, but with -Os it thinks the expand_mult_const path is better. I'll try to poke at this some more and come up with a patch.
[Bug target/87079] nios2 optimization for size - case of regression relatively to 5.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87079 --- Comment #2 from sandra at gcc dot gnu.org --- Author: sandra Date: Sat Nov 3 18:12:44 2018 New Revision: 265770 URL: https://gcc.gnu.org/viewcvs?rev=265770&root=gcc&view=rev Log: 2018-11-03 Sandra Loosemore PR target/87079 gcc/ * config/nios2/nios2.c (nios2_rtx_costs): Recognize sidi3 pattern. gcc/testsuite/ * gcc.target/nios2/pr87079-1.c: New. * gcc.target/nios2/pr87079-2.c: New. Added: trunk/gcc/testsuite/gcc.target/nios2/pr87079-1.c trunk/gcc/testsuite/gcc.target/nios2/pr87079-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/nios2/nios2.c trunk/gcc/testsuite/ChangeLog
[Bug target/87079] nios2 optimization for size - case of regression relatively to 5.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87079 sandra at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from sandra at gcc dot gnu.org --- Fixed on trunk.
[Bug target/78357] nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357 sandra at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #12 from sandra at gcc dot gnu.org --- I'm closing this issue since it looks like it was fixed a couple of years ago. The GCC 6 branch is now closed so it's too late to backport.
[Bug driver/80828] Command line option -e not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80828 --- Comment #2 from sandra at gcc dot gnu.org --- Author: sandra Date: Thu Nov 8 01:26:28 2018 New Revision: 265903 URL: https://gcc.gnu.org/viewcvs?rev=265903&root=gcc&view=rev Log: 2018-11-07 Sandra Loosemore PR driver/80828 gcc/ * doc/invoke.texi (Option Summary): Add -e and --entry. (Link Options): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug driver/80828] Command line option -e not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80828 sandra at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from sandra at gcc dot gnu.org --- Documentation for this option has been added on trunk. There are several driver options, including this one, that don't include any documentation for the --help output. I'm not sure if that was deliberate or not, but if it's a problem, it would be worth doing a review to see what else is missing.
[Bug middle-end/42726] -fno-common documentation inaccuracy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42726 --- Comment #1 from sandra at gcc dot gnu.org --- Author: sandra Date: Thu Nov 8 03:37:32 2018 New Revision: 265906 URL: https://gcc.gnu.org/viewcvs?rev=265906&root=gcc&view=rev Log: 2018-11-07 Sandra Loosemore PR middle-end/42726 gcc/ * doc/invoke.texi (Code Gen Options): Clarify -fno-common behavior. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug middle-end/42726] -fno-common documentation inaccuracy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42726 sandra at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from sandra at gcc dot gnu.org --- This has (finally) been fixed on trunk.
[Bug sanitizer/81902] new -fsanitize=pointer-overflow option undocumented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81902 sandra at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from sandra at gcc dot gnu.org --- Closing this issue as it has been fixed.
[Bug sanitizer/80998] Implement -fsanitize=pointer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80998 Bug 80998 depends on bug 81902, which changed state. Bug 81902 Summary: new -fsanitize=pointer-overflow option undocumented https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81902 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/54615] unclear documentation on -fomit-frame-pointer for -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54615
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||sandra at gcc dot gnu.org
Resolution|--- |WORKSFORME
--- Comment #1 from sandra at gcc dot gnu.org ---
The text about the interaction between -O and -fomit-frame-pointer in the
discussion of both options has been rewritten since this issue was filed. It
looks like it agrees with the code: "Enabled by default at @option{-O} and
higher."
[Bug middle-end/51019] unclear documentation on -fomit-frame-pointer default for -Os and different platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51019
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||sandra at gcc dot gnu.org
Resolution|--- |WORKSFORME
--- Comment #2 from sandra at gcc dot gnu.org ---
Since this issue was filed, the discussion about -fomit-frame-pointer has been
rewritten so that it no longer mentions specific releases or targets. It now
says "Enabled by default at @option{-O} and higher.", which matches what the
code in opts.c does with it.
[Bug c++/43105] Document restrictions on mixing -fno-rtti and -frtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43105 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #4 from sandra at gcc dot gnu.org --- It sounds to me like the right solution here is just to add a vague warning that mixing -frtti and -fno-rtti code may not always work, citing the base class example in the issue problem statement. WDYT?
[Bug other/36572] Documentation for some options starting with “no-” not clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36572 --- Comment #1 from sandra at gcc dot gnu.org --- Author: sandra Date: Thu Nov 8 22:02:38 2018 New Revision: 265939 URL: https://gcc.gnu.org/viewcvs?rev=265939&root=gcc&view=rev Log: 2018-11-08 Sandra Loosemore PR other/36572 gcc/ * doc/invoke.texi (Optimize Options): Clarify default behavior for -fno-sched-interblock and -fno-sched-spec. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug other/36572] Documentation for some options starting with “no-” not clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36572 sandra at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from sandra at gcc dot gnu.org --- Fixed (finally) on trunk.
[Bug driver/41179] Documentation for "-fno-toplevel-reorder" is confusing (and wrong)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41179 --- Comment #4 from sandra at gcc dot gnu.org --- Author: sandra Date: Fri Nov 9 20:45:06 2018 New Revision: 265993 URL: https://gcc.gnu.org/viewcvs?rev=265993&root=gcc&view=rev Log: 2018-11-09 Sandra Loosemore PR driver/41179 PR middle-end/65703 gcc/ * doc/invoke.texi (Optimize Options): Clarify default behavior for -fno-toplevel-reorder, -fno-defer-pop, and -fno-branch-count-reg. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug middle-end/65703] -fdefer-pop documentation is confusing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65703 --- Comment #3 from sandra at gcc dot gnu.org --- Author: sandra Date: Fri Nov 9 20:45:06 2018 New Revision: 265993 URL: https://gcc.gnu.org/viewcvs?rev=265993&root=gcc&view=rev Log: 2018-11-09 Sandra Loosemore PR driver/41179 PR middle-end/65703 gcc/ * doc/invoke.texi (Optimize Options): Clarify default behavior for -fno-toplevel-reorder, -fno-defer-pop, and -fno-branch-count-reg. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug middle-end/65703] -fdefer-pop documentation is confusing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65703 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #4 from sandra at gcc dot gnu.org --- I've fixed the problem with the wording of the -fno-defer-pop documentation. The other problem raised in this issue was the difficulty in locating documentation for the positive form -fdefer-pop. I'm going to address this in general by adding an @opindex entry for the positive form of all "no-" options so searching the document will at least turn up a hit in the index that will get you to the right place.
[Bug driver/41179] Documentation for "-fno-toplevel-reorder" is confusing (and wrong)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41179 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from sandra at gcc dot gnu.org --- Fixed on trunk, at least for the 3 cases explicitly mentioned in this issue.
[Bug middle-end/65703] -fdefer-pop documentation is confusing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65703 --- Comment #5 from sandra at gcc dot gnu.org --- Author: sandra Date: Sun Nov 11 01:33:53 2018 New Revision: 266008 URL: https://gcc.gnu.org/viewcvs?rev=266008&root=gcc&view=rev Log: 2018-11-10 Sandra Loosemore PR middle-end/65703 gcc/ * doc/invoke.texi (Optimize Options): Add @opindex entries for the positive forms of -fno-xxx and -mno-xxx options that were lacking them. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug middle-end/65703] -fdefer-pop documentation is confusing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65703 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from sandra at gcc dot gnu.org --- Now fixed on trunk.
[Bug c/26366] __builtin_expect needs better documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26366 --- Comment #6 from sandra at gcc dot gnu.org --- Author: sandra Date: Sun Nov 11 18:39:10 2018 New Revision: 266017 URL: https://gcc.gnu.org/viewcvs?rev=266017&root=gcc&view=rev Log: 2018-11-11 Sandra Loosemore PR c/26366 gcc/ * doc/extend.texi (Other Builtins): Document probability associated with __builtin_expect. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi
[Bug c/26366] __builtin_expect needs better documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26366 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from sandra at gcc dot gnu.org --- Fixed (finally) on trunk.
[Bug other/38768] -fschedule-insns documentation is wrong for x86 and some other targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38768 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #9 from sandra at gcc dot gnu.org --- It appears that the problems with -fschedule-insns on x86 were fixed in gcc 4.5 or thereabouts. The documentation on trunk agrees with what opts.c says about when this option is enabled, so nothing left to do here.
[Bug c++/43105] Document restrictions on mixing -fno-rtti and -frtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43105 --- Comment #6 from sandra at gcc dot gnu.org --- Author: sandra Date: Sun Nov 11 22:46:00 2018 New Revision: 266020 URL: https://gcc.gnu.org/viewcvs?rev=266020&root=gcc&view=rev Log: 2018-11-11 Sandra Loosemore PR c++/43105 gcc/ * doc/invoke.texi (C++ Dialect Options): Add warning about mixing -frtti and -fno-rtti code. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug c++/43105] Document restrictions on mixing -fno-rtti and -frtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43105 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from sandra at gcc dot gnu.org --- Fixed on trunk.
[Bug web/79738] Documentation for __attribute__((const)) slightly misleading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79738 sandra at gcc dot gnu.org changed: What|Removed |Added CC||msebor at gcc dot gnu.org, ||sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- The documentation for both "const" and "pure" was rewritten somewhat in r255469 (along with some much bigger changes to the attribute handling code to detect conflicts); now both places refer to "reading global variables" in discussing the differences between the two attributes. I think the semantics of the attributes have not changed and the suggested language is still good, correct?
[Bug c/61588] Optimization defaults are not what documentation say they should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61588 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from sandra at gcc dot gnu.org --- This bug is basically a duplicate of PR 87929, which was recently fixed on trunk. I believe the current documentation is correct, so I'm marking this one fixed as well.
[Bug c/69502] attribute aligned reduces alignment contrary to documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69502 --- Comment #3 from sandra at gcc dot gnu.org --- Author: sandra Date: Mon Nov 12 06:23:16 2018 New Revision: 266025 URL: https://gcc.gnu.org/viewcvs?rev=266025&root=gcc&view=rev Log: 2018-11-11 Sandra Loosemore PR c/69502 gcc/ * doc/extend.texi (Common Type Attributes): For the align type attribute, copy language about decreasing alignment from the corresponding variable attribute. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi
[Bug c/69502] attribute aligned reduces alignment contrary to documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69502 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from sandra at gcc dot gnu.org --- Fixed on trunk.
