[Bug gas/30856] Regression: operand size mismatch for `push'
https://sourceware.org/bugzilla/show_bug.cgi?id=30856 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- (In reply to Antoni Boucher from comment #0) Hi Antoni, > Reproducer for the bug Please could you upload the assembler output from the compiler ? It is likely that this bug is dependent upon the version of the compiler that is being used, so in order to reproduce and investigate the problem we really need the assembler output, rather than the C source file. It may also be that this problem is actually a bug in the compiler which was not being caught by the 2.40 assembler, but which is now detected by the 2.41 assembler. Hence having access to the assembler source file should allow us to find out if this is true. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30857] Use of uninitialized memory
https://sourceware.org/bugzilla/show_bug.cgi?id=30857 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Hi Jacob, Thanks for the bug report. > HOW TO FIX: > 1) Intead of calling XNEW call XCNEW that calls calloc instead of malloc. > This will ensure that the inequality will fail. I have checked in this suggested solution. > What is the point then of telling me to « go to bugzilla » ??? > I just do not understand this group really. The purpose is that it allows to keep track of bugs individually. This bug was a simple one and so will probably not involve a lot of discussion or trial and error whilst fixing, but this is not true of all bugs. Some take a long time to fix, and some are fixed and then later on reappear. Having a specific bug report to gather together all comments, patches and reproducers regarding a single problem makes things a lot easier to track and resolve. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30860] Possible usage of NULL in GAS
https://sourceware.org/bugzilla/show_bug.cgi?id=30860
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #2 from Nick Clifton ---
(In reply to jacob from comment #1)
>
>know(fragP->fr_next); // Not active if NDEBUG is defined
>after = fragP->fr_next->fr_address + stretch;
> We know that fragP->fr_next CAN BE NULL, since the controlling condition of
> this loop (the switch is inside a loop) is:
> for (fragP = segment_frag_root; fragP; fragP = fragP->fr_next) {
>
> So, we RELY on fr_next being NULL to stop the loop. But we do not test for
> this condition before using it here. As you know the "know" construct is
> NOT active if NDEBUG is active.
> PRPOSED FIX:
> Replace "know" by "gas_assert"
Actually this is wrong. The point of compiling with NDEBUG active
is that sanity checks like the one above are removed making the code
(theoretically) faster. Anyone using programs compiled with NDEBUG
must take on the risk that the program will fail in an unhelpful way
if the input is not as expected.
So replacing know() with gas_assert() will remove the benefit of
compiling with NDEBUG. Of course this leads to the question - why
have a gas_assert() function at all, why not just use know() all
the time ? The answer is partially programmer preference and
partially assumption of risk. If the programmer is sure that a
failing a particular test can only happen if something else is wrong
elsewhere in the code, eg a rs_org fragment not being followed by
another fragment, then using know() makes sense. If the test fails
then there is a bug elsewhere and this code is not at fault. So it
should be safe to remove the test when compiling with NDEBUG - using
NDEBUG implies that the user is happy with the code's behaviour and
does not want extra tests.
If on the other hand, the programmer knows that an issue can arise
because of input over which the code has no control - eg the assembler
source input file - and there is no easy way to report this error back
to the user, then using gas_assert() makes sense. The code cannot
continue and cannot go back, so halting with an error message is the
only option.
Having said all of that, there probably are places in the current code
where it would be better to use gas_assert() instead of know() and
places where it would be better to report an error back to the function
caller rather than halting. It is just that, in my opinion, write.c:3014
is not one of them.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/30856] Regression: operand size mismatch for `push'
https://sourceware.org/bugzilla/show_bug.cgi?id=30856 --- Comment #2 from Antoni Boucher --- Created attachment 15113 --> https://sourceware.org/bugzilla/attachment.cgi?id=15113&action=edit ASM reproducer for the bug Here it is. You simply need to run GNU as on this file to trigger the error. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30865] ld: =fillexp different behaviors for hexidecimal literal
https://sourceware.org/bugzilla/show_bug.cgi?id=30865 Nick Clifton changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nickc at redhat dot com CC||nickc at redhat dot com Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30824] BFD (GNU Binutils) 2.41 internal error, aborting at elf64-ppc.c:17531 in ppc64_elf_relocate_section
https://sourceware.org/bugzilla/show_bug.cgi?id=30824 Sam James changed: What|Removed |Added CC||sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30865] ld: =fillexp different behaviors for hexidecimal literal
https://sourceware.org/bugzilla/show_bug.cgi?id=30865
--- Comment #1 from Nick Clifton ---
(In reply to Fangrui Song from comment #0)
> A side effect possibly from this commit is that 0x literals have different
> behaviors from decimal literals and expressions.
>
> .text : { *(.text) } =0x90# set the fill pattern to 0x90909090
> .text : { *(.text) } =0x90909090 # set the fill pattern to 0x90909090
> .text : { *(.text) } =144 # set the fill pattern to 0x0090
> .text : { *(.text) } =0x90+0 # set the fill pattern to 0x0090
>
> This has been the case for ~20 years, so probably not worth changing,
Agreed.
> but I
> felt obliged to point out this special behavior to warn users about 0x90
> 0x9090 0x909090 that are shorter than 4 bytes.
So a documentation update is needed.
In the course of investigating this I also discovered that the difference
only applies to simple hexadecimal values specified with a 0x prefix. It
does not apply to expressions involving hex numbers, eg 0x1 + 0x2, nor to
hex values specified via a $ prefix, eg $9a, nor to hex values specified
by a letter suffix, eg 9aH, nor to hex values specified with a magnitude,
eg 0x9aK
Anyway please take a look at the uploaded patch which updates the
documentation and adds a new test case to make sure that the documented
behaviour continues.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30865] ld: =fillexp different behaviors for hexidecimal literal
https://sourceware.org/bugzilla/show_bug.cgi?id=30865 --- Comment #2 from Nick Clifton --- Created attachment 15114 --> https://sourceware.org/bugzilla/attachment.cgi?id=15114&action=edit Proposed patch -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30865] ld: =fillexp different behaviors for hexidecimal literal
https://sourceware.org/bugzilla/show_bug.cgi?id=30865 Nick Clifton changed: What|Removed |Added Attachment #15114|0 |1 is obsolete|| --- Comment #4 from Nick Clifton --- Created attachment 15115 --> https://sourceware.org/bugzilla/attachment.cgi?id=15115&action=edit Proposed patch -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30865] ld: =fillexp different behaviors for hexidecimal literal
https://sourceware.org/bugzilla/show_bug.cgi?id=30865 --- Comment #3 from Nick Clifton --- It is always the way - you post a patch and then immediately realise that you have forgotten something. In this case my patch updates the description of the FILL directive in the linker documentation, but it does not update the = expression description. So here is a revised patch that does just that. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/30867] New: merge.cc:668:27: error: ‘char16_t’ was not declared in this scope
https://sourceware.org/bugzilla/show_bug.cgi?id=30867 Bug ID: 30867 Summary: merge.cc:668:27: error: ‘char16_t’ was not declared in this scope Product: binutils Version: 2.42 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: vvinayag at arm dot com CC: ian at airs dot com Target Milestone: --- When building cross toolchains (for targets: aarch64_none_linux_gnu, arm_none_linux_gnueabi) using gcc 4.8.5, the following errors are seen: /…/src/binutils-gdb/gold/merge.cc:668:27: error: ‘char16_t’ was not declared in this scope class Output_merge_string; ^ /…/src/binutils-gdb/gold/merge.cc:668:35: error: template argument 1 is invalid class Output_merge_string; ^ /…/src/binutils-gdb/gold/merge.cc:671:27: error: ‘char32_t’ was not declared in this scope class Output_merge_string; ^ /…/src/binutils-gdb/gold/merge.cc:671:35: error: template argument 1 is invalid class Output_merge_string; ^ This looks related to the patch "gold: Use char16_t, char32_t instead of uint16_t, uint32_t as character types", so I have mentioned it here too: https://sourceware.org/pipermail/binutils/2023-September/129446.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/30867] merge.cc:668:27: error: ‘char16_t’ was not declared in this scope
https://sourceware.org/bugzilla/show_bug.cgi?id=30867 vvinayag at arm dot com changed: What|Removed |Added Target||aarch64-none-linux-gnu, ||arm-none-linux-gnueabihf -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/30867] merge.cc:668:27: error: ‘char16_t’ was not declared in this scope
https://sourceware.org/bugzilla/show_bug.cgi?id=30867 vvinayag at arm dot com changed: What|Removed |Added Host||x86_64-Linux -- You are receiving this mail because: You are on the CC list for the bug.
