--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-08-30 05:01
---
The following ICEs the the above patches which I reverted until I sort this
out.
MODULE print_it
CONTAINS
SUBROUTINE i()
LOGICAL :: qexist
INQUIRE (UNIT=1, EXIST=qexist)
END SUBROUTINE i
END MODULE pr
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-08-30 04:59
---
Reverted patch from PR33055
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from spop at gcc dot gnu dot org 2007-08-30 03:10 ---
Created an attachment (id=14137)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14137&action=view)
testcase
This is the last testcase that get scrambled by bugzilla.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #1 from spop at gcc dot gnu dot org 2007-08-30 03:07 ---
Created an attachment (id=14136)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14136&action=view)
testcase
I just realized that all these inlined testcases were scrambled by bugzilla.
I'm submitting the testcases
Here is a reduced testcase for Polyhedron:fatigue.f90:928. The non
vectorized loops that compute stress_tensor show up on the top user
times in the profile of that benchmark:
module perdida_m
integer, parameter, private :: LONGreal = selected_real_kind(15,90)
contains
subroutine perdida
The innermost loop in "j" cannot be vectorized because of the
irregular code in that loop, i.e. the condition "IF ( l.NE.k )". But
the cond expression is invariant in that loop, so the whole condition
can be hoisted outside that loop, versioning the loop, and potentially
allowing the vectorization
The following loop showing up in the top time users in capacita.f90 is
not vectorized because the loop latch block is non empty:
./capacita.f90:51: note: = analyze_loop_nest =
./capacita.f90:51: note: === vect_analyze_loop_form ===
./capacita.f90:51: note: not vectorized: unexpected loop f
There are two time consuming routines in air.f90 of the Polyhedron
benchmark that are not vectorized: lines 1328 and 1354. These appear
in the top counting of execution time with oprofile:
SUBROUTINE DERIVY(D,U,Uy,Al,Np,Nd,M)
IMPLICIT REAL*8(A-H,O-Z)
PARAMETER (NX=150,NY=150)
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-30
01:43 ---
Subject: Re: [4.3 Regression] libgcc2.c:1890: internal compiler error: in
local_cprop_pass, at gcse.c:3236
> Any news on this bug?
I have been building with Steven's change for the past couple of weeks
a
--- Comment #3 from mckelvey at maskull dot com 2007-08-30 01:33 ---
Yes, that was it. Removing the old GMP fixed the install.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33191
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-08-30 00:55
---
Test case from PR33223.
program t
print*,huge(1.0d0),tiny(1.0d0)
end program t
gives the output
1.797693134862316E+30^@ 2.225073858507201E-30^@
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-08-30 00:53
---
*** Bug 33223 has been marked as a duplicate of this bug. ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-08-30 00:53
---
*** This bug has been marked as a duplicate of 33225 ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-08-30 00:52
---
The patch has not been reversed yet. This is a duplicate of PR33225. Since
there is more information in the other PR, I will close this one and track on
the other.
I can reproduce the bug using -m32 on my syste
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-08-30 00:06 ---
*** Bug 33242 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-30 00:06 ---
Yep this code is invalid.
*** This bug has been marked as a duplicate of 7498 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-30 00:01 ---
The copy constructor on a fstream is invalid.
And you caused it to be created here: Seg s1 = Seg("");
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33242
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||gcc-bugs at gcc dot gnu dot
|
When I try to compile the following file (attached at the end. quite big) I get
the folloring message
onefile.F90: In function MAIN__:
onefile.F90:778: internal compiler error: in gfc_get_symbol_decl, at
fortran/trans-decl.c:1020
Please submit a full bug report,
with preprocessed source if approp
--- Comment #4 from dominiq at lps dot ens dot fr 2007-08-29 23:02 ---
Subject: Re: [4.3 regression] Missing last digit is
some formatted output
> Actually this is expected if you did not supply -fno-sign-zero ...
You are right!-) I have added the option in the script I am using
and
--- Comment #3 from pinskia at gmail dot com 2007-08-29 22:23 ---
Subject: Re: [4.3 regression] Missing last digit is some formatted output
On 29 Aug 2007 22:18:58 -, dominiq at lps dot ens dot fr
<[EMAIL PROTECTED]> wrote:
> FM406 gives:
>
> ...
> COMPUTED=
On 29 Aug 2007 22:18:58 -, dominiq at lps dot ens dot fr
<[EMAIL PROTECTED]> wrote:
> FM406 gives:
>
> ...
> COMPUTED=-0.0
> CORRECT= 0.0
Actually this is expected if you did not supply -fno-sign-zero or
-std=f95 as the default is to print negat
--- Comment #2 from dominiq at lps dot ens dot fr 2007-08-29 22:18 ---
I have run the NIST test suite and I got:
...
6 runtime errors
FM111 has NIST regression.
FM406 has NIST regression.
FM903 has NIST regression.
FM907 has NIST regression.
FM909 has NIST regression.
FM912 has NIST reg
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-08-29 22:14
---
Any news on this bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33029
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-29 22:14 ---
*** This bug has been marked as a duplicate of 33029 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-08-29 22:14 ---
*** Bug 33240 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
seen with SVN 20070828
Matthias
/scratch/packages/gcc/snap/gcc-snapshot-20070827/build-hppa64/./gcc/xgcc
-B/scratch/packages/gcc/snap/gcc-snapshot-20070827/build-hppa64/./gcc/
-B/usr/lib/gcc-snapshot/hppa64-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/hppa64-linux-gnu/lib/ -isystem
/usr/lib/gcc-snaps
--- Comment #1 from chris dot fairles at gmail dot com 2007-08-29 22:04
---
Not sure if this is same bug:
template
struct B;
template
struct B {};
template
struct B : public B {
H h;
};
template
class D : B<0,T...> {};
template
struct E;
template
struct E> {
typedef decl
--- Comment #1 from masse_nicolas at yahoo dot fr 2007-08-29 21:57 ---
Created an attachment (id=14135)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14135&action=view)
Complete sources tree where the problem happens
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33239
All is in the title. Here is the complete output I have (my system is in
french):
g++ -DHAVE_CONFIG_H -I. -I.. -I ../src-g -O2 -MT sample1.o -MD -MP -MF
.deps/sample1.Tpo -c -o sample1.o sample1.cpp
../src/tuple.hpp: In instantiation of 'yactl::tuple_impl, std::allocator >
>::append, std::alloc
--- Comment #12 from raeburn at raeburn dot org 2007-08-29 21:51 ---
Subject: Re: Error in compiling when there is a function with a char parameter
called before its declaration with inline parameters.
On Aug 29, 2007, at 13:39, andreagrassi at sogeasoft dot com wrote:
> I accept the a
--- Comment #1 from radford at blackbean dot org 2007-08-29 21:19 ---
Bug is present in 4.2.1 as well.
--
radford at blackbean dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-29 20:52 ---
I think this comes down to the referenced decls is huge because of the static
"const" variable but I don't know for sure (I had looked into one of those
issues before).
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||compile-time-hog
Summary|Tree memory partitioning is |[4.3
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-08-29 20:42 ---
That ICE is most likely PR 33140.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-29 20:41 ---
Mine, working on it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Assign
--- Comment #31 from andreast at gcc dot gnu dot org 2007-08-29 20:17
---
Thanks Jakub!
With this patch: http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02111.html
you not only brought back the testsuite passes, you also made the bytecode
compilation work again on ppc-linux and ppc-darwin
The following code gives an internal compiler error using gcc 4.1.2, but
compiles using 3.4. Remove the ()s around the {}s and it compiles just fine.
void reverse(void *_p, int nmemb, int size)
{
struct { char _[size]; } *p = _p, tmp;
for (int i=nmemb-1, j=0; jhttp://gcc.gnu.org/bugzilla
--- Comment #1 from dominiq at lps dot ens dot fr 2007-08-29 19:29 ---
Note that the problem disappears on Darwin with -m64 (excepted the problem
Error: Result of NEAREST overflows its kind at (1)).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
--- Comment #4 from pault at gcc dot gnu dot org 2007-08-29 19:19 ---
(In reply to comment #3)
> I am going to try this one.
>
Jerry,
This fixes it but I do not understand why it is necessary; nor have I
regtested. It's yours - I am going to tackle "spanned" pointers next, in the
hope
--- Comment #8 from tkoenig at gcc dot gnu dot org 2007-08-29 19:02 ---
Hi Jerry,
what was the problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33055
--- Comment #1 from bergner at gcc dot gnu dot org 2007-08-29 18:54 ---
Created an attachment (id=14134)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14134&action=view)
Test case mentioned above.
To recreate: gcc -O1 -S -ftime-report syntax-case.i
--
http://gcc.gnu.org/bugzi
The tree memory partitioning phase is spending 430 seconds of a 490 second
compile which seems a little excessive. The test case is a slightly modified
version of another test case within bugzilla (I forget which one) but with some
syntax warning cleaned up. I'm using GCC mainline revision 127398.
--- Comment #3 from martinwguy at yahoo dot it 2007-08-29 18:45 ---
The patches contained in http://files.futaris.org/gcc/crunch.tar.bz2 not only
fix this issue but also make MaverickCrunch support work reliably in gcc-4.1.2
and gcc-4.2.0 (presumably they can also apply to TRUNK).
There
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-29 18:38 ---
s/r31/r30 in comment #0, r31 is the frame pointer :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33236
If -minimal-toc is used with a leaf function (that uses global memory), the
register r31 is saved/restored which causes a LHS store on the Cell's PowerPC
side.
Simple example:
int i;
int f(void)
{
return i;
}
asm:
std 30,-16(1)
ld 30,[EMAIL PROTECTED](2)
ld 9,.LC0-.LCTOC1(
--- Comment #22 from dberlin at gcc dot gnu dot org 2007-08-29 18:30
---
Subject: Re: [4.3 Regression]
tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc
On 29 Aug 2007 15:19:10 -, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #21 from rguenth
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-29 18:15 ---
At least for it currently crashes already for the following reduced example;
the problem seems to be the default initializer. (Another hint that this is
indeed the problem: After commenting out the "if (f->sym && f->s
--- Comment #40 from eweddington at cso dot atmel dot com 2007-08-29 18:06
---
(In reply to comment #39)
> Created an attachment (id=14131)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14131&action=view) [edit]
> another test case
>
> This test case only has problems when gcc is
--- Comment #5 from patchapp at dberlin dot org 2007-08-29 18:05 ---
Subject: Bug number PR31879
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-08/msg02114.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #11 from andreagrassi at sogeasoft dot com 2007-08-29 17:39
---
Subject: R: Error in compiling when there is a function with a char parameter
called before its declaration with inline parameters.
I accept the answer to gave me but then also the definition of
a(a)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-29 17:09 ---
I have to look this up but I think this code is valid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33226
--- Comment #7 from dje at gcc dot gnu dot org 2007-08-29 17:01 ---
Subject: Bug 33168
Author: dje
Date: Wed Aug 29 17:01:35 2007
New Revision: 127910
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127910
Log:
2007-08-29 Paolo Bonzini <[EMAIL PROTECTED]>
PR target/331
--- Comment #10 from andreagrassi at sogeasoft dot com 2007-08-29 17:01
---
Subject: R: Error in compiling when there is a function with a char parameter
called before its declaration with inline parameters.
Read again your "brilliant" error message where you mention why my code is
i
--- Comment #9 from manu at gcc dot gnu dot org 2007-08-29 16:30 ---
Since "a" is called before being defined/declared is assumed:
extern int a();
See also: http://c-faq.com/decl/implfdecl.html
The error message could be a bit clearer by pointing out this explicitly:
a.c:7: error: co
--- Comment #1 from dgregor at gcc dot gnu dot org 2007-08-29 16:16 ---
Created an attachment (id=14133)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14133&action=view)
Failing test-case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33235
Overload resolution is picking the wrong candidate for the construction of b3,
below:
base2 b3(static_cast(b));
Instead of choosing the move constructor, it is picking the trivial copy
constructor. However, adding a normal copy constructor fixes the problem.
Naturally, this only occurs in C++0
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-08-29 16:15 ---
No C is defined this way. Look at the error message, we mention why this code
is invalid.
> a.c:7: note: an argument type that has a default promotion can't match an
> empty
> parameter name list declaration
Wha
The following is invalid Fortran 95/2003:
call sub (len, "abcdef")
unless one has used before "intrinsic len".
gfortran happily accepts this, "ifort -stand f03" diagnoses:
fortcom: Warning: intrinsic_actual_4.f90, line 17: Allowing an intrinsic
procedure name to appear as an actual argument
This is a follow up to PR30746.
While I believe the test case in PR30746 is correct, I think the
gfortran.dg/host_assoc_function_1.f90 test case is wrong.
(Simplified, see testsuite for the full file)
MODULE m
REAL :: x(3) = (/ 1.5, 2.5, 3.5 /)
CONTAINS
SUBROUTINE s
if (x(2) .ne. 2.5) ca
The following is a common vendor extension but to my knowledge not allowed up
to Fortran 2003 (and probably also Fortran 2008):
write(*,*), 'Hello'
read(*,*), a
end
gfortran -pedantic -std=f95 -Wall accepts simply accepts it.
ifort -stand f03 reports correctly:
fortcom: Warning: a.f90, line 1:
gfortran -fall-intrinsics -std=f95 -Wall -pedantic
gfortran.dg/elemental_subroutine_1.f90
gives no error, but ifort:
In a reference to an elemental subroutine, either all act-args shall be scalar,
or all act-args associated with INTENT(OUT) and INTENT(INOUT) dum-args shall be
conforming arrays.
gfortran -std=f95 -pedantic -Wall -fall-intrinsics
gfortran.dg/char_result_7.f90
Compiles, but as g95 remarks:
Error: Specification function 'fn' at (1) must be PURE
which NAG f95 confirms:
Error: Reference to non-specification function FN in specification
and ifort joins in as well:
An expl
--- Comment #30 from zadeck at naturalbridge dot com 2007-08-29 15:34
---
Subject: Re: [4.3 Regression] ecj1 hangs
bonzini at gnu dot org wrote:
> --- Comment #29 from bonzini at gnu dot org 2007-08-29 14:16 ---
> (When I said "post your first patch", I meant the first one fr
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-08-29 15:27
---
Subject: Bug 32989
Author: fxcoudert
Date: Wed Aug 29 15:22:55 2007
New Revision: 127905
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127905
Log:
PR fortran/32989
* iresolve.c (gfc_reso
--- Comment #2 from spark at gcc dot gnu dot org 2007-08-29 15:23 ---
I suspect this might be due to not updating the rd information after unrolling.
Can you check if
analyze_insns_in_loop() (which calls df_analyze()) is being called just before
the problematic unrolling ?
--
http:
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-29 15:25
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-08-29 15:19
---
I wonder why D.9380_64, defined as
D.9380_64 = &D.8894_34->_M_use_count;
points to anything and NULL:
D.9380_64, is dereferenced, points-to anything, points-to NULL
where the single dereference site looks l
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-08-29 15:16
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-29 15:16
---
Subject: Bug 33105
Author: fxcoudert
Date: Wed Aug 29 15:16:00 2007
New Revision: 127903
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127903
Log:
PR fortran/33105
* intrinsic.c (add_fun
The following invalid program gives a memory access error. Note, without
INTRINSIC or with IMPLICIT NONE, everything works as expected.
intrinsic cpu_time
real :: time
print *, CPU_TIME(TIME)
end
--
Summary: ICE with "intrinsic" plus calling a subroutine as
functi
--- Comment #29 from bonzini at gnu dot org 2007-08-29 14:16 ---
(When I said "post your first patch", I meant the first one from comment #26;
if my "fixing the mess" works, it'll not be necessary anymore).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32758
module m
USE MOD, only: foo1
interface generic_intrf
module procedure foo1
end interface
is accepted although "bar" is not a host-associated procedure, but a
use-associated procedure.
(Using "PROCEDURE foo1" instead of "MODULE PROCEDURE foo1" allows
use-associated procedures.)
NAG f95 correctl
--- Comment #28 from bonzini at gnu dot org 2007-08-29 14:14 ---
> Apparently dce is the only user of df_simulate_* which at the start of the
> basic block compares the resulting bitmap with DF_LR_IN.
Yes. The other two don't get infinite loops from their doing the wrong thing;
they j
--- Comment #27 from bonzini at gnu dot org 2007-08-29 14:11 ---
> Not all basic blocks have all 4 x86_64 regular_block_artificial_regs registers
> set in DF_LR_IN and so oring this in causes infinite loop, as
> process_dce_block
> always returns something changed.
If so, your previou
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-08-29 14:11 ---
Of course this is completely useless information for a bugreport. Please read
http://gcc.gnu.org/bugs.html and try again. You may also want to report to
your distributor, that is, RedHat in this case.
--
rguent
I have ran into a situation where code compiled on RedHat 8.0 with gcc 3.2 runs
well. We have upgraded our systems to Fedora Core 6 with gcc 4.1.1 and now
multiple programs are dropping core files left and right. When we turn the
optimization off (create a debugable version) the programs act norm
--- Comment #7 from andreagrassi at sogeasoft dot com 2007-08-29 13:56
---
Subject: R: Error in compiling when there is a function with a char parameter
called before its declaration with inline parameters.
Thank you so much for the speed, the kindness and the precision with which
you
--- Comment #26 from jakub at gcc dot gnu dot org 2007-08-29 13:56 ---
Apparently dce is the only user of df_simulate_* which at the start of the
basic block compares the resulting bitmap with DF_LR_IN. All other users
of these interfaces don't do that (ifcvt, rtl-factoring, peephole2).
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-29 13:36 ---
FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from l_belev at yahoo dot com 2007-08-29 13:35 ---
Tested this in 4.2.1 and int seems to be fixed (i.e. the compiler now does not
make difference between the 2 variants ot the code)
Thank you!
--
l_belev at yahoo dot com changed:
What|Removed
--- Comment #25 from jakub at gcc dot gnu dot org 2007-08-29 13:26 ---
Unfortunately it breaks e.g. memcpy-chk.c, simplified testcase here:
extern void abort (void);
typedef __SIZE_TYPE__ size_t;
extern void *memcpy (void *, const void *, size_t);
extern volatile int chk_fail_allowed;
ex
--- Comment #40 from gdr at cs dot tamu dot edu 2007-08-29 13:19 ---
Subject: Re: Unnecessary anonymous namespace warnings
"Andrew Pinski" <[EMAIL PROTECTED]> writes:
| On 29 Aug 2007 03:15:04 -, bangerth at dealii dot org
| <[EMAIL PROTECTED]> wrote:
| > It is a good question in
"Andrew Pinski" <[EMAIL PROTECTED]> writes:
| On 29 Aug 2007 03:15:04 -, bangerth at dealii dot org
| <[EMAIL PROTECTED]> wrote:
| > It is a good question in itself whether pimpl_ has a type at all -- it's a
| > pointer to an incomplete type in any case :-)
|
| All types in C++ are exported (
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-29 13:09 ---
Subject: Bug 33215
Author: burnus
Date: Wed Aug 29 13:08:55 2007
New Revision: 127898
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127898
Log:
2007-08-29 Christopher D. Rickett <[EMAIL PROTECTED]>
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-08-29 12:55
---
Fixing of the trunk was a side-effect of some major re-structuring. This won't
go on the branch for sure, no easy way to fix this another way either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29478
--- Comment #3 from dgregor at gcc dot gnu dot org 2007-08-29 12:28 ---
Fixed on mailine
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-08-29 12:25 ---
Subject: Bug 33194
Author: dgregor
Date: Wed Aug 29 12:25:01 2007
New Revision: 127896
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127896
Log:
2007-08-29 Douglas Gregor <[EMAIL PROTECTED]>
PR c
--- Comment #2 from sandra at codesourcery dot com 2007-08-29 12:19 ---
See patch and discussion here:
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02027.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33211
--- Comment #24 from paolo dot bonzini at lu dot unisi dot ch 2007-08-29
12:15 ---
Subject: Re: [4.3 Regression] ecj1 hangs
> Here is what I will try to regtest (already verified it fixes the testcase).
This is wrong, because local_live changes during execution of
dce_process_block.
If an identifier given inside an enum is the same as an existing class
the compiler still accepts it:
<<< code <<<
class MyClass { };
MyClass g_my_class; // An instance
enum { Mode1, MyClass }; // We could have error already here
MyClass g_my_class2; // Compiler gives error here
<<< endcode <
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-08-29 11:58
---
Due to the alias differences with -g compared to without -g we have the
following
difference after tree-level optimization:
--- - 2007-08-29 13:52:02.567822000 +0200
+++ b/auto_ptr.min.ii.116t.optimized2007-
--- Comment #23 from paolo dot bonzini at lu dot unisi dot ch 2007-08-29
11:47 ---
Subject: Re: [4.3 Regression] ecj1 hangs
> df_simulate_one_insn_forwards and df_simulate_one_insn_backwards
> (why we have the former when nothing ever uses it?) both call
> df_simulate_fixup_sets to f
--- Comment #18 from tbm at cyrius dot com 2007-08-29 11:47 ---
(In reply to comment #17)
> Unassigning.
So you don't intend to fix this for 4.2? I guess the patch you commited to
trunk
is too big for 4.2 but do you think there's some kind of workaround that could
be applied to 4.2? T
--- Comment #22 from jakub at gcc dot gnu dot org 2007-08-29 11:41 ---
Created an attachment (id=14132)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14132&action=view)
gcc43-pr32758.patch
Here is what I will try to regtest (already verified it fixes the testcase).
Alternatively,
--- Comment #21 from jakub at gcc dot gnu dot org 2007-08-29 11:18 ---
The major difference between say i?86 or x86_64 and ppc here is that
on the former two the hard frame pointer is actually visibly, not just
artificially, used when restoring the stack pointer. ppc restores the
stack
--- Comment #6 from raeburn at raeburn dot org 2007-08-29 11:12 ---
(In reply to comment #5)
> I don't understand the error !! It's all so simple and I don't understand
> why the compile works if I write in the second form (not inline parameter
> declaration) !!!
(This would be more sui
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-08-29 10:32
---
MTAG_ALIASES of the SMTs are different:
SMT.469 no aliases
SMT.470 no aliases
SMT.464{ ctor_count ctor_count dtor_count SMT.465 SMT.470 }
SMT.465{ ctor_count ctor_count dtor_count SMT.470 }
SMT.466{ ctor_count cto
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #6 from cyberflex at mail dot ru 2007-08-29 10:16 ---
(In reply to comment #4)
> Created an attachment (id=14129)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14129&action=view) [edit]
> Test case that works.
>
> With the new "Test case that works" and attached test.s
1 - 100 of 115 matches
Mail list logo
