Gathering Computer Technology and Information Science , sincerely invite you to join CTIS 2025

Gathering Computer Technology and Information Science, sincerely invite you to join CTIS 2025 Official Website: http://email.km.icctis.org/c/eJxMy7lOxDAQANCvsctoPB7bcTHFChGOgnMbqigZTw6WJSgEIv4eiYr66RUWTYm8VXbJA1EGDHbiCEBBB9Hc115q6DyVMsSS1XfSKdhpb0_6w0O

Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls

On Thu, May 2, 2024 at 12:23 PM Björn Schäpers wrote: > > Am 28.04.2024 um 20:16 schrieb Ian Lance Taylor: > > > > Which of your other patches are still relevant? Thanks. > > > only this one. Thanks. Committed. Ian

Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls

LdrRegisterDllNotification to load debug information of later loaded dlls. --- libbacktrace/pecoff.c | 106 ++ 1 file changed, 106 insertions(+) diff --git a/libbacktrace/pecoff.c b/libbacktrace/pecoff.c index

Re: Question about information from -fdump-rtl-sched2 on M1 Max

support (not yet upstream). > > 2) Those branches will also have hopefully better choices for the tuning and > scheduling within the available models (I got some advice from Tamar, > thanks!). > > 3) Andrew is correct, we have not really had much information from the vendor

Re: Question about information from -fdump-rtl-sched2 on M1 Max

pu=apple-m1,m2,m3 2) Those branches will also have hopefully better choices for the tuning and scheduling within the available models (I got some advice from Tamar, thanks!). 3) Andrew is correct, we have not really had much information from the vendor about the scheduling - although the latest d

Re: Question about information from -fdump-rtl-sched2 on M1 Max

On Mon, Apr 29, 2024 at 4:26 PM Lucier, Bradley J via Gcc wrote: > > The question: How to interpret scheduling info with the compiler listed below. > > Specifically, a tight loop that was reported to be scheduled in 23 cycles (as > I understand it) actually executes in a little over 2 cycles per

Re: Question about information from -fdump-rtl-sched2 on M1 Max

That should be 4 cycles per loop, sorry. > On Apr 29, 2024, at 7:24 PM, Lucier, Bradley J wrote: > > Specifically, a tight loop that was reported to be scheduled in 23 cycles (as > I understand it) actually executes in a little over 2 cycles per loop

Question about information from -fdump-rtl-sched2 on M1 Max

The question: How to interpret scheduling info with the compiler listed below. Specifically, a tight loop that was reported to be scheduled in 23 cycles (as I understand it) actually executes in a little over 2 cycles per loop, as I interpret two separate experiments. Am I misinterpreting somet

Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls

On Thu, Apr 25, 2024 at 1:15 PM Björn Schäpers wrote: > > > 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. Thanks. Committed as follows.

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

Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls

55319f4e2f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bj=C3=B6rn=20Sch=C3=A4pers?= Date: Sun, 30 Apr 2023 23:54:32 +0200 Subject: [PATCH 1/2] libbacktrace: get debug information for loaded dlls MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fixes https://githu

Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls

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 2

Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls

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://

Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls

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/ianlanceta

Re: [PATCH 4/4] libbacktrace: get debug information for loaded dlls

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_initial

[PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls

?= Date: Thu, 4 Jan 2024 22:02:03 +0100 Subject: [PATCH 2/2] libbacktrace: improve getting debug information for loaded dlls EnumProcessModules does not always result in all modules loaded, especially those that are loaded with LoadLibrary. libbacktrace/Changelog: * configure.ac: Ch

Re: [PATCH 4/4] libbacktrace: get debug information for loaded dlls

:54:32 +0200 Subject: [PATCH] libbacktrace: get debug information for loaded dlls MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except that libraries loaded after the backtrace_initialize are

Re: [PATCH 4/4] libbacktrace: get debug information for loaded dlls

> Date: Thu, 30 Nov 2023 11:53:54 -0800 > Cc: gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org > From: Ian Lance Taylor via Gcc > > Also starting with a module count of 1000 seems like a lot. Do > typical Windows programs load that many modules? Unlikely. I'd start with 100.

Re: [PATCH 4/4] libbacktrace: get debug information for loaded dlls

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

[PATCH 4/4] libbacktrace: get debug information for loaded dlls

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. Tested on x86_64-linux and i686-w64-mingw32. -- >8 -- * pecoff.c (coff_add)

Re: [RFC] database with API information

On Fri, 9 Sept 2022 at 19:41, SAIFI wrote: > > > ---Original Message--- > > From: Jonathan Wakely > > > > > Would any of the C++11 compliant CSV parsing libraries make the cut > > > in your analysis ? > > > > I'm not going to waste my time looking. > > > > > Vince CSV parser (RFC418

Re: [RFC] database with API information

> ---Original Message--- > From: Jonathan Wakely > > > Would any of the C++11 compliant CSV parsing libraries make the cut > > in your analysis ? > > I'm not going to waste my time looking. > > > Vince CSV parser (RFC4180 + flavours) > > https://github.com/vincentlaucsb/csv-par

Re: [RFC] database with API information

On Fri, 9 Sep 2022, 17:42 SAIFI, wrote: > > Perhaps this is something the current build scripts take care of anyway. > Is it possible to reuse ? > The makefiles could be adapted to add an extra step into the build process but it would take more effort to make it work. The proposed script already

Re: [RFC] database with API information

> On 9 Sep 2022, at 18:07, Ulrich Drepper via Gcc wrote: > > On Fri, Sep 9, 2022 at 5:26 PM Iain Sandoe wrote: > >> One small request, I realise that Python 2 is dead, but I regularly >> bootstrap GCC >> on older machines that only have Python 2 installations. If possible (and >> it sounds

Re: [RFC] database with API information

On Fri, Sep 9, 2022 at 5:26 PM Iain Sandoe wrote: > One small request, I realise that Python 2 is dead, but I regularly > bootstrap GCC > on older machines that only have Python 2 installations. If possible (and > it sounds > plausible if the job is really quite simple) - it would be good to sup

Re: [RFC] database with API information

> ---Original Message--- > From: Jonathan Wakely > > > Am i missing something here ? > > OK ... > > This script would be needed to bootstrap GCC. Using C++ would mean > that we need to restrict it to C++11 (since that's all that is needed > for bootstrapping GCC), and deal wit

Re: [RFC] database with API information

the table is not really a concern >>> anymore. >>> >>> Jonathan mentioned that he has to create and maintain a similar file for >>> the module support. It needs to list all the exported interfaces and this >>> is mostly a superset of the entries in the

Re: [RFC] database with API information

On Fri, 9 Sept 2022 at 13:06, SAIFI wrote: > > On 9 September 2022 11:47:30 am UTC, Jonathan Wakely > wrote: > >On Fri, 9 Sept 2022 at 12:17, SAIFI wrote: > >> > >> > > >> > let's use a simple database, a CSV file for simplicity, and generate > >> > both files from this. > >> > >> Curious to le

Re: [RFC] database with API information

On 9 September 2022 11:47:30 am UTC, Jonathan Wakely wrote: >On Fri, 9 Sept 2022 at 12:17, SAIFI wrote: >> >> > >> > let's use a simple database, a CSV file for simplicity, and generate both >> > files from this. >> >> Curious to learn, why wouldn't you want to do it in C++ itself ? >> >> As an

Re: [RFC] database with API information

On Fri, 9 Sept 2022 at 12:17, SAIFI wrote: > > > > > let's use a simple database, a CSV file for simplicity, and generate both > > files from this. > > Curious to learn, why wouldn't you want to do it in C++ itself ? > > As an example, please see > https://github.com/cplusplus/lib-issues-software

Re: [RFC] database with API information

> > let's use a simple database, a CSV file for simplicity, and generate both > files from this. Curious to learn, why wouldn't you want to do it in C++ itself ? As an example, please see https://github.com/cplusplus/lib-issues-software warm regards Saifi.

Re: [RFC] database with API information

n mentioned that he has to create and maintain a similar file for >> the module support. It needs to list all the exported interfaces and this >> is mostly a superset of the entries in the hint table. >> >> Instead of duplicating the information it should be kept in one p

Re: [RFC] database with API information

the module support. It needs to list all the exported interfaces and this > is mostly a superset of the entries in the hint table. > > Instead of duplicating the information it should be kept in one place. > Neither file itself is a natural fit because the additional information > ne

[RFC] database with API information

and this is mostly a superset of the entries in the hint table. Instead of duplicating the information it should be kept in one place. Neither file itself is a natural fit because the additional information needed (e.g., the standard version information for the name hint table) is not needed in

Re: [PATCH] gcov: fix file and function summary information

On 8/24/22 09:12, Jørgen Kvalsvik wrote: > I tested it and get the file summary as expected: > > File 'demo.cc' > Lines executed:84.62% of 26 > Branches executed:100.00% of 6 > Taken at least once:50.00% of 6 > Calls executed:100.00% of 4 > Creating 'demo.cc.gcov' > > Thanks, > Jørgen Great, I'v

Re: [PATCH] gcov: fix file and function summary information

On 22/08/2022 21:25, Martin Liška wrote: Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Jorgen: Can you please test it before I'll install it? Thanks, Martin gcc/ChangeLog: * gcov.cc (add_line_counts): Add group functions to coverage summary.

[PATCH] gcov: fix file and function summary information

Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Jorgen: Can you please test it before I'll install it? Thanks, Martin gcc/ChangeLog: * gcov.cc (add_line_counts): Add group functions to coverage summary. (accumulate_line_counts): Similarly for files

Save/Store information, which variable are not initialized

I known, IDE will detect cases, whereas variable is not initialized, but some developers still have problems with variable initialization. I suppose gcc do not support any run-time sanitizer, because I do not found any information. So: gcc will introduce hidden array of variables for each

Someone I have my own personal information my old personal data on my old Gmail all around my Samsung all account my Google Drive data AND YouTube channel personal URL number And My all domain name,s

Sent from my iPhone

Re: Dominance information problem

Erick, I assume that this needs to be done on all the functions since you mention "cfun". Gary From: Erick Ochoa Sent: Monday, September 14, 2020 12:10 AM To: Gary Oblock ; gcc@gcc.gnu.org Subject: Re: Dominance information problem [EXTERNAL EMAIL NO

Re: Dominance information problem

cally dominance information was not available for cfun. Also, you might also need to call: if (dom_info_available_p (CDI_DOMINATORS)) free_dominance_info (CDI_DOMINATORS); Just before your pass is done. These were some calls I needed to make in a different pass when I was working with dominators.

Dominance information problem

unc, loop, LI_ONLY_INNERMOST ) { size_t num_bbs = loop->num_nodes; basic_block *bbs = get_loop_body ( loop); // FAILS HERE!!! : stuff never reached How it's failing (in code from dominance.c) I'm guessing tells me the dominance information is messed up (unlikely) or need

Re: [EXT] Re: Mechanism to get at function information seems not to work

cc.gnu.org Subject: [EXT] Re: Mechanism to get at function information seems not to work External Email -- On Fri, 2020-01-03 at 23:02 +, Gary Oblock wrote: > I'm having some grief attempting to get at the local def

Re: Mechanism to get at function information seems not to work

On Fri, 2020-01-03 at 23:02 +, Gary Oblock wrote: > I'm having some grief attempting to get at the local definitions > in LTO (more about the options used later.) > > Here's the sequence of code in my optimization (part of attempt > at structure reorganization optimizations.) > > cgraph_nod

Mechanism to get at function information seems not to work

I'm having some grief attempting to get at the local definitions in LTO (more about the options used later.) Here's the sequence of code in my optimization (part of attempt at structure reorganization optimizations.) cgraph_node* node; FOR_EACH_FUNCTION_WITH_GIMPLE_BODY ( node) { tree d

Re: Information on Loop Blocking

On January 3, 2020 2:04:20 AM GMT+01:00, Gary Oblock wrote: >One of the engineers here at Marvel was experimenting, at the user >level, with GCC in a failed attempt >to get loop blocking to do loop blocking. Here's basically his >question. > > Exactly how does loop blocking work in GCC? > >I kno

Information on Loop Blocking

One of the engineers here at Marvel was experimenting, at the user level, with GCC in a failed attempt to get loop blocking to do loop blocking. Here's basically his question. Exactly how does loop blocking work in GCC? I know this must involve the polyhedral optimization code so an explanatio

Questions about where to find information on IPO state in GCC

IMPLE,RTL or SSA passes so I was wondering where to find information on this. The manual only seems to mention the pass manager and its interactions with passes for running them. Thanks, Nick

RE: COTS:[urgent]: [External]:Information required on security-related patches under Free Software Foundation

Hi Jonathan, Thank you for the information. Could you please provide me the point of contact from whom I can get the version details and updates. Thanks and Stay Secure, Dhanalakshmi Kumar Vulnerability Management Tata Consultancy Services | Contracted to Honeywell Desk:        +91

Re: COTS:[urgent]: [External]:Information required on security-related patches under Free Software Foundation

y fixes available in the installed version or post this > > ? > > > > Please provide us the URL where we can check all the new release notes > > available for this Application.(website URL) > > All the information you want can be found at https://gcc.gnu.org/ Although your version, "gcc-8 (SUSE Linux) 8.2.1 20180831" is provided by SUSE and you should probably be asking them for details of that version and any updates.

Re: COTS:[urgent]: [External]:Information required on security-related patches under Free Software Foundation

NU COMPILER COLLECTION > gcc-8 (SUSE Linux) 8.2.1 20180831 [gcc-8-branch revision 264010] > > > > Is there any security fixes available in the installed version or post this ? > > Please provide us the URL where we can check all the new release notes > available for this Ap

COTS:[urgent]: [External]:Information required on security-related patches under Free Software Foundation

-6746778032 Email: dhanalakshmi.ku...@honeywell.com<mailto:dhanalakshmi.ku...@honeywell.com> Disclaimer Notice Please do not email any confidential or privileged information that may violate export control rules as I'm NOT authorized to view Export Controlled Data.

Re: Improving GCC's line table information to help GDB

On Oct 16, 2019, Luis Machado wrote: > It seems, from reading the blog post about SFN's, that it was meant to > help with debugging optimized binaries. Indeed. Getting rid of the dummy jumps would be one kind of optimization, and then SFN might help preserve some of the loss of location info in

Re: Improving GCC's line table information to help GDB

On Wed, Oct 16, 2019 at 4:55 PM Luis Machado wrote: > > On 10/16/19 5:59 AM, Richard Biener wrote: > > I think that adding an extra jump is unwanted. Instead - if you disregard > > the single-source-line case - there's always the jump and the label we jump > > to which might/should get different

Re: Improving GCC's line table information to help GDB

worrying about the optimizer getting rid of them later on? Should we even worry about preserving such information for higher optimization levels?   Isn't it exactly what statement frontier notes have been invented for (and implemented) by Alexandre (cc-ed)?  Or am I confused and/or missing some

Re: Improving GCC's line table information to help GDB

On 10/16/19 5:59 AM, Richard Biener wrote: I think that adding an extra jump is unwanted. Instead - if you disregard the single-source-line case - there's always the jump and the label we jump to which might/should get different source locations. Like in one of the above cases: main () { in

Re: Improving GCC's line table information to help GDB

later on? Should we even worry about preserving such information for higher optimization levels? Isn't it exactly what statement frontier notes have been invented for (and implemented) by Alexandre (cc-ed)? Or am I confused and/or missing something here? Maciej I'm fresh to

Re: Improving GCC's line table information to help GDB

t preserving such > information for higher optimization levels? Isn't it exactly what statement frontier notes have been invented for (and implemented) by Alexandre (cc-ed)? Or am I confused and/or missing something here? Maciej

Re: Improving GCC's line table information to help GDB

dress by 5 to 0x4004c4 and > Line by -3 to 5 >[0x008c] Set column to 5 >[0x008e] Set is_stmt to 0 >[0x008f] Special opcode 131: advance Address by 9 to 0x4004cd > and Line by 0 to 5 >[0x0090] Set column to 3 >[0x0092] Set is_stmt to 1

Improving GCC's line table information to help GDB

2] Set is_stmt to 1 [0x0093] Special opcode 73: advance Address by 5 to 0x4004d2 and Line by -2 to 3 [0x0094] Advance PC by 5 to 0x4004d7 [0x0096] Extended opcode 1: End of Sequence Again, X marks the spot where we tell the debugger there is a line transition (from line 5 to li

Alert - New Payment Information

Hello You can get the last payment in your personal account. You need to react immediately or it will be deleted. Press Here To Acknowledge Your Payment Data Is Correct.   Registered email: g...@gnu.org User ID: 2Z905M2MJT Enjoy & please let me know if all is well. Have a Nice Day Angel

Alert - New Payment Information

Dear Customer You can get the last payment in your personal account. You have to address this immediately or it will be removed. Click Here To Verify Your Payment Information Is Correct.   Your account email: g...@gnu.org Customer ID: JV9EKZ5SU3 Enjoy & please let me know how yo

New Payment Information

Hi You could have the last payment in your trading account. You need to react immediately or it will be removed. Press Here To Acknowledge Your Payment Info Is Correct.   Registered email: g...@gnu.org Customer ID: 2Z905M2MJT Enjoy & please let me know how you do. Thanks! Maxwell   E

Re: alignof(type, field); sizeof(type, field); typeof(type, field): getting type information on nested field

On Tue, 2 Jul 2019 at 08:57, Yann Droneaud wrote: > > Hi, > > I'm sometime in need to "probe" the size, the type, (and less often the > alignment) of a field inside a structure. > > In such case I have to write "ugly" thing like > > struct A > { > struct > { > type_t t; > } B

alignof(type, field); sizeof(type, field); typeof(type, field): getting type information on nested field

Hi, I'm sometime in need to "probe" the size, the type, (and less often the alignment) of a field inside a structure. In such case I have to write "ugly" thing like struct A { struct { type_t t; } B; }; typeof(((struct A *)NULL)->B.t) V; It would have been some much p

Re: I want to know the information about the function arguments

On Wed, 2018-06-06 at 13:04 +0200, Martin Jambor wrote: > Hi, > > On Wed, Jun 06 2018, 冠人 王 via gcc wrote: > > When I modify the gcc source code, sometimes I do not know what > > parameters does the function call. > > For example, > > bool warn_if_unused_value(const tree exp,location_t locus){

Re: I want to know the information about the function arguments

Hi, On Wed, Jun 06 2018, 冠人 王 via gcc wrote: > When I modify the gcc source code, sometimes I do not know what parameters > does the function call. > For example,  > bool warn_if_unused_value(const tree exp,location_t locus){    function > declaration ... > } > I want to know what "exp" and "loc

I want to know the information about the function arguments

When I modify the gcc source code, sometimes I do not know what parameters does the function call. For example,  bool warn_if_unused_value(const tree exp,location_t locus){    function declaration ... } I want to know what "exp" and "locus" are by using fprintf such as fprintf(stderr,"%s\n%s\n",e

Re: Fwd: Is there a pass in GCC that provide us may alias information

On June 1, 2018 7:34:25 PM GMT+02:00, vineet singh wrote: >Hi, > >I want to know that whether GCC provides a pass that gives us "may >alias" >information and how we can access it? > >If yes, then is this may alias information available before and after >eac

Fwd: Is there a pass in GCC that provide us may alias information

Hi, I want to know that whether GCC provides a pass that gives us "may alias" information and how we can access it? If yes, then is this may alias information available before and after each pass of GCC? -- Regards Vineet Singh Master of Technology Department of Computer Science &a

Re: Have "gcc -v" print information about slow run-time checking?

On Fri, Oct 20, 2017 at 12:40 PM, Thomas Schwinge wrote: > Hi! > > In , we got a user wonder about released vs. > trunk GCC execution times, not knowing that the latter has more run-time > checking enabled. Once that got clarified, the discussion proceeded: > > (In re

Have "gcc -v" print information about slow run-time checking?

Hi! In , we got a user wonder about released vs. trunk GCC execution times, not knowing that the latter has more run-time checking enabled. Once that got clarified, the discussion proceeded: (In reply to petschy from comment #6) > Would it be sensible to put an extra

Re: [PATCH] Write dependency information (-M*) even if there are errors

Hi Boris, On Sat, Aug 12, 2017 at 05:53:44PM +0200, Boris Kolpackov wrote: > Segher Boessenkool writes: > > > Patches should go to gcc-patches. > > Ok, will keep in mind for future (seeing that we have a discussion > already it probably doesn't make sense to move this patch). Please do move it

Re: [PATCH] Write dependency information (-M*) even if there are errors

Boris Index: gcc/c-family/ChangeLog === --- gcc/c-family/ChangeLog (revision 250514) +++ gcc/c-family/ChangeLog (working copy) @@ -1,3 +1,8 @@ +2017-08-06 Boris Kolpackov + + * c-opts.c (c_common_finish): Write dependency informat

Re: [PATCH] Write dependency information (-M*) even if there are errors

Joseph Myers writes: > I suppose a question for the present proposal would be making sure any > dependencies generated in this case do not include dependencies on files > that don't exist (so #include "some-misspelling.h" doesn't create any sort > of dependency on such a header). Good point.

Re: [PATCH] Write dependency information (-M*) even if there are errors

gnostic machinery in cpplib. The description, regarding dependency information generation, in the original patch description <https://gcc.gnu.org/ml/gcc-patches/2009-02/msg00491.html>, is "the code in cpplib that checked for errors before deciding whether to write dependency output

Re: [PATCH] Write dependency information (-M*) even if there are errors

On 08/06/2017 01:59 AM, Boris Kolpackov wrote: > Hi, > > Currently GCC does not write extracted header dependency information > if there are errors. However, this can be useful when dealing with > outdated generated headers that trigger errors which would have been > resolved

Re: [PATCH] Write dependency information (-M*) even if there are errors

Hi! Patches should go to gcc-patches. Just a trivial remark: > --- gcc/c-family/c-opts.c (revision 250514) > +++ gcc/c-family/c-opts.c (working copy) > @@ -1152,8 +1152,11 @@ > { >FILE *deps_stream = NULL; > > - /* Don't write the deps file if there are errors. */ > - if (cpp_o

[PATCH] Write dependency information (-M*) even if there are errors

Hi, Currently GCC does not write extracted header dependency information if there are errors. However, this can be useful when dealing with outdated generated headers that trigger errors which would have been resolved if we could update it. A concrete example in our case is a version check with

Re: Lack of capability to represent arbitrary alias dependent information

ntime alias checks for data references in passes like >>>> vectorizer, it would be very useful to pass along the runtime alias >>>> dependent information to later passes. Given below expample: >>>> >>>> int foo (int *a, int *b, int *c, int *d, int *e,

Re: Lack of capability to represent arbitrary alias dependent information

, it would be very useful to pass along the runtime alias >>> dependent information to later passes. Given below expample: >>> >>> int foo (int *a, int *b, int *c, int *d, int *e, int len, int v) >>> { >>> int k, x; >>> for (k = 0; k <

Re: Lack of capability to represent arbitrary alias dependent information

On Mon, Jun 12, 2017 at 10:15 AM, Richard Biener wrote: > On Mon, Jun 12, 2017 at 11:02 AM, Bin.Cheng wrote: >> HI, >> GCC adds runtime alias checks for data references in passes like >> vectorizer, it would be very useful to pass along the runtime alias >> dependent

Re: Lack of capability to represent arbitrary alias dependent information

On Mon, Jun 12, 2017 at 11:02 AM, Bin.Cheng wrote: > HI, > GCC adds runtime alias checks for data references in passes like > vectorizer, it would be very useful to pass along the runtime alias > dependent information to later passes. Given below expample: > > int foo (int

Lack of capability to represent arbitrary alias dependent information

HI, GCC adds runtime alias checks for data references in passes like vectorizer, it would be very useful to pass along the runtime alias dependent information to later passes. Given below expample: int foo (int *a, int *b, int *c, int *d, int *e, int len, int v) { int k, x; for (k = 0; k

Re: LSDA unwind information is off by one (in __gcc_personality_v0)

On 10/20/2016 10:06 PM, Jim Wilson wrote: But I also see that while HAVE_GETIPINFO appears to be set by configure, it is apparently not being used when building unwind-c.o. I see that HAVE_GETIPINFO is set in the libgcc/auto-target.h file, but this file is not included by unwind-c.c. I only se

Re: LSDA unwind information is off by one (in __gcc_personality_v0)

On 10/21/2016 12:08 AM, Eric Botcazou wrote: We don't call _Unwind_GetIPInfo from __gcc_personality_v0 because HAVE_GETIPINFO is not defined. This happens only when using the system unwinder on ia64, if I'm not mistaken. Disassembly shows that the code is not compiled in and not part of libgcc_s

Re: LSDA unwind information is off by one (in __gcc_personality_v0)

> We don't call _Unwind_GetIPInfo from __gcc_personality_v0 because > HAVE_GETIPINFO is not defined. This happens only when using the system > unwinder on ia64, if I'm not mistaken. > > Disassembly shows that the code is not compiled in and not part of > libgcc_s.so.1, although _Unwind_GetIPInfo i

Re: LSDA unwind information is off by one (in __gcc_personality_v0)

On 10/20/2016 11:51 AM, Florian Weimer wrote: exception handling region. Subtracting 1 is an extremely hackish way to achieve that and likely is not portable at all. Gdb has been doing this for over 25 years for every architecture. When you use the backtrace command, it gets a return address

Re: LSDA unwind information is off by one (in __gcc_personality_v0)

On 10/20/2016 08:37 PM, Jeff Law wrote: Obviously if the PC value is actually pointing at the proper instruction, then the decrement is highly undesirable as it could put the adjusted PC into a different exception region. Yes, that's what's happening with the glibc bug. The question is how to

Re: LSDA unwind information is off by one (in __gcc_personality_v0)

On 10/20/2016 07:17 PM, Andreas Schwab wrote: On Okt 20 2016, Florian Weimer wrote: We have a fun little glibc bug which causes pthread_cond_wait to write out of bounds on i386: https://sourceware.org/bugzilla/show_bug.cgi?id=20719 Root cause is this in libgcc/unwind-c.c: 130 int ip

Re: LSDA unwind information is off by one (in __gcc_personality_v0)

On 10/20/2016 10:28 AM, Florian Weimer wrote: We have a fun little glibc bug which causes pthread_cond_wait to write out of bounds on i386: https://sourceware.org/bugzilla/show_bug.cgi?id=20719 Root cause is this in libgcc/unwind-c.c: 130 int ip_before_insn = 0; … 158 /* Pars

Re: LSDA unwind information is off by one (in __gcc_personality_v0)

On Okt 20 2016, Florian Weimer wrote: > We have a fun little glibc bug which causes pthread_cond_wait to write out > of bounds on i386: > > https://sourceware.org/bugzilla/show_bug.cgi?id=20719 > > Root cause is this in libgcc/unwind-c.c: > > 130 int ip_before_insn = 0; > … > 158

LSDA unwind information is off by one (in __gcc_personality_v0)

We have a fun little glibc bug which causes pthread_cond_wait to write out of bounds on i386: https://sourceware.org/bugzilla/show_bug.cgi?id=20719 Root cause is this in libgcc/unwind-c.c: 130 int ip_before_insn = 0; … 158 /* Parse the LSDA header. */ 159 p = parse_lsd

Re: does "assign_stack_local" from "function.h" automatically Do The Right Thing with debug information? [relates to the RTL-level if-conversion improvement project]

ebug". In at least many [if not all] such pairs, the file size is actually different. I wonder if "assign_stack_local" from "function.h" automatically Does The Right Thing with debug information? Especially, does it cause the debug information, if any, for stack-frame s

Re: Typecasting information in MEM[...] GIMPLE

On 07/28/2015 01:06 PM, Richard Biener wrote: As Jakub said this is not the full story if you factor in type-based aliasing. Also you of course have to account for the offset in operand 1. Okay. We understood the details after a bit of reading. For statement involving MEM[...], TREE_TYPE (

Re: Typecasting information in MEM[...] GIMPLE

On Mon, Jul 27, 2015 at 4:43 PM, Uday P. Khedker wrote: > > > Jakub Jelinek wrote on Monday 27 July 2015 03:50 PM: >> >> On Mon, Jul 27, 2015 at 03:35:45PM +0530, Uday Khedker wrote: >>> >>> We are interested in extracting the type of a tree node that appears >>> within >>> MEM_REF. >>> >>> Given

Re: Typecasting information in MEM[...] GIMPLE

Jakub Jelinek wrote on Monday 27 July 2015 03:50 PM: On Mon, Jul 27, 2015 at 03:35:45PM +0530, Uday Khedker wrote: We are interested in extracting the type of a tree node that appears within MEM_REF. Given a C program: struct node * * pvar; struct node qvar; pvar = (struct nod

Re: Typecasting information in MEM[...] GIMPLE

On Mon, Jul 27, 2015 at 12:20 PM, Jakub Jelinek wrote: > On Mon, Jul 27, 2015 at 03:35:45PM +0530, Uday Khedker wrote: >> We are interested in extracting the type of a tree node that appears within >> MEM_REF. >> >> Given a C program: >> >> struct node * * pvar; >> struct node qvar; >>

Re: Typecasting information in MEM[...] GIMPLE

On Mon, Jul 27, 2015 at 03:35:45PM +0530, Uday Khedker wrote: > We are interested in extracting the type of a tree node that appears within > MEM_REF. > > Given a C program: > > struct node * * pvar; > struct node qvar; > pvar = (struct node * *) malloc (sizeof (struct node *)); >

Typecasting information in MEM[...] GIMPLE

We are interested in extracting the type of a tree node that appears within MEM_REF. Given a C program: struct node * * pvar; struct node qvar; pvar = (struct node * *) malloc (sizeof (struct node *)); *pvar = &qvar; It is transformed into the following GIMPLE code: void *

  1   2   3   4   5   >