--
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 #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 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34123
--
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=34140
--- 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=34178
--
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 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34103
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)
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34101
--- 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
--
--- 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 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
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34206
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34244
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
--- 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
--
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34059
--
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 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:
--- 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 #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 #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=34029
--- 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
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 :-(
--- 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
--- 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 #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 #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 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 #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 #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
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
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34255
--- 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
--- 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 #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 #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 #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 #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 #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]>
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 #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
--- 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 #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 #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 #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 #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 #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 #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
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 #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.
--- 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 #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 #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 #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 #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
--
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 #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
101 - 164 of 164 matches
Mail list logo
