date:20231120

GCC 14.0.0 Status Report (2023-11-20), Stage 3 in effect now

2023-11-20 Thread Richard Biener via Gcc

Status
==

The GCC development branch which will become GCC 14 is in
general bugfixing mode (Stage 3) now.  There is still time
to get larger changes in that were posted before the end
of Stage 1 but this is more aimed at fixing important bugs
that are not regressions and maybe flesh out details of
larger changes that already went in.

Please help triaging UNCONFIRMED reported regressions and
start to assess the state of your favorite target also with
respect to expected performance, reporting issues you can find.


Quality Data


Priority  #   Change from last report
---   ---
P1   30   -   7
P2  499   -   2
P3  244   +  36
P4  212   -   2
P5   25
---   ---
Total P1-P3 773   +  27
Total  1010   +  25


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2023-October/242733.html

GCC developer room at FOSDEM 2024: Call for Participation open

2023-11-20 Thread Thomas Schwinge

Hi!

On 2023-11-10T18:20:55-0500, David Malcolm  wrote:
> We're excited to announce that GCC will have a developer room at the
> upcoming FOSDEM 2024, in Brussels, Belgium:

Now also announcing the devroom/CfP on , "News";
pushed commit 1825b255beb7d7edca775c401222ad2cb41ea193
"GCC developer room at FOSDEM 2024: Call for Participation open"
to wwwdocs master branch, see attached.


Grüße
 Thomas


