The following code gives:
t.f90:41.12:
call sub ( shape_line_P1 )
1
Error: Type/rank mismatch in argument 'sub1' at (1)
I tested ifort, lahey, g95 without any problem.
module int_m
interface shape_line_P1
module procedure shape_line_P1, shape_line_P1_2
end interface
contai
--- Comment #4 from dorit at gcc dot gnu dot org 2007-10-21 06:39 ---
I was able to reproduce this on i386-linux.
Looks like it's related to PLUS_EXPR vs. POINTER_PLUS_EXPR. The folowing patch
fixes this testcase:
Index: tree-vect-analyze.c
=
--- Comment #4 from tbm at cyrius dot com 2007-10-21 06:25 ---
Here's another one (requires -O3):
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
extern int sscanf (__const char *__restrict __s,
__const char *__restrict __format, ...);
unsigned char got_elevati
--- Comment #3 from tbm at cyrius dot com 2007-10-21 06:05 ---
Starting program: /home/tbm/tmp/gcc/gcc-4.3-20071020-r129504/gcc/cc1 -O2
-ftree-vectorize ~/allegro-mixer.c
clamp_val _mix_some_samples
Analyzing compilation unit
Performing interprocedural optimizations
Assembling
--- Comment #2 from tbm at cyrius dot com 2007-10-21 06:05 ---
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
/* { dg-do compile } */
/* { dg-options "-O2 -ftree-vectorize" } */
int clamp_val (int i)
{
return ~i >> 31;
}
void _mix_some_samples (long buf, int *mix_buffer, int m
--- Comment #1 from tbm at cyrius dot com 2007-10-21 06:03 ---
Created an attachment (id=14379)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14379&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33846
I see the following ICE with current trunk and with trunk from
2007-09-16. It doesn't happen with 2007-09-02.
(sid)29744:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -Wall -O2
-ftree-vectorize -c allegro-mixer.c
allegro-mixer.c: In function '_mix_some_samples':
allegro-mixer.c:19: internal
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-10-21 03:34
---
Tobias, is this what you meant in your original comment that should work?
module m
implicit none
interface
double precision function my1(x)
double precision, intent(in) :: x
end function my1
end
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-10-21 03:29
---
The original test case here no longer gives an ICE.
The case on Comment #2 does ICE
pr32129-a.f90: In function MAIN__:
pr32129-a.f90:11: internal compiler error: in gfc_trans_call, at
fortran/trans-stmt.c:320
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-10-21 00:15
---
This patch:
Index: interface.c
===
--- interface.c (revision 129496)
+++ interface.c (working copy)
@@ -1679,8 +1679,9 @@ compare_actual_formal (gfc
--- Comment #1 from bangerth at dealii dot org 2007-10-20 23:36 ---
The code should be invalid precisely because this is also invalid:
---
template struct A;
void foo()
{
A<0>;
}
---
g/x> c++ -c x.cc
x.cc: In function 'void foo()':
x.cc:5: error: decla
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot
|dot org
Valgrind gives this:
==28681==
==28681== 25,120 (14,664 direct, 10,456 indirect) bytes in 325 blocks are
definitely lost in loss record 8 of 10
==28681==at 0x4A05996: malloc (vg_replace_malloc.c:149)
==28681==by 0xB26057: xmalloc (xmalloc.c:147)
==28681==by 0x445B04: gfc_getmem (misc.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33844
The C++ generates a broken diagnostic for the following invalid code
snippet since GCC 3.4.0:
=
struct A {};
template void foo(void (A::* f)())
{
A a;
&(a.*f);
}
=
bug.cc: In function 'void foo(void (A::*)())':
bug.cc:6
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33843
The C++ generates a broken diagnostic for the following invalid code
snippet since GCC 3.4.2:
=
struct A {};
void foo(A* p())
{
p->A::~A();
}
=
bug.cc: In function 'void foo(A* (*)())':
bug.cc:5: error: request for member
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33842
The C++ generates a broken diagnostic for the following invalid code
snippet since GCC 4.0.0:
=
template struct A
{
A<__builtin_offsetof(T, x)>();
};
=
bug.cc:3: error: type/value mismatch at argument 1 in template paramete
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33841
The following invalid code snippet triggers an ICE since GCC 4.2.0:
===
template struct A
{
struct {} : 2;
};
struct B : A<0> {};
===
bug.cc: In instantiation of 'A<0>':
bug.cc:6: instantiated from here
bug.cc:3: error: bit-field 'A<0>:
The following invalid code snippet is accepted since at least GCC 2.95.3:
===
template struct A
{
struct {} : 2;
};
===
--
Summary: bit-field size accepted for struct
Product: gcc
Version: 4.3.0
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33839
The following code snippet triggers an ICE on mainline
(I'm not sure whether this is valid or not):
===
template struct A;
void foo()
{
__decltype A<0>;
}
===
bug5.cc: In function 'void foo()':
bug5.cc:9: internal compiler error: in cp_pa
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33838
The following invalid code snippet triggers an ICE on mainline:
===
template struct A
{
__decltype (T* foo());
};
===
bug.cc:3: error: expected primary-expression before '*' token
bug.cc:3: error: there are no arguments to 'foo' that depen
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33837
The following invalid code snippet triggers an ICE on mainline:
===
void foo()
{
__decltype A::foo();
}
===
bug.cc: In function 'void foo()':
bug.cc:3: error: 'A' was not declared in this scope
bug.cc:3: internal compiler error: tree check
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33836
The following invalid code snippet triggers an ICE since GCC 3.4.0:
===
template struct A
{
enum { M = && N };
};
A<0> a;
===
bug.cc:3: error: label 'N' referenced outside of any function
bug.cc: In instantiation of 'A<0>':
bug.cc:6: in
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-10-20 21:12 ---
Support for this was added for -std=c++0x .
See:
http://gcc.gnu.org/gcc-4.3/cxx0x_status.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14031
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-20
20:53 ---
Subject: Re: New:
gcc.c-torture/execute/longlong.c execution at -O3
Comparing 4.2 to 4.3, the significant difference in main appears to be:
4.2)
ldw 140(%r20),%r19 ;, tmp115
--- Comment #9 from rguenther at suse dot de 2007-10-20 20:52 ---
Subject: Re: [4.3 Regression] Exponential time
behavior in PRE
On Sat, 20 Oct 2007, dberlin at dberlin dot org wrote:
> --- Comment #8 from dberlin at gcc dot gnu dot org 2007-10-20 20:49
> ---
> Subject: Re:
--- Comment #8 from dberlin at gcc dot gnu dot org 2007-10-20 20:49 ---
Subject: Re: [4.3 Regression] Exponential time behavior in PRE
We may just want to disable PPRE of constants entirely :)
On 20 Oct 2007 10:14:53 -, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
--- Comment #2 from Markus dot Elfring at web dot de 2007-10-20 20:33
---
Why is it a "bad" idea to add more than the description
"--enable-languages=LIST specify which front-ends to build" to the top-level
configuration script?
--
Markus dot Elfring at web dot de changed:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from tbm at cyrius dot com 2007-10-20 19:51 ---
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
extern double cos (double x);
class bend_class
{
double *s_A;
public:
void set_s_A (double s_A0)
{
s_A[0] = s_A0;
}
};
class bend_set
{
bend_class *bend_a
--- Comment #1 from tbm at cyrius dot com 2007-10-20 19:51 ---
Starting program: /home/tbm/tmp/gcc/gcc-4.3-20071020-r129504/gcc/cc1plus -O
-ftree-vectorize ~/psicode-internals2.cc
void bend_class::set_s_A(double) void bend_set::set_s_A(int, double) void
bend_set::compute_s() void
Using a slightly modified version of the testcase from PR33834
I get a segfault in vect_is_simple_use. Unlike the other PR, which
goes back several months, this ICE doesn't happen with 20070916
(but with current trunk). It also triggers at -O rather than -O2
(and -ftree-vectorize, obviously).
(s
--- Comment #3 from tbm at cyrius dot com 2007-10-20 19:49 ---
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
extern double cos (double x);
extern double sin (double x);
class bend_class
{
double *s_A;
public:
void set_s_A (double s_A0)
{
s_A[0] = s_A0;
}
};
class b
--- Comment #2 from tbm at cyrius dot com 2007-10-20 19:48 ---
Created an attachment (id=14376)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14376&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33834
--- Comment #1 from tbm at cyrius dot com 2007-10-20 19:48 ---
Starting program: /home/tbm/tmp/gcc/gcc-4.3-20071020-r129504/gcc/cc1plus -O2
-ftree-vectorize ~/psicode-internals.cc
void bend_class::set_s_A(double) void bend_set::set_s_A(int, double) void
bend_set::compute_s() void
I get the following ICE with current trunk and -O2 -ftree-vectorize.
I see this ICE with gcc from trunk going back to 2007-04-22, but
not with 2007-03-26.
(sid)29591:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O2
-ftree-vectorize
psicode-internals.cc
psicode-internals.cc: In member fu
--- Comment #2 from hjl at lucon dot org 2007-10-20 19:31 ---
(In reply to comment #1)
> Actually there are 15 packages that fail out of 2500 because of this, another
> 6 from the ext/hash_fun.h move. I can't tell if in the other 400 packages
> that
> fail with 4.3 for various reasons
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-20 19:25 ---
All of the objective-C++ failures are filed in different bug reports already.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33830
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-20 19:24 ---
This is listed on the GCC subdirectory's configure.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from nightstrike at gmail dot com 2007-10-20 19:12 ---
Explicit paths for mingw for as and ld should not be required. We fixed this
for mingw-w64, and the same thing should be applied to mingw32. This same
error occurs regardless of whether or not you are in a mingw envi
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33833
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-20 18:48 ---
Actually there are 15 packages that fail out of 2500 because of this, another
6 from the ext/hash_fun.h move. I can't tell if in the other 400 packages that
fail with 4.3 for various reasons there are more cases of
--- Comment #3 from tbm at cyrius dot com 2007-10-20 18:23 ---
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
struct list_head
{
struct list_head *prev;
};
struct prio_array
{
struct list_head queue[100];
};
struct rq
{
struct prio_array *active, arrays[2];
} per_cpu__runq
--- Comment #2 from tbm at cyrius dot com 2007-10-20 18:22 ---
Created an attachment (id=14375)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14375&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33833
--- Comment #1 from tbm at cyrius dot com 2007-10-20 18:22 ---
(gdb) run -O3 ~/linux-sched.c
Starting program: /home/tbm/tmp/gcc/gcc-4.3-20071020-r129504/gcc/cc1 -O3
~/linux-sched.c
sched_init
Analyzing compilation unit
Performing interprocedural optimizations
Assembling functions
I'm getting the following ICE with current trunk. This doesn't happen
with gcc 4.2 or with trunk from 2007-09-16. The ICE message is the
same as in PR33453 but the backtrace looks completely different.
(sid)29299:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -O3 -c
linux-sched.c
linux-sche
--- Comment #26 from hjl at lucon dot org 2007-10-20 16:05 ---
(In reply to comment #25)
> HJ, does applying the patch from comment #6 bring back performance to 4.1 RH
> level?
>
It makes no difference. I saw 20% slowdown in 437.leslie3d on Intel Core
2 Duo 64bit between revision 11789
Revision 129442
http://gcc.gnu.org/ml/gcc-cvs/2007-10/msg00547.html
moved a few header files from include/ext to include/backward, which
introduced a new libstdc++ API. If a C++ applications want to support
both 4.2 and 4.3 APIs, it needs a way to tell different APIs, something
like
#if GLIBCXX
Revision 129442
http://gcc.gnu.org/ml/gcc-cvs/2007-10/msg00547.html
removed many libstdc++ header files from include/backward. That means gcc 4.3
has a different API. It breaks many C++ applications which use the current
libstdc++ API.
--
Summary: [4.3 Regression] Revision 129442 br
I have tried another language selection on my openSUSE 10.3 system.
Linux Sonne 2.6.22.9-0.4-default #1 SMP 2007/10/05 21:32:04 UTC x86_64 x86_64
x86_64 GNU/Linux
[EMAIL PROTECTED]:~/Projekte/GNU/GCC/erzeugt/4.2.2/kein_Ada>
~/Projekte/GNU/GCC/Quellen/4.2.2/configure
--enable-languages=c,c++,fortran
--- Comment #5 from alexandre dot nunes at gmail dot com 2007-10-20 13:35
---
(In reply to comment #4)
> (In reply to comment #2)
> > The standard puts all the burden on the implementation (See 6.7.2.1/10).
> > The GCC manual in turn says the behavior is specified by the ABI (4.9
> > St
--- Comment #12 from amodra at bigpond dot net dot au 2007-10-20 13:12
---
Patch applied
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
Sta
--- Comment #11 from amodra at gcc dot gnu dot org 2007-10-20 13:11 ---
Subject: Bug 33812
Author: amodra
Date: Sat Oct 20 13:11:14 2007
New Revision: 129511
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129511
Log:
PR target/33812
* config/rs6000/rs6000.c (rs60
--- Comment #4 from alexandre dot nunes at gmail dot com 2007-10-20 12:55
---
(In reply to comment #2)
> The standard puts all the burden on the implementation (See 6.7.2.1/10).
> The GCC manual in turn says the behavior is specified by the ABI (4.9
> Structures, unions, enumerations, a
--- Comment #4 from pcarlini at suse dot de 2007-10-20 12:33 ---
*** Bug 33729 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
-
--- Comment #1 from pcarlini at suse dot de 2007-10-20 12:33 ---
*** This bug has been marked as a duplicate of 31747 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from alexandre dot nunes at gmail dot com 2007-10-20 12:20
---
(In reply to comment #2)
> The standard puts all the burden on the implementation (See 6.7.2.1/10).
> The GCC manual in turn says the behavior is specified by the ABI (4.9
> Structures, unions, enumerations, a
--
Summary: HOST_HOOKS_GT_PCH_GET_ADDRESS is missing from the
documentation index
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: documentation
Severity: minor
Priority: P3
Componen
--- Comment #7 from burnus at gcc dot gnu dot org 2007-10-20 11:39 ---
FIXED on the trunk (4.3.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from burnus at gcc dot gnu dot org 2007-10-20 11:34 ---
Subject: Bug 33818
Author: burnus
Date: Sat Oct 20 11:34:21 2007
New Revision: 129510
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129510
Log:
2007-10-20 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #12 from pcarlini at suse dot de 2007-10-20 11:27 ---
(In reply to comment #11)
> I just tested this. It does a much better job at obfuscating the bias, which
> is
> still there (after all you are rescaling linearly). If you rescale a domain of
> size 16 to a range of size
--- Comment #6 from steven at gcc dot gnu dot org 2007-10-20 11:13 ---
Again from gcse.c:compute_transpout():
static void
compute_transpout (void)
{
basic_block bb;
unsigned int i;
struct expr *expr;
sbitmap_vector_ones (transpout, last_basic_block);
FOR_EACH_BB (bb)
{
--- Comment #5 from steven at gcc dot gnu dot org 2007-10-20 11:10 ---
>From gcse.c:compute_transpout()
/* Note that flow inserted a nop a the end of basic blocks that
end in call instructions for reasons other than abnormal
control flow. */
if (! CALL_P (
--- Comment #4 from steven at gcc dot gnu dot org 2007-10-20 11:08 ---
In gcse.c:compute_code_hoist_vbeinout(), the backward dataflow analysis problem
is solved using FOR_EACH_BB_REVERSE. which traverses all basic blocks through
the bb->prev_bb chain. Because the passes in gcse.c run in
--- Comment #11 from jkherciueh at gmx dot net 2007-10-20 11:07 ---
(In reply to comment #6)
> Actually, would be:
>
> Index: random
> ===
> --- random (revision 129456)
> +++ random (working copy)
> @@ -1607,7 +1
--- Comment #3 from steven at gcc dot gnu dot org 2007-10-20 10:54 ---
There is a discrepancy between the code in gcse.c:hoist_expr_reaches_here_p()
and the comment before it. Quoting:
/* Determine if the expression identified by EXPR_INDEX would
reach BB unimpared if it was placed
--- Comment #2 from steven at gcc dot gnu dot org 2007-10-20 10:48 ---
A second issue with code hoisting in gcse.c is that it only looks at basic
blocks immediately dominated by the branch point to hoist to. Quoting
gcse.c:hoist_code():
/* Walk over each basic block looking for poten
--- Comment #1 from steven at gcc dot gnu dot org 2007-10-20 10:37 ---
The first issue with code hoisting is that it can only hoist lexically
equivalent expressions. This means that dependent expressions that compute the
same value can unfortunately not be hoisted in one pass. Example:
This bug report about quality of implementation issues with the implementation
of code hoisting for RTL, which lives in gcse.c.
--
Summary: Issues with the implementation of code hoisting in
gcse.c
Product: gcc
Version: 4.3.0
Statu
--- Comment #10 from tkoenig at gcc dot gnu dot org 2007-10-20 10:17
---
I am tempted not to use gamma*() at all, but rather
check for tgamma*() and lgamma*() and use that
if available. If none of them are present, use
a fallback implementation.
This avoids potential problems with cro
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-10-20 10:14 ---
I guess we just compute all 2**26 constants that can end up at the conditional
store. And indeed, the number of 'Created value .*' in the dump matches this
(modulo some constant offset). This is PPRE at work, which
--- Comment #9 from tkoenig at gcc dot gnu dot org 2007-10-20 10:06 ---
Mine.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #10 from pcarlini at suse dot de 2007-10-20 10:05 ---
Fixed for 4.2.3.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from paolo at gcc dot gnu dot org 2007-10-20 10:03 ---
Subject: Bug 33815
Author: paolo
Date: Sat Oct 20 10:03:10 2007
New Revision: 129508
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129508
Log:
2007-10-20 Paolo Carlini <[EMAIL PROTECTED]>
* include
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-20 10:03 ---
foo is analyzed to be const by ipa-pure-const and so the self-recursive call
is DCEd. Now one could argue that foo indeed _is_ const, for example
unsigned foo(unsigned i)
{
if (i == 1)
return 1;
return foo(
--- Comment #8 from paolo at gcc dot gnu dot org 2007-10-20 10:02 ---
Subject: Bug 33815
Author: paolo
Date: Sat Oct 20 10:02:34 2007
New Revision: 129507
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129507
Log:
2007-10-20 Paolo Carlini <[EMAIL PROTECTED]>
* include
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-10-20 09:57
---
Please.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNC
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-10-20 09:56
---
Please.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNC
--- Comment #4 from Markus dot Elfring at web dot de 2007-10-20 09:48
---
I do not need to get informed here about useless targets for the selected
language. I find an explicit warning even more confusing in this case.
--
Markus dot Elfring at web dot de changed:
What
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-20 09:47 ---
The standard puts all the burden on the implementation (See 6.7.2.1/10).
The GCC manual in turn says the behavior is specified by the ABI (4.9
Structures, unions, enumerations, and bit-fields), which would be the sys
--- Comment #4 from Markus dot Elfring at web dot de 2007-10-20 09:43
---
The warning confuses me a bit. I do not not need its information if I should
ignore it.
--
Markus dot Elfring at web dot de changed:
What|Removed |Added
--- Comment #25 from rguenth at gcc dot gnu dot org 2007-10-20 09:38
---
HJ, does applying the patch from comment #6 bring back performance to 4.1 RH
level?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
--- Comment #36 from pault at gcc dot gnu dot org 2007-10-20 09:35 ---
Sorry I took a bit of time to do it - fixed on trunk.
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #35 from pault at gcc dot gnu dot org 2007-10-20 09:27 ---
Subject: Bug 31608
Author: pault
Date: Sat Oct 20 09:27:09 2007
New Revision: 129505
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129505
Log:
2007-10-20 Paul Thomas <[EMAIL PROTECTED]>
FX Coud
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-10-20 09:20
---
> Why is there a warning if unsupported targets will be excluded?
To make it explicit that they will?
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from schwab at suse dot de 2007-10-20 09:04 ---
Probably the same as PR29127.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33820
--- Comment #2 from Markus dot Elfring at web dot de 2007-10-20 09:03
---
The design is not clear as it seems for you:
Are these targets needed for Ada?
Why is there a warning if unsupported targets will be excluded?
--
Markus dot Elfring at web dot de changed:
What|
--- Comment #3 from schwab at suse dot de 2007-10-20 08:59 ---
They don't do any harm.
--
schwab at suse dot de changed:
What|Removed |Added
Status|UNCONFIRME
--- Comment #2 from Markus dot Elfring at web dot de 2007-10-20 08:55
---
I do not want the Ada targets and corresponding configuration checks in this
use case if I exclude Ada from the language selection.
--
Markus dot Elfring at web dot de changed:
What|Removed
--- Comment #6 from tbm at cyrius dot com 2007-10-20 08:02 ---
Adding Danny to CC since this is not yet fixed.
--
tbm at cyrius dot com changed:
What|Removed |Added
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-10-20 08:02
---
> Is it usual that more features get unsupported as the warning indicates if I
> limit my language selection for test purposes?
Yes, it works as designed.
--
ebotcazou at gcc dot gnu dot org changed:
1 - 100 of 103 matches
Mail list logo
