--- Comment #6 from joefoxreal at gmail dot com 2007-11-28 07:36 ---
(In reply to comment #5)
> (In reply to comment #4)
> > Created an attachment (id=14651)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14651&action=view) [edit]
> > sorry, this is the
> > config.log(x86_64-unknow
--
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 #3 from jason dot vas dot dias at gmail dot com 2007-11-28
05:35 ---
Please consider this as an enhancement request to provide some way to configure
a
gcc build that prepends a given path to its default search paths, including
that of the default dynamic linker. There appea
--- Comment #2 from jason dot vas dot dias at gmail dot com 2007-11-28
05:23 ---
OK, I understand this was not the designed use of "--with-sysroot",
but there appears to be no other way to get a gcc build that compiles
and links against a non-root directory hierarchy BY DEFAULT .
Cons
--- Comment #16 from etiennes at cse dot unsw dot edu dot au 2007-11-28
05:11 ---
I just tried compiling 2.6.23.9 ia64 and the compile failed citing
drivers/char/ipmi/ipmi_si_intf.c:1095: error: __param_hotmod causes a section
type conflict
gcc (GCC) 4.2.3 20071123 (prerelease) (Debian
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-11-28 04:26
---
Fixed on trunk
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #5 from kargl at gcc dot gnu dot org 2007-11-28 04:07 ---
(In reply to comment #4)
> Created an attachment (id=14651)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14651&action=view) [edit]
> sorry, this is the config.log(x86_64-unknown-linux-gnu/libgfortran/config.log)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-28 03:59 ---
sysroot is not supposed to be used this way. It is designed for cross
compilers. It is the root which is supposed to be the same as the system root
would be. So changing --with-sysroot behavior here is incorrect.
When gcc-4.2.2 is built with the '--with-sysroot=$path' configure option,
gcc does correctly prepend $path to the default include and library search
dirs,
but the default linux dynamic linker, /lib/ld-linux.so.2, is still used, even
though $path/lib/ld-linux.so.2 exists.
Thus to link programs with
--- Comment #8 from pcarlini at suse dot de 2007-11-28 02:05 ---
(In reply to comment #7)
> Too bad they aren't defined for any machine I've tried so far...
The explanation is very simple: the new macros are implemented only in mainline
(would be 4.3.0).
--
http://gcc.gnu.org/bugzi
--- Comment #7 from scovich at gmail dot com 2007-11-28 01:56 ---
(In reply to comment #2)
> I think this is essentially invalid. Note that now we also have the various
> __GCC_HAVE_SYNC_COMPARE_AND_SWAP_* macros:
>
> http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
>
--- Comment #15 from rask at gcc dot gnu dot org 2007-11-28 01:55 ---
Fixed for both 4.2.3 and 4.3.0.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from rask at gcc dot gnu dot org 2007-11-28 01:44 ---
Subject: Bug 34174
Author: rask
Date: Wed Nov 28 01:44:10 2007
New Revision: 130489
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130489
Log:
Backport from mainline:
2007-11-26 Rask Ingemann
--- Comment #1 from dean at arctic dot org 2007-11-28 01:43 ---
this appears to be a regression between gcc 4.1.x and 4.2.x. i had to switch
the intrinsic to _mm_cvtsi64_si64x but it otherwise generates the same code on
4.3.x...
ubuntu 4.1.2:
% objdump -dr movq.o
movq.o: file for
--- Comment #9 from hjl at lucon dot org 2007-11-28 01:25 ---
Fixed in gcc 4.3.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from hjl at gcc dot gnu dot org 2007-11-28 01:20 ---
Subject: Bug 34001
Author: hjl
Date: Wed Nov 28 01:20:34 2007
New Revision: 130488
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130488
Log:
2007-11-27 H.J. Lu <[EMAIL PROTECTED]>
Joey Ye <[EMAIL
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-11-28 01:15
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
S
gcc seems allergic to movq in the context of mmx:
% cat movq.c
#include
#include
__m64 x;
__m64 y;
uint64_t foo(__m64 m) {
return _mm_cvtm64_si64(_mm_add_pi32(x, y));
}
% gcc -g -O3 -Wall -std=gnu99 -c -o movq.o movq.c
% objdump -dr movq.o
movq.o: file format elf64-x86-64
Disassembly
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-11-28 01:12
---
Subject: Bug 32928
Author: jvdelisle
Date: Wed Nov 28 01:12:31 2007
New Revision: 130487
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130487
Log:
2007-11-27 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-11-28 01:09
---
Subject: Bug 34227
Author: jvdelisle
Date: Wed Nov 28 01:09:35 2007
New Revision: 130486
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130486
Log:
2007-11-27 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-11-28 01:02
---
Subject: Bug 32928
Author: jvdelisle
Date: Wed Nov 28 01:02:36 2007
New Revision: 130484
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130484
Log:
2007-11-27 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-11-28 01:01
---
Subject: Bug 34227
Author: jvdelisle
Date: Wed Nov 28 01:00:50 2007
New Revision: 130483
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130483
Log:
2007-11-27 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #4 from joefoxreal at gmail dot com 2007-11-28 01:00 ---
Created an attachment (id=14651)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14651&action=view)
sorry, this is the config.log(x86_64-unknown-linux-gnu/libgfortran/config.log)
--
http://gcc.gnu.org/bugzilla/
--- Comment #6 from pcarlini at suse dot de 2007-11-28 00:56 ---
Just a short note to follow up to my first message: as expected, in the next
standard both push_back and resize will be very different. The signature of the
new push_back, already available under the experimental C++0x mode
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-28 00:55 ---
(In reply to comment #2)
> Created an attachment (id=14650)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14650&action=view) [edit]
> Here's the config.log
No that is still the wrong one.
Please read the erorr
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34255
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01745.html regresses the property
that code output with -g must be the same as that without -g. make
bootstrap-debug demonstrates that several files miscompare after this patch,
and don't if the patch is reversed.
The patch not only causes -g divergenc
--- Comment #2 from joefoxreal at gmail dot com 2007-11-28 00:45 ---
Created an attachment (id=14650)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14650&action=view)
Here's the config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34242
--- Comment #8 from raj dot khem at gmail dot com 2007-11-28 00:11 ---
(In reply to comment #7)
> s/int//. The enumerated type is implementation defined but shall be capable to
> represent the values of all members.
Exactly and gcc for arm uses this definition to its advantage so that i
--- Comment #5 from kargl at gcc dot gnu dot org 2007-11-28 00:06 ---
(In reply to comment #4)
> (In reply to comment #3)
>
> (Admittedly from the 4.2.2 manual):
> 2.2 Options controlling Fortran dialect
> -frange-check
> Enable range checking on results of simplification of constan
--- Comment #7 from dominiq at lps dot ens dot fr 2007-11-27 23:27 ---
>From http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg01459.html,
powerpc64-unknown-linux-gnu shows the same pattern as powerpc-apple-darwin9:
anything linked to endianness?
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #6 from burnus at gcc dot gnu dot org 2007-11-27 23:12 ---
character(kind=1) __result_foo[1:1];
= __result_foo;
As Andrew pointed out, we return an array and not a scalar.
TODO:
a) Check that we expect a scalar to be returned in gfc_conv_function_call.
b) Ensure th
--- Comment #5 from dominiq at lps dot ens dot fr 2007-11-27 23:00 ---
On Intel Darwin9 (working) -fdump-tree-gimple shows without -m64:
foo ()
{
character(kind=1) __result_foo[1:1];
__result_foo[1]{lb: 1 sz: 1} = 66;
D.831 = __result_foo;
return D.831;
}
bar (x)
{
character
--- Comment #4 from terry at chem dot gu dot se 2007-11-27 22:56 ---
(In reply to comment #3)
(Admittedly from the 4.2.2 manual):
2.2 Options controlling Fortran dialect
-frange-check
Enable range checking on results of simplification of constant expressions
during compilation. For
--- Comment #3 from kargl at gcc dot gnu dot org 2007-11-27 22:45 ---
(In reply to comment #2)
> (In reply to comment #1)
> > There is no bug here. You have explicitly disabled
> > range checking. This means that you no longer have
> > a limitation on range in constant folding. It may
The following is rejected with:
Error: Parameter 'c_char' at (1) has not been declared or is a variable, which
does not reduce to a constant expression
I thought it was fixed by the patch for
PR fortran/31154
PR fortran/31229
PR fortran/4
but seemingly it was not :-(
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171
--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-27 22:24 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-27 22:23 ---
Subject: Bug 34016
Author: jakub
Date: Tue Nov 27 22:23:29 2007
New Revision: 130476
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130476
Log:
PR tree-optimization/34016
* tree-ssa-loop.c (pas
--- Comment #3 from terry at chem dot gu dot se 2007-11-27 22:23 ---
> I don't worry about "len=3", I'm worrying about the type:
>
> data emname/'bar'/
>
> is implicitly types REAL and then one line later comes:
>
> character(len=3) :: emname
>
> I still think that this violates:
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34059
--- Comment #5 from mmitchel at gcc dot gnu dot org 2007-11-27 22:22
---
FRV is not a primary or secondary platform. Is there a test-case for this on
another platform?
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
I see on my computer a lot of failures in the testsuite gcc.dg/vect. See
http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg01474.html
The failures are there since Sepember 2007. But the other testresults don't
show these failures.
--
Summary: Lots of failures in gcc.dg/vect
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34244
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34029
--- Comment #2 from burnus at gcc dot gnu dot org 2007-11-27 22:16 ---
(In reply to comment #1)
> But a character string is not an array. The len parameter is a type parameter.
> That part of the standard does not apply. It's legal.
I don't worry about "len=3", I'm worrying about the ty
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34206
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-11-27 22:15
---
My mistake. I moved too quickly, and thought this was ICE-on-invalid without a
previous valid error. P4.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from terry at chem dot gu dot se 2007-11-27 22:12 ---
But a character string is not an array. The len parameter is a type parameter.
That part of the standard does not apply. It's legal.
--
terry at chem dot gu dot se changed:
What|Removed
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-27 22:11 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from burnus at gcc dot gnu dot org 2007-11-27 22:09 ---
No regression. Valgrind shows:
==21714== Invalid read of size 4
==21714==at 0x49C077: generate_local_decl (trans-decl.c:2980)
==21714==by 0x471026: traverse_ns (symbol.c:2951)
==21714==by 0x499FFD: gfc_ge
--- Comment #7 from mmitchel at gcc dot gnu dot org 2007-11-27 22:09
---
P5 until/unless a non-Ada testcase is found.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-27 22:08 ---
Mark,
Why was this marked as a P2 as this is only an error recovery regression?
Thanks,
Andrew Pinski
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34101
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34222
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34178
--- Comment #7 from mmitchel at gcc dot gnu dot org 2007-11-27 22:02
---
Marking P2, not P1, because there is an easy work-around and this is not the
recommended way of building GCC.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34140
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34138
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34123
I discovered a few differences in the gcc implemenation of the
macros, as compared with the ISO C Tr24732 paper. It may be more likely that
the gcc implementation is incorrect.
In any case, here's what I see in the decfloat-constants.c test from the gcc
4.3 testsuite:
if (DEC32_MIN_EXP != -95)
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-11-27 21:59
---
Jason, would you please take a look at this issue?
Thanks,
-- Mark
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34103
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34102
--- Comment #2 from terry at chem dot gu dot se 2007-11-27 21:57 ---
(In reply to comment #1)
> There is no bug here. You have explicitly disabled
> range checking. This means that you no longer have
> a limitation on range in constant folding. It may
> be help to look at -fdump-parse
--- Comment #21 from fxcoudert at gcc dot gnu dot org 2007-11-27 21:51
---
(In reply to comment #20)
> OK, I've found the problem. tgammaf has not been added to
> gfortran.map.
Yuck. I should have remembered that :(
> I don't know
> enough about symbol versioning to determine if tga
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-27 21:50 ---
Subject: Bug 34181
Author: jakub
Date: Tue Nov 27 21:50:20 2007
New Revision: 130474
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130474
Log:
PR tree-optimization/34181
* method.c (use_thunk)
--- Comment #4 from dominiq at lps dot ens dot fr 2007-11-27 21:39 ---
> Works for me on Intel Darwin9, but fails with default (-m32) on ppc Darwin9.
More precisely, works with both -m32 and -m64 on Intel Darwin9, but fails with
both on ppc Darwin9.
--
http://gcc.gnu.org/bugzilla/s
--- Comment #1 from vgodunko at rostel dot ru 2007-11-27 21:08 ---
Created an attachment (id=14649)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14649&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34251
Hello,
I have following output from the compiler for attached testcase:
gcc -c items.adb -gnat05
items.adb:11:21: expected type
"System.Finalization_Implementation.Limited_Record_Controller"
items.adb:11:21: found type
"System.Finalization_Implementation.Record_Controller"
This strange diagnosis
--- Comment #4 from pault at gcc dot gnu dot org 2007-11-27 20:54 ---
Fixed on trunk.
Paul
PS Note the need to get the kind right for the index vector in order to
eliminate the temporary.
--
pault at gcc dot gnu dot org changed:
What|Removed |Add
--- Comment #1 from tromey at gcc dot gnu dot org 2007-11-27 20:53 ---
I think your proposed fix sounds ok.
I don't have a copy of the C++ standard handy.
Does this bug apply to both C and C++, or only C?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32868
--- Comment #9 from pault at gcc dot gnu dot org 2007-11-27 20:52 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #5 from pault at gcc dot gnu dot org 2007-11-27 20:51 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #14 from pault at gcc dot gnu dot org 2007-11-27 20:50 ---
Fixed on trunk I hope!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dominiq at lps dot ens dot fr 2007-11-27 20:49 ---
Works for me on Intel Darwin9, but fails with default (-m32) on ppc Darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34246
--- Comment #8 from pault at gcc dot gnu dot org 2007-11-27 20:48 ---
Subject: Bug 29389
Author: pault
Date: Tue Nov 27 20:47:55 2007
New Revision: 130472
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130472
Log:
2007-11-27 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #3 from pault at gcc dot gnu dot org 2007-11-27 20:48 ---
Subject: Bug 33850
Author: pault
Date: Tue Nov 27 20:47:55 2007
New Revision: 130472
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130472
Log:
2007-11-27 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #20 from kargl at gcc dot gnu dot org 2007-11-27 20:28 ---
OK, I've found the problem. tgammaf has not been added to
gfortran.map. I suspect that there may be other symbols
missing from gfortran.map. Unfortunately, I don't know
enough about symbol versioning to determine
--- Comment #4 from simartin at gcc dot gnu dot org 2007-11-27 20:26
---
Patch submitted here: http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01404.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34059
--- Comment #7 from aldot at gcc dot gnu dot org 2007-11-27 20:15 ---
s/int//. The enumerated type is implementation defined but shall be capable to
represent the values of all members.
I'd read this as -fshort-enum violating that ":16"?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #6 from aldot at gcc dot gnu dot org 2007-11-27 19:48 ---
I ment to build with arch=tune=abi for iwmmxt
As you say, arm.c suggests that iwmmxt defaults to -fshort-enums here, fwiw:
/* AAPCS based ABIs use short enums by default. */
static bool
arm_default_short_enums (void
--- Comment #35 from mark at codesourcery dot com 2007-11-27 19:45 ---
Subject: Re: [4.3 regression] udivdi3 counterproductive,
unwarranted use
bunk at stusta dot de wrote:
> Even if this specific issue in the kernel would turn out as a misoptimization,
> the general problem would st
--- Comment #34 from jakub at gcc dot gnu dot org 2007-11-27 19:43 ---
I certainly agree with Mark here, we can talk whether on a particular arch
with particular options this transformation is a win or not, but when the
kernel
people decide to implement libgcc on their own and intentiona
--- Comment #19 from kargl at gcc dot gnu dot org 2007-11-27 19:42 ---
Michael,
I found a part of the problem. First, I grabbed the tarballs
you specified and built gcc/gfortran in a directory as you
stated. The reason I did not see a problem previously is
because I always add -stati
--- Comment #33 from rakdver at kam dot mff dot cuni dot cz 2007-11-27
19:42 ---
Subject: Re: [4.3 regression] udivdi3 counterproductive, unwarranted use
> > --- Comment #29 from rguenth at gcc dot gnu dot org 2007-11-27 09:43
> > ---
> > This is IMHO at most a QOI issue - a
--- Comment #32 from bunk at stusta dot de 2007-11-27 19:31 ---
(In reply to comment #30)
>...
> I am not a kernel developer, but my feeling as a GCC developer is that
> you must provide the entry points in libgcc whenever you are linking
> code compiled with GCC. In other words, that G
--- Comment #5 from drow at gcc dot gnu dot org 2007-11-27 19:27 ---
Probably. Why are you using the iwmmxt ABI? Don't. Just trust the AAPCS, it
knows what's good for you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34205
--- Comment #13 from pault at gcc dot gnu dot org 2007-11-27 19:22 ---
Subject: Bug 33541
Author: pault
Date: Tue Nov 27 19:21:52 2007
New Revision: 130471
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130471
Log:
2007-11-27 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #4 from pault at gcc dot gnu dot org 2007-11-27 19:22 ---
Subject: Bug 34231
Author: pault
Date: Tue Nov 27 19:21:52 2007
New Revision: 130471
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130471
Log:
2007-11-27 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #31 from bunk at stusta dot de 2007-11-27 19:16 ---
(In reply to comment #29)
> This is IMHO at most a QOI issue - at Novell we mark timespec_add_ns's u64
> parameter as volatile to work around this issue. I expect upstream to adopt
> a workaround as well. Note that some ta
--- Comment #2 from matz at gcc dot gnu dot org 2007-11-27 19:05 ---
For reference, the internal one is at
https://bugzilla.novell.com/show_bug.cgi?id=344299
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34250
--- Comment #1 from matz at gcc dot gnu dot org 2007-11-27 19:02 ---
Created an attachment (id=14648)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14648&action=view)
fix for this
A potential fix for this problem, iterating over possibly multiple constant
refs. Shouldn't have muc
--- Comment #30 from mark at codesourcery dot com 2007-11-27 18:58 ---
Subject: Re: [4.3 regression] udivdi3 counterproductive,
unwarranted use
rguenth at gcc dot gnu dot org wrote:
> --- Comment #29 from rguenth at gcc dot gnu dot org 2007-11-27 09:43
> ---
> This is IMHO a
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-27 18:44 ---
Additionally, repo_emit_p should IMHO use DECL_INTEGRAL_CONSTANT_VAR_P
rather than DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P check - if a static
data member isn't const, then it really doesn't matter if it is initializ
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-27 18:28 ---
patch:
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01449.html
so you don't read the patches list.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34247
This was triggered by a patch of ours on the SLES10 compiler, which is 4.1.2
based. But it can be seen without any patches, for 4.1.x and trunk at least.
I'm sure the other compilers in between have the same problem, as the code
in the s390 backend is designed to error in these cases. Anyway, do
--- Comment #8 from rask at gcc dot gnu dot org 2007-11-27 18:04 ---
Created an attachment (id=14647)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14647&action=view)
Patch to enhance cse.c
The attached patch can optimize this testcase:
void foo (int);
int bar2 (int a, int b)
{
--- Comment #7 from rwgk at yahoo dot com 2007-11-27 17:43 ---
(In reply to comment #6)
> Fixed.
>
Confirmed (yesterday with svn revision 130447).
Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34233
--- Comment #15 from burnus at gcc dot gnu dot org 2007-11-27 17:36 ---
(In reply to comment #13)
> For testsub.f, g95 creates (for "EXTERNAL BDTEST"):
> static void * U0 = bdtest_;
> which shows up as:
> U bdtest_
> same for ifort. While sunf95 and openf95 have bdte
1 - 100 of 164 matches
Mail list logo
