--- Comment #16 from dominiq at lps dot ens dot fr 2007-11-29 08:06 ---
A quick report of the comparison between the regression results for revision
130500 + patch in comment #5 + Tobias' patch for pr34262 and revision 130489 +
some patches applied to rev. 130500. I have the following
--- Comment #1 from ubizjak at gmail dot com 2007-11-29 08:09 ---
(In reply to comment #0)
b) gfortran -m32 -march=opteron -ffast-math -funroll-loops -ftree-vectorize
-ftree-loop-linear -O3
induct.f90: 61.41 [100%] vs 46.94 [ 76%]
test2.f90: 5.45 [100%] vs 4.54 [ 83%]
I have
--- Comment #1 from irar at il dot ibm dot com 2007-11-29 09:31 ---
I can't reproduce this failure with the same flags with revision 130403 on
ppc64-redhat-linux.
(Some loops indeed get vectorized in reload.c and reload1.c:
reload1.c.104t.vect:reload1.c:2433: note: LOOP VECTORIZED.
--- Comment #13 from ek dot kato at gmail dot com 2007-11-29 09:08 ---
Oops, I noticed the diff sent yesterday was broken. Here is the correct one
for the workaround.
Index: libgcc/Makefile.in
===
--- libgcc/Makefile.in
Here is my program inspired by Barnes' Ada 95 2nd book page 158:
--bug1.ads
package bug1 is
I : Integer := 0;
A: array(1.. 10) of Integer := (others = 0);
procedure Silly(X: in out Integer);
end bug1;
--bug1.adb
with Ada.Integer_Text_Io; use Ada.Integer_Text_Io;
package body bug1 is
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
Hi,
* Detailed description:
===
The file gcc/trunk/gnattools/configure.ac contains the definition of the
variable TOOLS_TARGET_PAIRS for each supported target. The x86-darwin case is
missing which results in using the default file mlib-tgt-specific.adb when
building GNAT for
--- Comment #4 from bauhaus at futureapps dot de 2007-11-29 10:25 ---
I expect that in the case described in the report (#0)
the compiler does not produce wrong code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33994
--- Comment #5 from bauhaus at futureapps dot de 2007-11-29 10:27 ---
BTW, I have named the procedure Too_Big for
a reason ... :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33994
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-29 10:28 ---
With __typeof__ instead of __decltype this ICEs already in 4.2.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-29 10:29 ---
I think return z is an access.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34282
A construct with char arrays within a struct incorrectly triggers
a buffer overflow warning.
testcase attached.
--
Summary: buffer overflow incorrectly detected
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
--- Comment #1 from marcus at jet dot franken dot de 2007-11-29 10:37
---
Created an attachment (id=14664)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14664action=view)
xx.i
gcc -O2 -Wall -c xx.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34285
--- Comment #18 from dominiq at lps dot ens dot fr 2007-11-29 10:22 ---
I have had a look at what's happening for kepler.f90 (from the 2004 polyhedron
test suite?) and it looks like another missed vectorization: if I count the
mulpd in the kepler.s files, I find 24 before the patch and
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-11-29 10:11
---
Doh, not only I missed to diff the chunk mentioned in comment #6, but I also
added the original unrolling pass, not the one only supposed to unroll inner
loops #)
So, change the passes.c hunk to
Index:
--- Comment #1 from bechir dot zalila at gmail dot com 2007-11-29 10:09
---
Created an attachment (id=14660)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14660action=view)
Ada spec
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34284
--- Comment #2 from bechir dot zalila at gmail dot com 2007-11-29 10:09
---
Created an attachment (id=14661)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14661action=view)
Ada package body
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34284
--- Comment #3 from bechir dot zalila at gmail dot com 2007-11-29 10:10
---
Created an attachment (id=14662)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14662action=view)
Ada library project file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34284
--- Comment #4 from bechir dot zalila at gmail dot com 2007-11-29 10:11
---
Created an attachment (id=14663)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14663action=view)
Patch to solve the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34284
--- Comment #5 from bechir dot zalila at gmail dot com 2007-11-29 10:17
---
I did not know that the attaching file to a bug report comes after the commit.
I reattached the files I gave as plain text in the bug report body.
Sorry :-)
--
bechir dot zalila at gmail dot com changed:
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-29 10:33 ---
Yes, I also think 'return z' is a load from z which cannot be optimized away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34282
--- Comment #19 from dominiq at lps dot ens dot fr 2007-11-29 10:40 ---
Richard,
I am not sure to understand your patch in comment #17. I have already in
gcc/passes.c (after your patch in comment #5):
NEXT_PASS (pass_merge_phi);
NEXT_PASS (pass_vrp);
NEXT_PASS
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-29 10:42 ---
__builtin___strncpy_chk (foo.a[0], line, 19, 10)
The issue comes down to folding of (char*)foo into foo.a[0], we should not be
doing that folding.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #3 from mueller at gcc dot gnu dot org 2007-11-29 10:47 ---
fortify_source=2 is supposed to reject it (only sizeof the struct member, not
the whole struct is allowed).
use fortify_source=1 or fix your broken code.
--
mueller at gcc dot gnu dot org changed:
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
When we compile an application loading Oracle client 9.2.0.4 from a dynamically
(dlopen) loaded library, we get a segmentation fault in teh exit method, at the
very end of the application. This does not happen when loading libclntsh.so
dynamically directly from teh main method, before starting the
--- Comment #6 from jakub at gcc dot gnu dot org 2007-11-29 11:07 ---
Fix has been already posted 3 days ago:
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01419.html
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from dominiq at lps dot ens dot fr 2007-11-29 11:00 ---
I have applied my interpretation of the first two changes in comment #17.
gfortran.dg/array_1.f90 still abort and induct.v3.f90 is still not vectorized.
The good news are that induct.f90 is still properly unrolled
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-11-29 11:00 ---
Yes, this looks invalid - but can we diagnose this at compile-time?
Also, from decl2.c:
/* Error on
namespace { struct A { static int i; }; }
int foo () { return
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-29 11:11 ---
Is this really a GCC issue?
Where is the crash? Use a debugger and see where the crash is.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from rguenther at suse dot de 2007-11-29 11:13 ---
Subject: Re: Missed optimizations
On Thu, 29 Nov 2007, dominiq at lps dot ens dot fr wrote:
Richard,
I am not sure to understand your patch in comment #17. I have already in
gcc/passes.c (after your patch in
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-29 11:14 ---
(In reply to comment #3)
use fortify_source=1 or fix your broken code.
The code is not broken as the person is accessing via the array via char and
not via a different type.
--
pinskia at gcc dot gnu dot org
--- Comment #22 from dominiq at lps dot ens dot fr 2007-11-29 11:16 ---
In top of the first two patches of comment #17, I have MOVED
+ NEXT_PASS (pass_tree_loop_init);
+ NEXT_PASS (pass_complete_unrolli);
+ NEXT_PASS (pass_tree_loop_done);
to the first suggested place.
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-29 11:25 ---
It is invalid for -D_FORTIFY_SOURCE=2.
-D_FORTIFY_SOURCE=1 allows all standard conforming code, -D_FORTIFY_SOURCE=2
imposes further restrictions (one is e.g. that %n for *printf arguments must be
only used in strings
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
Overview:
While trying to compile GCC with an old release of Mingw headers (2.4), I got
a stop in libcpp, trying to use ssize_t which was not typedef'd.
Steps to reproduce:
- grab an old-fashionned, non-POSIX, environment
- ./configure ./make all-gcc
- go out for lunch if the hardware
[Already posted on gcc-bugs mailing list sorry]
Here is my program inspired by Barnes' Ada 95 2nd book page 158:
--bug1.ads
package bug1 is
I : Integer := 0;
A: array(1.. 10) of Integer := (others = 0);
procedure Silly(X: in out Integer);
end bug1;
--bug1.adb
with Ada.Integer_Text_Io; use
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2007-11-29 11:25:01 |2007-11-29
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-11-29 11:29 ---
(In reply to comment #5)
family of functions not only can't overflow into some other object, but can't
overflow from one struct field into another
HUH There is no overflow from one struct field to another
--- Comment #12 from bonzini at gnu dot org 2007-11-29 11:43 ---
I think this should use find_comparison_args.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #7 from mueller at gcc dot gnu dot org 2007-11-29 11:47 ---
Andrew, read the comments or stop reopening. the behaviour is documented that
way even.
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from aldyh at gcc dot gnu dot org 2007-11-29 11:56 ---
I am testing this patch, and will post to gcc-patches when they finish.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33713
Hi,
When recompiling an Ada file (attachements p.ads p.adb) using -s option for
gnatmake. The object file is systemtically rebuild even if it is up-to-date and
if even the compiler flags have not changed.
* How to reproduce the bug:
===
INPUT FILES:
--- Comment #1 from bechir dot zalila at gmail dot com 2007-11-29 12:01
---
Created an attachment (id=14665)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14665action=view)
Ada package spec
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34289
--- Comment #2 from bechir dot zalila at gmail dot com 2007-11-29 12:01
---
Created an attachment (id=14666)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14666action=view)
Ada package body
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34289
Hello,
I have following compiler crash:
gcc -c main_windows-constructors.adb
+===GNAT BUG DETECTED==+
| 4.3.0 20071129 (experimental) (i686-pc-linux-gnu) Assert_Failure
exp_disp.adb:|
| Error detected at main_windows-constructors.adb:10:57
--- Comment #1 from vgodunko at rostel dot ru 2007-11-29 12:02 ---
Created an attachment (id=14667)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14667action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34290
--
vgodunko at rostel dot ru changed:
What|Removed |Added
Severity|normal |major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34290
--- Comment #23 from dominiq at lps dot ens dot fr 2007-11-29 12:24 ---
In top of the first two patches of comment #17, I have MOVED
+ NEXT_PASS (pass_tree_loop_init);
+ NEXT_PASS (pass_complete_unrolli);
+ NEXT_PASS (pass_tree_loop_done);
to the second suggested place.
.
Tested with gcc version 4.3.0 20071129 (experimental) (GCC) on Mac OS X 10.4.11
intel.
Index: libgfortran/io/list_read.c
===
--- libgfortran/io/list_read.c (revision 130508)
+++ libgfortran/io/list_read.c (working copy)
@@ -2646,6
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #1 from ek dot kato at gmail dot com 2007-11-29 13:18 ---
It turns out that my explanation and assumption about uninitialization was
wrong, but the real cause of the segmentation fault is that some functions call
free_line(dtp) without resetting line_buffer_enabled. Here is
--- Comment #2 from aldot at gcc dot gnu dot org 2007-11-29 13:27 ---
Can you please provide a testcase for the testsuite?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34291
Hi,
the following program does not compile. Omiting the data statement leads to a
compile without notice.
program bsp
INTEGER :: I,J
REAL ::X(2,2)=0.
!code compiles, if the following line is commented out.
DATA (( X(I,J), I=1,2), J=1,2) / 4*0. /
end program
--- Comment #6 from sam at gcc dot gnu dot org 2007-11-29 13:48 ---
Patch looks fine to me.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
In some of our methods, that are very long and fully inlined, we experience
hangs (infinite loops), that are automatically solved when we add a real
(non-inlined) call to any other function.
--
Summary: Hang because of extreme inlining
Product: gcc
Version:
We have several libraries that we load dynamically (dlopen), and from which we
use only one symbol, in which we use the same variable (char **) in the cpp
files. These symbols are never shared between libraries, but on this version
(4.2.1) of gcc, we experience big problems, because these homonym
--- Comment #3 from burnus at gcc dot gnu dot org 2007-11-29 14:57 ---
Subject: Bug 34262
Author: burnus
Date: Thu Nov 29 14:56:48 2007
New Revision: 130513
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130513
Log:
2007-11-29 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #3 from burnus at gcc dot gnu dot org 2007-11-29 15:01 ---
Jerry, libgfortran IO is your domain...
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2007-11-29 15:00 ---
Fixed on the trunk (4.3.0). I do not intent to backport the patch to 4.2.x and
4.1.x, but I can be convinced to do so.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-29 15:08 ---
This is an internal compiler error on invalid code.
REAL ::X(2,2)=0.
DATA (( X(I,J), I=1,2), J=1,2) / 4*0. /
You initialize the variable X twice, which is not allowed according to the
Fortran
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-29 15:14 ---
Created an attachment (id=14668)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14668action=view)
gcc43-pr33984.patch
I've tried to fix this by the attached patch.
standard_conversion also uses
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-29 15:31 ---
Testcase?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from dominiq at lps dot ens dot fr 2007-11-29 15:49 ---
I think I have now a partial understanding of what is happening for the induct
variants that do not vectorize with the patch in comment #5: they do not
contain any loop inside the k loop. If I replace
In an inlined method, we cast a double argument into an INT64 : with gcc4.2.1
(not with other versions or compilers), this gives a completely false result
that leads to a crash. To avoid this, we had to create an INT64 on the stach
and to memcpy the double into it, which is much less optimized...
The following code does not give a warning:
CHARACTER(2) FUNCTION ctbgt() RESULT(ctab)
END function ctbgt
Only if one removes either the RESULT or changes CHARACTER in, e.g., INTEGER a
warning is shown.
w/ RESULT and INTEGER:
warning: Function return value not set
w/o RESULT:
warning:
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-29 16:05 ---
I wanted to add that a possible reason for the character FUNCTION problem is
that the value is returned as argument and not as function return value:
test (__result, .__result)
--
--- Comment #6 from jakub at gcc dot gnu dot org 2007-11-29 16:21 ---
Subject: Bug 32130
Author: jakub
Date: Thu Nov 29 16:21:18 2007
New Revision: 130516
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130516
Log:
PR target/32130
* config/rs6000/eabi-cn.asm
--- Comment #2 from dvt at isoft dot fr 2007-11-29 16:26 ---
(In reply to comment #1)
Testcase?
No : As I said, this is a very big method. It is in a template and includes
other inlined template and non-template methods : it contains only inlined
functions. Thus, it is very difficult
--- Comment #7 from jakub at gcc dot gnu dot org 2007-11-29 16:28 ---
Tested today on x86_64-linux - powerpc-eabisim combined tree cross.
While without the patch, e.g. neither libgfortran nor libstdc++-v3 configures
successfully, with this patch it builds just fine. E.g. for make
Hi,
if you publish this email, please remove my email address from the posting.
Problem description:
gcc versions = 4.0 seem to optimize away strings.
Older versions seem to work.
For a more detailed description see below.
exact gcc versions containing the bug:
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-29 16:52 ---
We cannot do anything about such a report then. Sorry.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #123 from rguenth at gcc dot gnu dot org 2007-11-29 16:54
---
*** Bug 34295 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-29 16:54 ---
You are violating C aliasing rules. Use memcpy (as you did) or a union to
guard
the type punning.
*** This bug has been marked as a duplicate of 21920 ***
--
rguenth at gcc dot gnu dot org changed:
--- Comment #7 from andreasmeier80 at gmx dot de 2007-11-29 17:05 ---
It fails in 128121, works in 128079
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34253
--- Comment #2 from dvt at isoft dot fr 2007-11-29 17:09 ---
(In reply to comment #1)
You are violating C aliasing rules. Use memcpy (as you did) or a union to
guard
the type punning.
*** This bug has been marked as a duplicate of 21920 ***
Are-you sure? Were is the rule that
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-29 17:21 ---
The recommended (and optimized) way to do this is:
union {
INT64 i;
double d;
} x;
x.d = arg;
return x.i;
you can also make your way work optimized by specifying -fno-strict-aliasing.
That it works without
--- Comment #4 from steven at gcc dot gnu dot org 2007-11-29 17:23 ---
Try compiling with -fno-strict-aliasing. This is only automatically enabled at
-O2 or higher. See the fine manual.
I'm not sure what you mean with more efficient than memcpy. If you mean more
efficient as in
--- Comment #3 from burnus at gcc dot gnu dot org 2007-11-29 17:41 ---
Subject: Bug 34248
Author: burnus
Date: Thu Nov 29 17:41:37 2007
New Revision: 130517
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130517
Log:
2007-11-29 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #4 from burnus at gcc dot gnu dot org 2007-11-29 17:43 ---
FIXED on the trunk (4.3.0). I do not intent to backport the fix to 4.2.x or
4.1.x, but I can be convinced to do so.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-29 18:08 ---
Testcase? It might be because you are using global bindings for the shared
libraries.
Note this really cannot be a GCC bug as GCC does not do dynamic loading.
MSDEV, IBM XLC, have you tried GCC on Windows or AIX
--- Comment #2 from dvt at isoft dot fr 2007-11-29 18:16 ---
(In reply to comment #1)
Testcase? It might be because you are using global bindings for the shared
libraries.
Note this really cannot be a GCC bug as GCC does not do dynamic loading.
MSDEV, IBM XLC, have you tried GCC on
--- Comment #1 from tromey at gcc dot gnu dot org 2007-11-29 18:20 ---
The check in gcc/configure.ac defaults ssize_t to int if it isn't found.
But, we also need to do this in libcpp/configure.ac.
If I send you a patch, can you test it?
I will send a patch for configure as well.
--
--- Comment #19 from jakub at gcc dot gnu dot org 2007-11-29 18:39 ---
Have a modified patch which cures this, testing...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33434
--- Comment #2 from janis at gcc dot gnu dot org 2007-11-29 19:01 ---
I can reproduce the failure with revision 130507 on a p970 system. I compile
176.gcc with -m32 -O3 -maltivec and execute that benchmark program with test
input.
My list of vectorized loops is the same except that
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-11-29 19:27 ---
I still say GCC is incorrect here, even if I was drinking last night. This
should work as the whole struct is touched and not even looked at the one
field.
Even if the documentation says that, it is still bad
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-29 21:04 ---
Subject: Bug 34268
Author: jakub
Date: Thu Nov 29 21:04:04 2007
New Revision: 130519
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130519
Log:
PR c++/34267
PR c++/34268
* parser.c
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-29 21:04 ---
Subject: Bug 34267
Author: jakub
Date: Thu Nov 29 21:04:04 2007
New Revision: 130519
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130519
Log:
PR c++/34267
PR c++/34268
* parser.c
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-29 21:06 ---
Subject: Bug 34270
Author: jakub
Date: Thu Nov 29 21:06:18 2007
New Revision: 130520
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130520
Log:
PR c++/34270
* tree.c (lvalue_p_1) case COND_EXPR:
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-29 21:07 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-29 21:07 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-29 21:08 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #20 from jakub at gcc dot gnu dot org 2007-11-29 21:57 ---
Subject: Bug 33434
Author: jakub
Date: Thu Nov 29 21:57:38 2007
New Revision: 130521
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130521
Log:
PR tree-optimization/33434
* tree-inline.c
--- Comment #21 from jakub at gcc dot gnu dot org 2007-11-29 21:58 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from sam at gcc dot gnu dot org 2007-11-29 23:26 ---
Confirmed on SVN trunk
+===GNAT BUG DETECTED==+
| 4.3.0 20071129 (experimental) (i686-pc-linux-gnu) Assert_Failure
exp_disp.adb:|
| Error detected at main_windows
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-29 23:59 ---
This is really a bug in glibc and not GCC. Static linking never worked
correctly with pthreads anyways.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ek dot kato at gmail dot com 2007-11-30 01:11 ---
I can't provide a simple test case sorry, but I now realized that it seems to
be related that READ() for a namelist file ended with END instead of /
causes the problem.
I use a library which creates namelist file by
1 - 100 of 119 matches
Mail list logo
