--- Comment #3 from burnus at gcc dot gnu dot org 2010-03-09 07:24 ---
Quoting the standard. Note especially that also "NaN(optional)" is valid:
"(1) On input, leading blanks are not significant. When the input field is not
an IEEE exceptional specification (10.6.1.2.1), the interpretat
--- Comment #38 from rupp at gnat dot com 2010-03-09 05:20 ---
I patched gnatpro gcc-head snapshot from 20100307 with "ppa" (less ada bits) as
instructed in comment #33, and it bootstraps fine on alphaev67-dec-osf5.1b,
also compiles p.ad[bs] aka "p.txt"
--
http://gcc.gnu.org/bugzill
--- Comment #21 from howarth at nitro dot med dot uc dot edu 2010-03-09
03:48 ---
Interestingly, I get...
gfortran -fgraphite-identity -O3 -Wstrict-overflow=5 -c spectop.f90
spectop.f90: In function spectop:
spectop.f90:5:0: warning: assuming signed overflow does not occur when chang
--- Comment #20 from howarth at nitro dot med dot uc dot edu 2010-03-09
03:45 ---
The offending optimization for the spectop subroutine at -O2
-fgraphite-identity appears to be -fstrict-overflow. I can compile...
gfortran -fgraphite-identity -O3 -fno-strict-overflow -c spectop.f90
gfor
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2010-03-09 02:38
---
Confirmed. In io/read.c we have:
/* TODO: handle not-a-numbers and infinities. */
I will take this on. But it is back burner to some other issues.
--
jvdelisle at gcc dot gnu dot org changed:
--- Comment #5 from jason at gcc dot gnu dot org 2010-03-09 02:38 ---
This is a bug: G++ fails to consider the built-in operator%(long,long) because
double is not an integral type.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #19 from howarth at nitro dot med dot uc dot edu 2010-03-09
02:37 ---
Created an attachment (id=20051)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20051&action=view)
diff between assembly for spectop subroutine at -O2 without and with
-fgraphite-identity
--
http
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2010-03-09
02:35 ---
Created an attachment (id=20050)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20050&action=view)
assembly for spectop subroutine compiled at -graphite-identity -O2 on
x86_64-apple-darwin10
--
h
--- Comment #17 from howarth at nitro dot med dot uc dot edu 2010-03-09
02:34 ---
Created an attachment (id=20049)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20049&action=view)
assembly for spectop subroutine compiled at -O2 on x86_64-apple-darwin10
--
http://gcc.gnu.org/b
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2010-03-09
02:26 ---
The miscompiled code in air.f90 is the subroutine SPECTOP. If I pull that
subroutine out into a separate file and compile it at -O3 without
-fgraphite-identity, the remainder of the code can be compiled wi
--- Comment #16 from paolo dot carlini at oracle dot com 2010-03-09 01:59
---
I reverted my changes and re-opened the PR: DR 579 is being resolved as NAD,
because there is evidence (eg, the Dinkumware implementation) that returning an
iterator doesn't necessarily impact performance.
-
--- Comment #15 from paolo at gcc dot gnu dot org 2010-03-09 01:56 ---
Subject: Bug 41975
Author: paolo
Date: Tue Mar 9 01:56:42 2010
New Revision: 157300
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157300
Log:
2010-03-08 Paolo Carlini
Revert:
2010-02-11
--- Comment #1 from scovich at gmail dot com 2010-03-09 01:04 ---
(In reply to comment #0)
> Let's just say this led to extremely frustrating behavior until I decided to
> start digging...
To be more specific, the gcc/as wrapper is generated with:
ORIGINAL_AS_FOR_TARGET=""
ORIGINAL_LD_
--- Comment #6 from smal dot root at gmail dot com 2010-03-09 01:02 ---
Well, I will make necessary tests
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43104
./configure ... --with-build-time-tools=$MY_TOOLS ignores $MY_TOOLS (though it
correctly warns when $MY_TOOLS is not an absolute path).
Let's just say this led to extremely frustrating behavior until I decided to
start digging...
Suggested patch to correct the problem:
Index: /home/Ryan/apps/gcc
--- Comment #3 from spop at gcc dot gnu dot org 2010-03-09 00:49 ---
Ok, so then this is not related to Graphite.
I'm removing the Graphite flag from the subject.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-09 00:36 ---
insert_partition_copy_on_edge does not take into account the mode being BLKmode
for SSA_NAMEs. This is only true with vector types.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43300
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-09 00:34 ---
As far as I can tell this is an out of SSA issue here is a testcase which will
fail on every target I know of:
typedef float V2SF __attribute__ ((vector_size (128)));
V2SF
foo (int x, V2SF a)
{
while (x--)
a +
Testcase is:
gcc.c-torture/compile/pr33614.c
with compiler parameters -Os -fgraphite-identity
-- pr33614.c --
typedef float V2SF __attribute__ ((vector_size (8)));
V2SF
foo (int x, V2SF a)
{
while (x--)
a += (V2SF) {1.0f/0.0f - 1.0f/0.0f, 1.0f/0.0f - 1.0f/0.0f};
return a;
}
--
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-09 00:14 ---
Could you please attach rs6000.i and what gcc options were used to compile it?
Would save me time building it tomorrow, I could jump straight to debugging.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||assemble-failure
Summary|Subversion id 157264 breaks |[4.5
Unless you use BOOT_CFLAGS='-g -O2 -fno-var-tracking', the change Jakub made on
March 7th, 2010 breaks the powerpc 64-bit bootstrap.
Here is the error message:
/tmp/cckGWIfy.s: Assembler messages:
/tmp/cckGWIfy.s:117666: Error: junk at end of line, first unrecognized
character is `@'
/tmp/cckGWIfy
--- Comment #7 from schaub-johannes at web dot de 2010-03-08 23:41 ---
I've digged this up from an early draft ('96:
http://ra.dkuug.dk/JTC1/SC22/WG21/docs/wp/txt/jun96/body.txt), '98 and '03).
Each has different rules. In fact, C++98 would accept comment#3's code.
- '96pre-standard sa
--- Comment #5 from eric dot weddington at atmel dot com 2010-03-08 23:26
---
(In reply to comment #4)
> > I still cannot reproduce the error
> you got
> >>lds r24, 0x
> that is error!
Take a look at the generated assembly. 3 accesses to the same variable. The
disassembly shows
--- Comment #15 from spop at gcc dot gnu dot org 2010-03-08 23:16 ---
Yes.
I think it is important to understand what is miscompiled with the graphite
identity.
I will try to reduce this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
--- Comment #5 from spop at gcc dot gnu dot org 2010-03-08 23:10 ---
Sorry, I didn't meant this.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #5 from spop at gcc dot gnu dot org 2010-03-08 23:10 ---
Ok, then let's close this PR.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from spop at gcc dot gnu dot org 2010-03-08 23:09 ---
Ok, then let's close this PR.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2010-03-08
23:09 ---
Is this issue to be fixed for gcc 4.5?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-03-08
23:07 ---
I don't see the failures on x86_64-apple-darwin10 on recent gcc trunk...
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg00487.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41334
--- Comment #49 from bernds_cb1 at t-online dot de 2010-03-08 23:06 ---
This fix caused a SPEC regression (see bug 42216). Could you test the patch I
attached to #42216, on top of current mainline, to see whether it does not
cause your problem to reappear?
--
http://gcc.gnu.org/bug
--- Comment #23 from bernds_cb1 at t-online dot de 2010-03-08 23:04 ---
Created an attachment (id=20048)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20048&action=view)
Alternative fix for 42220
If you wouldn't mind, please test the attached patch which should be an
alternative f
--- Comment #3 from spop at gcc dot gnu dot org 2010-03-08 22:59 ---
Hi Jack,
is gcc.dg/graphite/run-id-1.c still failing on x86_64-apple-darwin10 or has it
been fixed since then?
Thanks,
Sebastian
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41334
--- Comment #2 from hjl dot tools at gmail dot com 2010-03-08 22:54 ---
It was fixed between revision 157277 and revision 157292.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #20 from pinskia at gcc dot gnu dot org 2010-03-08 22:50
---
*** Bug 39604 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #22 from pinskia at gcc dot gnu dot org 2010-03-08 22:50
---
This is the same as bug 39509.
*** This bug has been marked as a duplicate of 39509 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from spop at gcc dot gnu dot org 2010-03-08 22:49 ---
Hi,
is this fail on i686-linux? On x86_64-unknown-linux-gnu I see no fails in
libgomp/ for graphite.exp .
Sebastian
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43274
--- Comment #4 from smal dot root at gmail dot com 2010-03-08 21:49 ---
> I still cannot reproduce the error
you got
>>lds r24, 0x
that is error!
address of variable is NULL. Address of
volatile uint8_t SomeVariable
cant be NULL in any case.
--
Data Memory Map for ATmega1
--- Comment #3 from eric dot weddington at atmel dot com 2010-03-08 21:35
---
(In reply to comment #2)
> (In reply to comment #1)
> > I cannot reproduce the problem.
> >
> >c: 80 91 00 00 lds r24, 0x
>
> Its mean load data from SRAM at address 0x. Variable (in ou
--- Comment #1 from jjcogliati-r1 at yahoo dot com 2010-03-08 21:17 ---
program should be: (both exhibit the bug though, but this works if bug is not
present)
program nan_test
implicit none
character(15) :: nan = ' NAN -INF INF'
real :: a,b,c, d = 0.0
print ('(3F5.2
--- Comment #2 from smal dot root at gmail dot com 2010-03-08 21:15 ---
(In reply to comment #1)
> I cannot reproduce the problem.
>
>c: 80 91 00 00 lds r24, 0x
Its mean load data from SRAM at address 0x. Variable (in our case
mUsart0BufferReadPtr) has address not
As I understand it, fortran should be able to read in a NaN or Inf value.
See 10.6.1.2.1 F editing in the Fortran 2003 specification. This is a new
Fortran 2003 feature and is not in the Fortran 95 specification.
gfortran properly prints out the NaN values, but cannot read them in, thus
causing t
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-03-08 21:09
---
If it works with 4.3.x then this is not a 4.3 regression.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from jakub at gcc dot gnu dot org 2010-03-08 21:07 ---
On the:
int i;
static int j;
extern int bar (void);
int foo (void)
{
return i + j + bar ();
}
testcase with -fexceptions -O2 -mtune=generic -dA -m32 -fpic the difference is:
@@ -14,9 +14,9 @@ foo:
.cfi_def_cf
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-08 21:03 ---
Created an attachment (id=20047)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20047&action=view)
gcc45-pr43293.patch
So far untested fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43293
--- Comment #1 from edwintorok at gmail dot com 2010-03-08 21:03 ---
Created an attachment (id=20046)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20046&action=view)
testcase
Testcase (partially) reduced with delta. Could probably be reduced further.
--
http://gcc.gnu.org/bu
--- Comment #1 from tromey at gcc dot gnu dot org 2010-03-08 21:02 ---
zlib is not maintained as part of gcc -- it is just imported into
the tree for convenience.
As such we minimize the changes we make to zlib.
A change like this one should be reported to the real zlib maintainers.
--
On sparc64 gcc 4.4.1 -O3 -fPIC breaks ClamAV's htmlnorm.c.
To reproduce bug:
$ /opt/cfarm/release/4.4.1/bin/gcc -O3 -fPIC hh.c
$ ./a.out
Aborted
On the attached testcase -O2 -fPIC breaks too (on ClamAV's htmlnorm only -O3
breaks):
$ /opt/cfarm/release/4.4.1/bin/gcc -O2 -fPIC hh.c
$ ./a.out
Aborte
--- Comment #1 from eric dot weddington at atmel dot com 2010-03-08 20:56
---
I cannot reproduce the problem.
Used this command line:
avr-gcc -save-temps -O0 -mmcu=atmega164p -c test.c -o test.o
Generated this assembly:
.file "test.c"
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L_
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-03-08 20:51
---
You need to ./configure the toplevel dir, not the gcc subir. See instructions.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
I have tried building both gcc-4.4.0 and gcc-4.4.4 and everytime I am running
into the same error ".../gcc-4.4.0/gcc/ada/gcc-interface/Make-lang.in:305 ***
multiple target patterns. Stop." I am trying to compile gcc(fortran and c)
using cygwin. I first download gcc-4.4.4.tar.bz2 and then extract al
I just ran the new sourceforge-based tool cppcheck over
the source code of the 4.5 snapshot 20100304 and cppcheck said
[./zlib/contrib/iostream2/zstream.h:101]: (style) The function 'izstream::fp'
can be const
[./zlib/contrib/iostream2/zstream.h:234]: (style) The function 'ozstream::fp'
can be con
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-03-08 20:19
---
Regarding the additional test cases given here:
http://gcc.gnu.org/ml/fortran/2010-03/msg00037.html
I do believe that gfortran has this correct. You are not allowed to attempt to
read from a location past the
--- Comment #3 from dushistov at mail dot ru 2010-03-08 20:18 ---
(In reply to comment #1)
> compiles without problems using 4.4.3 and 4.5.0
>
> if this only fails with GCC 4.2 it's unlikely to get fixed
>
There is something strange here.
I have report that with little different exam
--- Comment #11 from dominiq at lps dot ens dot fr 2010-03-08 20:06 ---
With the patch in comment #10 I am now at stage 2. So far so good! Thanks for
the patch.
Why is rs6000_delegitimize_address much simpler (even with the patch) than
ix86_delegitimize_address?
--
dominiq at lps do
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-03-08 19:49 ---
The regno that is failing is 22 which is xmm1.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-08 19:30 ---
This was fixed in at least 4.2.4 so closing as fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from aldot at gcc dot gnu dot org 2010-03-08 19:28 ---
(In reply to comment #8)
> What's the status of this bug ?
we currently still end up with
call 0
on e.g. i386
> The same things can happen in libraries with fpic
yes. Thing is that we could theoretically work around
--- Comment #1 from redi at gcc dot gnu dot org 2010-03-08 19:27 ---
compiles without problems using 4.4.3 and 4.5.0
if this only fails with GCC 4.2 it's unlikely to get fixed
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-08 19:15 ---
m68k probably needs a delegitimize_address target hook that will transform some
UNSPEC (or expression involving UNSPEC) back to what debuginfo can contain.
See i386, rs6000, s390 etc. hooks.
--
http://gcc.gnu.org/
--- Comment #10 from jakub at gcc dot gnu dot org 2010-03-08 19:08 ---
Created an attachment (id=20045)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20045&action=view)
gcc45-pr43287.patch
Possible fix. Needs testing on darwin as well as verification that there
really isn't any i
if [ x"-fpic" != x ]; then \
/home/andreas/src/gcc/m68k/./gcc/xgcc
-B/home/andreas/src/gcc/m68k/./gcc/ -B/usr/local/m68k-linux/m68k-linux/bin/
-B/usr/local/m68k-linux/m68k-linux/lib/ -isystem
/usr/local/m68k-linux/m68k-linux/include -isystem
/usr/local/m68k-linux/m68k-linux/sys-include
--- Comment #9 from jakub at gcc dot gnu dot org 2010-03-08 18:11 ---
x is:
(unspec:DI [
(symbol_ref/u:DI ("*LC0") [flags 0x2])
] 50)
Guess rs6000_delegitimize_address needs to handle UNSPEC_MACHOPIC_OFFSET.
ix86_delegitimize_address handles it, so assuming it means the same
--- Comment #4 from ullner at gmail dot com 2010-03-08 17:59 ---
That still doesn't make sense.
1. Why does enabling -O3 (O1 and O2 does the same) remove this problem?
2. Why does storing the value in an intermediate variable make any change in
what the result is?
Consider without O3:
(
--- Comment #4 from spop at gcc dot gnu dot org 2010-03-08 17:55 ---
Fixed by http://gcc.gnu.org/viewcvs?view=revision&revision=157286
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from spop at gcc dot gnu dot org 2010-03-08 17:54 ---
Fixed by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157287
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2010-03-08
17:54 ---
The last good build for powerpc-apple-darwin9 on regress was at r157263 so...
r157264
must be the offending commit. Is powerpc64-unknown-linux-gnu still
bootstrapping?
--
http://gcc.gnu.org/bugzilla/
--- Comment #12 from spop at gcc dot gnu dot org 2010-03-08 17:53 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #20 from spop at gcc dot gnu dot org 2010-03-08 17:51 ---
Fixed now the second unrelated bug reported within this PR.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from spop at gcc dot gnu dot org 2010-03-08 17:50 ---
Subject: Bug 43065
Author: spop
Date: Mon Mar 8 17:49:57 2010
New Revision: 157289
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157289
Log:
Fix PR43065: Insert bounds on pointer type parameters.
2010-03-05
--- Comment #10 from spop at gcc dot gnu dot org 2010-03-08 17:50 ---
Subject: Bug 43065
Author: spop
Date: Mon Mar 8 17:49:48 2010
New Revision: 157288
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157288
Log:
Add testcase from PR43065.
2010-03-04 Sebastian Pop
P
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2010-03-08
17:50 ---
regress is failing from this...
http://gcc.gnu.org/regtest/HEAD/native-lastbuild.txt.gzip
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43287
--- Comment #19 from spop at gcc dot gnu dot org 2010-03-08 17:49 ---
Subject: Bug 42326
Author: spop
Date: Mon Mar 8 17:48:55 2010
New Revision: 157280
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157280
Log:
Fix PR42326: handle default definitions.
2010-03-02 Sebastian Po
--- Comment #11 from pinskia at gcc dot gnu dot org 2010-03-08 17:16
---
No longer working on this one, I lost the patches when I left sony.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-03-08 17:15 ---
No longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from redi at gcc dot gnu dot org 2010-03-08 17:02 ---
(In reply to comment #11)
> hmm... is there a way to have g++ put everything into some default namespace
> so
> I always get errors like this? If so, that would satisfy my needs.
No.
--
http://gcc.gnu.org/bugz
--- Comment #10 from jakub at gcc dot gnu dot org 2010-03-08 17:00 ---
I'll test it, both on the trunk and 4.4-RH.
BTW, I've moved the 2) issue to PR43293.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
int i;
static int j;
extern int bar (void);
int foo (void)
{
return i + j + bar ();
}
-m32 -O2 -fpic -mtune=generic -fexceptions generates:
.cfi_startproc
pushl %ebp
.cfi_def_cfa_offset 8
movl%esp, %ebp
.cfi_offset 5, -8
.cfi_def_cfa_register
--- Comment #9 from hjl dot tools at gmail dot com 2010-03-08 16:58 ---
(In reply to comment #8)
> Created an attachment (id=20044)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20044&action=view) [edit]
> gcc44-pr43290-2.patch
>
> Another fix. Wonder why that insn is marked as f
--- Comment #8 from jakub at gcc dot gnu dot org 2010-03-08 16:45 ---
Created an attachment (id=20044)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20044&action=view)
gcc44-pr43290-2.patch
Another fix. Wonder why that insn is marked as frame related at all, for the
drap saving t
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-08 16:42 ---
Oh, it is. Sorry for the noise.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jakub at gcc dot gnu dot org 2010-03-08 16:39 ---
Created an attachment (id=20043)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20043&action=view)
gcc44-pr43290-1.patch
One alternative fix that cures this testcase on redhat/gcc-4_4-branch.
--
http://gcc.g
--- Comment #6 from jakub at gcc dot gnu dot org 2010-03-08 16:38 ---
Not sure if there haven't been follow-ups. There were at least 100 changes to
dwarf2out.c since 4.4 release, and at least 10 of them were related to the
indirect vs. direct stuff.
--
http://gcc.gnu.org/bugzilla/s
--- Comment #11 from erh+gcc at nimenees dot com 2010-03-08 16:36 ---
(In reply to comment #6)
> You don't need a new warning to get what you want, as long as you put your
> functions in a namespace:
>
...snip...
> error: 'void ns::myfunc(const char*)' should have been declared inside '
--- Comment #10 from erh+gcc at nimenees dot com 2010-03-08 16:35 ---
(In reply to comment #8)
> > The code that calls the function also *compiles* cleanly, and only the link
> > fails.
>
> No, the code calling it does not compile cleanly if there's no previous
> declaration.
> It only
--- Comment #1 from hjl dot tools at gmail dot com 2010-03-08 16:32 ---
It is caused by revision 154121:
http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00342.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43288
--- Comment #9 from bangerth at gmail dot com 2010-03-08 16:23 ---
(In reply to comment #7)
> The code that calls the function also *compiles* cleanly, and only the link
> fails.
By compiling I meant translating from source code to executable. That
includes linking. The point I want to
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aldyh at gcc dot gnu dot org
|dot org
--- Comment #8 from redi at gcc dot gnu dot org 2010-03-08 16:18 ---
(In reply to comment #7)
>
> That's exactly my point! This is a case where the (function implementation)
> code DOES compile cleanly, but there is an obvious problem that causes it to
> be
> unusable.
See comment 6
--- Comment #1 from uweigand at gcc dot gnu dot org 2010-03-08 16:11
---
Why doesn't this make sense? The address space is a property of the pointed-to
type, not the pointer type itself (just like const/volatile-ness) ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43292
--- Comment #13 from redi at gcc dot gnu dot org 2010-03-08 16:10 ---
the decltype issue is
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#743
the proposed change is in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3031.pdf
suspending ...
--
redi at gcc dot
--- Comment #7 from erh+gcc at nimenees dot com 2010-03-08 16:07 ---
(In reply to comment #5)
> What I'm saying is that this entire discussion is already present in PR13687
> and that there is nothing more to say. The warning exists in C because it
> can lead to hard-to-find bugs in C co
expr.c:expand_expr_real_1
case TARGET_MEM_REF:
{
addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (exp));
struct mem_address addr;
doesn't make sense. TREE_TYPE (exp) is the type of the access, not
the pointer-type used for it.
--
Summary: Bogus TYPE_ADDR_SPAC
--- Comment #12 from manu at gcc dot gnu dot org 2010-03-08 15:59 ---
*** Bug 43285 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6709
--- Comment #4 from manu at gcc dot gnu dot org 2010-03-08 15:59 ---
(In reply to comment #3)
> You sure that you want to ban this? Looks like you'll just have to unban it
> again. From http://en.wikipedia.org/wiki/Decltype:
This information is nice and welcome but doesn't make this bug
--- Comment #1 from dominiq at lps dot ens dot fr 2010-03-08 15:57 ---
As noted in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43256#c9, the third
hunk of the patch for resolve.c in revision 157272 does not apply to
fortran-dev. The test in comment #0 passes with fortran-dev and my patch
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-03-08 15:53 ---
Works for me, thus is ok for trunk with a changelog entry.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #20 from janus at gcc dot gnu dot org 2010-03-08 15:50 ---
(In reply to comment #18)
> I will open a new PR for this.
This is now PR 43291.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
--- Comment #19 from dominiq at lps dot ens dot fr 2010-03-08 15:49 ---
(In reply to comment #18)
> This is surely due to the patch for PR43256 that I committed today.
Sure!
> Note that this only happens for comment #1, but not for
> comment #8, which still gives the same error as bef
This is a spin-off from PR42769 comment #17. The test case has been extracted
from comment #1 in that PR. It was working before r157272 (which fixed
PR43256), but fails now:
module m1
type :: t1
contains
procedure :: sizeof
end type
contains
integer function sizeof(a)
class(t1) :
1 - 100 of 151 matches
Mail list logo
