--- Comment #7 from pault at gcc dot gnu dot org 2007-11-30 07:49 ---
(In reply to comment #5)
> Erik, Paul, as authors of the original patch and testcases, can you confirm my
> conclusion that the code in comment #4 (and thus, the
> gfortran.dg/alloc_comp_constructor_1.f90 testcase) is
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-30 07:26 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Summary|
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-30 07:25 ---
Subject: Bug 34275
Author: jakub
Date: Fri Nov 30 07:24:54 2007
New Revision: 130533
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130533
Log:
PR c++/34275
* error.c (dump_expr): Handle OBJ_TY
--- Comment #11 from jakub at gcc dot gnu dot org 2007-11-30 07:20 ---
Fixed, thanks.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #4 from bonzini at gnu dot org 2007-11-30 07:17 ---
So -fvect-cost-model is doing its job. The vectorizations must not be
profitable, or are they?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32086
--- Comment #1 from dweatherford at facebook dot com 2007-11-30 07:00
---
Created an attachment (id=14669)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14669&action=view)
Reduced test case
The two branches of the '#if' should be functionally identical, but the one
indicated as d
I'm not really sure how to explain this one, so I'll let the attached reduced
test case do the talking. The same code compiles fine on the same machine
running g++-4.1.2-20061115 (Debian prerelease 4.1.1-21)
Output of `g++ -v`:
Reading specs from /usr/lib/gcc/i486-linux-gnu/3.4.6/specs
Configured
--- Comment #3 from ubizjak at gmail dot com 2007-11-30 06:42 ---
(In reply to comment #1)
> w/ -fvect-cost-model:
> user0m46.439s
Looking a bit into generated code, it looks that -fect-cost-model effectively
disables all interesting vectorizations, effectively -fno-tree-vectorize.
--- Comment #2 from bonzini at gnu dot org 2007-11-30 05:41 ---
What were the benchmarks where the cost model was slower?
--
bonzini at gnu dot org changed:
What|Removed |Added
---
--- Comment #16 from bonzini at gnu dot org 2007-11-30 05:39 ---
One suspect is fwprop. Anyone can confirm?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-11-30 05:16
---
I have retitled this to reflect a bit more correctly. The workaround in Comment
#6 almost works, but it masks another problem. The patch that caused the
regression is r129016. The test case works fine on r129015
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-11-30 04:18
---
Subject: Bug 34230
Author: jvdelisle
Date: Fri Nov 30 04:18:05 2007
New Revision: 130532
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130532
Log:
2007-11-29 Steven G. Kargl <[EMAIL PROTECTED]>
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2007-11-30 04:14
---
Subject: Bug 33583
Author: jvdelisle
Date: Fri Nov 30 04:14:01 2007
New Revision: 130531
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130531
Log:
2007-11-29 Steven G. Kargl <[EMAIL PROTECTED]>
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-11-30 04:11
---
Subject: Bug 34203
Author: jvdelisle
Date: Fri Nov 30 04:10:47 2007
New Revision: 130530
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130530
Log:
2007-11-29 Steven G. Kargl <[EMAIL PROTECTED]>
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-11-30 04:11
---
Subject: Bug 34230
Author: jvdelisle
Date: Fri Nov 30 04:10:47 2007
New Revision: 130530
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130530
Log:
2007-11-29 Steven G. Kargl <[EMAIL PROTECTED]>
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-11-30 04:04
---
I will get on this soon.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ek dot kato at gmail dot com 2007-11-30 02:39 ---
Maybe I could find a reliable testcase for the problem. Following program will
crash while accessing dtp->u.p.line_buffer[dtp->u.p.item_count].
IMPLICIT NONE
CHARACTER(len=10), DIMENSION(2) :: var
NAMELIST /i
--- 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
--- Comment #10 from rakdver at gcc dot gnu dot org 2007-11-30 00:32
---
Subject: Bug 34244
Author: rakdver
Date: Fri Nov 30 00:32:04 2007
New Revision: 130527
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130527
Log:
PR tree-optimization/34244
* tree-vrp.c (ad
--- 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
Tracking down a problem with a much more rigorous codebase. Using this
contrived example to demonstrate the issue:
#include
using namespace std;
// static link this with pthreads to test
int main()
{
// this will exit cleanly
cout << "std::cout" << endl;
// this will segfault, why?
--- 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 #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 #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=gcc&view=rev&rev=130521
Log:
PR tree-optimization/33434
* tree-inline.c (setu
--- 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 #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 #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
Summary|
--- 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=gcc&view=rev&rev=130520
Log:
PR c++/34270
* tree.c (lvalue_p_1) : Handle x ?:
--- 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=gcc&view=rev&rev=130519
Log:
PR c++/34267
PR c++/34268
* parser.c (cp_
--- 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=gcc&view=rev&rev=130519
Log:
PR c++/34267
PR c++/34268
* parser.c (cp_
--- 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 behav
--- 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 r
--- 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 #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 #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 G
--- 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 #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 |Added
--- 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=gcc&view=rev&rev=130517
Log:
2007-11-29 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- 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 pro
--- 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 op
--- 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 f
--- 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 #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 #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
-
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 #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 check
--- 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 #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=gcc&view=rev&rev=130516
Log:
PR target/32130
* config/rs6000/eabi-cn.asm (__DT
--- 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)
--
http://gcc.gnu.org/bugzilla/
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: Functi
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...
--- 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
--- 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
Status|UNCONF
--- 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=14668&action=view)
gcc43-pr33984.patch
I've tried to fix this by the attached patch.
standard_conversion also uses is_bitfield_expr_
--- 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 standa
--- 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 |Ad
--- 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=gcc&view=rev&rev=130513
Log:
2007-11-29 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
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 v
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: 4.2.1
--- 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
CC|
--- 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 b
--- 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
--
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 #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.
) as follows.
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
--
vgodunko at rostel dot ru changed:
What|Removed |Added
Severity|normal |major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34290
--- 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=14667&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34290
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 #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=14666&action=view)
Ada package body
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34289
--- 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=14665&action=view)
Ada package spec
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34289
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:
Attach
--- 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
--- 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 #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 #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 he
--
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 11:2
--- 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 w
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
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
--
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 #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. N
--- 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 #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 c
--- 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
[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 Ad
--- 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 an
--- 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 A::i
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
--
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
--- 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:
--- 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 #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 (pass_d
--- 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=14664&action=view)
xx.i
gcc -O2 -Wall -c xx.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34285
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
Prio
--- 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
1 - 100 of 119 matches
Mail list logo
