--- 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
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 reichelt at gcc dot gnu dot org 2005-09-14
06:31 ---
Fixed on mainline.
--
What|Removed |Added
Status|NEW
--- 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
--- 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: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,
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
07:09 ---
Actually the issue is that we don't change the constructor into a VECTOR_CST:
constructor 0x41ec8720
type vector_type 0x41ebb9a0 __v4sf type real_type 0x41e0fd90 float
sizes-gimplified
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-14
08:21 ---
(From update of attachment 7541)
Already in mainline
--
What|Removed |Added
Attachment #7541
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-14
09:27 ---
Subject: Bug 22480
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-14 09:27:02
Modified files:
gcc: ChangeLog Makefile.in
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-09-14
11:04 ---
Auch; that patch is actually a very bad idea. Pretending that complex
addressing modes are cheaper, when they are not, is just confusing. If there
are optimizers that indeed want to prefer complex
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-14
12:22 ---
It looks like it is just following existing practice?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18463
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr
2005-09-14 12:38 ---
Subject: Re: [data deps] Distance on outer loops for self output deps
In this case neither implementation got the dependece right: there are
bugs in both implementations. For the following
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-09-14 12:41 ---
Subject: Re: [4.0 Regression] suboptimal use of fancy x86 addressing modes
It looks like it is just following existing practice?
yes, I know. The practice is just wrong, though.
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-14
13:41 ---
Which also hints at the problem why we don't accept this.
The instance from which we take the qualifiers is
VA_ARG_EXPR apD.1742
and we do not handle this in build_this / build_address / build_unary_op.
--- Additional Comments From fitzsim at redhat dot com 2005-09-14 13:52
---
This broke when we moved back to the two-threaded event loop model.
--
What|Removed |Added
--- Additional Comments From fitzsim at redhat dot com 2005-09-14 13:53
---
*** Bug 23877 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-14
13:54 ---
I have a patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-09-14
13:56 ---
Confirmed. This seems to be a problem with loop unswitching
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
14:32 ---
Note the testcase is now called struct3.C.
Confirmed.
--
What|Removed |Added
--
What|Removed |Added
Target Milestone|--- |3.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23870
--
Bug 21468 depends on bug 22480, which changed state.
Bug 22480 Summary: [4.1 Regression] ICE in convert_move, at expr.c:390 with
-ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22480
What|Old Value |New Value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
14:46 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From bangerth at dealii dot org 2005-09-14 15:23
---
This has been complained about in other PRs before. The problem is that
the following syntax is allowed:
struct S {} typedef A;
i.e., the infix-form of typedef. Since there are other PRs about this,
--- Additional Comments From bangerth at dealii dot org 2005-09-14 15:25
---
I don't see the problem either. You should simply mark the argument to
the constructor as const so that temporaries can be bound to it.
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-09-14 15:28
---
Confirmed. This is a regression against 3.3 which compiled the code
just fine.
W.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
15:34 ---
As I said, I think this is a dup of bug 14258, we never really got using
correct.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-09-14 15:35
---
I believe the compiler is correct. In order to check whether there
is a conversion sequence from float to AC, it needs to instantiate the
type, parts of which are declared by incomplete. This should be an
--- Additional Comments From bangerth at dealii dot org 2005-09-14 15:36
---
Indeed a duplicate.
*** This bug has been marked as a duplicate of 9335 ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-09-14 15:36
---
*** Bug 23510 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
15:42 ---
Fixed in 4.0.2.
--
What|Removed |Added
Status|NEW
--
Bug 15502 depends on bug 19358, which changed state.
Bug 19358 Summary: [gfortran] Segfault with missing upper bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19358
What|Old Value |New Value
--
What|Removed |Added
Target Milestone|4.0.3 |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23211
--- Additional Comments From appfault at hotmail dot com 2005-09-14 16:09
---
Ok, so that's the best code it can generate, fine. So if instant segfault is
the best possible generated code, I think NOT generating any code is far more
helpful to the user. If not generating any code
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-14
16:23 ---
Ok, so that's the best code it can generate, fine. So if instant segfault is
the best possible generated code, I think NOT generating any code is far more
helpful to the user. If not generating any
--- Additional Comments From micis at gmx dot de 2005-09-14 17:23 ---
I did a bootstrap with C/C++, ran the testsuite and got no new regressions for
your patch.
Michael Cieslinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23853
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
17:34 ---
This is the same issue as PR 14295 so closing as a dup.
*** This bug has been marked as a duplicate of 14295 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
17:35 ---
*** Bug 18268 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
Bug 22157 depends on bug 18268, which changed state.
Bug 18268 Summary: structure copy propagation not done
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18268
What|Old Value |New Value
--
Bug 22156 depends on bug 18268, which changed state.
Bug 18268 Summary: structure copy propagation not done
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18268
What|Old Value |New Value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
17:45 ---
Caused by:
http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00040.html
Reduced testcase:
struct Track {
char soundName[15];
};
int foobar = ((long) ( ((Track *) 42)-soundName[0])) - 42;
--
What
--- Additional Comments From bangerth at dealii dot org 2005-09-14 18:07
---
I'm not sure it is a duplicate, since the error messages are very
different. But be that as it may, this is a regression and should
be fixed. If it is, someone may want to take a look at that other
PR as
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
18:15 ---
Could you try make bootstrap instead of just make?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23801
Sorry to resort to email, but the required info and means of delivery is a bit
beyond my present abilities.
I was following instructions from LinuxQuestions.org Forums Linux -
Distributions Slackware Sendmail SMTP AUTH Howto - page 8 - on Sendmail
SMTP AUTH Howto. The make for
When I tried to use gfortran40 to compile a softawre I obtained this error:
module.F =
Using built-in specs.
Target: i386-portbld-freebsd4.9
Configured with: ./..//gcc-4.0-20050602/configure --disable-nls
--with-system-zlib
It looks like the two stage name binding doesn't work for the following small
program. This happen with many g++ versions (including recent ones) except
version 3.3.2 Red Hat:
Config `g++ --version`result
1- 2.96 2731 (Red Hat Linux 7.1 2.96-81) wrong
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
18:54 ---
Can you attach module.F?
--
What|Removed |Added
CC|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
19:03 ---
I think this is a dup of bug 16635.
--
What|Removed |Added
BugsThisDependsOn|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
19:14 ---
catchall-1.m is a regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23393
$HOME/gcc-4.0.1/bin/g++ --version
g++ (GCC) 4.0.1
Built like this (from config.status):
../gcc-4.0.1/configure --prefix=$HOME/gcc-4.0.1
--with-gcc-version-trigger=$HOME/reference/gnu/gcc-4.0.1/gcc/version.c
--enable-languages=c,c++,java,objc
--
What|Removed |Added
Known to fail||4.0.1
Known to work||3.4.0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
19:29 ---
Reduced testcase:
module param
double precision mutdefc(8,5,7)
data mutdefc(1,1,7) /0.d0/
* mutdefc(1,1,7) /0.d0/
end module param
But this is really a dup of bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
19:29 ---
*** Bug 23884 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fitzsim at redhat dot com
|dot org |
Status|UNCONFIRMED
--- Additional Comments From fitzsim at redhat dot com 2005-09-14 20:15
---
Fixed on HEAD. Closing.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-14
20:19 ---
Subject: Bug 21875
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-14 20:18:19
Modified files:
libgfortran: ChangeLog libgfortran.h
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-14
20:20 ---
Subject: Bug 21875
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-14 20:19:38
Modified files:
gcc/fortran: ChangeLog trans-io.c
Log message:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-14
20:27 ---
Subject: Bug 21875
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-14 20:25:56
Modified files:
gcc/testsuite : ChangeLog
Added files:
--- Additional Comments From martin dot audet at imi dot cnrc-nrc dot gc
dot ca 2005-09-14 20:36 ---
Hi again,
I agree with you, this bug and 16635 seems to be related to the same cause
(which is I guess the two-stage name-lookup for templates).
I also ran the three code examples
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
20:41 ---
It fails on 3.3.3 also.
--
What|Removed |Added
Known to fail|4.0.1 4.0.0 3.4.3 3.4.2
--- Additional Comments From jvdelisle at verizon dot net 2005-09-14 20:43
---
This is fixed in 4.1 branch. If nothing new shows up in the next few days I
will close this PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21875
--- Additional Comments From assar at kth dot se 2005-09-14 20:49 ---
Subject: Re: friend in containing namespace is not found
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
Not a bug, as friend class A; refers to Foo::Bar::A and not Foo::A
as defined by the C++ standard.
--- Additional Comments From gdr at integrable-solutions dot net
2005-09-14 21:03 ---
Subject: Re: SFINAE bug
bangerth at dealii dot org [EMAIL PROTECTED] writes:
| I believe the compiler is correct. In order to check whether there
| is a conversion sequence from float to AC, it
--- Additional Comments From bangerth at dealii dot org 2005-09-14 21:10
---
Fair enough. And to get more to the point of only using user-defined
conversion sequences (instead of the standard conversion from double
to int):
struct A;
struct B { B(const double
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
21:23 ---
(In reply to comment #6)
I retract my point of view. This doesn't mean, however, that I'm convinced
that the opposite would be true.
But both of those testcases represent void f(const BC a); .
Here is
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-14
21:29 ---
Subject: Bug 23868
CVSROOT:/cvs/gcc
Module name:gcc
Branch: sh-elf-4_1-branch
Changes by: [EMAIL PROTECTED] 2005-09-14 21:29:08
Modified files:
gcc/config/sh :
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-14
21:31 ---
Subject: Bug 23868
CVSROOT:/cvs/gcc
Module name:gcc
Branch: sh-elf-4_1-branch
Changes by: [EMAIL PROTECTED] 2005-09-14 21:30:58
Modified files:
gcc:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-14
21:34 ---
Subject: Bug 23584
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-14 21:34:37
Modified files:
gcc/testsuite : ChangeLog
Added files:
Now that the cassert include has been removed from the debug mode includes,
the question that immediately comes to mind is: should we throw instead of
assert?
Advantages:
1) in the testsuite, we could check for the proper exception, instead of
xfailing on the expected abort call. This would
--- Additional Comments From gdr at integrable-solutions dot net
2005-09-14 22:11 ---
Subject: Re: SFINAE bug
bangerth at dealii dot org [EMAIL PROTECTED] writes:
| Fair enough. And to get more to the point of only using user-defined
| conversion sequences (instead of the standard
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
22:19 ---
I think this is a good idea, just like any other runtime exceptions.
Confirmed.
--
What|Removed |Added
consider the following program
program random
implicit none
real :: x
call random_seed();
call random_number(x);
write(*,*) x
end program random
When I run this program, I want to output different random numbers for
each run. This does not happen with gfortran.
$gfortran random.f90
$./a.out
--
What|Removed |Added
Component|fortran |libfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23889
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-14
22:43 ---
G++ will issue a diagnostic about this usage with -pedantic.
The decision not to issue a diagnostic in the default mode is conscious and
intentional; G++ has historically accepted this code, and there is
--- Additional Comments From bangerth at dealii dot org 2005-09-14 22:57
---
Well, we've been tightening the compiler in many places. I consider this
a particularly useless extension -- it's true that it doesn't hurt anyone,
but it adds nothing whatsoever of value to the language. I
--- Additional Comments From gdr at integrable-solutions dot net
2005-09-14 23:04 ---
Subject: Re: Accepts qualified member function declaration in class
mmitchel at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| G++ will issue a diagnostic about this usage with -pedantic.
|
| The
--- Additional Comments From bangerth at dealii dot org 2005-09-14 23:05
---
I think that's a particularly bad idea: if we use assert(), then we get
an immediate backtrace when run in the debugger. If an exception is
thrown, it is a pain to set a breakpoint in the correct libsupc++
--- Additional Comments From pcarlini at suse dot de 2005-09-14 23:15
---
Well, I have a very donw to earth perplexity (have still to digest all the
various deep points and I'm a little tired, sorry): what about the demangling?
Only because the __PRETTY_FUNCTION__ extension does it for
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-09-14 23:53 ---
(In reply to comment #0)
mingw sets the USERNAME environment variable, we should use it to provide a
getlog procedure.
NT and later set USERNAME by default. win95, win98 do not. The var may
The following test case, derived from Eclipse/ecj, fails to compile on HEAD and
current 4.0 branch. This is a regression since 4.0.0.
package ast;
import classfmt.*;
public abstract class ASTNode implements ClassFileConstants {
}
---
package ast;
public class EqualExpression extends ASTNode {
--- Additional Comments From mckinlay at redhat dot com 2005-09-15 00:08
---
The problem is that fold_constant_for_init() saves the current_class state when
resolving other dependent constants, but not the current package
(ctxp-package). If a constant in another package is referenced,
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-15 00:15
---
(In reply to comment #0)
consider the following program
program random
implicit none
real :: x
call random_seed();
call random_number(x);
write(*,*) x
end program random
When I run this
--- Additional Comments From greenrd at gcc dot gnu dot org 2005-09-15
00:27 ---
Yes, I'm sure. I know what's going on here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-15
01:28 ---
Subject: Bug 23835
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-15 01:28:14
Modified files:
gcc: ChangeLog tree-ssa-alias.c
Log
--- Additional Comments From kamaraju at gmail dot com 2005-09-15 02:11
---
Subject: Re: non intuitive behaviour of gfortran
On 15 Sep 2005 00:15:27 -, kargl at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Additional Comments From kargl at gcc dot gnu dot org
I cannot find anything that says this should happen. It is causing SIGILL on
the host system.
When enabling -msse or -msse2 I expect the intrinsics to be enabled. This would
then be useful for creating SSE and non-SSE functions based off of CPUID.
However with these enabled, other code is
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-15
02:31 ---
Not a bug. Use a different file for the common code.
Yes the documention can be improved but that is PR 23809.
I am just going to mark this as a dup of bug 23809.
*** This bug has been marked as a
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-15
02:31 ---
*** Bug 23892 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From corey dot taylor at gmail dot com 2005-09-15
02:36 ---
Just the answer I was looking for. I tried a search but didn't find anything
with my keywords.
corey
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23892
--- Additional Comments From sgk at troutmask dot apl dot washington dot
edu 2005-09-15 03:43 ---
(In reply to comment #2)
I agree that the current gfortran's behaviour is standard conforming.
Enough said.
But it is counter intuitive.
It is counter intuitive to you
--- Additional Comments From appfault at hotmail dot com 2005-09-15 04:22
---
Yes well I don't think you should have to go out of your way to ask the
compiler to not generate invalid code. Not generating invalid code should be
the default behavior.
We're talking about the difference
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-15
04:52 ---
Yes well I don't think you should have to go out of your way to ask the
compiler to not generate invalid code. Not generating invalid code should be
the default behavior.
Again the compiler
92 matches
Mail list logo
