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
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".
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
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
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)
>
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
I'm delta reducing this.
Toon, have you opened a bug, or do you want me to open the bug report?
Thanks,
Sebastian
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
On Thu, Aug 5, 2010 at 12:33 PM, Sebastian Pop wrote:
> Toon,
> From your backtrace it looks like a problem in LNO.
> Please submit a bug report and attach your testcase.
>
I saw
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
==23110== Invalid read of size 8
==23110==
Toon,
>From your backtrace it looks like a problem in LNO.
Please submit a bug report and attach your testcase.
Thanks,
Sebastian
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
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
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
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 expect to see
It is most likely that this bug is actually caused by one of the
modifications that you have made to the backend.
In 4.3, the rtl backend is very picky about the kinds of modifications
that can be made to insns and in particular the api's that are used to
modify, insert or delete insns or even w
On 05 June 2007 16:49, [EMAIL PROTECTED] wrote:
> 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
On Tue, 2007-06-05 at 11:49 -0400, [EMAIL PROTECTED] wrote:
> 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/g
"kernel coder" <[EMAIL PROTECTED]> writes:
>Thanks for your explaination.I just figured out the
> problem.actually a pattern named "bgtu" was generated by gcc and in
> my backend ,i defined all branch patterns except bgtu.So when gcc
> tried to match "bgtu" pattern ,it could not find it and g
hi,
Thanks for your explaination.I just figured out the
problem.actually a pattern named "bgtu" was generated by gcc and in
my backend ,i defined all branch patterns except bgtu.So when gcc
tried to match "bgtu" pattern ,it could not find it and generated
above mentioned error.Now i have define
On 30 August 2006 15:11, kernel coder wrote:
> 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/l
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
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
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
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
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
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
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.
On 02/28/06 18:42, FX Coudert wrote:
> Jakuk, Diego? Is this a bug or a feature? :)
>
Looks like a bug, but I'm not really sure what is causing it. I can
reproduce it with one of the tests in libgomp
(libgomp.fortran/appendix-a/a.16.1.f90), but I get a different trace:
-
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
questions to the gcc-help
Should I file a bug ?
I think it might be better to wait for the opinion of the gomp
maintainers, as I'm fairly new to that stuff and could have missed
something important.
Jakuk, Diego? Is this a bug or a feature? :)
Hum... for trunk on i686-linux, I do see the following. Dynamic
linkin
> 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-linux, I do see th
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
-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
> CVS head today. My o
33 matches
Mail list logo
