Re: [Regarding GCOV].gcda:stamp mismatch with notes file
Am 25.04.2024 um 08:45 schrieb Gejoe Daniel via Gcc: Hi team, The following is my query posted but would need more inputs : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751 The gcov tool which was working so far seems to fail with our latest branch where gcc is 11.4.0 and hence we wanted to sort this out by getting the right help as early as possible. Awaiting prompt reply. Thanks to the GCC team for all the help ! Regards, Gejoe thanks for looking at that subject - i think i also stumbled over this - thought it was something with my configuration i tried: https://github.com/mozilla/grcov as a temporary solution that worked for me - hoping the fix that maybe comes for you also helps im my case
Re: [Regarding GCOV].gcda:stamp mismatch with notes file
On Thu, 25 Apr 2024 at 07:47, Gejoe Daniel via Gcc wrote: > > Hi team, > The following is my query posted but would need more inputs : > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751 > > The gcov tool which was working so far seems to fail with our latest branch > where gcc is 11.4.0 and hence we wanted to sort this out by getting the right > help as early as possible. > > Awaiting prompt reply. > > Thanks to the GCC team for all the help ! Please don't cross-post to both gcc and gcc-help lists. You've already reported it to bugzilla, spamming multiple lists isn't needed.
Re: [Regarding GCOV].gcda:stamp mismatch with notes file
On Thu, 25 Apr 2024 at 09:54, Jonathan Wakely wrote: > > On Thu, 25 Apr 2024 at 07:47, Gejoe Daniel via Gcc wrote: > > > > Hi team, > > The following is my query posted but would need more inputs : > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751 > > > > The gcov tool which was working so far seems to fail with our latest branch > > where gcc is 11.4.0 and hence we wanted to sort this out by getting the > > right help as early as possible. > > > > Awaiting prompt reply. > > > > Thanks to the GCC team for all the help ! > > Please don't cross-post to both gcc and gcc-help lists. You've already > reported it to bugzilla, spamming multiple lists isn't needed. Just to expand on this, either you're discussing development of GCC, or asking for help using it, but not both. So posting to both lists isn't usually appropriate. If it's a "meta topic" like an announcement to all users of GCC mailing lists then of course sending to multiple lists makes sense.
☠️ NEW! Ивент по One Piece
Зоро спит, а мы нет, потому что запускаем новый аниме-спешл... Узнать подробнее Вы получили это письмо, потому что подписались на рассылку от LB Group. Чтобы отписаться, перейдите по ссылке.
[PATCH] Fix rust on *-w64-mingw32
Hello,
Attached is a patch for fixing build issues on *-w64-mingw32. Please check and
update at your leisure.
'gcc/system.h' contains a macro called `mkdir()` and there is no need to invoke `_mkdir()` within a
conditional block.
--
Best regards,
LIU Hao
diff --git a/gcc/rust/checks/errors/borrowck/rust-borrow-checker.cc
b/gcc/rust/checks/errors/borrowck/rust-borrow-checker.cc
index 5daa7eb8ded..aff0c372789 100644
--- a/gcc/rust/checks/errors/borrowck/rust-borrow-checker.cc
+++ b/gcc/rust/checks/errors/borrowck/rust-borrow-checker.cc
@@ -28,13 +28,7 @@ void
mkdir_wrapped (const std::string &dirname)
{
int ret;
-#ifdef _WIN32
- ret = _mkdir (dirname.c_str ());
-#elif unix
ret = mkdir (dirname.c_str (), 0775);
-#elif __APPLE__
- ret = mkdir (dirname.c_str (), 0775);
-#endif
(void) ret;
}
diff --git a/gcc/rust/expand/rust-proc-macro.cc
b/gcc/rust/expand/rust-proc-macro.cc
index 09680733e98..3518bffaf03 100644
--- a/gcc/rust/expand/rust-proc-macro.cc
+++ b/gcc/rust/expand/rust-proc-macro.cc
@@ -102,6 +102,7 @@ static_assert (
} // namespace
+#ifndef _WIN32
template
bool
register_callback (void *handle, Symbol, std::string symbol_name,
@@ -125,6 +126,7 @@ register_callback (void *handle, Symbol, std::string
symbol_name,
#define REGISTER_CALLBACK(HANDLE, SYMBOL, CALLBACK)
\
register_callback (HANDLE, SYMBOL, #SYMBOL, CALLBACK)
+#endif // _WIN32
const ProcMacro::ProcmacroArray *
load_macros_array (std::string path)
diff --git a/gcc/rust/parse/rust-parse.cc b/gcc/rust/parse/rust-parse.cc
index 504a409cc4d..b78ac524f61 100644
--- a/gcc/rust/parse/rust-parse.cc
+++ b/gcc/rust/parse/rust-parse.cc
@@ -89,7 +89,7 @@ extract_module_path (const AST::AttrVec &inner_attrs,
// Source: rustc compiler
//
(https://github.com/rust-lang/rust/blob/9863bf51a52b8e61bcad312f81b5193d53099f9f/compiler/rustc_expand/src/module.rs#L174)
#if defined(HAVE_DOS_BASED_FILE_SYSTEM)
- path.replace ('/', '\\');
+ std::replace(path.begin(), path.end(), '/', '\\');
#endif /* HAVE_DOS_BASED_FILE_SYSTEM */
return path;
OpenPGP_signature.asc
Description: OpenPGP digital signature
Build errors for older versions
Hi all, while bisecting I recently ran into build errors like In file included from /devel/gcc/libgcc/../gcc/tsystem.h:101, from /devel/gcc/libgcc/libgcov.h:42, from /devel/gcc/libgcc/libgcov-interface.c:26: /usr/include/stdlib.h:931:6: error: wrong number of arguments specified for 'malloc' attribute 931 | __attr_dealloc_free __wur; | ^~~ /usr/include/stdlib.h:931:6: note: expected between 0 and 0, found 2 My host system is Fedora 39 on x86_64 while trying to build r11-3896-g61a43de58cb6de. The error does not appear if I'm using e.g. Fedora 34. Is this known and if so does there exist a workaround such that building older versions on a recent OS works? Cheers, Stefan
Re: [PATCH] Fix rust on *-w64-mingw32
On Thu, Apr 25, 2024 at 07:16:31PM +0800, LIU Hao via Gcc wrote:
> --- a/gcc/rust/parse/rust-parse.cc
> +++ b/gcc/rust/parse/rust-parse.cc
> @@ -89,7 +89,7 @@ extract_module_path (const AST::AttrVec &inner_attrs,
>// Source: rustc compiler
>//
> (https://github.com/rust-lang/rust/blob/9863bf51a52b8e61bcad312f81b5193d53099f9f/compiler/rustc_expand/src/module.rs#L174)
> #if defined(HAVE_DOS_BASED_FILE_SYSTEM)
> - path.replace ('/', '\\');
> + std::replace(path.begin(), path.end(), '/', '\\');
This should be
std::replace (path.begin (), path.end (), '/', '\\');
(at least if gcc/rust/ follows normal GCC coding conventions).
Jakub
Re: Build errors for older versions
On Thu, Apr 25, 2024 at 4:21 AM Stefan Schulze Frielinghaus via Gcc wrote: > > Hi all, > > while bisecting I recently ran into build errors like > > In file included from /devel/gcc/libgcc/../gcc/tsystem.h:101, > from /devel/gcc/libgcc/libgcov.h:42, > from /devel/gcc/libgcc/libgcov-interface.c:26: > /usr/include/stdlib.h:931:6: error: wrong number of arguments specified for > 'malloc' attribute > 931 | __attr_dealloc_free __wur; > | ^~~ > /usr/include/stdlib.h:931:6: note: expected between 0 and 0, found 2 > > My host system is Fedora 39 on x86_64 while trying to build > r11-3896-g61a43de58cb6de. The error does not appear if I'm using e.g. > Fedora 34. Is this known and if so does there exist a workaround such > that building older versions on a recent OS works? Basically glibc's check for GCC version is only designed for released versions of GCC. So bisecting GCC means sometimes that check will break. I have not fully looked into it but maybe glibc folks can provide a workaround to disable the version check to assume a much older version of GCC here. Thanks, Andrew Pinski > > Cheers, > Stefan
Re: Build errors for older versions
On Thu, Apr 25, 2024 at 8:55 AM Andrew Pinski wrote: > > On Thu, Apr 25, 2024 at 4:21 AM Stefan Schulze Frielinghaus via Gcc > wrote: > > > > Hi all, > > > > while bisecting I recently ran into build errors like > > > > In file included from /devel/gcc/libgcc/../gcc/tsystem.h:101, > > from /devel/gcc/libgcc/libgcov.h:42, > > from /devel/gcc/libgcc/libgcov-interface.c:26: > > /usr/include/stdlib.h:931:6: error: wrong number of arguments specified for > > 'malloc' attribute > > 931 | __attr_dealloc_free __wur; > > | ^~~ > > /usr/include/stdlib.h:931:6: note: expected between 0 and 0, found 2 > > > > My host system is Fedora 39 on x86_64 while trying to build > > r11-3896-g61a43de58cb6de. The error does not appear if I'm using e.g. > > Fedora 34. Is this known and if so does there exist a workaround such > > that building older versions on a recent OS works? > > Basically glibc's check for GCC version is only designed for released > versions of GCC. So bisecting GCC means sometimes that check will > break. > I have not fully looked into it but maybe glibc folks can provide a > workaround to disable the version check to assume a much older version > of GCC here. > > Thanks, > Andrew Pinski I keep the older versions of GCC around for this case: [hjl@gnu-cfl-3 usr]$ ls -d /usr/gcc* /usr/gcc-10.2.1-32bit /usr/gcc-12.3.1-32bit /usr/gcc-14.0.1-x32 /usr/gcc-10.2.1-mx32 /usr/gcc-12.3.1-mx32 /usr/gcc-6.4.1-x32 /usr/gcc-10.2.1-x32/usr/gcc-12.3.1-x32/usr/gcc-7.4.1-x32 /usr/gcc-11.2.1-32bit /usr/gcc-13.2.1-32bit /usr/gcc-8.4.1-x32 /usr/gcc-11.2.1-mx32 /usr/gcc-13.2.1-mx32 /usr/gcc-9.3.1-x32 /usr/gcc-11.2.1-x32/usr/gcc-13.2.1-x32 [hjl@gnu-cfl-3 usr]$ -- H.J.
Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls
Am 15.03.2024 um 21:40 schrieb Björn Schäpers: Am 25.01.2024 um 23:04 schrieb Ian Lance Taylor: On Thu, Jan 25, 2024 at 11:53 AM Björn Schäpers wrote: Am 23.01.2024 um 23:37 schrieb Ian Lance Taylor: On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote: Am 03.01.2024 um 00:12 schrieb Björn Schäpers: Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor: On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote: From: Björn Schäpers Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except that libraries loaded after the backtrace_initialize are not handled. But as far as I can see that's the same for elf. Thanks, but I don't want a patch that loops using goto statements. Please rewrite to avoid that. It may be simpler to call a function. Also starting with a module count of 1000 seems like a lot. Do typical Windows programs load that many modules? Ian Rewritten using a function. If that is commited, could you attribute that commit to me (--author="Björn Schäpers ")? Thanks and kind regards, Björn. I noticed that under 64 bit libraries loaded with LoadLibrary were missing. EnumProcessModules stated the correct number of modules, but did not fill the the HMODULEs, but set them to 0. While trying to investigate I noticed if I do the very same thing from main (in C++) I even got fewer module HMODULEs. So I went a different way. This detects all libraries correctly, in 32 and 64 bit. The question is, if it should be a patch on top of the previous, or should they be merged, or even only this solution and drop the EnumProcessModules variant? Is there any reason to use both patches? Seems simpler to just use this one if it works. Thanks. Ian This one needs the tlhelp32 header and its functions, which are (accoridng to the microsoft documentation) are only available since Windows XP rsp. Windows Server 2003. If that's no problem, and in my opinion it shouldn't be, then I can basically drop patch 4 and rebase this one. I don't see that as a problem. It seems like the patch will fall back cleanly on ancient Windows and simply fail to pick up other loaded DLLs. I think that is fine. I'll look for an updated patch. Thanks. Ian Attached is the combined version of the two patches, only implementing the variant with the tlhelp32 API. Tested on x86 and x86_64 windows. Kind regards, Björn. A friendly ping.
gcc-11-20240425 is now available
Snapshot gcc-11-20240425 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20240425/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision dca9066e7deda6182b722ee4373f08909b8236d9 You'll find: gcc-11-20240425.tar.xz Complete GCC SHA256=3f02f1ba0e67c0171a203eab58188400cb74c4084325d70bfac0035d651437d7 SHA1=e17bed5a446c9caead827ec4d56f10b3afa6ad08 Diffs from 11-20240418 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
