[Bug c/34803] wrong code for dereferencing type-punned pointer
--- Comment #6 from gin at mo dot msk dot ru 2008-01-18 16:21 --- Subject: Re: wrong code for dereferencing type-punned pointer looks good for 4.2. Can we see (assembler) output of that 4.2, with those same `-fno-strict-aliasing -O3 -fno-strict-aliasing' optimization options, for the same preprocessed input as posted in the initial bug description, http://gcc.gnu.org/bugzilla/attachment.cgi?id=14944action=view? Was that some recent snapshot from 4.2 version control branch, or what is the version? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34803
[Bug c/34803] wrong code for dereferencing type-punned pointer
--- Comment #5 from gin at mo dot msk dot ru 2008-01-17 17:45 --- Subject: test case [Re: wrong code for dereferencing type-punned pointer] No test case program hitting this wrong code will do something reliably: the code incorrectness is passing uninitialized value to the rest of program, so it can no longer `abort ()' or do something else depending on this value deterministically, reliably. One can only talk only about doing so with some reasonable probability. At least one such program already exist. Remember, the input was built after code in actual application. It was xemacs. More precisely, built recent stable version as taken from location in (mirror) list in http://www.xemacs.org/Releases/index.html#Stable-Download. Its `print.c' `std_handle_out_va' code for passing `extptr' to `std_handle_out_external' gets compiled wrong exactly as described, that is, passes uninitialized value that is generally invalid pointer, and most likely is other than what is passed as arg 1 to `memcpy' call earlier in `std_handle_out_va'. Exactly before `callq [EMAIL PROTECTED]' instruction the value is in `$rdi', exactly before `callq std_handle_out_external' it is in `$rdx'. They should be the same, but they are not. Had the wrong code executed as follows. Started it in debugger. Stopped exactly before `initial_command_loop' call in `main_1' in `emacs.c'. Called `stderr_out (\n)' in debugger. (When actually debugging the program, it happens in course of `ldp' command defined by `.gdbinit' file created in build directory during build.) Program would receive `SIGSEGV' in backtrace: std_handle_out_external std_handle_out_va stderr_out Simpler program to link with preprocessed code initially posted, work in batch mode, clearly complain that the wrong code is hit in most cases when hits? Will write such - in my copious free time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34803
[Bug c/34803] New: wrong code for dereferencing type-punned pointer
No simpler C code is (yet) known to hit this. On request will describe actual package where similar code occurs. In the attached preprocessed code, incorrect arg 3, `%rdx', is passed to `handle_out_external'. Code expects this value, `extlen', to be the same as value that is returned from `__builtin_alloca', stored in `c', passed to `memcpy' as arg 1. It is not. Instead, the following assembler code is output. movq%rbx, %rdi callmemcpy movq-72(%rbp), %rcx movq-40(%rbp), %rdx movq%rbx, -40(%rbp) It passes in `%rbx' uninitialized value that was in `-40(%rbp)' and only then writes into `-40(%rbp)' the correct value to pass. Observing when compiling not only `-O3', but even `-fno-strict-aliasing -O3 -fno-strict-aliasing'. In these 2 invocations assembler output is the same. That is, `-fno-strict-aliasing' no longer disables optimizations that require strict aliasing rules in code. It, however, disables warnings output when `-Wstrict-aliasing=2' is specified. -- Summary: wrong code for dereferencing type-punned pointer Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gin at mo dot msk dot ru GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34803
[Bug c/34803] wrong code for dereferencing type-punned pointer
--- Comment #1 from gin at mo dot msk dot ru 2008-01-15 21:41 --- Created an attachment (id=14944) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14944action=view) preprocessed code in question Instead of `extptr', uninitialized value is passed to `handle_out_external'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34803
[Bug c/34803] wrong code for dereferencing type-punned pointer
--- Comment #3 from gin at mo dot msk dot ru 2008-01-16 00:49 --- Subject: Re: wrong code for dereferencing type-punned pointer obviously violating c aliasing rules here. Certainly. Was quite explicit about that: That is, `-fno-strict-aliasing' no longer disables optimizations that require strict aliasing rules in code. To reproduce compiler (still) doing such an optimizations (and breaking code), one has to violate aliasing rules. Also confirming that one may factor these separate issues in the report. . Compiler ignores `-fno-strict-aliasing'. Expecting that can violate aliasing rules, and tell compiler to allow that, by passing this option. The expectation is based on both option documentation and earlier gcc versions actually doing so. . Warning not issued, even when compiler does optimizations that require code to conform to c strictest aliasing rules. On request will confine this bug database entry to one of them, and post another issue as separate bug database entry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34803
[Bug bootstrap/28472] -B$(build_tooldir)/bin/
--- Comment #8 from gin at mo dot msk dot ru 2007-01-13 01:15 --- Subject: Re: -B$(build_tooldir)/bin/ Wrote on Fri, 29 Dec 2006 17:35:39 +0300: will try it for 3.0.3 Did so. `--with-ld=/bin/ld --without-gnu-ld' it did link programs properly even if `$(build_tooldir)/bin/ld' was present and broken and even if passed `-B$(build_tooldir)/bin/'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28472
[Bug bootstrap/28472] -B$(build_tooldir)/bin/
--- Comment #7 from gin at mo dot msk dot ru 2006-12-29 14:35 ---
Subject: Re: -B$(build_tooldir)/bin/
Can you give the output of the original confgure which should show you which
ld/as GCC is going to use?
No. Version 4 just does not build on that system at all (or this
requires essentially reimplementing the support of the system in gcc).
So the question must be about the same older one that I already wrote
about. It does not report that - unlike 4.0.2, 4.1.1.
That is, in it `gcc/config.log' says nothing about that. Re- ran
`gcc/configure' with the same options as `config.status --r' would do
(created another directory for that). Neither it said anything about
that. It would not even report is the linker it found gnu one or not.
By default the toplevel configure looks into PREFIX/${TARGET} for ld/as.
Looks like `xgcc' of old version actually does that. Even without
that `-B' option, but with `ld' in that directory existing, it
outputs:
PREFIX/lib/gcc-lib/i586-pc-sco3.2v5.0.4/3.0.3/../../../../i586-pc-sco3.2v5.0.4/bin/ld:
unrecognized option '-YP,/usr/ccs/lib:/lib:/usr/lib'
PREFIX/lib/gcc-lib/i586-pc-sco3.2v5.0.4/3.0.3/../../../../i586-pc-sco3.2v5.0.4/bin/ld:
use the --help option for usage information
collect2: ld returned 1 exit status
That is, looked for `ld' in in directory based on its own installation
one. This is equivalent of `-B$(build_tooldir)/bin/', and does
exactly the same harm.
The worst is that could not have foreseen that by documentation. This
directory was even missing in standard rules in `--with-as'
description in that version of `gcc/doc/install.texi'. That file
would mention only
@[EMAIL PROTECTED]/lib/gcc-lib/@var{target}/@var{version}} and
operating system specific directories.
use --with-ld/--with-as.
It is a workaround at best (will try it for 3.0.3). Programs
installed even in the same PREFIX are not necessarily intended for
gcc. Certainly options passed to program must match the type of
program configuration chose. The very use of gnu ld on non- gnu
system when neither `--with-ld' nor `--with-gnu-ld' are specified is
at least suspicious and should issue warning.
The lack of a standard way to figure which `as', `ld' are used is also
bug, and already fixed in 4.
No, I still say you are incorrect.
Thus partly agree with that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28472
[Bug bootstrap/28472] -B$(build_tooldir)/bin/
--- Comment #5 from gin at mo dot msk dot ru 2006-12-28 13:32 --- Subject: Re: -B$(build_tooldir)/bin/ It actually broke build of gcc (version 3.0.3) at least on one class of systems, i386-pc-sco3.2v5, as follows. Had on that system gnu binutils installed with PREFIX. Had gcc configured with to install with the same PREFIX. Configured it --without-included-gettext --prefix=PREFIX --with-as=PREFIX/bin/gas --enable-multilib --disable-static --enable-shared (Native `as' was broken in many ways, so GNU one was indeed strongly preferred. OTOH, not specifying `--with-ld', so that native is used `ld', was essential: one from binutils, at least as of 2.11.2, would output elf binaries that system dynamic linker would not link.) make bootstrap would fail as follows. stage1/xgcc -Bstage1/ -BPREFIX/i586-pc-sco3.2v5.0.4/bin/ -DIN_GCC-g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -DGENERATOR_FILE -o gengenrtl \ gengenrtl.o ` case obstack.o in ?*) echo obstack.o ;; esac ` ` case alloca.o in ?*) echo alloca.o ;; esac ` ` case in ?*) echo ;; esac ` ` case in ?*) echo ;; esac ` ` case in ?*) echo ;; esac ` ` case in ?*) echo ;; esac ` PREFIX/i586-pc-sco3.2v5.0.4/bin/ld: unrecognized option '-YP,/usr/ccs/lib:/lib:/usr/lib' PREFIX/i586-pc-sco3.2v5.0.4/bin/ld: use the --help option for usage information collect2: ld returned 1 exit status gmake[2]: *** [gengenrtl] Error 1 The `-YP' exists in native `ld', but not in GNU one. That is, gcc correctly configured itself to use to `ld' options for native one. It is exactly `-B$(build_tooldir)/bin/' that expands to `-BPREFIX/i586-pc-sco3.2v5.0.4/bin/' so that gcc finds and invokes GNU `ld' instead of native one. Moving `PREFIX/i586-pc-sco3.2v5.0.4/bin/' directory works around that. If the bug was not already reopened, would do that now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28472
[Bug other/29700] check requires autogen
--- Comment #6 from gin at mo dot msk dot ru 2006-11-06 17:24 --- Subject: Re: check requires autogen `make' performing all tests is not enough to test successfully. The test failures normally result in make error, ignored by `-k' or not. One looks for such error messages in `make' output. Having to sieve out other sorts of errors, those caused by missing `autogen', at least complicates use of tests and automating it in particular. This is why considering `-k' workaround unacceptable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29700
[Bug other/29700] check requires autogen
--- Comment #2 from gin at mo dot msk dot ru 2006-11-03 19:43 --- Subject: Re: check requires autogen Certainly ran `make check' in top level build directory, and indicated that by including parts of `make -w' output, printout of directories entered and left by `make'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29700
[Bug other/29700] check requires autogen
--- Comment #4 from gin at mo dot msk dot ru 2006-11-03 20:03 --- Subject: Re: check requires autogen Sorry for not indicating that. Always specified `-k' in all `make' runs. They yield the results as described. The gist is that currently the only way to obtain actual test script, `check.sh', is running `autogen'. Being unable to make tests in some subdirectories for that reason certainly may be worked around with `-k', and that is not a fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29700
[Bug bootstrap/29620] can not build libgcc.a on stage 1
--- Comment #3 from gin at mo dot msk dot ru 2006-10-31 19:17 --- Subject: Re: can not build libgcc.a on stage 1 Obsoleting sparc-sun-solaris2.5, if ever occurred for 4.1 branch, is certainly not noted in neither `NEWS' nor `INSTALL/specific.html' of 4.1.1 release. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29620
[Bug other/29622] broken anchor name in html
--- Comment #2 from gin at mo dot msk dot ru 2006-10-27 20:18 --- Subject: Re: broken anchor name in html Confirming that anchor names are consistent in http://gcc.gnu.org/install/specific.html Hope that the updated version will get in next gcc release. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29622
[Bug bootstrap/28472] -B$(build_tooldir)/bin/
--- Comment #3 from gin at mo dot msk dot ru 2006-09-04 19:32 --- Subject: Re: -B$(build_tooldir)/bin/ Why do you think this wrong? -B. is suppied first so this is not a bug If during build all files are found through `-B./' (or other specification of part of build tree containing files that are already built), then `-B$(build_tooldir)/bin/' is not needed at all. Otherwise, build process uses some external software that must be installed before build. Where it is installed has nothing to do with gcc build configuration and installation tree conventions. We have to configure arbitrary directories / compiler options for this. With `Makefile.in' as it is currently one can not do that. It sets this external software option unconditionally to point to `$(exec_prefix)/$(target_noncanonical)/bin' directory - with variables from build configuration of gcc, not of that external software. It will break build if the external software to use is actually installed elsewhere, and software in `$(build_tooldir)/bin/' also exists, but behaves in a quite different way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28472
[Bug bootstrap/28472] -B$(build_tooldir)/bin/
--- Comment #4 from gin at mo dot msk dot ru 2006-09-04 20:02 --- A question was sent to original reporter: Why do you think this wrong? If it was needed at all, the actions on the bug could have depended on the answer, and whether it should be closed could be decided only after receiving the answer. Instead, it was closed *along* with sending question. The answer alone, now that it is posted, whatever it is, is sufficient new information on bug. -- gin at mo dot msk dot ru changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28472
[Bug bootstrap/28469] stage2 error: toplev.c redefines floor_log2
--- Comment #3 from gin at mo dot msk dot ru 2006-07-24 19:52 --- Subject: Re: stage2 error: toplev.c redefines floor_log2 On other system where that translation module compiles normally there are also 2 definitions of the same function, but even function type declarations in definitions are quite different. This certainly may have something to do with system headers. Have to suspect this, despite both conflicting function definitions gcc complains about are in gcc own code. If it so widely known to be caused by broken with kernel headers, that a description of these headers bug is published, please post a pointer to that description. There may be a patch that can easily be applied without rebuilding and reinstalling the full core system packages. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28469
[Bug debug/28099] loses type in debug info
--- Comment #2 from gin at mo dot msk dot ru 2006-06-23 19:57 --- Subject: Re: loses type in debug info As for marking the bug as already reported, this seems plausible to me. Confirming that `.i' sent in my bug report uses lost type in exactly the same way as test code in PR 21391; moreover, the entire program including that `.i' appears to use it exactly the same way. Unfortunately, checking for that would mean vgrep in bug database, which could not possibly do. So did violate http://gcc.gnu.org/bugs.html wrt duplicate bug reports, and most likely will do that again. After all, nobody makes slightest fuss about that, and before doing it, he should ensure that bug database is easily vgrep'able, that is, fairly small :-/. pinskia at gcc dot gnu dot org writes: Next time please don't paste the preprocessed source in gccbug or in the comments section in bugzilla. Please reverse the request to do so in http://gcc.gnu.org/bugs.html and update it and its copies included in releases. In that update please also suggest another way to be specific in report. AFAIK, unless was able to perform (generally, very tedious) experimentation and figure a short test program, it is the only way to be specific. One more note, 2.96 was never an official release. Perhaps should state that explicitly in future reports. Anyway, did include full name of the system binary package, so that anybody can identify the snapshot it is based on (and if no, avoid using systems from that vendor). As for binary packages based on official releases, neither observed it in `gcc-3.3.2-6mdk'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28099
[Bug bootstrap/25002] build breaks if no `NAN'
--- Comment #3 from gin at mo dot msk dot ru 2005-11-23 15:58 --- Subject: Re: build breaks if no `NAN' Did that. This particular translation unit compiles. With warning telling the same. For this particular system there is a workaround, but does it have to be on any system? If it has neither `NAN' nor equivalent value, what standard does it violate, so that one can file a complaint? If there is no such standard, it is still safer to be able to inhibit using `NAN'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25002
[Bug bootstrap/25002] build breaks if no `NAN'
--- Comment #4 from gin at mo dot msk dot ru 2005-11-23 18:08 --- Subject: Re: build breaks if no `NAN' Know at least one more system that has no `NAN' and which native `cc' normally generates code that causes program to terminate abnormally: Arithmetic Exception (core dumped) The system is i586-pc-sco3.2v5.0.2. When specified `-K noieee', `( 0.0 / 0.0 )' static initializer works and generates value that is converted by `printf' to `0.00'. Unlikely to make much sense. Perhaps other systems have other tricky options, with unpredictable results. Still think that allowing to disable use of `NAN' is not needed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25002
