Re: Inconsistent segmentation fault in GCC

On Thu, 23 Dec 2021, 06:07 Alessandro Baretta via Gcc, wrote: > > How I might help diagnose and fix this bug? For instance, how does one > run gcc from inside gdb? I know that gcc is just the driver and > cc1plus is the actual compiler, so I presume I'd have to run cc1plus > inside gdb, but as fa

Re: Inconsistent segmentation fault in GCC

Andrew, Thank you for your kind reply. You alerted me to the fact that the bug I am seeing is likely limited to a version or a small range of versions of GCC. I have thus tinkered with my project's CMakeLists.txt and discovered the following: * The compiler was originally set to `gcc-11`, whereas

Re: Inconsistent segmentation fault in GCC

On Wed, Dec 22, 2021 at 5:07 PM Alessandro Baretta via Gcc wrote: > > Hello GCC hackers, and thank you very much for your precious work here. > > I've been observing somewhat random GCC segfaults in my C++ 20 > codebase for a while. By "random" I mean that if I rerun the cmake > build after a fail

Inconsistent segmentation fault in GCC

Hello GCC hackers, and thank you very much for your precious work here. I've been observing somewhat random GCC segfaults in my C++ 20 codebase for a while. By "random" I mean that if I rerun the cmake build after a failure, 75% out of the time it will succeed, and it might fail again the next tim

Re: [BUILDROBOT] arm-netbsdelf: "cc1: internal compiler error: Segmentation fault" during -fself-test triggered from forcibly_ggc_collect()

