Bug 46454 - Pointer to pointer function parameter handled incorrectly
Summary: Pointer to pointer function parameter handled incorrectly
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.4.5
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-12 19:07 UTC by Alexander Taradov
Modified: 2010-11-12 23:28 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Taradov 2010-11-12 19:07:12 UTC
Exact GCC version: gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)

Program below when compiled with -O2 or higher produces output like:
------- 0x08724018 0x00000000 0x08724008

With -O1 it produces expected output:
------- 0x09917018 0x09917008 0x09917008

------------------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

typedef struct List_t
{
  struct List_t *next;
} List_t;

typedef struct Symbol_t
{
  struct Symbol_t *next;
} Symbol_t;

typedef struct First_t
{
  Symbol_t       *set;
} First_t;

static void list_add(void **list, void *element)
{
  ((List_t *)element)->next = NULL;

  if (*list)
  {
    List_t *last = *list;
    while (last->next)
      last = last->next;
    last->next = element;
  }
  else
    *list = element;
}

int main(void)
{
  First_t *item;
  Symbol_t *res;

  res = malloc(sizeof(Symbol_t));
  res->next = NULL;

  item = malloc(sizeof(struct First_t));
  item->set = NULL;
  list_add((void *)&item->set, res);

  printf("------- 0x%08lx 0x%08lx 0x%08x\n", item, item->set, res);
  return 0;
}
--------------------------------------

Bug seems to be fixed in 4.6.x branch, but present in 4.4.x and 4.5.x.
Comment 1 Drea Pinski 2010-11-12 19:14:39 UTC
I think this has aliasing violations in it.
Comment 2 Alexander Taradov 2010-11-12 19:50:40 UTC
(In reply to comment #1)
> I think this has aliasing violations in it.

Yes, my bad.
Comment 3 Richard Biener 2010-11-12 23:28:54 UTC
see comment #2