--- Comment #6 from uros at gcc dot gnu dot org 2007-03-15 07:25 ---
Subject: Bug 31167
Author: uros
Date: Thu Mar 15 07:25:22 2007
New Revision: 122945
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122945
Log:
PR target/31167
* config/i386/i386.md (*addti3_1,
--- Comment #7 from dominiq at lps dot ens dot fr 2007-03-15 08:24 ---
And Dominique, I would appreciate if you could test the patch on ppc-darwin7.
So far all the tests passed. I am doing a full regtesting of gfortran, but I do
not expect any new failure.
Thanks for the fix.
--
--- Comment #5 from dominiq at lps dot ens dot fr 2007-03-15 08:34 ---
Can you check if the attached patch gives a more reasonable error?
I now get:
failure_v2.c: In function 'main':
failure_v2.c:15: sorry, unimplemented: no way to expand a call to 'cexpi'
but would not it be more
--- Comment #4 from burnus at gcc dot gnu dot org 2007-03-15 08:47 ---
(In reply to comment #3)
this issue now seems fixed on trunk for me as well, so I guess this could be
closed.
Mark FIXED based on this comment and on the fact that it works with gfortran
4.3, 4.2, 4.1.
--
--- Comment #8 from dominiq at lps dot ens dot fr 2007-03-15 08:52 ---
regtest results:
...
Running /Users/dominiq/test/gcc-4.3-20070309/gcc/testsuite/gfortran.dg/dg.exp
...
FAIL: gfortran.dg/large_real_kind_2.F90 -O0 execution test
...
FAIL: gfortran.dg/large_real_kind_2.F90 -Os
--- Comment #14 from pcarlini at suse dot de 2007-03-15 09:38 ---
Thanks Craig for all your additional info, I'll try to make further progress
myself over the next days...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-03-15 09:40 ---
Yes, I'll restore 4.2.0 behavior here. Though maybe falling back to a function
call to cexp would be more natural...
The Problem with Fortran and C++ is that they assume a C99 runtime and so they
effectively set
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-15 09:46 ---
Now find the file that was miscompiled to produce the differing assembly...
(at which point do the dumps start to look different, then exchange affected
object files for the stage1 variant and see if the difference
--- Comment #7 from dominiq at lps dot ens dot fr 2007-03-15 10:11 ---
Subject: Re: __builtin_cexpi is broken on Darwin
Yes, I'll restore 4.2.0 behavior here. Though maybe falling back to a
function
call to cexp would be more natural...
I agree (see below).
The Problem with
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-03-15 10:40 ---
I have no idea why it is not working properly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
--- Comment #9 from dominiq at lps dot ens dot fr 2007-03-15 11:33 ---
Subject: Re: __builtin_cexpi is broken on Darwin
I have no idea why it is not working properly.
Who could?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-03-15 11:37
---
Darwin people. Or at least someone with enough knowledge of ppc asm...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
cat bug.cc
int buf[256 * 9];
void f() {
for (int i = 0; i 256; ++i) {
for (int j = 0; j 8; ++j) {
buf[j + 1] = 0;
}
}
}
g++ -O3 -ftree-loop-linear bug.cc
bug.cc: In function 'void f()':
bug.cc:2: internal compiler error:
--- Comment #15 from pcarlini at suse dot de 2007-03-15 12:05 ---
(In reply to comment #13)
Exactly which CPP symbol: On this platform, to select the errno function,
/usr/include/errno.h requires
defined(_REENTRANT) || defined(_TS_ERRNO) || _POSIX_C_SOURCE - 0 =
199506L
--- Comment #2 from dsb at boyski dot com 2007-03-15 12:42 ---
This is because the default behavior is to preprocess in C mode but as I
mentioned it happens in assembler mode. If you add the flag '-x
assembler-with-cpp' you should see the reported result. My test case was in a
file with
--- Comment #3 from dsb at boyski dot com 2007-03-15 12:44 ---
(when I said this I meant to refer to the invalid token warnings)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31182
In the man page for gfortran, the option -fd-lines-as-comments is misspelled
as -fd-lines-as-comment (note the missing final s). This can also be seen
in the web documentation at page
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gfortran/Fortran-Dialect-Options.html#Fortran-Dialect-Options
--
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-03-15 12:57
---
Commited to 4.3, closing.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-15 12:59
---
(In reply to comment #1)
I have a patch to permit gfc_check_random_seed to deal with arguments
with the optional attribute set. I was waiting on pault's size0/size1
patch to hit the tree to see if it does the
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-15 13:05 ---
Seems to work for me. Any details on the architecture you tested on?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31183
--- Comment #2 from ubizjak at gmail dot com 2007-03-15 13:13 ---
(In reply to comment #1)
Seems to work for me. Any details on the architecture you tested on?
Target: i686-pc-linux-gnu
gcc version 4.3.0 20070315 (experimental)
g++ -O2 -S -ftree-loop-linear pr31183.cc
pr31183.cc
--- Comment #1 from kkojima at gcc dot gnu dot org 2007-03-15 13:16 ---
I've confirmed that the trunk and 4.2 compilers ice on the testcase
and 4.0 doesn't fail. So this is a 4.1/4.2/4.3 regression.
In the problematic case, sh_adjust_cost takes SET_DEST (PATTERN (dep_insn))
where
--- Comment #5 from aschorr at telemetry-investments dot com 2007-03-15
13:22 ---
FYI, I had this same problem trying to build gcc-4.1.2 on Solaris 8.
After a lot of experimentation, I found that it could be solved by
changing my PATH so that any invocations of 'make' will actually
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-15 13:40 ---
Ok, it's a HWI 32 issue then. The caller should use host_integerp () on the
tree before calling int_cst_value.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31183
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-15 13:44 ---
Uh:
static void
gather_interchange_stats (VEC (ddr_p, heap) *dependence_relations,
VEC (data_reference_p, heap) *datarefs,
struct loop *loop,
I'm using gcc compiler v3.4.3 to compile our custom product in Solaris Sparc
processor.
While executing in release mode, i'm receiving Bus Error where as in debug mode
i'm receiving signal SIGSECV.
I'm assuming that this could be a issue with data alignment issues with sparc
processor. Can you
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-15 13:59 ---
You need to ask your vendor about issues with such old gcc. If you are not
actively breaking alignment rules gcc should do fine by default.
--
rguenth at gcc dot gnu dot org changed:
What
When C_INCLUDE_PATH is defined and -I/usr/include is used, /usr/include should
have the precedence, but examples show that it is not taken into account.
vin:~ cat test.c
#include mpfr.h
vin:~ C_INCLUDE_PATH=/home/vlefevre/include gcc -E -I/usr/include test.c |
grep mpfr.h
# 1
The following code, which compiles fine on gcc 4.1.2 and I believe is valid,
fails on an up-to-date checkout from the 4.2 branch:
--
class foo { };
namespace
{
extern foo foo1;
foo foo1;
}
template foo *
class bar { };
bar foo1 bar1;
The following code triggers the gcc_assert (begin-expr_type == EXPR_ARRAY)
assertion in find_array_section (in expr.c):
module foo_mod
implicit none
character (len=1), parameter :: letters(2) = (/a,b/)
contains
subroutine concat(ivec)
integer, intent(in) :: ivec(:)
write (*,*) a // letters(ivec)
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-15 14:43 ---
This is blocked by the same fact as PR30317 in that ASSERT_EXPRs can only
assert half-ranges or single valued ranges. This makes the following prototype
not assert [0, prec) but [-INF, prec) instead :(
Index:
--- Comment #2 from baldrick at gcc dot gnu dot org 2007-03-15 14:49
---
Created an attachment (id=13208)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13208action=view)
Proposed fix
Bootstraps with all languages including Ada. Does not introduce any new
testsuite failures. I'd
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-03-15 15:12
---
Bootstraps with all languages including Ada. Does not introduce any new
testsuite failures. I'd appreciate it if the ACT people could pass it
through their regression test suite. I don't know if this
--- Comment #4 from baldrick at free dot fr 2007-03-15 15:16 ---
Subject: Re: tree-nested creates pointless static chains and trampolines when
the callgraph is non-trivial
Bootstraps with all languages including Ada. Does not introduce any new
testsuite failures. I'd appreciate
--- Comment #2 from kkumar dot pdtr at gmail dot com 2007-03-15 15:27
---
(In reply to comment #1)
You need to ask your vendor about issues with such old gcc. If you are not
actively breaking alignment rules gcc should do fine by default.
So does the version 3.4.3 actually has
--- Comment #5 from baldrick at free dot fr 2007-03-15 15:34 ---
Subject: Re: tree-nested creates pointless static chains and trampolines when
the callgraph is non-trivial
Bootstraps with all languages including Ada. Does not introduce any new
testsuite failures. I'd appreciate
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-15 15:48 ---
I don't think this is a bug, you need to read the other part of the document
which says if you supply -I DEFAULT_DIR, it is ignored.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31186
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-15 16:07 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tromey at gcc dot gnu dot org 2007-03-15 16:28 ---
I think this is probably the same thing as bug #28709,
and most likely fixed by the same patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2007-03-15 16:45 ---
Just to make sure: Did revision 122820 bootstrap without problems? I.e. is it
certain that the patch for r122821 caused the bootstrap comparison failure?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
--- Comment #2 from vincent at vinc17 dot org 2007-03-15 16:51 ---
(In reply to comment #1)
I don't think this is a bug, you need to read the other part of the document
which says if you supply -I DEFAULT_DIR, it is ignored.
OK, but this isn't very clear, as the description under
Since PR 30498 is fixed, gfortran supports backtraces. However, they are only
displayed for library errors not for, e.g., SEGV or signalling IEEE signals.
A support for these can be found embedded in the patch at
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00747.html
--
Summary:
--- Comment #6 from sje at cup dot hp dot com 2007-03-15 16:52 ---
Yes, I did a successful bootstrap on PA with 122820, updated to 122821, did a
new bootstrap (after removing the object directory) and got the comparision
failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
--- Comment #7 from sje at cup dot hp dot com 2007-03-15 16:56 ---
Created an attachment (id=13209)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13209action=view)
output of stage1 compiler from ivopts
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
--- Comment #8 from sje at cup dot hp dot com 2007-03-15 16:56 ---
Created an attachment (id=13210)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13210action=view)
output of stage2 compiler from ivopts
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
--- Comment #9 from sje at cup dot hp dot com 2007-03-15 16:58 ---
I created two attachments, one is the output of ivopts from the stage1 compiler
and the other is from the stage2 compiler. This is the first place the two
compilers divirge in their output when compiling the test case
--- Comment #1 from bonzini at gnu dot org 2007-03-15 17:03 ---
Created an attachment (id=13211)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13211action=view)
patch that fixes the bug, untested
REG_N_CALLS_CROSSED is computed using live, not urec. caller_save uses
it to decide
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-03-15 17:19
---
Now what is interesting despite of being wrong or not is that we use an
index only for the MEM ref:
L11:;
D.1641_16 = D.1589_4 + -1;
D.1642_15 = regexp_3(D)-regexp.oneof.regexps[D.1641_16];
ivtmp___31_21 =
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-03-15 17:28
---
Note that either SCEV or ivopts derives a loop trip count of 1 wrongly out of
the [1] sized array as it is a tail array. Why this happens in stage2 and not
stage1 is of course a mystery if not (what is probably
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-03-15 17:57
---
It would be interesting to know why tree-ssa-loop-niter.c:array_at_struct_end_p
()
returns a different value for the stage1/stage2 compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-03-15 18:09
---
Subject: Bug 30364
Author: rguenth
Date: Thu Mar 15 18:09:26 2007
New Revision: 122956
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122956
Log:
2007-03-15 Richard Guenther [EMAIL PROTECTED]
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-03-15 18:10
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from craig dot lawson at centrify dot com 2007-03-15 18:15
---
(In reply to comment #15)
Tried it. Did not work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
--- Comment #17 from pcarlini at suse dot de 2007-03-15 18:27 ---
(In reply to comment #16)
Tried it. Did not work.
Why?
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #18 from craig dot lawson at centrify dot com 2007-03-15 18:39
---
(In reply to comment #17)
Why?
Don't know. The file and change were included as expected.
Without fully understanding how CPP is evaluating these files, we're shooting
in the dark. gcc's -E and -CC
--- Comment #19 from pinskia at gcc dot gnu dot org 2007-03-15 18:40
---
Try adding -dD which causes the preprocessor to also emit all #defines.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
--- Comment #20 from pcarlini at suse dot de 2007-03-15 18:45 ---
Thanks Andrew. I'd like to know what happens if you just compile a small
snippet like:
#define _TS_ERRNO
#include cerrno
int main()
{
return errno;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
A feature of g95 I find convenient is that
list-directed output is printed in the minimum amount
of space required, making it more readable IMO. For
example, for
print*,(i,i=1,6)
end
g95 gives
1 2 3 4 5 6
and gfortran gives
1 2 3 4 5
--- Comment #2 from hp at gcc dot gnu dot org 2007-03-15 19:04 ---
The patch in comment #1 fixes the regression for cris-axis-elf
(regtested with revision r122955).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31159
--- Comment #21 from craig dot lawson at centrify dot com 2007-03-15 19:07
---
(In reply to comment #17)
Why?
OK, now I know why. Reason is that os_defines.h is included after errno.h.
Here's the include sequence:
c++locale.cc
cerrno
/usr/include/errno.h-- extern
--- Comment #22 from pcarlini at suse dot de 2007-03-15 19:17 ---
(In reply to comment #21)
(In reply to comment #17)
Why?
OK, now I know why. Reason is that os_defines.h is included after errno.h.
Oh yes, you are totally right. The problem is that cerrno is one of the very
few
--- Comment #23 from craig dot lawson at centrify dot com 2007-03-15 19:26
---
(In reply to comment #22)
Oh yes, you are totally right. The problem is that cerrno is one of the very
few c headers not including bits/c++config.h first. We can easily fix that.
Why did cerrno not
--- Comment #13 from sje at cup dot hp dot com 2007-03-15 19:26 ---
With respect to comment #12. It looks like array_at_struct_end_p is returning
true in both compilers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-15 19:31 ---
If one comments out the if block in gfc_simplify_expr (expr.c):
--
case EXPR_VARIABLE:
/* Only substitute array parameter variables if we are in an
initialization expression, or we want
--- Comment #24 from pcarlini at suse dot de 2007-03-15 19:37 ---
(In reply to comment #23)
(In reply to comment #22)
Oh yes, you are totally right. The problem is that cerrno is one of the
very
few c headers not including bits/c++config.h first. We can easily fix
that.
--- Comment #6 from baldrick at gcc dot gnu dot org 2007-03-15 19:45
---
(In reply to comment #1)
Try this: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01201.html
I don't think you need to consider FDESC_EXPR when constructing
the callgraph. It seems only to be used for vtables;
--- Comment #6 from sebor at roguewave dot com 2007-03-15 19:54 ---
(In reply to comment #5)
I've checked all three but none of them seems to achieve an optimal layout in a
modified template case. Let me attach my test program.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176
--- Comment #7 from sebor at roguewave dot com 2007-03-15 19:55 ---
Created an attachment (id=13212)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13212action=view)
test case for data member reordering
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-03-15 20:15
---
Subject: Bug 31161
Author: rguenth
Date: Thu Mar 15 20:14:49 2007
New Revision: 122958
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122958
Log:
2007-03-15 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-03-15 20:15 ---
Subject: Bug 29719
Author: rguenth
Date: Thu Mar 15 20:14:49 2007
New Revision: 122958
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122958
Log:
2007-03-15 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-03-15 20:16
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-03-15 20:17
---
Fixed. (The ICE, the wrong-code is tracked by the other PR)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from craig dot lawson at centrify dot com 2007-03-15 20:28
---
(In reply to comment #24)
Oh, that's excellent news, because we have to include bits/c++config.h first
in cerrno anyway... But now you make me curious!!! If you look at
c++config.h
it doesn't appear do
--- Comment #3 from pault at gcc dot gnu dot org 2007-03-15 20:36 ---
(In reply to comment #2)
(In reply to comment #1)
The program works as expected. n.sym-name is ivec. I don't understand why
ivec
is FL_PARAMETER and not FL_VARIABLE.
It is not correct to have the line gcc_assert
--- Comment #26 from pcarlini at suse dot de 2007-03-15 20:44 ---
(In reply to comment #25)
Sorry, that news was too excellent. It's not true.
Ok.
The reason I suggested also including clocale in comment #10 was because I
found bits/c++config.h was not enough. I agree that clocale
The regression was introduced between r120825 (10s runtime) and r120846 (110s
runtime). The obvious candidate is:
+2007-01-16 Jan Hubicka [EMAIL PROTECTED]
+
+ * cgraph.h (cgraph_decide_inlining_incrementally): Kill.
+ * tree-pass.h: Reorder to make IPA passes appear toegher.
+
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-15 20:55 ---
http://www.suse.de/~gcctest/c++bench/freefem/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31191
--
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=31191
--- Comment #4 from patchapp at dberlin dot org 2007-03-15 20:55 ---
Subject: Bug number PR31188
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01045.html
--
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-15
20:59 ---
Subject: Re: Bootstrap comparison error at revision 122821g
Just to make sure: Did revision 122820 bootstrap without problems? I.e. is it
certain that the patch for r122821 caused the bootstrap
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-15 21:03 ---
A compiler option that used a minimal width for output
for list directed WRITEs would be convenient.
There are pros and cons for both.
Assume:
print *,(huge(0),i=1,6)
print*,(i,i=1,6)
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-03-15 21:06
---
Did you try reverting the last hunk:
@@ -1816,7 +1833,8 @@
the new range. */
/* Divisions by zero result in a VARYING value. */
- if (code != MULT_EXPR
+ if ((code != MULT_EXPR
+
--- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-15
21:12 ---
Subject: Re: Bootstrap comparison error at revision 122821
Did you try reverting the last hunk:
No. I'll give it a try shortly.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
--- Comment #27 from craig dot lawson at centrify dot com 2007-03-15 21:17
---
(In reply to comment #26)
I understand. I'll collect this information from the systems I have, and then
post it here ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
--- Comment #15 from fche at redhat dot com 2007-03-15 21:41 ---
This still seems fishy to me FWIW: both gcc's implementation and documentation
appear to be needlessly aggressive.
--
fche at redhat dot com changed:
What|Removed |Added
--- Comment #2 from hubicka at ucw dot cz 2007-03-15 22:01 ---
Subject: Re: New: [4.3 Regression] 1000% Runtime regression for FreeFEM
navier-stokes example
The regression was introduced between r120825 (10s runtime) and r120846 (110s
runtime). The obvious candidate is:
--- Comment #3 from manu at gcc dot gnu dot org 2007-03-15 22:24 ---
Subject: Bug 24924
Author: manu
Date: Thu Mar 15 22:24:42 2007
New Revision: 122961
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122961
Log:
2007-03-15 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #2 from manu at gcc dot gnu dot org 2007-03-15 22:45 ---
Subject: Bug 30891
Author: manu
Date: Thu Mar 15 22:45:17 2007
New Revision: 122962
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122962
Log:
2007-03-15 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #3 from manu at gcc dot gnu dot org 2007-03-15 22:47 ---
Fixed for GCC 4.3
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from manu at gcc dot gnu dot org 2007-03-15 22:49 ---
Fixed for GCC 4.3
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
Problem could be easy reproduced by gcc412 -O1 -fwhole-program -S
gcc-4.1.2/gcc/testsuite/gcc.gd/tree-ssa/wholeprogram-2.c. The output file
wholeprogram-2.s contains:
.file wholeprogram-2.c
.text
.type externally_visible_function, @function
externally_visible_function:
--- Comment #13 from spark at gcc dot gnu dot org 2007-03-15 23:48 ---
Subject: Bug 30590
Author: spark
Date: Thu Mar 15 23:48:13 2007
New Revision: 122964
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122964
Log:
2007-03-15 Seongbae Park [EMAIL PROTECTED]
PR
--- Comment #8 from sebor at roguewave dot com 2007-03-15 23:51 ---
Some additional comments on the request precipitated by a discussion with the
implementers of another compiler:
The rationale for allowing the attribute on individual members is to provide
fine-grained control over
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-03-16 00:04
---
Reopening - missed part of this. Patch submitted for approval
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Hello
Gcc 3.4.2 on WinXP seems to generate a warning that it should not.
$ gcc -v
Reading specs from C:/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2007-03-16 00:41
---
Subject: Bug 31099
Author: jvdelisle
Date: Fri Mar 16 00:41:36 2007
New Revision: 122970
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122970
Log:
2007-03-15 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #4 from patchapp at dberlin dot org 2007-03-16 00:45 ---
Subject: Bug number PR30891
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00698.html
--
--- Comment #3 from hp at gcc dot gnu dot org 2007-03-16 00:56 ---
There was no PR/31159 on the ChangeLog entry for the committed fix (hi steven),
but the patch was sent to gcc-patches and committed a few hours ago, so I'm
closing this.
--
hp at gcc dot gnu dot org changed:
1 - 100 of 114 matches
Mail list logo