> https://fosdem.org/2024/
>
> This email is a Call for Presentations about GCC for the developer
> room.
>
> Important Dates:
>
> 1st December 2023  Submission deadline
> 8th December 2023  Acceptance notifications
> 15th December 2023 Final Schedule announcement
> 3rd-4th February 2024  FOSDEM!
>
> ## CFP Introduction
>
> This devroom is geared towards both users of GCC and developers of GCC,
> and of closely related toolchain components (binutils, glibc, newlib,
> for example).
>
> The goal of the devroom is for GCC developers to get in touch with each
> other, and with users of GCC, to have (we hope) productive discussions
> about it, to help people get involved in development, and to have fun.
>
> The format of the expected presentations will cover a range that
> includes:
>
>  * technical presentations
>  * tutorials
>  * lightning talks
>  * demos
>
> Typically presentation slots are 25 minutes, with 15 minutes
> recommended for presentations, and 10 minutes for Q&A.
> Lightning talks are 5 minutes each.
>
> ### What is FOSDEM?
>
> **FOSDEM is a free event for software developers to meet, share ideas
> and collaborate.**
>
> Every year, thousands of developers of free and open source software
> from all over the world gather at the event in Brussels.
>
> FOSDEM 2024 will take place on Saturday 3 and Sunday 4 February 2024.
> It will be an in-person event at the **ULB Solbosch Campus, Brussels,
> Belgium, Europe.**
> If you aren't there, you can watch the live streams from the main
> tracks and developer rooms.
>
> ### Important stuff:
>
> - FOSDEM is free to attend. There is no registration.
> - [FOSDEM website](https://fosdem.org/)
> - [FOSDEM code of conduct](https://fosdem.org/2024/practical/conduct/)
> - [FOSDEM Schedule](https://fosdem.org/2024/schedule/)
>
> ### Desirable topics:
>
>  * Technical presentations, such as discusion of GCC internals
>  * Talks for users of GCC, such as presentation of new features
>  * Tutorials (e.g. on GCC usage, or on getting involved in
>  GCC development)
>  * Lightning talks
>  * Demos
>
> ### Topic overlap
>
> There are over 50 developer rooms this year, and multiple main tracks,
> so there may be overlap with some other events.
> If the topic would fit more than one devroom, you are free to choose
> which to submit to, but we encourage you to consider the focus of the
> talk, and see which devroom is best matched.
>
> Full list of devrooms
> [here](https://fosdem.org/2024/news/2023-11-08-devrooms-announced/).
>
> ### How to submit your proposal
>
> To submit a talk, please visit the [FOSDEM 2024 Pretalx
> website](https://pretalx.fosdem.org/fosdem-2024/cfp).
>
> Click **Submit a proposal**. Make sure you choose the "GCC" devroom in
> the track drop-down menu (so that we see it rather than another
> devroom's organisers)
>
> ### What should be in your submission
>
> - name
> - short bio
> - contact info
> - title
> - abstract (what you're going talk about, supports markdown)
>
> Your abstract should indicate expected prior knowledge / intended
> audience, to help FOSDEM attendees choose between sessions.
>
> Optional:
>
> - submission notes (for the organiser only, not made public)
> - description (more detail description, supports markdown)
> - session image (if you have an illustration to go with the talk)
> - additional speaker/s (if more than one person presenting)
>
> Afterwards, click "Continue".
> The second page will include fields for:
>
> - Extra materials for reviewers (optional, for organisers only)
> - Additional information about the speaker (optional).
> - Resources to be used during the talk
>
> All presentations will be recorded and made available under Creative
> Commons licenses. In the Submission notes field, please indicate that
> you agree that your presentation will be licensed under the CC-By-SA-
> 4.0 or CC-By-4.0 license and that you agree to have your presentation
> recorded.
>
> For example:
>
>   "If my presentation is accepted for FOSDEM, I hereby agree to
>   license all recordings, slides, and other associated materials
>   under the Creative Commons Attribution Share-Alike 4.0 International 
>   License.
>
>  Sincerely,
>
>  ."
>
> Once you've completed the required sections, submit and we'll get back
> to you soon!
>
> ### Things to be aware of
>
> * The reference time will be Brussels local lime (CET)
> 
> * If you're not able to attend the talk in-person, live stream links
>

Re: LRA for avr: Maintain live range info for pseudos assigned to FP?

2023-11-20 Thread Georg-Johann Lay





Am 20.11.23 um 08:14 schrieb SenthilKumar.Selvaraj--- via Gcc:

On Thu, 2023-10-05 at 15:33 -0400, Vladimir Makarov wrote:

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe

On 9/7/23 07:21, senthilkumar.selva...@microchip.com wrote:

Hi,

One more execution failure for the avr target, this time from
gcc.c-torture/execute/bitfld-3.c.

Steps to reproduce

Enable LRA in avr.cc by removing TARGET_LRA_P hook, build with

$  make all-host && make install-host

and then

$ avr-gcc gcc/testsuite/gcc.c-torture/execute/bitfld-3.c -S -Os -mmcu=avr51 
-fdump-rtl-all

When lra_update_fp2sp_elimination runs and pseudos assigned to the
FP have to be spilled to stack slots, they sometimes end up in a
slot that already has a reg with an overlapping live range.  This is
because lra_reg_info[regno].live_ranges is NULL for such spilled
pseudos, and therefore when assign_stack_slot_num_and_sort_pseduos
checks if lra_intersected_live_ranges_p, it always returns false.

In the below reload dump, all the pseudos assigned to FP get
allocated to slot 0. The live ranges for some of them (r1241 for
e.g.) conflicts with r603 that was originally assigned to slot 0,
but they still end up in the same slot, causing the execution failure.


Sorry for the delay with the answer, Senthil.  Avr is unusual target and
needs some changes in LRA but the changes improves LRA portability.  So
thank you for your work on porting LRA to AVR.

The patch is ok for me.  The only comment is that making calculation of
the set only once would be nice. Live range calculation in LRA can take
a lot of time, code of update_pseudo_point is hot and the worst the set
will be really used rarely but it is calculated every time.

You can commit the current patch and I'll do it by myself or, if you
want, you can modify the patch by yourself and submit it for review and
I'll review as soon as possible.  Either way works for me.


Apologies for the extreme delay in responding - had to sort out some medical 
issues.

Is it ok if I commit the patch now? I have one more patch in ira.cc, after
which I'm hoping the regression results would be good enough to switch the
avr target to LRA.

Regards
Senthil


I have two questions:

1) Is there a command line option to switch back to IRA?

2) Will the X register be used for memory accesses? I am asking because
as far as I understand, there is no replacement for 
LEGITIMIZE_RELOAD_ADDRESS.


Regards,

Johann

Reporitng libstdc++ bug without account to Bugzilla

2023-11-20 Thread Palmu, Miro M

Hi

I think I found libstdc++ bug and I tried to report to Bugzilla but "user 
account creation has been restricted".

So I'm going to report it here in hope that someone with a account could report 
it to Bugzilla if they seem it fit.

Using gcc 13.2 with -std=c++23 code below (https://godbolt.org/z/Kc36rcMYx) 
does not compile even if all compile time
allocations are freed before returning from compile time context. MSVC is able 
to compile it.

I was suggested elsewhere that it could be some oversight in the SSO 
implementation.
 
```
#include 
#include 
#include 
#include 

using namespace std;
using namespace std::literals;

constexpr auto foo() {
const auto vec = vector{ "a"s, "b"s, "c"s };
return ranges::fold_left(vec, ""s, plus{});
}

constexpr auto bar() {
return foo().size();
}

int main() {
constexpr auto _ = bar(); // This does not compile
}
```

Error message:

```
: In function 'int main()':
:19:27:   in 'constexpr' expansion of 'bar()'
:15:23:   in 'constexpr' expansion of 'foo()()'
:19:28:   in 'constexpr' expansion of 
'std::ranges::__fold_left_fn::operator()(_Range&&, _Tp, _Fp) const [with _Range 
= const std::vector, 
std::allocator > >&; _Tp = 
std::__cxx11::basic_string; _Fp = std::plus](vec, 
std::literals::string_literals::operator""s(const char*, std::size_t)(0), 
(std::plus(), std::plus()))'
:19:28:   in 'constexpr' expansion of 
'std::__cxx11::basic_string((* & 
std::move<__cxx11::basic_string&>(__init)))'
:19:28: error: accessing 'std::__cxx11::basic_string_M_allocated_capacity' member instead of initialized 
'std::__cxx11::basic_string_M_local_buf' member in 
constant expression
   19 | constexpr auto _ = bar();
  |^
```

Miro Palmu

Re: Reporitng libstdc++ bug without account to Bugzilla

2023-11-20 Thread Jonathan Wakely via Gcc

On Mon, 20 Nov 2023 at 14:23, Palmu, Miro M wrote:
>
> Hi
>
> I think I found libstdc++ bug and I tried to report to Bugzilla but "user 
> account creation has been restricted".
>
> So I'm going to report it here in hope that someone with a account could 
> report it to Bugzilla if they seem it fit.

No, but if you email the account creation address as suggested by
bugzilla, then we can create an account for you.

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

2023-11-20 Thread Björn Schäpers


Hi,

this is what I'm using with GCC 12 and 13 on my windows machines, rebased onto 
the current HEAD.


Kind regards,
Björn.

Am 06.02.2023 um 01:22 schrieb Ian Lance Taylor:

On Sun, Feb 5, 2023 at 1:21 AM Björn Schäpers  wrote:


Am 24.01.2023 um 19:32 schrieb Ian Lance Taylor:

On Tue, Jan 24, 2023 at 10:12 AM Eli Zaretskii via Gcc-patches
 wrote:



From: Ian Lance Taylor 
Date: Tue, 24 Jan 2023 09:58:10 -0800
Cc: g...@hazardy.de, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org

I'd rather that the patch look like the appended.  Can someone with a
Windows system test to see what that builds and passes the tests?


ENOPATCH


Gah.

Ian


That seems to be my original patch, right? That one I have tested (and
am actually using) on x86 and x64 windows.


It's very similar but I changed the windows_get_executable_path function.

Ian
From e0ee58b71f726606205aa1f0168a724859162c21 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B6rn=20Sch=C3=A4pers?= 
Date: Sun, 30 Apr 2023 23:48:18 +0200
Subject: [PATCH 1/3] libbacktrace: detect executable path on windows
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Tested on x86_64-linux with GCC 12, i686-w64-mingw32 and
x86_64-w64-mingw32 with GCC 12 & 13. This patch is rebased onto the
current HEAD.

-- >8 --

* configure.ac: Add a check for windows.h.
* configure, config.h.in: Regenerate.
* fileline.c: Add windows_get_executable_path.
* fileline.c (fileline_initialize): Add a pass using
windows_get_executable_path.

Signed-off-by: Björn Schäpers 
---
 libbacktrace/config.h.in  |  3 +++
 libbacktrace/configure| 13 +++
 libbacktrace/configure.ac |  2 ++
 libbacktrace/fileline.c   | 49 ++-
 4 files changed, 66 insertions(+), 1 deletion(-)

diff --git a/libbacktrace/config.h.in b/libbacktrace/config.h.in
index a4f5bf6..ee2616335c7 100644
--- a/libbacktrace/config.h.in
+++ b/libbacktrace/config.h.in
@@ -104,6 +104,9 @@
 /* Define to 1 if you have the  header file. */
 #undef HAVE_UNISTD_H
 
+/* Define to 1 if you have the  header file. */
+#undef HAVE_WINDOWS_H
+
 /* Define if -lz is available. */
 #undef HAVE_ZLIB
 
diff --git a/libbacktrace/configure b/libbacktrace/configure
index 0ccc060901d..7ade966b54d 100755
--- a/libbacktrace/configure
+++ b/libbacktrace/configure
@@ -13509,6 +13509,19 @@ $as_echo "#define HAVE_LOADQUERY 1" >>confdefs.h
 
 fi
 
+for ac_header in windows.h
+do :
+  ac_fn_c_check_header_mongrel "$LINENO" "windows.h" "ac_cv_header_windows_h" 
"$ac_includes_default"
+if test "x$ac_cv_header_windows_h" = xyes; then :
+  cat >>confdefs.h <<_ACEOF
+#define HAVE_WINDOWS_H 1
+_ACEOF
+
+fi
+
+done
+
+
 # Check for the fcntl function.
 if test -n "${with_target_subdir}"; then
case "${host}" in
diff --git a/libbacktrace/configure.ac b/libbacktrace/configure.ac
index 71cd50f8cdf..00acb42eb6d 100644
--- a/libbacktrace/configure.ac
+++ b/libbacktrace/configure.ac
@@ -379,6 +379,8 @@ if test "$have_loadquery" = "yes"; then
   AC_DEFINE(HAVE_LOADQUERY, 1, [Define if AIX loadquery is available.])
 fi
 
+AC_CHECK_HEADERS(windows.h)
+
 # Check for the fcntl function.
 if test -n "${with_target_subdir}"; then
case "${host}" in
diff --git a/libbacktrace/fileline.c b/libbacktrace/fileline.c
index 0e560b44e7a..28d752e2625 100644
--- a/libbacktrace/fileline.c
+++ b/libbacktrace/fileline.c
@@ -47,6 +47,18 @@ POSSIBILITY OF SUCH DAMAGE.  */
 #include 
 #endif
 
+#ifdef HAVE_WINDOWS_H
+#ifndef WIN32_MEAN_AND_LEAN
+#define WIN32_MEAN_AND_LEAN
+#endif
+
+#ifndef NOMINMAX
+#define NOMINMAX
+#endif
+
+#include 
+#endif
+
 #include "backtrace.h"
 #include "internal.h"
 
@@ -165,6 +177,34 @@ macho_get_executable_path (struct backtrace_state *state,
 
 #endif /* !HAVE_DECL__PGMPTR */
 
+#ifdef HAVE_WINDOWS_H
+
+static char *
+windows_get_executable_path (char *buf, backtrace_error_callback 
error_callback,
+void *data)
+{
+  size_t got;
+  int error;
+
+  got = GetModuleFileNameA (NULL, buf, MAX_PATH - 1);
+  error = GetLastError ();
+  if (got == 0
+  || (got == MAX_PATH - 1 && error == ERROR_INSUFFICIENT_BUFFER))
+{
+  error_callback (data,
+ "could not get the filename of the current executable",
+ error);
+  return NULL;
+}
+  return buf;
+}
+
+#else /* !defined (HAVE_WINDOWS_H) */
+
+#define windows_get_executable_path(buf, error_callback, data) NULL
+
+#endif /* !defined (HAVE_WINDOWS_H) */
+
 /* Initialize the fileline information from the executable.  Returns 1
on success, 0 on failure.  */
 
@@ -178,7 +218,11 @@ fileline_initialize (struct backtrace_state *state,
   int called_error_callback;
   int descriptor;
   const char *filename;
+#ifdef HAVE_WINDOWS_H
+  char buf[MAX_PATH];
+#else
   char buf[64];
+#endif
 
   if (!state->threaded)
 failed = state->fileline_initialization_failed;
@@ -202,7 +246,7 @@ fileline_initialize (struct backtrace_sta

Re: [PATCH 3/4] libbacktrace: work with aslr on windows

2023-11-20 Thread Björn Schäpers

An updated version, using neither A or W, but just the macro.

Am 21.01.2023 um 12:42 schrieb Eli Zaretskii:

Date: Sat, 21 Jan 2023 11:47:42 +0100
Cc: g...@hazardy.de, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
From: Gabriel Ravier 

On 1/21/23 05:05, Eli Zaretskii wrote:

Date: Fri, 20 Jan 2023 21:39:56 +0100
Cc: g...@hazardy.de, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
From: Gabriel Ravier 

- using wide APIs with Windows is generally considered to be a best
practice, even when not strictly needed (and in this case I can't see
any problem with doing so, unless maybe we want to code to work with
Windows 95 or something like that...)

There's no reason to forcibly break GDB on platforms where wide APIs
are not available.

Are there even any platforms that have GetModuleHandleA but not
GetModuleHandleW ? MSDN states that Windows XP and Windows Server 2003
are the first versions to support both of the APIs, so if this is
supposed to work on Windows 98, for instance, whether we're using
GetModuleHandleA or GetModuleHandleW won't matter.

I'm not sure I follow the logic.  A program that calls
GetModuleHandleW will refuse to start on Windows that doesn't have
that API.  So any version before XP is automatically excluded the
moment you use code which calls that API directly (i.e. not through a
function pointer or somesuch).

A program that calls GetModuleHandleA will also refuse to start on
Windows if it doesn't have that API. The set of Windows versions that do
not have GetModuleHandleA is, according to MSDN, the same as the set of
Windows versions that do not have GetModuleHandleW.

MSDN lies (because it wants to pretend that older versions don't
exist).  Try this much more useful site:

   http://winapi.freetechsecrets.com/win32/WIN32GetModuleHandle.htm
From 52cbe06b1c165172191f66ff7e55a49adecf661d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B6rn=20Sch=C3=A4pers?= 
Date: Sun, 30 Apr 2023 23:52:37 +0200
Subject: [PATCH 2/3] libbacktrace: work with aslr on windows
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Any underflow which might happen, will be countered by an overflow in
dwarf.c.

Tested on x86_64-linux and i686-w64-mingw32.

-- >8 --

Fixes https://github.com/ianlancetaylor/libbacktrace/issues/89 and
https://github.com/ianlancetaylor/libbacktrace/issues/82.

* pecoff.c (coff_add): Set the base_address of the module, to
find the debug information on moved applications.

Signed-off-by: Björn Schäpers 
---
 libbacktrace/pecoff.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/libbacktrace/pecoff.c b/libbacktrace/pecoff.c
index 56af4828e27..9cc13b47947 100644
--- a/libbacktrace/pecoff.c
+++ b/libbacktrace/pecoff.c
@@ -39,6 +39,18 @@ POSSIBILITY OF SUCH DAMAGE.  */
 #include "backtrace.h"
 #include "internal.h"

+#ifdef HAVE_WINDOWS_H
+#ifndef WIN32_MEAN_AND_LEAN
+#define WIN32_MEAN_AND_LEAN
+#endif
+
+#ifndef NOMINMAX
+#define NOMINMAX
+#endif
+
+#include 
+#endif
+
 /* Coff file header.  */

 typedef struct {
@@ -610,6 +622,8 @@ coff_add (struct backtrace_state *state, int descriptor,
   int debug_view_valid;
   int is_64;
   uintptr_t image_base;
+  uintptr_t base_address = 0;
+  uintptr_t module_handle;
   struct dwarf_sections dwarf_sections;

   *found_sym = 0;
@@ -856,7 +870,12 @@ coff_add (struct backtrace_state *state, int descriptor,
  + (sections[i].offset - min_offset));
 }

-  if (!backtrace_dwarf_add (state, /* base_address */ 0, &dwarf_sections,
+#ifdef HAVE_WINDOWS_H
+module_handle = (uintptr_t) GetModuleHandle (NULL);
+base_address = module_handle - image_base;
+#endif
+
+  if (!backtrace_dwarf_add (state, base_address, &dwarf_sections,
0, /* FIXME: is_bigendian */
NULL, /* altlink */
error_callback, data, fileline_fn,
-- 
2.42.1

Re: [PATCH 3/4] libbacktrace: work with aslr on windows

2023-11-20 Thread Eli Zaretskii via Gcc

> Date: Mon, 20 Nov 2023 20:57:38 +0100
> Cc: gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
> From: Björn Schäpers 
> 
> +#ifndef NOMINMAX
> +#define NOMINMAX
> +#endif

Why is this part needed?

Otherwise, LGTM, thanks.  (But I'm don't have the approval rights, so
please wait for Ian to chime in.)

function parameters

2023-11-20 Thread André Albergaria Coelho via Gcc


Hello

#include 

void func(char *ptr) {
    printf("\n%i",sizeof(ptr));
}

int main(void) {
    char arr[10];
    printf("\n Sizeof arr %i",sizeof(arr));
    func(arr);

    return 0;
}

/* sizeof(arr) != sizeof(ptr), but they point to same thing. */


So problem. On main, arr has size 10, while on func, arr has size 8. But 
they are equal.



--
André Albergaria Coelho
andrealberga...@gmail.com

Re: function parameters

2023-11-20 Thread Martin Uecker

Am Dienstag, dem 21.11.2023 um 02:30 + schrieb André Albergaria Coelho via 
Gcc:
> Hello
> 
> #include 
> 
> void func(char *ptr) {
>      printf("\n%i",sizeof(ptr));
> }
> 
> int main(void) {
>      char arr[10];
>      printf("\n Sizeof arr %i",sizeof(arr));
>      func(arr);
> 
>      return 0;
> }
> 
> /* sizeof(arr) != sizeof(ptr), but they point to same thing. */
> 
> 
> So problem. On main, arr has size 10, while on func, arr has size 8. But 
> they are equal.

No problem. sizeof(ptr) is the size of the pointer object
itself, while arr is the size of the array. 

In  func(arr)  the array is converted to a pointer to
its first element.

If you want to pass the address of the array itself and
then get its size in 'func' you could write it like this:

#include 

void func(char (*ptr)[10]) {
 printf("\n%i",sizeof(*ptr));  // sizeof pointer target
}

int main(void) {
 char arr[10];
 printf("\n Sizeof arr %i",sizeof(arr));
 func(&arr);// pass address to array

 return 0;
}


Martin


> 
>

Question about creating an outermost loop

2023-11-20 Thread Hanke Zhang via Gcc

Hi, I'm working on loop tiling recently. I want to add this
optimization to GCC. But I have encoutered some problems here and ask
for help.

For the code below as an example:

for (int i = 0; i < 12; i++) {
  for (int j = 0; j < arr.length; j++) { // arr.length may be huge
// do something with arr[j]
  }
}

I want to create an outermost loop that wraps around the two loops of
the inner layer, and at the same time change the loop variables of the
innermost loop. The final result is as follows:

for (int k = 0; k < 8192; k++) {
  for (int i = 0; i < 12; i++) {
for (int j = 0; j < arr.length / 8192; j++) {
  // do something with arr[k * (arr.length / 8192) + j]
}
  }
}

But I don't know how to do this properly. I'm stuck with virtual
oprands and PHIs.

Is there any existing optimization in GCC that I can refer to?

Thanks.
Hanke Zhang.

GCC 14.0.0 Status Report (2023-11-20), Stage 3 in effect now

GCC developer room at FOSDEM 2024: Call for Participation open

Re: LRA for avr: Maintain live range info for pseudos assigned to FP?

Reporitng libstdc++ bug without account to Bugzilla

Re: Reporitng libstdc++ bug without account to Bugzilla

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

Re: [PATCH 3/4] libbacktrace: work with aslr on windows

Re: [PATCH 3/4] libbacktrace: work with aslr on windows

function parameters

Re: function parameters

Question about creating an outermost loop

11 matches

Site Navigation

Mail list logo

Footer information