On Tue, 2017-03-21 08:46:50 -0600, Jeff Law wrote: > On 02/12/2017 03:57 PM, Jan-Benedict Glaw wrote: > > When building a cross-gcc using config_list.mk using r245361 (as both, > > a freshly built `build' compiler and as sources for the > > cross-compiler), my build robot fails (see > > http://too

Re: [BUILDROBOT] arm-netbsdelf: "cc1: internal compiler error: Segmentation fault" during -fself-test triggered from forcibly_ggc_collect()

On 02/12/2017 03:57 PM, Jan-Benedict Glaw wrote: Hi! When building a cross-gcc using config_list.mk using r245361 (as both, a freshly built `build' compiler and as sources for the cross-compiler), my build robot fails (see http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=696565). S

[BUILDROBOT] arm-netbsdelf: "cc1: internal compiler error: Segmentation fault" during -fself-test triggered from forcibly_ggc_collect()

test=/home/jbglaw/repos-configlist_mk/gcc/gcc/testsuite/selftests cc1: internal compiler error: Segmentation fault 0xaf7fdf crash_signal /home/jbglaw/repos-configlist_mk/gcc/gcc/toplev.c:333 0x6739b3 lookup_page_table_entry /home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-page.c:635 0x6739b3 ggc_set

Re: Segmentation fault with unique_ptr

13.02.2015 16:04, tassos_souris writes: > Compile with: g++-4.9 -std=c++14 -g -o main main.cpp > and run with ./main. I get segfault. gdb in bt shows that the segfault > happens inside unique_ptr destructor. So it is not a memory issue. > Also since the code runs with less size (i.e size=1000 no p

Re: segmentation fault with fclose

Try the "comp.lang.c.moderated" group for C and C library questions. You probably meant: if( fp != NULL ) fclose( fp ); That is, "!= NULL" rather than "== NULL".

Re: segmentation fault with fclose

On 20 March 2011 22:47, bd satish wrote: > Hi, > > I'm trying to close a file using fclose, but the following program seg-faults: > > > #include > > int main(void) > { >    FILE* fp = fopen("unfounded.txt", "r"); > >    if(fp == NULL) >        fclose(fp); > >    return 0; > } > > > The file I'm tr

segmentation fault with fclose

Hi, I'm trying to close a file using fclose, but the following program seg-faults: #include int main(void) { FILE* fp = fopen("unfounded.txt", "r"); if(fp == NULL) fclose(fp); return 0; } The file I'm trying to open doesn't exist in the directory, so fp is indeed NULL.

Re: gcc 4.5.2-6 - internal compiler: Segmentation fault

On 02/13/2011 01:31 AM, Eric Botcazou wrote: >> I figured if I knew what was needed before opening the bug it would cut >> down on the need-info requests. Thanks. > > The instructions are available on the http://gcc.gnu.org/bugs/ page. > Thank you Eric, I've tried to include everyt

Re: gcc 4.5.2-6 - internal compiler: Segmentation fault

> I figured if I knew what was needed before opening the bug it would cut > down on the need-info requests. Thanks. The instructions are available on the http://gcc.gnu.org/bugs/ page. -- Eric Botcazou

gcc 4.5.2-6 - internal compiler: Segmentation fault

Guys, I need some help on what information will be wanted with the bug report for the following Segmentation fault encountered when compiling Trinity on Arch Linux with gcc 4.5.2-6? I haven't encountered a gcc segfault before, so I'm not quite sure what will be needed. The erro

Re: Segmentation fault for the following Fortran program at -O3 on x86-64.

Sebastian Pop wrote: On Thu, Aug 5, 2010 at 15:17, Sebastian Pop wrote: On Thu, Aug 5, 2010 at 15:07, Sebastian Pop wrote: I'm delta reducing this. Reduced it looks like this, and it seems like the bug is in the loop distribution for memset zero changes. parameter(numlev=3,numob

Re: Segmentation fault for the following Fortran program at -O3 on x86-64.

On Thu, Aug 5, 2010 at 15:17, Sebastian Pop wrote: > On Thu, Aug 5, 2010 at 15:07, Sebastian Pop wrote: >> I'm delta reducing this. > > Reduced it looks like this, and it seems like the bug is in the loop > distribution > for memset zero changes. > >      parameter(numlev=3,numoblev=1000) >      

Re: Segmentation fault for the following Fortran program at -O3 on x86-64.

On Thu, Aug 5, 2010 at 15:07, Sebastian Pop wrote: > I'm delta reducing this. Reduced it looks like this, and it seems like the bug is in the loop distribution for memset zero changes. parameter(numlev=3,numoblev=1000) integer i_otyp(numoblev,numlev), i_styp(numoblev,numlev) lo

Re: Segmentation fault for the following Fortran program at -O3 on x86-64.

I'm delta reducing this. Toon, have you opened a bug, or do you want me to open the bug report? Thanks, Sebastian

Re: Segmentation fault for the following Fortran program at -O3 on x86-64.

On Thu, Aug 5, 2010 at 15:00, H.J. Lu wrote: > I saw > ==23110==    by 0xAA5809: tree_loop_distribution > (tree-loop-distribution.c:1199) Mine. Thanks for running the trace, Sebastian

Re: Segmentation fault for the following Fortran program at -O3 on x86-64.

oc'd or (recently) free'd ==23110== inv_dee_main.f: In function ‘inv_dee_main’: inv_dee_main.f:1:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. ==23110== -- H.J.

Re: Segmentation fault for the following Fortran program at -O3 on x86-64.

Toon, >From your backtrace it looks like a problem in LNO. Please submit a bug report and attach your testcase. Thanks, Sebastian

Segmentation fault for the following Fortran program at -O3 on x86-64.

experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20100805 (experimental), GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Program received signal SIGSEGV, Segmentation fault. find_uses_t

Re: Segmentation fault when calling a library fun - GCC bug?

Mohamed Shafi writes: > After analyzing the issue i find that this might be a bug. I just want > to confirm if that is the case or not. > In order to reproduce i think the target should have the following properties > a. Only 2 32bit registers available as argument registers. > b. Second 64bit va

Segmentation fault when calling a library fun - GCC bug?

I am doing a port for a 32bit target in GCC 4.4.0 I am getting segmentation fault in the function assign_temp in the following line: if (DECL_P (type_or_decl)) After analyzing the issue i find that this might be a bug. I just want to confirm if that is the case or not. In order to reproduce i

Re: [lambda] Segmentation fault in simple lambda program

On Thu, Aug 6, 2009 at 6:27 AM, Adam Butcher > wrote: I take you're point on [finish_struct_1] potentially being overkill but at least it means that user programs that copy can work. Right. I only added that comment so that other developers who come along

Re: [lambda] Segmentation fault in simple lambda program

Adam Butcher wrote: >John Freeman wrote: >> >> I just inspected my code again. The call to layout_class_type at the >> beginning of finish_lambda_function_body at semantics.c:5241 was >> intended to recalculate offsets to members in the case of default captures. >> >> Here is the complete order of

Re: [lambda] Segmentation fault in simple lambda program

John Freeman wrote: +/* relayout again -- to allow for implicit + * parameters to have been added to the capture if it was a + * 'default capture' -- note that this would not be necessary if + * the stack-pointer variant was implemented -- since the layout + * would be known

Re: [lambda] Segmentation fault in simple lambda program

Jason Merrill wrote: Incidentally, how does it work to just move the existing call of finish_struct to after we parse the body? I don't see why we need it to be complete while we're in the body. When I was working on it, there were some checks to make sure the class was complete. I can't re

Re: [lambda] Segmentation fault in simple lambda program

Jason Merrill wrote: On 08/04/2009 10:17 AM, John Freeman wrote: Reiterating, to allow more freedom in implementation, we can just say it "behaves as" a template, rather than "is" a template. I don't see the difference. As long as they work the same, the compiler is free to do whatever it wa

Re: [lambda] Segmentation fault in simple lambda program

On 08/03/2009 09:39 PM, John Freeman wrote: * Instead of transforming: * * [&] { i = 1; j = 2; k = 3; }; * * into * * [&i,&j,&k] { i = 1; j = 2; k = 3; }; * * and thus storing three pointers to int, transform it into: * * [sp=enclosing-stack-pointer] { var-from-stack(i,sp) = 1; * var-from-stack(j

Re: [lambda] Segmentation fault in simple lambda program

On 08/04/2009 10:17 AM, John Freeman wrote: Reiterating, to allow more freedom in implementation, we can just say it "behaves as" a template, rather than "is" a template. I don't see the difference. As long as they work the same, the compiler is free to do whatever it wants internally. Jaso

Re: [lambda] Segmentation fault in simple lambda program

On 08/04/2009 04:52 AM, Adam Butcher wrote: Yes sorry about that. I appreciate the issue. I had taken a branch of trunk and applied the lambda changes to it to keep only lambda changes on my working branch (allowing simpler future rebaseing). There were a number of things I had to change to

Re: [lambda] Segmentation fault in simple lambda program

Jason Merrill wrote: On 08/04/2009 09:35 AM, John Freeman wrote: In my opinion, lambdas are not intended as just a shortcut to writing a function object class. This is why our proposal did not require that lambdas be implemented as classes; it is simply one implementation. (Awaiting word to see

Re: [lambda] Segmentation fault in simple lambda program

On 08/04/2009 09:35 AM, John Freeman wrote: In my opinion, lambdas are not intended as just a shortcut to writing a function object class. This is why our proposal did not require that lambdas be implemented as classes; it is simply one implementation. (Awaiting word to see if this is still the

Re: [lambda] Segmentation fault in simple lambda program

Adam Butcher wrote: Hopefully. From my point of view the class generated by a lambda expression should be equivalent to something you could write yourself -- aside from the single stack-pointer reference optimization which only a compiler could achieve -- the class has a name, albeit invisibl

Re: [lambda] Segmentation fault in simple lambda program

Hi Jason, Pending response from assign at gnu dot org, I've attached diffs made against your latest lambda head. They are cleaned up a little to from the previous diffs against trunk. First is the re-layout fix, second is experimental polymorphic lambda support. Cheers, Adam 0001-Re-laid-ou

Re: [lambda] Segmentation fault in simple lambda program

Jason Merrill wrote: > On 08/03/2009 09:36 PM, Adam Butcher wrote: >> Thanks. I haven't any copyright assignments on file -- this is my first >> dabbling with gcc and I've been doing it >> mostly to experiment with C++ lambda support and non-standard extensions >> such as polymorphic lambda supp

Re: [lambda] Segmentation fault in simple lambda program

I haven't been following GCC, so I need to thank Jason for forwarding this issue to me. I just read through the messages on the list, and had some more comments: +/* relayout again -- to allow for implicit + * parameters to have been added to the capture if it was a + * 'default ca

Re: [lambda] Segmentation fault in simple lambda program

Jason Merrill wrote: Experimenting with a working version and seeing it's issues will be useful to me. To others to maybe. With concepts gone from C++0x and being reworked for C++15(?) maybe support for polymorphic lambdas could be reintroduced? -- though I'm sure its much too late for that an

Re: [lambda] Segmentation fault in simple lambda program

On 08/03/2009 09:36 PM, Adam Butcher wrote: Thanks. I haven't any copyright assignments on file -- this is my first dabbling with gcc and I've been doing it mostly to experiment with C++ lambda support and non-standard extensions such as polymorphic lambda support. OK. We'll need an assignm

Re: [lambda] Segmentation fault in simple lambda program

On 07/29/2009 06:27 AM, Adam Butcher wrote: Esben Mose Hansen writes: I am completely new to gcc hacking, just dying to get lambda into gcc 4.5 :) Me too on both counts! Great! Please feel free to ask me any questions you have directly. Do you have copyright assignments on file yet? I

Re: [lambda] Segmentation fault in simple lambda program

Adam Butcher wrote: Hi Esben Mose Hansen writes: this program SEGFAULTs #include int main() { int numbers[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 }; const std::size_t nn = sizeof(numbers)/sizeof(int); int sum = 0; int f = 5; std::for_each(&numbers[0], &numbers[nn], [&] (int n) {

Re: [lambda] Segmentation fault in simple lambda program

Hi Esben Mose Hansen writes: > this program SEGFAULTs > > #include > > int main() { > int numbers[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 }; > const std::size_t nn = sizeof(numbers)/sizeof(int); > int sum = 0; > int f = 5; > std::for_each(&numbers[0], &numbers[nn], [&] (int n) { > sum +=

Re: [lambda] Segmentation fault in simple lambda program

On Thursday 30 April 2009 19:19:31 you wrote: > When I try to specify the capture it works ((&sum, &f) works too but f is > const): > > #include > > int > main(void) > { > int numbers[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 }; > const std::size_t nn = sizeof(numbers)/sizeof(int); > int sum = 0; >

Re: [lambda] Segmentation fault in simple lambda program

Esben Mose Hansen writes: > this program SEGFAULTs > > #include > > int main() { > int numbers[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 }; > const std::size_t nn = sizeof(numbers)/sizeof(int); > int sum = 0; > int f = 5; > std::for_each(&numbers[0], &numbers[nn], [&] (int n) { > sum +=

Re: [lambda] Segmentation fault in simple lambda program

Esben Mose Hansen writes: > this program SEGFAULTs > > #include > > int main() { > int numbers[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 }; > const std::size_t nn = sizeof(numbers)/sizeof(int); > int sum = 0; > int f = 5; > std::for_each(&numbers[0], &numbers[nn], [&] (int n) { > sum +=

[lambda] Segmentation fault in simple lambda program

Hi, this program SEGFAULTs #include int main() { int numbers[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 }; const std::size_t nn = sizeof(numbers)/sizeof(int); int sum = 0; int f = 5; std::for_each(&numbers[0], &numbers[nn], [&] (int n) { sum += n * f; }); } Now, my assembly days are

Re: Creating own Backend: Segmentation fault in mark_jump_label_1

Joe Buck <[EMAIL PROTECTED]> writes: > On Wed, Aug 20, 2008 at 06:31:11AM -0700, Ian Lance Taylor wrote: >> Writing your own gcc backend requires digging into the code and >> figuring it out. It's not simple. We can't answer precise and >> detailed questions about how it is supposed to work, but

Re: Creating own Backend: Segmentation fault in mark_jump_label_1

On Wed, Aug 20, 2008 at 06:31:11AM -0700, Ian Lance Taylor wrote: > Writing your own gcc backend requires digging into the code and > figuring it out. It's not simple. We can't answer precise and > detailed questions about how it is supposed to work, but we can't help > you debug it. I think you

Re: Creating own Backend: Segmentation fault in mark_jump_label_1

Balthasar Biedermann <[EMAIL PROTECTED]> writes: > #0 0x081c5d48 in mark_jump_label_1 (x=0x0, insn=0xb7b77118, in_mem=0 > '\0', is_target=0 '\0') at ../.././gcc/jump.c:987 > #1 0x081c60e0 in mark_jump_label_1 (x=0xb7b70e28, insn=0xb7b77118, > in_mem=0 '\0', is_target=0 '\0') at ../.././gcc/jump.

Re: Creating own Backend: Segmentation fault in mark_jump_label_1

Ben Elliston schrieb: > Perhaps you could get a stack backtrace and try to understand why you're > getting a NULL_RTX passed in? I already made a stack backtrace and posted it in my first mail: Program received signal SIGSEGV, Segmentation fault. 0x081c5d48 in mark_jump_label_1 (

Re: Creating own Backend: Segmentation fault in mark_jump_label_1

> > The Error occures in mark_jump_label_1. It is called with a null pointer > > as the rtx x. > > Does nobody have an idea why or where the error occures? I really start > to became desperate. I'm sure plenty of people have an idea of why the error occurs. However, you need to be clearer in expl

Re: Creating own Backend: Segmentation fault in mark_jump_label_1

Balthasar Biedermann schrieb: > I create a gcc-backend. I have already created the *.md, *.h and *.c > files and I have compiled the gcc which includes backend. > > But when I try to compile a simple c-File with my gcc I get a > Segmentation fault. I tried to debug it but I don&

Creating own Backend: Segmentation fault in mark_jump_label_1

Hello everybody, I create a gcc-backend. I have already created the *.md, *.h and *.c files and I have compiled the gcc which includes backend. But when I try to compile a simple c-File with my gcc I get a Segmentation fault. I tried to debug it but I don't get the point. The Error occur

Re: Segmentation fault in df-scan.c

On Sun, 20 Jan 2008, Kenneth Zadeck wrote: > If you > build your compiler with --enable-checking=df,yes (basically add "df" > onto what ever you normally set for --enable-checking) it will check that > there have been no unauthorized changes to any instructions after > every rtl pass. For the reco

Re: Segmentation fault in df-scan.c

However,making this simpler works: rtx tmp_reg_rtx = copy_to_mode_reg (QImode,gen_rtx_MEM (QImode, addr1)); emit_move_insn (addr1, gen_rtx_PLUS (Pmode, addr1, const1_rtx)); aka Rx=[Ry] Ry=Ry+1 For now I have gone back to the second case, though the code is not quite as good. When your patter

Re: Segmentation fault in df-scan.c

Alas, enable-checking produced no different result or additional warnings or errors (though it might help me in the future!) I have a work around but don't fully understand why a define_expand should have caused segmentation fault. I believe the issue might be that gcse does not expe

Re: Segmentation fault in df-scan.c

s generally the problem. Kenny > While working on a Cygwin/AVR backend patch, I had segmentation fault > occur in df-scan.c - which appears unrelated to target. > I can't provide testcase as backend is modfied - but source was 2003-1.c > > It all happens i

Segmentation fault in df-scan.c

While working on a Cygwin/AVR backend patch, I had segmentation fault occur in df-scan.c - which appears unrelated to target. I can't provide testcase as backend is modfied - but source was 2003-1.c It all happens in df_scan.c (Rev 130805 14 Dec 2007) df_ref_create_structure() tr

RE: internal compiler error: Segmentation fault

kernel32!BaseProcessStart 0:000> p ntdll!KiUserApcDispatcher+0x1a: `77ef30aa e861dd callntdll!NtContinue (`77ef0e10) 0:000> k Child-SP RetAddr Call Site `0022fab0 `77d59620 ntdll!KiUserApcDispatcher+0x1a `0022ffa8 000

RE: internal compiler error: Segmentation fault

Hi, "J. Finch" wrote on 10.01.2008 16:31:38: Thank you very much for your dumps, but you should use on runtime the option '-dH' option to enforce that you reach the point, where the exception is caused. > stack before and after segmentation fault is as: > &g

RE: internal compiler error: Segmentation fault

Hi, stack before and after segmentation fault is as: .. .. ntdll!KiUserApcDispatcher+0x15: `77ef30a5 488bcc mov rcx,rsp 0:000> p ntdll!KiUserApcDispatcher+0x18: `77ef30a8 b201mov dl,1 0:000> k Child-SP RetAddr Cal

RE: internal compiler error: Segmentation fault

f90: In function 'MAIN__': c.f90:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. ntdll!ZwTerminateProcess+0xa: `77ef0caa c3 ret 0:000> kb *** ERROR: Symbol file could not be foun

RE: internal compiler error: Segmentation fault

word ptr [rsp+30h] > ss:`0022fa00= > 0:000> p > ntdll!CsrCaptureMessageBuffer+0x4b6: > `77ed5876 e95c4c0200 jmp ntdll!wcsrchr+0x197 > (`77efa4d7) > 0:000> p > ntdll!wcsrchr+0x197: > `77efa4d7 e8e476 call

Re: internal compiler error: Segmentation fault

> To have a better chance to find the issue could you anwser these question? I'll let J. answer these himself, since I have no direct experience of the bug myself (no Win64 machine), but... > a) Does this happens on a cross compiler, too? I doubt it, since he sees the bug even on trivial program

Re: internal compiler error: Segmentation fault

> [for [EMAIL PROTECTED] and [EMAIL PROTECTED] readers, seeshort thread > starting at http://gcc.gnu.org/ml/fortran/2008-01/msg00103.html] > > > Gcc gets the similar problem. It only works without optimization. > It seems not a problem with gfortran. > > OK, then it'd be more appropriate to ask

Re: internal compiler error: Segmentation fault

[for [EMAIL PROTECTED] and [EMAIL PROTECTED] readers, seeshort thread starting at http://gcc.gnu.org/ml/fortran/2008-01/msg00103.html] > Gcc gets the similar problem. It only works without optimization. It seems > not a problem with gfortran. OK, then it'd be more appropriate to ask the mingw m

RE: segmentation fault

gcc-4.2.0/gcc/tsystem.h:53: internal compiler error: > Segmentation fault. > > Lines 52-54 of tsystem.h are: > > #ifndef malloc > extern void *malloc (size_t); > #endif > > If I remove these lines, all the other extern statements fail also. > What precisely does Segme

Re: segmentation fault

> /cygdrive/c/gcc-4.2.0/gcc/tsystem.h:53: internal compiler error: Segmentation > fault. It is probably Cygwin that is reporting the segmentation fault. If you're a Windows user, this term refers to a memory access fault due to accessing an unmapped address or de-referencing the null

segmentation fault

With apologies for being new: In porting a hardware configuration from gcc-3.4.1 to gcc-4.2.0, I'm getting the following error message: In file included from /cygdrive/c/gcc-4.2.0/gcc/crtstuff.c:68: /cygdrive/c/gcc-4.2.0/gcc/tsystem.h:53: internal compiler error: Segmentation fault. Lines

Re: build error: gcc/gcc/gimplify.c:424: internal compiler error: Segmentation fault

Daniel Franke wrote: SVN revision: 118109 Try 118110 Andreas

build error: gcc/gcc/gimplify.c:424: internal compiler error: Segmentation fault

.c -o gimplify.o ../../gcc/gcc/gimplify.c: In function 'create_tmp_var_name': ../../gcc/gcc/gimplify.c:424: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate.

Re: segmentation fault in building __floatdisf.o

uot;bgtu" pattern ,it could not find it and generated > above mentioned error.Now i have defined that pattern and it is > compiling without any error. It should not have gotten a segmentation fault in that case. Something odd is still happening. > It was by luck that i figured out tha

Re: segmentation fault in building __floatdisf.o

he error is > > ../../gcc-4.1.0/gcc/libgcc2.c: In function '__floatdisf': > ../../gcc-4.1.0/gcc/libgcc2.c:1354: internal compiler error: Segmentation > fault This is always the first sign of a bug in your backend, as it's the first bit of code that gets compiled for the

RE: segmentation fault in building __floatdisf.o

floatdisf': > ../../gcc-4.1.0/gcc/libgcc2.c:1354: internal compiler error: Segmentation > fault This is always the first sign of a bug in your backend, as it's the first bit of code that gets compiled for the target by the newly-compiled backend. In this case, it's a

segmentation fault in building __floatdisf.o

hi, I'm having some problem during build up of libgcc2 in function __floatdisf(build up of __floatdisf.o).Actually i'm modifying mips backend.The error is ../../gcc-4.1.0/gcc/libgcc2.c: In function '__floatdisf': ../../gcc-4.1.0/gcc/libgcc2.c:1354: internal compiler error

ofdstream.h and segmentation fault

using namespace std; int main() { int fd = open("a.log", O_WRONLY|O_CREAT, 0600); if (fd < 0) { cerr << "open error" << endl; exit(1); } ofdstream ofs(fd); ofs << "testtest" << flush; close(fd); return 0;

Re: Segmentation fault in openmp simple routine from libgomp testsuite.

On Mar 10, 2006, at 3:14 PM, Andrew Pinski wrote: And it turned out I was correct in saying libstdc++ is also effected. See PR 26633. So this is not a libfortran specific issue any more. Actually that turned out to the TLS not be updated correctly for threads issue with static linking problem

Re: Segmentation fault in openmp simple routine from libgomp testsuite.

On Mar 7, 2006, at 6:31 PM, Andrew Pinski wrote: I bet the same issue now will happen with libstdc++ (and in 4.1.0 in fact). I want to say the weak references is the wrong way of doing things for non shared libraries. And it turned out I was correct in saying libstdc++ is also effected. S

Re: Segmentation fault in openmp simple routine from libgomp testsuite.

On Mar 7, 2006, at 6:12 PM, FX Coudert wrote: The only sure-fire fix I can think of is to actually build two static versions of libgfortran -- one threaded and one not threaded. I'm not sure this is worth the effort, really. I'd be more inclined to put a couple of checks in such that the stati

Re: Segmentation fault in openmp simple routine from libgomp testsuite.

On Wed, Mar 08, 2006 at 12:12:24AM +0100, FX Coudert wrote: > Hum, there are some platforms where libgfortran (and other target > libraries) cannot be built as shared libraries. i386-mingw32 is an > example of that. We've been careful until now to keep static > libgfortran working even as a stat

Re: Segmentation fault in openmp simple routine from libgomp testsuite.

The only sure-fire fix I can think of is to actually build two static versions of libgfortran -- one threaded and one not threaded. I'm not sure this is worth the effort, really. I'd be more inclined to put a couple of checks in such that the static libgfortran only runs non-threaded, and force p

Re: Segmentation fault in openmp simple routine from libgomp testsuite.

On Tue, Mar 07, 2006 at 12:34:05PM -0500, Diego Novillo wrote: > #0 0x in ?? () > #1 0x0804d112 in find_unit_1 (n=6, do_create=1) The problem here is a combination of factors: static linking and weak symbol references via gthr.h. The direct cause is that pthread_mutex_trylock isn't pull

Re: Segmentation fault in openmp simple routine from libgomp testsuite.

On Tue, Mar 07, 2006 at 12:34:05PM -0500, Diego Novillo wrote: > Richard mentioned similar problems with broken libc versions that > wouldn't initialize TLS properly, but this particular one doesn't seem > related. Richard, any ideas? Huh. No, this one doesn't look like the failure I had before.

Re: Segmentation fault in openmp simple routine from libgomp testsuite.

s -lgomp -L/i686-pc-linux-gnu/./libgomp/../libgfortran/.libs -lgfortranbegin -lgfortran -lm -o ./a.16.1.exe -static $ ./a.16.1.exe Segmentation fault (core dumped) $ gdb ./a.16.1.exe core.23910 [ ... ] Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0x

RE: Segmentation Fault (core dump)

On 07 March 2006 15:38, Neeta Kale wrote: > I am running a program which is compiled using GCC > 2.95.3. When I run the program, I get the following > error : > Segmentation Fault (core dumped) Your program is almost certainly buggy. Please send general how-to-program question

Segmentation Fault (core dump)

I am running a program which is compiled using GCC 2.95.3. When I run the program, I get the following error : Segmentation Fault (core dumped) When i use the gdb debugger to find the issue, it gives the following information : (gdb) break main Breakpoint 1 at 0x7aad4: file Test.cpp, line 7

Re: Segmentation fault in openmp simple routine from libgomp testsuite.

fortran -fopenmp omp_hello.f -static -lgomp -lrt && OMP_NUM_THREADS=2 ./a.out zsh: segmentation fault OMP_NUM_THREADS=2 ./a.out And the backtrace is: Program received signal SIGSEGV, Segmentation fault. 0x08048466 in initialize_team () at ../../../gcc/libgomp/config/posix/sem.h:75 75

Re: Segmentation fault in openmp simple routine from libgomp testsuite.

> I might be missing out on something but I get a segmentation fault when > manualy executing omp_hello.f from libgomp testsuite > (libgomp/testsuite/libgomp.fortran/omp_hello.f)... > > Compiled using gfortran -static -fopenmp -g omp_hello.f -o omp_hello Hum... for trunk on i686-

Re: Segmentation Fault building GCC for i686-pc-mingw32

Correlating the stacktrace with CVS revealed that this was fixed a few hours after I updated. The bug was 23929. Ranjit, thanks for the help getting the debugger going. TJ

Re: Segmentation Fault building GCC for i686-pc-mingw32

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 TJ Laurenzo wrote: > I'm getting a segmentation fault in the GCC build from today's CVS > HEAD. I am building the suite for mingw using a cross compiler from > Linux. This setup was working fine prior to updating to the latest &g

Segmentation Fault building GCC for i686-pc-mingw32

I'm getting a segmentation fault in the GCC build from today's CVS HEAD. I am building the suite for mingw using a cross compiler from Linux. This setup was working fine prior to updating to the latest CVS head today. My old sources, which were working correctly, were from 9/1/2005