Public bug reported:
If I compile the attached file with -O3, gcc produces an empty function
(simply returns 0). If I compile without -O3, gcc produces viable code
that functions as expected.
Linux outhouse 5.4.0-58-generic #64-Ubuntu SMP Wed Dec 9 08:16:25 UTC
2020 x86_64 x86_64 x86_64 GNU/Linux
** Attachment added: "Additional (header) file needed to compile."
https://bugs.launchpad.net/ubuntu/+bug/1909838/+attachment/5448651/+files/cpmutl.h
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1
** Package changed: ubuntu => gcc-9 (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1909838
Title:
gcc -O3 produces invalid code
To manage notifications about this bug go to:
https://bugs.la
On a hunch, I added "volatile" to the declarations of the function
parameters:
int match_fcb(volatile struct cpmfcb *mask, volatile struct cpmfcb *fcb)
This caused code to be generated, and it looks viable. It's still
unclear to me why this code was being optimized away.
--
You received this bu
I see that gcc-7 also has the same issue. I'm starting to wonder if this
code is flawed, but I don't see the problem. I would have thought "-O3"
is pretty safe and sane. I could imagine -O5 doing something like this.
--
You received this bug notification because you are a member of Ubuntu
Bugs, w
Here's the latest code example, eliminating the need for the cpmutl.h
header file
** Attachment added: "stand-alone match_fcb.c example"
https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1909838/+attachment/5448725/+files/match_fcb.c
--
You received this bug notification because you are a
I've discovered that "-Og" does produce working, somewhat-optimized,
code. Still, I need to understand why this code was appearing to the
optimizer as a no-op. I need to make sure that no other code is being
incorrectly optimized. As it stands, this looks to me to be erroneous
optimization by GCC.
Turns out, this is due to the programmer's assumption that fcb->name[8]
and fcb->ext[3] can be accessed contiguously by fcb->name[0..10]. So,
the code is actually "lazy", if not bad. Obviously, this has worked in C
for a long time but no longer can be depended on.
** Changed in: gcc-9 (Ubuntu)
Public bug reported:
The example program creates a JLabel with text set to "". On previous versions of the
openjdk-8-jre, this would work and the PNG was displayed in the JLabel.
On the current version, 8u212-b03-0ubuntu1.18.04.1, all that is rendered
is a tiny label with no apparent image inside.
The results screenshot test-java1.8.0_212.png shows how it fails to
render the image. test-java1.8.0_162.png shows success on the original
18.04 version of the JRE. Note, in all cases if I specify an image file
that does not exist, all version properly render a JLabel of appropriate
size. So, it wo
This looks a lot like the problem in LP #1662673, but that fix is
supposed to be in kernel 4.4.0-65-generic. Might be worth confirming
though. Or perhaps confirming that the fix actually works on the Z
architecture (depends on how the architecture/compiler handles 'bool').
--
You received this bu
I'm confused about the release mechanics, I guess. Looking at the git
repository, I see tag "Ubuntu-4.4.0-65.86" (for example) and that tag
commit does contain the fix. Is it then possible for a kernel labeled
"4.4.0-65-generic #86" to NOT contain that patch? Am I making a gross
assumption that the
Carsten, I am currently thinking there are two possibilities here.
Maybe three.
1) The fix I submitted is not in the kernel(s) you are running.
2) The s390 compiler does not produce the necessary code to implicitly convert
long int to bool.
3) You are hitting a different bug that just happens to
The corresponding bug for this issue has been closed as unreproducible.
Unclear why that was not communicated here. This launchpad can also be
closed.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1566
Public bug reported:
This began as question #76. I've observed odd behavior in vim since
my upgrade from 18.04 to 20.04. One in particular is when I use the "r"
command to replace a single character, shifted letters fail to work
correctly and vim sputters and changes the case of letters in the
I cloned the vim github repo and did a default build (version 8.2.4014),
that version of vim does not exhibit any of this odd behavior. Seems
likely that either something has fixed this upstream or else Ubuntu
20.04 vim build enables some feature that causes this.
--
You received this bug notific
Examining the raw I/O between this new vim and my xterm, I see that the
'r' command is now turning off modifyOtherKeys (and then back on after
the replacement character is typed). So, it would appear that there is a
fix to this upstream, and Ubuntu vim is just lacking that fix.
As far as use of ^V
What version of vim is planned for 22.04? Will these fixes be included?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1956062
Title:
vim mis-manages modifyOtherKeys on xterms
To manage notification
18 matches
Mail list logo
