--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
06:51 ---
Hmm, but vectors are not consider as aggregates.
at the tree level right before optimization, we have:
A_6 = {1.299523162841796875e+0, 1.299523162841796875e+0,
1.299523162841796875e+0, 1.2
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
06:36 ---
Another way to fix this would have copy-propagation for aggregates, see PR
14295.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
06:31 ---
I Have a fix which I will posting in the morning.
--
What|Removed |Added
AssignedTo|
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-14
06:31 ---
Fixed on mainline.
--
What|Removed |Added
Status|NEW |R
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
06:25 ---
"as promoted according to the default argument promotions" is what makes this
undefined by the way.
char is promoted to int.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10719
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-14
06:15 ---
> I still say generating code that is not executable is a ridiculous way to
> handle this ambiguity in the standard...
You still don't get the point. Read again comment #2, the bottom line is that
it's
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
05:16 ---
(In reply to comment #0)
> if ((DECL_CONTEXT (decl) && TREE_CODE (DECL_CONTEXT (decl))
>== FUNCTION_DECL)
One more thing is that the DECL_CONTEXT at the point where we call the function
t
Take the following code:
void f(void)
{
int a __attribute__((model(small)));
}
We should reject the attribute but don't as of today even though the code in
ia64.c thinks it should be
rejected:
case VAR_DECL:
if ((DECL_CONTEXT (decl) && TREE_CODE (DECL_CONTEXT (decl))
== FU
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-14
05:12 ---
Subject: Bug 19358
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-14 05:12:12
Modified files:
gcc/fortran: trans-array.c ChangeLog
gcc/
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-14
03:22 ---
Subject: Bug 21674
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-14 03:22:17
Modified files:
libstdc++-v3 : ChangeLog
Added files:
libst
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-09-14
02:49 ---
I have a patch for the alias portion of this
--
What|Removed |Added
AssignedTo|unass
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22068
--- Additional Comments From dje at gcc dot gnu dot org 2005-09-14 01:28
---
Patch committed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-14
01:12 ---
Subject: Bug 22068
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-14 01:12:48
Modified files:
gcc: ChangeLog
gcc/config/rs6000:
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org
|dot org |
Status|NEW
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
Status|UNCONFIRMED
DR117 is not implemented in the same way of DR118: operator<<(short) calls
operator<<(long), operator<<(unsigned short) calls operator<<(unsigned long),
operator<<(int) calls operator<<(long), etc... I think the way we implemented
DR118 is better (i.e., following the letter of the resolution, with
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
00:42 ---
Hmm, in 4.0.0, we have about 6,800 SSA_NAMEs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
00:35 ---
Hmm, in 4.0.0, we take a nice time at -O3.
may_alias took only:
tree alias analysis : 0.28 ( 3%) usr 0.01 ( 1%) sys 0.21 ( 2%) wall
Total time:
TOTAL : 8.55 1.04
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
00:32 ---
[20:26] < pinskia> but 38% are in compute_may_aliases
[20:27] < pinskia> and 80% of that is in the loop which is going through all
SSA_NAMES
[20:27] < pinskia> this is in create_name_tags
[20:28] < pinskia>
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-14
00:25 ---
Subject: Bug 23180
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-14 00:25:02
Modified files:
gcc/testsuite : ChangeLog
Added files:
gcc/t
--- Additional Comments From appfault at hotmail dot com 2005-09-14 00:16
---
Ok, disregard comment 16, the issue I saw was the same as comment 0.
Unfortunately, there was a '-w' sneakily in a 3rd-party makefile which hid the
warning. Maybe I should open another zilla for warning you
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
23:29 ---
(In reply to comment #8)
> We have at least 5 SSA_NAMEs, that is just huge. We have only V_MAY_DEFs
> for .GLOBAL_VAR
> and a TMT.
Over half, 40,000 are scalars registers.
--
http://gcc.gnu.org/bu
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-13 23:21
---
It was discovered that to use string, you have to do all this magic with the
debug mode that involves not using extern template and a bunch of the other
linkage optimizations. There were some PRs about this.
--- Additional Comments From tprince at computer dot org 2005-09-13 23:15
---
Created an attachment (id=9726)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9726&action=view)
include files from libgfortran, required in build
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23845
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
23:13 ---
We have at least 5 SSA_NAMEs, that is just huge. We have only V_MAY_DEFs
for .GLOBAL_VAR and
a TMT.
This happens on all targets and not just ia64.
--
What|Removed
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-13 23:09 ---
Additional data:
For the testcase in PR8361:
size -f generate-3.4*.o
textdata bss dec hex filename
297025 4 181 297210 488fa generate-3.4-4.0.o
318366 8
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
23:02 ---
(In reply to comment #4)
>/* We can't use regparm(3) for nested functions as these use
> static chain pointer in third argument. */
>if (local_regparm == 3 && DECL_CONTEXT (decl)
>&& !
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-13 22:57 ---
(In reply to comment #6)
> Maybe a better check would be check in the decl's function struct's
> field
> static_chain_decl is set.
I am not sure I understand what you mean here...
Maybe adding
--- Additional Comments From pinskia at physics dot uc dot edu 2005-09-13
22:49 ---
Subject: Re: local calling convention not used when using -fwhole-program
--combine
On Sep 13, 2005, at 6:36 PM, dann at godzilla dot ics dot uci dot edu
wrote:
>
> --- Additional Comments From
On Sep 13, 2005, at 6:36 PM, dann at godzilla dot ics dot uci dot edu
wrote:
--- Additional Comments From dann at godzilla dot ics dot uci dot
edu 2005-09-13 22:36 ---
It looks like the -fwhole-program version of ClearLeft only passes the
first 2 arguments to the ClearInLine call
--- Additional Comments From pinskia at physics dot uc dot edu 2005-09-13
22:41 ---
Subject: Re: local calling convention not used when using -fwhole-program
--combine
On Sep 13, 2005, at 6:36 PM, dann at godzilla dot ics dot uci dot edu
wrote:
>
> But the above just fixes the symp
On Sep 13, 2005, at 6:36 PM, dann at godzilla dot ics dot uci dot edu
wrote:
But the above just fixes the symptoms, it's probably not the correct
way to test for a nested function.
DECL_NO_STATIC_CHAIN (decl) should be true for this function but
why is it not?
/* In a FUNCTION_DECL with
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
22:37 ---
The main function is huge, no wonder this takes more time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-13 22:36 ---
It looks like the -fwhole-program version of ClearLeft only passes the
first 2 arguments to the ClearInLine call in register, the 3rd one is
passed on the stack.
The reason for that is this code i
--- Additional Comments From pcarlini at suse dot de 2005-09-13 22:27
---
Yes, for 4.0.3 backporting only those bits would make sense. Thanks Janis for
testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23871
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
22:18 ---
tree alias analysis : 5.56 (17%) usr 0.07 ( 8%) sys 5.66 (17%) wall
13812 kB ( 3%) ggc
tree SSA incremental : 3.15 (10%) usr 0.01 ( 2%) sys 3.18 (10%) wall
8152 kB ( 2%) ggc
hmm, we
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
22:09 ---
Can you run with -ftime-report and attach the results?
--
What|Removed |Added
Keyw
--- Additional Comments From jaffe at broad dot mit dot edu 2005-09-13
22:03 ---
We recompiled gcc 4.1.0 with checking disabled. The results are now less
dramatic but still of concern: optimized 4.1.0 compiles take about twice as
long as 3.4.3 compiles on the test case:
Compile time
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13
21:46 ---
Subject: Bug 17740
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-13 21:46:04
Modified files:
gcc/fortran: ChangeLog trans-expr.c
gcc/t
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
21:13 ---
(In reply to comment #13)
> Are there remaining issues with them?
Yes, it does not work when configuring gcc with --with-cpu=pentium4 see PR
19161.
--
What|Removed |Add
--- Additional Comments From fjahanian at apple dot com 2005-09-13 21:09
---
Hello,
What is the status of Uros's patches in:
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01128.html
Looks like they did not make it to FSF mainline? Are there remaining issues
with them?
--
http://
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-13 20:45 ---
The fact that the dump is different depending on function order or compilation
flags seems to point to either an uninitialized variable or some memory
corruption.
--
http://gcc.gnu.org/bugzil
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
20:32 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
20:31 ---
Confirmed, just the subreg issue.
--
What|Removed |Added
BugsThisDependsOn|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
20:28 ---
>int result = 0; <--- this line appears twice...
That is because there is DECL_EXPR there and you just don't see it.
This is all really a front-end issue.
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
20:26 ---
Confirmed, a regression from 3.4.0. Just a note, 4.0 branch is frozen right
now.
--
What|Removed |Added
Using gcc -O2 -fdump-tree-all -S
to compile:
int bar (void) { return 0;}
int foo (int reject) { int result = 0; return result;}
the .t02.original dump looks like:
;; Function bar (bar)
;; enabled by -tree-original
{
return 0;
}
;; Function foo (foo)
;; enabled by -tree-original
{
int
and the current 4.0 branch with:
elm3b11% /opt/gcc-nightly/4.0/bin/g++ -c bug.cc
/home/gcc-nightly/4.0-20050913/bin/../lib/gcc/powerpc64-linux/4.0.2/../../../../include/c++/4.0.2/ostream:
In member function std::basic_ostream<_
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
20:21 ---
Confirmed.
We should recognized that __builtin_stack_restore at the end of the function is
not needed. This should
be done while doing CFG exand.
--
What|Removed |Adde
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-13 20:20
---
Mine.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot g
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-13 20:19
---
Created an attachment (id=9723)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9723&action=view)
Checks for libiconv_ open and close functions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22339
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
20:18 ---
Confirmed, I don't know how offten this shows up but what I have seen from
compiling GCC, is that it
does not show up at all.
--
What|Removed |Added
---
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-13 20:18
---
Is this in reference to _GLIBCXX_USE_ICONV?
That is only useful for the codecvt specializations that use iconv. As of 4.0.0,
this is in libstdc++-v3/include/ext/codecvt_specializations.h.
Or is this in refe
--
What|Removed |Added
CC||nathan at gcc dot gnu dot
||org
Keywords|
--
What|Removed |Added
GCC build triplet|i686-pc-linux-gnu |
GCC host triplet|i686-pc-linux-gnu |
GCC target triplet|sh64-unknown-linux-gnu |sh64-*-linux
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
20:15 ---
Confirmed. After IPA constant prop and before inlining, we need early
optimizations, like DCE and
constant prop. But that is it.
--
What|Removed |Added
---
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-13
20:11 ---
*** Bug 17123 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-13
20:11 ---
This has been fixed on mainline by the patch for PR 19928.
As noted there PR 17123 really seems to be a duplicate.
*** This bug has been marked as a duplicate of 19928 ***
--
What|Removed
--
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855
--- Additional Comments From fredrik at hederstierna dot com 2005-09-13
20:08 ---
This bug only shows when you compile with -O3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23870
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
20:03 ---
Confirmed.
--
What|Removed |Added
URL||http://gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
20:03 ---
Confirmed.
--
What|Removed |Added
URL||http://gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
19:59 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
19:58 ---
Confirmed, note I did add this to the patch queue:
http://www.dberlin.org/cgi-bin/patches.py
--
What|Removed |Added
--
--
What|Removed |Added
Component|c |other
GCC host triplet|Linux Fedora Core3 kernel |i686-pc-linux-gnu
|2.6.9
When I try to compile any of these functions below, GCC 3.4.4 hangs the whole
computer! I was needed to reboot my Feodore Core3 system - severe memory leak?
I'm compiling on a Linux machine running Feodore Core3 kernel 2.6.9.
The compiler is arm-elf-gcc-3.4.4 compiled with binutils-2.16.1, newlib-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
19:52 ---
Confirmed, a known issue. Related to PR 15911. and Really is caused by not
doing PR 15357 late in the
game.
--
What|Removed |Added
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-09-13 19:51 ---
Fixed.
--
What|Removed |Added
Status|NEW |RES
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
19:48 ---
Fixed on the mainline and since this is not a regression closing as fixed.
Fixed with 4.1.0 20050802 and 4.1.0 20050714.
--
What|Removed |Added
-
On x86 architectures, when the target is -march=pentium or higher, the compiler
seems to replace (x || y) by ((x | y) != 0) too soon for optimizations to apply,
when x and y are integers.
Testcase (compiled with "gcc -O3 -march=something"):
typedef int T;
void g(T);
void f(T x, T y) {
if (x ||
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
19:45 ---
Hmm, we are trying to gimplify a SCEV tree:
() ((long unsigned intD.7) {0, +, D.2009_8}_2 * 8)
--
What|Removed |Added
---
--
What|Removed |Added
Component|c++ |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21274
--
What|Removed |Added
GCC target triplet||x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21274
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-13 19:40
---
Mine.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot g
--
What|Removed |Added
GCC build triplet||sparc-sun-solaris2.9
GCC host triplet||sparc-sun-solaris2.9
http://gcc.gnu.org/
--
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
||patches/2005-
|
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-13 19:35
---
Mine.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot g
apply_result_size uses reg_raw_mode for every register that is flagged with
FUNCTION_VALUE_REGNO_P. However, reg_raw_mode is the mode to save a single
hard register, while a return value can be held in multiple consecutive hard
registers, and FUNCTION_VALUE_REGNO_P has to be true only for the firs
--
What|Removed |Added
Known to fail||3.4.0
Summary|linking error while |linking error while
|compiling ddd wit
--
What|Removed |Added
Known to work||3.3.2
Summary|linking error while |linking error while
|compiling ddd wit
--- Additional Comments From callahan at sci dot utah dot edu 2005-09-13
19:32 ---
Subject: Re: SSA Crash, reproducable
This still crashes for me with the latest Ubuntu g++ build.
g++ (GCC) 4.0.2 20050808 (prerelease) (Debian 4.0.1-4ubuntu6)
The error is the same, but the crash is li
--
What|Removed |Added
GCC target triplet||sparc-sun-solaris2.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22612
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-13 19:29
---
Moving to c++ component, maybe they can help him...
--
What|Removed |Added
Component|
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13
19:23 ---
Subject: Bug 23734
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-13 19:22:52
Modified files:
libstdc++-v3 : ChangeLog
libstdc++-v3/inclu
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13
19:23 ---
Subject: Bug 22554
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-13 19:22:52
Modified files:
libstdc++-v3 : ChangeLog
libstdc++-v3/inclu
The libstdc++ ABI testsuite does not work when testing an installed compiler
because:
* abi.exp checks for "../src/.libs/libstdc++.so", which of course is not
available with an installed compiler.
* abi.exp requires baseline_file to be set in site.exp; with installed compiler
testing, site.exp is
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-13
19:19 ---
Just for the record:
This was fixed by Richard Sandiford's patch for PR19239:
http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00346.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21063
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13
19:03 ---
Subject: Bug 19358
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-13 19:02:57
Modified files:
gcc/fortran: trans-
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13
19:02 ---
Subject: Bug 23816
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-13 19:02:05
Modified files:
gcc: ChangeLog
gcc/config/i386: s
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
18:51 ---
This is what we get one the mainline:
.L4:
movl(%ecx), %eax
addl$4, %ecx
movl%eax, (%edi,%edx,4)
movl(%ebp,%edx,4), %eax
movl%eax, (%esi,%edx,4)
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-13
18:29 ---
Please provide a standalone testcase.
gcc -O2 -S matmul_r8.c
matmul_r8.c:31:20: error: config.h: No such file or directory
matmul_r8.c:35:25: error: libgfortran.h: No such file or directory
matmul_r8.c:49:
--- Additional Comments From janis at gcc dot gnu dot org 2005-09-13 18:17
---
I'm still looking at this. My earlier comment about having fixed it on
mainline was wrong; I thought it was a problem in altivec.h, but it's in
the compiler itself and this problem never showed up on mainline
--
What|Removed |Added
Attachment #9720 is|1 |0
patch||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297
--- Additional Comments From benjamin at smedbergs dot us 2005-09-13 16:34
---
Created an attachment (id=9720)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9720&action=view)
Failure even with the latest patch
I'm wrong. attachment 9035 fixes the compile errors in the main mozilla
--- Additional Comments From macro at linux-mips dot org 2005-09-13 16:06
---
Created an attachment (id=9719)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9719&action=view)
gcc-4.0.1-fortran-form-free.patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23862
When "-pipe" is used for .F90 and .F95 sources this warning is produced:
Warning: Reading file '' as free form.
The reason is the compiler cannot deduce the form from the file name
suffix as in this case it's only known to the preprocessor.
Here is an obvious patch following the approach used
--- Additional Comments From macro at linux-mips dot org 2005-09-13 16:03
---
Created an attachment (id=9718)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9718&action=view)
gcc-4.0.1-specs-pipe-suffix.patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23861
Bootstrapping with Fortran enabled fails for 4.0.1 if "-pipe" is included
among flags passed through to library builds. It used to work for 4.0.0.
The reason is "libgfortran/intrinsics/f2c_specifics.F90", which is new to
4.0.1, and the "%|" operator used in the specs
("gcc/fortran/lang-specs.
1 - 100 of 150 matches
Mail list logo
