[Bug c/82063] issues with arguments enabled by -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82063 --- Comment #2 from jim.wilson at linaro dot org --- On Thu, Aug 31, 2017 at 1:32 PM, manu at gcc dot gnu.org <gcc-bugzi...@gcc.gnu.org> wrote: > This is already possible: > https://gcc.gnu.org/onlinedocs/gccint/Option-properties.html > > LangEnabledBy(language, opt) > LangEnabledBy(language, opt, posarg, negarg) > ... > > See examples in c.opt. I did already look at examples, and read the docs, and step through code in the debugger. Posarg and negarg are integers, which are ignored for options that take a string as an argument. So no, this doesn't work. Note in optc-gen.awk, where the handle_generated_option call is generated, the fourth argument is always NULL. This is "const char *arg" which is the argument for options that take string arguments. The fifth argument, int value, is where the posarg/negarg value gets passed. Also, note, in the file opts-common.c, in the function set_options, in the case CLVC_STRING, it uses only arg, it does not use value. Since the posarg/negarg values end up in value here, they are ignored, and are useless. I would rather ask why the -Walloc-size-larger-than= option is (unsuccessfully) being enabled by -Wall. It seems an odd one to try to enable by default. Another weirdness I just noticed, the docs say that a size suffix is optional, but in the function alloc_max_size in calls.c, if no suffix is specified, it does unit = 0; ... w *= unit; which means the argument always gets ignored unless there is a size suffix. I think that should be unit = 1; instead.
[Bug rtl-optimization/81434] AArch64 instruction fusing and pipeline scheduling problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81434 --- Comment #7 from jim.wilson at linaro dot org --- On Thu, Jul 20, 2017 at 4:20 AM, wilco at gcc dot gnu.org <gcc-bugzi...@gcc.gnu.org> wrote: > Do you think it might be feasible to update resource usage of a schedule > group? > Or would it be easier to replace a fused pair with a single instruction with > correct resource usage, and expand after scheduling in say split5? > > For some cases (single destination reg like ADRP/ADD, AES, MOV/MOVK) it would > be simpler to treat them as a single instruction from early on. I haven't looked at this issue yet. This problem wastes one issue slot per cycle, where as the SCHED_GROUP problem wastes up to N-1 issue slots per cycle, where N is the issue rate. For falkor, this is up to 3 issue slots per cycle. Since the SCHED_GROUP problem is more serious, I looked at that one first. Thinking about this a bit, I don't know if there is an easy way to correct resource usage for a fused pair if represented as two insns. If we represent a fused pair as a single instruction, then we are getting the issue count wrong, as they take two issue slots, but one function unit slot. However, there is a way to deal with the issue count. We could use TARGET_SCHED_VARIABLE_ISSUE to make the single fused insn take two issue slots. I already wrote a patch like that for a different reason as an experiment so I know this can work. We may also have to worry about instruction lengths, depending on when exactly we split the fused insn into two insns. There could be some other details that turn up when we try to implement this. What do we do if a fused insn takes the last issue slot for instance? Maybe we try to prevent that, or maybe we reduce the issue rate by one for the next cycle. This may depend on how the hardware implements insn fusing.
[Bug rtl-optimization/81434] AArch64 instruction fusing and pipeline scheduling problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81434 --- Comment #5 from jim.wilson at linaro dot org --- On Wed, Jul 19, 2017 at 4:25 AM, wilco at gcc dot gnu.org <gcc-bugzi...@gcc.gnu.org> wrote: > To more accurately schedule fusion pairs wouldn't we need to specify the > scheduling behaviour of the group as well? From the dumps below it schedules > the adrp/add in the same cycle if we're lucky, but it is modelled as using 2 > ALUs rather than a new single fused instruction. The fusion pair takes two issue slots and uses one alu, but is modeled as taking two issues slots and using two alus. I haven't tried to address this problem. I'm just trying to get the issue slot handling correct for now, so that they can issue in the same cycle. > Also is your change fixing the issue that the scheduler cannot schedule 2 > instructions with a zero latency dependency between them in the same cycle? > That's a very similar bug. The scheduler can schedule 2 insns w/ zero latency dependency in the same cycle. However, it does not do so when a SCHED_GROUP is involved. This is the bug that my patch fixes. Jim
[Bug bootstrap/66319] [6 Regression] gcov-tool.c:84:65: error: invalid conversion from 'int (*)(const c har*, const stat*, int, FTW*)' to 'int (*)(const char*, const stat*, int, FTW)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66319 --- Comment #18 from jim.wilson at linaro dot org --- On 07/12/2016 09:36 AM, bugzilla-gcc at thewrittenword dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66319 > > --- Comment #16 from The Written Word com> --- > (In reply to John David Anglin from comment #15) >> Steve Ellcey used to support HP-UX/IA64 but he moved on to MIPS. Don't >> know Jim Wilson's status. I've never had access to HP-UX/IA64. I've only used ia64-linux. I no longer have an IA-64 machine at home. I don't have access to IA-64 at work, and there is no IA-64 hardware in the gcc compile farm. I retain a lot of knowledge about how IA-64 works, but with no hardware access, and no HP-UX access, there isn't much I can do to help. Jim
[Bug driver/66849] Incorrect multilib chosen with -mthumb -mfloat-abi=hard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66849 --- Comment #6 from jim.wilson at linaro dot org --- On Tue, Aug 4, 2015 at 6:39 AM, simon at pushface dot org gcc-bugzi...@gcc.gnu.org wrote: The t-aprofile that Ramana mentioned does support thumb/hard multilibs, but makes this work by requiring armv7 or higher. Wouldn’t I need a t-mprofile? Perhaps. I'm relatively new to arm, and not sure about the differences between the a-profile and m-profile. Jim
[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932 --- Comment #16 from jim.wilson at linaro dot org --- On Tue, Jun 16, 2015 at 8:03 AM, christian.eggers at kathrein dot de gcc-bugzi...@gcc.gnu.org wrote: Shall I also test the other patch? The out-of-ssa patch is unfinished, and won't work without more changes. Jim
[Bug target/66258] compiling a stdarg function with arch +nofp generates an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66258 --- Comment #7 from jim.wilson at linaro dot org --- On Sat, Jun 6, 2015 at 2:02 AM, pinskia at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: Do you plan to backport this to gcc-5-branch? I didn't realize it was broken on the gcc-5 release branch. I only checked mainline. I can check the gcc-5 release branch and backport, but I'm a little out of touch, and not sure what approval I need for the backport. If I can't backport to the FSF gcc-5 release branch for some reason, I can backport to the linaro gcc-5 branch instead. I've also discovered that I got a little bad info on grub. The person who tried -mgeneral-regs-only accidentally compiled linux user space with that option, which is why the build with it failed. Grub itself apparently doesn't use FP. So with correct makefiles, changing grub to use -mgeneral-regs-only instead of +nofp does solve the problem. Since the linux kernel already uses -mgeneral-regs-only, and this option is (presumably) not broken in gcc-5, I believe that grub will be changed to use -mgeneral-regs-only to match the kernel, in which case a build will work with gcc-5. There is still the problem that grub versions before the change was made (this week? last week?) will still fail with gcc-5 unless the patch is backported, or users make local mods to grub to use -mgeneral-regs-only instead of +nofp. Jim
