2009/11/26 Piotr Wyderski:
Clean, simple and GCC used to happily accept that.
Only with the experimental C++0x mode, which is a moving target and
you shouldn't really complain if it changes.
But now it is illegal because of 3 draft violations:
Base() shall be public, but is not
~Base()
2009/11/26 Jonathan Wakely:
This still lets you use defaulted functions, but the base is not
trivially copyable.
Oops, I meant the base is not a trivial class ... but then it can't be
anyway as you have a virtual function.
On 11/26/2009 12:20 AM, Alexandre Oliva wrote:
sed -i 's,[ \t]*$,,' probably won't work, if there are all-blanks lines
being left alone in the patch (so the rx will match the patch markers
too), but something slightly more elaborate preserving a fixed number of
leading blanks dependng on the
Jonathan Wakely wrote:
It's under discussion
That's certainly a good news. Anyway, I'll wait
with porting my framework to the newest GCC,
until this issue is settled, as:
a) = default works as I expect on gcc 4.5-20090604
and maybe it will still do in the future;
b) gcc 4.5-20091119 reports so
On Thu, Nov 26, 2009 at 9:56 AM, Paolo Bonzini bonz...@gnu.org wrote:
On 11/26/2009 12:20 AM, Alexandre Oliva wrote:
sed -i 's,[ \t]*$,,' probably won't work, if there are all-blanks lines
being left alone in the patch (so the rx will match the patch markers
too), but something slightly more
Richard Guenther richard.guent...@gmail.com writes:
Does svn rely on patch for merging
No, it uses an internal diff3 algorithm. You can make it use an
external diff3 program via the command line or the config file.
and can it be taught to use -l?
The internal diff/merge will ignore
On 2009-11-25 17:49:39 +0100, Richard Guenther wrote:
On Wed, 25 Nov 2009, Richard Kenner wrote:
Why the latter? I agree with the problems this can cause, but if
they can't be fixed by removing it from the database, why revert
it? All things being equal, trailing blanks in fact aren't a
On 2009-11-26 10:12:39 +1100, Ben Elliston wrote:
On Wed, 2009-11-25 at 15:17 -0500, Kaveh R. GHAZI wrote:
Finally, we have a process for reverting a patch. If anyone wants to
revert some part, it needs to be followed. Otherwise *that* would be
breaking the rules...
Won't reverting the
Hi,
On Wed, 25 Nov 2009, Richard Kenner wrote:
In my mind it's very simple: trailing whitespace poses exactly _no_
problem (except of being against the coding standard),
It's against the coding standards for a very good reason, which is that it
makes patching harder because you have
Hi,
On Wed, 25 Nov 2009, Basile STARYNKEVITCH wrote:
1. What to do in the immediate term with the repo. I've got no strong
opinions here.
I do understand most of the opinions, but I would rather prefer that we
don't revert the trailing whitespace patch. I definitely can live with
On 11/25/09 16:51, Lu, Hongjiu wrote:
Sorry for that. I did send an email and though it was an obvious fix. I guess the
patch may be too big, 400K with bz2.
Did you get a reject message? If so, that should have caused you to
stop and think a little...
Jeff
Michael Matz wrote:
I Don't Want To Work Around useless unapproved mass changes.
Hey, nor do I. (In fact, I don't even like having to work around useful
approved mass changes, merging is always dull and tedious work. But I think
of it as just something that goes with the territory.)
To
Michael Matz wrote:
Hi,
On Wed, 25 Nov 2009, Basile STARYNKEVITCH wrote:
1. What to do in the immediate term with the repo. I've got no strong
opinions here.
I do understand most of the opinions, but I would rather prefer that we
don't revert the trailing whitespace patch. I definitely
On 11/26/2009 08:18 AM, Michael Matz wrote:
How, for goodness sake, can pure trailing whitespace changes, which by
necessity you can't even _see_ in an editor (except if you activate modes
that explicitely show them e.g. in different color) clean up code? Have
you looked at the patch or fallout
Snapshot gcc-4.5-20091126 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20091126/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Did you get a reject message? If so, that should have caused you to
stop and think a little...
I sent:
Date: Wed, 25 Nov 2009 02:53:21 -0800
From: H.J. Lu hongjiu...@intel.com
To: gcc-patc...@gcc.gnu.org
Subject: PATCH: Remove trailing white spaces
User-Agent: Mutt/1.5.19
The rsult is also same, you go too far.
Code I want to show a fact in Linux, when a process load a library into memory,
such as 0x1000
foo.so 0x1000
ELF header
.text section
.data section
.bss section
...
Here data in 0x1000 and its follower have an *exact* map to foo.so in disk, you
need
yunfeng zhang wrote:
have an *exact* map to foo.so in disk
This is where your misunderstanding arises. Just as 5+3 can add up to the
same result as 4+4, so you cannot ignore that the final mapped addresses you
are seeing add up to the same result via different routes. Compile your
sources
You can run a.out several times
24a5e0, 24941c
1115e0, 11041c
c785e0, c7741c
8c35e0, 8c241c
...
Now open f.map
g = 0x15e0, foo = 0x41c
is it 5 + 3 = 4 + 4?
2009/11/27 Dave Korn dave.korn.cyg...@googlemail.com:
yunfeng zhang wrote:
have an *exact* map to foo.so in disk
This is where your
yunfeng zhang wrote:
a.out
f.map
is it 5 + 3 = 4 + 4?
If you refuse to look at the source code that gcc generates, you will never
know what the difference is.
I cannot make that decision for you.
cheers,
DaveK
Yunfeng Zhang, please try this example.
elf.tar.gz
Description: GNU Zip compressed data
On 11/26/2009 02:04 PM, yunfeng zhang wrote:
The result is the same
#includestdio.h
extern int g __attribute__((visibility(hidden)));
int g;
int foo(int a, int b)
{
g = a + b;
printf(%x, %x,g, foo);
return g;
}
load and call `foo' in the library, an outputting
Sorry! I've made a mistake! But using LD_PRELOAD to force to reposition a
variable/function from a module is violating software engineer. And the more
important is, as the result, all user *all* pay the bill for this even they
make sure they don't need the feature, such as, glibc itself.
--- Comment #4 from jakub at gcc dot gnu dot org 2009-11-26 09:31 ---
Caused by http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01059.html aka r154354.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2009-11-26 09:42 ---
The problem seems to be the new set_underlying_type call called from
build_self_reference. Apparently the objc-act.c expects that type variants at
that point are only created for some other purpose (don't know objc,
--- Comment #6 from jakub at gcc dot gnu dot org 2009-11-26 09:47 ---
Created an attachment (id=19152)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19152action=view)
gcc45-pr42156.patch
Untested patch. I'm not familiary with ObjC/ObjC++, so have no idea whether it
is the right
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-26 09:56 ---
Aliasing rules are indeed broken because you access a union of anonymous type
through a pointer to a union of type ieee_double_extract.
I think you want
union { union ieee_double_extract d; unsigned long long
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2009-11-26
11:02 ---
note that there are no warnings
A warning is issued with -Wstrict-aliasing=1 or -Wstrict-aliasing=2, but no
warning with -Wstrict-aliasing=3 (or -Wall).
I see there are already a few bug reports about
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-26 11:25 ---
Correct. We can either produce possibly lots of false positives or not warn.
Warning in the cases where we can prove your code is wrong would be pointless
as in that case we'd better take measures to not miscompile
The valarray mask_array implementation creates out of bound memory accesses
when
the number of the True bits is smaller that the size of array, although this
is perfect legal.
This produce valgrin error at best, sometime segfaults, or infinite loops.
To reproduce, compile the attached test:
--- Comment #1 from christian dot bruel at st dot com 2009-11-26 11:32
---
Created an attachment (id=19153)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19153action=view)
reduced case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
--- Comment #2 from christian dot bruel at st dot com 2009-11-26 11:35
---
Created an attachment (id=19154)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19154action=view)
computed assignment test case
compiled with g++ -O0
gnx2439$ valgrind ./a.out==1599== Memcheck, a memory
--- Comment #3 from paolo dot carlini at oracle dot com 2009-11-26 11:35
---
Hey, this is pointless, the issue is well known and Gaby is the reference
person in this area.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from christian dot bruel at st dot com 2009-11-26 11:38
---
Created an attachment (id=19155)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19155action=view)
controversal testcase
compile with -O0, Segfaults on x86 with
gcc version 4.5.0 20091119 (experimental)
--- Comment #5 from christian dot bruel at st dot com 2009-11-26 11:40
---
Created an attachment (id=19156)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19156action=view)
Proposed patch
2009-11-23 Christian Bruel christian.br...@st.com
* include/bits/mask_array.h
--- Comment #6 from christian dot bruel at st dot com 2009-11-26 12:08
---
(In reply to comment #3)
Hey, this is pointless, the issue is well known and Gaby is the reference
person in this area.
no problem, if the issue is known it can be recorded
for the reference, a link to
--- Comment #7 from paolo dot carlini at oracle dot com 2009-11-26 12:15
---
What I meant, exactly, is that if any issue is well known to the concerned
people, there is no need for a Bugzilla, in particular an invalid one ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
--- Comment #8 from christian dot bruel at st dot com 2009-11-26 12:18
---
(In reply to comment #7)
What I meant, exactly, is that if any issue is well known to the concerned
people, there is no need for a Bugzilla, in particular an invalid one ;)
Well I still need to be convinced
--- Comment #9 from paolo dot carlini at oracle dot com 2009-11-26 12:57
---
The point is that the code is not conforming. In any case, conforming or not,
in the future please do not open Bugzilla for issues already known to the
maintainers, thanks in advance.
--
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-11-26 13:02
---
This is what I would call a very fundamental bug, at the soul of what fortran
is suppose to do. I am looking at it but think it would go better with a team
effort here. Anyone have any thoughts about it?
--
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-11-26 14:35
---
I think we need to gfc_walk_op_expr before we try to gfc_conv_array_transpose
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41278
--- Comment #3 from matz at gcc dot gnu dot org 2009-11-26 14:50 ---
I have a patch.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Compiling of
qt-x11-opensource-src-4.5.3/src/3rdparty/webkit/WebCore/rendering/RenderMenuList.cpp
failed with the following compiler call
g++ -c -fpreprocessed -m32 -O2 RenderMenuList.1.i
RenderMenuList.1.i: In member function
'WebCore::RenderMenuList::controlClipRect(int, int) const':
--- Comment #1 from mario-baumann at web dot de 2009-11-26 15:07 ---
Created an attachment (id=19157)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19157action=view)
preprocessed cpp file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42183
=g++
COLLECT_LTO_WRAPPER=/opt/gcc/4.5.0-20091126-svn154671/x86_64/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --with-cloog=/opt/gcc/svn/aux
--with-gmp=/opt/gcc/svn/aux --with-mpc=/opt/gcc/svn/aux
--with-mpfr=/opt/gcc/svn/aux
--- Comment #3 from nbenoit at tuxfamily dot org 2009-11-26 15:08 ---
Using integer instead of double, the performance difference is even more
noticeable :
* with -O1
GCC 4.4.2 7475 ms
GCC-trunk-r154672 9390 ms
--
--- Comment #3 from olga at il dot ibm dot com 2009-11-26 15:35 ---
Potential patch (as Andew suggested). Please check for your platform.
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01467.html
Thanks,
Olga
--
olga at il dot ibm dot com changed:
What|Removed
--- Comment #4 from vincent at vinc17 dot org 2009-11-26 15:53 ---
(In reply to comment #1)
Aliasing rules are indeed broken because you access a union of anonymous type
through a pointer to a union of type ieee_double_extract.
OK, the real code in MPFR is a double accessed through a
--- Comment #4 from matz at gcc dot gnu dot org 2009-11-26 15:58 ---
Fixed in r154674.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jason at gcc dot gnu dot org 2009-11-26 16:00 ---
Subject: Bug 10690
Author: jason
Date: Thu Nov 26 15:59:52 2009
New Revision: 154675
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154675
Log:
PR c++/10690
* rtti.c (get_tinfo_decl_dynamic):
--- Comment #9 from jason at gcc dot gnu dot org 2009-11-26 16:04 ---
Fixed for 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
One would assume that the following program prints the same number four times,
but instead 1 0 1 0 is printed. I compiled it with options -std=c99 -lm.
#include stdio.h
#include math.h
#include stdlib.h
int main(void)
{
long double value1 = 1.6646342e21;
long double value2 =
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-11-26 16:39 ---
The frontend code should indeed be able to unconditionally warn for
((union ieee_double_extract *)(x.d))-s.exp because it can see both
the underlying object and the access through the non-conflicting type.
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-26 16:41 ---
reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42183
--- Comment #2 from matz at gcc dot gnu dot org 2009-11-26 16:51 ---
I have a patch: http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01474.html
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
20091126 (experimental) [trunk revision 154675] (GCC)
--
Summary: [4.5 Regression] expected gimple_assign(error_mark),
have gimple_call() in gimple_assign_rhs_code, at
gimple.h:1820
Product: gcc
Version: 4.5.0
Status
--- Comment #1 from jv244 at cam dot ac dot uk 2009-11-26 17:02 ---
*** Bug 41051 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
--- Comment #2 from jv244 at cam dot ac dot uk 2009-11-26 17:02 ---
*** This bug has been marked as a duplicate of 42181 ***
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #2 from jv244 at cam dot ac dot uk 2009-11-26 17:04 ---
the following is a testcase for the ICE (derived from CP2K bug crashes in the
same place):
cat bug.f90
MODULE powell
INTEGER, PARAMETER :: dp=8
CONTAINS
SUBROUTINE newuob (n,npt,x,rhobeg,rhoend,maxfun,xbase,
--- Comment #3 from jv244 at cam dot ac dot uk 2009-11-26 17:05 ---
the ice is absent in 4.4 but present in 4.5 trunk
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #1 from hutchinsonandy at gcc dot gnu dot org 2009-11-26 17:12
---
R1 and R0 are used at assembler level outside of compiler scope.
R1 is always expected to contain as a zero value - to avoid using a register to
load this common value. R1 maybe used in assembler for other
--- Comment #1 from kargl at gcc dot gnu dot org 2009-11-26 17:13 ---
I think that you may be looking at a library issue
and the conversion of a decimal string to binary.
Add
printf(%La\n%La\n%La\n%La\n, value1, value2, value3, value4);
to your program yields
REMOVE:kargl[209] ./z
--- Comment #6 from hutchinsonandy at gcc dot gnu dot org 2009-11-26 17:20
---
Fixed on 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21078
--
hutchinsonandy at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hutchinsonandy at gcc dot gnu dot org 2009-11-26 17:25
---
Author: hutchinsonandy
Date: Mon Nov 23 21:38:32 2009
New Revision: 154467
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154467
Log:
* gcc.dg/pr36998.c: Frame pointer required for avr target.
*
--- Comment #3 from hutchinsonandy at gcc dot gnu dot org 2009-11-26 17:29
---
Fixed 4.5
Author: hutchinsonandy
Date: Mon Nov 23 22:21:21 2009
New Revision: 154474
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154474
Log:
* gcc.dg/torture/pr37868.c: Use smaller bitfield for
--- Comment #10 from christian dot bruel at st dot com 2009-11-26 17:44
---
Paolo,
I entered this defect for user reference, since the problem that originates the
thread occurs in many public places such as testsuites (perenial Sec26/P26774)
or class books
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-11-26 17:50
---
Removing the assert appears to fix this. Testing now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41278
--- Comment #11 from paolo dot carlini at oracle dot com 2009-11-26 18:00
---
Yes, but remember our policy in the future, thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
--- Comment #12 from janus at gcc dot gnu dot org 2009-11-26 19:01 ---
Subject: Bug 42048
Author: janus
Date: Thu Nov 26 19:01:02 2009
New Revision: 154679
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154679
Log:
2009-11-26 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-26 19:01 ---
Subject: Bug 42167
Author: janus
Date: Thu Nov 26 19:01:02 2009
New Revision: 154679
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154679
Log:
2009-11-26 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-26 19:05 ---
Fixed with r154679. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-11-26 19:05
---
Subject: Bug 41278
Author: jvdelisle
Date: Thu Nov 26 19:05:37 2009
New Revision: 154680
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154680
Log:
2009-11-26 Jerry DeLisle jvdeli...@gcc.gnu.org
gfortran -c -fgraphite-identity -g -O3 -ffast-math bug.f90
bug.f90: In function calerf:
bug.f90:3:0: error: definition in block 11 does not dominate use in block 4
for SSA_NAME: xden_2 in statement:
D.1562_21 = D.1561_20 + xden_2;
bug.f90:3:0: internal compiler error: verify_ssa failed
Please
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42186
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2009-11-26 19:10
---
Subject: Bug 41278
Author: jvdelisle
Date: Thu Nov 26 19:10:29 2009
New Revision: 154681
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154681
Log:
2009-11-26 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #1 from jv244 at cam dot ac dot uk 2009-11-26 19:11 ---
pretty similar in this case
gfortran -c -fgraphite-identity -g -O3 -ffast-math bug.f90 bug.f90
bug.f90: In function psi:
bug.f90:4:0: internal compiler error: gimple check: expected
gimple_assign(error_mark), have
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-11-26
19:29 ---
This patch on x86_64-apple-darwin10 returns the obj-c++ testsuite results back
to their previous results of...
=== obj-c++ Summary ===
# of expected passes398
# of unexpected
I just tried to compile package boswars-2.5 with the GNU C++ compiler
version 4.5 snapshot 20091119 and the compiler said
engine/guichan/widgets/textbox.cpp:595:1: error: inlined_to pointer set for
noninline callers
engine/guichan/widgets/textbox.cpp:595:1: error: multiple inline callers
--- Comment #1 from dcb314 at hotmail dot com 2009-11-26 20:05 ---
Created an attachment (id=19158)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19158action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42187
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #4 from jason at gcc dot gnu dot org 2009-11-26 20:58 ---
Subject: Bug 42026
Author: jason
Date: Thu Nov 26 20:58:47 2009
New Revision: 154686
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154686
Log:
PR c++/42026, DR 239
* parser.c
Follow-up to PR42048. Consider the following code:
module grid_module
implicit none
type grid
contains
procedure :: new_grid
procedure :: new_int
end type
contains
subroutine new_grid(this)
class(grid) :: this
end subroutine
integer function new_int(this)
class(grid) :: this
--- Comment #13 from janus at gcc dot gnu dot org 2009-11-26 21:05 ---
Comment #4 is fixed with r154679. For the issues in comment #6 to #10 I have
opened PR42188, so this one can be closed.
--
janus at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from jason at gcc dot gnu dot org 2009-11-26 21:11 ---
Fixed for 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-11-26 21:11 ---
Well FreeBSD has slightly different default x87 precision setting .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42184
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-26 21:15 ---
1.6646342e21 will produce a double and then that is extended into long double.
On the other hand 1.6646342e21L is a long double so it is parsed what you
expect into a long double.
1 0 1 0 is the correct value for
--- Comment #5 from bernds at gcc dot gnu dot org 2009-11-26 21:35 ---
Subject: Bug 38582
Author: bernds
Date: Thu Nov 26 21:35:35 2009
New Revision: 154687
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154687
Log:
PR rtl-opt/38582
* regrename.c (struct
--- Comment #6 from bernds at gcc dot gnu dot org 2009-11-26 21:41 ---
Subject: Bug 38582
Author: bernds
Date: Thu Nov 26 21:41:42 2009
New Revision: 154688
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154688
Log:
PR rtl-opt/38582
* regrename.c (struct du_head):
--- Comment #9 from burnus at gcc dot gnu dot org 2009-11-26 21:46 ---
The following assert is wrong:
gcc_assert (src_info-dimen == 2);
(and has been removed in the comment patch of comment 7). I only want to link
to an email which gives the reason why.
--- Comment #27 from jvdelisle at gcc dot gnu dot org 2009-11-26 21:53
---
Subject: Bug 41807
Author: jvdelisle
Date: Thu Nov 26 21:52:52 2009
New Revision: 154690
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154690
Log:
2009-11-26 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #13 from tkoenig at gcc dot gnu dot org 2009-11-26 21:56
---
Created an attachment (id=19159)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19159action=view)
patch that implements the multiplication idea
This generates
if (D.1339 0)
{
if (D.1338
--- Comment #28 from jvdelisle at gcc dot gnu dot org 2009-11-26 21:57
---
Subject: Bug 41807
Author: jvdelisle
Date: Thu Nov 26 21:57:32 2009
New Revision: 154691
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154691
Log:
2009-11-26 Jerry DeLisle jvdeli...@gcc.gnu.org
Follow up to PR 41807 - based on the comment at
http://gcc.gnu.org/ml/fortran/2009-11/msg00181.html
cf. also http://gcc.gnu.org/ml/fortran/2009-11/msg00208.html
it is both unacceptable and unanticipated that gfc_is_constant_expr have side
effects like that. Should we, perhaps copy the expression
--- Comment #14 from kargl at gcc dot gnu dot org 2009-11-26 22:07 ---
(In reply to comment #13)
}
countm1.1 = (((character(kind=4)) D.1338 - (character(kind=4)) D.1337) *
(character(kind=4)) step_sign.2) / (character(kind=4)) (step_sign.2 * D.1339);
implementing the
The following program
pragma Restrictions (No_Local_Allocators);
procedure Restrict_Bug is
generic
package Generic_Pkg is
I : Integer;
end Generic_Pkg;
package Instance is new Generic_Pkg;
begin
null;
end Restrict_Bug;
creates the error message:
gnatmake -v restrict_bug
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2009-11-26 22:11
---
Just a note of appreciation to Chris for reporting this bug and providing a
simple and extremely useful test case. When I get a moment, I will add Chris
to the test case as recognition.
Shall we backport this
--- Comment #29 from jvdelisle at gcc dot gnu dot org 2009-11-26 22:18
---
Subject: Bug 41807
Author: jvdelisle
Date: Thu Nov 26 22:18:36 2009
New Revision: 154692
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154692
Log:
2009-11-26 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #30 from jvdelisle at gcc dot gnu dot org 2009-11-26 22:21
---
Fixed on trunk and 4.4.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #85 from howarth at nitro dot med dot uc dot edu 2009-11-26
22:35 ---
Created an attachment (id=19160)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19160action=view)
combined patch that fixes dsymutil asserts
Combined patches...
1 - 100 of 110 matches
Mail list logo
