[Bug fortran/45197] [F2008] Allow IMPURE elemental procedures

[domob at gcc dot gnu dot org]

--- Comment #2 from domob at gcc dot gnu dot org  2010-08-15 15:28 ---
Subject: Bug 45197

Author: domob
Date: Sun Aug 15 15:28:10 2010
New Revision: 163261

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163261
Log:
2010-08-15  Daniel Kraft  

PR fortran/45197
* decl.c (gfc_match_prefix): Match IMPURE prefix and mark ELEMENTAL
routines not IMPURE also as PURE.
* intrinsic.c (enum klass): New class `CLASS_PURE' and renamed
`NO_CLASS' in `CLASS_IMPURE'.
(add_sym): Set symbol-attributes `pure' and `elemental' correctly.
(add_sym_0s): Renamed `NO_CLASS' in `CLASS_IMPURE'.
(add_functions): Ditto.
(add_subroutines): Ditto and mark `MOVE_ALLOC' as CLASS_PURE.
* resolve.c (gfc_pure): Do not treat ELEMENTAL as automatically PURE.
(resolve_formal_arglist): Check that arguments to ELEMENTAL procedures
are not ALLOCATABLE and have their INTENT specified.

2010-08-15  Daniel Kraft  

PR fortran/45197
* gfortran.dg/elemental_args_check_3.f90: New test.
* gfortran.dg/impure_1.f08: New test.
* gfortran.dg/impure_2.f08: New test.
* gfortran.dg/impure_3.f90: New test.
* gfortran.dg/typebound_proc_6.f03: Changed expected error message.

Added:
trunk/gcc/testsuite/gfortran.dg/elemental_args_check_3.f90
trunk/gcc/testsuite/gfortran.dg/impure_1.f08
trunk/gcc/testsuite/gfortran.dg/impure_2.f08
trunk/gcc/testsuite/gfortran.dg/impure_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/intrinsic.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/typebound_proc_6.f03


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45197

[Bug fortran/45211] C interoperable error when compiling BIND(C) function in a module.

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2010-08-15 16:21 ---
Subject: Bug 45211

Author: burnus
Date: Sun Aug 15 16:20:56 2010
New Revision: 163264

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163264
Log:
2010-08-15  Tobias Burnus  

PR fortran/45211
* decl.c (verify_c_interop_param): Remove superfluous space (" ").
(verify_c_interop): Handle unresolved DT with bind(C).

2010-08-15  Tobias Burnus  

PR fortran/45211
* gfortran.dg/bind_c_usage_21.f90: New.
* gfortran.dg/bind_c_dts_3.f03: Update dg-error.


Added:
trunk/gcc/testsuite/gfortran.dg/bind_c_usage_21.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/bind_c_dts_3.f03


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45211

[Bug fortran/45211] C interoperable error when compiling BIND(C) function in a module.

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2010-08-15 16:23 ---
FIXED on the trunk (4.6). Thanks for the bug report!

(I do not intent to backport the patch to the 4.4/4.5 branch; tell me if you
think it should be applied there as well.)


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45211

[Bug fortran/45197] [F2008] Allow IMPURE elemental procedures

[domob at gcc dot gnu dot org]

--- Comment #3 from domob at gcc dot gnu dot org  2010-08-15 16:26 ---
Fixed.


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45197

[Bug fortran/44666] [F2008] Passing NULL pointer or unallocated allocatable to OPTIONAL dummy

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2010-08-15 16:26 ---
FIXED on the 4.6 trunk.

I have missed to include the PR when writing, submitting, and committing the
patch. It can be found at:

Patch: http://gcc.gnu.org/ml/fortran/2010-08/msg00174.html
Committal: http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00474.html


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44666

[Bug fortran/45128] Segmentation fault with -fwhole-file for subref_array_pointer

[paul dot richard dot thomas at gmail dot com]

--- Comment #4 from paul dot richard dot thomas at gmail dot com  
2010-08-15 16:32 ---
Subject: Re:  Segmentation fault with -fwhole-file for subref_array_pointer

Dear Jerry,


> --- Comment #3 from jvdelisle at gcc dot gnu dot org  2010-08-09 17:18 
> ---
> Paul, can you send me a preview of the new descriptor structure so I can be
> planning the internal unit I/O impacts if any.

This is something that we will all have to agree.  At present, my work
is entirely devoted to getting the new dimension triplet working and
sorting out the side-effects of adding one or more new fields to the
descriptor. It's a real dog... Still, I have four evenings that I
can devote to it this week :-)

Cheers

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45128

[Bug fortran/45288] New: Double initialization: Warn if the value is different

[burnus at gcc dot gnu dot org]

The following program (pasted in the #fortran IRC channel) is accepted by
gfortran -- unless -std=f2008 is used.

Expected: By default a warning (or error) is printed - if two different values
are used. Maybe one should reject the program altogether - or allow it only
with -std=legacy. -- The program can too easily produce indented results (cf.
below).

However, I think one can still allow double initialization of the same value
with -std=gnu and without a warning.

Without a warning (or better error) one can easily miss unintended double
initializations - e.g. in legacy programs. Additionally, the result of such an
initialization by different values is completely arbitrary as the program below
shows. As variant, one can swap the whole-array initialization ("prefill") with
the "individual values".

ifort always prints "-1" independent of the order, Pathscale seemingly does
what the user intended - the initially set "-1" is later overridden. While
gfortran keeps the initial value, i.e. prints "-1" for the program below but
the "intended" result if one swaps the order.

  PROGRAM Foo
C COMMON Variables
PARAMETER (MatDim=4)
PARAMETER (MatMax=MatDim**2)
DOUBLE PRECISION Matrix(MatDim,MatDim)
COMMON /CNMatrix/ Matrix
PRINT *,'Matrix:'
PRINT '(4(4(F5.2,3H),/))',Matrix
  END

  BLOCK DATA MatrixData
C COMMON Variables
PARAMETER (MatDim=4)
PARAMETER (MatMax=MatDim**2)
DOUBLE PRECISION Matrix(MatDim,MatDim)
COMMON /CNMatrix/ Matrix

DATA Matrix/MatMax*-1.0/  ! prefill
DATA Matrix(2,1)/2.0/  ! individual values
DATA Matrix(1,2)/3.0/  ! individual values
  END


-- 
   Summary: Double initialization: Warn if the value is different
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45288

[Bug target/45196] ld: warning: can't add line info to anonymous symbol

[howarth at nitro dot med dot uc dot edu]

--- Comment #3 from howarth at nitro dot med dot uc dot edu  2010-08-15 
17:36 ---
These still appear to be present on i386-apple-darwin10 but not
x86_64-apple-darwin10. Odd.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45196

[Bug fortran/45170] [F2003] allocatable character lengths

[kargl at gcc dot gnu dot org]

--- Comment #4 from kargl at gcc dot gnu dot org  2010-08-15 18:46 ---
A patch to do the parsing and some error checking has
been posted at

http://gcc.gnu.org/ml/fortran/2010-08/msg00181.html

It is not a complete implementation of the feature
and requires much additional work.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170

[Bug target/45196] ld: warning: can't add line info to anonymous symbol

[howarth at nitro dot med dot uc dot edu]

--- Comment #4 from howarth at nitro dot med dot uc dot edu  2010-08-15 
18:47 ---
Created an attachment (id=21480)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21480&action=view)
compressed preprocessed source for 20_util/auto_ptr/6.cc on
-i386-apple-darwin10


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45196

[Bug target/45196] ld: warning: can't add line info to anonymous symbol

[howarth at nitro dot med dot uc dot edu]

--- Comment #5 from howarth at nitro dot med dot uc dot edu  2010-08-15 
18:48 ---
Created an attachment (id=21481)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21481&action=view)
compressed assembly file for 20_util/auto_ptr/6.cc on -i386-apple-darwin10


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45196

[Bug target/45196] ld: warning: can't add line info to anonymous symbol

[howarth at nitro dot med dot uc dot edu]

--- Comment #6 from howarth at nitro dot med dot uc dot edu  2010-08-15 
18:48 ---
Created an attachment (id=21482)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21482&action=view)
compressed object file for 20_util/auto_ptr/6.cc on -i386-apple-darwin10


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45196

[Bug target/45196] ld: warning: can't add line info to anonymous symbol

[howarth at nitro dot med dot uc dot edu]

--- Comment #7 from howarth at nitro dot med dot uc dot edu  2010-08-15 
18:52 ---
Files created with...

/sw_i386/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/g++ -shared-libgcc
-B/sw_i386/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc -nostdinc++
-L/sw_i386/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/i386-apple-darwin10.5.0/libstdc++-v3/src
-L/sw_i386/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/i386-apple-darwin10.5.0/libstdc++-v3/src/.libs
-B/sw_i386/lib/gcc4.6/i386-apple-darwin10.5.0/bin/
-B/sw_i386/lib/gcc4.6/i386-apple-darwin10.5.0/lib/ -isystem
/sw_i386/lib/gcc4.6/i386-apple-darwin10.5.0/include -isystem
/sw_i386/lib/gcc4.6/i386-apple-darwin10.5.0/sys-include
-B/sw_i386/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/i386-apple-darwin10.5.0/./libstdc++-v3/src/.libs
-g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections
-g -O2 -g -O2 -DLOCALEDIR="." -nostdinc++
-I/sw_i386/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/i386-apple-darwin10.5.0/libstdc++-v3/include/i386-apple-darwin10.5.0
-I/sw_i386/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/i386-apple-darwin10.5.0/libstdc++-v3/include
-I/sw_i386/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100814/libstdc++-v3/libsupc++
-I/sw_i386/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100814/libstdc++-v3/include/backward
-I/sw_i386/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100814/libstdc++-v3/testsuite/util
/sw_i386/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100814/libstdc++-v3/testsuite/20_util/auto_ptr/6.cc
-include bits/stdc++.h ./libtestc++.a -L/sw_i386/lib -liconv -lm --save-temps
-m32 -o ./6.exe
ld: warning: can't add line info to anonymous symbol
cstring=A_from_A_ptr->ctor_count == 1 from 6.o


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45196

[Bug middle-end/37734] Missing optimization: gcc fails to reuse flags from already calculated expression for condition check with zero

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|target  |middle-end
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-08-15 18:59:54
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37734

[Bug middle-end/44569] Debug statements passed to rtx

[steven at gcc dot gnu dot org]

--- Comment #1 from steven at gcc dot gnu dot org  2010-08-15 19:05 ---
Is this still a problem for you? I can try to help you here, but I need to know
what patch I should apply and to what revision, to reproduce the problem.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44569

[Bug c/45289] New: gcc lacks a "posix" option for "-std" since POSIX 2008 defines special behavior

[reddwarf at opensuse dot org]

As originally reported at
http://lists.opensuse.org/opensuse-packaging/2010-08/msg00038.html POSIX 2008
says
(http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_12_03):

"2.12.3 Pointer Types

All function pointer types shall have the same representation as the type
pointer to void. Conversion of a function pointer to void * shall not alter the
representation. A void * value resulting from such a conversion can be
converted back to the original function pointer type, using an explicit cast,
without loss of information.

Note:
The ISO C standard does not require this, but it is required for POSIX
conformance."

When compiling the example code for dlsym
(http://www.opengroup.org/onlinepubs/9699919799/functions/dlsym.html) gcc
complains with: "warning: dereferencing type-punned pointer will break
strict-aliasing rules".

Not sure how this applies for C++, but g++ outputs the same warning.


The suggested fix is to add a posix/posix2008 mode and make that the default
for "platforms that are supposed to be POSIX", specifically Linux.


-- 
   Summary: gcc lacks a "posix" option for "-std" since POSIX 2008
defines special behavior
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reddwarf at opensuse dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45289

[Bug c/45289] gcc lacks a "posix" option for "-std" since POSIX 2008 defines special behavior

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-08-15 19:31 ---
> "*(void **)(&comp_compress) = dlsym(handle, "comp_compress");"

That is not alias safe. Try instead:
comp_compress = (__typeof__(comp_compress)) dlsym(handle, "comp_compress");

Which is alias safe.  In fact reading what posix standard says it talks about
conversion between pointer to function types being safe but not access to a
function pointer type via a pointer to void type.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45289

[Bug middle-end/44569] Debug statements passed to rtx

[artyom dot shinkaroff at gmail dot com]

--- Comment #2 from artyom dot shinkaroff at gmail dot com  2010-08-15 
19:35 ---
Created an attachment (id=21483)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21483&action=view)
Recent version of the patch for the revision 163240

Recent version of the patch for the revision 163240


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44569

[Bug middle-end/44569] Debug statements passed to rtx

[artyom dot shinkaroff at gmail dot com]

--- Comment #3 from artyom dot shinkaroff at gmail dot com  2010-08-15 
19:38 ---
Yes, I still would like to solve the problem.

I just uploaded the patch for the revision 163240 (2010-08-14). The bug is
still there. The problem happens when you compile the following code with "-On
-g".

#define vector(elcount, type)  \
__attribute__((vector_size((elcount)*sizeof(type type

#define vidx(type, vec, idx) (*((type *) &(vec) + idx))
#define uchar unsigned char

#define ch14 1,2,3,4
#define ch1  1,1,1,1

int main (int argc, char *argv[]) {
vector(16, uchar) vuchar  = { ch14, ch14, ch14, ch14};
vector(16,  char) vchar0  = { ch1, ch1, ch1, ch1};
vector(16, uchar) u1;

u1 = vuchar << vchar0;

if (vidx(char, u1, 0) != ((uchar)1  << (char)1))
__builtin_abort ();

vuchar <<= vchar0;
return 0;
}

The error message is the same as in the original description.
Thanks for help.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44569

[Bug c/45289] gcc lacks a "posix" option for "-std" since POSIX 2008 defines special behavior

[redi at gcc dot gnu dot org]

--- Comment #2 from redi at gcc dot gnu dot org  2010-08-15 19:38 ---
I don't think adding -std=posix is the right solution, since dlsym needs to be
usable if users choose other options such as -std=c++0x or -std=gnu99


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45289

[Bug fortran/45290] New: [F08] pointer initialization

[janus at gcc dot gnu dot org]

John Reid, The new features of Fortran 2008, chapter 5.5:

A pointer may be initially associated with a target:

type (entry), target :: bottom
type (entry), pointer :: top => bottom

*

Currently gfortran responds with:

type (entry), pointer :: top => bottom
   1
Error: Pointer initialization requires a NULL() at (1)

*

A look at the current draft of F08 seems to indicate that this is allowed for
any kind of pointer: Data pointers and data pointer components as well as
procedure pointers and procedure pointer components. See:

R442 component-initialization
R443 initial-data-target
C460

R505 initialization
C511

R1216 proc-pointer-init
R1217 initial-proc-target

Note: For procedure-pointer components I was not able to find any specific
reference to non-NULL default initialization. However, chapter 4.5.4.6
("Default initialization for components") explicitly mentions the possibility
of having an initial-proc-target for a PPC.


-- 
   Summary: [F08] pointer initialization
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org
OtherBugsDependingO 39627
 nThis:


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290

[Bug fortran/38936] F2003: ASSOCIATE construct / improved SELECT TYPE (a=>expr)

[domob at gcc dot gnu dot org]

--- Comment #6 from domob at gcc dot gnu dot org  2010-08-15 19:46 ---
Subject: Bug 38936

Author: domob
Date: Sun Aug 15 19:46:21 2010
New Revision: 163268

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163268
Log:
2010-08-15  Daniel Kraft  

PR fortran/38936
* gfortran.h (gfc_find_proc_namespace): New method.
* expr.c (gfc_build_intrinsic_call): No need to build symtree messing
around with namespace.
* symbol.c (gfc_find_proc_namespace): New method.
* trans-decl.c (gfc_build_qualified_array): Use it for correct
value of nest.
* primary.c (gfc_match_varspec): Handle associate-names as arrays.
* parse.c (parse_associate): Removed assignment-generation here...
* resolve.c (resolve_block_construct): ...and added it here.
(resolve_variable): Handle names that are arrays but were not parsed
as such because of association.
(resolve_code): Fix BLOCK resolution.
(resolve_symbol): Generate array-spec for associate-names.

2010-08-15  Daniel Kraft  

PR fortran/38936
* gfortran.dg/associate_1.f03: Enable test for array expressions.
* gfortran.dg/associate_3.f03: Clarify comment.
* gfortran.dg/associate_5.f03: New test.
* gfortran.dg/associate_6.f03: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/associate_5.f03
trunk/gcc/testsuite/gfortran.dg/associate_6.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/symbol.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/associate_1.f03
trunk/gcc/testsuite/gfortran.dg/associate_3.f03


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38936

[Bug c/45289] gcc lacks a "posix" option for "-std" since POSIX 2008 defines special behavior

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-08-15 19:47 ---
Yes, POSIX adds additional requirements about pointer representation and
conversion, but AFAIK all targets GCC support and have POSIXish runtime satisfy
that.  The conversion between pointer types is not the problem in your code, it
is aliasing violation, and there is nothing in POSIX that says your code is
valid.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45289

[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements

[janus at gcc dot gnu dot org]

--- Comment #9 from janus at gcc dot gnu dot org  2010-08-15 20:01 ---
(In reply to comment #4)
> Possible solutions:
> 1) Make sure we use the right symbol from the right module.
> 2) Do the vtab initialization inside the module that defines the class, i.e.
> add a module procedure like 'vtab$trivial_gradient_type$init' which does it,
> and call this from the main program. Then there is no name ambiguity.

3) Do it in the original module (like in #2), but statically via default
initialization. This is definitely the most elegant and efficient way. It
should be possible once PR45290 is implemented.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271

[Bug target/45291] New: avr miscompilations related to frame pointer registers

[otaylor at redhat dot com]

Opening caveats: This comes from a day of digging into why the Arduino
environment wasn't working correctly on my Fedora 13 system with avr-gcc-4.5.
I'm not a GCC hacker and not intending to become one, so forgive sloppy
terminology and if the right fix is one of the larger things I mention below,
someone else is going to have to do it. I didn't turn up any previous work on
this other than people on the Arduino forums recommending downgrading to
gcc-4.3, but I also didn't actively ask around, so I'm 3/4's expecting a fix
for this to already exist somewhere on gcc-patches or on someone's hard drive.
If so, at least I learned a bit more about GCC internals. :-)

OK, with that out of the way, the following code is miscompiling on AVR (-O1 or
-O2) with gcc-4.5.1:

===
unsigned char func1(void);
void funct2(int l);

void dummy(void) {
  int l = 256 * func1() + func1();
  if (l > 256) {
  return;
  }
  func1();
  funct2(l);
}
===

Producing the assembly for the body of the function:

===
rcall func1
rcall func1
ldi r18,lo8(0)
mov r28,r18
mov r29,r19
add r28,r24
adc r29,__zero_reg__
ldi r19,hi8(257)
cpi r28,lo8(257)
cpc r29,r19
brge .L1
rcall func1
mov r24,r28
mov r25,r29
rcall funct2
===

The obvious place where things go wrong is in the IRA pass. THe insns:

===
(insn 35 10 33 2 foo.c:5 (set (reg:HI 50 [ D.1955 ])
(const_int 0 [0x0])) 10 {*movhi} (nil))

(insn 33 35 34 2 foo.c:5 (set (subreg:QI (reg:HI 50 [ D.1955 ]) 1)
(reg:QI 41 [ D.1955 ])) 4 {*movqi} (expr_list:REG_DEAD (reg:QI 41 [
D.1955 ])
(nil)))

(insn 34 33 13 2 foo.c:5 (set (subreg:QI (reg:HI 50 [ D.1955 ]) 0)
(const_int 0 [0x0])) 4 {*movqi} (nil))
===

Get rewritten after register assignment (r41 => r17, r50 => r28) to:

===
(insn 35 10 37 2 foo.c:5 (set (reg:HI 28 r28 [orig:50 D.1955 ] [50])
(const_int 0 [0x0])) 10 {*movhi} (expr_list:REG_EQUAL (const_int 0
[0x0])
(nil)))

(insn 37 35 33 2 foo.c:5 (set (reg:HI 14 r14)
(reg:HI 28 r28 [orig:50 D.1955 ] [50])) 10 {*movhi} (nil))

(insn 33 37 39 2 foo.c:5 (set (reg:QI 18 r18)
(reg:QI 17 r17 [orig:41 D.1955 ] [41])) 4 {*movqi} (nil))

(insn 39 33 38 2 foo.c:5 (set (reg:QI 15 r15 [+1 ])
(reg:QI 18 r18)) 4 {*movqi} (nil))

(insn 38 39 34 2 foo.c:5 (set (reg:HI 28 r28 [orig:50 D.1955 ] [50])
(reg:HI 14 r14)) 10 {*movhi} (nil))

(insn 34 38 40 2 foo.c:5 (set (reg:QI 18 r18)
(const_int 0 [0x0])) 4 {*movqi} (nil))

(insn 40 34 13 2 foo.c:5 (set (reg:HI 28 r28 [orig:50 D.1955 ] [50])
(reg:HI 18 r18)) 10 {*movhi} (nil))
===

Note the the way that insn 34 is transformed into insn 34 and 40, which
at first glance aren't doing the same thing at all and overwrite the
earlier computation of r29.

There are basically two problems here:

 Problem 1: there are severe restrictions on the use of r28/r29 (which
 is the frame pointer) from checks in avr_hard_regno_mode_ok() and
 in simplify_gen_subreg. These checks prevent subregister access to
 it by splitting it into two pieces from being allowed.

 See:

http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00834.html

 for some background information. But the register allocator happily
 puts stuff into r28/r29 and reload has to bend over backwards to
 try and sort things out.

 Problem 2: supposedly, according to the description of (set...) in rtl.texi

[...], if @var{lval} is a @code{subreg} whose machine mode is
narrower than the mode of the register, the rest of the register can
be changed in an undefined way.

 So actually the transform from insn 34 to insn 34/40 is correct. It's the
 generation of insn 40 by lower-subreg.c:resolve_shift_zext() that was
 wrong; for dest_zero it generates a (subreg ...) expression when setting
 the low part after setting the high part.

 This may be the only place where there is a problem, but considering
 the enormous amount of simplify_gen_subreg(), and the very limited use
 of (strict-lower-part...) my guess is that there are a bunch of similar
 problems.

 The insn 34 => insn 34/40 transformation comes from code in push_reload()
which
 turns a subreg set into a set of the full parent register if that would
 be valid according to the above rule and direct subreg access isn't
 allowed.

 (The slightly smaller of the two gigantic if statements in that function,
 with the comment "Similarly for paradoxical and problematical SUBREGs
 on the output." I think this is the "problematic" part of that, and
 is modelled by the '!HARD_REGNO_MODE_OK (subreg_regno (out), outmode)'
 check within that function.)

So, ideas about fixing:

 1) Remove r28/r29 (the framepointer) from GENERAL_REGS on AVR.
Then (almost?) nothing will ever be allocated to it, and it should
be at least very hard to trigger the problem. I'll attach a patch
implementing this. It seems to work in basic testing; libgcc compiles,
the te

[Bug c/45289] gcc lacks a "posix" option for "-std" since POSIX 2008 defines special behavior

[reddwarf at opensuse dot org]

--- Comment #4 from reddwarf at opensuse dot org  2010-08-15 20:21 ---
> Yes, POSIX adds additional requirements about pointer representation and
> conversion, but AFAIK all targets GCC support and have POSIXish runtime 
> satisfy
> that.  The conversion between pointer types is not the problem in your code, 
> it
> is aliasing violation, and there is nothing in POSIX that says your code is
> valid.

Uhm. Sorry, indeed the example code in posix 2008 dlsym() documentation is
wrong because of aliasing (where should this be reported? is also wrong in
http://www.kernel.org/doc/man-pages/). I was confused because that code was
wrong in posix 2004 but the fix from comment #1 was also wrong (not anymore in
posix 2008).


But using the fix from comment #1 gcc complains with "warning: ISO C forbids
conversion of object pointer to function pointer type", at least when using
-pedantic.
The *message* in the warning is correct. But it is complaining about something
that isn't a conversion from "object pointer to function pointer type" but a
conversion from "void* pointer to function pointer type", that posix 2008
explicitly allows.


-- 

reddwarf at opensuse dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45289

[Bug fortran/38936] F2003: ASSOCIATE construct / improved SELECT TYPE (a=>expr)

[domob at gcc dot gnu dot org]

--- Comment #7 from domob at gcc dot gnu dot org  2010-08-15 20:25 ---
This extended the support to array-expressions -- the original example works
now.  Next will be a rework to do the association in the trans phase, which is
probably necessary to get full array support and association to variables
working.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38936

[Bug target/45291] avr miscompilations related to frame pointer registers

[otaylor at redhat dot com]

--- Comment #1 from otaylor at redhat dot com  2010-08-15 20:27 ---
Created an attachment (id=21484)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21484&action=view)
Patch removing the frame pointer from general regs

Here's the patch described; I don't have any sort of extensive framework for
testing the AVR backend - doing such tests would likely be a good idea before
applying this if the general idea is right.

(Patch is git formatted and against 4.5.1 but it should apply to the trunk of
svn fine.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45291

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2010-08-15 20:36 ---
It works for me:

(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /export/home/hjl/bugs/gcc/pr45286/foo 

Breakpoint 1, sigvtalarm (foo=0) at foo.c:25
25  {
(gdb) x/1g $rsp
0x7fffde38: 0x00401060
(gdb) disass 0x00401060
Dump of assembler code for function __restore_rt:
   0x00401060 <+0>: mov$0xf,%rax
   0x00401067 <+7>: syscall 
   0x00401069 <+9>: nopl   0x0(%rax)
End of assembler dump.
(gdb) 

You have to show me how I can reproduce miscompiled
sigaction.c.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[vapier at gentoo dot org]

--- Comment #8 from vapier at gentoo dot org  2010-08-15 20:40 ---
yes, we did.  take the .i files we already posted and compile them with the
quoted pic/pie flags and look at the disassembled code.

the hardened gentoo variant builds all of glibc with pic/pie support (including
static libraries) which is why building a stock glibc with stock gcc wont hit
the problem.

i dont see how the disassembled code using mov to load up data can work.  is it
attempting to read a PLT entry or something ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug fortran/24524] Fortran dependency checking should reverse loops

[tkoenig at gcc dot gnu dot org]

--- Comment #6 from tkoenig at gcc dot gnu dot org  2010-08-15 20:41 ---
Hello Paul,

I think the patch you committed to 4.5 causes a regression for normal
loops, which are now handled as overlapping.

I think I fixed that in

http://gcc.gnu.org/viewcvs?view=revision&revision=162829

on trunk.

Could you maybe backport that patch, or, if I got that wrong,
look at fixing the regression some other way?  Test case is
dependency_29.f90 on trunk.

(I don't have access to my e-mail or to SVN right now, so
I can't do this myself).

Thomas


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24524

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[hjl dot tools at gmail dot com]

--- Comment #9 from hjl dot tools at gmail dot com  2010-08-15 20:45 ---
You have to show me exact CFLAGS used to compile sigaction.c.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug middle-end/44569] Debug statements passed to rtx

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2010-08-15 20:48 ---
Investigating...


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |steven at gcc dot gnu dot
   |dot org |org
 Status|WAITING |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-08-15 20:48:13
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44569

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[vapier at gentoo dot org]

--- Comment #10 from vapier at gentoo dot org  2010-08-15 21:01 ---
from the glibc-2.11.2/signal/ subdir:

$ gcc -Wall -Winline -Wwrite-strings -Wstrict-prototypes -std=gnu99 -O2
-fgnu89-inline -fmerge-all-constants -fno-strict-aliasing -fno-unwind-tables -g
-pipe '-DWRAPPER_INCLUDE=' -I../include
-I/var/tmp/portage/sys-libs/glibc-2.11.2/work/build-amd64-x86_64-pc-linux-gnu-nptl/signal
-I/var/tmp/portage/sys-libs/glibc-2.11.2/work/build-amd64-x86_64-pc-linux-gnu-nptl
-I../sysdeps/x86_64/elf -I../nptl/sysdeps/unix/sysv/linux/x86_64
-I../sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/wordsize-64
-I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread
-I../sysdeps/pthread -I../ports/sysdeps/unix/sysv/linux
-I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common
-I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../nptl/sysdeps/unix/sysv
-I../ports/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64
-I../nptl/sysdeps/unix -I../ports/sysdeps/unix -I../sysdeps/unix
-I../sysdeps/posix -I../sysdeps/x86_64/fpu -I../nptl/sysdeps/x86_64
-I../sysdeps/x86_64 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754/ldbl-96
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754
-I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I../ports -I..
-I../libio -I. -nostdinc -isystem
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/include -isystem
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/include-fixed -isystem /usr/include
-D_LIBC_REENTRANT -include ../include/libc-symbols.h -U_FORTIFY_SOURCE -DPIC
../sysdeps/unix/sysv/linux/x86_64/sigaction.c -c -o sigaction.o -fPIC -fPIE

$ objdump -d -r sigaction.o | grep rax.*restore
  db:   48 8b 05 2e ff ff ffmov-0xd2(%rip),%rax   # 10 <__restore_rt>

emphasis is that it is PIC+PIE+NOSHARED


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45289] gcc lacks a "posix" option for "-std" since POSIX 2008 defines special behavior

[matz at gcc dot gnu dot org]

--- Comment #5 from matz at gcc dot gnu dot org  2010-08-15 21:07 ---
First, yes, the work-around from the official POSIX man-pages is alias-unsafe.
They added this example because ISO C doesn't allow conversion of void*
pointers to function pointer, but dlsym returns a void* pointer.

There are two possibilities to use dlsym:
1) ptrtofntype f = (ptrtofntype) dlsym (...);
2) *(void**)&f = dlsym (...);

The former is invalid ISO C (conversion between void* and function pointer
not allowed), the latter is invalid ISO C (alias violation).

So they were between a rock and a hard place, the dlsym interface was
impossible to use with a strict ISO C compiler when it was used to get at
addresses of functions.

That's why they added language to POSIX 2008 to make conversions between
void* and function-pointer types valid.  They could have added a new
interface in parallel to dlsym that would return a function pointer from
the start.  Well, they chose to add a new requirement for POSIX systems
making variant (1) valid.

GCC, at least on POSIX systems, should reflect this, and also make this
conversion valid.  In fact we're already doing the right thing for such
conversions, so we only need to specify that this isn't going to change
in the future and disable the warning even in pedantic mode.

That means we wouldn't be a strict ISO compiler in this mode anymore.
It's what happen when there are two standards in conflict with each other.
I think that by default, even with -pedantic, we should not warn for the
void* <-> fnptr conversion (note that POSIX only specifically allows the
conversion from/to void*, not to any arbitrary data pointer type).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45289

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[hjl dot tools at gmail dot com]

--- Comment #11 from hjl dot tools at gmail dot com  2010-08-15 21:15 
---
It works for me with -fPIC -fPIE using gcc 4.4.4 on
Fedora 13. I got

movq__restore...@gotpcrel(%rip), %rax
movq%rax, 56(%rsp)

in assembly output. It is correct. Please make sure that
you use the current Linux binutils.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[zorry at ume dot nu]

--- Comment #12 from zorry at ume dot nu  2010-08-15 21:31 ---
(In reply to comment #11)
> It works for me with -fPIC -fPIE using gcc 4.4.4 on
> Fedora 13. I got
> 
> movq__restore...@gotpcrel(%rip), %rax
> movq%rax, 56(%rsp)
> 
> in assembly output. It is correct. Please make sure that
> you use the current Linux binutils.
> 
what do you get only with -fPIE?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45289] gcc lacks a "posix" option for "-std" since POSIX 2008 defines special behavior

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-08-15 21:33 ---
There are more possibilities, like:
3) void (*fnptr) (void); void *p = dlsym (...); memcpy (&fnptr, &p, sizeof
(p)); fnptr ();
The POSIX standard wording doesn't talk about void * and function pointers
being compatible types as used in ISO C99, 6.5.  It only talks about the same
representation and conversion preserving it.  Thus, from this wording, I'd say
the 1) is also valid for POSIX, but not 2).  When the representation is the
same, memcpy should be safe, both from aliasing POV and should DTRT, as
workaround for the warning in 1).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45289

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[hjl dot tools at gmail dot com]

--- Comment #13 from hjl dot tools at gmail dot com  2010-08-15 21:36 
---
(In reply to comment #12)
> (In reply to comment #11)
> > It works for me with -fPIC -fPIE using gcc 4.4.4 on
> > Fedora 13. I got
> > 
> > movq__restore...@gotpcrel(%rip), %rax
> > movq%rax, 56(%rsp)
> > 
> > in assembly output. It is correct. Please make sure that
> > you use the current Linux binutils.
> > 
> what do you get only with -fPIE?

The same. Please try the current Linux binutils from:

http://www.kernel.org/pub/linux/devel/binutils/

It could be a linker bug.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45289] gcc lacks a "posix" option for "-std" since POSIX 2008 defines special behavior

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-08-15 21:38 ---
Note that this is a common mistake anyways and for example with LTO we
unify all pointer alias-sets to that of void *.  In fact I proposed that
for all languages anyway (look at the hack the C++ FE has for pointer-to-member
function pointers for example).

So, I'll just take this one and finally commit the pending patch(es).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-08-15 21:38:37
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45289

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[vapier at gentoo dot org]

--- Comment #14 from vapier at gentoo dot org  2010-08-15 21:59 ---
we are using current GNU binutils (2.20.1).  we dont use Linux binutils anymore
in Gentoo by default due to the instability and random patches that never get
mainlined into the GNU binutils.  however, even with binutils-2.20.51.0.11, i
get the same behavior:
  f8:   48 8b 05 11 ff ff ffmov-0xef(%rip),%rax   # 10 <__restore_rt>

while the initial report is gcc-4.3.4, same behavior can be observed with
gcc-4.4.4.  seems general users (like me) cannot update the Known-to-fail
field.

how can it be a linker bug if the compiled .o seems to be incorrect ?  i dont
think lazy linking changes the actual code generated ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[rguenth at gcc dot gnu dot org]

--- Comment #15 from rguenth at gcc dot gnu dot org  2010-08-15 22:11 
---
(In reply to comment #14)
> we are using current GNU binutils (2.20.1).  we dont use Linux binutils 
> anymore
> in Gentoo by default due to the instability and random patches that never get
> mainlined into the GNU binutils.

That's ok - I think nobody uses Linux binutils anymore.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

[Bug middle-end/45292] New: [4.5/4.6 regression] libgomp test failures for i586-linux

[hjl dot tools at gmail dot com]

When configured for i586-linux, there are extra
libgomp test failures:

FAIL: libgomp.c/nqueens-1.c execution test
FAIL: libgomp.c/pr39591-1.c execution test
FAIL: libgomp.c/pr39591-2.c execution test
FAIL: libgomp.c/sort-1.c execution test
FAIL: libgomp.c/task-2.c execution test
FAIL: libgomp.c/task-3.c execution test

Gcc 4.4.4 works fine.


-- 
   Summary: [4.5/4.6 regression] libgomp test failures for i586-
linux
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45292

[Bug middle-end/45292] [4.5/4.6 regression] libgomp test failures for i586-linux

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Known to fail||4.5.3 4.6.0
  Known to work||4.4.4
   Target Milestone|--- |4.5.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45292

[Bug middle-end/45231] gcc.c-torture/compile/941014-2.c ICEs with -fgraphite-identity

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-08-15 23:09 ---
Created an attachment (id=21485)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21485&action=view)
reduced testcase

Testcase crashes at x86_64-linux as well.
Valgrind output (r163261):

$ valgrind --trace-children=yes -q
/mnt/svn/gcc-trunk/binary-163261-lto-fortran-checking-yes-rtl-df/bin/gcc -O1
-funswitch-loops -fgraphite-identity testcase.c
==1230== Invalid read of size 1
==1230==at 0x716434: gsi_for_stmt (gimple.h:245)
==1230==by 0xF4404F: insert_out_of_ssa_copy (graphite-sese-to-poly.c:2130)
==1230==by 0xF4486B: rewrite_phi_out_of_ssa (graphite-sese-to-poly.c:2328)
==1230==by 0xF4A1C1: rewrite_reductions_out_of_ssa
(graphite-sese-to-poly.c:2403)
==1230==by 0xF35A8C: graphite_transform_loops (graphite.c:290)
==1230==by 0x984326: graphite_transforms (tree-ssa-loop.c:296)
==1230==by 0x7BF13B: execute_one_pass (passes.c:1567)
==1230==by 0x7BF3D4: execute_pass_list (passes.c:1622)
==1230==by 0x7BF3E6: execute_pass_list (passes.c:1623)
==1230==by 0x7BF3E6: execute_pass_list (passes.c:1623)
==1230==by 0x7BF3E6: execute_pass_list (passes.c:1623)
==1230==by 0x901335: tree_rest_of_compilation (tree-optimize.c:452)
==1230==  Address 0x61 is not stack'd, malloc'd or (recently) free'd
==1230== 
testcase.c: In function 'f':
testcase.c:2:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45231

[Bug middle-end/45230] gcc.c-torture/execute/strncmp-1.c ICEs with -fgraphite-identity

[zsojka at seznam dot cz]

--- Comment #2 from zsojka at seznam dot cz  2010-08-15 23:23 ---
Created an attachment (id=21486)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21486&action=view)
reduced testcase

Crashes at x86_64-linu as well.
Valgrind output (r163261):
$ valgrind --trace-children=yes -q
/mnt/svn/gcc-trunk/binary-163261-lto-fortran-checking-yes-rtl-df/bin/gcc -Os
-fgraphite-identity testcase.c
testcase.c: In function 'foo':
testcase.c:2:1: internal compiler error: in rename_uses, at sese.c:534
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45230

[Bug c/45289] gcc lacks a "posix" option for "-std" since POSIX 2008 defines special behavior

[matz at gcc dot gnu dot org]

--- Comment #8 from matz at gcc dot gnu dot org  2010-08-16 00:55 ---
Well, okay, (3) indeed is valid ISO C (no warning) and works on POSIX 2008.
I'd find it very awkward to write such work-around for (1) just so the
warning in strict ISO C mode is silenced.  I find this case different from
other cases where such warnings about standard violations are explicitely
wanted even though perhaps the code happens to work.  I think it's different
from those cases because POSIX (mostly concerned with portability) is a 
standard too, one that we'd probably like to adhere to on some systems.

Hence, I still would suggest to not warn about solution (1), even in ISO C
mode.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45289

[Bug c++/45293] New: ICE in iterative_hash_template_arg, at cp/pt.c:1589

[fang at csl dot cornell dot edu]

with g++-4.5.1 (powerpc-apple-darwin8):
internal compiler error: in iterative_hash_template_arg, at cp/pt.c:1589
with the attached unreduced test case, which I'm delta-reducing at the
moment...

never tested against 4.5.0.  
This code compiled with 4.4.x and earlier, which leads me to believe that it is
valid, but I cannot be certain.


-- 
   Summary: ICE in iterative_hash_template_arg, at cp/pt.c:1589
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fang at csl dot cornell dot edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45293

[Bug c++/45293] ICE in iterative_hash_template_arg, at cp/pt.c:1589

[fang at csl dot cornell dot edu]

--- Comment #1 from fang at csl dot cornell dot edu  2010-08-16 01:07 
---
Created an attachment (id=21487)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21487&action=view)
unreduced test case triggering ICE


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45293

[Bug middle-end/45292] [4.5/4.6 regression] libgomp test failures for i586-linux

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2010-08-16 01:13 ---
It is caused by revision 145825:

http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00448.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||bonzini at gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45292

[Bug middle-end/45292] [4.5/4.6 regression] libgomp test failures for i586-linux

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2010-08-16 01:18 ---
libgomp is miscompiled.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45292

[Bug middle-end/45292] [4.5/4.6 regression] libgomp test failures for i586-linux

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2010-08-16 02:29 ---
task.o is miscompiled.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45292

[Bug middle-end/45292] [4.5/4.6 regression] libgomp test failures for i586-linux

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2010-08-16 02:52 ---
gomp_barrier_handle_tasks is miscompiled.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45292

[Bug target/45294] New: pextrw, redundant zero (or otherwise) extension

[tbptbp at gmail dot com]

This is a friendly reminder there's still no way to enjoy pextrw without undue
zero/sign extension unless inline asm is used; there's even a gradient of
ignominy from intrinsic to builtins, as exemplified by:
$ cat pextrw.cc
#include 
long unsigned int foo1(__m128i x) { return _mm_extract_epi16(x, 3); }
long unsigned int foo2(__v8hi x) { return __builtin_ia32_vec_ext_v8hi((__v8hi)
x, 3); }
int main() { return 0; }
$ /usr/local/gcc-4.6-20100811/bin/g++ -O3 -march=native pextrw.cc
004004a0 <_Z4foo1Dv2_x>:
  4004a0:   66 0f c5 c0 03  pextrw $0x3,%xmm0,%eax
  4004a5:   98  cwtl   
  4004a6:   48 98   cltq   
  4004a8:   c3  retq   

004004b0 <_Z4foo2Dv8_s>:
  4004b0:   66 0f c5 c0 03  pextrw $0x3,%xmm0,%eax
  4004b5:   48 0f bf c0 movswq %ax,%rax
  4004b9:   c3  retq   

That's on x86-64, on a Intel I7 which, incidentally, is much faster at that
whole pextrw business than previous generations.

This report may or may not be construed as a duplicate of the long forgotten PR
41323.


-- 
   Summary: pextrw, redundant zero (or otherwise) extension
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45294

[Bug middle-end/45292] [4.5/4.6 regression] libgomp test failures for i586-linux

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2010-08-16 05:04 ---
Disable

+(define_expand "cmpcc"
+  [(set (reg:CC FLAGS_REG)
+(compare:CC (match_operand 0 "flags_reg_operand" "")
+(match_operand 1 "general_operand" "")))]
+  ""
+{
+  ix86_compare_op0 = operands[0];
+  ix86_compare_op1 = operands[1];
+  DONE;
+})

fixed miscompilation. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45292

[Bug middle-end/45292] [4.5/4.6 regression] libgomp test failures for i586-linux

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2010-08-16 05:18 ---
-mtune=i586 miscompiled gomp_barrier_handle_tasks which
has a loop and calls:

static inline void gomp_mutex_lock (gomp_mutex_t *mutex)
{
  if (!__sync_bool_compare_and_swap (mutex, 0, 1))
gomp_mutex_lock_slow (mutex);
}

setcc was moved out of loop. But for multi-thread
applications, __sync_bool_compare_and_swap may change
CC even if current thread doesn't change anything.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45292

[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O

[jvdelisle at gcc dot gnu dot org]

--- Comment #9 from jvdelisle at gcc dot gnu dot org  2010-08-16 06:09 
---
The problem resides in resolve_transfer.  The checks are not performed because
the expression is wrapped in parenthesis and so the expression is of type
EXPR_OP, so resolve_transfer is just exited.  The following patch simply finds
the first operand that is not of type EXPR_OP and sets exp to that for
checking.

Index: resolve.c
===
--- resolve.c   (revision 163259)
+++ resolve.c   (working copy)
@@ -7696,6 +7696,12 @@

   exp = code->expr1;

+  while (exp != NULL && exp->expr_type == EXPR_OP)
+exp = exp->value.op.op1;
+
+  if (exp == NULL)
+return;
+
   if (exp->expr_type != EXPR_VARIABLE && exp->expr_type != EXPR_FUNCTION)
 return;



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859

[Bug c++/45293] ICE in iterative_hash_template_arg, at cp/pt.c:1589

[fang at csl dot cornell dot edu]

--- Comment #2 from fang at csl dot cornell dot edu  2010-08-16 06:11 
---
still reducing...

command to reproduce (passed to multidelta):

#!/bin/sh
g++-fsf-4.5 -pipe -ansi -pedantic-errors -Wold-style-cast -Woverloaded-virtual
-W -Wextra -Wall -Wundef -Wshadow -Wno-unused-parameter -Wpointer-arith
-Wcast-qual -Wcast-align -Wconversion -Werror -std=c++0x -Wno-error=conversion
-g -O3 -Wno-long-long -o footprint.o -c footprint.ii > footprint.err 2>&1
grep -q "internal compiler error: in iterative_hash_template_arg, at
cp/pt.c:1589" footprint.err


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45293

[Bug fortran/45295] New: intrinsic.texi: SELECTED_CHAR_KIND should mention wide-char support

[burnus at gcc dot gnu dot org]

http://gcc.gnu.org/onlinedocs/gfortran/SELECTED_005fCHAR_005fKIND.html

only mentions DEFAULT and ASCII, it should also include ISO_10646 and possibly
some example for it.

Possible example (requires an UTF-8 terminal):

use iso_fortran_env
implicit none
integer, parameter :: wc = selected_char_kind('ISO_10646')
integer, parameter :: ac = selected_char_kind('ASCII')

character(kind=wc,len=20) :: hello4
character(kind=ac,len=20) :: hello1

hello1 = ac_'Hello'
hello4 = wc_'Hello and '//char(int(z'4F60'),wc)//char(int(z'597D'),wc)
open(output_unit,encoding='utf-8')
write(*,'(5a)') '>',trim(hello1),'<'
write(*,'(3a)') '>',trim(hello4),'<'
end


-- 
   Summary: intrinsic.texi: SELECTED_CHAR_KIND should mention wide-
char support
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45295

[Bug rtl-optimization/45296] New: register long double ICE at -O2, -Os, -O3

[adam at consulting dot net dot nz]

#include 

register long double F80 __asm__("st");

typedef void (*inst_t)(uint32_t *ip);

void exec_inst(uint32_t *ip) {
  ((inst_t) (uint64_t) ip[0])(ip);
}

int main() {
  return 0;
}

At -O2 and above gcc generates:

register_long_double_ICE.c:3:1: warning: call-clobbered register used for
global register variable
register_long_double_ICE.c: In function ‘exec_inst’:
register_long_double_ICE.c:9:1: internal compiler error: in compensate_edge, at
reg-stack.c:2789
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: register long double ICE at -O2, -Os, -O3
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: adam at consulting dot net dot nz


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45296